JP2005110294A

JP2005110294A - 送受信方法およびその装置

Info

Publication number: JP2005110294A
Application number: JP2004318793A
Authority: JP
Inventors: Tomoyoshi Ito; 智祥伊藤; Takao Yamaguchi; 孝雄山口; Junichi Sato; 潤一佐藤; Hiroshi Arakawa; 博荒川; Yoshinori Matsui; 義徳松井; Yoji Notoya; 陽司能登屋
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2000-08-24
Filing date: 2004-11-02
Publication date: 2005-04-21
Anticipated expiration: 2021-08-13
Also published as: JP3708950B2

Abstract

【課題】インターネットのような、様々な接続形態が存在し、しかも伝送帯域が変動する伝送路において（特に、従来安定した伝送品質でデータ伝送を行うことが困難であった有線網、無線網の混在する接続形態において）、安定した伝送品質でデータ伝送を行う。
【解決手段】有線区間と無線区間の境界に位置するゲートウェイ６２から、受信端末６１に対して有線区間でのパケットロスをロス通知パケットを用いて通知することにより、パケットロスの原因を切り分ける。また、このロス通知パケットを利用して、有線区間、無線区間のパケットロス率を個別に計算し、それぞれの区間のロス率に応じて、送信端末６０におけるデータパケットの伝送レート、誤り耐性強度を決定する。
【選択図】図６

Description

本発明は、携帯電話や携帯情報端末、パソコンやＴＶといった様々な仕様、能力を持つ受信端末が無数に存在するネットワーク環境におけるデータの送受信方法に関し、特に音声情報などの時系列的制約が大きい情報と、絵画や医療画像などの静止画像データのように、時間的にはとびとびになっても情報伝達を行うことができる情報とが混在する中で、いかに効率良く、情報を伝達するかといった情報通信技術に関するものである。

パケットロスの発生する環境においてパケットを送信する場合には、ロスしたパケットの再送を行うことで、サービス品質の高いデータ送信が可能となる。ＲＴＰ（Realtime Transport Protocol）に再送の枠組みを提供する方法として、Ｗ−ＲＴＰ（Wireless-RTP）やＲＴＰ／ＲＸといったストリームパケットの送受信方法が挙げられる。Ｗ−ＲＴＰやＲＴＰ／ＲＸでは、ロスしたパケットに対して受信端末からＲＴＣＰ（RTP Control Protocol）を用いて再送要求を送信し、送信端末は再送要求に応じてＲＴＰパケットを再送する（A. Miyazaki et al., "RTP Payload Format to Enable Multiple Selective Retransmissions", Internet Draft, draft-miyazaki-avt-rtp-selret-01.txt, Internet Engineering Taskforce, Jul. 2000や、K. Yano et al., "RTP Profile for RTCP-based Retransmission Request for Unicast session", Internet Draft, draft-podolsky-avt-rtprx-01.txt, Internet Engineering Taskforce, Mar. 2000を参照）。

一方、ＲＦＣ２７３３には、ＦＥＣ（Forward Error Correction）によりロスパケットを復元する技術が規定されている（J. Rosenberg et al., "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, Internet Engineering Taskforce, Dec. 1999）。日本国特開２００１−０４５０９８号公報に開示された技術によれば、マルチキャスト環境において各受信端末がそれぞれの受信環境に適した受信レートおよびエラー耐性を選択できるように、送信側においてデータの階層符号化を採用し、かつ各受信端末が必要に応じてＦＥＣデータを利用する。各受信端末は、パケットロス率、送信レート、受信レートといった送受信状況をモニタし、送信レートに対する受信レートの比、つまり送受信レート比を計算し、パケットロス率および送受信レート比に従って、受信すべきデータの階層と、ＦＥＣデータの受信の要否とを決定する。

上記従来技術には、次のような種々の課題があった。

〈課題１〉
（１）送信端末や伝送路が過負荷な状態になった場合、（２）より多くの受信端末にストリームパケットを送信するために再送を制限してストリームパケット送信用の帯域を確保する場合、（３）受信端末ごとに再送を行うか行わないかを区別することで異なるサービスを提供する場合には、再送を制限する必要がある。Ｗ−ＲＴＰやＲＴＰ／ＲＸは、こういった場合でも再送要求を停止する機能を持たないため、受信端末が再送要求パケットを送信し続け、帯域を無駄に消費することになる。

〈課題２〉
Ｗ−ＲＴＰやＲＴＰ／ＲＸによれば、送信端末が複数の受信端末から一度に多くの再送要求パケットを受信した場合には、送信端末もしくは伝送路が瞬間的な過負荷状態となるため、送信端末のデータパケットの送信処理に悪影響を及ぼす場合がある。

〈課題３〉
パケットの伝送路が有線区間と無線区間とをもつものとする。一般に、有線区間と無線区間のロスの原因は異なる。有線区間のパケットロスは輻輳が原因であるため、再送要求を行うとより輻輳を悪化させる可能性がある。したがって、有線区間でのパケットロスである場合には、再送要求を行う際に、パケットの伝送レートを下げるか、もしくは再送要求を行わないといった処理を行う必要がある。また、無線区間でのパケットロスの原因は、ビット誤りによる受信端末でのパケット廃棄である。したがって、有線区間での再送方法を利用して、再送要求に従ってパケットの伝送レートを下げてもパケットロス率は変化しないため、パケットの伝送レートを下げ続ける結果となる。以上から、受信端末は、再送要求を行う場合にロスがどちらの区間でロスしたかを切り分け、有線区間でロスした場合と、無線区間でロスした場合とで再送要求の方法を切り替えることが必要となる。

ところが、ＲＴＰ／ＲＸには、有線区間と無線区間のパケットロスを区別するための方法がない。Ｗ−ＲＴＰは、有線区間と無線区間の境界に存在するゲートウェイにおいてＷ−ＲＴＰパケットのＳＳＮ（Second Sequence Number）を変更することで、有線区間で発生したパケットロスに対して再送要求を行わないようにすることが可能である。しかしながら、Ｗ−ＲＴＰはＲＴＰのパケットフォーマットを変更する方法であるため、従来のＲＴＰパケットを送信する送信端末からのストリームを受信するためには、Ｗ−ＲＴＰパケットを送信するように送信端末を変更するか、ゲートウェイにおいてＲＴＰヘッダをＷ−ＲＴＰ用に変換する変換処理が必要になる。

〈課題４〉
パケットロスの原因による動作の切り替えは、再送の場合だけでなく、伝送レート制御や、データパケットに誤り耐性を付加する場合にも必要である。輻輳が原因でパケットロスが発生した場合には、輻輳回避のために伝送レートを下げる必要があるが、伝送誤りが原因である場合には、伝送レートを下げても誤り率は変化しないため、伝送レートを下げるのは無意味であり、むしろデータパケットに付加する誤り耐性を強化すべきである。

上記日本国特開２００１−０４５０９８号公報の技術では、各受信端末において受信レートをモニタするために、伝送誤りが発生したパケットについてもパケット長を知る必要がある。ところが、パケット長を示すフィールドにも誤りが発生している可能性があるため、正確な受信レートを求めることができない。さらに、送受信レート比からは、無線区間で実際にどれだけのパケットロスが発生したかを知ることはできないため、どの程度の誤り耐性強度を付加するべきかを決定する（すなわち、送受信レート比の閾値を決定する）のが困難である。

本発明は、このような従来の課題を考慮し、インターネットのような、様々な接続形態が存在し、しかも伝送帯域が変動する伝送路において（特に、従来安定した伝送品質でデータ伝送を行うことが困難であった有線網、無線網の混在する接続形態において）、安定した伝送品質でデータ伝送を行うことを目的とする。

この目的を達成するため、本発明に係る送受信方法は、有線区間と無線区間とをもつ伝送路において、両区間の境界部分にゲートウェイが存在し、当該ゲートウェイを介して送信端末と受信端末との間でデータパケットを送受信し、かつゲートウェイと受信端末との間でロスしたデータパケットについては受信端末が再送要求を行う送受信方法であって、送信端末とゲートウェイとの間でデータパケットがロスしたことを示す情報を、ゲートウェイがロス通知パケットとして受信端末に送信し、当該ロス通知パケットにより通知されたデータパケットについては受信端末が再送要求を行わないこととしたものである。

以下では、本発明に係る実施の形態について、図面を参照しつつ説明を行う。

〈実施の形態１〉
本実施の形態は、送信端末から複数の受信端末の再送要求を各々禁止／許可することにより、主として前述の課題１を解決するものである。

図１は、本実施の形態における全体像を示す概略図である。送信端末１０において、送受信部１０１はモデム、ＬＡＮ（Local Area Network）等のパケットを送受信する手段である。通信環境としては、ノイズや輻輳によりパケットロスの発生する環境を想定している。

データ送信部１００は、ビデオキャプチャ、マイク、ファイル、共有メモリといった入力からデータを受け取り、必要なら符号化し、必要ならパケット化して、送受信部１０１を通して受信端末１１へデータパケットを送信する手段である。また、再送制御部１０２の指示により、再送要求のあったデータパケットを再送する手段でもある。

再送制御部１０２は、受信端末１１からの再送要求パケットを受信し、要求のあったデータパケットの再送をデータ送信部１００に指示する手段である。また、再送要求禁止／許可制御部１０４の指示により、受信端末１１に対して再送要求禁止通知パケット、再送要求許可通知パケットを送信する手段でもある。

再送要求禁止／許可制御部１０４は、伝送路や送信端末１０の負荷の状態、接続しているユーザの種別、各ユーザが使用しているアプリケーションの種別などを監視し、これらの情報に応じて再送要求禁止通知パケットもしくは再送要求許可通知パケットを受信端末１１へ送信するよう再送制御部１０２に指示する手段である。ユーザの種別による再送要求の禁止／許可の例としては、ユーザが加入しているサービスによって再送の有無を区別し、より高いサービス料金を支払っているユーザに再送を行って、より良いサービス品質を提供するといった例が考えられる。また、アプリケーションの種別による再送要求の禁止／許可の例としては、ＶｏＤ（Video on Demand）のようなリアルタイム性の低いアプリケーションであれば再送要求を許可し、ＴＶ電話のようなリアルタイム性の強いアプリケーションであれば再送要求を禁止するといった例が考えられる。リアルタイム性の強いアプリケーションでは、再送が間に合わない場合が多いためである。

端末制御部１０３は、これら各部を制御する手段である。

受信端末１１において、送受信部１１０は、モデム、ＬＡＮ等の、送信端末１０より送信されたデータパケットを受信する手段である。データ受信部１１１は、送受信部１１０からデータパケットを受け取り、必要ならパケットをシーケンス番号順に並べ替え、必要ならパケットをほどき、必要なら復号化し、モニタ、スピーカ、ファイル、共有メモリといった出力にデータを渡す手段である。再送要求制御部１１２は、データパケットのロスを観測し、ロスしたパケットに対して再送要求を行う。また、送信端末１０から再送要求禁止通知パケットを受信した場合には、再送要求を行わないように制御する手段でもある。端末制御部１１３は、これら各部を制御する手段である。

送信端末１０と受信端末１１との間で送受信される情報は、再送要求パケット、再送要求禁止／許可通知パケット、データパケット、再送データパケットである。再送要求パケットは、再送要求制御部１１２から送信され、再送制御部１０２で受信される。再送要求禁止／許可通知パケットは、再送制御部１０２から送信され、再送要求制御部１１２で受信される。データパケットおよび再送データパケットは、データ送信部１００から送信され、データ受信部１１１で受信される。送信端末１０は、複数の受信端末１１との間で、再送要求パケット、再送要求禁止／許可通知パケット、データパケット、再送データパケットの各情報を送受信する。

図２は、送信端末１０と受信端末１１との間で、再送要求禁止／許可通知パケットおよび再送要求パケットの送受信にＲＴＣＰを用い、データパケットの送受信にＲＴＰを用いた場合のシーケンス図である。

送信端末１０は、（１）送信端末１０もしくは伝送路が過負荷の状態になり、再送に応じられない、（２）より多くの受信端末１１にデータパケットを送信するために、再送機能を停止して送信端末１０もしくは伝送路のリソースを確保する、（３）ＴＶ電話のようなリアルタイム性の強いアプリケーションを利用している、（４）ユーザが再送を行わないサービスに加入している、（５）伝送されるべきデータの種別といった理由により、一部もしくは全ての受信端末１１に再送要求禁止通知パケットを通知する（ＲＴＣＰパケット２０１）。再送要求禁止通知パケットを受け取った受信端末１１は、パケットロスを観測した場合でも再送要求を行わない（再送要求しない２００）。なお、伝送されるべきデータの種別に関しては、例えば、映像であればＩ（Intra）、Ｐ（Predictive）、Ｂ（Bidirectionally predictive）といったフレームタイプ、ＭＰＥＧ（Moving Picture Coding Experts Group）であればＧＯＰ（Group Of Pictures）といったシーケンスブロック、音声であれば有音部と無音部、データ構造であればヘッダ部分とペイロード部分、文書であれば見出し部分と本文、あるいは予めデータに編者の意図やエンコーダで優先度情報が付与されていてデータ種別が区別できることを想定している。それぞれのデータ種別に相対的な第１の優先度を付与し、第１の優先度の低い情報に関しては再送を禁止する。例えば、フレーム単位の場合は、ＩフレームはＰ、Ｂフレームより第１の優先度は高いとする。Ｉフレームは単独で復号が可能であるが、Ｐ、Ｂフレームは単独では復号できないためである。シーンブロック単位の場合、編者が強調したいシーンブロック（ＭＰＥＧではシーンブロックはＧＯＰ単位で再生されるのが一般的である）の優先度を高くする。具体的なコンテンツとしてはコマーシャルなどシーンブロックの第１の優先度を高くする。音声であれば、無音部分は情報としては意味をなさないので、第１の優先度は低くする。データ構造であれば、ヘッダ情報は復号、再生に不可欠であるため、ペイロード部分より第１の優先度を高くする。文書の場合は、見出し部分は本文よりも要点が記述されているため、第１の優先度を高くする。このように優先度付けを行い、優先度の高いデータには再送を許可し、優先度の低いデータには再送を禁止する。また、メディアの種類毎に第２の優先度を割り当て、第１と第２の優先度の関係（例えば、優先度値を加算、減算する）から再送禁止のデータを決定してもよい。第２の優先度に関しては、例えば、制御情報、音声、映像の順に高い優先度を付与する。

また、送信端末１０は、（１）送信端末１０もしくは伝送路が過負荷状態から負荷の小さい状態になる、（２）受信端末１１の数が少なく、データパケットを再送する資源を確保できる状況となる、（３）ＶｏＤのようなリアルタイム性の弱いアプリケーションを利用している、（４）ユーザが再送を行うサービスに加入している、（５）伝送されるべきデータの種別といった理由から、一部もしくは全ての受信端末１１に再送要求許可通知パケットを送信する（ＲＴＣＰパケット２０２）。再送要求許可通知パケットを受け取った受信端末１１は、パケットロスを観測した場合に再送要求パケットを送信してもよい（ＲＴＣＰパケット２０３）。

図３は、送信端末１０や伝送路の負荷、ユーザの加入サービスに基づいて、再送制御部１０２が再送要求禁止／許可通知パケットの送信を決定する際の動作を表すフローチャートである。まず、再送制御部１０２は、新規受信端末が接続したかどうかを判定する。新規受信端末が接続した場合には、その受信端末が、再送を行うサービスに加入しているか判定する。サービスに加入していない場合には、再送要求禁止通知パケットをその受信端末に通知し、その受信端末からの再送要求を禁止する。つまり、その受信端末に対しては、再送要求許可通知パケットは送信しない（ステップ３００）。

続いて、送信端末１０のメモリ使用率、ＣＰＵ（Central Processing Unit）使用率、帯域使用率を取得し、これらをそれぞれの閾値と比較する（ステップ３０１）。使用率Ｐが閾値Ｔよりも大きい場合、つまり、利用率Ｐとその閾値Ｔとの差分Ｄが正である場合には、許容範囲内に収まるよう再送要求禁止通知パケットを受信端末１１に送信する（ステップ３０２）。このとき、再送により送信端末１０もしくは伝送路にかかる負荷Ｆを、再送率（全送信パケットに対する再送パケットの割合）Ｒと、使用率Ｐとに基づいて、Ｆ＝Ｐ・Ｒと計算する。受信端末１１の１台あたりに再送する負荷Ｇは、接続端末数をＮとするとＧ＝Ｆ／Ｎである。これらの値から、負荷を許容範囲内に収めるために再送要求禁止通知パケットの送信対象とする受信端末１１の数Ｍは、Ｍ＝Ｄ／Ｇ＝Ｄ・Ｎ／（Ｐ・Ｒ）となる。続いて、Ｍ台の受信端末１１をランダムに選択し、選択された受信端末１１に再送要求禁止通知パケットを送信する。

また、メモリ使用率、ＣＰＵ使用率、帯域使用率のいずれもが閾値よりも小さい場合には、送信端末１０および伝送路に余裕があるため、Ｕ（Ｕは適当な固定値）台の受信端末１１に再送要求許可通知パケットを送信する（ステップ３０３）。

図４は、送信するデータパケットの種別に応じて再送制御部１０２が再送要求禁止／許可通知パケットの送信を決定する際の動作を表すフローチャートである。まず、再送制御部１０２は、送信するデータパケットの種別を取得する（ステップ４００）。送信するデータパケットの種別が再送を許可する種別であった場合には、再送要求許可通知パケットを送信する（ステップ４０１）。一方、再送を許可しない種別であった場合には、再送要求禁止通知パケットを送信する（ステップ４０２）。

なお、本実施の形態は、通常のＩＰ（Internet Protocol）ネットワークの形態であるユニキャストネットワークだけでなく、マルチキャスト、ブロードキャストといったネットワーク形態においても適用が可能である。

〈実施の形態２〉
本実施の形態は、受信端末の再送要求をランダム化することにより、主として前述の課題２を解決するものである。

図５は、本実施の形態における送受信方法を説明するシーケンス図である。この例では、データパケットの送受信にＲＴＰを、再送要求パケットの送受信にＲＴＣＰをそれぞれ用いることとしている。受信端末５０１，５０２でのパケットロスの検知方法としては、ＲＴＰパケットのシーケンス番号の跳びを観測することとしている。

図５において、受信端末５０１，５０２は再送要求を送信するかしないかをランダム化しており、その結果、受信端末５０２はパケットロスが発生しても再送要求パケットを送信しない（５０３）。受信端末５０１からの再送要求パケットを受信した送信端末５００は、データパケットの再送要求をしていない受信端末５０２にも送信する（５０４）。これにより、送信端末５００が統計的には一度に多くの再送要求パケットを受信することがなくなり、再送要求受信による送信端末５００もしくは伝送路の瞬時的な過負荷状態を防ぐことが可能となる。なお、再送要求をするかしないかではなく、パケットロスを検出してから再送要求するまでの時間をランダム化することにしてもよい。過去の再送要求の履歴を参照し、再送要求の傾向の似ている端末をグループ化して、グループ単位に再送を行うことにしてもよい。

〈実施の形態３〉
本実施の形態は、ゲートウェイからロス通知パケットを送信することにより、主として前述の課題３および４を解決するものである。

図６は、本実施の形態における全体像を示す概略図である。図６において、送信端末６０は、ゲートウェイ６２を介して受信端末６１に接続されている。送信端末６０とゲートウェイ６２との間は有線網により、ゲートウェイ６２と受信端末６１との間は無線網によりそれぞれ接続されている。このような接続形態は、携帯電話などの移動体端末が受信端末６１となり、サーバ（送信端末６０）に接続する場合などが考えられる。すなわち、サーバ６０とゲートウェイ６２とがイーサネット（Ethernet）やＡＴＭ（Asynchronous Transfer Mode）などの有線網で接続され、受信端末６１とゲートウェイ６２とが無線ＬＡＮやＷ−ＣＤＭＡ（Wideband Code Division Multiple Access）などの無線網で接続されている場合である。また、家庭内ネットワークが無線ＬＡＮ、BlueToothなどにより構成されており、家庭内のネットワークと外部ネットワークとを接続するホームゲートウェイなどから電話回線などを通じてインターネットに接続されている場合にも、同様の接続形態になる。アプリケーションとしては、ＶｏＤのような映像配信や、ＴＶ電話のような双方向の通信を想定している。

送信端末６０は、図１における送信端末１０から、再送制御部１０２および再送要求禁止／許可制御部１０４を削除したものと同等である。受信端末６１は、再送要求制御部６１０を除き、図１における受信端末１１と同等のものである。

受信端末６１において、再送要求制御部６１０は、パケットロスを観測し、ゲートウェイ６２に再送要求を行う手段である。ただし、ゲートウェイ６２から送信されるロス通知パケットに示されるデータパケットについては、パケットロスを観測しても再送要求パケットを送信しない。使用するプロトコルとしては、ＲＴＣＰといった制御情報用のプロトコルを使用してもよい。

ゲートウェイ６２は、送信端末６０と受信端末６１との間に位置し、有線区間と無線区間との境界部に存在する。このゲートウェイ６２において、送受信部６２０，６２３、データ受信部６２１、データ送信部６２２、端末制御部６２５はそれぞれ、図１の送受信部１０１、データ受信部１１１、データ送信部１００、端末制御部１０３と同等である。再送制御部６２４は、受信端末６１からの再送要求パケットを受信し、データ送信部６２２に再送を指示する手段である。また、データ受信部６２１において受信されるデータパケットにパケットロスが発生した場合には、受信端末６１にロス通知パケットを送信する手段でもある。

送信端末６０とゲートウェイ６２との間で送受信される情報は、データパケットである。ゲートウェイ６２と受信端末６１との間で送受信される情報は、再送要求パケット、ロス通知パケット、データパケット、再送データパケットである。再送要求パケットは、再送要求制御部６１０から送信され、再送制御部６２４で受信される。ロス通知パケットは、再送制御部６２４から送信され、再送要求制御部６１０で受信される。データパケットは、データ送信部６００から送信され、データ受信部６２１、データ送信部６２２を通してデータ受信部６１１で受信される。再送データパケットは、データ送信部６２２から送信され、データ受信部６１１で受信される。

この構成によれば、受信端末６１は、ゲートウェイ６２に無駄な再送要求をすることがなくなり、前述の課題３を解決することができる。

なお、本実施の形態では、再送データパケットはデータパケット送信用のチャネルとは別の制御情報用チャネルを用いて送信することにしている。ただし、データ送信用のチャネルを用いてロスしたデータパケットの代わりに送信してもよい。

また、本実施の形態では、再送要求をゲートウェイ６２で処理することにしているが、ゲートウェイ６２はロス通知パケットを送信するのみとし、再送要求は送信端末６０が処理することにしてもよい。この構成によれば、受信端末６１は無線網のロスに対してのみ再送要求を行うことになるため、ロス通知パケットを送信しないで送信端末６０と受信端末６１との間で再送を行う場合と比較して、再送による有線区間の輻輳の悪化を防ぐことが可能となる。

図７は、データパケットの送受信にＲＴＰを、再送要求パケットおよびロス通知パケットの送受信にＲＴＣＰをそれぞれ用いた場合のシーケンス図である。また、この例では、受信端末６１でのパケットロスの検知方法として、ＲＴＰパケットのシーケンス番号の欠落を観測することとしている。

ゲートウェイ６２は、送信端末６０からのデータパケットのロスを観測した場合には、ロス通知パケットを受信端末６１へ送信する。図７では、データパケット２のロスを検知したため、データパケット２がロスしたことを示すロス通知パケットを送信している（７０１）。なお、ロス通知パケットは、複数のパケットロスの情報を束ねて送信してもよい。ロス通知パケットがロスする可能性を考慮して、データパケットのロスの情報を複数回送信することとしてもよい。受信端末６１は、ロス通知パケットを受信した場合には、ロス通知パケットに示されるパケットについてはＲＴＰパケットのロスを観測した場合でも再送要求パケットを送信しない（７０２）。また、受信端末６１において、ロス通知パケットを受信していない状態でパケットロスを観測した場合には、再送要求パケットを送信する。図７では、ＲＴＰデータパケット４のロスを確認したため、受信端末６１が再送要求パケットを送信している（７０３）。ゲートウェイ６２は、再送要求に応じて再送パケットを送信する。図７では、データパケット４の再送を要求され、この要求に応じて再送を行っている（７０４）。

図８および図９（ａ）〜図９（ｃ）は、上記再送要求禁止／許可通知パケットおよび上記ロス通知パケットを送信するプロトコルとしてＲＴＣＰを利用した場合のフォーマットの例である。

図８において、バージョン８０１、パディング８０２、パケットタイプ８０４、長さ８０５、ＳＳＲＣ８０６については、他のＲＴＣＰパケットと同じ意味を持つ。パケットタイプ８０４には、例えば再送要求の禁止を通知するパケットであることを意味する識別子を入力する。サブタイプ（SubType）８０７には、再送要求禁止通知、再送要求許可通知、パケットロス通知のいずれかを表す識別子を入力する。例えば、SubType＝０が再送要求禁止通知を、SubType＝１がパケットロス通知を、SubType＝２が再送要求許可通知をそれぞれ意味する。再送要求禁止通知部８０８は、サブタイプ８０７の値によって構造が変化する。

図９（ａ）は、サブタイプ８０７が再送要求禁止もしくは再送要求許可を表す識別子である場合、つまりSubType＝０または２の場合のフォーマットの例である。パディング９０１は、バイトアラインのためのパディングビットであり、入力される値に意味はない。シーケンス番号９０２は、再送要求の禁止もしくは許可を開始するデータパケットのシーケンス番号を入力する。

図９（ｂ）および図９（ｃ）は、サブタイプ８０７がパケットロス通知である場合、つまりSubType＝１の場合のフォーマットの例である。フォーマットタイプ（ＦＴ）９０３は、ロス通知パケットのいくつかのフォーマットのうちどれを利用しているかを示す識別子であり、例えば０００、００１、０１０、０１１、１１１のいずれかである。フォーマットタイプ９０３に入力される値により、フォーマットタイプ９０３以降のフォーマットがさらに図９（ｂ）および図９（ｃ）に示されるとおりに変化する。

フォーマットタイプ（ＦＴ）に入力される識別子が１１１以外である場合には、図９（ｂ）のフォーマットが利用される。パディング９０４は、ビットアラインのためのパディングビットであり、入力される値に意味はない。シーケンス番号９０５は、ロスしたパケットを表すＲＴＰのシーケンス番号を入力する。フォーマットタイプ９０３の識別子をＦＴ＝０００〜０１０にすることによって、シーケンス番号９０５に入力された値からいくつまでがロスしたかを表すことが可能である。また、フォーマットタイプ９０３の識別子をＦＴ＝０１１とすることによって、シーケンス番号９０５および９０６を用いてこの間にあるＲＴＰパケットの全てがロスしたことを表すこともできる。

フォーマットタイプ（ＦＴ）に入力される識別子が１１１である場合には、図９（ｃ）に示すフォーマットを用いてパケットロスの状態を表現する。シーケンス番号９０８は、ビットマップ９０９で表されるパケットの欠落状態を表すビット列の先頭ビットがどのシーケンス番号のパケットにあたるかを表す。ビットマップ９０９は、先頭からＮビット目のビットが、シーケンス番号９０８に入力された値＋Ｎ番目のパケットロスの状態を表しており、例えばロスしていれば１を、ロスしていなければ０を入力する。また、長さ９０７はビットマップ９０９の長さを表しており、図８中の長さ８０５で表される最終３２ビットワードのビット列のうち、何ビットまでが有効であるかを示す。

図９（ａ）〜図９（ｃ）のいずれかで表されるフォーマットを１つの要素とし、この要素を列挙することで、複数の情報を表してもよい。ただし、図９（ｃ）のフォーマットを利用する場合には、要素列の一番最後に配置しなくてはならない。図８中の要素数８０３には、再送要求禁止通知部８０８に含まれる要素の数を表す値を入力する。

さて、上記ゲートウェイ６２からのロス通知パケットを無線区間のパケットロス率の計算に利用し、無線区間、有線区間のパケットロス率それぞれに基づいて、データパケットの誤り耐性強度の決定、伝送レートの決定を行うことができる。具体的に述べると、ゲートウェイ６２からのロス通知パケットは、有線区間のパケットロス数を通知するものであり、受信端末６１で観測されるパケットロス数は、有線区間と無線区間の両方でロスしたパケットロス数となる。したがって、
（受信端末６１で観測されたパケットロス数）−（ロス通知パケットで通知されるパケットロス数）＝（無線区間でロスしたパケットロス数）
となり、受信端末６１は、ロス通知パケットを受信することで、無線区間でロスしたパケット数、有線区間でロスしたパケット数をそれぞれ知ることができる。これらの値から有線区間、無線区間のパケットロス率をそれぞれ計算して送信端末６０に通知し、送信端末６０は、これらのパケットロス率に基づいてデータパケットの伝送レート、誤り耐性強度を決定するのである。これにより、前述の課題４を解決することができる。この課題４の解決については、以下の実施形態においてさらに詳しく説明する。

〈実施の形態４〉
図１０は、本実施の形態における全体像を表す概略図である。図１０において、送信端末１２０は、ゲートウェイ１２２を介して受信端末１２１に接続されている。送信端末１２０とゲートウェイ１２２との間は有線網により、ゲートウェイ１２２と受信端末１２１との間は無線網によりそれぞれ接続されている。

ゲートウェイ１２２は、送信端末１２０からのデータパケットを監視し、パケットロスが発生した場合には、パケットロスが発生したことをパケットロス通知を用いて受信端末１２１に通知する。このゲートウェイ１２２において、送受信部１０２０は、図６中の送受信部６２３と同等である。

データパケット観測部１０２１は、送信端末１２０からのデータパケットのパケットロスの発生を検出し、パケットロス通知送信部１０２２に通知する手段である。パケットロスは、データパケットに付加されたシーケンス番号の欠落により検出が可能である。

パケットロス通知送信部１０２２は、データパケット観測部１０２１より通知されたパケットロス発生情報に基づいて、パケットロスが発生したことを示すパケットロス通知を生成し、受信端末１２１に送信する。なお、パケットロス通知のフォーマットは、図８および図９（ｂ）に示すフォーマットを用いてもよい。このパケットロス通知送信部１０２２で生成されるパケットロス通知は、送信端末１２０からゲートウェイ１２２までの伝送路上で発生したパケットロスを通知するものであるため、有線区間のパケットロスを通知することとなる。

端末制御部１０２３は、これら各部を統括管理する手段である。

受信端末１２１は、図６の受信端末６１から再送要求制御部６１０を削除し、パケットロス率計算部１０１４、誤り訂正部１０１０、パケットロス通知受信部１０１２、制御情報送信部１０１３を加えたものである。

受信端末１２１中のデータ受信部１０１１は、送信端末１２０からのデータパケットを受信し、必要ならパケットをシーケンス番号順に並べ替え、必要ならパケットをほどき、必要なら復号化し、モニタ、スピーカ、ファイル、共有メモリといった出力にデータを渡す手段である。また、受信したデータパケットのシーケンス番号のうち、最大の値を最大シーケンス番号として記憶し、また、データパケットのパケットロスを、データパケットのシーケンス番号の欠落から検出し、データのパケットロス数を計算する手段でもある。

パケットロス通知受信部１０１２は、ゲートウェイ１２２からのパケットロス通知を受信し、この通知に含まれる有線区間のパケットロスの情報から、有線区間のパケットロス数を取得する手段である。

パケットロス率計算部１０１４は、データ受信部１０１１において観測されたパケットロス数と、パケットロス通知受信部１０１２から通知された有線区間でのパケットロス数とから、有線区間、無線区間それぞれのパケットロス率を計算する手段である。

制御情報送信部１０１３は、パケットロス率計算部１０１４で計算された有線区間、無線区間のパケットロス率を、送信端末１２０への制御情報パケットに入力して送信する手段である。

誤り訂正部１０１０は、データ受信部１０１１で受信したデータを監視し、パケットロスを検出した場合には、可能であればロスしたパケットの復元を行う手段である。ロスパケットの復元を行う方法としては、ＲＦＣ２７３３に記述される方式を用いてもよい。

送信端末１２０は、図６の送信端末６０に誤り耐性強度決定部１０００、伝送レート決定部１００１、誤り耐性付加部１００２、伝送レート変更部１００３、制御情報受信部１００４を加えたものと同等である。

制御情報受信部１００４は、受信端末１２１から送信される制御情報パケットから、有線区間、無線区間の各々のパケットロス率を取得する手段である。

誤り耐性強度決定部１０００は、制御情報受信部１００４で取得された無線区間のパケットロス率から、データパケットに付加する誤り耐性強度を決定する手段である。

伝送レート決定部１００１は、制御情報受信部１００４で取得された有線区間のパケットロス率から伝送レートを決定する手段である。そのアルゴリズムとして、ＤＤＡ方式（D. Sisalem et al.,"The Direct Adjustment Algorithm: A TCP-Friendly Adaptation Scheme", Technical Report GMD-FOKUS, August 1997. Available from http://www.fokus. gmd.dc/usr/sisalem）、ＬＤＡ方式（D. Sisalem et al.,"The Loss-Delay Based Adjustment Algorithm: A TCP-Friendly Adaptation Scheme", in the proceedings of NOSSDAV'98, July, Cambridge, UK）などを適用してもよい。

誤り耐性付加部１００２は、誤り耐性強度決定部１０００から通知された誤り耐性強度を送信データに付加するための手段である。付加する誤り耐性としては、例えば映像データの符号化方式としてＭＰＥＧ４を利用する場合には、Ｉフレームの挿入間隔、データパケットサイズ、ＡＩＲ（Adaptive Intra Refresh）を行う１フレームあたりのマクロブロックの数、ＣＩＲ（Constant Intra Refresh）の周期、ＨＥＣ（Header Extension Code）の挿入方法、ＲＦＣ２７３３で規定されるＦＥＣパケットの挿入間隔などを変更することで、誤り耐性付加を行うこととしてもよい。

なお、誤り耐性付加部１００２において、データパケット自体に誤り耐性を付加する以外にも、制御情報送信部１０１３において、無線区間のパケットロス率が大きい場合には、有線区間、無線区間のパケットロス率を通知する制御情報パケットの通知間隔を短くすることで、誤り耐性を強化してもよい。制御情報パケットの送信間隔を短くすると、（１）制御情報パケットの送信回数が増え、制御情報の冗長度が上がるため、制御情報パケット自体の誤り耐性強化の効果があるという点と、（２）無線区間のパケットロスが発生した際に、すばやく誤り耐性強度を強くすることが可能となるという点において、誤り耐性を強化する結果となる。

伝送レート変更部１００３は、データパケットの伝送レートを、伝送レート決定部１００１で決定された伝送レートに変更する手段である。

図１１は、本実施形態の動作を表すシーケンス図である。送信端末１２０が受信端末１２１にデータパケットを送信する際に、送信端末１２０とゲートウェイ１２２との間の有線区間でパケットがロスした場合には、ゲートウェイ１２２がシーケンス番号の欠落でパケットロスを検出し、ゲートウェイ１２２からパケットロス通知を送信する（ステップ１１００）。一方、ゲートウェイ１２２と受信端末１２１との間の無線区間でデータパケットがロスした場合には、ゲートウェイ１２２からパケットロス通知を送信しない（ステップ１１０１）。受信端末１２１は、当該受信端末１２１で検出されるパケットロスと、ゲートウェイ１２２からのパケットロス通知から、一定期間の無線区間のパケットロス率と、有線区間のパケットロス率とを計算し、ＲＴＣＰを用いて送信端末１２０に通知する（ステップ１１０２）。送信端末１２０は、ステップ１１０２において受け取ったＲＴＣＰパケットから有線区間、無線区間のパケットロス率を知ることができ、この値に基づいてデータパケットの伝送レート、誤り耐性強度を決定する。

図１２は、パケットロス率計算部１０１４における有線区間、無線区間のパケットロス率の計算方法を示すフローチャートである。パケットロス率計算部１０１４は、データパケットの受信開始とともに起動し、まず、送信端末１２０に無線区間、有線区間のパケットロス率を通知する通知時刻を決定するタイマーをセットする（ステップ１２００）。本フローチャートでは、送信間隔をＩとしている。続いて、通知時刻になると、データ受信部１０１１から過去の時間Ｉの間に受信端末１２１で観測されたパケットロスの数と、過去受信したデータパケットの最大シーケンス番号とを取得する。また、パケットロス通知受信部１０１２から過去の時間Ｉの間にロスしたデータパケットの数を取得する（ステップ１２０１）。これらの値に基づいて、無線区間のパケットロス率を求め、無線区間、有線区間のパケットロス率を送信端末１２０に通知する（ステップ１２０２）。最後に、次の通知時刻を決定し（ステップ１２０３）、ステップ１２０１に戻る。

図１３は、誤り耐性強度決定部１０００におけるデータパケットに付加する誤り強度を決定するアルゴリズムを示すフローチャートである。誤り耐性強度決定部１０００は、データ送信開始から起動し、まず、閾値Ｌ（ｉ）とそれに対応する誤り耐性方式Ｔ（ｉ）との対応表を、送信端末１２０に蓄積されたファイルなどから取得する（ステップ１３００）。ここで、この対応表は、図１４に示すとおり、無線区間のパケットロス率がある閾値の範囲内のときに、データパケットに付加する誤り耐性強度を決定する表となっている。続いて、無線区間のパケットロス率Ｌ３が入力された制御情報パケットを受信すると、閾値Ｌ（ｉ）とＬ３とを比較し、対応する誤り耐性方式を選択する（ステップ１３０１）。その結果を誤り耐性付加部１００２に通知し（ステップ１３０２）、ステップ１３０１に戻る。

なお、上記の例では、受信端末１２１は有線区間のパケットロス率と無線区間のパケットロス率とを送信端末１２０にＲＴＣＰなどを用いて通知し、送信端末１２０がこれらの値に基づいて伝送レート制御、誤り耐性付加を行うが、受信端末１２１が伝送レート決定部１００１と誤り耐性強度決定部１０００とを有し、受信端末１２１が伝送レートや誤り耐性強度を決定することとしてもよい。

また、上記パケットロス通知を行う代わりに、ゲートウェイ１２２での輻輳を通知することとしてもよい。例えば、ゲートウェイ１２２において輻輳が発生し、当該ゲートウェイ１２２のキュー長がある閾値よりも大きくなった場合に、パケットロスを通知するのと同じ方法で輻輳が発生したことを受信端末１２１に通知する。すなわち、ロスしたパケットを通知する代わりに、ゲートウェイ１２２のキュー長がある閾値よりも長い状態のときに到着したパケットを通知する。受信端末１２１は、パケットロス通知を受信した場合と同様に、輻輳が発生した場合には伝送レートを下げるよう送信端末１２０に通知し、輻輳がない場合には伝送レートを上げるよう送信端末１２０に指示する。この方式では、有線区間でのパケットロスが発生する前に伝送レートを下げるため、有線区間でのパケットロスが発生しない。したがって、受信端末１２１は、観測される全てのパケットロスが無線区間のパケットロスであると判定できるようになり、観測されるパケットロス数を誤り耐性の強度の変更に利用できるようになる。なお、輻輳通知は、輻輳が発生しているかどうかを２値で表すだけでなく、輻輳の度合いを表す値（例えば、輻輳なし：１、小輻輳：２、大輻輳：３といったように）を入力してもよい。

〈実施の形態５〉
上記実施の形態４では、受信端末１２１において無線区間のパケットロス率を計算したが、送信端末１２０やゲートウェイ１２２において無線区間のパケットロス率を計算することとしてもよい。本実施の形態では、図１５に示すように、送信端末１５０において無線区間のパケットロス率を計算するよう構成する。

送信端末１５０は、図１０の送信端末１２０にパケットロス通知受信部１５０４とパケットロス率計算部１５０５とを加えたものと同等である。ゲートウェイ１５２のパケットロス通知送信部１５２０からのパケットロス通知を、送信端末１５０に対して送信するのである。なお、この場合には、受信端末１５１で観測されるパケットロス率を制御情報送信部１５１０が送信端末１５０へ通知することとする。

図１６は、図１５の構成におけるパケットロス率計算部１５０５のパケットロス率計算方法を表すフローチャートである。パケットロス率計算部１５０５は、制御情報受信部１５０２が制御情報パケットを受信すると、この制御情報パケットから受信端末１５１で観測されたパケットロス率を取得する。また、パケットロス通知受信部１５０４から、前回制御情報パケットを受信してから今回制御情報パケットを受信するまでの間にロスしたデータパケットの数を取得する。また、データ送信部１５０３から送信したデータパケットの最大シーケンス番号を取得する（ステップ１６０１）。これらの値に基づいて、無線区間のパケットロス率、有線区間のパケットロス率を求め、無線区間のパケットロス率を誤り耐性強度決定部１５００に通知し、有線区間のパケットロス率を伝送レート決定部１５０１に通知し（ステップ１６０２）、ステップ１６０１に戻る。

〈実施の形態６〉
本実施の形態では、図１７に示すように、ゲートウェイ１７２において無線区間のパケットロス率を計算するよう構成する。

図１７は、図１０の構成からパケットロス通知送信部１０２２、パケットロス通知受信部１０１２を削除し、図１０のゲートウェイ１２２に、パケットロス率計算部１７００、制御情報観測部１７０１、制御情報送信部１７０２を追加したものと同等である。

制御情報観測部１７０１は、受信端末１７１から送信される制御情報パケットを受信し、この制御情報パケットに含まれている、受信端末１７１で観測されたパケットロス率を取得する手段である。また、データパケット観測部１７０３で観測された有線区間のパケットロス数を、受信した制御情報パケットに入力して送信する手段でもある。

パケットロス率計算部１７００は、データパケット観測部１７０３で観測された有線区間のパケットロス数と、制御情報観測部１７０１で取得された受信端末１７１のパケットロス率とから、無線区間のパケットロス率を計算する手段である。

制御情報送信部１７０２は、パケットロス率計算部１７００で計算された無線区間のパケットロス率を制御情報パケットとして送信端末１７０に送信する手段である。使用するプロトコルとしては、ＲＴＣＰを想定している。

図１７に示す構成により、ゲートウェイ１７２で無線区間のパケットロス率を計算し、この値を送信端末１７０に通知する。送信端末１７０からみると、図１０の構成の場合と比べて、制御情報パケットの送信元が異なることを除けば、受信する制御情報パケットは同じである。したがって、図１７に示す構成により、ゲートウェイ１７２で無線区間のパケットロス率を計算する構成としても、本発明の実施は可能である。

〈実施の形態７〉
本発明は、１対１通信だけでなく、図１８に示すような１対Ｎ通信（マルチキャスト）においても適用可能である。以下に、マルチキャストにおける実施の形態を示す。

図１９は、マルチキャストにおける実施の形態の全体像を表す概略図である。送信端末１９０において、データ情報送信部１９０３は、送信端末１９０が送信可能な伝送レート、誤り耐性強度を入力したデータ情報を送信する手段である。データ情報としては、図２０に示すような、マルチキャストアドレスとパケットロス率の閾値とを対応させた対応表を送信してもよい。この表は、例えば、無線区間のパケットロス率が０．１以上０．２未満であり、かつ有線区間のパケットロス率が０．２以上であった場合には、アドレス「１２」で表されるマルチキャストアドレスを選択し、このアドレス「１２」を用いてマルチキャストグループに参加することを意味している。

データ送信部１９００，１９０１は、ビデオキャプチャ、マイク、ファイル、共有メモリといった入力からデータを受け取り、必要なら符号化し、必要ならパケット化して、送受信部１９０４を通して受信端末１９１へデータパケットを送信する手段である。これらのデータ送信部１９００，１９０１は、互いに異なる伝送レートや誤り耐性を付加したデータを送信するものとする。送信端末１９０は、このようなデータ送信部を、図２０に示す対応表に記載されるマルチキャストアドレスの数だけ保持しているものとする。送受信部１９０４は、図１における送受信部１０１と同等である。端末制御部１９０２は、これら各部を統括管理する手段である。

ゲートウェイ１９２は、図１０におけるゲートウェイ１２２と同等である。

受信端末１９１は、図１０における受信端末１２１から制御情報送信手段１０１３を削除し、受信データ選択部１９１０、データ情報受信部１９１１を加えたものである。

データ情報受信部１９１１は、送信端末１９０から送信される、当該送信端末１９０が送信可能な伝送レート、誤り耐性強度を入力したデータ情報を受信する手段である。

受信データ選択部１９１０は、パケットロス率計算部１９１２で計算された有線区間、無線区間のパケットロス率と、データ情報受信部１９１１で取得された対応表とに基づき、受信端末１９１が所属するマルチキャストグループのマルチキャストアドレスを選択する。また、選択したマルチキャストグループに所属するマルチキャストグループを変更する手段でもある。１９１３は、受信端末１９１が備えたパケットロス通知受信部である。

図２１は、本実施の形態の動作を表すフローチャートである。まず、受信端末１９１は、送信端末１９０からデータ情報を取得する（ステップ２１００）。続いて、取得したデータ情報の中から、適当なマルチキャストアドレスを選択し、そのマルチキャストアドレスを用いてマルチキャストグループに参加する（ステップ２１０１）。この際、ＩＧＭＰ（Internet Group Management Protocol）を用いる。そして、参加したマルチキャストグループにおいて、データパケットの受信を開始する。データの伝送途中で、有線区間でパケットロスが発生した場合には、ゲートウェイ１９２からパケットロス通知を受信端末１９１へ送信し（ステップ２１０２）、無線区間でパケットロスが発生した場合には、パケットロス通知を送信しない（ステップ２１０３）。受信端末１９１は、当該受信端末１９１で観測されるパケットロスと、パケットロス通知により通知されるパケットロス情報とから、有線区間、無線区間のパケットロス率を計算し、これらの値から当該受信端末１９１が所属するマルチキャストグループを決定する。決定されたマルチキャストグループが、現在所属するマルチキャストグループと異なる場合には、現在所属するマルチキャストグループを離脱し、新しいマルチキャストアドレスに所属しなおす（ステップ２１０４）。

なお、上記のマルチキャストにおける実施の形態においては、マルチキャストアドレスごとに独立したデータを送信することとしたが、階層符号化を利用し、送信端末１９０でベースレイヤ、エンハンスメントレイヤ、誤り耐性レイヤ（ＦＥＣレイヤ）を準備し、受信端末１９１は有線区間、無線区間のパケットロス率に応じて、これらのレイヤを組み合わせて受信することとしてもよい。例えば、受信端末１９１にデータ情報として、図２２の表を送信する。ここで、Ｂはベースレイヤ、Ｅ１、Ｅ２はエンハンスメントレイヤ、Ｆ１、Ｆ２は誤り耐性レイヤのマルチキャストアドレスを表すものとする。そして、例えば受信端末１９１で観測された無線区間のパケットロス率が０．１以上０．２未満であり、かつ有線区間のパケットロス率が０．０５未満であった場合には、ベースレイヤ、エンハンスメントレイヤ１、ＦＥＣレイヤ１を選択し、これらのレイヤを受信することとするのである。

〈実施の形態８〉
図２３は、マルチキャストにおける他の実施の形態の全体像を示す概略図である。図２３は、図１９において、受信端末１９１からパケットロス通知受信部１９１３、パケットロス率計算部１９１２を削除し、送信端末１９０にこれら各部を追加している。また、データ情報送信部１９０３、データ情報受信部１９１１を削除し、制御情報受信部２３００、グループ決定部２３０１を送信端末２３０に追加し、制御情報送信部２３１０、グループ変更部２３１１を受信端末２３１に追加している。

制御情報送信部２３１０は、受信端末２３１で観測されるパケットロス率を制御情報パケットに入力して送信端末２３０に送信する手段である。使用するプロトコルとしては、ＲＴＣＰを想定している。

送信端末２３０において、制御情報受信部２３００は、受信端末２３１から送信された制御情報パケットから、パケットロス率を取得する手段である。

グループ決定部２３０１は、パケットロス率計算部２３０２により計算された、有線区間、無線区間のパケットロス率に基づき、受信端末２３１が所属するマルチキャストグループを決定する。また、受信端末２３１が所属するマルチキャストグループを通知するマルチキャストグループ通知パケットを受信端末２３１に送信する手段でもある。パケットロス率からマルチキャストグループを決定する方法としては、前述の図２０に示す対応表を保持し、この対応表を参照してマルチキャストグループを決定することとしてもよい。

受信端末２３１のグループ変更部２３１１は、送信端末２３０から送信されたマルチキャストグループ通知パケットを受信し、通知されたマルチキャストグループが、当該受信端末２３１が現在所属するマルチキャストグループと異なる場合には、所属するマルチキャストグループを変更する手段である。

図２４は、図２３に示す構成の動作を表すシーケンス図である。受信端末２３１は、最初に、マルチキャストグループＡに参加し、データの受信を開始する（ステップ２４００）。データ送信中に、有線区間でパケットロスが発生した場合には、ゲートウェイ２３２からパケットロス通知を送信端末２３０へ送信し、無線区間でパケットロスが発生した場合にはパケットロス通知を送信しない（ステップ２４０１）。受信端末２３１は、当該受信端末２３１で観測されるパケットロスからパケットロス率を計算し、ＲＴＣＰを用いて送信端末２３０に送信する（ステップ２４０２）。送信端末２３０は、パケットロス通知と受信端末２３１からのパケットロス率から、有線区間、無線区間のパケットロス率をそれぞれ計算し、それらの値から受信端末２３１が所属すべきマルチキャストグループを決定し、受信端末２３１に通知する（ステップ２４０３）。図２４の例では、マルチキャストグループＢに所属するよう通知している。受信端末２３１は、現在所属するマルチキャストグループと通知されたマルチキャストグループとが異なる場合には、現在所属するマルチキャストグループから離脱し、通知されたマルチキャストグループに所属しなおす（ステップ２４０４）。以上により、受信端末２３１は、受信状況に応じたデータ受信が可能となる。

以上、本発明に係る実施の形態１〜８を説明してきた。なお、上記各実施の形態においては、送信端末が有線区間に存在し、受信端末が無線区間に存在するという伝送路を前提としていたが、送信端末が無線区間に、受信端末が有線区間に存在する場合にも、本発明の実施は可能である。

また、上記各実施の形態においては有線区間、無線区間が１段ずつ接続した伝送路を想定しているが、例えば図２５に示すような、有線区間、無線区間が複数縦属接続された伝送路でも、本発明は適用可能である。図２５に示す接続形態としては、屋内のネットワークが有線で構築されており、ＦＷＡ（Fixed Wireless Access）などで外部ネットワークに接続している形態が考えられる。また、自動車の車内ネットワークが有線で構築されており、ＤＳＲＣ（Dedicated Short Range Communication）などで外部ネットワークと接続している場合も同様の接続形態となる。アプリケーションとしては、ＶｏＤのような映像配信や、ＴＶ電話のような双方向の通信が考えられる。

図２５のような接続形態の場合には、ゲートウェイ２５０１が送信端末２５００からゲートウェイ２５０１までの間で発生したパケットロスを検出し、受信端末２５０３（もしくは送信端末２５００）にパケットロス通知を送信する。また、ゲートウェイ２５０２は、送信端末２５００とゲートウェイ２５０２との間で発生したパケットロスを検出し、受信端末２５０３（もしくは送信端末２５００）に通知する。通知を受信した受信端末２５０３（もしくは送信端末２５００）では、
（有線区間２５０４のパケットロス率）＝（ゲートウェイ２５０１からのパケットロス通知から計算されるパケットロス率）、
（無線区間２５０５のパケットロス率）＝（ゲートウェイ２５０２からのパケットロス通知から計算されるパケットロス率）−（ゲートウェイ２５０１からのパケットロス通知から計算されるパケットロス率）、
（有線区間２５０６のパケットロス率）＝（受信端末２５０３でのパケットロス率）−（ゲートウェイ２５０２からのパケットロス通知から計算されるパケットロス率）、
（全有線区間のパケットロス率）＝（有線区間２５０４のパケットロス率）＋（有線区間２５０６のパケットロス率）
と計算することができ、無線区間のパケットロス率と有線区間のパケットロス率とをそれぞれ計算することが可能である。このように、有線区間と無線区間とを相互接続するゲートウェイからパケットロス通知を送信することで、個々の有線区間、無線区間のパケットロス率が計算可能となるため、有線区間、無線区間が複数段接続した場合にも本発明が適用可能であることは明らかである。

以上、本発明に係る実施の形態１〜８とその変形例とを説明したが、本発明の送受信方法を実現するための送信装置（送信端末）、受信装置（受信端末）、ゲートウェイ、およびこれらを備えた送受信システムも本発明に含まれることは、言うまでもない。

本発明は、上述した本発明の送信装置、受信装置、ゲートウェイ、送受信システムの全部または一部の手段（または、装置、素子、回路、部など）の機能をコンピュータにより実行させるためのプログラムであって、コンピュータと協働して動作するプログラムをも含む。なお、本発明のコンピュータは、ＣＰＵなどの純然たるハードウェアに限らず、ファームウェアやＯＳ（Operating System）、さらに周辺機器を含むものであってもよい。

本発明は、上述した本発明の送受信方法の全部または一部のステップ（または、工程、動作、作用など）の動作をコンピュータにより実行させるためのプログラムであって、コンピュータと協働して動作するプログラムをも含む。

また、本発明のプログラムを記録した、コンピュータに読み取り可能な記録媒体も本発明に含まれる。また、本発明のプログラムの一利用形態は、コンピュータにより読み取り可能な記録媒体に記録され、コンピュータと協働して動作する態様であってもよい。また、本発明のプログラムの一利用形態は、伝送媒体中を伝送し、コンピュータにより読み取られ、コンピュータと協働して動作する態様であってもよい。また、記録媒体としては、ＲＯＭ（Read Only Memory）等が含まれ、伝送媒体としては、インターネット等の伝送媒体、光・電波・音波等が含まれる。

また、本発明の構成は、ソフトウェア的に実現してもよいし、ハードウェア的に実現してもよい。

産業上の利用の可能性

本発明によれば、インターネットのような、様々な接続形態が存在し、しかも伝送帯域が変動する伝送路において、安定した伝送品質で、効率良くデータ伝送を行うことができる。特に、従来安定した伝送品質でデータ伝送を行うことが困難であった有線網、無線網の混在する接続形態においても、本発明を適用することにより、インターネットＴＶ電話、ＶｏＤ、放送（マルチキャスト）、ビデオ掲示板などの幅広いアプリケーションにおいて、安定した伝送品質で、効率良くデータ伝送を行うことが可能となる。

本発明の実施の形態１における全体像を示す概略図である。本発明の実施の形態１における送信端末と受信端末との間のシーケンス図である。本発明の実施の形態１における再送制御のフローチャートである。本発明の実施の形態１における他の再送制御のフローチャートである。本発明の実施の形態２における送信端末と複数の受信端末との間のシーケンス図である。本発明の実施の形態３における全体像を示す概略図である。本発明の実施の形態３における送信端末と受信端末との間のシーケンス図である。本発明の実施の形態１および３におけるＲＴＣＰパケットのフォーマット例を示す図である。（ａ）〜（ｃ）は、図８中のサブタイプ（SubType）以下の部分のフォーマット例を示す図である。本発明の実施の形態４における全体像を示す概略図である。本発明の実施の形態４における送信端末と受信端末との間のシーケンス図である。本発明の実施の形態４におけるパケットロス率の計算手順を示すフローチャートである。本発明の実施の形態４における誤り耐性強度の決定手順を示すフローチャートである。本発明の実施の形態４におけるパケットロス率の閾値と誤り耐性方式との対応表である。本発明の実施の形態５における全体像を示す概略図である。本発明の実施の形態５におけるパケットロス率の計算手順を示すフローチャートである。本発明の実施の形態６における全体像を示す概略図である。本発明の実施の形態７におけるマルチキャストでの接続形態を表す図である。本発明の実施の形態７における全体像を示す概略図である。本発明の実施の形態７における有線区間、無線区間のパケットロス率と所属すべきマルチキャストグループとの対応を示す図である。本発明の実施の形態７における送信端末と受信端末との間のシーケンス図である。本発明の実施の形態７における有線区間、無線区間のパケットロス率と所属すべきマルチキャストグループとの対応を示す他の図である。本発明の実施の形態８における全体像を示す概略図である。本発明の実施の形態８における送信端末と受信端末との間のシーケンス図である。本発明が適用可能な、送信端末と受信端末との他の接続形態を示す図である。

Claims

有線区間と無線区間とをもつ伝送路において、前記両区間の境界部分にゲートウェイが存在し、前記ゲートウェイを介して送信端末と受信端末との間でデータパケットを送受信し、かつ前記ゲートウェイと前記受信端末との間でロスしたデータパケットについては、前記受信端末が再送要求を行う送受信方法であって、
前記送信端末と前記ゲートウェイとの間でデータパケットがロスしたことを示す情報を、前記ゲートウェイがロス通知パケットとして前記受信端末に送信し、
前記ロス通知パケットにより通知されたデータパケットについては、前記受信端末が再送要求を行わないことを特徴とする送受信方法。
請求項１記載の送受信方法において、
前記受信端末からの再送要求を、前記送信端末もしくは前記ゲートウェイに送信することを特徴とする送受信方法。
有線区間と無線区間とをもつ伝送路において、送信装置と受信装置との間のデータパケットの中継を司るように前記両区間の境界部分に存在するゲートウェイであって、
前記送信装置と前記ゲートウェイとの間で発生したデータパケットのパケットロスを検出するデータパケット観測手段と、
パケットロスを検出した際に、パケットロスが発生したことを前記受信装置もしくは前記送信装置に通知するパケットロス通知送信手段とを備えたことを特徴とするゲートウェイ。