通信システムにおけるリソース割当方法及びリソース割当システム並びにそれに用いる基地局
【課題】効果的に送信遅延を抑制することができる通信システムにおけるリソース割当方法を提供する。
【解決手段】端末１１０と、基地局１００とを含み、端末１１０にデータが発生し、基地局１００は端末１１０にリソースを割当て、端末１１０はリソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、基地局１００は、データの受信状況を監視する受信トラヒック監視部で監視し、データが規則的に発生すると判定した場合、周期的にリソースを割当てるリソース管理部１０２を備える。
【解決手段】端末１１０と、基地局１００とを含み、端末１１０にデータが発生し、基地局１００は端末１１０にリソースを割当て、端末１１０はリソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、基地局１００は、データの受信状況を監視する受信トラヒック監視部で監視し、データが規則的に発生すると判定した場合、周期的にリソースを割当てるリソース管理部１０２を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信システムにおけるリソース割当方法及びリソース割当システム並びにそれに用いる基地局に関し、特に規則的にトラヒックが発生する通信システムにおけるリソース割当方式に関するものである。
【背景技術】
【０００２】
３ＧＰＰ（3rd Generation Partnership Project）において標準化が進められているＬＴＥ（Long Term Evolution ）の上り回線では、スケジューリング方法として、いわゆるDynamic （動的）スケジューリングとPersistent（固定的）スケジューリングとの両スケジューリング方式が検討されている（非特許文献１参照）。
【０００３】
前者のDynamic スケジューリングは、１ＴＴＩ（Transmission Time Interval）毎に、通信端末（以下、単に端末と称す）にリソースを割当てるスケジューリングである。ここに、リソースとは、ＲＢ（Resource Block）と、ＭＣＳ（Modulation and Coding Schemes ）を指し、ＲＢとは、１ＴＴに割当てることができる周波数リソースの最小単位である。ＬＴＥの上り回線では、１つの端末に周波数軸上で連続した複数のＲＢを割り当てることが可能である。ＭＣＳとは、変調方式と誤り訂正の符号化率のセットである。割当てるＲＢ数とＭＣＳとの組み合わせによって送信ビット数が決定される。
【０００４】
このDynamic スケジューリングによれば、チャネル品質に応じたリソース割当てができるので、高スループットが期待できるが、シグナリング情報が多いために、１ＴＴＩでの同時送信端末数が制限される。従って、規則的にトラヒックが発生する場合、例えば、ＶｏＩＰ（Voice over IP ）トラヒックのように、１パケットのサイズが小さく、所定の周期でトラヒックが発生する場合、割当て可能なＲＢ数に余裕があるにも関わらず、同時送信端末数の制限のために収容端末（ユーザ）数を増やせないという問題がある。
【０００５】
かかる問題点を解決するために、後者のPersistentスケジューリングが検討されている。このPersistentスケジューリングは、所定の周期で使用できるリソースを割当てるスケジューリングであり、１度リソースを割当てれば、シグナリング情報を送信しないで済むという利点がある。チャネル品質に応じた動的なリソース割当てはできないが、シグナリング情報が削減できるので、１ＴＴＩの同時送信端末（ユーザ）数を増やすことができる。
【０００６】
また、Persistentスケジューリングの１つとして、バンドリング（Bundling）が検討されている。このバンドリングは、複数のパケットをまとめて１ＴＴＩで送信する方法であり、オーバヘッドの削減が期待されている（非特許文献２参照）。
【０００７】
なお、関連する技術として、特許文献１や２などがある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００３−１６３６６７号公報
【特許文献２】特開２００７−１０４７０５号公報
【非特許文献】
【０００９】
【非特許文献１】3GPP TS36.300 V8.1.0 (2007-06), 3GPP Evolved Universal Terre strial Radio Access and Evolved Universal Terrestrial Radio Access Network, pp.56
【非特許文献２】R2-072630, 3GPP TSG-RAN WG2 Meeting #58bis, HARQ operation in case of UL Power Limitation
【発明の概要】
【発明が解決しようとする課題】
【００１０】
規則的に発生するトラヒックを、Persistentスケジューリングで送信する場合、特にバンドリングにおいて、送信遅延が問題となる。この問題点を図２２を参照して説明する。トラヒックはＶｏＩＰトラヒックであり、音声パケットのエンコード周期を２０ｍｓとし、バンドリングであると仮定し、１ＴＴＩで２音声パケットを送信し、ＲＢの割当て周期をエンコード周期の２倍の４０ｍｓとする。また、パケット発生から５０ｍｓ以内に送信を完了できない場合には、ＱｏＳ（Quality of Service）を満足できないものとする。
【００１１】
いま、パケットＰ１，Ｐ２の送信直後の１ｍｓ後（時刻Ｔ０）に、パケットＰ３が発生すると仮定する。その２０ｍｓ後にパケットＰ４が発生し、パケットＰ３，Ｐ４は、時刻Ｔ１に最初の送信がなされるとする（本送）。チャネル品質が悪いために、時刻Ｔ１での送信に失敗した場合、
時刻Ｔ２＝Ｔ１＋ＨＡＲＱ（Hybrid Automatic Repeat request ）ＲＴＴ（Round Trip Time ）で再送がなされる（再１）。更に、時刻Ｔ２での再送に失敗した場合、
時刻Ｔ３＝Ｔ１＋２＊ＨＡＲＱ ＲＴＴ
で次の再送がなされる（再２）。
【００１２】
ここで、１ＲＴＴ＝６ｍｓとし、２回目の再送で送信に成功した場合、以下のように、パケットＰ３の送信遅延が５０ｍｓを超えてしまうことになる。
Ｄｅｌａｙ（Ｐ３）＝Ｔ３−Ｔ０＝Ｔ１−Ｔ０＋２＊ＨＡＲＱ ＲＴＴ
＝３９＋２＊６＝５１ｍｓ＞５０ｍｓ
Ｄｅｌａｙ（Ｐ４）＝Ｔ３−（Ｔ０＋２０）＝３１ｍｓ＜５０ｍｓ
【００１３】
また、基地局が、トラヒックが規則的に発生することを事前に把握できない場合や、規則的なトラヒックであることは認識できても、トラヒックの発生周期やトラヒックのサイズなどがわからない場合、Persistentスケジューリングを実施できない点が問題となる。
【００１４】
ここで、特許文献１及び２を参照すると、送信遅延を防止するために、前者では、蓄積パケット量を、後者では、キューの長さを、それぞれ監視して、この監視結果に基づいて送信遅延を抑制するようなリソース割当てを実施するというものである。これら特許文献１や２の技術では、蓄積パケット量やキューの長さ、すなわちバッファサイズに基づいて遅延を予測するものであるから、送信パケットの発生周期やそのタイミングの変化やずれに対しては、何等送信遅延を効果的に抑制するようなリソース割当てを実施することはできない。
【００１５】
本発明の目的は、効果的に送信遅延を抑制することができる通信システムにおけるリソース割当方法及びリソース割当システム並びにそれに用いる基地局を提供することである。
【課題を解決するための手段】
【００１６】
本発明による第一の方法は、端末と、基地局とを含み、前記端末に規則的にデータが発生し、基地局は前記端末にリソースを割当て、前記通信端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、前記端末は、前記データを監視する監視ステップと、前記データに所定の変化が発生したら前記基地局に報告する報告ステップとを備え、前記基地局は、前記端末からの報告に基づいてリソース割当てを決める割当てステップを備えることを特徴とする。
【００１７】
本発明による第二の方法は、端末と、基地局とを含み、前記端末に規則的にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、前記端末は、前記データの送信状況を監視する監視ステップと、前記送信状況が所定条件を満足しなければ前記基地局に報告する報告ステップとを備え、前記基地局は、前記端末からの報告に基づいてリソース割当てを決める割当てステップを備えることを特徴とする。
【００１８】
本発明による第三の方法は、端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、前記基地局は、前記データの受信状況を監視する監視ステップと、前記受信状況に基づいて前記データが規則的に発生するか判定する判定ステップと、規則的に発生すると判定した場合、前記監視結果に基づいて周期的にリソースを割当てる割当てステップとを備えることを特徴とする。
【００１９】
本発明による第四の方法は、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが規則的に到着し、前記基地局は前記端末にリソースを割当て、前基地局は前記リソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、前記基地局は、前記データの送信状況を監視する監視ステップと、前記送信状況が所定条件を満足しなければ、前記監視結果に基づいてリソース割当てを決定する割当てステップとを備えることを特徴とする。
【００２０】
本発明による第五の方法は、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが到着し、前記基地局は前記端末にリソースを割当て、前基地局は前記リソースを用いてデータを送信する通信システムにおけるリソース割り当て方法であって、前記基地局は、前記データを監視する監視ステップと、前記監視結果に基づいて前記データが規則的に到着するか判定する判定ステップと、規則的に到着すると判定した場合、前記監視結果に基づいて前記リソースを割当てる割当てステップとを備えることを特徴とする。
【００２１】
本発明による第一のシステムは、端末と、基地局とを含み、前記端末に規則的にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当てシステムであって、前記端末は、前記データを監視して前記データに所定の変化が発生したら前記基地局に報告する監視手段を備え、前記基地局は、前記報告に基づいてリソース割当てを決める割当て手段を備えることを特徴とする。
【００２２】
本発明による第二のシステムは、端末と、基地局とを含み、前記端末に規則的にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当てシステムであって、前記端末は、前記データの送信状況を監視して前記送信状況が所定条件を満足しなければ前記基地局に報告する監視手段を備え、前記基地局は、前記端末からの報告に基づいてリソース割当てを決める割当て手段を備えることを特徴とする。
【００２３】
本発明による第三のシステムは、端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当システムであって、前記基地局は、前記データの受信状況を監視する監視手段と、前記受信状況に基づいて前記データが規則的に発生するか判定する判定手段と、規則的に発生すると判定した場合、前記監視結果に基づいてリソースを割当てる割当て手段とを備えることを特徴とする。
【００２４】
本発明による第四のシステムは、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが規則的に到着し、前記基地局は前記端末にリソースを割当て、前記基地局は前記リソースを用いてデータを送信する通信システムにおけるリソース割り当てシステムであって、前記基地局は、前記データの送信状況を監視する監視手段と、前記送信状況が所定の条件を満足しなければ、前記監視結果に基づいてリソース割当てを決定する割当て手段とを備えることを特徴とする。
【００２５】
本発明による第五のシステムは、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが到着し、前記基地局は前記端末にリソースを割当て、前基地局は前記リソースを用いてデータを送信する通信システムにおけるリソース割り当てシステムであって、前記基地局は、前記データを監視する監視手段と、前記監視結果に基づいて前記データが規則的に到着するか判定する判定手段と、規則的に到着すると判定した場合、前記監視結果に基づいて前記データの発生から所定の時間内に前記データを送信できるリソースを周期的に割当てる割当て手段とを備えることを特徴とする。
【００２６】
本発明による第一の基地局は、端末と、基地局とを含み、前記端末に規則的にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおける基地局であって、前記データに所定の変化が発生した旨の前記端末からの報告に基づいて、前記リソース割当てを決める割当て手段を備えることを特徴とする。
【００２７】
本発明による第二の基地局は、端末と、基地局とを含み、前記端末に規則的にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおける基地局であって、前記データの送信状況が所定条件を満足しない旨の、前記端末からの報告に基づいてリソース割当てを決める割当て手段を備えることを特徴とする。
【００２８】
本発明による第三の基地局は、端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおける基地局であって、前記データの受信状況を監視する監視手段と、前記受信状況に基づいて前記データが規則的に発生するか判定する判定手段と、規則的に発生すると判定した場合、前記監視結果に基づいてリソースを割当てる割当て手段とを備えることを特徴とする。
【００２９】
本発明による第四の基地局は、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが規則的に到着し、前記基地局は前記端末にリソースを割当て、前基地局は前記リソースを用いてデータを送信する通信システムにおける基地局であって、前記データの送信状況を監視する監視手段と、前記送信状況が所定の条件を満足しなければ、前記監視結果に基づいてリソース割当てを決定する割当て手段とを備えることを特徴とする。
【００３０】
本発明による第五の基地局は、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが到着し、前記基地局は前記端末にリソースを割当て、前基地局は前記リソースを用いてデータを送信する通信システムにおける基地局であって、前記データを監視する監視手段と、前記監視結果に基づいて前記データが規則的に到着するか判定する判定手段と、規則的に到着すると判定した場合、前記監視結果に基づいて前記データの発生から所定の時間内に前記データを送信できるリソースを周期的に割当てる割当て手段とを備えることを特徴とする。
【発明の効果】
【００３１】
本発明による第１の効果は、規則的に発生するトラヒックに対し、送信遅延を抑制したPersistentスケジューリングを実施できることである。その第１の理由は、トラヒックを監視して、トラヒックに所定の変化が生じれば、基地局に報告し、基地局は、報告に基づいて、報告に基づいて送信遅延が小さくなるタイミングの周期的なリソースを割当てるからである。また、その第２の理由は、トラヒックの送信状況を監視して、送信状況が所定の条件を満足しなければ、基地局に報告し、基地局は、報告に基づいて、報告に基づいて送信遅延が小さくなるタイミングの周期的なリソースを割当てるからである。
【００３２】
また、本発明による第２の効果は、基地局が事前に規則的なトラヒックであることを把握できなくても、送信遅延を抑制したPersistentスケジューリングを実施できることである。その理由は、基地局が、トラヒックの受信状況を監視し、規則的なトラヒックか否かの判定を行ない、規則的なトラヒックであれば、送信遅延が小さくなるタイミングの周期的なリソースを割当てるからである。
【図面の簡単な説明】
【００３３】
【図１】第一の実施の形態の通信システムの構成を示すブロック図である。
【図２】第一の実施の形態の端末の動作手順を示すフローチャート図である。
【図３】第一の実施の形態の基地局の動作手順を示すフローチャート図である。
【図４】発生するトラヒックのイメージ図である。
【図５】トラヒックの発生状態の変更のイメージ図である。
【図６】ＲＢの割当て状態の管理イメージ図である。
【図７】パケットの発生タイミングとＲＢの割当て状態のイメージ図である。
【図８】第一の実施の形態のデータ送信タイミング図である。
【図９】第二の実施の形態の通信システムの構成を示すブロック図である。
【図１０】第三の実施の形態の通信システムの構成を示すブロック図である。
【図１１】第三の実施の形態の端末の動作手順を示すフローチャート図である。
【図１２】第三の実施の形態の基地局の動作手順を示すフローチャート図である。
【図１３】第三の実施の形態の割当リソースの計算方法の動作手順を示すフローチャート図である。
【図１４】第四の実施の形態の通信システムの構成を示すブロック図である。
【図１５】第四の実施の形態の端末の動作手順を示すフローチャート図である。
【図１６】第四の実施の形態の基地局の動作手順を示すフローチャート図である。
【図１７】第四の実施の形態のデータ受信タイミング図である。
【図１８】第四の実施の形態のデータ送信タイミング図である。
【図１９】第一と第四の実施の形態を組み合わせた場合のシグナリングフローイメージ図である。
【図２０】第五の実施の形態の通信システムの構成を示すブロック図である。
【図２１】第六の実施の形態の通信システムの構成を示すブロック図である。
【図２２】既存の技術におけるデータ送信タイミング図である。
【発明を実施するための形態】
【００３４】
以下に、図面を参照しつつ本発明の実施の形態について詳細に説明する。
＜第一の実施の形態＞
図１は、本発明が適用される通信システムの基本構成の例を示す図である。本実施の形態では、通信システムとして、ＬＴＥの上り回線を例にとって説明する。図１を参照すると、本通信システムは、基地局１００と端末１１０とから構成される。基地局１００は、端末１１０と無線チャネルによって接続される。基地局１００は図示せぬネットワークと接続されている。また、図示していないが、基地局１００は複数の端末と接続することができる。また、基地局も複数存在することができる。
【００３５】
図１を参照すると、基地局１００は、基地局動作部１０１と、リソース管理部１０２とを含んでいる。また、端末１１０は、端末動作部１１１と、トラヒック発生部１１２と、発生トラヒック監視部１１３を含んでいる。基地局動作部１０１は、ＬＴＥシステムにおいて一般的に用いられる基地局と同等の機能を有しており、その構成及び動作については周知であるので、その説明を省略する。本実施の形態においては、一般的な機能ではあるが、端末１１０から送信されるトラヒックを受信する機能を有する。リソース管理部１０２は、ＲＢの割当状態を管理し、端末に割当てるリソースを決定する機能を有する。
【００３６】
端末動作部１１１は、ＬＴＥシステムにおいて一般的に用いられる端末と同等の機能を有しており、その構成及び動作については周知であるので、その説明を省略する。本実施の形態においては、一般的な機能ではあるが、割当てられたリソースで、トラヒックを送信する機能を有する。トラヒック発生部１１２は、トラヒック発生の開始と終了を端末動作部１１１に通知する機能と、トラヒックを発生する機能とを有する。発生トラヒック監視部１１３は、トラヒックを監視し、監視結果を基地局１００に報告する機能を有する。
【００３７】
次に、本実施の形態の動作について図面を参照して説明する。図２及び図３は、規則的なトラヒックが発生する端末１１０に対して、基地局１００がPersistentスケジューリングでリソース割当てを行なう動作手順を示すもであり、端末１１０及び基地局１００の各フローチャートである。
【００３８】
図２を参照して、端末１１０の実際の動作手順を説明する。端末動作部１１１は、トラヒック発生時、基地局１００にトラヒック情報を送信する（Ｓ１０１）。トラヒック情報とは、パケットの発生周期、発生タイミング、発生サイズの各パラメータを指す。パケットとは、トラヒックの到着単位である。図４に、トラヒック情報のイメージ図を示す。発生周期をｔ_gp 、発生タイミングをｔ_gt 、発生サイズをＳ（Size）として、各パラメータは変動しないと仮定している。
【００３９】
ｔ_gt は現在時刻を発生周期ｔ_gp で割った余りで表され、以下の式で定義される。
ｔ_gt ＝ＭＯＤ（Ｔgn ，ｔ_gp ）
ここで、Ｔgnは、パケットＰn が端末の送信バッファに到着した時刻を表す。発生タイミングを考慮せず、Ｔgn+1の直前のＲＢを割当てると、遅延が増大してＱｏＳを満足できない問題が発生し易くなる。但し、端末１１０と基地局１００間で既知のトラヒック情報のパラメータは送信する必要はない。例えば、端末１１０と基地局１００間で、発生周期と発生サイズとは、事前に既知の情報であれば、発生タイミングのみを送信すればよい。
【００４０】
次に、基地局１００より、割当リソース情報を受信できれば（Ｓ１０２、Ｙｅｓ）、端末動作部１１１は、割当リソース情報を記憶し（Ｓ１０３）、周期的に割当てられたリソースでのトラヒックの送信を開始する。割当リソース情報を受信できなければ（Ｓ１０２、Ｎｏ）、リソースが割当てられなかったので、処理を終了する。
【００４１】
次に、発生トラヒック監視部１１３は、トラヒックを監視し（Ｓ１０４）、トラヒックに所定の変化があれば（Ｓ１０５、Ｙｅｓ）、基地局１００にトラヒック情報を送信する（Ｓ１０６）。送信するのは、変化があったパラメータだけでよい。図５に、トラヒックの発生状態の変化のイメージ図を示す。ａ）は初期状態である。ｂ）は発生タイミングの変化例である。ｃ）は発生周期の変化例である。ｄ）は発生サイズの変化例である。
【００４２】
例えば、図５のパラメータを用いれば、以下のいずれかの条件を満足できない場合、所定の変化が発生したと判定する。
｜ｔ_gt k+1 −ｔ_gt k ｜＜Ｔｈ_tgt
｜ｔ_gp k+1 −ｔ_gp k ｜＜Ｔｈ_tgp
｜Ｓk+1 −Ｓk ｜＜Ｔｈ_S
ここに、Ｔｈ_tgt，Ｔｈ_tgp，Ｔｈ_Sは、それぞれしきい値を表す。
【００４３】
次に、基地局１００より、トラヒックの変化による割当リソースの更新情報を受信した場合（Ｓ１０７、Ｙｅｓ）、端末動作部１１１は、割当リソース情報を更新する（Ｓ１０８）。割当リソース情報を受信しなければ（Ｓ１０７、Ｎｏ）、引き続き、割当て済みのリソースでデータを送信する。次に、端末動作部１１１は、トラヒック終了時（Ｓ１０９）、基地局１００にトラヒック終了報告を送信し（Ｓ１１０）、処理を終了する。
【００４４】
次に、図３を参照して、基地局１００の実際の動作手順を説明する。リソース管理部１０２は、端末１１０から、トラヒック情報を受信した場合（Ｓ１２１、Ｙｅｓ）、割当リソースを計算し（Ｓ１２２）、ＲＢの割当状態から、割当リソースを更新できる場合（Ｓ１２３、Ｙｅｓ）、割当リソース情報を端末１１０に送信する（Ｓ１２４）。割当リソースの計算方法は後述する。
【００４５】
図６に、ＲＢの割当状態の管理イメージを示す。縦軸はＲＢ番号（RB Index）、横軸はＴＴＩ番号（TTI Index）であり、１ＴＴＩ当たり最大７個のＲＢを、２０ＴＴＩの周期で繰り返し使用できるＲＢの管理テーブルを示している。３個のＲＢを割当てる場合、割当可能なTTI Index ＝５、RB Index＝３〜５を選択する例を示している。なお、網かけ部分は割当て済みのＲＢを示し、白い部分は未割当のＲＢを示し、太線内の３個のＲＢが割当てるＲＢを示す。
【００４６】
次に、リソース管理部１０２は、端末１１０から、トラヒック終了報告を受信した場合（Ｓ１２５、Ｙｅｓ）、端末のリソースの解放処理を行い、処理を終了する（Ｓ１２６）。次に、割当リソース、即ち、ＭＣＳとＲＢとの計算方法を説明する。本実施の形態では、ＭＣＳは予め決められた唯一の固定値を選択する。また、１ＲＢ当たりの送信データサイズをＴＤＵ（Transmission Data Unit）と定義する。ＴＤＵはＭＣＳよって一意に決まり、例えば、３個のＲＢを割当てる場合、送信データサイズは３＊ＴＤＵとなるとする。また、１ＴＴＩで送信するパケット数をＮ_tp とし、固定値とする。
【００４７】
ＲＢに関するパラメータとしては、割当ＲＢ数（Ｎ_RBs）と、割当周期（ｔ_ap ）と、TTI Index （tti_idx ）とを計算する。また、tti_idx ＝０に該当する時刻（Ｔbase[TTI] ）を基地局１００と端末１１０とにより共有し、かつ現在時刻も共有する。Ｔbaseは以下を満足する。
【００４８】
ＭＯＤ（Ｔbase，Ｔap）＝０
現在時刻の共有は、ＧＰＳ（Global Positioning System)を用いる方法や、所定のタイミングで、基地局１００が端末１１０に、現在時刻を通知する方法などが考えられる。また、Ｔbaseの共有は、所定のタイミングや、割当リソース情報を送信するに、基地局１００が端末１１０に通知する方法などが考えられる。
【００４９】
Ｎ_RBsは以下となる。
Ｎ_RBs＝ＣＥＩＬ（（Ｎ_tp ＊Ｓ）／ＴＤＵ）
ここに、ＣＥＩＬは、少数点以下を切り上げる整数を返す関数を表す。例えば、ＣＥＩＬ（１．５）＝２となる。ｔ_ap は、以下となる。
ｔ_ap ＝Ｎ_tp ＊ｔ_gp
tti_idx は、送信遅延を少なくするため、送信バッファへのパケット到着からｔ_gp ／２以内のタイミングで送信するよう、以下を満足する中で、ＲＢの割当状態を考慮して決定する。
ＭＯＤ（tti_idx ＋ｔ_gp −ｔ_gt ，ｔ_gp ）≦ｔ_gp ／２
【００５０】
また、再送データのリソース割当て方法をPersistentスケジューリングと、Dynamic スケジューリングのどちらにするかは、任意に選択できるものとする。例えば、チャネル品質が悪く、再送回数の期待値が大きい場合、Persistentスケジューリングで、再送分のリソースを確保しておくことが考えられる。
【００５１】
また、本実施の形態では、ＭＣＳは唯一のものを選択したが、パイロット信号や制御信号やトラヒックの受信時に、端末１１０のチャネル品質を測定しておき、チャネル品質に応じてＭＣＳを選択することも可能である。また、本実施の形態では、トラヒックの発生周期、発生タイミング、発生サイズを、固定的としたが、変動してもよい。その場合、以下のような測定を行い、発生トラヒックの状況を監視する。例えば、発生周期ｔ_gp については、ある所定の時間内の平均値（ｔ_gp_ave t ）を測定する。次に、前回の平均値（ｔ_gp_ave t-1 ）と比較し、以下の条件式を満足できなければ、所定の変化が発生したと判定するなどである。
｜ｔ_gp_ave t −t_gp_avet-1 ｜＞Ｔｈ_tgp
発生タイミングｔ_gt 、発生サイズＳも同様である。
【００５２】
次に、割当リソースの計算に関する具体例について説明する。ＴＴＩはｍｓ単位とし、トラヒック情報のうち、発生周期ｔ_gp ＝２０ｍｓ、発生サイズＳ＝３２０ビットは不変で、基地局１００、端末１１０間で既知とする。また、端末１１０から、発生タイミングｔ_gt ＝５ｍｓが、基地局１００に送信されたと仮定する。また、リソース管理部１０２のパラメータは以下を仮定する。
ＴＤＵ＝１７０ビット、Ｎ_tp ＝２
【００５３】
先ず、割当ＲＢ数Ｎ_RBsは以下となる。
Ｎ_RBs＝ＣＥＩＬ（（Ｎ_tp ＊Ｓ）／ＴＤＵ）＝ＣＥＩＬ（２＊３２０／１７０）＝４
次に、割当周期ｔ_ap は以下となる。
ｔ_ap ＝Ｎ_tp ＊ｔ_gp ＝２＊２０＝４０ｍｓ
次に、パケットの発生タイミングとＲＢの割当状態を図７とすると、tti_idx は、選択可能な直近のＴＴＩの２５を選択する。上記より、端末１１０は、４０ｍｓに１回、４ＲＢを使ってトラヒックの本送を行なうことができる。
【００５４】
本実施の形態を適用した場合の、図２２の既存の例に対する効果を図８に示す。パケットが発生してから本送するまでのＴ1 −Ｔ0 の期待値が、従来例の３０ｍｓ（＝（２０＋３９）／２）から２５ｍｓ（＝（２０＋３０）／２）に改善されることになる。
【００５５】
＜第二の実施の形態＞
次に、本発明の第二の実施の形態について説明する。図９は本実施の形態による通信システムの基本構成の例を示す図であり、図１と同等部分は同一符号により示している。図９の構成を図１の例と比較すると、端末１１０のトラヒック発生部１１２が削除され、代わりに、端末１１０の外部にトラヒック発生装置１２０が追加された点が異なる。
【００５６】
トラヒック発生装置１２０は、図１のトラヒック発生部１１２と同等の機能を有する。また、端末１１０とトラヒック発生装置１２０とは、無線リンクで接続されている。例えば、トラヒック発生装置１２０をパソコン（パーソナルコンピュータ）とし、端末１１０を無線モデムとして、両者はBluetooth （登録商標）等の無線リンクで接続されており、パソコンでインターネット電話をする場合が、本実施の形態に該当することになる。
【００５７】
本実施の形態の動作は、図２及び図３に示された第一の実施の形態のそれと同じである。なお、Persistentスケジューリングのリソース割当ての更新契機としては、端末１１０とトラヒック発生装置１２０間の無線リンクが不安定で、トラヒック発生装置１２０から端末１１０に到着するパケットのタイミングがずれた場合など、が考えられる。
【００５８】
＜第三の実施の形態＞
次に、本発明の第三の実施の形態について説明する。図１０は本実施の形態による通信システムの基本構成の例を示す図である。図１と同等部分は同一符号により示している。図１０の構成を図１の例と比較すると、端末１１０において、発生トラヒック監視部１１３が削除され、代わりに送信トラヒック監視部１１４が追加された点が異なる。
【００５９】
送信トラヒック監視部１１４は、トラヒックの送信状況を監視し、監視結果を基地局１００に報告する機能を有する。また、リソース管理部１０２は、第一の実施の形態の機能に加えて、トラヒックの受信状況から、リソースの使用状態を監視する機能を、更に有する。
【００６０】
次に、本実施の形態の動作について図面を参照して説明する。図１１及び図１２は、規則的なトラヒックが発生する端末１１０に対して、基地局１００がPersistentスケジューリングでリソース割当てを行なう動作手順を示すフローチャートであり、図１１が端末１１０、図１２が基地局１００の、各フローチャートである。
【００６１】
図１１を参照して、端末１１０の実際の動作手順を説明する。端末動作部１１１は、トラヒック発生時、基地局１００にリソース割当要求を送信し（Ｓ１４１）、基地局１００より、割当リソース情報を受信できれば（Ｓ１４２、Ｙｅｓ）、端末動作部１１１は、割当リソース情報を記憶し（Ｓ１４３）、割当てられたリソースでのトラヒックの送信を開始する。割当リソース情報を受信できなければ（Ｓ１４２、Ｎｏ）、リソースが割当てられなかったので、処理終了となる。
【００６２】
次に、送信トラヒック監視部１１４は、トラヒックの送信状況を監視する（Ｓ１４４）。トラヒックの送信状況として、送信バッファにあるパケット数（Ｎ_buff ）と、パケットｉの送信遅延（ｄｅｌａｙi ）の各パラメータを監視する。ｄｅｌａｙi の測定には、上位レイヤの確認応答を用いることが考えられる。
【００６３】
次に、送信バッファにあるパケット数Ｎ_Buff と新規に測定したｄｅｌａｙi を各しきい値（Ｔｈ_N_buff ，Ｔｈ_delay）と比較し、以下の条件式（１），（２）を１つでも満足しない場合、トラヒックの送信状況に問題ありと判定し（Ｓ１４５）、基地局１００に、トラヒックの送信情報として、条件式を満足できなかったパラメータを送信する（Ｓ１４６）。
Ｎ_buff ＜Ｔｈ_N_buff ……（１）
ｄｅｌａｙi ＜Ｔｈ_delay……（２）
【００６４】
例えば、式（１）を満足できないのは、割当リソース不足が原因と考えることができる。また、式（２）を満足できないのは、割当リソース不足と、不適切な送信タイミングの少なくとも１つが原因と考えることができる。次に、基地局１００より、割当リソースの更新情報を受信した場合（Ｓ１４７、Ｙｅｓ）、端末動作部１１１は、割当リソース情報を更新する（Ｓ１４８）。割当リソース情報を受信できなければ（Ｓ１４７、Ｎｏ）、引き続き、割当済みのリソースでデータを送信する。次に、端末動作部１１１は、トラヒック終了時（Ｓ１４９）、基地局１００にトラヒック終了報告を送信し（Ｓ１５０）、処理を終了する。
【００６５】
図１２を参照して、基地局１００の実際の動作手順を説明する。リソース管理部１０２は、端末１１０からリソース割当要求を受信した場合（Ｓ１６１、Ｙｅｓ）、初期設定で決められた割当リソースを計算し（Ｓ１６２）、ＲＢの割当状態から、割当て可能なリソースがある場合（Ｓ１６３、Ｙｅｓ）、端末１１０にリソースを割当て、割当リソース情報を端末１１０に送信する（Ｓ１６４）。
【００６６】
次に、端末１１０から、トラヒックの送信情報を受信した場合（Ｓ１６５、Ｙｅｓ）、割当リソースを計算し、ＲＢの割当状態から割当リソースを更新できる場合（Ｓ１６６、Ｙｅｓ）、割当リソース情報を端末１１０に送信する（Ｓ１６７）。
【００６７】
図１３を参照して、図１２のステップＳ１６６の割当リソースの計算方法を詳細に説明する。ＭＣＳは、第一の実施の形態と同様に、予め決められた唯一の固定値を選択する。また、１ＴＴＩで送信するパケット数Ｎ_tp も固定値とする。ＲＢに関するパラメータの種類は、第一の実施の形態と同じく、割当ＲＢ数Ｎ_RBsと、割当周期ｔ_ap と、tti_idxとする。このうち、トラヒックの送信情報を受信しても、割当周期ｔ_ap は更新しないとする。
【００６８】
先ず、トラヒックの送信情報として、送信バッファにあるパケット数Ｎ_Buff を受信した場合（Ｓ１８１、Ｙｅｓ）、リソース不足が原因と判定し、以下の式に従って、更新する場合のＮ_RBsを計算し、リソース管理部１０２は、ＲＢの割当状態から、図９の第一の実施の形態と同様に、割当可能なtti_idx を検索する（Ｓ１８２）。
Ｎ_RBs＝Ｎ_RBs＋１
【００６９】
tti_idx は、送信タイミングよって、送信遅延が増加しないよう、割当済みのtti_idxから、降順に検索するのが望ましい。例えば、割当済みのtti_idx を５とし、割当周期を２０ＴＴＩとすると、以下の順に検索することになる。
tti_idx 候補→５，４…１，２０，１９…７，６
【００７０】
また、トラヒックの送信情報として、送信バッファにあるパケット数Ｎ_Buff を受信しなかった場合（Ｓ１８１、Ｎｏ）、送信遅延だけを受信しているので、不適切な送信タイミングが原因と判定し、送信遅延が増加しないよう、割当済みのtti_idx 以外から、降順に検索する（Ｓ１８３）。例えば、割当済みのtti_idx を１とし、割当周期を２０ＴＴＩとすると、以下の順に検索することになる。
tti_idx 候補→２０，１９…３，２
【００７１】
Ｓ１８２，Ｓ１８３による検索の結果、割当可能なＲＢがあれば（Ｓ１８４、Ｙｅｓ）、割当リソース情報を端末１１０に送信する（Ｓ１６７）。
【００７２】
次に、リソース管理部１０２は、リソースの使用状態を監視し（Ｓ１６８）、リソース使用率が所定のしきい値よりも小さければ、割当リソースが過剰である判定し（Ｓ１６９、Ｙｅｓ）、割当リソースを削減し（Ｓ１７０）、割当リソース情報を端末１１０に送信する（Ｓ１７１）。リソース使用率の判定は、以下の条件式を用いる。
Σ｛ＴＤ／（Ｎ_RBs＊ＴＤＵ）｝＜Ｔｈ_band
【００７３】
ここに、ＴＤはあるＴＴＩで実際に送信されたトラヒックサイズを表し、Ｎ_RBs＊ＴＤＵは割当ＲＢで送信可能なトラヒックサイズを表す。従って、ＴＤ／（Ｎ_RBs＊ＴＤＵ）は、割当られた帯域の使用率を表す。Σは、ＲＢの割当タイミング（tti_idx ）で測定した結果の合計を取ることを示す。Ｔｈ_band は、リソース使用率しきい値である。
【００７４】
割当リソースを削減する場合、以下のように、Ｎ_RBsを更新する。
Ｎ_RBs＝ＭＡＸ（Ｎ_RBs−１，１）
次に、リソース管理部１０２は、端末１１０から、トラヒック終了報告を受信した場合（Ｓ１７２、Ｙｅｓ）、端末のリソースの解放処理を行い、処理を終了する（Ｓ１７３）。
【００７５】
なお、本実施の形態では、Ｎ_RBsを１ずつ増減する例を示したが、送信バッファにあるパケット数Ｎ_Buff と、しきい値Ｔｈ_N_buff とを比較して、２以上増加させることも可能である。また、本実施の形態では、トラヒックの送信状態として、送信バッファにあるパケット数と送信遅延とを用いたが、例えば、パケット数はデータサイズに、送信遅延はスループットに、それぞれ置換えることも可能である。
【００７６】
＜第四の実施の形態＞
次に、本発明の第四の実施の形態について説明する。図１４は、本発明の第四の実施の形態による通信システムの基本構成の例を示す図であり、図１と同等部分は同一符号により示す。図１４の構成において、図１のそれと比較すると、端末１１０から発生トラヒック監視部１１３が削除され、代わりに基地局１００に受信トラヒック監視部１０３が追加された点が異なる。
【００７７】
受信トラヒック監視部１０３は、トラヒックの受信状況を監視し、リソース管理部１０２と監視結果を共有する機能を有する。また、基地局動作部１０１は、第一の実施の形態の機能に加えて、端末１１０のチャネル品質を測定する機能を、更に有する。チャネル品質は、パイロット信号や制御信号やトラヒックの受信時に測定されるものとする。
【００７８】
次に、本実施の形態の動作について図面を参照して説明する。図１５及び図１６は、トラヒックが発生した端末１１０に対して、基地局１００は受信状況から規則的なトラヒックか判定し、規則的なトラヒックであれば、Persistentスケジューリングでリソース割当てを行なう動作手順を示すフローチャートであり、端末１１０及び基地局１００の各フローチャートである。
【００７９】
図１６の基地局１００のフローチャートは、主に、大きく２つ部分から構成されている。第１の部分は、Learning Period （Dynamic スケジューリング）と記載した部分である。この部分は、トラヒックを解析し、規則的に発生するトラヒックか否かを判定する処理を行なうものである。また、第２の部分は、Learning based Persistent スケジューリングと記載した部分であり、判定の結果、ＶｏＩＰなど、規則的なトラヒックであれば、解析結果に基づいて周期的なリソースを割当てる処理を行なうものである。
【００８０】
一方、ＦＴＰ（File Transfer Protocol）ファイル転送など、バースト的に発生する非規則的なトラヒックであれば、Dynamic スケジューリングの適用を継続する。図１５の端末１１０のフローチャートの構成も、Learning Period と、Learning based Persistentスケジューリングに対応している。
【００８１】
図１５を参照して、端末１１０の実際の動作手順を説明する。端末動作部１１１は、送信するトラヒックがある場合（Ｓ２０１）、基地局１００にリソース要求を送信する（Ｓ２０２）。次に、基地局１００から瞬時的な割当リソース情報を受信した場合（Ｓ２０３、Ｙｅｓ）、端末動作部１１１は割当リソース情報を記憶し、指定された送信タイミングでトラヒックを送信する（Ｓ２０４）。
【００８２】
一方、基地局１００から周期的な割当リソース情報を受信した場合（Ｓ２０５、Ｙｅｓ）、端末動作部１１１は、割当リソース情報を記憶し、周期的なトラヒック送信が開始できることになる（Ｓ２０６）。次に、周期的な割当リソースの解放通知を受信した場合（Ｓ２０７）、端末１１０は、基地局１００に受信に対する確認応答を送信し、Persistentスケジューリングでのトラヒックの送信を終了する（Ｓ２０８）。発生するのが非規則的なトラヒックであれば、Ｓ２０１〜Ｓ２０５の処理を繰り返し、Dynamic スケジューリングが継続される。
【００８３】
図１６を参照して、基地局１００の実際の動作手順を説明する。リソース管理部１０２は、端末１１０からリソース要求を受信した場合（Ｓ２２１、Ｙｅｓ）、トラヒックが規則的か否か判定済みでなければ（Ｓ２２２、Ｎｏ）、判定を実施する期間であるLearningPeriod を開始する（Ｓ２２３）。次に、測定したチャネル品質から、ＭＣＳと割当ＲＢとを計算し、瞬時的な割当リソース情報を端末１１０に送信する（Ｓ２２４）。
【００８４】
次に、受信トラヒック監視部１０３は、端末１１０からのトラヒックの受信状況を監視する（Ｓ２２５）。トラヒックの受信状況として、受信したパケット数（ＮumPacket）、受信したパケットｉのサイズ（Ｓrxi ）、パケットｉの一部を最初に受信した時刻と、次のパケットｉ＋１の一部を最初に受信した時刻の間隔（ｔ_periodk ）を監視する。ｔ_periodk は、ＮumPacket−１個測定できる。次に、所定のLearning period が経過したら（Ｓ２２６）、トラヒックを解析し、規則的か否か判定する（Ｓ２２７）。判定は以下のように行なう。
【００８５】
先ず、パケットの発生間隔の平均値（ｔperiod_ave）、偏差（ｔperiod_dev）を以下の式から推定する。
Ｔperiod_ave＝Σ（ｔ_periok k ）／（ＮumPacket−１）
Ｔperiod_dev＝［Σ（ｔ_period k −ｔperiod_ave）＾２／（ＮumPacket−１）］＾（１／２）
【００８６】
ここで、ΣはLearning period 間の合計を計算することを示している。また、パケットの発生サイズの平均値（Ｓ_ave）及び偏差（Ｓ_dev）を同様に計算する。
Ｓ_ave＝Σ（Ｓrxi ）／ＮumPacket
Ｓ_dev＝［Σ（Ｓrxi −Ｓ_ave）＾２／ＮumPacket］＾（１／２）
【００８７】
次に、以下の条件式をいずれも満足する場合、規則的なトラヒックと判定する。
ｔperiod_dev／ｔperiod_ave＜Ｔｈ_period ……（３）
Ｓ_dev／Ｓ_ave＜Ｔｈ_size ……（４）
【００８８】
ここに、Ｔｈ_period ，Ｔｈ_size は、規則的トラヒックと判定するためのしきい値である。規則的なトラヒックであれば、平均値に対する偏差が小さいと考えるからである。
【００８９】
本実施の形態では、規則的なトラヒックの判定のために、平均値と偏差とを用いたが、判定方法はこれに限らない。例えば、以下のように、各測定値の最大値と最小値とが、所定のしきい値よりも小さい場合を判定条件にすることも考えられる。
（ｔ_period max −ｔ_period min ）＜Ｔｈ_period2
（Ｓrxmax −Ｓrxmin ）＜Ｔｈ_size2
ここで、ｍａｘ，ｍｉｎは、測定値の最大値、最小値をそれぞれ表す。
【００９０】
上記条件式のいずれかを満足しない場合、非規則的なトラヒックと判定し（Ｓ２２７、Ｎｏ）、本トラヒックに関しては、Dynamic スケジューリングの適用を継続する（Ｓ２２８）。上記条件式（３），（４）を何れも満足する場合、規則的なトラヒックと判定し（Ｓ２２７、Ｙｅｓ）、周期的に割当てるリソースを計算する（Ｓ２２９）。割当リソースの計算方法は、第一の実施の形態と同じとする。発生周期ｔ_gp 、発生サイズＳは、それぞれ以下のように計算する。
ｔ_gp ＝ｔperiod_ave
Ｓ＝Ｓ_ave
【００９１】
また、発生タイミングｔ_gt は、Learning period 中の最後に受信したパケットの一部を最初に受信した時刻（Ｔ_last ）を使って、以下の式で計算する。
ｔ_gt ＝ＭＯＤ（Ｔ_last ，ｔ_gp ）
【００９２】
図１７に受信タイミングのイメージ図を示す。図１７の例では、Learning Period 中に監視できる受信トラヒックはパケット３個である。各パラメータは以下のように計算できる。
ｔperiod_ave＝（ｔ_period 1 ＋ｔ_period 2 ）／（３−１）
ｔperiod_dev＝［｛（ｔ_period 1 −ｔ_period_ave ）＾２＋（ｔ_period 2 −ｔperiod_ave）＾２｝／（３−１）］＾（１／２）
Ｓ_ave＝（Ｓrx1 ＋Ｓrx2 ＋Ｓrx3 ）／３
Ｓ_dev＝［｛（Ｓrx1 −Ｓ_ave）＋（Ｓrx2 −Ｓ_ave）＋（Ｓrx3 −Ｓ_ave）｝／３］＾（１／２）
【００９３】
次に、ＲＢの割当状態から、割当てるリソースがある場合（Ｓ２３０、Ｙｅｓ）、割当リソース情報を端末１１０に送信する（Ｓ２３１）。割当てるリソースがない場合、リソースが割当てられるまで、Persistentスケジューリングの割当候補として、Dynamic スケジューリングを継続するが（Ｓ２３２）、所定時間、リソース要求を受信できなくなれば（Ｓ２３３、Ｙｅｓ）、トラヒックの発生が終了したと判断し、Persistentスケジューリングの割当候補としては除外し、処理を終了する。
【００９４】
次に、受信トラヒック監視部１０３は、受信トラヒックを監視し（Ｓ２３４）、所定時間、端末１１０がトラヒックを送信しない場合（Ｓ２３５、Ｙｅｓ）、トラヒックの発生が終了したと判定し、端末１１０に周期的に割当てたリソースを解放することを通知する（Ｓ２３６）。この通知に対する確認応答を受信できれば（Ｓ２３７、Ｙｅｓ）、周期的に割当てたリソースを解放し、端末１１０に対するPersistentスケジューリングを終了する（Ｓ２３８）。
【００９５】
本実施の形態を適用した場合のデータ送信のイメージ図を図１８に示す。本実施の形態では、端末は送信するトラヒックがある場合、リソース要求のみ送信しているが、例えば、送信バッファサイズを送信してもよい。この場合、基地局は、Dynamic スケジューリングにおいて、送信バッファのデータを送信可能なだけのリソースを割当てればよいので、無線リソースの利用効率が改善する。
【００９６】
また、本実施の形態において、更に第一の実施の形態のように、端末１００でトラヒックを監視すれば、トラヒックの状態に変更があっても、適切なリソースの再割当てが可能となる。また、ハンドオーバー時、基地局１００は、判定した端末１１０の周期的なトラヒックの情報を、ハンドオーバー先の基地局に転送すれば、ハンドオーバー先の基地局は、Learning Period を実施する手間が省け、効率的である。
【００９７】
ＶｏＩＰトラヒック等で、本第四の実施の形態と第一の実施の形態を組み合わせた場合のシグナリングフローのイメージ例を図１９に示す。ＵＥ（端末）は、トラヒックを送信する場合、Source cell （ハンドオーバー基の基地局のセル）と、Call Setup（コールセットアップ）を行い（Ｓ３０１）、無線リンクを確立する。次に、Source Cell は、Learning Periodで、トラヒックの解析を行なう（Ｓ３０２）。次に、解析結果に基づいて、Source Cell は、Persistentスケジューリングでリソース割当てを行なう（Ｓ３０３）。
【００９８】
ハンドオーバーを実施する場合、例えば、以下の手順でシグナリングを実施する。先ず、ＵＥは、Source cell にHO request（ハンドオーバー要求）を送信し（Ｓ３０４）、Source cell は、Target cell(ハンドオーバー先の基地局のセル）に、HO requestを送信する（Ｓ３０５）。次に、ハンドオーバーが可能であれば、Target cell は、ネットワーク側のＧＷ（ゲートウェイ）にＨＯ（ハンドオーバー）の実施を通知し（Ｓ３０６）、同時に、HO command（ハンドオーバーコマンド）をSource cell に送信する（Ｓ３０７）。
【００９９】
次に、Source cell は、HO commandをＵＥに送信し（Ｓ３０８）、同時に、Learning Periodで解析した情報をTarget cell にForwarding（転送）する（Ｓ３０９）。次に、ＵＥはHO complete をTarget cell に送信し（Ｓ３１０）、ハンドオーバーが完了する。ハンドオーバー後、Target cell は、Learning Period を実施せず、Persistentスケジューリングを実施できる（Ｓ３１１）。
【０１００】
Learning Periodで解析した情報の転送は、Source cell とTarget cell とにおいて実施している無線システムが異なっている場合でも、効果がある。無線システムに関わらず、Persistentスケジューリングをサポートしてれば、Learning Period を省略できるからである。例えば、Source cell では、ＬＴＥが実施されており、Target cell では、ＷＣＤＭＡや無線ＬＡＮが実施されている場合などである。
【０１０１】
＜第五の実施の形態＞
次に、本発明の第五の実施の形態について説明する。図２０は、上述した第三の実施の形態を下り回線に適用した場合の基本構成の例を示す図であり、図１０と同等部分は同一符号により示す。図２０において、端末１１０は端末動作部１１のみを有しており、基地局１００は、基地局動作部１０１と、リソース管理部１０２と、トラヒック発生部１０４と、送信トラヒック監視部１０５とを有している。トラヒック発生部１０４及び送信トラヒック監視部１０５は、図１０のトラヒック発生部１１２及び送信トラヒック監視部１１４とそれぞれ同等機能を有する。
【０１０２】
本実施の形態における動作は、図２，３に示された第一の実施の形態と同様であるので、説明を省略するが、下り回線の場合、ネットワークを介してトラヒックが基地局の送信バッファに到着するので、トラヒックのゆらぎ等が発生する。従って、本実施の形態のように、送信状況を監視し、割当リソースを再割当て、即ち、割当リソースを調整することは、送信遅延に対して効果が大きい。
【０１０３】
＜第六の実施の形態＞
次に、本発明の第六の実施の形態について説明する。図２１は、上述した第四の実施の形態を下り回線に適用した場合の基本構成の例を示す図であり、図１４と同等部分は同一符号により示す。図２１において、端末１１０は端末動作部１１のみを有しており、基地局１００は、基地局動作部１０１と、リソース管理部１０２と、トラヒック発生部１０４と、トラヒック判定部１０６とを有している。トラヒック判定部１０６は、第四の実施の形態の受信トラヒック監視部１０３と同様に、トラヒックを監視し、トラヒックが規則的に到着するかを判定する機能を有する。
【０１０４】
本実施の形態の動作は、図１５及び図１６に示された第四の実施の形態と同様であるので、説明を省略する。
【０１０５】
以上述べたように、本発明では、端末は、規則的に発生するトラヒックを監視し、トラヒックに所定の変化が発生したら、基地局に報告する。基地局は、報告に基づいて、Persistentスケジューリングでリソース割当てを行なう。これにより、送信遅延を満足できる適切なリソースを割当てることができる。また、トラヒックに所定の変化が発生した場合だけ報告するので、シグナリングに伴うリソース消費を抑制できる。
【０１０６】
また、本発明では、規則的に発生するトラヒックの送信状況を監視し、送信状況が所定の条件を満足しなければ、基地局に送信状況を報告する。基地局は、報告に基づいて、Persistentスケジューリングでリソース割当てを行なう。これにより、送信遅延を満足できるリソースを割当てることができる。更に、本発明では、基地局は、端末に割当てたリソースの使用率を監視し、使用率が低ければ、割当てたリソースを削減する。これにより、過剰なリソース割当てを回避できる。
【０１０７】
更にはまた、本発明では、基地局は、端末から送信されるトラヒックの受信状況を監視し、規則的なトラヒックか否かの判定を行ない、規則的なトラヒックであれば、Persistentスケジューリングでリソース割当てを行なう。これにより、基地局が事前に規則的なトラヒックであることを把握できなくても、Persistentスケジューリングでリソースを割当てることができる。
【０１０８】
また、本発明では、基地局は、端末に割当てたリソースの使用率を監視し、使用率が低ければ、リソースを割当てたリソースを解放する。これにより、無駄なリソース割り当てを回避することができる。また、ハンドオーバー時、判定したトラヒック情報を、ハンドオーバー先の基地局に転送できる。これにより、ハンドオーバー先の基地局は、トラヒックが周期的か否かを判定する手間が省ける。
【産業上の利用可能性】
【０１０９】
以上の各実施の形態では、ＬＴＥを例に説明したが、トラヒックが規則的に発生し、そのトラヒックの送信に、周期的に使用できるリソースを割当てる通信システムであれば、他の通信システムにも適用できる。また、フローチャートを用いて説明した各実施の形態の動作は、その動作手順を予めプログラムとしてＲＯＭなどの記録媒体に格納しておき、これをコンピュータにより読取らせて実行させるように構成できることは明白である。
【符号の説明】
【０１１０】
１００ 基地局
１０１ 基地局動作部
１０２ リソース管理部
１０３ 受信トラヒック監視部
１０４ 基地局
１０５ 送信トラヒック監視部（基地局）
１０６ トラヒック判定部
１１０ 端末
１１１ 端末動作部
１１２ トラヒック発生部
１１３ 発生トラヒック監視部
１１４ 送信トラヒック監視部（端末）
【技術分野】
【０００１】
本発明は通信システムにおけるリソース割当方法及びリソース割当システム並びにそれに用いる基地局に関し、特に規則的にトラヒックが発生する通信システムにおけるリソース割当方式に関するものである。
【背景技術】
【０００２】
３ＧＰＰ（3rd Generation Partnership Project）において標準化が進められているＬＴＥ（Long Term Evolution ）の上り回線では、スケジューリング方法として、いわゆるDynamic （動的）スケジューリングとPersistent（固定的）スケジューリングとの両スケジューリング方式が検討されている（非特許文献１参照）。
【０００３】
前者のDynamic スケジューリングは、１ＴＴＩ（Transmission Time Interval）毎に、通信端末（以下、単に端末と称す）にリソースを割当てるスケジューリングである。ここに、リソースとは、ＲＢ（Resource Block）と、ＭＣＳ（Modulation and Coding Schemes ）を指し、ＲＢとは、１ＴＴに割当てることができる周波数リソースの最小単位である。ＬＴＥの上り回線では、１つの端末に周波数軸上で連続した複数のＲＢを割り当てることが可能である。ＭＣＳとは、変調方式と誤り訂正の符号化率のセットである。割当てるＲＢ数とＭＣＳとの組み合わせによって送信ビット数が決定される。
【０００４】
このDynamic スケジューリングによれば、チャネル品質に応じたリソース割当てができるので、高スループットが期待できるが、シグナリング情報が多いために、１ＴＴＩでの同時送信端末数が制限される。従って、規則的にトラヒックが発生する場合、例えば、ＶｏＩＰ（Voice over IP ）トラヒックのように、１パケットのサイズが小さく、所定の周期でトラヒックが発生する場合、割当て可能なＲＢ数に余裕があるにも関わらず、同時送信端末数の制限のために収容端末（ユーザ）数を増やせないという問題がある。
【０００５】
かかる問題点を解決するために、後者のPersistentスケジューリングが検討されている。このPersistentスケジューリングは、所定の周期で使用できるリソースを割当てるスケジューリングであり、１度リソースを割当てれば、シグナリング情報を送信しないで済むという利点がある。チャネル品質に応じた動的なリソース割当てはできないが、シグナリング情報が削減できるので、１ＴＴＩの同時送信端末（ユーザ）数を増やすことができる。
【０００６】
また、Persistentスケジューリングの１つとして、バンドリング（Bundling）が検討されている。このバンドリングは、複数のパケットをまとめて１ＴＴＩで送信する方法であり、オーバヘッドの削減が期待されている（非特許文献２参照）。
【０００７】
なお、関連する技術として、特許文献１や２などがある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００３−１６３６６７号公報
【特許文献２】特開２００７−１０４７０５号公報
【非特許文献】
【０００９】
【非特許文献１】3GPP TS36.300 V8.1.0 (2007-06), 3GPP Evolved Universal Terre strial Radio Access and Evolved Universal Terrestrial Radio Access Network, pp.56
【非特許文献２】R2-072630, 3GPP TSG-RAN WG2 Meeting #58bis, HARQ operation in case of UL Power Limitation
【発明の概要】
【発明が解決しようとする課題】
【００１０】
規則的に発生するトラヒックを、Persistentスケジューリングで送信する場合、特にバンドリングにおいて、送信遅延が問題となる。この問題点を図２２を参照して説明する。トラヒックはＶｏＩＰトラヒックであり、音声パケットのエンコード周期を２０ｍｓとし、バンドリングであると仮定し、１ＴＴＩで２音声パケットを送信し、ＲＢの割当て周期をエンコード周期の２倍の４０ｍｓとする。また、パケット発生から５０ｍｓ以内に送信を完了できない場合には、ＱｏＳ（Quality of Service）を満足できないものとする。
【００１１】
いま、パケットＰ１，Ｐ２の送信直後の１ｍｓ後（時刻Ｔ０）に、パケットＰ３が発生すると仮定する。その２０ｍｓ後にパケットＰ４が発生し、パケットＰ３，Ｐ４は、時刻Ｔ１に最初の送信がなされるとする（本送）。チャネル品質が悪いために、時刻Ｔ１での送信に失敗した場合、
時刻Ｔ２＝Ｔ１＋ＨＡＲＱ（Hybrid Automatic Repeat request ）ＲＴＴ（Round Trip Time ）で再送がなされる（再１）。更に、時刻Ｔ２での再送に失敗した場合、
時刻Ｔ３＝Ｔ１＋２＊ＨＡＲＱ ＲＴＴ
で次の再送がなされる（再２）。
【００１２】
ここで、１ＲＴＴ＝６ｍｓとし、２回目の再送で送信に成功した場合、以下のように、パケットＰ３の送信遅延が５０ｍｓを超えてしまうことになる。
Ｄｅｌａｙ（Ｐ３）＝Ｔ３−Ｔ０＝Ｔ１−Ｔ０＋２＊ＨＡＲＱ ＲＴＴ
＝３９＋２＊６＝５１ｍｓ＞５０ｍｓ
Ｄｅｌａｙ（Ｐ４）＝Ｔ３−（Ｔ０＋２０）＝３１ｍｓ＜５０ｍｓ
【００１３】
また、基地局が、トラヒックが規則的に発生することを事前に把握できない場合や、規則的なトラヒックであることは認識できても、トラヒックの発生周期やトラヒックのサイズなどがわからない場合、Persistentスケジューリングを実施できない点が問題となる。
【００１４】
ここで、特許文献１及び２を参照すると、送信遅延を防止するために、前者では、蓄積パケット量を、後者では、キューの長さを、それぞれ監視して、この監視結果に基づいて送信遅延を抑制するようなリソース割当てを実施するというものである。これら特許文献１や２の技術では、蓄積パケット量やキューの長さ、すなわちバッファサイズに基づいて遅延を予測するものであるから、送信パケットの発生周期やそのタイミングの変化やずれに対しては、何等送信遅延を効果的に抑制するようなリソース割当てを実施することはできない。
【００１５】
本発明の目的は、効果的に送信遅延を抑制することができる通信システムにおけるリソース割当方法及びリソース割当システム並びにそれに用いる基地局を提供することである。
【課題を解決するための手段】
【００１６】
本発明による第一の方法は、端末と、基地局とを含み、前記端末に規則的にデータが発生し、基地局は前記端末にリソースを割当て、前記通信端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、前記端末は、前記データを監視する監視ステップと、前記データに所定の変化が発生したら前記基地局に報告する報告ステップとを備え、前記基地局は、前記端末からの報告に基づいてリソース割当てを決める割当てステップを備えることを特徴とする。
【００１７】
本発明による第二の方法は、端末と、基地局とを含み、前記端末に規則的にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、前記端末は、前記データの送信状況を監視する監視ステップと、前記送信状況が所定条件を満足しなければ前記基地局に報告する報告ステップとを備え、前記基地局は、前記端末からの報告に基づいてリソース割当てを決める割当てステップを備えることを特徴とする。
【００１８】
本発明による第三の方法は、端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、前記基地局は、前記データの受信状況を監視する監視ステップと、前記受信状況に基づいて前記データが規則的に発生するか判定する判定ステップと、規則的に発生すると判定した場合、前記監視結果に基づいて周期的にリソースを割当てる割当てステップとを備えることを特徴とする。
【００１９】
本発明による第四の方法は、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが規則的に到着し、前記基地局は前記端末にリソースを割当て、前基地局は前記リソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、前記基地局は、前記データの送信状況を監視する監視ステップと、前記送信状況が所定条件を満足しなければ、前記監視結果に基づいてリソース割当てを決定する割当てステップとを備えることを特徴とする。
【００２０】
本発明による第五の方法は、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが到着し、前記基地局は前記端末にリソースを割当て、前基地局は前記リソースを用いてデータを送信する通信システムにおけるリソース割り当て方法であって、前記基地局は、前記データを監視する監視ステップと、前記監視結果に基づいて前記データが規則的に到着するか判定する判定ステップと、規則的に到着すると判定した場合、前記監視結果に基づいて前記リソースを割当てる割当てステップとを備えることを特徴とする。
【００２１】
本発明による第一のシステムは、端末と、基地局とを含み、前記端末に規則的にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当てシステムであって、前記端末は、前記データを監視して前記データに所定の変化が発生したら前記基地局に報告する監視手段を備え、前記基地局は、前記報告に基づいてリソース割当てを決める割当て手段を備えることを特徴とする。
【００２２】
本発明による第二のシステムは、端末と、基地局とを含み、前記端末に規則的にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当てシステムであって、前記端末は、前記データの送信状況を監視して前記送信状況が所定条件を満足しなければ前記基地局に報告する監視手段を備え、前記基地局は、前記端末からの報告に基づいてリソース割当てを決める割当て手段を備えることを特徴とする。
【００２３】
本発明による第三のシステムは、端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当システムであって、前記基地局は、前記データの受信状況を監視する監視手段と、前記受信状況に基づいて前記データが規則的に発生するか判定する判定手段と、規則的に発生すると判定した場合、前記監視結果に基づいてリソースを割当てる割当て手段とを備えることを特徴とする。
【００２４】
本発明による第四のシステムは、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが規則的に到着し、前記基地局は前記端末にリソースを割当て、前記基地局は前記リソースを用いてデータを送信する通信システムにおけるリソース割り当てシステムであって、前記基地局は、前記データの送信状況を監視する監視手段と、前記送信状況が所定の条件を満足しなければ、前記監視結果に基づいてリソース割当てを決定する割当て手段とを備えることを特徴とする。
【００２５】
本発明による第五のシステムは、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが到着し、前記基地局は前記端末にリソースを割当て、前基地局は前記リソースを用いてデータを送信する通信システムにおけるリソース割り当てシステムであって、前記基地局は、前記データを監視する監視手段と、前記監視結果に基づいて前記データが規則的に到着するか判定する判定手段と、規則的に到着すると判定した場合、前記監視結果に基づいて前記データの発生から所定の時間内に前記データを送信できるリソースを周期的に割当てる割当て手段とを備えることを特徴とする。
【００２６】
本発明による第一の基地局は、端末と、基地局とを含み、前記端末に規則的にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおける基地局であって、前記データに所定の変化が発生した旨の前記端末からの報告に基づいて、前記リソース割当てを決める割当て手段を備えることを特徴とする。
【００２７】
本発明による第二の基地局は、端末と、基地局とを含み、前記端末に規則的にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおける基地局であって、前記データの送信状況が所定条件を満足しない旨の、前記端末からの報告に基づいてリソース割当てを決める割当て手段を備えることを特徴とする。
【００２８】
本発明による第三の基地局は、端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおける基地局であって、前記データの受信状況を監視する監視手段と、前記受信状況に基づいて前記データが規則的に発生するか判定する判定手段と、規則的に発生すると判定した場合、前記監視結果に基づいてリソースを割当てる割当て手段とを備えることを特徴とする。
【００２９】
本発明による第四の基地局は、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが規則的に到着し、前記基地局は前記端末にリソースを割当て、前基地局は前記リソースを用いてデータを送信する通信システムにおける基地局であって、前記データの送信状況を監視する監視手段と、前記送信状況が所定の条件を満足しなければ、前記監視結果に基づいてリソース割当てを決定する割当て手段とを備えることを特徴とする。
【００３０】
本発明による第五の基地局は、端末と、基地局とを含み、前記基地局に、前記端末に送信するデータが到着し、前記基地局は前記端末にリソースを割当て、前基地局は前記リソースを用いてデータを送信する通信システムにおける基地局であって、前記データを監視する監視手段と、前記監視結果に基づいて前記データが規則的に到着するか判定する判定手段と、規則的に到着すると判定した場合、前記監視結果に基づいて前記データの発生から所定の時間内に前記データを送信できるリソースを周期的に割当てる割当て手段とを備えることを特徴とする。
【発明の効果】
【００３１】
本発明による第１の効果は、規則的に発生するトラヒックに対し、送信遅延を抑制したPersistentスケジューリングを実施できることである。その第１の理由は、トラヒックを監視して、トラヒックに所定の変化が生じれば、基地局に報告し、基地局は、報告に基づいて、報告に基づいて送信遅延が小さくなるタイミングの周期的なリソースを割当てるからである。また、その第２の理由は、トラヒックの送信状況を監視して、送信状況が所定の条件を満足しなければ、基地局に報告し、基地局は、報告に基づいて、報告に基づいて送信遅延が小さくなるタイミングの周期的なリソースを割当てるからである。
【００３２】
また、本発明による第２の効果は、基地局が事前に規則的なトラヒックであることを把握できなくても、送信遅延を抑制したPersistentスケジューリングを実施できることである。その理由は、基地局が、トラヒックの受信状況を監視し、規則的なトラヒックか否かの判定を行ない、規則的なトラヒックであれば、送信遅延が小さくなるタイミングの周期的なリソースを割当てるからである。
【図面の簡単な説明】
【００３３】
【図１】第一の実施の形態の通信システムの構成を示すブロック図である。
【図２】第一の実施の形態の端末の動作手順を示すフローチャート図である。
【図３】第一の実施の形態の基地局の動作手順を示すフローチャート図である。
【図４】発生するトラヒックのイメージ図である。
【図５】トラヒックの発生状態の変更のイメージ図である。
【図６】ＲＢの割当て状態の管理イメージ図である。
【図７】パケットの発生タイミングとＲＢの割当て状態のイメージ図である。
【図８】第一の実施の形態のデータ送信タイミング図である。
【図９】第二の実施の形態の通信システムの構成を示すブロック図である。
【図１０】第三の実施の形態の通信システムの構成を示すブロック図である。
【図１１】第三の実施の形態の端末の動作手順を示すフローチャート図である。
【図１２】第三の実施の形態の基地局の動作手順を示すフローチャート図である。
【図１３】第三の実施の形態の割当リソースの計算方法の動作手順を示すフローチャート図である。
【図１４】第四の実施の形態の通信システムの構成を示すブロック図である。
【図１５】第四の実施の形態の端末の動作手順を示すフローチャート図である。
【図１６】第四の実施の形態の基地局の動作手順を示すフローチャート図である。
【図１７】第四の実施の形態のデータ受信タイミング図である。
【図１８】第四の実施の形態のデータ送信タイミング図である。
【図１９】第一と第四の実施の形態を組み合わせた場合のシグナリングフローイメージ図である。
【図２０】第五の実施の形態の通信システムの構成を示すブロック図である。
【図２１】第六の実施の形態の通信システムの構成を示すブロック図である。
【図２２】既存の技術におけるデータ送信タイミング図である。
【発明を実施するための形態】
【００３４】
以下に、図面を参照しつつ本発明の実施の形態について詳細に説明する。
＜第一の実施の形態＞
図１は、本発明が適用される通信システムの基本構成の例を示す図である。本実施の形態では、通信システムとして、ＬＴＥの上り回線を例にとって説明する。図１を参照すると、本通信システムは、基地局１００と端末１１０とから構成される。基地局１００は、端末１１０と無線チャネルによって接続される。基地局１００は図示せぬネットワークと接続されている。また、図示していないが、基地局１００は複数の端末と接続することができる。また、基地局も複数存在することができる。
【００３５】
図１を参照すると、基地局１００は、基地局動作部１０１と、リソース管理部１０２とを含んでいる。また、端末１１０は、端末動作部１１１と、トラヒック発生部１１２と、発生トラヒック監視部１１３を含んでいる。基地局動作部１０１は、ＬＴＥシステムにおいて一般的に用いられる基地局と同等の機能を有しており、その構成及び動作については周知であるので、その説明を省略する。本実施の形態においては、一般的な機能ではあるが、端末１１０から送信されるトラヒックを受信する機能を有する。リソース管理部１０２は、ＲＢの割当状態を管理し、端末に割当てるリソースを決定する機能を有する。
【００３６】
端末動作部１１１は、ＬＴＥシステムにおいて一般的に用いられる端末と同等の機能を有しており、その構成及び動作については周知であるので、その説明を省略する。本実施の形態においては、一般的な機能ではあるが、割当てられたリソースで、トラヒックを送信する機能を有する。トラヒック発生部１１２は、トラヒック発生の開始と終了を端末動作部１１１に通知する機能と、トラヒックを発生する機能とを有する。発生トラヒック監視部１１３は、トラヒックを監視し、監視結果を基地局１００に報告する機能を有する。
【００３７】
次に、本実施の形態の動作について図面を参照して説明する。図２及び図３は、規則的なトラヒックが発生する端末１１０に対して、基地局１００がPersistentスケジューリングでリソース割当てを行なう動作手順を示すもであり、端末１１０及び基地局１００の各フローチャートである。
【００３８】
図２を参照して、端末１１０の実際の動作手順を説明する。端末動作部１１１は、トラヒック発生時、基地局１００にトラヒック情報を送信する（Ｓ１０１）。トラヒック情報とは、パケットの発生周期、発生タイミング、発生サイズの各パラメータを指す。パケットとは、トラヒックの到着単位である。図４に、トラヒック情報のイメージ図を示す。発生周期をｔ_gp 、発生タイミングをｔ_gt 、発生サイズをＳ（Size）として、各パラメータは変動しないと仮定している。
【００３９】
ｔ_gt は現在時刻を発生周期ｔ_gp で割った余りで表され、以下の式で定義される。
ｔ_gt ＝ＭＯＤ（Ｔgn ，ｔ_gp ）
ここで、Ｔgnは、パケットＰn が端末の送信バッファに到着した時刻を表す。発生タイミングを考慮せず、Ｔgn+1の直前のＲＢを割当てると、遅延が増大してＱｏＳを満足できない問題が発生し易くなる。但し、端末１１０と基地局１００間で既知のトラヒック情報のパラメータは送信する必要はない。例えば、端末１１０と基地局１００間で、発生周期と発生サイズとは、事前に既知の情報であれば、発生タイミングのみを送信すればよい。
【００４０】
次に、基地局１００より、割当リソース情報を受信できれば（Ｓ１０２、Ｙｅｓ）、端末動作部１１１は、割当リソース情報を記憶し（Ｓ１０３）、周期的に割当てられたリソースでのトラヒックの送信を開始する。割当リソース情報を受信できなければ（Ｓ１０２、Ｎｏ）、リソースが割当てられなかったので、処理を終了する。
【００４１】
次に、発生トラヒック監視部１１３は、トラヒックを監視し（Ｓ１０４）、トラヒックに所定の変化があれば（Ｓ１０５、Ｙｅｓ）、基地局１００にトラヒック情報を送信する（Ｓ１０６）。送信するのは、変化があったパラメータだけでよい。図５に、トラヒックの発生状態の変化のイメージ図を示す。ａ）は初期状態である。ｂ）は発生タイミングの変化例である。ｃ）は発生周期の変化例である。ｄ）は発生サイズの変化例である。
【００４２】
例えば、図５のパラメータを用いれば、以下のいずれかの条件を満足できない場合、所定の変化が発生したと判定する。
｜ｔ_gt k+1 −ｔ_gt k ｜＜Ｔｈ_tgt
｜ｔ_gp k+1 −ｔ_gp k ｜＜Ｔｈ_tgp
｜Ｓk+1 −Ｓk ｜＜Ｔｈ_S
ここに、Ｔｈ_tgt，Ｔｈ_tgp，Ｔｈ_Sは、それぞれしきい値を表す。
【００４３】
次に、基地局１００より、トラヒックの変化による割当リソースの更新情報を受信した場合（Ｓ１０７、Ｙｅｓ）、端末動作部１１１は、割当リソース情報を更新する（Ｓ１０８）。割当リソース情報を受信しなければ（Ｓ１０７、Ｎｏ）、引き続き、割当て済みのリソースでデータを送信する。次に、端末動作部１１１は、トラヒック終了時（Ｓ１０９）、基地局１００にトラヒック終了報告を送信し（Ｓ１１０）、処理を終了する。
【００４４】
次に、図３を参照して、基地局１００の実際の動作手順を説明する。リソース管理部１０２は、端末１１０から、トラヒック情報を受信した場合（Ｓ１２１、Ｙｅｓ）、割当リソースを計算し（Ｓ１２２）、ＲＢの割当状態から、割当リソースを更新できる場合（Ｓ１２３、Ｙｅｓ）、割当リソース情報を端末１１０に送信する（Ｓ１２４）。割当リソースの計算方法は後述する。
【００４５】
図６に、ＲＢの割当状態の管理イメージを示す。縦軸はＲＢ番号（RB Index）、横軸はＴＴＩ番号（TTI Index）であり、１ＴＴＩ当たり最大７個のＲＢを、２０ＴＴＩの周期で繰り返し使用できるＲＢの管理テーブルを示している。３個のＲＢを割当てる場合、割当可能なTTI Index ＝５、RB Index＝３〜５を選択する例を示している。なお、網かけ部分は割当て済みのＲＢを示し、白い部分は未割当のＲＢを示し、太線内の３個のＲＢが割当てるＲＢを示す。
【００４６】
次に、リソース管理部１０２は、端末１１０から、トラヒック終了報告を受信した場合（Ｓ１２５、Ｙｅｓ）、端末のリソースの解放処理を行い、処理を終了する（Ｓ１２６）。次に、割当リソース、即ち、ＭＣＳとＲＢとの計算方法を説明する。本実施の形態では、ＭＣＳは予め決められた唯一の固定値を選択する。また、１ＲＢ当たりの送信データサイズをＴＤＵ（Transmission Data Unit）と定義する。ＴＤＵはＭＣＳよって一意に決まり、例えば、３個のＲＢを割当てる場合、送信データサイズは３＊ＴＤＵとなるとする。また、１ＴＴＩで送信するパケット数をＮ_tp とし、固定値とする。
【００４７】
ＲＢに関するパラメータとしては、割当ＲＢ数（Ｎ_RBs）と、割当周期（ｔ_ap ）と、TTI Index （tti_idx ）とを計算する。また、tti_idx ＝０に該当する時刻（Ｔbase[TTI] ）を基地局１００と端末１１０とにより共有し、かつ現在時刻も共有する。Ｔbaseは以下を満足する。
【００４８】
ＭＯＤ（Ｔbase，Ｔap）＝０
現在時刻の共有は、ＧＰＳ（Global Positioning System)を用いる方法や、所定のタイミングで、基地局１００が端末１１０に、現在時刻を通知する方法などが考えられる。また、Ｔbaseの共有は、所定のタイミングや、割当リソース情報を送信するに、基地局１００が端末１１０に通知する方法などが考えられる。
【００４９】
Ｎ_RBsは以下となる。
Ｎ_RBs＝ＣＥＩＬ（（Ｎ_tp ＊Ｓ）／ＴＤＵ）
ここに、ＣＥＩＬは、少数点以下を切り上げる整数を返す関数を表す。例えば、ＣＥＩＬ（１．５）＝２となる。ｔ_ap は、以下となる。
ｔ_ap ＝Ｎ_tp ＊ｔ_gp
tti_idx は、送信遅延を少なくするため、送信バッファへのパケット到着からｔ_gp ／２以内のタイミングで送信するよう、以下を満足する中で、ＲＢの割当状態を考慮して決定する。
ＭＯＤ（tti_idx ＋ｔ_gp −ｔ_gt ，ｔ_gp ）≦ｔ_gp ／２
【００５０】
また、再送データのリソース割当て方法をPersistentスケジューリングと、Dynamic スケジューリングのどちらにするかは、任意に選択できるものとする。例えば、チャネル品質が悪く、再送回数の期待値が大きい場合、Persistentスケジューリングで、再送分のリソースを確保しておくことが考えられる。
【００５１】
また、本実施の形態では、ＭＣＳは唯一のものを選択したが、パイロット信号や制御信号やトラヒックの受信時に、端末１１０のチャネル品質を測定しておき、チャネル品質に応じてＭＣＳを選択することも可能である。また、本実施の形態では、トラヒックの発生周期、発生タイミング、発生サイズを、固定的としたが、変動してもよい。その場合、以下のような測定を行い、発生トラヒックの状況を監視する。例えば、発生周期ｔ_gp については、ある所定の時間内の平均値（ｔ_gp_ave t ）を測定する。次に、前回の平均値（ｔ_gp_ave t-1 ）と比較し、以下の条件式を満足できなければ、所定の変化が発生したと判定するなどである。
｜ｔ_gp_ave t −t_gp_avet-1 ｜＞Ｔｈ_tgp
発生タイミングｔ_gt 、発生サイズＳも同様である。
【００５２】
次に、割当リソースの計算に関する具体例について説明する。ＴＴＩはｍｓ単位とし、トラヒック情報のうち、発生周期ｔ_gp ＝２０ｍｓ、発生サイズＳ＝３２０ビットは不変で、基地局１００、端末１１０間で既知とする。また、端末１１０から、発生タイミングｔ_gt ＝５ｍｓが、基地局１００に送信されたと仮定する。また、リソース管理部１０２のパラメータは以下を仮定する。
ＴＤＵ＝１７０ビット、Ｎ_tp ＝２
【００５３】
先ず、割当ＲＢ数Ｎ_RBsは以下となる。
Ｎ_RBs＝ＣＥＩＬ（（Ｎ_tp ＊Ｓ）／ＴＤＵ）＝ＣＥＩＬ（２＊３２０／１７０）＝４
次に、割当周期ｔ_ap は以下となる。
ｔ_ap ＝Ｎ_tp ＊ｔ_gp ＝２＊２０＝４０ｍｓ
次に、パケットの発生タイミングとＲＢの割当状態を図７とすると、tti_idx は、選択可能な直近のＴＴＩの２５を選択する。上記より、端末１１０は、４０ｍｓに１回、４ＲＢを使ってトラヒックの本送を行なうことができる。
【００５４】
本実施の形態を適用した場合の、図２２の既存の例に対する効果を図８に示す。パケットが発生してから本送するまでのＴ1 −Ｔ0 の期待値が、従来例の３０ｍｓ（＝（２０＋３９）／２）から２５ｍｓ（＝（２０＋３０）／２）に改善されることになる。
【００５５】
＜第二の実施の形態＞
次に、本発明の第二の実施の形態について説明する。図９は本実施の形態による通信システムの基本構成の例を示す図であり、図１と同等部分は同一符号により示している。図９の構成を図１の例と比較すると、端末１１０のトラヒック発生部１１２が削除され、代わりに、端末１１０の外部にトラヒック発生装置１２０が追加された点が異なる。
【００５６】
トラヒック発生装置１２０は、図１のトラヒック発生部１１２と同等の機能を有する。また、端末１１０とトラヒック発生装置１２０とは、無線リンクで接続されている。例えば、トラヒック発生装置１２０をパソコン（パーソナルコンピュータ）とし、端末１１０を無線モデムとして、両者はBluetooth （登録商標）等の無線リンクで接続されており、パソコンでインターネット電話をする場合が、本実施の形態に該当することになる。
【００５７】
本実施の形態の動作は、図２及び図３に示された第一の実施の形態のそれと同じである。なお、Persistentスケジューリングのリソース割当ての更新契機としては、端末１１０とトラヒック発生装置１２０間の無線リンクが不安定で、トラヒック発生装置１２０から端末１１０に到着するパケットのタイミングがずれた場合など、が考えられる。
【００５８】
＜第三の実施の形態＞
次に、本発明の第三の実施の形態について説明する。図１０は本実施の形態による通信システムの基本構成の例を示す図である。図１と同等部分は同一符号により示している。図１０の構成を図１の例と比較すると、端末１１０において、発生トラヒック監視部１１３が削除され、代わりに送信トラヒック監視部１１４が追加された点が異なる。
【００５９】
送信トラヒック監視部１１４は、トラヒックの送信状況を監視し、監視結果を基地局１００に報告する機能を有する。また、リソース管理部１０２は、第一の実施の形態の機能に加えて、トラヒックの受信状況から、リソースの使用状態を監視する機能を、更に有する。
【００６０】
次に、本実施の形態の動作について図面を参照して説明する。図１１及び図１２は、規則的なトラヒックが発生する端末１１０に対して、基地局１００がPersistentスケジューリングでリソース割当てを行なう動作手順を示すフローチャートであり、図１１が端末１１０、図１２が基地局１００の、各フローチャートである。
【００６１】
図１１を参照して、端末１１０の実際の動作手順を説明する。端末動作部１１１は、トラヒック発生時、基地局１００にリソース割当要求を送信し（Ｓ１４１）、基地局１００より、割当リソース情報を受信できれば（Ｓ１４２、Ｙｅｓ）、端末動作部１１１は、割当リソース情報を記憶し（Ｓ１４３）、割当てられたリソースでのトラヒックの送信を開始する。割当リソース情報を受信できなければ（Ｓ１４２、Ｎｏ）、リソースが割当てられなかったので、処理終了となる。
【００６２】
次に、送信トラヒック監視部１１４は、トラヒックの送信状況を監視する（Ｓ１４４）。トラヒックの送信状況として、送信バッファにあるパケット数（Ｎ_buff ）と、パケットｉの送信遅延（ｄｅｌａｙi ）の各パラメータを監視する。ｄｅｌａｙi の測定には、上位レイヤの確認応答を用いることが考えられる。
【００６３】
次に、送信バッファにあるパケット数Ｎ_Buff と新規に測定したｄｅｌａｙi を各しきい値（Ｔｈ_N_buff ，Ｔｈ_delay）と比較し、以下の条件式（１），（２）を１つでも満足しない場合、トラヒックの送信状況に問題ありと判定し（Ｓ１４５）、基地局１００に、トラヒックの送信情報として、条件式を満足できなかったパラメータを送信する（Ｓ１４６）。
Ｎ_buff ＜Ｔｈ_N_buff ……（１）
ｄｅｌａｙi ＜Ｔｈ_delay……（２）
【００６４】
例えば、式（１）を満足できないのは、割当リソース不足が原因と考えることができる。また、式（２）を満足できないのは、割当リソース不足と、不適切な送信タイミングの少なくとも１つが原因と考えることができる。次に、基地局１００より、割当リソースの更新情報を受信した場合（Ｓ１４７、Ｙｅｓ）、端末動作部１１１は、割当リソース情報を更新する（Ｓ１４８）。割当リソース情報を受信できなければ（Ｓ１４７、Ｎｏ）、引き続き、割当済みのリソースでデータを送信する。次に、端末動作部１１１は、トラヒック終了時（Ｓ１４９）、基地局１００にトラヒック終了報告を送信し（Ｓ１５０）、処理を終了する。
【００６５】
図１２を参照して、基地局１００の実際の動作手順を説明する。リソース管理部１０２は、端末１１０からリソース割当要求を受信した場合（Ｓ１６１、Ｙｅｓ）、初期設定で決められた割当リソースを計算し（Ｓ１６２）、ＲＢの割当状態から、割当て可能なリソースがある場合（Ｓ１６３、Ｙｅｓ）、端末１１０にリソースを割当て、割当リソース情報を端末１１０に送信する（Ｓ１６４）。
【００６６】
次に、端末１１０から、トラヒックの送信情報を受信した場合（Ｓ１６５、Ｙｅｓ）、割当リソースを計算し、ＲＢの割当状態から割当リソースを更新できる場合（Ｓ１６６、Ｙｅｓ）、割当リソース情報を端末１１０に送信する（Ｓ１６７）。
【００６７】
図１３を参照して、図１２のステップＳ１６６の割当リソースの計算方法を詳細に説明する。ＭＣＳは、第一の実施の形態と同様に、予め決められた唯一の固定値を選択する。また、１ＴＴＩで送信するパケット数Ｎ_tp も固定値とする。ＲＢに関するパラメータの種類は、第一の実施の形態と同じく、割当ＲＢ数Ｎ_RBsと、割当周期ｔ_ap と、tti_idxとする。このうち、トラヒックの送信情報を受信しても、割当周期ｔ_ap は更新しないとする。
【００６８】
先ず、トラヒックの送信情報として、送信バッファにあるパケット数Ｎ_Buff を受信した場合（Ｓ１８１、Ｙｅｓ）、リソース不足が原因と判定し、以下の式に従って、更新する場合のＮ_RBsを計算し、リソース管理部１０２は、ＲＢの割当状態から、図９の第一の実施の形態と同様に、割当可能なtti_idx を検索する（Ｓ１８２）。
Ｎ_RBs＝Ｎ_RBs＋１
【００６９】
tti_idx は、送信タイミングよって、送信遅延が増加しないよう、割当済みのtti_idxから、降順に検索するのが望ましい。例えば、割当済みのtti_idx を５とし、割当周期を２０ＴＴＩとすると、以下の順に検索することになる。
tti_idx 候補→５，４…１，２０，１９…７，６
【００７０】
また、トラヒックの送信情報として、送信バッファにあるパケット数Ｎ_Buff を受信しなかった場合（Ｓ１８１、Ｎｏ）、送信遅延だけを受信しているので、不適切な送信タイミングが原因と判定し、送信遅延が増加しないよう、割当済みのtti_idx 以外から、降順に検索する（Ｓ１８３）。例えば、割当済みのtti_idx を１とし、割当周期を２０ＴＴＩとすると、以下の順に検索することになる。
tti_idx 候補→２０，１９…３，２
【００７１】
Ｓ１８２，Ｓ１８３による検索の結果、割当可能なＲＢがあれば（Ｓ１８４、Ｙｅｓ）、割当リソース情報を端末１１０に送信する（Ｓ１６７）。
【００７２】
次に、リソース管理部１０２は、リソースの使用状態を監視し（Ｓ１６８）、リソース使用率が所定のしきい値よりも小さければ、割当リソースが過剰である判定し（Ｓ１６９、Ｙｅｓ）、割当リソースを削減し（Ｓ１７０）、割当リソース情報を端末１１０に送信する（Ｓ１７１）。リソース使用率の判定は、以下の条件式を用いる。
Σ｛ＴＤ／（Ｎ_RBs＊ＴＤＵ）｝＜Ｔｈ_band
【００７３】
ここに、ＴＤはあるＴＴＩで実際に送信されたトラヒックサイズを表し、Ｎ_RBs＊ＴＤＵは割当ＲＢで送信可能なトラヒックサイズを表す。従って、ＴＤ／（Ｎ_RBs＊ＴＤＵ）は、割当られた帯域の使用率を表す。Σは、ＲＢの割当タイミング（tti_idx ）で測定した結果の合計を取ることを示す。Ｔｈ_band は、リソース使用率しきい値である。
【００７４】
割当リソースを削減する場合、以下のように、Ｎ_RBsを更新する。
Ｎ_RBs＝ＭＡＸ（Ｎ_RBs−１，１）
次に、リソース管理部１０２は、端末１１０から、トラヒック終了報告を受信した場合（Ｓ１７２、Ｙｅｓ）、端末のリソースの解放処理を行い、処理を終了する（Ｓ１７３）。
【００７５】
なお、本実施の形態では、Ｎ_RBsを１ずつ増減する例を示したが、送信バッファにあるパケット数Ｎ_Buff と、しきい値Ｔｈ_N_buff とを比較して、２以上増加させることも可能である。また、本実施の形態では、トラヒックの送信状態として、送信バッファにあるパケット数と送信遅延とを用いたが、例えば、パケット数はデータサイズに、送信遅延はスループットに、それぞれ置換えることも可能である。
【００７６】
＜第四の実施の形態＞
次に、本発明の第四の実施の形態について説明する。図１４は、本発明の第四の実施の形態による通信システムの基本構成の例を示す図であり、図１と同等部分は同一符号により示す。図１４の構成において、図１のそれと比較すると、端末１１０から発生トラヒック監視部１１３が削除され、代わりに基地局１００に受信トラヒック監視部１０３が追加された点が異なる。
【００７７】
受信トラヒック監視部１０３は、トラヒックの受信状況を監視し、リソース管理部１０２と監視結果を共有する機能を有する。また、基地局動作部１０１は、第一の実施の形態の機能に加えて、端末１１０のチャネル品質を測定する機能を、更に有する。チャネル品質は、パイロット信号や制御信号やトラヒックの受信時に測定されるものとする。
【００７８】
次に、本実施の形態の動作について図面を参照して説明する。図１５及び図１６は、トラヒックが発生した端末１１０に対して、基地局１００は受信状況から規則的なトラヒックか判定し、規則的なトラヒックであれば、Persistentスケジューリングでリソース割当てを行なう動作手順を示すフローチャートであり、端末１１０及び基地局１００の各フローチャートである。
【００７９】
図１６の基地局１００のフローチャートは、主に、大きく２つ部分から構成されている。第１の部分は、Learning Period （Dynamic スケジューリング）と記載した部分である。この部分は、トラヒックを解析し、規則的に発生するトラヒックか否かを判定する処理を行なうものである。また、第２の部分は、Learning based Persistent スケジューリングと記載した部分であり、判定の結果、ＶｏＩＰなど、規則的なトラヒックであれば、解析結果に基づいて周期的なリソースを割当てる処理を行なうものである。
【００８０】
一方、ＦＴＰ（File Transfer Protocol）ファイル転送など、バースト的に発生する非規則的なトラヒックであれば、Dynamic スケジューリングの適用を継続する。図１５の端末１１０のフローチャートの構成も、Learning Period と、Learning based Persistentスケジューリングに対応している。
【００８１】
図１５を参照して、端末１１０の実際の動作手順を説明する。端末動作部１１１は、送信するトラヒックがある場合（Ｓ２０１）、基地局１００にリソース要求を送信する（Ｓ２０２）。次に、基地局１００から瞬時的な割当リソース情報を受信した場合（Ｓ２０３、Ｙｅｓ）、端末動作部１１１は割当リソース情報を記憶し、指定された送信タイミングでトラヒックを送信する（Ｓ２０４）。
【００８２】
一方、基地局１００から周期的な割当リソース情報を受信した場合（Ｓ２０５、Ｙｅｓ）、端末動作部１１１は、割当リソース情報を記憶し、周期的なトラヒック送信が開始できることになる（Ｓ２０６）。次に、周期的な割当リソースの解放通知を受信した場合（Ｓ２０７）、端末１１０は、基地局１００に受信に対する確認応答を送信し、Persistentスケジューリングでのトラヒックの送信を終了する（Ｓ２０８）。発生するのが非規則的なトラヒックであれば、Ｓ２０１〜Ｓ２０５の処理を繰り返し、Dynamic スケジューリングが継続される。
【００８３】
図１６を参照して、基地局１００の実際の動作手順を説明する。リソース管理部１０２は、端末１１０からリソース要求を受信した場合（Ｓ２２１、Ｙｅｓ）、トラヒックが規則的か否か判定済みでなければ（Ｓ２２２、Ｎｏ）、判定を実施する期間であるLearningPeriod を開始する（Ｓ２２３）。次に、測定したチャネル品質から、ＭＣＳと割当ＲＢとを計算し、瞬時的な割当リソース情報を端末１１０に送信する（Ｓ２２４）。
【００８４】
次に、受信トラヒック監視部１０３は、端末１１０からのトラヒックの受信状況を監視する（Ｓ２２５）。トラヒックの受信状況として、受信したパケット数（ＮumPacket）、受信したパケットｉのサイズ（Ｓrxi ）、パケットｉの一部を最初に受信した時刻と、次のパケットｉ＋１の一部を最初に受信した時刻の間隔（ｔ_periodk ）を監視する。ｔ_periodk は、ＮumPacket−１個測定できる。次に、所定のLearning period が経過したら（Ｓ２２６）、トラヒックを解析し、規則的か否か判定する（Ｓ２２７）。判定は以下のように行なう。
【００８５】
先ず、パケットの発生間隔の平均値（ｔperiod_ave）、偏差（ｔperiod_dev）を以下の式から推定する。
Ｔperiod_ave＝Σ（ｔ_periok k ）／（ＮumPacket−１）
Ｔperiod_dev＝［Σ（ｔ_period k −ｔperiod_ave）＾２／（ＮumPacket−１）］＾（１／２）
【００８６】
ここで、ΣはLearning period 間の合計を計算することを示している。また、パケットの発生サイズの平均値（Ｓ_ave）及び偏差（Ｓ_dev）を同様に計算する。
Ｓ_ave＝Σ（Ｓrxi ）／ＮumPacket
Ｓ_dev＝［Σ（Ｓrxi −Ｓ_ave）＾２／ＮumPacket］＾（１／２）
【００８７】
次に、以下の条件式をいずれも満足する場合、規則的なトラヒックと判定する。
ｔperiod_dev／ｔperiod_ave＜Ｔｈ_period ……（３）
Ｓ_dev／Ｓ_ave＜Ｔｈ_size ……（４）
【００８８】
ここに、Ｔｈ_period ，Ｔｈ_size は、規則的トラヒックと判定するためのしきい値である。規則的なトラヒックであれば、平均値に対する偏差が小さいと考えるからである。
【００８９】
本実施の形態では、規則的なトラヒックの判定のために、平均値と偏差とを用いたが、判定方法はこれに限らない。例えば、以下のように、各測定値の最大値と最小値とが、所定のしきい値よりも小さい場合を判定条件にすることも考えられる。
（ｔ_period max −ｔ_period min ）＜Ｔｈ_period2
（Ｓrxmax −Ｓrxmin ）＜Ｔｈ_size2
ここで、ｍａｘ，ｍｉｎは、測定値の最大値、最小値をそれぞれ表す。
【００９０】
上記条件式のいずれかを満足しない場合、非規則的なトラヒックと判定し（Ｓ２２７、Ｎｏ）、本トラヒックに関しては、Dynamic スケジューリングの適用を継続する（Ｓ２２８）。上記条件式（３），（４）を何れも満足する場合、規則的なトラヒックと判定し（Ｓ２２７、Ｙｅｓ）、周期的に割当てるリソースを計算する（Ｓ２２９）。割当リソースの計算方法は、第一の実施の形態と同じとする。発生周期ｔ_gp 、発生サイズＳは、それぞれ以下のように計算する。
ｔ_gp ＝ｔperiod_ave
Ｓ＝Ｓ_ave
【００９１】
また、発生タイミングｔ_gt は、Learning period 中の最後に受信したパケットの一部を最初に受信した時刻（Ｔ_last ）を使って、以下の式で計算する。
ｔ_gt ＝ＭＯＤ（Ｔ_last ，ｔ_gp ）
【００９２】
図１７に受信タイミングのイメージ図を示す。図１７の例では、Learning Period 中に監視できる受信トラヒックはパケット３個である。各パラメータは以下のように計算できる。
ｔperiod_ave＝（ｔ_period 1 ＋ｔ_period 2 ）／（３−１）
ｔperiod_dev＝［｛（ｔ_period 1 −ｔ_period_ave ）＾２＋（ｔ_period 2 −ｔperiod_ave）＾２｝／（３−１）］＾（１／２）
Ｓ_ave＝（Ｓrx1 ＋Ｓrx2 ＋Ｓrx3 ）／３
Ｓ_dev＝［｛（Ｓrx1 −Ｓ_ave）＋（Ｓrx2 −Ｓ_ave）＋（Ｓrx3 −Ｓ_ave）｝／３］＾（１／２）
【００９３】
次に、ＲＢの割当状態から、割当てるリソースがある場合（Ｓ２３０、Ｙｅｓ）、割当リソース情報を端末１１０に送信する（Ｓ２３１）。割当てるリソースがない場合、リソースが割当てられるまで、Persistentスケジューリングの割当候補として、Dynamic スケジューリングを継続するが（Ｓ２３２）、所定時間、リソース要求を受信できなくなれば（Ｓ２３３、Ｙｅｓ）、トラヒックの発生が終了したと判断し、Persistentスケジューリングの割当候補としては除外し、処理を終了する。
【００９４】
次に、受信トラヒック監視部１０３は、受信トラヒックを監視し（Ｓ２３４）、所定時間、端末１１０がトラヒックを送信しない場合（Ｓ２３５、Ｙｅｓ）、トラヒックの発生が終了したと判定し、端末１１０に周期的に割当てたリソースを解放することを通知する（Ｓ２３６）。この通知に対する確認応答を受信できれば（Ｓ２３７、Ｙｅｓ）、周期的に割当てたリソースを解放し、端末１１０に対するPersistentスケジューリングを終了する（Ｓ２３８）。
【００９５】
本実施の形態を適用した場合のデータ送信のイメージ図を図１８に示す。本実施の形態では、端末は送信するトラヒックがある場合、リソース要求のみ送信しているが、例えば、送信バッファサイズを送信してもよい。この場合、基地局は、Dynamic スケジューリングにおいて、送信バッファのデータを送信可能なだけのリソースを割当てればよいので、無線リソースの利用効率が改善する。
【００９６】
また、本実施の形態において、更に第一の実施の形態のように、端末１００でトラヒックを監視すれば、トラヒックの状態に変更があっても、適切なリソースの再割当てが可能となる。また、ハンドオーバー時、基地局１００は、判定した端末１１０の周期的なトラヒックの情報を、ハンドオーバー先の基地局に転送すれば、ハンドオーバー先の基地局は、Learning Period を実施する手間が省け、効率的である。
【００９７】
ＶｏＩＰトラヒック等で、本第四の実施の形態と第一の実施の形態を組み合わせた場合のシグナリングフローのイメージ例を図１９に示す。ＵＥ（端末）は、トラヒックを送信する場合、Source cell （ハンドオーバー基の基地局のセル）と、Call Setup（コールセットアップ）を行い（Ｓ３０１）、無線リンクを確立する。次に、Source Cell は、Learning Periodで、トラヒックの解析を行なう（Ｓ３０２）。次に、解析結果に基づいて、Source Cell は、Persistentスケジューリングでリソース割当てを行なう（Ｓ３０３）。
【００９８】
ハンドオーバーを実施する場合、例えば、以下の手順でシグナリングを実施する。先ず、ＵＥは、Source cell にHO request（ハンドオーバー要求）を送信し（Ｓ３０４）、Source cell は、Target cell(ハンドオーバー先の基地局のセル）に、HO requestを送信する（Ｓ３０５）。次に、ハンドオーバーが可能であれば、Target cell は、ネットワーク側のＧＷ（ゲートウェイ）にＨＯ（ハンドオーバー）の実施を通知し（Ｓ３０６）、同時に、HO command（ハンドオーバーコマンド）をSource cell に送信する（Ｓ３０７）。
【００９９】
次に、Source cell は、HO commandをＵＥに送信し（Ｓ３０８）、同時に、Learning Periodで解析した情報をTarget cell にForwarding（転送）する（Ｓ３０９）。次に、ＵＥはHO complete をTarget cell に送信し（Ｓ３１０）、ハンドオーバーが完了する。ハンドオーバー後、Target cell は、Learning Period を実施せず、Persistentスケジューリングを実施できる（Ｓ３１１）。
【０１００】
Learning Periodで解析した情報の転送は、Source cell とTarget cell とにおいて実施している無線システムが異なっている場合でも、効果がある。無線システムに関わらず、Persistentスケジューリングをサポートしてれば、Learning Period を省略できるからである。例えば、Source cell では、ＬＴＥが実施されており、Target cell では、ＷＣＤＭＡや無線ＬＡＮが実施されている場合などである。
【０１０１】
＜第五の実施の形態＞
次に、本発明の第五の実施の形態について説明する。図２０は、上述した第三の実施の形態を下り回線に適用した場合の基本構成の例を示す図であり、図１０と同等部分は同一符号により示す。図２０において、端末１１０は端末動作部１１のみを有しており、基地局１００は、基地局動作部１０１と、リソース管理部１０２と、トラヒック発生部１０４と、送信トラヒック監視部１０５とを有している。トラヒック発生部１０４及び送信トラヒック監視部１０５は、図１０のトラヒック発生部１１２及び送信トラヒック監視部１１４とそれぞれ同等機能を有する。
【０１０２】
本実施の形態における動作は、図２，３に示された第一の実施の形態と同様であるので、説明を省略するが、下り回線の場合、ネットワークを介してトラヒックが基地局の送信バッファに到着するので、トラヒックのゆらぎ等が発生する。従って、本実施の形態のように、送信状況を監視し、割当リソースを再割当て、即ち、割当リソースを調整することは、送信遅延に対して効果が大きい。
【０１０３】
＜第六の実施の形態＞
次に、本発明の第六の実施の形態について説明する。図２１は、上述した第四の実施の形態を下り回線に適用した場合の基本構成の例を示す図であり、図１４と同等部分は同一符号により示す。図２１において、端末１１０は端末動作部１１のみを有しており、基地局１００は、基地局動作部１０１と、リソース管理部１０２と、トラヒック発生部１０４と、トラヒック判定部１０６とを有している。トラヒック判定部１０６は、第四の実施の形態の受信トラヒック監視部１０３と同様に、トラヒックを監視し、トラヒックが規則的に到着するかを判定する機能を有する。
【０１０４】
本実施の形態の動作は、図１５及び図１６に示された第四の実施の形態と同様であるので、説明を省略する。
【０１０５】
以上述べたように、本発明では、端末は、規則的に発生するトラヒックを監視し、トラヒックに所定の変化が発生したら、基地局に報告する。基地局は、報告に基づいて、Persistentスケジューリングでリソース割当てを行なう。これにより、送信遅延を満足できる適切なリソースを割当てることができる。また、トラヒックに所定の変化が発生した場合だけ報告するので、シグナリングに伴うリソース消費を抑制できる。
【０１０６】
また、本発明では、規則的に発生するトラヒックの送信状況を監視し、送信状況が所定の条件を満足しなければ、基地局に送信状況を報告する。基地局は、報告に基づいて、Persistentスケジューリングでリソース割当てを行なう。これにより、送信遅延を満足できるリソースを割当てることができる。更に、本発明では、基地局は、端末に割当てたリソースの使用率を監視し、使用率が低ければ、割当てたリソースを削減する。これにより、過剰なリソース割当てを回避できる。
【０１０７】
更にはまた、本発明では、基地局は、端末から送信されるトラヒックの受信状況を監視し、規則的なトラヒックか否かの判定を行ない、規則的なトラヒックであれば、Persistentスケジューリングでリソース割当てを行なう。これにより、基地局が事前に規則的なトラヒックであることを把握できなくても、Persistentスケジューリングでリソースを割当てることができる。
【０１０８】
また、本発明では、基地局は、端末に割当てたリソースの使用率を監視し、使用率が低ければ、リソースを割当てたリソースを解放する。これにより、無駄なリソース割り当てを回避することができる。また、ハンドオーバー時、判定したトラヒック情報を、ハンドオーバー先の基地局に転送できる。これにより、ハンドオーバー先の基地局は、トラヒックが周期的か否かを判定する手間が省ける。
【産業上の利用可能性】
【０１０９】
以上の各実施の形態では、ＬＴＥを例に説明したが、トラヒックが規則的に発生し、そのトラヒックの送信に、周期的に使用できるリソースを割当てる通信システムであれば、他の通信システムにも適用できる。また、フローチャートを用いて説明した各実施の形態の動作は、その動作手順を予めプログラムとしてＲＯＭなどの記録媒体に格納しておき、これをコンピュータにより読取らせて実行させるように構成できることは明白である。
【符号の説明】
【０１１０】
１００ 基地局
１０１ 基地局動作部
１０２ リソース管理部
１０３ 受信トラヒック監視部
１０４ 基地局
１０５ 送信トラヒック監視部（基地局）
１０６ トラヒック判定部
１１０ 端末
１１１ 端末動作部
１１２ トラヒック発生部
１１３ 発生トラヒック監視部
１１４ 送信トラヒック監視部（端末）
【特許請求の範囲】
【請求項１】
端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、
前記基地局は、前記データの受信状況を監視する監視ステップと、前記受信状況に基づいて前記データが規則的に発生するか判定する判定ステップと、規則的に発生すると判定した場合、前記監視結果に基づいて周期的にリソースを割当てる割当てステップとを備えることを特徴とする方法。
【請求項２】
前記判定ステップは、前記データの受信状況から、前記データの発生間隔と、前記データの発生サイズとを計算し、各々が所定条件を満足するか判定することを特徴とする請求項１記載の方法。
【請求項３】
前記基地局は、割当てたリソースの使用率を測定するステップと、前記使用率が所定しきい値よりも低ければ、割当てたリソースを解放するステップとを、更に備えることを特徴とする請求項１記載の方法。
【請求項４】
前記基地局は、ハンドオーバー時、前記受信状況の監視結果をハンドオーバー先の基地局に転送するステップを、更に備えることを特徴とする請求項１記載の方法。
【請求項５】
端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当システムであって、
前記基地局は、前記データの受信状況を監視する監視手段と、前記受信状況に基づいて前記データが規則的に発生するか判定する判定手段と、規則的に発生すると判定した場合、前記監視結果に基づいてリソースを割当てる割当て手段とを備えることを特徴とするシステム。
【請求項６】
前記判定手段は、前記データの受信状況から、前記データの発生間隔と前記データの発生サイズとを計算し、各々が所定条件を満足するか判定することを特徴とする請求項５記載のシステム。
【請求項７】
前記基地局は、割当てたリソースの使用率を測定する測定手段と、前記使用率が所定のしきい値よりも低ければ、割当てたリソースを解放する解放手段とを、更に備えることを特徴とする請求項５記載のシステム。
【請求項８】
前記基地局は、ハンドオーバー時、前記監視結果をハンドオーバー先の基地局に転送する転送手段を、更に備えることを特徴とする請求項５記載のシステム。
【請求項９】
端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおける基地局であって、
前記データの受信状況を監視する監視手段と、前記受信状況に基づいて前記データが規則的に発生するか判定する判定手段と、規則的に発生すると判定した場合、前記監視結果に基づいてリソースを割当てる割当て手段とを備えることを特徴とする基地局。
【請求項１０】
前記判定手段は、前記データの受信状況から、前記データの発生間隔と前記データの発生サイズとを計算し、各々が所定条件を満足するか判定することを特徴とする請求項９記載の基地局。
【請求項１１】
割当てたリソースの使用率を測定する測定手段と、前記使用率が所定のしきい値よりも低ければ、割当てたリソースを解放する解放手段とを、更に備えることを特徴とする請求項９記載の基地局。
【請求項１２】
ハンドオーバー時、前記監視結果をハンドオーバー先の基地局に転送する転送手段を、更に備えることを特徴とする請求項９記載の基地局。
【請求項１】
端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当方法であって、
前記基地局は、前記データの受信状況を監視する監視ステップと、前記受信状況に基づいて前記データが規則的に発生するか判定する判定ステップと、規則的に発生すると判定した場合、前記監視結果に基づいて周期的にリソースを割当てる割当てステップとを備えることを特徴とする方法。
【請求項２】
前記判定ステップは、前記データの受信状況から、前記データの発生間隔と、前記データの発生サイズとを計算し、各々が所定条件を満足するか判定することを特徴とする請求項１記載の方法。
【請求項３】
前記基地局は、割当てたリソースの使用率を測定するステップと、前記使用率が所定しきい値よりも低ければ、割当てたリソースを解放するステップとを、更に備えることを特徴とする請求項１記載の方法。
【請求項４】
前記基地局は、ハンドオーバー時、前記受信状況の監視結果をハンドオーバー先の基地局に転送するステップを、更に備えることを特徴とする請求項１記載の方法。
【請求項５】
端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおけるリソース割当システムであって、
前記基地局は、前記データの受信状況を監視する監視手段と、前記受信状況に基づいて前記データが規則的に発生するか判定する判定手段と、規則的に発生すると判定した場合、前記監視結果に基づいてリソースを割当てる割当て手段とを備えることを特徴とするシステム。
【請求項６】
前記判定手段は、前記データの受信状況から、前記データの発生間隔と前記データの発生サイズとを計算し、各々が所定条件を満足するか判定することを特徴とする請求項５記載のシステム。
【請求項７】
前記基地局は、割当てたリソースの使用率を測定する測定手段と、前記使用率が所定のしきい値よりも低ければ、割当てたリソースを解放する解放手段とを、更に備えることを特徴とする請求項５記載のシステム。
【請求項８】
前記基地局は、ハンドオーバー時、前記監視結果をハンドオーバー先の基地局に転送する転送手段を、更に備えることを特徴とする請求項５記載のシステム。
【請求項９】
端末と、基地局とを含み、前記端末にデータが発生し、前記基地局は前記端末にリソースを割当て、前記端末は前記リソースを用いてデータを送信する通信システムにおける基地局であって、
前記データの受信状況を監視する監視手段と、前記受信状況に基づいて前記データが規則的に発生するか判定する判定手段と、規則的に発生すると判定した場合、前記監視結果に基づいてリソースを割当てる割当て手段とを備えることを特徴とする基地局。
【請求項１０】
前記判定手段は、前記データの受信状況から、前記データの発生間隔と前記データの発生サイズとを計算し、各々が所定条件を満足するか判定することを特徴とする請求項９記載の基地局。
【請求項１１】
割当てたリソースの使用率を測定する測定手段と、前記使用率が所定のしきい値よりも低ければ、割当てたリソースを解放する解放手段とを、更に備えることを特徴とする請求項９記載の基地局。
【請求項１２】
ハンドオーバー時、前記監視結果をハンドオーバー先の基地局に転送する転送手段を、更に備えることを特徴とする請求項９記載の基地局。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【公開番号】特開２０１２−２１３２００（Ｐ２０１２−２１３２００Ａ）
【公開日】平成２４年１１月１日（２０１２．１１．１）
【国際特許分類】
【出願番号】特願２０１２−１３０６９２（Ｐ２０１２−１３０６９２）
【出願日】平成２４年６月８日（２０１２．６．８）
【分割の表示】特願２００９−５３８９７８（Ｐ２００９−５３８９７８）の分割
【原出願日】平成２０年９月１６日（２００８．９．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＣＤＭＡ
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年１１月１日（２０１２．１１．１）
【国際特許分類】
【出願日】平成２４年６月８日（２０１２．６．８）
【分割の表示】特願２００９−５３８９７８（Ｐ２００９−５３８９７８）の分割
【原出願日】平成２０年９月１６日（２００８．９．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＣＤＭＡ
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]