(57)【要約】【課題】ＴＣＰタイマがタイムアウトする前に無線状態が回復しても、ＲＬＣにおけるデータ欠落時の再送間隔が一定時間であるためにＴＣＰタイマをタイムアウトさせてしまい、その結果として送信レートを低下させてしまうことは好ましくない。【解決手段】一実施形態による通信装置は、第１のプロトコルに基づくデータを、前記第１のプロトコルより下位の第２のプロトコルに基づく送信信号として相手装置に送信し、前記相手装置から前記送信信号に対する送達確認を受信しないとき、前記送信信号を再送する制御部と、前記第１のプロトコルに基づくデータの送信レートを低下させるまでの時間を測る第１のタイマと、前記第２のプロトコルに基づく送信信号を再送するまでの時間を測る第２のタイマとを有する。前記制御部は、前記第１のタイマの経過時間に応じて、前記第２のタイマの設定時間を変更する。【選択図】図６
2010093628.tif 000002
【特許請求の範囲】
【請求項１】
第１のプロトコルに基づくデータを、前記第１のプロトコルより下位の第２のプロトコルに基づく送信信号として相手装置に送信し、前記相手装置から前記送信信号に対する送達確認を受信しないとき、前記送信信号を再送する制御部と、
前記第１のプロトコルに基づくデータの送信レートを低下させるまでの時間を測る第１のタイマと、
前記第２のプロトコルに基づく送信信号を再送するまでの時間を測る第２のタイマとを有し、
前記制御部は、前記第１のタイマの経過時間に応じて、前記第２のタイマの設定時間を変更することを特徴とする通信装置。
【請求項２】
前記制御部は、前記第２のプロトコルの制御信号を用いて、前記第１のタイマの設定値に関する情報を前記相手装置から受信する、請求項１に記載の通信装置。
【請求項３】
前記制御部は、前記第２のプロトコルの制御信号を用いて、前記第１のタイマの設定値に関する情報を前記相手装置に送信する、請求項１に記載の通信装置。
【請求項４】
前記制御部は、前記第１のタイマの経過時間に応じて、前記第２のタイマの設定時間を段階的に変更する、請求項１乃至３いずれか一項に記載の通信装置。
【請求項５】
第１のプロトコルに基づくデータを、前記第１のプロトコルより下位の第２のプロトコルに基づく送信信号として相手装置に送信する段階と、
前記相手装置から前記送信信号に対する送達確認を受信しないとき、前記送信信号を再送する段階とを含み、
前記第１のプロトコルに基づくデータの送信レートを低下させるまでの時間の経過に応じて、前記送信信号を再送するまでの時間を変更することを特徴とする送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信装置及び信号送信方法に関する。
【背景技術】
【０００２】
移動通信システムにおけるデータ通信には様々なプロトコルが使用されている。
【０００３】
図１は、移動通信システムにおいて使用されるプロトコルスタック例を示す図である。図１は、ユーザ端末（ＵＥ）１０が、無線ネットワーク制御装置（ＲＮＣ）２０を介して、パケットデータ網（すなわちコアネットワーク）３０とユーザデータ１２を送受信するときに使用されるプロトコルスタックを示している。具体的には、アクセス側では、ユーザ端末１０は参照符号１５Ａで示したプロトコル群を使用し、無線ネットワーク制御装置２０は参照符号２５Ａで示したプロトコル群を使用する。また、コアネットワーク側では、無線ネットワーク制御装置２０は参照符号２５Ｃで示したプロトコル群を使用する。パケットデータ網３０が使用するプロトコルは省略した。
【０００４】
ユーザデータ１２は一般的にはＴＣＰ／ＩＰベースのパケットデータである。
【０００５】
このように、ＴＣＰ／ＩＰベースのパケットデータを送受信する場合、輻輳制御はＴＣＰのスロースタートアルゴリズムで行われる。
【０００６】
図２は、ＴＣＰにおけるスロースタートアルゴリズムを説明するための図である。ＴＣＰはユーザ端末（ＵＥ）１０とパケットデータ網（すなわちコアネットワーク）３０との間のデータ伝送を制御するプロトコルであり、図を見やすくするため無線ネットワーク制御装置２０は省略した。
【０００７】
ＴＣＰでは、パケットデータ網３０がユーザ端末１０にデータを送信する（ダウンリンク方向の）とき、パケットデータ網３０は、最初に１つのセグメント（パケット）２１を送信する。このセグメントに対する送達確認信号（ＡＣＫ）２２をユーザ端末１０から受信すると、パケットデータ網３０は、次に２つのセグメント２３を送信する。各セグメントに対するＡＣＫ２４をユーザ端末１０から受信すると、パケットデータ網３０は、次に４つのセグメント２５を送信する。各セグメントに対するＡＣＫ２６をユーザ端末１０から受信すると、パケットデータ網３０はさらに倍のセグメントを送信する。このように、パケットデータ網３０は、各セグメントに対する送達確認信号を受信するたびに、一度に送信するセグメント数を倍にしていき、ある一定値に到達すると、後は緩やかに送信セグメント数を増やしていく。
【０００８】
ユーザ端末１０がパケットデータ網３０にデータを送信する（アップリンク方向の）ときもこれと同様である。
【０００９】
一方、所定時間以内（ＴＣＰタイマがタイムアウトする前まで）に送達確認信号（ＡＣＫ）を受信できない送信セグメントが１つでもある（データ欠落）と、パケットデータ網３０は、送信レートを低下して輻輳を防止するため、一度に送信するセグメント数を減少させる。セグメント数の減少のさせ方により、データ欠落が発生すると送信セグメント数を１まで減少させるＴＡＨＯＥ方式と、データ欠落が発生すると送信セグメント数を半分に減少させるＲＥＮＯ方式がある。
【００１０】
図３Ａは、ＴＣＰにおけるデータ欠落時の対応方式であるＴＡＨＯＥ方式を示す図である。
【００１１】
また、図３Ｂは、ＴＣＰにおけるデータ欠落時の対応方式であるＲＥＮＯ方式を示す図である。
【００１２】
次に、アクセス側のプロトコルである無線リンク制御（ＲＬＣ）プロトコルについて説明する。無線リンク制御（以下、ＲＬＣ）は上位レイヤに対して透過型伝送、送達確認型伝送、非送達確認型伝送のサービスを提供する。ここでは送達確認型伝送について説明する。
【００１３】
図４Ａは、ＲＬＣにおける信号送信方法を示す図である。ＲＬＣは伝送データをＰＤＵ（Packet Data Unit）単位で送信する。ＰＤＵにはシーケンスナンバー（ＳＮ）が付与されている。またＰＤＵには送達確認信号の返信の要否を示すＰｏｌｌ−Ｂｉｔが付与されている。
【００１４】
無線ネットワーク制御装置２０は、ユーザ端末１０に送達確認を要求する場合、Ｐｏｌｌ−ＢｉｔをＯＮにしてＰＤＵ４１送信する。
【００１５】
ユーザ端末１０は、Ｐｏｌｌ−ＢｉｔがＯＮのＰＤＵ４１を受信すると、これに対して送達確認信号（ＡＣＫ）４２を返す。
【００１６】
また、Ｐｏｌｌ−ＢｉｔがＯＮでない場合、無線ネットワーク制御装置２０が一連のシーケンスナンバー（この場合、ＳＮ＝１〜４）のＰＤＵ４３を送信して、ＰＤＵ（ＳＮ＝３）が欠落した場合、ユーザ端末２０は、無線ネットワーク制御装置２０に対して再送要求（ＬＩＳＴ）信号４４を送信して、欠落したＰＤＵのシーケンスナンバーＳＮ＝３を通知して再送要求を行う。この再送要求を受信すると、無線ネットワーク制御装置２０はＰＤＵ（ＳＮ＝３）４５を再送する。
【００１７】
ダウンリンクの場合を説明したが、言うまでもなくアップリンクの場合も同様である。
【００１８】
図４Ｂは、ＲＬＣにおけるデータ欠落時の自律再送を示す図である。無線ネットワーク制御装置２０は、Ｐｏｌｌ−ＢｉｔをＯＮにしてＰＤＵ（ＳＮ＝０）４７を送信する。そして、一定時間Ｔまでに送達確認（ＡＣＫ）信号の返信がなければ、自立的に同じＰＤＵ（ＳＮ＝０）４７を再送信する。
【００１９】
なお、無線ネットワークにおける再送制御について、欠落していないデータを再送してしまうことを避けるために、送信装置において再送のタイミングを変更することが提案されている。また、受信装置において、データリンク層で順序保証を行っていると欠落データを待つために通信レートが低下してしまうため、一定の範囲で順序保証をしないことが提案されている。
【特許文献１】特開２００５−２３６９６１号公報
【特許文献２】特開２００５−１５０９５１号公報
【発明の開示】
【発明が解決しようとする課題】
【００２０】
ここまで説明したように、従来、ＲＬＣとＴＣＰはそれぞれ独立に制御され、ＲＬＣはデータ欠落が生じた時に一定時間ごとに同じＰＤＵを再送信する。
【００２１】
しかし、ＴＣＰタイマがタイムアウトする前に無線状態が回復しても、ＲＬＣにおけるデータ欠落時の再送間隔が一定時間であるためにＴＣＰタイマをタイムアウトさせてしまい、その結果として送信レートを低下させてしまうことは好ましくない。
【課題を解決するための手段】
【００２２】
一実施形態による通信装置は、第１のプロトコルに基づくデータを、前記第１のプロトコルより下位の第２のプロトコルに基づく送信信号として相手装置に送信し、前記相手装置から前記送信信号に対する送達確認を受信しないとき、前記送信信号を再送する制御部と、前記第１のプロトコルに基づくデータの送信レートを低下させるまでの時間を測る第１のタイマと、前記第２のプロトコルに基づく送信信号を再送するまでの時間を測る第２のタイマとを有する。前記制御部は、前記第１のタイマの経過時間に応じて、前記第２のタイマの設定時間を変更する。
【００２３】
他の実施形態による送信方法は、第１のプロトコルに基づくデータを、前記第１のプロトコルより下位の第２のプロトコルに基づく送信信号として相手装置に送信する段階と、前記相手装置から前記送信信号に対する送達確認を受信しないとき、前記送信信号を再送する段階とを含む。前記第１のプロトコルに基づくデータの送信レートを低下させるまでの時間の経過に応じて、前記送信信号を再送するまでの時間を変更する。
【発明の効果】
【００２４】
ＴＣＰタイマがタイムアウトする前に無線状態が回復した場合、ＴＣＰタイマをタイムアウトさせずに送信レートを維持できる。
【発明を実施するための最良の形態】
【００２５】
図面を参照して実施形態を詳細に説明する。各図面で同一または対応する構成要素には同一または対応する参照符号を付した。
【００２６】
実施形態として伝送制御プロトコル（ＴＣＰ）と無線リンク制御プロトコル（ＲＬＣ）とを用いる場合を説明する。しかし、他の実施形態では、今後規定されるであろうＴＣＰやＲＬＣに改良や修正を加えたプロトコルを用いるものでもよい。
【００２７】
また、データを無線ネットワーク制御装置（ＲＮＣ）からユーザ端末（ＵＥ）に送信するダウンリンクの場合を主に説明するが、ユーザ端末（ＵＥ）から無線ネットワーク制御装置（ＲＮＣ）に送信するアップリンクの場合も同様である。
【００２８】
図５は、従来のＲＬＣにおける通信方法を示す図である。ユーザ端末１０が、例えばトンネルに入ったり建物の影に入ったりして一時的に無線状態が悪化した場合（図５の網掛け部分に入った状態）、無線ネットワーク制御装置２０はＰｏｌｌ−ＢｉｔをＯＮにしてＰＤＵ（ＳＮ＝０）５１を送信しても、そのＰＤＵはユーザ端末１０に到達せず送達確認（ＡＣＫ）が返信されない。そのため、再送タイマにより一定時間ＴごとにこのＰＤＵ５１の送信を繰り返す。
【００２９】
ユーザ端末１０の無線状態が回復すると（図５において網掛け部分から出た状態）、その後に無線ネットワーク制御装置２０が送信したＰＤＵ５２はユーザ端末１０に到達し、送達確認（ＡＣＫ）５３が返される。
【００３０】
しかし、図５に示したように、ＲＮＣ２０のＲＬＣはＴＣＰとは独立に制御されているため、ＲＬＣによりＰＤＵ５２が再送される時点では、すでにＴＣＰタイマがタイムアウトしてしまうおそれがある。その場合、必ずしも輻輳が生じていなくても、図３Ａ及び図３Ｂを参照して説明したように、ＴＣＰレイヤにおいて輻輳回避のために送信するセグメント数が減少されてしまうという問題がある。
【００３１】
かかる問題を解消または低減するため、一実施形態による通信方法は、伝達制御プロトコル（ＴＣＰ）に基づくデータを、ＴＣＰより下位の無線リンク制御プロトコル（ＲＬＣ）に基づく送信信号として相手装置に送信する段階と、相手装置からその送信信号に対する送達確認を受信しないとき、その送信信号を再送する段階とを含む。そして、伝達制御プロトコルに基づくデータの送信レートを低下させるまでの時間の経過に応じて、その送信信号を再送するまでの時間を変更する。一実施形態では、「変更」とは短縮である。他の実施形態では、「変更」には伸張を含んでもよい。例えば、伝達制御プロトコルに基づくデータの送信レートを低下させるまでの時間の経過に応じて送信信号を送信するまでの時間を複数回変更する場合、その複数回の一部で伸張してもよい。図６を参照して、より詳細に説明する。
【００３２】
図６は、一実施形態によるＲＬＣにおける通信方法を示す図である。トンネルや建物の影に入って一時的に無線品質が悪い状態になったときに、ＴＣＰは、輻輳が生じていなくてもＴＣＰタイマが満了すれば送信セグメント数を落としてしまう。そこで、ＴＣＰタイマの満了が近づいたときにＲＬＣタイマの設定値を変更（この場合短縮）して、ＲＬＣレイヤがより頻繁にＰＤＵを再送するようにする。
【００３３】
図６において、ＲＮＣ２０は、ＰＤＵ５１を送信してそれに対するＡＣＫが返信されなければ、ＲＬＣ再送タイマにより時間Ｔが経過するごとにＰＤＵ５１を再送する。しかし、ＲＮＣ２０は、ＴＣＰタイマをチェックして、その経過時間に応じてＰＤＵを再送する（図６のＰＤＵ６１）までの時間を変更（この場合短縮）する。この時間の短縮はＲＬＣタイマの設定値の変更により行う。これにより、ユーザ端末１０が悪い無線状態（図６の網掛け部分）から脱してからＴＣＰタイマが満了するまでの時間に、ＰＤＵを再送することができ（図６のＰＤＵ６２）、ＡＣＫ６３の返信を受けることができる。
【００３４】
一実施形態では、ＲＬＣタイマの設定値は、図６に示したように、ＴＣＰタイマの経過時間が閾値を越えると満了までの間に、デフォルト値から短縮値に段階的に小さくしていくことができる。他の実施形態では、デフォルト値から短縮値に直線的に短くしてもよい。このように、ＲＬＣタイマの設定値の短縮のしかたは実施形態に応じて適切なものを選択することができる。
【００３５】
ＲＬＣはユーザ端末（ＵＥ）と無線ネットワーク制御装置（ＲＮＣ）との間で終端されるプロトコルであるが、ＴＣＰはユーザ端末（ＵＥ）とパケットデータ網（正確には、パケットデータ網中のサーバ等）との間で終端されるプロトコルである。そのため、ユーザ端末（ＵＥ）はＲＬＣとＴＣＰの両方を実装しているが、無線ネットワーク制御装置（ＲＮＣ）はＲＬＣのみを実装し、ＴＣＰは実装していない。本実施形態では、ＴＣＰレイヤのタイムアウトまでの時間経過に応じて、ＲＬＣレイヤにおけるＰＤＵの再送間隔を短縮するために、ＲＬＣレイヤがＴＣＰレイヤのタイマ値を取得することが好ましい。
【００３６】
そこで、一実施形態では、ＲＬＣの制御信号を用いて、ＴＣＰレイヤのＴＣＰタイマ値、すなわちＴＣＰに基づくデータの送信レートを低下させるまでの時間に関する情報を相手装置から受信する。
【００３７】
図８は、一実施形態によるＲＮＣへのＴＣＰタイマ通知方法を示す図である。ＲＬＣレイヤには、状態を通知するＳＴＡＴＵＳ  ＰＤＵという制御信号がある。この制御信号を用いてＴＣＰレイヤのタイマ値を送信することができる。図８において、ユーザ端末１０は、ＲＮＣ２０とコネクションを設定する（ステップＳ８１）と、ＴＣＰタイマ値を示したＳＴＡＴＵＳ  ＰＤＵをＲＮＣ２０に送信する（ステップＳ８３）。これにより、ＲＮＣが自分に実装されていないＴＣＰのタイマ値を取得することができる。
【００３８】
また、ユーザ端末１０は、ＴＣＰタイマ値に変更が生じると（ステップＳ８５）、変更後のＴＣＰタイマ値を示したＳＴＡＴＵＳ  ＰＤＵをＲＮＣ２０に送信する（ステップＳ８７）。これにより、ＴＣＰレイヤでタイマ値が変更された場合にも、ＲＮＣが自分に実装されていないＴＣＰタイマ値を取得することができる。
【００３９】
このようにＳＴＡＵＳ  ＰＤＵを使用するため、一実施形態では、図９に示したように、ＳＴＡＴＵＳ  ＰＤＵのＳＵＦＩ  Ｔｙｐｅ＝８として新たにＴＣＰタイマを追加することができる。図９は、図８のＴＣＰタイマ通知方法で利用できるＳＴＡＴＵＳ  ＰＤＵを示す図である。このように、ＳＴＡＴＵＳ  ＰＤＵにＴＣＰタイマを通知するＳＵＦＩタイプを追加することにより、ユーザ端末１０が無線ネットワーク制御装置２０にＴＣＰタイマ値を通知することができるようになる。
【００４０】
図１０は、一実施形態によるＲＬＣにおける送信方法１００を示すフローチャートである。送信方法１００において、通信装置（例えば、図６の無線ネットワーク制御装置２０）は、相手装置（例えば、図６のユーザ端末１０）に送信すべきデータがある場合、最初にＲＬＣ  ＰＤＵとしてデータを送信する。このとき同時にＲＬＣ再送タイマを通常のデフォルト値でスタートさせる（ステップＳ１０２）。また同様にＴＣＰレイヤから通知されたＴＣＰタイマの設定値を用いて、ＴＣＰタイマもスタートさせる（ステップＳ１０４）。
【００４１】
通信装置は、送信データ（ＲＬＣ  ＰＤＵ）に対する送達確認を相手装置から受信したか判断する（ステップＳ１０６）。
【００４２】
ステップＳ１０６の判断の結果、送達確認を受信していれば（ステップＳ１０６でＹＥＳ）、ステップＳ１０２でスタートしたＲＬＣタイマをクリアし（ステップＳ１０８）、ステップＳ１０４でスタートしたＴＣＰタイマもクリアする（ステップＳ１１０）。そして、本送信方法は終了する。
【００４３】
一方、ステップＳ１０６の判断の結果、送達確認を受信していなければ（ステップＳ１０６でＮＯ）、ステップＳ１０２でスタートしたＲＬＣ再送タイマが満了したか判断し（ステップＳ１１２）、満了していなければ（ステップＳ１１２でＮＯ）、ステップＳ１０６に戻り、送達確認が取れるか、ＲＬＣ再送タイマが満了するまで待つ。
【００４４】
ステップＳ１１２の判断の結果、ＲＬＣ再送タイマが満了すれば（ステップＳ１１２でＹＥＳ）、該当ＰＤＵを再送して（ステップＳ１１４）、再度ＲＬＣ再送タイマをスタートさせる。このとき、ステップＳ１０４でスタートしたＴＣＰタイマがＸ％（例えば８０％）以上経過しているか判断し（ステップＳ１１６）、Ｘ％以上経過していない場合（ステップＳ１１６でＮＯ）、ＲＬＣ再送タイマにデフォルト値を設定して再びＲＬＣ再送タイマをスタートする（ステップＳ１１８）。そして、ステップＳ１０６に戻り、送達確認が取れるか、ＲＬＣ再送タイマが満了するまで待つ。
【００４５】
一方、ステップＳ１１６の判断の結果、ＴＣＰタイマがＸ％以上経過している場合、ＴＣＰタイマが満了する前に送達確認を取るために、ＲＬＣ再送タイマ値をデフォルト値のＹ％（例えば５０％）にして再びＲＬＣ再送タイマをスタートさせる（ステップＳ１２０）。そして、ステップＳ１０６に戻り、送達確認が取れるか、ＲＬＣ再送タイマが満了するまで待つ。
【００４６】
このようにしてＴＣＰタイマの経過時間に応じて、ＲＬＣレイヤにおけるＰＤＵの再送間隔を変更することにより、無線状態が回復していればＴＣＰタイマの満了前に送達確認を取ることができる。
【００４７】
図１０に示した送信方法１００では、ＴＣＰタイマがＸ％経過したか否かに応じて、ＲＬＣ再送タイマの設定値をデフォルト値からそのＹ％に短縮したが、この短縮のしかたは図７を参照して説明したように、実施形態に応じて様々な態様が考えられる。
【００４８】
このような送信方法の各ステップを、コンピュータ、コントローラ、マイクロプロセッサ等に実行させられることは当業者には明らかである。
【００４９】
ここまで実施形態による送信方法を説明した。次に、これらの送信方法を実施できる、一実施形態による移動通信システムを説明する。この移動通信システムは、無線ネットワーク制御装置とユーザ端末とを含む。
【００５０】
一実施形態による無線ネットワーク制御装置は、伝送制御プロトコル（ＴＣＰ）に基づくデータを、ＴＣＰより下位の無線リンク制御プロトコル（ＲＬＣ）に基づく送信信号としてユーザ端末に送信し、そのユーザ端末から送信信号に対する送達確認を受信しないとき、その送信信号を再送する制御部と、ＴＣＰに基づくデータの送信レートを低下させるまでの時間を測るＴＣＰタイマと、ＲＬＣに基づく送信信号を再送するまでの時間を測るＲＬＣ再送タイマとを有する。制御部は、ＴＣＰタイマの経過時間に応じて、ＲＬＣタイマの設定時間を変更する。
【００５１】
また、他の実施形態によるユーザ端末は、伝送制御プロトコル（ＴＣＰ）に基づくデータを、ＴＣＰより下位の無線リンク制御プロトコル（ＲＬＣ）に基づく送信信号として無線ネットワーク制御装置に送信し、その無線ネットワーク制御装置から送信信号に対する送達確認を受信しないとき、その送信信号を再送する制御部と、ＴＣＰに基づくデータの送信レートを低下させるまでの時間を測るＴＣＰタイマと、ＲＬＣに基づく送信信号を再送するまでの時間を測るＲＬＣ再送タイマとを有する。制御部は、ＴＣＰタイマの経過時間に応じて、ＲＬＣタイマの設定時間を変更する。
【００５２】
一実施形態では、「変更」とは短縮である。他の実施形態では、「変更」には伸張を含んでもよい。例えば、伝達制御プロトコルに基づくデータの送信レートを低下させるまでの時間の経過に応じて送信信号を送信するまでの時間を複数回変更する場合、その複数回の一部で伸張してもよい。
【００５３】
かかる実施形態を、図１１を参照してさらに詳しく説明する。図１１は、一実施形態による移動通信システムを示すブロック図である。図１１に示した移動通信システム１１００は、ユーザ端末（ＵＥ）１００と、無線ネットワーク制御装置（ＲＮＣ）２００と、コアネットワーク３００とを含む。
【００５４】
ユーザ端末１００は、無線ネットワーク制御装置２００からのダウンリンク方向の受信信号を受信するダウンリンク（ＤＬ）受信部１５１と、受信信号を処理するダウンリンク（ＤＬ）データ処理部１５２を有する。また、ユーザ端末１００は、受信信号に含まれるデータを利用する上位アプリケーション１７０を有する。さらに、ユーザ端末１００は、上位アプリケーション１７０が生成・処理したデータを送信するために処理するアップリンク（ＵＬ）データ処理部１６２と、処理されたデータを無線ネットワーク制御装置２００にアップリンク方向の送信信号として送信するアップリンク（ＵＬ）送信部１６３とを有する。
【００５５】
ユーザ端末１００は、システム全体の動作を制御し、データを処理する制御部１１０と、ＴＣＰタイマ（図示せず）及びＲＬＣ再送タイマ（図示せず）を含むタイマ部１３０とを有する。制御部１１０は、ＲＬＣ機能部１１１と、タイマ監視・管理部１１２と、送信済管理部１１３とを有する。これらの各部の動作は後で詳しく説明する。
【００５６】
無線ネットワーク制御装置２００は、コアネットワーク３００からのダウンリンク方向の受信信号を受信するダウンリンク（ＤＬ）受信部２５１と、受信信号を処理するダウンリンク（ＤＬ）データ処理部２５２と、処理した受信信号をユーザ端末１００に送信するダウンリンク（ＤＬ）送信部２５３とを有する。また、無線ネットワーク制御装置２００は、ユーザ端末１００から受信したアップリンク方向の受信信号を受信するアップリンク（ＵＬ）受信部２６１と、受信した受信信号を処理するアップリンク（ＵＬ）データ処理部２６２と、処理した受信信号をコアネットワーク３００に送信するアップリンク（ＵＬ）送信部２６３とを有する。
【００５７】
無線ネットワーク制御装置２００は、そのシステム全体の動作を制御し、データを処理する制御部２１０と、ＴＣＰタイマ（図示せず）及びＲＬＣ再送タイマ（図示せず）を含むタイマ部２３０とを有する。制御部２１０は、ＲＬＣ機能部２１１と、タイマ監視・管理部２１２と、送信済管理部２１３とを有する。これらの各部の動作は以下に詳しく説明する。
【００５８】
ここで、コアネットワーク３００からユーザ端末１００方向にデータを送信するダウンリンク方向の処理について説明する。
【００５９】
まず、ＵＥ１００は、ＲＮＣ２００にＴＣＰタイマの設定値を通知するため、ＲＮＣ２００とのコネクションを設定すると、ＲＮＣ２００にＴＣＰタイマの設定値を送信する。そのため、ＵＥ１００において、制御部１１０に含まれるＲＬＣ機能部１１１は、ＴＣＰレイヤを含む上位アプリケーション部１７０からＴＣＰタイマの設定値を取得して、図８及び図９を参照して説明したようにＳＴＡＴＵＳ  ＰＤＵとしてＵＬ送信部１６３を介してＲＮＣ２００に送信する。
【００６０】
ＲＮＣ２００において、ＵＬ受信部２６１がこのＳＴＡＴＵＳ  ＰＤＵを受信し、ＵＬデータ処理部２６２がＴＣＰタイマ設定値を通知するＳＴＡＴＵＳ  ＰＤＵであると判断し、そのＴＣＰタイマ設定値を制御部２１０に含まれるＲＬＣ機能部２１１に通知する。制御部２１０に含まれるタイマ監視・管理部２１２は、ＲＬＣ機能部２１１からこのタイマ設定値を受け取り、タイマ部２３０にあるＴＣＰタイマ（図示せず）に設定する。
【００６１】
その後、ＲＮＣ２００は、コアネットワーク３００からデータを受信すると、ＵＥ１００へ送信するために無線プロトコルに変換してＵＥ１００に送信する。このとき送信されたＰＤＵは制御部２１０に含まれる送信済管理部２１３に格納され、ＲＬＣ機能部２１１は、このタイミングで制御部２１０に含まれるタイマ管理部２１２に、タイマ部２３０に含まれるＲＬＣタイマ（図示せず）とＴＣＰタイマ（図示せず）をスタートさせる。
【００６２】
タイマ部２３０に含まれるＲＬＣタイマが満了すると、制御部２１０に含まれるタイマ監視・管理部２１２は、ＲＬＣ機能部２１１に満了通知を送り、ＲＬＣ機能部２１１は送信済管理部２１３に、格納されたＰＤＵの再送要求を出して、再送させる。またタイマ部２３０のＴＣＰタイマがある一定閾値以上経過した場合は、同様にタイマ監視・管理部２３０がタイマ管理部２３０のＲＬＣ再送タイマを短縮値に設定する。
【００６３】
ＵＥ１００は、データを受信した時は、ＤＬデータ処理部１５２でデータを受信したことを制御部１１０のＲＬＣ機能部１１１に通知する。ＲＬＣ機能部１１１は、ＵＬ送信部１６３を介して送達確認信号（ＳＴＡＴＵＳ−ＡＣＫ）をＲＮＣ２００に送信する。
【００６４】
ユーザ端末１００から無線ネットワーク制御装置２００を介してコアネットワーク３００にデータを送信するアップリンク方向の処理についても同様であるが、ユーザ端末１００は上位アプリケーション１７０がＴＣＰタイマの設定値を知っているので、その設定値をＲＬＣのＰＤＵで通知する必要はなく、例えば、制御部１１０に含まれるＲＬＣ機能部１１１がその設定値を上位アプリケーションから取得して、タイマ監視・管理部１１２を介してタイマ部１３０に設定すればよい。
【００６５】
上記の通り、無線ネットワーク制御装置からユーザ端末にデータを送信するダウンリンク通信を主に説明したが、上記の実施形態は、ユーザ端末から無線ネットワーク制御装置にデータを送信するアップリンク通信にも適用できることは当業者には明らかである。
【００６６】
以上、実施形態について詳述したが、特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形及び変更が可能である。
【００６７】
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
第１のプロトコルに基づくデータを、前記第１のプロトコルより下位の第２のプロトコルに基づく送信信号として相手装置に送信し、前記相手装置から前記送信信号に対する送達確認を受信しないとき、前記送信信号を再送する制御部と、
前記第１のプロトコルに基づくデータの送信レートを低下させるまでの時間を測る第１のタイマと、
前記第２のプロトコルに基づく送信信号を再送するまでの時間を測る第２のタイマとを有し、
前記制御部は、前記第１のタイマの経過時間に応じて、前記第２のタイマの設定時間を変更することを特徴とする通信装置。
（付記２）
前記制御部は、前記第２のプロトコルの制御信号を用いて、前記第１のタイマの設定値に関する情報を前記相手装置から受信する、付記１に記載の通信装置。
（付記３）
前記制御部は、前記第２のプロトコルの制御信号を用いて、前記第１のタイマの設定値に関する情報を前記相手装置に送信する、付記１に記載の通信装置。
（付記４）
前記第１のプロトコルは伝送制御プロトコル（ＴＣＰ）である、付記１に記載の通信装置。
（付記５）
前記第２のプロトコルは無線リンク制御プロトコル（ＲＬＣ）である、付記１に記載の通信装置。
（付記６）
前記制御部は、前記第１のタイマの経過時間に応じて、前記第２のタイマの設定時間を段階的に変更する、付記１に記載の通信装置。
（付記７）
第１のプロトコルに基づくデータを、前記第１のプロトコルより下位の第２のプロトコルに基づく送信信号として相手装置に送信する段階と、
前記相手装置から前記送信信号に対する送達確認を受信しないとき、前記送信信号を再送する段階とを含み、
前記第１のプロトコルに基づくデータの送信レートを低下させるまでの時間の経過に応じて、前記送信信号を再送するまでの時間を変更することを特徴とする送信方法。
【図面の簡単な説明】
【００６８】
【図１】移動通信システムにおいて使用されるプロトコルスタック例を示す図である。
【図２】ＴＣＰにおけるスロースタートアルゴリズムを説明するための図である。
【図３Ａ】ＴＣＰにおけるデータ欠落時の対応方式であるＴＡＨＯＥ方式を示す図である。
【図３Ｂ】ＴＣＰにおけるデータ欠落時の対応方式であるＲＥＮＯ方式を示す図である。
【図４Ａ】ＲＬＣにおける信号送信方法を示す図である。
【図４Ｂ】ＲＬＣにおけるデータ欠落時の自律再送を示す図である。
【図５】従来のＲＬＣにおける通信方法を示す図である。
【図６】一実施形態によるＲＬＣにおける通信方法を示す図である。
【図７】図６の通信方法におけるＲＬＣタイマの短縮を示すグラフである。
【図８】一実施形態によるＲＮＣへのＴＣＰタイマ通知方法を示す図である。
【図９】図８のＴＣＰタイマ通知方法で利用できるＳＴＡＴＵＳ  ＰＤＵを示す図である。
【図１０】一実施形態によるＲＬＣにおける送信方法を示すフローチャートである。
【図１１】一実施形態による移動通信システムを示すブロック図である。
【符号の説明】
【００６９】
１００  ユーザ端末
１１０  制御部
１１１  ＲＬＣ機能部
１１２  タイマ監視・管理部
１１３  送信済管理部
１３０  タイマ部
１５１  ＤＬ受信部
１５２  ＤＬデータ処理部
１６２  ＵＬデータ処理部
１６３  ＵＬ送信部
１７０  上位アプリケーション
２００  無線ネットワーク制御装置
２１０  制御部
２１１  ＲＬＣ機能部
２１２  タイマ監視・管理部
２１３  送信済管理部
２３０  タイマ部
２５１  ＤＬ受信部
２５２  ＤＬデータ処理部
２５３  ＤＬ送信部
２６１  ＵＬ受信部
２６２  ＵＬデータ処理部
２６３  ＵＬ送信部
３００  コアネットワーク
【図１】
2010093628.tif 000003
【図２】
2010093628.tif 000004
【図３Ａ】
2010093628.tif 000005
【図３Ｂ】
2010093628.tif 000006
【図４Ａ】
2010093628.tif 000007
【図４Ｂ】
2010093628.tif 000008
【図５】
2010093628.tif 000009
【図６】
2010093628.tif 000010
【図７】
2010093628.tif 000011
【図８】
2010093628.tif 000012
【図９】
2010093628.tif 000013
【図１０】
2010093628.tif 000014
【図１１】
2010093628.tif 000015