(57)【要約】  ＶｏＩＰサービスを支援する無線通信システムにおいてアップリンクリソースをスケジューリングする方法が提供される。基地局は、端末のデータレート変更要請によってアップリンクデータレートが変更されるまで持続的に同一のリソースを割り当てる。データレートが変更されると、端末がそれを基地局に報告することで、基地局が上記要請されたデータレートに応じてリソースを割り当てるようにする。
2008510422.tif 000002
【特許請求の範囲】
【請求項１】
伝送データのサイズが可変する無線通信システムにおいて端末（ＳＳ）がリアルタイムでデータを伝送する方法であって、
基地局（ＢＳ）により割り当てられたデータレートに対応したサイズのデータを前記ＢＳに伝送する過程と、
前記データレートの変更が必要である場合、前記ＢＳに現在のデータレートの変更を要請する過程とを、含み、
前記変更されたデータレートに対応したサイズのデータが、前記レート変更要請と共に伝送されることを特徴とする方法。
【請求項２】
前記レート変更要請は、レートダウン要請であることを特徴とする請求項１に記載の方法。
【請求項３】
前記レート変更要請ステップは、前記データレートの減少によって節約された余剰リソースを用いて前記現在のデータレートの変更を要請する過程を含むことを特徴とする請求項２に記載の方法。
【請求項４】
少なくとも一つの端末と該端末にアップリンクデータレートを割り当てる基地局とを備える移動通信システムにおいてアップリンクデータレートを制御する方法であって、
前記端末において、前記アップリンクデータレートの変更が必要であるかどうかを判定し、
前記アップリンクデータレートの変更が必要である場合、前記アップリンクデータレートを変更するために前記基地局に変更要請を伝送し、
前記基地局において、前記変更要請によって指定された前記アップリンクデータレートを前記端末に割り当てることを特徴とするアップリンクデータレートの制御方法。
【請求項５】
前記変更要請は、アップリンク割り当て要請とレートダウン要請のいずれかであることを特徴とする請求項４に記載の方法。
【請求項６】
前記レートダウン要請は、伝送されるデータにおけるアップリンクデータレートを含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記レートダウン要請は、データレートインデックスによって指定された前記アップリンクデータレートにて生成されたデータと共にピギーバックされることを特徴とする請求項６に記載の方法。
【請求項８】
前記アップリンク割り当て要請は、前記端末が伝送するデータを有する時に伝送される初期アップリンク割り当て要請と同じであることを特徴とする請求項５に記載の方法。
【請求項９】
前記変更要請を伝送する過程は、
前記変更が増大変更であるかまたは減少変更であるかを判定し、
前記変更が前記増大変更である時、前記アップリンク割り当て要請を伝送し、
前記変更が前記減少変更である時、減少されたデータレートでのデータと共にレートダウン要請を伝送することを特徴とする請求項５に記載の方法。
【請求項１０】
前記アップリンクデータレートを割り当てる過程は、
前記変更要請がアップリンクデータ割り当て要請である時、前記端末のために使用可能な最大データレートを割り当て、
前記レートダウン要請によって指定された前記アップリンクデータレートを割り当てることを特徴とする請求項９に記載の方法。
【請求項１１】
少なくとも一つの加入者端末と該加入者端末のデータレートにて生成された音声パケットを伝送するためのアップリンクリソースを割り当てる基地局とを備えるＩＰ基盤の無線システムにおいて音声通信のためのアップリンクリソースを割り当てる方法であって、
前記加入者端末において、前記データレートの変更が必要であるかどうかを判定し、
前記変更が増大変更であるかまたは減少変更であるかを判定し、
前記変更が減少変更である時、前記アップリンクデータレートを減らすためのリソース割り当て要請を伝送し、
前記基地局において、前記リソース割り当て要請によって指定された前記アップリンクリソースの再割り当てを行うことを特徴とするアップリンクリソースの割り当て方法。
【請求項１２】
前記リソース割り当て要請を伝送する過程は、
前記リソース割り当て要請によって指定された前記データレートにて前記音声パケットを生成し、
前記音声パケットを前記リソース割り当て要請と共にピギーバックすることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記変更が前記減少変更である時、前記加入者端末のために使用可能な最大アップリンクリソースを要請する前記リソース割り当て要請を伝送する過程をさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１４】
少なくとも一つの加入者端末と該加入者端末にアップリンクリソースを割り当てる基地局とを備えるＩＰ基盤の無線システムにおいて音声通信のためのアップリンクリソースを割り当てる方法であって、
前記加入者端末において、前記アップリンクリソースの要請のために前記基地局に帯域幅要請メッセージを伝送し、
前記基地局において、前記帯域幅要請メッセージを受信すると、前記加入者端末の最大データレートにて生成された音声パケットのためのアップリンクリソースを割り当て、
前記加入者端末において、前記音声パケットを生成するための初期データレートを判定し、
前記判定されたデータレートにて生成された前記音声パケットを伝送することを特徴とするアップリンクリソースの割り当て方法。
【請求項１５】
前記音声パケットを伝送する過程は、
前記初期データレートが前記最大データレートより小さいかどうかを判定し、
前記判定されたデータレートが前記最大データレートより小さい時、前記データレートが増大されるべきかまたは減少されるべきかを判定し、
前記データレートが増大されるべきであると判定された時、グラント管理メッセージを伝送し、
前記データレートが減少されるべきであると判定された時、帯域幅要請メッセージを伝送することを特徴とする請求項１４に記載の方法。
【請求項１６】
前記グラント管理メッセージは、前記減少されたデータレートにて生成された前記音声パケットと共にピギーバックによって伝送されることを特徴とする請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線システムにおけるアップリンクスケジューリング方法に係り、特にＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）のためにアップリンクリソースをスケジューリングする方法に関する。
【背景技術】
【０００２】
限られたリソースを使って様々なサービスを提供する無線システムでは、リソースを効率よく使うためのスケジューリング手法が切実に求められている。不要に割り当てられたリソースを迅速に回収し、スケジューリングによって再割り当てを行うことが理想的である。さらには、情報量を減らすことにより節約された余剰リソースを他の目的にて用いる技法が考えられる。
【０００３】
ＶｏＩＰサービスのための従来のアップリンクスケジューリングタイプとしては、様々なものが提案されている。その代表的な例が、送信権割り当てサービス（ＵＧＳ：Ｕｎｓｏｌｉｃｉｔｅｄ  Ｇｒａｎｔ  Ｓｅｒｖｉｃｅ）とリアルタイムポーリングサービス（ｒｔＰＳ：Ｒｅａｌ-Ｔｉｍｅ  Ｐｏｌｌｉｎｇ  Ｓｅｒｖｉｃｅ）である。
【０００４】
上記ＵＧＳの場合は、ユーザの要請によって固定されたサイズのアップリンクリソースを割り当てる。したがって、ユーザは、固定されたサイズのアップリンクリソースを用いて自分が伝送したいデータを基地局（ＢＳ）に伝送する。上記ｒｔＰＳの場合は、ユーザからの周期的なアップリンクリソース割り当て要請に応答して、必要なリソースを割り当てる。したがって、ユーザは自分が伝送したいデータの量に応じて適切なリソースを割り当てられ、上記データを伝送する。
【０００５】
図１は、従来のＵＧＳによるアップリンクスケジューリング過程を示すグラフである。
【０００６】
上記図１を参照すれば、端末の状態は、時間軸上でオン区間（Ｔａｌｋ-ｓｐｕｒｔ  ＰＢＲｉｏｄ）とオフ区間（ｓｉｌｅｎｃｅ  ＰＢＲｉｏｄ）とに大きく分けられる。上記オン区間は、伝送データパケットが存在する区間であり、上記オフ区間は、伝送データパケットが存在しない区間である。上記図１では、最大データレート（Ｒａｔｅ  １）を支援することができるリソースが固定的に割り当てられた例を示している。
【０００７】
しかしながら、上記端末（ＳＳ：ｓｕｂｓｃｒｉｂｅｒ  ｓｔａｔｉｏｎ）は、常に自分に割り当てられたすべてのリソースを使ってデータを伝送しない。オフ区間１１０、１１８では、サービスを維持するのに必要な最小リソース（一例として、Ｒａｔｅ  １／８）だけが使われる。
【０００８】
そして、上記オン区間でも、割り当てられたリソースの一部だけが使われることもある。すなわち、上記ＳＳは、上記オン区間で自分に割り当てられたリソースの一部または全部を使ってデータパケットを伝送する。例えば、オン区間１１２では、Ｒａｔｅ  １にてデータパケットを伝送する。このためには、割り当てられたすべてのリソースを使う。オン区間１１４では、伝送するデータパケットの減少によりＲａｔｅ  １／２にてデータパケットを伝送する。この時は、割り当てられたリソースの１／２にあたるリソースのみを使う。オン区間１１６では、Ｒａｔｅ  １／４にてデータパケットを伝送する。この時は、割り当てられたリソースの１／４にあたるリソースのみを使う。その後、伝送するデータパケットが存在しないオフ区間１１８で、上記ＳＳは、最小リソースのみを使う。上記、最小リソースは、最小データレートであるＲａｔｅ  １／８を支援するためのリソースにあたる。
【０００９】
前述したように、最大データレートを使わない区間１１４、１１６、１１８では、固定的に割り当てられたリソースの一部が余剰リソースとして残るようになる。これは、アップリンクスケジューリングが効率よく行われていないことを示す。したがって、上記オフ区間だけでなくオン区間でもアップリンクのリソースが無駄使いされる問題が生じるようになる。
【００１０】
図２は、従来のｒｔＰＳによるアップリンクスケジューリング過程を示すグラフである。
【００１１】
上記図２を参照すれば、ｒｔＰＳにおいて、ＳＳは、参照符号２１２ないし２３６で示すように、アップリンクリソースを割り当てられるためにＢＳにリソース割り当てを要請する。上記ＢＳは、上記ＳＳから要請されたアップリンクリソースを該ＳＳに割り当てる。上記ＳＳは、参照符号２１０、２２０、２３０で示すように、上記ＢＳから割り当てられたリソースを用いてデータパケットを伝送する。
【００１２】
オン区間は、使われるデータレートによって３つの区間２１０、２２０、２３０に分けられる。上記第一のオン区間２１０は、Ｒａｔｅ  １にてデータパケットを伝送する区間であり、第二のオン区間２２０は、Ｒａｔｅ  １／２にてデータパケットを伝送する区間である。第三のオン区間２３０は、Ｒａｔｅ  １／４にてデータパケットを伝送する区間である。したがって、上記ＳＳは、上記オン区間において要請するリソースが互いに異なる。上記オン区間２１０から上記オン区間２２０への変更及び上記オン区間２２０から上記オン区間２３０への変更は、ＳＳにおけるデータレートの減少に起因する。
【００１３】
詳述すれば、ＳＳは、オフ区間で伝送するデータパケットが発生すると、ＢＳにリソース割り当てを要請する（ステップＳ２１２）。これに対応して上記ＢＳは、最大データレート（一例として、Ｒａｔｅ  １）を支援するための最大リソースを割り当てる。上記ＳＳは、該割り当てられたリソースを用いてＲａｔｅ  １にてデータパケットを伝送する。このようにＲａｔｅ  １にてデータパケットを伝送する動作は、オン区間２１０で繰り返し行われる。
【００１４】
上記オン区間２１０で伝送するデータパケットの量の減少によってデータレートの変更が必要になると、上記ＳＳは、減少されたデータレート（Ｒａｔｅ  １／２）を支援するためのリソース割り当てを要請する（ステップＳ２２２）。その後、上記ＢＳから割り当てられたリソースを用いてデータパケットを伝送する。このようにＲａｔｅ  １／２にてデータパケットを伝送する動作は、オン区間２２０で繰り返し行われる。
【００１５】
上記オン区間２２０でデータレートの減少がさらに要求されると、上記ＳＳは、さらに減少されたデータレート（Ｒａｔｅ  １／４）を支援するためのリソース割り当てを要請する（ステップＳ２３２）。その後、上記ＳＳは、Ｒａｔｅ  １／４にてデータパケットを伝送する。上記Ｒａｔｅ  １／４にてデータパケットを伝送するための動作は、オン区間２３０で繰り返し行われる。
【００１６】
上記ＳＳは、すべてのデータパケットの伝送が完了すると、最小リソース（一例として、Ｒａｔｅ  １／８）を使うオフ区間２４０での動作を行う。
【００１７】
前述の説明から分かるように、ｒｔＰＳを支援するためには、ＳＳによって周期的に行われるポーリング過程（アップリンクリソース要請過程２１２ないし２１８、２２２ないし２２６、２３２ないし２３６）が必ず必要である。このため、参照符号２１０、２２０、２３０で示すような同一のリソースによるデータパケットの伝送が要求される状況でも、周期的なポーリング過程２１４ないし２１８、２２４ないし２２６、２３４ないし２３６が行われる必要がある。したがって、不要なポーリング過程の遂行によってアップリンクのリソースが無駄使いされる問題が生じる。
【００１８】
前述したように、ＵＧＳ及びｒｔＰＳは、端末のリアルタイム状態に関係なく各スケジューリングタイプによって周期的にアップリンクリソースを割り当てていた。これは、リアルタイムに変化する端末の状態を適切に反映したアップリンクスケジューリングと言えない。したがって、端末の状況をリアルタイムで反映した効率よいアップリンクスケジューリング方案の確立が切実に求められている。
【発明の開示】
【発明が解決しようとする課題】
【００１９】
そこで、本発明は、上記従来技術の問題点を解決するためになされたものであって、その目的は、ＶｏＩＰサービスのためのアップリンクスケジューリングを効率よく行う方法を提供することである。
【００２０】
本発明の他の目的は、アップリンクリソースを割り当てるに際して、不要なリソースの無駄使いを最小化するアップリンクスケジューリング方法を提供することである。
【００２１】
本発明のまた他の目的は、ＳＳが不要にＢＳにリソース割り当てを要請することを防止するためのアップリンクスケジューリング方法を提供することである。
【００２２】
本発明のさらなる目的は、ＳＳの所望するデータレートを支援するための最適のリソースを割り当てるアップリンクスケジューリング方法を提供することである。
【００２３】
本発明のまた他の目的は、ＳＳからのデータレートの変更通知に応じてアップリンクスケジューリングを行う方法を提供することである。
【課題を解決するための手段】
【００２４】
上記した目的は、ＶｏＩＰサービスを支援する無線通信システムにおけるアップリンクリソーススケジューリング方法によって達成される。
【００２５】
本発明の第一の実施の形態によると、ＶｏＩＰを支援する無線通信システムの端末（ＳＳ）におけるアップリンクリソースのスケジューリング方法において、上記ＳＳは、上記ＶｏＩＰデータを伝送するリソースの割り当てを基地局（ＢＳ）に要請し、上記ＢＳから周期的に最大データレートを支援するリソースを割り当てられる。上記ＳＳは、上記最大データレートにて上記ＶｏＩＰデータを伝送する。上記リソース割り当てを要請する時、上記ＳＳは、上記ＢＳに上記最大データレートが変更される前までは同一のリソースを継続して割り当てることを要請する帯域幅要請情報を一緒に伝送する。上記リソース割り当て要請に応答して、最初のリソースは、上記周期と関係なく上記リソース割り当て要請を受信してから第一のリソース割り当て周期が到来する前に割り当てられる。
【００２６】
本発明の他の実施の形態によると、ＶｏＩＰを支援する無線通信システムの基地局（ＢＳ）におけるアップリンクリソースのスケジューリング方法において、上記ＢＳは、上記ＶｏＩＰデータの伝送のためのリソース割り当て要請をＳＳから受信する。上記リソース割り当て要請に応答して、上記ＢＳは、上記ＳＳより最大データレートにて上記データを伝送するのに必要なリソースを周期的に割り当てる。上記リソース割り当て要請を受信する時、上記ＢＳは、上記ＳＳから上記最大データレートが変更される前までは同一のリソースを継続して割り当てることを要請する帯域幅要請情報を一緒に受信する。上記リソース割り当て要請に応答した最初のリソースが、上記周期と関係なく上記リソース割り当て要請を受信してから第一のリソース割り当て周期が到来する前に割り当てられる。
【００２７】
本発明のまた他の実施の形態によると、ＶｏＩＰを支援する無線通信システムの端末（ＳＳ）におけるアップリンクリソースのスケジューリング方法において、上記ＳＳは、上記ＶｏＩＰデータを伝送するリソースの割り当てをＢＳに要請する。上記ＳＳは、上記ＢＳにより割り当てられたリソースを用いて最大データレートにて上記ＶｏＩＰデータを伝送する。上記データレートが変更されると、上記ＳＳは、該変更されたデータレートにて上記データを上記ＢＳに伝送し、残りのリソースを用いてデータレートが変更されたことを知らせる識別情報を上記ＢＳに伝送する。リソース割当を要請する時、上記ＳＳは、上記データレートが変更される前までは同一のリソースを継続して割り当てることを要請する帯域幅要請情報を一緒に伝送する。
【発明の効果】
【００２８】
以上で説明したように、本発明では、リアルタイムで変化するアップリンクレートを勘案してアップリンクリソースを割り当てることができるため、最適のアップリンクスケジューリングが行われ、その結果、次のような効果が得られる。
【００２９】
第一に、データ伝送効率を極大化することができ、またＳＳのオーバーヘッドを減らすことにより、リソースの無駄使いを防止することができる。
【００３０】
第二に、ＳＳの変更されるアップリンクレートをリアルタイムで反映してリソースを割り当てることにより、余剰リソースを他の用途にて活用することができる。
【００３１】
第三に、ＳＳが、アップリンクレートの減少により発生する余剰リソースを用いてレートの変更をＢＳに知らせることにより、さらなるオーバーヘッドが発生しない。
【００３２】
第四に、ＳＳによって周期的に行われたリソース割り当て要請を減らすことができるため、ＶｏＩＰサービスのために不要に消費されていたアップリンクリソースを減らすことができる。
【発明を実施するための最良の形態】
【００３３】
以下、添付した図面に基づき、本発明に係る好適な実施の形態を詳細に説明する。本発明を説明するに当たって、関連する公知の機能あるいは構成についての詳細な説明が本発明の要旨を余計に曖昧にすると認められる場合、その詳細な説明を省く。
【００３４】
後述する本発明では、ＳＳからのリソース割り当て要請によってリソースが割り当てられ、上記ＳＳによって使われるリソースが変更される前まで、ポーリング過程なしに上記割り当てられたリソースを用いてデータパケットを伝送する。なお、上記ＳＳは、別途のポーリング過程がなくても、継続して同一のリソースの割り当てを上記ＢＳに要求しなければならない。このために、本発明では、帯域幅要請ヘッダーの帯域幅要請フィールドに予め約束された特定のパターンを書き込んで伝送する。上記特定のパターンとしては、上記帯域幅要請フィールドを構成するすべてのビットが１に設定されたビットパターンを使うことを提案する。
【００３５】
そして、上記ＳＳは、データレートの減少が要求されると、該減少されたデータレートにてデータパケットを伝送する。その時、上記ＳＳは、データレートの減少によって使うリソースが変更されたことを知らせる情報をＢＳに伝送する。それにより、上記ＢＳは、上記ＳＳから発生する余剰リソースを他の用途にて使うことができるようになる。
【００３６】
本発明において、上記ＳＳは、次の二つの手法でデータレートが変更されたことを上記ＢＳに知らせることができる。
【００３７】
その第一の手法は、既存のグラント管理サブヘッダーフォーマット（Ｇｒａｎｔ  Ｍａｎａｇｅｍｅｎｔ  ｓｕｂｈｅａｄｅｒ  ｆｏｒｍａｔ）に状態識別子（ＳＴＩ：ＳｔａＴｕｓ  Ｉｎｄｉｃａｔｏｒ）フィールドを追加することである。この手法を適用するためには、追加されたＳＴＩフィールドに関して、データレートが変更されたことを示すビット値が定義される必要がある。例えば、データレートが変更される場合は、ビット値として１を設定し、データレートが同じである場合は、ビット値として０を設定する。そして、上記ＳＴＩフィールドに割り当てられる１ビットは、既存の上記グラント管理サブヘッダーを構成するＰＢＲ（Ｐｉｇｇｙ  Ｂａｃｋ  Ｒｅｑｕｅｓｔ）フィールドの１６ビットから１ビットを借りて使う。したがって、ＳＴＩフィールドを追加すれば、グラント管理サブヘッダーのＰＢＲフィールドは、１５ビットだけから構成される。上記第一の手法によって実現する時における、グラント管理サブヘッダーフォーマットは、次の表１に示すように提案できる。
【００３８】
【表１】
2008510422.tif 000003
【００３９】
次の表２は、上記表１で示しているフィールドのうち本発明の実施の形態のために使われるフィールドについて定義している。
【００４０】
【表２】
2008510422.tif 000004
【００４１】
上記表２において、ＰＢＲフィールドは、１ビットが割り当てられるＳＴＩビットの使用有無によって、そのビット数が決められる。上記ＳＴＩビットが使われる場合は、上記ＰＢＲフィールドは１５ビットから構成される。しかし、上記ＳＴＩビットが使われない場合は、上記ＰＢＲフィールドは１６ビットから構成される。上記ＳＴＩビットは、データレートの変更有無を指示する。上記ＳＴＩビットが０であると、データレートの変更がないことを指示する。上記ＳＴＩビットが１であると、データレートの変更を指示する。
【００４２】
その第二の手法は、既存のグラント管理サブヘッダーフォーマットに存在するＰＢＲフィールドを用いることである。この手法を適用するためには、データレートが変更されたことを知らせるために、上記ＰＢＲフィールドに設定する特定のビットパターンが定義されなければならない。このビットパターンは、既に他の用途にて使われていたビットパターンとは異なる。例えば、データレートの変更を示すために、上記ＰＢＲフィールドを構成する１６ビットをすべて０と設定する。次の表３では、上記第二の手法によって実現される時における、グラント管理サブヘッダーフォーマットでの各フィールドについての定義を示している。
【００４３】
【表３】
2008510422.tif 000005
【００４４】
「Ａ．スケジューリング過程」
以下、本発明で提案されたアップリンクスケジューリング過程を具体的に説明する。
【００４５】
図３は、本発明の実施の形態によるアップリンクスケジューリング過程を示す図である。図３を参照すれば、端末状態は、時間軸上でオン区間とオフ区間とに大きく分けられる。上記オン区間は、伝送データパケットが存在する区間であり、上記オフ区間は、伝送データパケットが存在しない区間である。
【００４６】
ＳＳは、参照符号３１０で示すように、上記オフ区間から上記オン区間に切り替えられると、ＢＳにリソース割り当てを要請する。上記リソース割り当て要請は、予め割り当てられた最小リソースを使って伝送する。一例として、上記ＳＳは、リソース割り当てを要請するために帯域幅要請ヘッダーを使う。上記帯域幅要請ヘッダーを通じては、別途のポーリング過程がなくても継続して同一のリソースの割り当てを要求する帯域幅要請情報が伝送される。
【００４７】
次の表４では、上記帯域幅要請ヘッダーを構成するフィールドと各フィールドの長さ及び特徴について説明している。
【００４８】
【表４】
2008510422.tif 000006
【００４９】
上記帯域幅要請情報は、上記表４で示しているフィールドのうち帯域幅要請（ＢＲ：Ｂａｎｄｗｉｄｔｈ  Ｒｅｑｕｅｓｔ）フィールドを通じて伝送される。上記表４において、上記帯域幅要請情報を、１９ビットがすべて１と設定されているビット列として定義している。
【００５０】
上記ＢＳは、上記帯域幅要請ヘッダーを受信すれば、最大データレートにてデータを伝送するのに必要なリソースを周期的に上記ＳＳに割り当てる。これに対応して、上記ＳＳは、参照符号３１２で示すように、上記割り当てられたリソースを使ってデータを伝送する。上記データ伝送は、最大データレート（レート  １）にて行われる。
【００５１】
しかしながら、上記リソース割り当て要請によって最初に割り当てられたリソースを使って行われるデータ伝送は周期的ではない。すなわち、上記リソース割り当てが要請された時点から上記周期によりデータが最初に伝送される時点の間で上記最初に割り当てられたリソースを使ってのデータ伝送が行われる。
【００５２】
上記ＳＳは、最大データレートにて周期的にデータを伝送する状況でデータレートの変更が要請されると、次の伝送周期で上記変更されたデータレートにてデータを伝送する。上記変更されたデータレートは、以前に使っていたデータレートに比べて相対的に低いデータレートである。図３では、Ｒａｔｅ  １からＲａｔｅ  １／２に変更される例を示している。なお、上記ＳＳは、データレートが変更されたことを上記ＢＳに知らせるための識別情報を伝送する。上記識別情報は、上記データレートを下げることにより発生する余剰リソースを使って伝送する。上記識別情報をグラント管理サブヘッダーを使って上記ＢＳに伝送するための具体的な手法は、上述したとおりである。その後、上記ＳＳは、参照符号３１４で示すように、上記変更されたデータレートにて周期的なデータ伝送を行う。
【００５３】
上記ＢＳは、グラント管理サブヘッダーを通じて上記識別情報を受信すれば、上記Ｒａｔｅ  １／２を支援するのに必要な最小のリソースを上記ＳＳに割り当てる。上記データレートの変更に伴うリソース割り当ては、必要に応じて行われる。すなわち、現在割り当て可能なリソースが十分であるとすれば、上記ＢＳは、上記ＳＳから割り当てられたリソースをリアルタイムで回収する必要はない。
【００５４】
上記ＳＳは、Ｒａｔｅ  １／２にて周期的にデータを伝送する状況でデータレートの変更が要請されると、次の伝送周期で上記変更されたデータレートであるＲａｔｅ  １／４にてデータを伝送する。なお、上記ＳＳは、データレートが変更されたことを知らせるための識別情報を上記ＢＳに伝送する。その後、上記ＳＳは、参照符号３１６で示すように、上記変更されたデータレートであるＲａｔｅ  １／４にて周期的なデータ伝送を行う。グラント管理サブヘッダーを通じて上記識別情報を受信すれば、上記ＢＳは、上記Ｒａｔｅ  １／４を支援するのに必要な最小のリソースを上記ＳＳに割り当てる。
【００５５】
Ｒａｔｅ  １／４にて周期的にデータを伝送する状況でデータレートの変更が要請されるかまたは伝送データが存在しない場合、次の伝送周期で使うデータレートをＲａｔｅ  １／８に変更する。上記Ｒａｔｅ  １／８は、本発明においてＳＳに割り当てることができる最低データレートであると仮定されている。そして上記ＳＳは、データレートが変更されたことを知らせるための識別情報を上記ＢＳに伝送する。その後、上記ＳＳは、通常のオフ区間３１８での動作を行う。
【００５６】
「Ｂ．シグナリング」
以下、本発明で提案されたアップリンクスケジューリング過程によるＳＳとＢＳ間におけるシグナリングについて、図４を参照して具体的に説明する。
【００５７】
図４を参照すれば、ステップＳ４１０において、上記ＢＳは、上記ＳＳよりリソース割り当てを要請するのに必要な最小リソースを割り当てる。通常、ＳＳよりリソース割り当てを要請するためには、１６バイトの情報が伝送可能なリソースであれば十分である。上記リソース割り当て要請は、Ｒａｔｅ  １／８にて伝送されると推測されるため、リソース割り当て要請のためには、最小限の必須リソースとしてＲａｔｅ  １／８が提供される。
【００５８】
伝送データが存在すれば、上記ＳＳは、先ずＢＳから割り当てられた最小リソースを使ってデータ伝送のためのリソース割り当てを要請する帯域幅要請ヘッダーを上記ＢＳに伝送する（ステップＳ４１２）。この時、オン区間が、上記帯域幅要請ヘッダーの伝送と共に始まる。本発明によるアップリンクスケジューリングの適用を上記帯域幅要請ヘッダーを通じて知らせる必要がある。すなわち、データレートが変更されるまでは、追加のリソース割り当て要請をしないことを知らせる情報が、上記帯域幅要請ヘッダーを通じて提供される。一例として、上記帯域幅要請ヘッダーのＢＲフィールドがすべて１に設定されている。
【００５９】
上記帯域幅要請ヘッダーを受信すれば、上記ＢＳは、上記ＳＳが最大データレート（Ｒａｔｅ  １）にてデータパケットを伝送できるリソースを割り当てる（ステップＳ４１４）。上記ＳＳは、上記割り当てられたリソースを使って最大データレートにてデータパケットを伝送する（ステップＳ４１６）。リソース割り当てステップＳ４１４とデータ伝送ステップＳ４１６は、上記データレートが変更されるまで繰り返し行われる。
【００６０】
ステップＳ４１８において、上記ＳＳは、既に使っていた最大データレートを支援するためのリソースを上記ＢＳから割り当てられる。しかし、この時点で上記ＳＳが使うデータレートがＲａｔｅ  １／２に変更されると、上記ＳＳは、ステップＳ４２０において変更されたデータレートであるＲａｔｅ  １／２にてデータパケットを伝送する。そして、上記ＳＳは、自分が使われていたデータレートがＲａｔｅ  １からＲａｔｅ  １／２に変更されたことを知らせるためのグラント管理サブヘッダーを上記ＢＳに伝送する。上記データレートの変更が上記グラント管理サブヘッダーによって常に指示されるわけではない。すなわち、上記ＳＳは、上記グラント管理サブヘッダーを通じてデータレートの変更のみを知らせることにより、上記ＢＳは、以前に使っていたデータレートに比べて一レベル低いデータレートに変更されたことが分かる。データレートの変更は、様々な手法にて上記グラント管理サブヘッダーを用いて知らせることができる。本発明では、代表的な例として、グラント管理サブヘッダーにＳＴＩフィールドを追加する手法と、グラント管理サブヘッダーを構成するＰＢＲフィールドを用いる手法を提案する。これらの手法は、上述したとおりであって、ここでは再度説明しないことにする。
【００６１】
上記ＢＳは、上記グラント管理サブヘッダーから上記ＳＳのデータレートが変更されたことを確認する。ステップＳ４２２において、上記ＢＳは、変更されたデータレートであるＲａｔｅ  １／２を支援するのに必要なリソースを割り当てる。これにより上記ＢＳでは、Ｒａｔｅ  １／２を支援することができる余剰リソースが発生するようになるので、それを他の用途にて使うことができるようになる。一方、上記ステップＳ４２２におけるリソース割り当ては、上記グラント管理サブヘッダーを受信した直後に行われなくてもよい。上記ＢＳは、割り当て可能なリソースに余裕がある場合、既に割り当てられたリソースを上記ＳＳが継続して使うことを許容する。そして、余剰リソースの必要な状況が発生すると、その時点で上記ＢＳは、上記ＳＳに対してリソースの再割り当てを行う。したがって、上記ステップＳ４２０と上記ステップＳ４２２との間では、上記ＳＳは、既に割り当てられたリソースを用いて上記ＢＳにデータパケットを継続して伝送する。とりわけ、上記ステップＳ４２０と上記ステップＳ４２２におけるデータパケットの伝送時には、上記ＳＳによって使われない余剰リソースが発生する。しかしながら、上記ＢＳがＲａｔｅ  １／２を支援するのに必要なリソースを割り当てた後のステップＳ４２４では、データ伝送から余剰リソースは発生しない。
【００６２】
ステップＳ４２６において、上記アップリンクレートがＲａｔｅ  １／２を支援するためのリソースからＲａｔｅ  １／４に変更された場合、上記ＳＳは、ステップＳ４２８において、該変更されたデータレートであるＲａｔｅ  １／４にてデータパケットを伝送する。上記ＳＳは、ＢＳにグラント管理サブヘッダーを伝送して、上記データレートがＲａｔｅ  １／２からＲａｔｅ  １／４に変更されたことを知らせる。
【００６３】
上記ＢＳは、上記グラント管理サブヘッダーから上記アップリンクデータが変更されたことを確認する。ステップＳ４３０において、上記ＢＳは、Ｒａｔｅ  １／４を支援するのに必要なリソースを割り当てる。これにより上記ＢＳでは、Ｒａｔｅ  １／４を支援可能な余剰リソースが発生するようになるので、それを他の用途にて使うことができるようになる。しかしながら、ステップＳ４３０におけるリソース割り当ては、上記グラント管理サブヘッダーを受信した直後に行われなくてもよい。上記ＢＳは、割り当て可能なリソースに余裕がある場合、既に割り当てられたリソースを上記ＳＳが継続して使うことを許容する。そして、余剰リソースの必要な状況が発生すると、その時点で上記ＢＳは、上記ＳＳに対してリソースの再割り当てを行う。したがって、上記ステップＳ４３０が行われる前までは、上記ＳＳは、既に割り当てられたリソースを用いて上記ＢＳにデータパケットを継続して伝送する。この場合、上記ＳＳによって使われない余剰リソースが発生する。しかしながら、上記ＢＳは、ステップＳ４３２において上記ＢＳにより再割り当てが行われたリソースを用いてデータパケットを伝送することにより、該データ伝送からは余剰リソースは発生しない。
【００６４】
上記ＢＳは、ステップＳ４３４においてＲａｔｅ  １／４を支援するためのリソースを割り当てる。この時点で上記アップリンクレートがＲａｔｅ  １／８に変更される。上記Ｒａｔｅ  １／８は、上記ＳＳが支援可能な最小レートである。本発明では、上記Ｒａｔｅ  １／８が使われる区間をオフ区間と定義している。したがって、上記レートがＲａｔｅ  １／８に変更される時点が、上記オフ区間の開始時点となる。上記ＳＳは、上記オフ区間において割り当てられたリソースを使ってデータを伝送するか、またはリソース割り当てを要請することができる。図４では、上記ＳＳがステップＳ４４４においてリソース割り当てを要請する前までは、上記ＳＳは、Ｒａｔｅ  １／８にてデータを伝送することを示している。
【００６５】
ステップＳ４３６において、上記ＳＳは、Ｒａｔｅ  １／８にて、データパケット及び上記レートがＲａｔｅ  １／４からＲａｔｅ  １／８に変更されたことを知らせるためのグラント管理サブヘッダーを伝送する。上記ステップＳ４３６においては、伝送するデータパケットが存在しない場合、データパケットの伝送が行われない。
【００６６】
上記ＢＳは、上記グラント管理サブヘッダーから上記アップリンクレートが変更されたことを確認する。ステップＳ４３８において、上記ＢＳは、Ｒａｔｅ  １／８を支援するのに必要なリソースを割り当てる。上記ＳＳは、ステップＳ４４０ないし４４２において、Ｒａｔｅ  １／８にてデータパケットを伝送する。
【００６７】
上記ＢＳは、ステップＳ４３４においてＲａｔｅ  １／８を支援するためのリソースを割り当てる。この時点で、増大したレートにて伝送する伝送データが、上記ＳＳにおいて発生したと仮定する。したがって、上記時点は、オン区間の開始時点になる。
【００６８】
ステップＳ４４４において、上記ＳＳは、Ｒａｔｅ  １／８を支援するのに必要な割り当てられた最小リソースを用いて帯域幅要請ヘッダーを上記ＢＳに伝送する。上記帯域幅要請ヘッダーは、データレートが変更されるまでは追加のリソース割り当て要請をしないことを知らせる情報を運ぶ。
【００６９】
上記帯域幅要請ヘッダーを受信すれば、上記ＢＳは、ステップＳ４４６において、上記ＳＳが最大データレートであるＲａｔｅ  １にてデータパケットを伝送できるのに必要なリソースを割り当てる。その後、上記ＳＳは、ステップＳ４４８において、上記割り当てられたリソースを用いてＲａｔｅ  １にてデータパケットを伝送する。
【００７０】
「Ｃ．ＳＳにおける動作」
図５は、本発明の実施の形態によるアップリンクスケジューリングのためのＳＳの動作を示すフローチャートである。図５を参照すれば、上記ＳＳは、ステップＳ５１０において、ＶｏＩＰによって伝送するデータの存在有無を確認する。伝送データが存在すれば、上記ＳＳは、ステップＳ５１２においてＢＳにリソース割り当てを要請する。上記リソース割り当て要請は、帯域幅要請ヘッダーの伝送によって行われる。このとき、上記帯域幅要請ヘッダーは、データレートが変更されるまでには追加のリソース割り当て要請をしないことを知らせる情報を運ぶ。一例として、上記ＳＳは、上記帯域幅要請ヘッダーの帯域幅要請フィールドを構成する１９ビットをすべて１と設定することができる。なお、上記ＳＳは、上記帯域幅要請ヘッダーを伝送するのに必要なリソースを予めＢＳから割り当てられることができる。
【００７１】
上記ＢＳからリソース割り当てが行われた後、上記ＳＳは、ステップＳ５１４において、上記割り当てられたリソースを用いてデータを伝送する。上記割り当てられたリソースは、通常上記ＳＳで使用可能な最大データレート（一例として、Ｒａｔｅ  １）を支援する。
【００７２】
上記ＳＳは、ステップＳ５１６において、伝送するデータパケットの存在有無を持続的にモニタする。データパケットが存在すれば、上記ＳＳは、ステップＳ５１８において、現在割り当てられたリソースが上記データの伝送のための量を超えているかどうか、すなわち現在のレートを下げる必要があるかどうかをを判定する。レートの減少が要求される場合、上記ＳＳは、ステップＳ５２２において、減少されたリソース、すなわち減少されたレート（Ｒａｔｅ  １／２）にてデータを伝送する。同時に上記ＳＳは、上記ＢＳにレートの減少、すなわちレート変更を知らせる。前述したように、上記リソースの減少は、グラント管理サブヘッダーのＰＢＲフィールドまたは新たなＳＴＩビットにより知らせる。その後、上記ＳＳは、ステップＳ５１４へ進み、上記変更されたレートにてデータパケットを伝送する。
【００７３】
上記ステップＳ５１８において現在のレートを下げる必要がないと判定された場合、その後、ステップＳ５２０において、上記ＳＳは、多量のリソースが要求されているかどうかを判定する。もし、リソースの増大が要求される場合、上記ＳＳは、ステップＳ５１２においてリソース割り当てを要請する。その後、上記ＳＳは、最大データレート（Ｒａｔｅ  １）にてデータパケットを伝送する。
【００７４】
なお、図５では示していないが、上記ＳＳが、データフレーム毎の伝送のためにリソース割り当てを要請しなくても、上記ＢＳは上記ＳＳに所定量のリソースを割り当てる。
【００７５】
「Ｄ．ＢＳにおける動作」
図６は、本発明の実施の形態によるアップリンクスケジューリングのためのＢＳの動作を示すフローチャートである。図６を参照すれば、上記ＢＳは、ステップＳ６１０において上記ＳＳからのリソース割り当て要請の受信有無をモニタする。一例として、上記リソース割り当て要請は、帯域幅要請ヘッダーの受信によって行われる。上記帯域幅要請ヘッダーを受信すれば、上記ＢＳは、上記帯域幅要請ヘッダーのＢＲフィールドに設定された値をチェックする。もし、上記設定された値が本発明により提案されたアップリンクスケジューリングを要求する値（すべてのビット値が１と設定された場合）である場合、上記ＢＳは、本発明によるアップリンクスケジューリング手法によってアップリンクリソースを割り当てる。そうでない場合は、通常のアップリンクスケジューリング技法が適用される。上記通常のアップリンクスケジューリング技法が適用されることは自明な事項なので、具体的な説明は省くことにする。
【００７６】
上記ＢＳは、ステップＳ６１２において上記ＳＳが使用可能な最大データレートを支援するのに必要なリソースを割り当てた後、ステップＳ６１４に進み、上記ＳＳから割り当てられたリソースを用いて伝送したデータを受信する。上記ＢＳは、ステップＳ６１６において、上記ＳＳからのリソース減少要請の受信有無をモニタする。上記ＢＳが上記リソース減少要請を受信した場合、上記ＢＳは、ステップＳ６２０において、上記リソース減少要請によって指示された量でリソースを割り当てる。上記ＢＳが上記リソース減少要請を受信していない場合、上記ＢＳは、ステップＳ６１８において、リソース割り当て要請の受信有無を判定する。上記リソース割り当て要請を受信した場合、上記ＢＳは、上記ＳＳのために使用可能な最大のリソース量を割り当てる。
【００７７】
ステップＳ６１６において、リソース減少要請を受信した場合、上記ＢＳは、ステップＳ６２０において、上記リソースの減少、すなわち上記ＳＳに対して、低いデータレートを支援するためのリソースを割り当て、ステップＳ６１４に戻る。上記ＢＳは、上記ＳＳによって変更された量のリソースでデータを受信する。
【００７８】
他方、上記ＢＳが上記リソース割り当て要請を受信すると、上記ＢＳは、ステップＳ６１２において、最大データレートの支援が可能なリソースを割り当てる。図６では示していないが、上記ＢＳは、データフレーム毎に要求されるリソースを割り当てる。
【図面の簡単な説明】
【００７９】
【図１】従来のＵＧＳによるアップリンクスケジューリング過程を示すグラフである。
【図２】従来のｒｔＰＳによるアップリンクリスケジューリング過程を示すグラフである。
【図３】本発明の実施の形態によるアップリンクスケジューリング過程を示すグラフである。
【図４】本発明の実施の形態によるアップリンクスケジューリングのための端末と基地局間におけるシグナリングを示す図である。
【図５】本発明の実施の形態によるアップリンクスケジューリングのための端末の動作を示すフローチャートである。
【図６】本発明の実施の形態によるアップリンクスケジューリングのための基地局の動作を示すフローチャートである。
【図１】
2008510422.tif 000007
【図２】
2008510422.tif 000008
【図３】
2008510422.tif 000009
【図４】
2008510422.tif 000010
【図５】
2008510422.tif 000011
【図６】
2008510422.tif 000012
【国際調査報告】
2008510422.tif 000013
2008510422.tif 000014