(57)【特許請求の範囲】
【請求項１】
リソース要求装置によってリソース割当装置にリソースを要求する方法であって、
前記リソース要求装置から前記リソース割当装置にリソース要求メッセージを送信するステップと、
前記リソース要求メッセージの受信の後に、リソースを前記リソース要求装置に対してセットされた時間間隔内に割り当てることができないときには、前記リソース割当装置から前記リソース要求装置に前記リソース要求メッセージに対するＵＬ許可による肯定応答を送信するステップとを含み、前記リソース割当装置によって送信される前記ＵＬ許可内のリソースのサイズを示す値は、０になるようにセットされ、さらに、
前記リソースが前記セットされた時間間隔内に前記リソース要求装置に割り当てられるときには、前記リソース割当装置から前記リソース要求装置に前記リソース要求メッセージの前記肯定応答を送信しないステップとを含む方法。
【請求項２】
前記リソース要求装置が、前記セットされた時間間隔内に前記リソース要求装置に前記リソース割当装置によって送信された前記リソース要求メッセージの前記肯定応答を受信するときには、前記リソース要求装置は、前記リソース割当装置からのリソース割当を待つ、請求項１に記載の方法。
【請求項３】
前記リソース要求装置が、前記セットされた時間間隔内に前記リソース要求装置に前記リソース割当装置によって送信された有効なリソース割当または前記リソース要求メッセージの前記肯定応答を受信しないときには、前記リソース要求装置は、リソースの要求の再送信を開始する、請求項１に記載の方法。
【請求項４】
前記リソース要求装置は、ＵＬ許可内のリソースのサイズを示す値が０であるかどうかを検出し、前記リソース要求装置は、リソースの前記サイズを示す前記値が０であるときには、前記リソース割当装置からのリソース割当を待つ、請求項２に記載の方法。
【請求項５】
リソース要求装置からリソース要求メッセージを受信する送受信ユニットと、
前記送受信ユニットが前記リソース要求メッセージを受信した後のセットされた時間間隔内に前記リソース要求装置にリソースを割り当てるべきかどうかを判断するリソース・スケジューリングおよび割当ユニットと、
リソースを前記セットされた時間間隔内に前記リソース要求装置に割り当てることができないときには、前記リソース要求メッセージをＵＬ許可によって肯定応答するメッセージを生成する肯定応答メッセージ生成ユニットとを含み、
前記リソース要求メッセージを肯定応答する前記メッセージは、前記送受信ユニットを介して前記リソース要求装置に送信され、前記ＵＬ許可内のリソースのサイズを示す値は、前記リソースを前記セットされた時間間隔内に前記リソース要求装置に割り当てることができないときには、０になるようにセットされる、リソース割当装置。
【請求項６】
リソース要求装置であって、
リソース要求メッセージを送信し、リソース割当装置からメッセージを受信する送受信ユニットと、
前記受信されたメッセージが所定の条件を満足するかどうかを検出する検出ユニットとを含み、前記検出ユニットが、ＵＬ許可内のリソースのサイズを示す値が０であるかどうかを検出し、
前記リソース要求装置は、リソースの前記サイズを示す前記値が０であるときには、前記リソース割当装置からのリソース割当結果を待つ、リソース要求装置。
【請求項７】
前記リソース要求装置が、セットされた時間間隔内に前記リソース要求装置に前記リソース割当装置によって送信された前記リソース要求メッセージの前記肯定応答を受信するときには、前記リソース要求装置は、前記リソース割当装置からのリソース割当を待つ、請求項６に記載のリソース要求装置。
【請求項８】
前記リソース要求装置が、前記セットされた時間間隔内に前記リソース要求装置に前記リソース割当装置によって送信された有効なリソース割当または前記リソース要求メッセージの前記肯定応答を受信しないときには、前記リソース要求装置は、リソースの要求の再送信を開始する、請求項６に記載のリソース要求装置。
【請求項９】
前記リソースは少なくとも帯域幅を含む、請求項６に記載のリソース要求装置。
【請求項１０】
請求項５に記載のリソース割当装置および請求項６に記載のリソース要求装置を含む通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動体通信に関し、具体的には、リソース割当装置がリソース要求装置からリソース（帯域幅）要求を受信し、リソースをタイムリーに割り当てることができないときにリソース割当装置が帯域幅要求について肯定応答することを可能にする、リソースを要求する方法、装置、および通信システムに関する。
【背景技術】
【０００２】
ＩＥＥＥ８０２．１６ｅでは、ＵＧＳ（アンソリシティド・グラント・サービス（ｕｎｓｏｌｉｃｉｔｅｄ  ｇｒａｎｔ  ｓｅｒｖｉｃｅ））接続を除くすべてのアップリンク・サービスが、基地局ＢＳに帯域幅を要求することを必要とする。移動局ＭＳのバッファ内のデータがアップリンク送信を待っている時には、ＭＳは、上記の帯域幅要求を行う。帯域幅要求は、ＭＳが対応するアップリンク送信を進めるためにどれほど大きい帯域幅を必要とするのかをＭＳがＢＳに示す機構を指す。ＭＳの帯域幅要求は、ＭＡＣ（媒体アクセス制御）ＰＤＵ（プロトコル・データ・ユニット）によって搬送されるバイト数を考慮に入れる必要がある。ＢＳが、ＭＳから帯域幅要求を受信する時に、ＢＳは、ＭＳにリソースを割り当てるために、使用可能なリソースおよびスケジューリング方式を考慮する。ＭＳが、期待されるものより少ない送信機会を受け取るか、ＢＳからＵＬ許可を受信できないことがありえる。これは、スケジューリング判断、不十分なリソース、または要求メッセージの消失などの問題によって引き起こされる可能性がある。ＭＳの要求と一致するリソースを割り当てることの失敗に関して、ＢＳは、明確な理由を提供しない。
【０００３】
図７に、ＩＥＥＥ  ８０２．１６ｅで提供される帯域幅要求／許可手順を示す。ステップＳ７０１では、ＭＳは、帯域幅を要求する必要が生じた後に、ＣＤＭＡレンジング・コード（ｒａｎｇｉｎｇ  ｃｏｄｅ）を選択し、コンペティション（ｃｏｍｐｅｔｉｔｉｏｎ）のためのレンジング・スロット内でそのＣＤＭＡレンジング・コードをＢＳに供給する。ステップＳ７０２では、ＣＤＭＡレンジング・コードが検出された後に、ＢＳは、ＣＤＭＡ＿ＩＥ  ＵＬ割当情報をＭＳに供給する。
【０００４】
ステップＳ７０３では、ＭＳは、割り当てられたリソース内で、帯域幅要求メッセージをＢＳに送信する。その後、ＢＳは、ステップＳ７０４でＵＬ許可を応答して、ＭＳによって要求された帯域幅リソースを割り当てなければならない。ＢＳが、上記のＵＬ割当情報を送信しない場合、または帯域幅要求が、指定された時間間隔内の後続ステップで対応する帯域幅をＢＳに割り当てさせない場合には、ＭＳは、帯域幅要求が失敗すると仮定し、帯域幅要求をもう一度ファイルしたか、対応するＳＤＵを破棄する。
【０００５】
ＭＳが帯域幅要求を送信した後に、ＭＳは、ＢＳから帯域幅割当（ＵＬ許可）を受信すると期待する。しかし、いくつかの場合に、ＭＳは、期待された帯域幅割当を入手しない場合がある。１つの理由は、いくつかの悪いネットワーク環境で、帯域幅要求情報が破棄されるか、破壊される可能性があることである。図８に示されているように、送信された帯域幅要求メッセージが失われた後に、ＭＳは、ＭＳのタイマがオーバーフローしない限り、ＣＤＭＡコンペティションをもう一度送信することができない。したがって、ＢＳは、ＭＳによって送信された帯域幅要求メッセージを正しく受信することができない。これは、ＭＳによって望まれたＵＬ許可メッセージをＭＳに送信することの失敗を引き起こす。もう１つの理由は、スケジューリング判断に関連する。ＢＳが、使用可能なリソースがすべての帯域幅要求を満足することはできないと考える場合に、ＢＳは、いくつかの特定のＭＳへの帯域幅割当を遅延させると判断し、たとえば、これらのＭＳに後続フレームで帯域幅を割り当てる可能性が高い。したがって、ＢＳは、まず、いくつかの時間にクリティカルなサービスの需要を満足することができる。ＭＳが、対応する帯域幅割当を入手しない場合であっても、ＢＳは、明確な説明をＭＳに与えない。ＭＳは、タイマがオーバーフローするかどうかを判断することによって、帯域幅要求の無効を検出する。タイマによってセットされる待ち時間が、既に経過しており、ＭＳが、所望の帯域幅割当を受け取らない場合には、ＭＳは、新しいＣＤＭＡコンペティションを再開始する。
【０００６】
帯域幅要求メッセージが失われる場合に、ＭＳは、帯域幅割当要求を再送信するために、不必要な期間（たとえば、タイマがオーバーフローするまでの期間）だけ待たなければならない。これは、帯域幅要求の待ち時間を増やす。待ち時間が、比較的短くなるように構成される場合には、ＢＳがオリジナル要求を正しく入手する場合であっても、ＭＳは、ＢＳがＭＳへのＵＬ許可をスケジューリングし始める前にタイマがオーバーフローする可能性があるので、帯域幅要求メッセージを再送信する可能性がある。これは、不必要なオーバーヘッドを引き起こし、図９に示されているように、ＢＳがそれを新しい要求と誤って見なすことを引き起こす。この問題の理由は、帯域幅要求メッセージを受信するＢＳが、そのメッセージの受信を肯定応答しないことである。
【０００７】
ＩＥＥＥ  ８０２．１６ｍワーク・グループは、エア・インターフェースの許可されたチャネルでの動作性能を向上させるために、既にＩＥＥＥ  ８０２．１６標準規格を修正し始めている。要求される文書によれば、これは、帯域幅要求に関するより厳密な要件すなわち、より短い待ち時間およびより少ないオーバーヘッドを提案するものである。したがって、上の問題に対する解決策が、より重要になる。
【０００８】
ＩＥＥＥ  ８０２．１６の第５６回会合（２００８年７月）で、Ｉｎｔｅｌ  Ｃｏｒｐｏｒａｔｉｏｎ社は、できる限り早くランダム・アクセスの再開始を可能にするために、ＢＳが帯域幅要求メッセージを受信するかどうかをＭＳが明確に肯定応答することを可能にする解決策（非特許文献１：ＩＥＥＥ  Ｃ８０２１６ｍ−０８＿６３５，ＢＷ−ＲＥＱ  ｃｈａｎｎｅｌ  ｄｅｓｉｇｎ  ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ  ｆｏｒ  ＩＥＥＥ  ８０２．１６ｍ、Ｉｎｔｅｌ  Ｃｏｒｐｏｒａｔｉｏｎ、２００８年７月１３日）を提案する。
【０００９】
図１０に示されているように、ステップＳ１００１では、ＭＳのバッファが送信されるべきデータを有する時に、ＭＳは、ＣＤＭＡコンペティションのために対応するレンジング・コードを選択する。次に、ＢＳが、ＭＳからＣＤＭＡコンペティションを受信した後に、ＢＳは、対応するＣＤＭＡ＿ＩＥ割当を実行する、すなわち、いつまたはどのリソースでＭＳがリソース要求メッセージを送信すべきなのかをＭＳが知ることを可能にする。
【００１０】
その後、ステップＳ１００３で、ＭＳは、対応する瞬間にまたは対応するリソースで、リソース要求メッセージを送信する。ステップＳ１００４では、ＢＳがＭＳからリソース要求メッセージを受信した後に、ＢＳは、明確な肯定応答を行う。その後、ステップＳ１００５では、リソースが、要求されたリソースをＭＳに割り当て、これをＵＬ許可情報を介してＭＳに送信するために、ＢＳの側でスケジューリングされる。ステップＳ１００６では、ＭＳがＢＳによって割り当てられたリソースを受信した後に、ＭＳは、そのリソース上で、バッファ内の送信すべきデータをＢＳに送信する。
【００１１】
ＩＥＥＥ  ８０２．１６ｅの手順と比較して、上の非特許文献１の解決策は、帯域幅要求を肯定応答するステップ（図１０のステップＳ１００４）を追加する。ＢＳが、ＭＳから帯域幅要求メッセージを受信した後に、ＢＳは、その要求に関する肯定応答メッセージを明確に提供する。これは、ＭＳが、不成功な帯域幅要求からできる限り早く復元するためにランダム・アクセス手順をすばやく再開始することを可能にする。ＭＳに関して、ＭＳは、次のフレームで肯定応答メッセージＡＣＫを受信すべきであることを知り、この肯定応答メッセージＡＣＫは、ＢＳが帯域幅要求メッセージを既に成功して受信したことを示す。ＭＳが、ＢＳから所望の肯定応答メッセージを受信しない場合には、ＭＳは、前に送信された要求が失われたことを知る。その後、ＭＳは、帯域幅要求メッセージを再送信し、これによって、不必要な待ち時間（すなわち、タイマがオーバーフローするまでの期間）を実質的に減らす。
【００１２】
上の解決策は、ＭＳの側での不必要な待ち時間を除去するが、それでも、短所すなわちオーバーヘッドの増加を有する。各ＭＳ要求に関して、ＢＳは、ＡＣＫ応答を行うためにあるリソースを提供しなければならず、このリソースは、少なくとも、ＭＳ識別（ＭＳ  ＩＤ）または接続識別および肯定応答命令を含む。これがあるメッセージによって搬送される場合に、メッセージ送信は、それ自体のフォーマット（ヘッダおよびメッセージ本体）を有する。したがって、ＢＳは、メッセージをどこで受信すべきかについてＭＳに知らせるためにＭＡＰ  ＩＥ内の余分なリソースを割り当てることもしなければならない。しかし、アップリンク帯域幅要求の大多数に関して、ＢＳがＭＳから帯域幅要求を受信する時に、ＢＳは、ＵＬ許可メッセージをＭＳにタイムリーに応答する。ＭＳは、ＵＬ許可をすばやく受信することができる。この場合に、帯域幅要求の肯定応答は、役に立たないものになる。したがって、不必要なオーバーヘッドが引き起こされる。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】ＩＥＥＥ  Ｃ８０２１６ｍ−０８＿６３５，ＢＷ−ＲＥＱ  ｃｈａｎｎｅｌ  ｄｅｓｉｇｎ  ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ  ｆｏｒ  ＩＥＥＥ  ８０２．１６ｍ、Ｉｎｔｅｌ  Ｃｏｒｐｏｒａｔｉｏｎ、２００８年７月１３日
【発明の概要】
【発明が解決しようとする課題】
【００１４】
本発明の目的は、リソース・アロケータが、リソース（帯域幅）要求を移動局から受信し、そのリソースをタイムリーに割り当てることができない時にリソース・アロケータが帯域幅要求について肯定応答することを可能にする、リソースを要求する方法、装置、および通信システムを提供することである。
【課題を解決するための手段】
【００１５】
本発明の第１の態様によれば、リソース要求装置によってリソース割当装置にリソースを要求する方法であって、リソース要求装置からリソース割当装置にリソース要求メッセージを送信するステップと、リソース要求メッセージの受信の後に、リソースをリソース要求装置に対してセットされた時間間隔内に割り当てることができない場合に、リソース割当装置からリソース要求装置にリソース要求メッセージの肯定応答を送信するステップと、リソースがセットされた時間間隔内にリソース要求装置に割り当てられる場合に、リソース割当装置からリソース要求装置にリソース要求メッセージの肯定応答を送信しないステップとを含む方法が提供される。
【００１６】
好ましくは、リソースをリソース要求装置に対してセットされた時間間隔内に割り当てることができない場合に、リソース要求メッセージの肯定応答は、ＵＬ許可によってリソース割当装置からリソース要求装置に送信される。
【００１７】
好ましくは、リソースをセットされた時間間隔内にリソース要求装置に割り当てることができない場合に、リソース割当装置によって送信されるＵＬ許可内のリソースのサイズを示す値は、０になるようにセットされる。
【００１８】
好ましくは、リソース要求装置が、セットされた時間間隔内にリソース要求装置にリソース割当装置によって送信されたリソース要求メッセージの肯定応答を受信する場合に、リソース要求装置は、リソース割当装置からのリソース割当を待つ。
【００１９】
好ましくは、リソース要求装置が、セットされた時間間隔内にリソース要求装置にリソース割当装置によって送信された有効なリソース割当またはリソース要求メッセージの肯定応答を受信しない場合に、リソース要求装置は、リソースの要求の再送信を開始する。
【００２０】
好ましくは、リソース要求装置は、ＵＬ許可内のリソースのサイズを示す値が０であるかどうかを検出し、リソース要求装置は、リソースのサイズを示す値が０である場合に、リソース割当装置からのリソース割当を待つ。
【００２１】
好ましくは、リソースは、少なくとも帯域幅を含む。
【００２２】
本発明の第２の態様によれば、リソース要求装置からリソース要求メッセージを受信する送受信ユニットと、送受信ユニットがリソース要求メッセージを受信した後のセットされた時間間隔内にリソース要求装置にリソースを割り当てるべきかどうかを判断するリソース・スケジューリングおよび割当ユニットと、リソースをセットされた時間間隔内にリソース要求装置に割り当てることができない場合にリソース要求メッセージを肯定応答するメッセージを生成する肯定応答メッセージ生成ユニットとを含み、リソース要求メッセージを肯定応答するメッセージは、送受信ユニットを介してリソース要求装置に送信される、リソース割当装置が提供される。
【００２３】
本発明の第３の態様によれば、リソース要求装置であって、リソース要求メッセージを送信し、リソース割当装置からメッセージを受信する送受信ユニットと、受信されたメッセージが所定の条件を満足するかどうかを検出する検出ユニットとを含み、リソース要求装置は、受信されたメッセージが所定の条件を満足することを検出結果が示すときに、リソース割当装置からのリソース割当結果を待つ、リソース要求装置が提供される。
【００２４】
本発明の第４の態様によれば、前述のリソース割当装置および前述のリソース要求装置を含む通信システムが提供される。
【００２５】
上で述べたように、本発明は、上記の非特許文献１に示された肯定応答方法ではなく、帯域幅要求メッセージの受信の暗黙の肯定応答を使用する。これは、移動局が、帯域幅要求メッセージが失われたことを知ることを可能にし、その結果、移動局ができる限り早く帯域幅要求メッセージを再送信できるようにする。
【００２６】
言い換えると、本発明によって提案される解決策は、帯域幅適用を肯定応答するのにスケジューリング・シグナリングを使用することができる。基地局が、スケジューリング方式のゆえに即座にリソースを割り当てない場合に、その基地局は、それでも、帯域幅を要求する移動局にＵＬ許可を割り当てる。しかし、割り当てられるリソースのサイズは、たとえば０である。特定のＵＬ許可が受信された後に、移動局は、基地局がその帯域幅要求を既に正しく受信したことを知り、唯一のことは、現在割り当てるべき適切なリソースがないことである。したがって、移動局は、冗長な繰り返される要求を回避するために、帯域幅要求メッセージの再送信を試みない。基地局が、リソースを即座に割り当てると判断し、移動局にＵＬ許可応答を送信する場合には、基地局は、余分な肯定応答メッセージを送信する必要なしに通常の動作手順に従ってリソースを割り当て、これによって、オーバーヘッドが減らされる。移動局が、移動局が帯域幅要求を送信した後のセットされた時間間隔内にＵＬ許可（割り当てられた所望のリソースまたは０）を全く受信しない場合には、移動局は、帯域幅要求が失われたことを知る。移動局は、即座に帯域幅要求を再送信し、これによって、不必要な待ち時間（すなわち、タイマがオーバーフローするまでの期間）を実質的に減らす。
【００２７】
本発明の方法および構造を利用することによって、基地局は、必要な場合に限って追加の肯定応答メッセージを送信し、したがって、オーバーヘッドが大幅に減らされる。さらに、本発明の解決策は、基地局と移動局との間で交換されるシグナリングを全く変更しないので、後方互換性の要件を満足することができる。
【００２８】
本発明の実施形態を、添付図面を参照して例示的な形でのみ説明する。
【図面の簡単な説明】
【００２９】
【図１】本発明の実施形態による通信システムを示す全般的な構造図である。
【図２】本発明の実施形態による基地局を示す概略構造ブロック図である。
【図３】本発明の実施形態による移動局を示す概略構造ブロック図である。
【図４】本発明の実施形態による帯域幅要求を肯定応答する手順を示す図である。
【図５】本発明の実施形態による帯域幅要求メッセージが失われるか破壊される時に帯域幅要求メッセージを再送信する手順を示す図である。
【図６】本発明の実施形態による帯域幅要求／許可手順を示す図である。
【図７】ＩＥＥＥ  ８０２．１６ｅで定義された帯域幅要求／許可手順を示す図である。
【図８】帯域幅要求を再送信する前の不必要な待ち時間を示す図である。
【図９】タイマのオーバーフロー時間が基地局のスケジューリング遅延より短い状況を示す図である。
【図１０】非特許文献１による帯域幅要求を肯定応答する手順を示す図である。
【発明を実施するための形態】
【００３０】
本発明の好ましい実施形態を、下で添付図面を参照して詳細に説明する。同一の符号が異なる図面に記されているが、これらは、同一のまたは同様の構成要素を表す。明瞭さおよび簡潔さのために、本明細書に含まれ、本発明の主題に関連しない既知の機能および構造の詳細な説明は、それらが本願発明を不明確にするのを防ぐために省略される。
【００３１】
図１は、本発明の実施形態による通信システムを示す全般的な構造図である。図１に示されているように、通信システムは、基地局ＢＳならびに移動局ＭＳ１およびＭＳ２を含む。当然、複数の基地局および複数の移動局を含む通信システムの構成も存在する。
【００３２】
図２は、本発明の実施形態による基地局の概略構造ブロック図である。図３は、本発明の実施形態による移動局の概略構造ブロック図である。
【００３３】
図２に示されているように、本発明の実施形態による基地局１００は、送受信ユニット１１０、リソース・スケジューリングおよび割当ユニット１２０、肯定応答メッセージ生成ユニット１３０、ならびにバッファ１４０を含む。図３に示されているように、本発明の実施形態による移動局２００は、送受信ユニット２１０、バッファ２２０、および検出ユニット２３０を含む。別の実施形態によれば、移動局は、さらに、タイマ２４０を有する。上の基地局および移動局の特定の構造および動作手順を、特定の例と組み合わせて詳細に説明する。
【００３４】
図４は、本発明の実施形態による帯域幅要求を肯定応答する手順を示す。各有効な帯域幅要求に関して、基地局は、その基地局が既に基地局のリソース・スケジューリングを行ったかどうかにかかわりなくＵＬ許可応答を即座に行う必要がある。ＵＬ許可は、ＯＦＤＭＡ  ＵＬ−ＭＡＰ  ＩＥフォーマットで送信される。ＯＦＤＭＡ  ＵＬ−ＭＡＰ  ＩＥは、ＵＬ帯域幅割当を定義する。帯域幅割当は、ブロック割当（絶対オフセット）またはタイム・スロット内の持続時間（相対的なまたは絶対的なタイム・スロット・オフセット）のいずれかによって指定される。
【００３５】
移動局２００のバッファ２２０が、送信すべきデータを有する時に、移動局の送受信ユニット２１０は、ＣＤＭＡコンペティションのために適切なレンジング・コードを選択する。基地局１００のリソース・スケジューリングおよび割当ユニット１２０は、移動局２００に、対応するＣＤＭＡ＿ＩＥ  ＵＬ割当情報を供給する。割当情報によって指定される位置または瞬間に、ステップＳ４０１で、移動局の送受信ユニット２１０は、データを送信するために基地局にある帯域幅を要求するために、バッファ２２０内のデータの量に従って帯域幅要求を送信する。
【００３６】
本発明の実施形態によれば、移動局２００の帯域幅要求メッセージの受信時に、基地局１００のリソース・スケジューリングおよび割当ユニットは、それが即座に移動局にリソースを割り当てることができるかどうかを判定する。そうではない場合には、ステップＳ４０２で、肯定応答メッセージ生成ユニット１３０が、識別に、移動局に送信されるＵＬ許可メッセージ内の特定のフィールドの値をセットする。１つの方法は、０になるように割り当てられるリソースのサイズをセットし、次に、これを送受信ユニット１１０を介して移動局に送信することである。
【００３７】
次のフレームでは、移動局は、対応するＵＬ許可を受信し、検出ユニット２３０は、ＵＬ許可メッセージ内の特定のフィールドの値の識別を検出し、たとえば、割り当てられたソースのサイズが０であるかどうかを検出する。このサイズが０である場合には、基地局が移動局２００によって送信された帯域幅要求を既に成功して受信済みであることが示される。この場合に、移動局２００は、帯域幅要求メッセージを再送信せずに待ち続ける。
【００３８】
ステップＳ４０３では、リソース・スケジューリングおよび割当ユニット１２０が、移動局２００に割り当てることのできる適切なリソースを有する場合に、リソース・スケジューリングおよび割当ユニット１２０は、ＵＬ許可メッセージを介して帯域幅のサイズおよび位置などの対応するリソース情報を移動局２００に送信する。ステップＳ４０４では、移動局の送受信ユニット２１０は、受信したＵＬ許可メッセージからリソース情報を入手し、送信すべきデータをバッファ２００から取り出し、リソース情報によって判定されたリソース上でそのデータを基地局１００に送信する。
【００３９】
本発明の実施形態によれば、基地局１００が、現在のフレームで移動局に既にあるリソースを割り当てている場合には、基地局１００のリソース・スケジューリングおよび割当ユニット１２０は、帯域幅要求メッセージの肯定応答をさらに埋め込む必要なしに、従来の動作に従って対応するＯＦＤＭＡ  ＵＬ−ＭＡＰ  ＩＥを送信する。ＯＦＤＭＡ  ＵＬ−ＭＡＰ  ＩＥは、この解決策に従って割り当てられたリソースを含む。
【００４０】
上で述べたように、いくつかの場合に、基地局１００は、いくつかの特定の移動局へのリソース割当を遅延させると判断し、たとえば、いくつかの時間にクリティカルなサービスの需要を満足できるスケジューリング方式に従って後続フレーム内でこれらの特定の移動局に関するリソース割当を実行する。したがって、基地局１００は、それでも、対応するＯＦＤＭＡ  ＵＬ−ＭＡＰ  ＩＥを、帯域幅を要求する移動局２００に送信する。しかし、肯定応答メッセージ生成ユニット１３０は、リソースのサイズを示す値を０になるようにセットする。具体的に言うと、ＯＦＤＭＡシンボル数（ＵＬパルスを搬送するＯＦＤＭＡシンボルの個数）、サブチャネル（後続インデックスを有するサブチャネルの個数）、および持続時間フィールド（単位としてＯＦＤＭＡタイム・スロットを用いて割り当てられた時間の長さを示す）のフィールドなどのＯＦＤＭＡ  ＵＬ−ＭＡＰ  ＩＥのいくつかのフィールドは、０でなければならない。基地局は、標準フォーマットでＯＦＤＭＡ  ＵＬ−ＭＡＰ  ＩＥを送信する。したがって、これは、後方互換性の要件を満足することができ、新しいメッセージまたはシグナリングを定義する必要はない。後方互換性に関する要件がない場合には、基地局は、オプションで、肯定応答フィールドが埋め込まれたＯＦＤＭＡ  ＵＬ−ＭＡＰ  ＩＥを送信する。
【００４１】
図４に示された手順では、基地局が、帯域幅要求を正しく受信するが、リソースを即座には割り当てないと判断する場合に、基地局は、ＵＬ許可に埋め込まれた肯定応答フィールドを送信する。移動局が、その特定のＵＬ許可を受信する時に、移動局は、基地局がその帯域幅要求を既に正しく受信したことを知り、したがって、リソース割当を待つ。移動局は、冗長な繰り返される要求を回避するために、要求を再送信することは試みない。
【００４２】
図５に、本発明の実施形態による帯域幅要求メッセージが失われるか破壊される時に帯域幅要求メッセージを再送信する手順を示す。このケースでは、基地局１００は、ＵＬ許可を移動局２００に全く送信しない。移動局２００は、所望の時点（たとえば、帯域幅要求が送信された後のフレーム）に全くＵＬ許可を受信できないので、それ自体の帯域幅要求が失われたことを知る。移動局２００の送受信ユニット２１０は、即座に帯域幅要求を再送信し、これによって、不必要な待ち時間を実質的に減らす。
【００４３】
図６に、本発明の実施形態による帯域幅要求／許可手順を示す。この手順は、従来の手順に似ており、相違は、移動局２００が、ＵＬ−ＭＡＰに埋め込まれたＡＣＫ情報をチェックする必要があることと、タイマがオーバーフローするかどうかを判断する必要がないことである。
【００４４】
ステップＳ６０１では、移動局２００が、まず、従来の手順と同一の手順に従って帯域幅要求を送信する。ステップＳ６０２では、所望の時点（たとえば、次のフレーム）に、移動局２００が、ＵＬ−ＭＡＰをチェックして、所望の時点が基地局手順に関連するかどうかおよび基地局が移動局に通知するかどうかを調べる。
【００４５】
その後、ステップＳ６０３では、移動局２００が、それに向けられたＵＬ−ＭＡＰ  ＩＥユニットを検索し、ステップＳ６０４では、それ自体のＵＬ−ＭＡＰ  ＩＥユニットを入手できるかどうかを判断する。移動局２００が、それに向けられたＵＬ−ＭＡＰ  ＩＥを見つけることができない場合には、ステップＳ６０５で、移動局２００は、帯域幅要求が失われたことを知る。移動局は、即座に帯域幅要求を再送信し、これによって、待ち時間を実質的に減らす。
【００４６】
移動局が、それに割り当てられたＵＬ−ＭＡＰ  ＩＥユニットを入手する場合には、移動局２００は、基地局が帯域幅要求を既に正しく受信していることを知る。したがって、移動局は、冗長な繰り返される要求を回避するために、帯域幅要求を送信することを試みない。次に、移動局２００の検出ユニットは、ステップＳ６０６で、ＵＬ−ＭＡＰ  ＩＥで割り当てられたリソースが０であるかどうかを検出する。リソースのサイズが０である場合には、これは、基地局１００が、帯域幅要求を既に正しく受信してはいるが、そのフレームで移動局にリソースを割り当てないことを意味する。基地局は、スケジューリング方式に従って後続フレームで移動局にリソースを割り当てる。ステップＳ６０７では、移動局２００は、後続フレームが来るのを待ち、ＵＬ−ＭＡＰチェックを繰り返す。ステップＳ６０８では、移動局２００が、有効な帯域幅割当を有するＵＬ−ＭＡＰ  ＩＥを入手した時に、移動局２００の送受信ユニット２１０は、バッファ２２０内の送信すべきデータを、割り当てられた時間−周波数リソース・ブロック上で送信する。
【００４７】
上で述べたように、上の肯定応答は、移動局が、帯域幅要求が失われたことをできる限り早く知り、要求を送信することを再開始することを可能にする。したがって、移動局は、失敗した帯域幅要求からすばやく復元することができる。従来の手順と比較して、本発明による手順は、帯域幅要求を再送信する前の実質的に減らされた待ち時間を示す。
【００４８】
さらに、上の解決策は、帯域幅割当（ＵＬ−ＭＡＰ  ＩＥ）以外に余分な肯定応答情報を搬送することができる。これは、肯定応答手順のために新しいメッセージまたはシグナリングを定義することを全く必要とせず、したがって、後方互換性をサポートする。
【００４９】
基地局が、移動局の要求に応答し、リソースを即座に割り当てると判断する時には、基地局は、余分な肯定応答情報を送信する必要が全くない。必要なものは、たとえば、基地局が要求を正しく受信するがリソースを即座には割り当てない時に、基地局が、帯域幅要求の肯定応答を送信することだけである。この解決策は、オーバーヘッドを実質的に減らす。
【００５０】
非特許文献１に示された肯定応答手順では、基地局が、各帯域幅要求に応答するためにリソースを消費しなければならないので、これが、比較的大きいオーバーヘッドを引き起こす。対照的に、本発明の実施形態による上の解決策は、帯域幅要求の肯定応答を使用する。基地局は、必要な時に限って肯定応答を行う。したがって、オーバーヘッドはより少ない。さらに、本発明の実施形態による解決策は、余分な肯定応答情報を帯域幅割当に埋め込むことを可能にし、新しいメッセージまたはシグナリングを定義することを全く必要とせず、したがって、後方互換性をサポートする。
【００５１】
上の説明は、基地局と移動局との間の帯域幅要求および肯定応答に関するが、上の解決策を、たとえばＢＳ−ＲＳ、ＲＳ−ＭＳ、およびＢＳ−フェムトＢＳの間のリソースの適用および割当のケースに適用することもできる。
【００５２】
本発明を、上の例示的実施形態を参照して詳細に図示し、説明したが、本発明は、これらの実施形態に限定されない。当業者は、形態および詳細に対するさまざまな変更が添付の特許請求の範囲で定義される本発明の趣旨および範囲から逸脱しないことを了解するに違いない。
【図１】
0005345704.tif 000002
【図２】
0005345704.tif 000003
【図３】
0005345704.tif 000004
【図４】
0005345704.tif 000005
【図５】
0005345704.tif 000006
【図６】
0005345704.tif 000007
【図７】
0005345704.tif 000008
【図８】
0005345704.tif 000009
【図９】
0005345704.tif 000010
【図１０】
0005345704.tif 000011