(57)【要約】【課題】移動通信システムにおいて、で端末（ＵＥ）と基地局（ＮＢ）間のアップリンク（ＵＬ）データ送受信時に発生する遅延を低減できる方法及び装置を提供する。【解決手段】本開示は、４Ｇシステム以降の、より高いデータ送信率をサポートするための５Ｇ通信システムとこれをＩｏＴ技術と融合する通信技法及びそのシステムに関する。本発明に係る移動通信システムにおける端末（ＵＥ）のＵＬ（アップリンク）スケジューリング方法は、バッファに記憶されたデータ量を識別する段階と、ＳＲ（ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ、スケジューリング要求）を生成する段階と、基地局（ＮＢ）からＵＬリソースが割り当てられるように前記基地局へ前記識別されたデータ量に基づいて前記ＳＲを送信する段階と、を含む。【選択図】図３
2019532538.tif 000002
【特許請求の範囲】
【請求項１】
移動通信システムにおける端末（ＵＥ）のアップリンク（以下、ＵＬという）スケジューリング方法であって、
バッファに記憶されたデータ量を識別する段階と、
ＳＲ（ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ、スケジューリング要求）を生成する段階と、
基地局（ＮＢ）からＵＬリソースが割り当てられるように前記基地局へ前記識別されたデータ量に基づいて前記ＳＲを送信する段階と、を含むことを特徴とする、方法。
【請求項２】
前記ＳＲを送信する段階は、
前記識別されたデータ量に基づいて前記ＳＲの送信時点を決定する段階と、
前記決定された送信時点において前記ＳＲを前記基地局へ送信する段階と、を含むことを特徴とする、請求項１に記載の方法。
【請求項３】
前記ＳＲを送信する段階は、
前記識別されたデータ量に基づいて前記ＳＲの送信回数を決定する段階と、
前記決定された送信回数に従って前記ＳＲを前記基地局へ送信する段階を含むことを特徴とする、請求項１に記載の方法。
【請求項４】
前記ＳＲを送信する段階は、
前記ＳＲの連続送信回数を決定し、前記連続送信回数に対するビットマップ（ｂｉｔｍａｐ）を生成する段階と、
前記識別されたデータ量に対して前記ビットマップをマッピングする段階と、
前記ビットマップをマッピングした結果に従って前記ＳＲを前記基地局へ送信する段階と、を含むことを特徴とする、請求項１に記載の方法。
【請求項５】
前記ＳＲは多重ＳＲビット（ｍｕｌｔｉｐｌｅ  ＳＲ＿ｂｉｔｓ）から構成され、前記識別されたデータ量に対して前記多重ＳＲビットがマッピングされることを特徴とする、請求項１に記載の方法。
【請求項６】
前記ＳＲが生成可能なサブフレームのサブフレームインデクスを、前記バッファの状態を示すバッファ状態（ＢＳ）インデクスに対してマッピングする段階を含み、
前記バッファ状態（ＢＳ）インデクスは前記バッファに記憶されたデータ量に従って設定されることを特徴とする、請求項１に記載の方法。
【請求項７】
前記ＳＲはサブフレーム内において第１ＴＴＩ（ｔｒａｎｓｍｉｓｓｉｏｎ  ｔｉｍｅ  ｉｎｔｅｒｖａｌ、送信時間間隔）内の第１リソース及び第２ＴＴＩ内の第２リソースのうちの少なくとも一つに割り当てられ、前記第１ＴＴＩは前記第２ＴＴＩより長いことを特徴とする、請求項１に記載の方法。
【請求項８】
移動通信システムにおける基地局（ＮＢ）のＵＬスケジューリング方法であって、
端末（ＵＥ）からＳＲ（ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ、スケジューリング要求）を受信する段階と、
前記ＳＲを用いて前記端末のバッファに記憶されたデータ量を識別する段階と、
前記識別されたデータ量に基づいて前記端末に対してＵＬリソースを割り当てる段階と、を含むことを特徴とする、方法。
【請求項９】
前記ＳＲを受信する段階は、
前記バッファに記憶されたデータ量に従って決定された前記ＳＲの送信時点において前記端末から前記ＳＲを受信する段階、を含むことを特徴とする、請求項８に記載の方法。
【請求項１０】
前記ＳＲを受信する段階は、
前記バッファに記憶されたデータ量に基づいて決定された前記ＳＲの送信回数に従って前記ＳＲを前記端末から受信する段階と、を含むことを特徴とする、請求項８に記載の方法。
【請求項１１】
移動通信システムにあってＵＬをスケジューリングする端末（ＮＥ）であって、
信号を送受信する送受信部と、
バッファに記憶されたデータ量を識別し、ＳＲ（ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ、スケジューリング要求）を生成し、基地局（ＮＢ）からＵＬリソースを割り当てられるように前記基地局で前記識別されたデータ量に基づいて前記ＳＲを送信するように制御する制御部と、を含むことを特徴とする、端末。
【請求項１２】
前記制御部は、
前記識別されたデータ量に基づいて前記ＳＲの送信時点を決定し、前記決定された送信時点によって前記ＳＲを前記基地局へ送信するように制御することを特徴とする、請求項１１に記載の端末。
【請求項１３】
前記ＳＲは多重ＳＲビット（ｍｕｌｔｉｐｌｅ＿ＳＲ＿ｂｉｔｓ）から構成され、前記識別されたデータ量に対して前記多重ＳＲビットがマッピングされることを特徴とする、請求項１１に記載の端末。
【請求項１４】
移動通信システムにあってＵＬスケジューリングする基地局（ＮＢ）であって、
信号を送受信する送受信部と、
端末からＳＲ（ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ、スケジューリング要求）を受信し、前記ＳＲを用いて前記端末のバッファに記憶されたデータ量を識別し、前記識別されたデータ量に基づいて前記端末でＵＬリソースを割り当てるように制御する制御部と、を含むことを特徴とする、基地局。
【請求項１５】
前記制御部は、
前記バッファに記憶されたデータ量に基づいて決定された前記ＳＲの送信時点において前記端末から前記ＳＲを受信するように制御することを特徴とする、請求項１４に記載の基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムにおいて端末と基地局間のＵＬデータを送受信する方法及び装置に関する。
【背景技術】
【０００２】
４Ｇ通信システムの商用化以後にも増加趨勢にある無線データトラフィックに対するニーズを満たすため、改善された５Ｇ又はプレ５Ｇ（ｐｒｅ−５Ｇ）通信システムを開発するための努力がなされつつある。このような理由で、５Ｇ通信システム又はプレ５Ｇ通信システムは、４Ｇネットワーク越え（Ｂｅｙｏｎｄ  ４Ｇ  Ｎｅｔｗｏｒｋ）通信システム又はポストＬＴＥ（Ｐｏｓｔ  ＬＴＥ）システムと呼ばれている。
高いデータ送信率を達成するために、５Ｇ通信システムは超高周波（ｍｍＷａｖｅ）帯域（例えば、６０ギガ（６０ＧＨｚ）帯域）での具現が考慮されている。超高周波帯域での電波の経路損失を緩和し、電波の伝達距離を増加するために、５Ｇ通信システムでは、ビームフォーミング（ｂｅａｍ−ｆｏｒｍｉｎｇ）、巨大配列の多重入出力（ｍａｓｓｉｖｅ  ＭＩＭＯ）、及び全次元の多重入出力（Ｆｕｌｌ  Ｄｉｍｅｎｓｉｏｎａｌ  ＭＩＭＯ：ＦＤ−ＭＩＭＯ）、並びにこれらに係る、アレイアンテナ（ａｒｒａｙ  ａｎｔｅｎｎａ）、アナログビームフォーミング（ａｎａｌｏｇ  ｂｅａｍ−ｆｏｒｍｉｎｇ）、及び大規模アンテナ（ｌａｒｇｅ  ｓｃａｌｅ  ａｎｔｅｎｎａ）技術が論議されている。
また、システムのネットワーク改善のために、５Ｇ通信システムでは進化した小型セル、先進的小型セル（ａｄｖａｎｃｅｄ  ｓｍａｌｌ  ｃｅｌｌ）、クラウド無線アクセスネットワーク（ｃｌｏｕｄ  ｒａｄｉｏ  ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ：ｃｌｏｕｄ  ＲＡＮ）、超高密度ネットワーク（ｕｌｔｒａ−ｄｅｎｓｅ  ｎｅｔｗｏｒｋ）、機器間の通信（Ｄｅｖｉｃｅ  ｔｏ  Ｄｅｖｉｃｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ：Ｄ２Ｄ）、無線バックホール（ｗｉｒｅｌｅｓｓ  ｂａｃｋｈａｕｌ）、移動ネットワーク（ｍｏｖｉｎｇ  ｎｅｔｗｏｒｋ）、協力通信（ｃｏｏｐｅｒａｔｉｖｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＣｏＭＰ（Ｃｏｏｒｄｉｎａｔｅｄ  Ｍｕｌｔｉ−Ｐｏｉｎｔｓ）、及び受信干渉除去（ｉｎｔｅｒｆｅｒｅｎｃｅ  ｃａｎｃｅｌｌａｔｉｏｎ）などの技術開発が成されつつある。
この以外にも、５Ｇシステムでは先進的コーディング変調（Ａｄｖａｎｃｅｄ  Ｃｏｄｉｎｇ  Ｍｏｄｕｌａｔｉｏｎ：ＡＣＭ）方式であるＦＱＡＭ（Ｈｙｂｒｉｄ  ＦＳＫ  ａｎｄ  ＱＡＭ  Ｍｏｄｕｌａｔｉｏｎ）及びＳＷＳＣ（Ｓｌｉｄｉｎｇ  Ｗｉｎｄｏｗ  Ｓｕｐｅｒｐｏｓｉｔｉｏｎ  Ｃｏｄｉｎｇ）と、先進的接続技術であるＦＢＭＣ（Ｆｉｌｔｅｒ  Ｂａｎｋ  Ｍｕｌｔｉ  Ｃａｒｒｉｅｒ）、ＮＯＭＡ（ｎｏｎ  ｏｒｔｈｏｇｏｎａｌ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、及びＳＣＭＡ（ｓｐａｒｓｅ  ｃｏｄｅ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）などが開発されている。
【０００３】
一方、インタネットは人間が情報を生成して消費する人間中心の接続網から、事物など分散した構成要素が情報を取り交わして処理するＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ、事物インタネット）網に進化しつつある。クラウドサーバなどとの接続を通じるビッグデータ（Ｂｉｇ  Ｄａｔａ）処理技術などがＩｏＴ技術に結合されたＩｏＥ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｅｖｅｒｙｔｈｉｎｇ）技術も台頭している。ＩｏＴを具現するため、センシング技術、有無線通信及びネットワークインフラ、サービスインタフェース技術、及びセキュリティ（ｓｅｃｕｒｉｔｙ、保安）技術のような技術要素が要求され、最近には事物間の接続のためのセンサネットワーク（ｓｅｎｓｏｒ  ｎｅｔｗｏｒｋ）、マシンツーマシン（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ、Ｍ２Ｍ）、ＭＴＣ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などの技術が研究されている。
ＩｏＴ環境では接続された事物で生成されたデータを収集、分析して人間の生活に新しい価値を創出する知能型ＩＴ（Ｉｎｔｅｒｎｅｔ  Ｔｅｃｈｎｏｌｏｇｙ）サービスが提供できる。ＩｏＴは既存のＩＴ（ｉｎｆｏｒｍａｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｙ）技術と多様な産業間の融合及び複合を介してスマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、スマートグリッド、ヘルスケア、スマート家電、先端医療サービスなどの分野に応用できる。
【０００４】
これに合わせて、５Ｇ通信システムをＩｏＴ網に適用するための多様な試みがなされている。例えば、センサネットワーク（ｓｅｎｓｏｒ  ｎｅｔｗｏｒｋ）、マシンツーマシン（Ｍａｃｈｉｎｅ  ｔｏ  Ｍａｃｈｉｎｅ、Ｍ２Ｍ）、ＭＴＣ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などの技術が５Ｇ通信技術がビームフォーミング、ＭＩＭＯ、及びアレイアンテナなどの技法によって具現されていることである。前述したビックデータ処理技術としてクラウド無線アクセスネットワーク（ｃｌｏｕｄ  ＲＡＮ）が適用されることも５Ｇ技術とＩｏＴ技術融合の一例と言えるであろう。
【０００５】
端末において、基地局へ送信されるべきデータが発生した場合、端末は基地局からデータ送信に必要なリソースの割り当てを受けなければならない。この時、端末は基地局にＳＲ（ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ、スケジューリング要求）情報を送信してデータ送信のためのリソースが割り当てられる。
【０００６】
端末がＳＲ情報を送信するのに用いられるリソースは基地局から事前に決定できる。例えば、ＬＴＥシステムの場合、端末はＵＬ制御情報チャンネル（ＰＵＣＣＨ）領域中の一部をスケジューリングリクエスト送信のために使用できる。端末からスケジューリングリクエストを受けた基地局は当該端末にＵＬリソースを決定して通知できる。
【０００７】
端末は以後ＢＳＲ（バッファ状態報告、Ｂｕｆｆｅｒ  Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ）を送信して自分が送信すべきデータがさらにあることを基地局で通知できる。ただし、基地局は端末に何バイト（ｂｙｔｅ）の量のＵＬデータが発生したかＢＳＲを受信する迄分からないという問題点がある。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明が達成しようとする技術的な課題は、移動通信システムにおいて端末と基地局間のＵＬデータ送受信時に発生する遅延を低減できる方法及び装置を提供する。
【課題を解決するための手段】
【０００９】
本発明の実施形態による移動通信システムにおいて、端末のＵＬスケジューリング方法は、バッファに記憶されたデータ量を識別する段階と、ＳＲ（ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ）を生成する段階と、基地局からＵＬリソースが割り当てられるように前記基地局で前記識別されたデータ量に基づいて前記ＳＲを送信する段階と、を含む。
【００１０】
前記ＳＲを送信する段階は、前記識別されたデータ量に基づいて前記ＳＲの送信時点を決定する段階と、前記決定された送信時点によって前記ＳＲを前記基地局へ送信する段階と、を含む。
前記ＳＲを送信する段階は、前記識別されたデータ量に基づいて前記ＳＲの送信回数を決定する段階と、前記決定された送信回数によって前記ＳＲを前記基地局へ送信する段階と、を含む。
前記ＳＲを送信する段階は、前記ＳＲの連続送信回数を決定し、前記連続送信回数に対するビットマップ（ｂｉｔｍａｐ）を生成する段階と、前記識別されたデータ量と前記ビットマップをマッピングする段階と、前記マッピング結果によって前記ＳＲを前記基地局へ送信する段階と、を含む。
実施形態によって、前記ＳＲは多重ＳＲビット（ｍｕｌｔｉｐｌｅ＿ＳＲ＿ｂｉｔｓ）から構成され、前記識別されたデータ量と前記多重ビットがマッピングできる。
実施形態によって、前記端末のＵＬスケジューリング方法は、前記ＳＲが発生できる任意のサブフレーム内のサブフレームインデクスと前記バッファの状態を示すバッファ状態（以下、ＢＳと略す）インデクスをマッピングする段階を含み、前記ＢＳインデクスは前記バッファに記憶されたデータ量によって設定され得る。
実施形態によって、前記ＳＲは任意のサブフレーム（サブフレーム）内で第１ＴＴＩ（ｔｒａｎｓｍｉｓｓｉｏｎ  ｔｉｍｅ  ｉｎｔｅｒｖａｌ、送信時間間隔）内の第１リソース及び第２ＴＴＩ内の第２リソースの少なくとも一つに割り当てできる。
【００１１】
本発明の実施形態による移動通信システムにおいて、基地局のＵＬスケジューリング方法は、端末からＳＲ（ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ）を受信する段階と、前記ＳＲを用いて前記端末のバッファに記憶されたデータ量を識別する段階と、前記識別されたデータ量に基づいて前記端末でＵＬリソースを割り当てる段階と、を含む。
【００１２】
本開示の特徴によって、ＵＬデータのスケジューリング方法及び装置は、端末と基地局間のＵＬデータの送受信遅延を低減できる。
【００１３】
以下の詳細な説明をする前に、この特許文献全体にわたって用いられた特定単語及び語句の定義を記述することが有益であろう：  “含む”という用語及びその派生語は、制限無し含むことを意味する；  “又は”という用語は包括的であり、“及び／又は”という意味を有する；  “関連される”及び“関連ある”という文言及びその派生語は、その中に含まれるか、含むか、相互に連結されるか、並行するか、並べるか、並置されるか、近接するか、バインディングされるか、有しているか、所有しているか、などの属性を意味する；“制御部”という用語は、少なくとも一つの動作を制御する任意の装置、システム又はその一部を意味し、それらの装置はハードウェア、ファームウエア又はソフトウェア、又はこれらのうちの少なくとも２つの組み合わせで具現できる。  特定のコントローラに係る機能はローカル又は遠隔で中央集中式又は分散型であり得る。
【００１４】
また、以下で説明される様々な機能は一つ以上のコンピュータプログラムによって具現されるか、又はサポートされ得、各々のコンピュータプログラムはコンピュータ読取り可能プログラムコードでもって形成され、コンピュータ読取り可能媒体に具現される。“アプリケーション”及び“プログラム”という用語は、適切なコンピュータ読取り可能プログラムで具現するために適応された一つ以上のコンピュータプログラム、ソフトウェア構成要素、コマンドセット、手続き、機能、客体、クラス、インスタンス、関連データ又はその一部を示す。
“コンピュータ読取り可能プログラムコード”という文言は、ソースコード、オブジェクトコード及び実行可能コードを含み、あらゆる類型のコンピュータコードを含む。“コンピュータ読取り可能媒体”という文言は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ハードディスクドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、又は任意の異なる類型のメモリなどの、コンピュータによりアクセスできる任意の類型の媒体を含む。“一時的でない（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ）”コンピュータ読取り可能媒体は、一時的な電気又は異なる信号を送信する有線、無線、光学又は他の通信リンクを排除する。非一時的なコンピュータ判読可能媒体は、データを永久に記憶できる媒体、及び再記録可能な光ディスク又は消去可能メモリ装置のようにデータを記憶し、後で上書き可能な媒体を含む。
【００１５】
特定の単語及び語句に対する定義がこの特許文献全体にわたって提供され、当業者は殆どの場合ではないが多くの場合、そのような定義がそのように定義された単語及び語句の過去及び未来使用に適用されるものと理解しなければならない。
【発明の効果】
【００１６】
本発明の実施形態によるＵＬデータスケジューリング方法及び装置は、端末と基地局間のＵＬデータ送受信時に発生する遅延を低減できる効果がある。
【図面の簡単な説明】
【００１７】
【図１】移動通信システムでＵＬデータを送受信する第１方法を説明するフローチャートである。
【図２】移動通信システムでＵＬデータを送受信する第２方法を説明するフローチャートである。
【図３】本発明の第１実施形態によるＵＬデータ送受信方法を説明する図面である。
【図４】本発明の第１実施形態によってバッファ状態（ＢＳ）インデクスとＵＬデータのマッピング関係の例示を示す図面である。
【図５】本発明の第１実施形態による基地局と端末間のＵＬリソース割り当てを説明するフローチャートである。
【図６】本発明の第１実施形態による端末の動作を示すフローチャートである。
【図７】本発明の第２−１実施形態によるＵＬデータ送受信方法を説明する図面である。
【図８】本発明の第２−１実施形態によってＳＲ送信回数とＵＬデータ大きさのマッピング関係の例示を示す  図面である。
【図９】本発明の第２−１実施形態によってＳＲ送信を禁止するタイマーを決定する過程を示す図面である。
【図１０】本発明の第２−２実施形態によるＵＬデータ送受信方法を説明する図面である。
【００１８】
【図１１】発明の第２−２実施形態によってＳＲ送信に係るビットマップとＵＬデータのマッピング関係の例示を示す図面である。
【図１２】本発明の第３実施形態によるＵＬデータ送受信方法を説明する図面である。
【図１３】（Ａ）は、本発明の第３−１実施形態によって多重ビットから構成されたＳＲとＵＬデータのマッピング関係の例示を示す  図面であり、（Ｂ）は、本発明の第３−２実施形態によってコード基盤ＳＲとＵＬデータのマッピング関係の例示を示す図面であり、（Ｃ）は、本発明の実施形態によってＳＲ送信方法とＳＲ送信方法が含む情報の対応関係を示す図面である。
【図１４】本発明の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【図１５】本発明の他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【図１６】本発明のまた他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【図１７】本発明のまた他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【図１８】本発明のまた他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【図１９】本発明のまた他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【図２０】本発明のまた他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【００１９】
【図２１】本発明の第４−１実施形態によるＵＬデータ送受信方法を説明する図面である。
【図２２】本発明の第４−２実施形態によるＵＬデータ送受信方法を説明する図面である。
【図２３】本発明の第５−１実施形態によるＵＬ送受信方法を説明する図面である。
【図２４】本発明の第５−２実施形態によるＵＬ送受信方法を説明する図面である。
【図２５】本発明の第５−３実施形態によるＵＬ送受信方法を説明する図面である。
【図２６】本発明の実施形態によってＳＲリソースとＮＯＭＡ基盤ＳＲリソースが共存する状況を示す図面である。
【図２７】本発明の他の実施形態によってＳＲリソースとＮＯＭＡ基盤ＳＲリソースが共存する状況を示す図面である。
【図２８】本発明の実施形態によってサービス別でＳＲリソースが用いられることを説明する図面である。
【図２９】本発明の他の実施形態によってサービス別でＳＲリソースが用いられることを説明する図面である。
【図３０】本発明のまた他の実施形態によってサービ別でＳＲリソースが用いられることを説明する図面である。
【００２０】
【図３１】本発明の実施形態によるＳＲ送受信手続きを説明する図面である。
【図３２】本発明の実施形態によってマルチ−ビットＳＲ信号に係る情報を送受信する過程を説明する図面である。
【図３３】本発明の実施形態によって最小初期ＵＬリソース大きさに関する情報を送受信する過程を説明する図面である。
【図３４】本発明の実施形態によって最小初期ＵＬリソース大きさに関する情報を送受信する過程を説明するフローチャートである。
【図３５】本発明の実施形態による基地局を示す図面である。
【図３６】本発明の実施形態による基地局を示す図面である。
【発明を実施するための形態】
【００２１】
以下で議論される図１乃至図３５、及び本特許文献において本開示の原理を説明するために使用された様々な実施形態は、ただ説明のためのもので、本発明の範囲を制限するものと解釈されてはならない。当業者は本開示の原理が任意の適切に配列されたシステム又は装置として具現できることを理解するであろう。
【００２２】
以下、添付された図面を参照して本発明の好ましい実施形態を詳しく説明する。この時、添付された図面で同一構成要素は可能な同一符号に付している事に留意すべきである。また、本発明の要旨を不明瞭にしかねない公知機能及び構成に対する詳細な説明は省略する。
【００２３】
本明細書で実施形態を説明するにあたり本発明が属する技術分野によく知られており、発明と直接的に関連がない技術内容に対しては説明を省略する。これは不必要な説明を省略することによって本発明の要旨を明瞭にしてより明確に伝達するためである。
【００２４】
同じ理由で添付図面において一部構成要素は、誇張されるか省略されるか、又は概略的に図示された。また、各構成要素の大きさは実際の大きさを全的に反映するのではない。各図面で同一又は対応する構成要素には同一参照番号を付した。
【００２５】
本発明の利点及び特徴、そして、それらを達成する方法は添付される図面と共に詳細に後述されている実施形態を参照すれば明確になるであろう。しかし、本発明は以下で開示される実施形態に限定されるのではなく互いに異なる多様な形態で具現でき、本実施形態は、単に、本発明の開示を完全にし、本発明が属する技術分野で通常の知識を有する者に発明の範疇を完全に報らせるために提供されるものであり、本発明は請求項の範疇によって定義されるだけである。明細書全体にかけて同一参照符号は同一構成要素を指称する。
【００２６】
このとき、処理フローチャートの各ブロックとフローチャートの図面の組合せは、コンピュータプログラムインストラクションによって実行できることを理解できるであろう。これらコンピュータプログラムインストラクションは、汎用コンピュータ、特殊用コンピュータ又はその他のプログラム可能なデータプロセッシング装備のプロセッサに搭載できるので、コンピュータ又はその他のプログラム可能なデータプロセッシング装備のプロセッサを介して行われるそのインストラクションが、フローチャートブロックで説明された機能を行う手段を生成するようになる。これらコンピュータプログラムインストラクションは、特定方式で機能を具現するためにコンピュータ又はその他のプログラム可能なデータプロセッシング装備を志向できるコンピュータ利用可能、又はコンピュータ判読可能メモリに記憶されることも可能であるので、そのコンピュータ利用可能又はコンピュータ判読可能メモリに記憶されたインストラクションは、フローチャートブロックで説明された機能を行うインストラクション手段を内包する製造品目を生産することも可能である。コンピュータプログラムインストラクションは、コンピュータ又はその他のプログラム可能なデータプロセッシング装備上に搭載されることも可能であるので、コンピュータ又はその他のプログラム可能なデータプロセッシング装備上で一連の動作段階が行われ、コンピュータで実行されるプロセスを生成してコンピュータ又はその他のプログラム可能なデータプロセッシング装備を行うインストラクションはフローチャートブロックで説明された機能を行うための段階を提供することも可能である。
【００２７】
また、各ブロックは、特定された論理的機能を行うための１つ以上の実行可能なインストラクションを含むモジュール、セグメント、又はコードの一部を表示できる。また、幾つか代替実行例ではブロックで言及された機能が段階を外れて発生することも可能であることを注目しなければならない。例えば、連接して示されている２つのブロックは、実は同時に行われることも可能で、又は、そのブロックは、その時の該当する機能によっては逆順に行われることも可能である。
【００２８】
このとき、本実施例に用いられる‘ユニット’、‘モジュール’、又はその類似物という用語（以下、総称して‘〜ユニット’という）は、何らかの機能又は動作を実行する、ソフトウェア構成要素、又はＦＰＧＡ、並びにＡＳＩＣのようなハードウェア構成要素を意味する。しかし、‘〜ユニット’は、ソフトウェア又はハードウェアに限定されない。‘〜ユニット’はアドレシング可能な記憶媒体に存在するようにも構成でき、１つ又はその以上のプロセッサを駆動するようにも構成できる。
従って、一例として‘〜ユニット’はソフトウェア構成要素、客体（オブジェクト）志向ソフトウェア構成要素、クラス構成要素及びタスク構成要素などの構成要素と、プロセス、関数、属性、プロシージャ、サブルーティン、プログラムコードのセグメント、ドライバ、ファームウエア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。構成要素と‘〜ユニット’のうちで提供される機能は、より小さい数の構成要素及び‘〜ユニット’に結合されるか、及び／又は、追加的な構成要素と‘〜ユニット’にさらに分解できる。それだけでなく、構成要素及び‘〜ユニット’はセキュア（ｓｅｃｕｒｅ、機密性の確保された）マルチメディアカード内のデバイス或いは１つ又はその以上のＣＰＵを駆動するようにも具現できる。
【００２９】
以下、本発明の実施例を添付した図面とともに詳しく説明する。さらに、本発明を説明するにおいて関連する機能あるいは構成に対する具体的な説明が本発明の要旨を不必要に不明瞭にしかねないと判断された場合、その詳細な説明は省略する。そして、後述される用語は、本発明での機能を考慮して定義された用語であって、ユーザ、運用者の意図又は慣例などによって変化できる。従って、その定義は本明細書全般にわたった内容に基づいて下されなければならないであろう。
【００３０】
以下、基地局ＮＢは、端末へのリソース割り当てを行う主体とし、ｅＮｏｄｅＢ、ＮｏｄｅＢ（ＮＢ）、ＢＳ（Ｂａｓｅ  Ｓｔａｔｉｏｎ）、無線接続ユニット、基地局制御機、又はネットワーク上のノードのうちの少なくとも一つであり得、これらを総称して‘ＮＢ’とする。端末は、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ、ユーザ装置）、ＭＳ（Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ、移動局）、セルラフォン、スマートフォン、コンピュータ、又は通信機能を実行できる  マルチメディアステムを包含できる。本発明において、ダウンリンク（Ｄｏｗｎｌｉｎｋ；以下、ＤＬという）は基地局が端末に送信する信号の無線送信経路で、（Ｕｐｌｉｎｋ；以下、ＵＬという）は端末が基地局に送信する信号の無線送信経路を意味する。さらに、以下でＬＴＥ或いはＬＴＥ−Ａシステムを一例として本発明の実施形態を説明するが、類似の技術的背景又はチャンネル形態を有するそのほかの通信システムにも本発明の実施形態が適用できる。
【００３１】
図１は、移動通信システムでＵＬデータを送受信する第１方法を説明するフローチャートである。
【００３２】
図１に示された方法はＬＴＥ又は５Ｇ移動通信システムで端末と基地局間のＵＬＵＬデータ送受信手続きを示す。
【００３３】
先ず、端末ＵＥで基地局ＮＢに送信すべきＵＬデータが発生したと仮定する。例えば、前記ＵＬデータは９００ｂｙｔｅであれば良い。
【００３４】
Ｓ１００段階で、端末ＵＥは自分に割り当てられたＳＲ（ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ、スケジューリング要求）機会に基地局ＮＢへＳＲ（Ｓｃｈｅｄｕｌｉｎｇ＿Ｒｅｑｕｅｓｔ、スケジューリング要求、以下、ＳＲと略す）を送信できる。
【００３５】
Ｓ１１０段階で、前記基地局ＮＢは前記端末ＵＥが送信したＳＲを受信し、前記ＳＲに応答して前記端末ＵＥへＵＬグラント（ｕｐｌｉｎｋ  ｇｒａｎｔ（許可））を送信することによって前記端末ＵＥに対してＵＬリソースを割り当てできる。
【００３６】
この時、前記基地局ＮＢは前記端末ＵＥに何バイト（ｂｙｔｅ）のＵＬデータが発生したのか分からない。
従って、前記基地局ＮＢは前記端末ＵＥに所定の（ｇｉｖｅｎ）大きさに該当するＵＬリソースを割り当てできる。例えば、前記基地局ＮＢは前記端末ＵＥにＢＳＲ（バッファ状況報告）を送信できるほどのＵＬリソースを割り当てできる。
【００３７】
図１では前記基地局ＮＢが３００ｂｙｔｅのＵＬデータを送信できるＵＬリソースを前記端末ＵＥに割り当てたと仮定する。
【００３８】
Ｓ１２０段階で、前記端末は前記基地局からＵＬグラント（ｕｐｌｉｎｋ  ｇｒａｎｔ）を受信して割り当てられたＵＬリソースを介してＵＬＵＬデータを前記基地局へ送信できる。
【００３９】
図１では端末ＵＥに９００ｂｙｔｅのＵＬデータが発生したが、基地局ＮＢは前記端末ＵＥに３００ｂｙｔｅのＵＬデータを送信できるリソースを割り当てたので、前記端末ＵＥは発生したＵＬデータ全部（即ち、９００ｂｙｔｅ）を送信できない。
【００４０】
Ｓ１２０段階で、端末ＵＥは基地局ＮＢにＢＳＲ（バッファ状態報告）を送信して自分が送信すべきＵＬデータが６００ｂｙｔｅ存在するという事実を前記基地局で通知できる。
【００４１】
Ｓ１３０段階で、基地局ＮＢは、端末ＵＥからＢＳＲを受信してＢＳＲに含まれた情報、即ち、端末ＵＥが送信すべきＵＬデータが６００ｂｙｔｅ存在するという事実に基づいて追加的に端末ＵＥにリソースを割り当てできる。
【００４２】
Ｓ１４０段階で、端末ＵＥは基地局ＮＢからＵＬグラントを受信した後に割り当てられたリソースを介して残余のＵＬデータ（即ち、６００ｂｙｔｅ）を前記基地局ＮＢへ送信できる。
【００４３】
図２は、移動通信システムでＵＬデータを送受信する第２方法を説明するフローチャートである。
【００４４】
図２に示された方法はＬＴＥ又は５Ｇ移動通信システムにおける端末と基地局間のＵＬデータ送受信手続きを示す。
【００４５】
先ず、端末で基地局に送信すべきＵＬデータが発生したと仮定する。例えば、前記ＵＬデータは９００ｂｙｔｅであるとする。
【００４６】
Ｓ２００段階で、端末は自分に割り当てられたＳＲ機会で基地局にＳＲを送信できる。
【００４７】
Ｓ２１０段階で、前記基地局は前記端末が送信したＳＲを受信し、前記ＳＲに応答して前記端末へＵＬグラントを送信することによって前記端末にＵＬリソースを割り当てできる。
【００４８】
この時、前記基地局は前記端末に何バイトのＵＬデータが発生したのか分かる。従って、前記基地局は前記ＵＬデータに相応する正確な大きさのＵＬリソースを前記端末に割り当てできる。例えば、前記基地局は前記端末に９００ｂｙｔｅのＵＬリソースを割り当てできる。
【００４９】
Ｓ２２０段階で、前記端末は前記基地局からＵＬグラントを受信して割り当てられたＵＬリソースを介してＵＬデータを前記基地局へ送信できる。
【００５０】
図２では端末に９００ｂｙｔｅのＵＬデータが発生することを認知した基地局が前記端末に９００ｂｙｔｅのＵＬデータを送信できるリソースを割り当てる。
【００５１】
従って、図１に示された方法と比べて図２に示された方法はＵＬデータ送受信手続きに要する時間を低減する効果がある。
【００５２】
【表１】
2019532538.tif 000003
【００５３】
前記表１を参照すれば、第１方法は図１に示された方法による遅延（ｄｅｌａｙ）又はレイテンシ（ｌａｔｅｎｃｙ）を示し、第２方法は図２に示された方法による遅延又はレイテンシを示す。
【００５４】
ここで、端末が自分に割り当てられたＳＲ機会を待つ時間を除いて、プロセッシング（ｐｒｏｃｅｓｓｉｎｇ）時間は３サブフレーム（ＴＴＩ（送信時間間隔）と同一）と仮定した。
【００５５】
図１に示された第１方法では、基地局は、端末が送信しようとするＵＬデータの大きさが分からないので２回にわたってＵＬグラントを行うので、総計１７サブフレームの所要時間が発生することが分かる。
【００５６】
即ち、第１方法の動作によれば基地局は端末に何バイトのＵＬデータが発生したのかＢＳＲを受信する迄分からない。従って、第１のＵＬグラントを介して割り当てられたリソースでＵＬ送受信を完了できなくなる。さらに、ＢＳＲを送受信する動作及び第２のＵＬグラント及びデータ送受信動作で遅延が発生することを分かる。
【００５７】
図２に示された第２方法では、基地局は端末が送信しようとするＵＬデータの大きさが分かっているので一回のＵＬグラントを行うことによって、総計９サブフレームの所要時間が発生することが分かる。
【００５８】
即ち、基地局は、端末に発生したＵＬデータの大きさが分かっているならば、端末からＳＲを受信した後に第１ＵＬグラントを介して、端末が全てのＵＬデータを一回に送信するように十分な量のリソースを割り当てできる。従って、端末と基地局間にＢＳＲ手続きが行われる前にＵＬ送受信が完了される。
【００５９】
本発明ではＵＬ送受信の遅延を減らすための方法を提案する。特に、５Ｇ移動通信システムでは低レイテンシ（ｌｏｗ＿ｌａｔｅｎｃｙ）サービスをサポートするのが重要な性能指標中の一つである。このためにフィジカルレイヤー（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）ではｓｈｏｒｔ  ＴＴＩ及びＮＯＭＡ（Ｎｏｎ−Ｏｒｔｈｏｇｏｎａｌ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）技術が研究されている。これらは送信の観点からレイテンシを減らすための核心的な技術であるが、端末に発生したＵＬデータの大きさまでは考慮していない。
【００６０】
さらに、端末のサービス側面では、端末が初期の送信を速く行うことより、現在端末が送信しなければならない低レイテンシサービス関連ＵＬデータ全部を一度に迅速に送信するのがより重要である。
【００６１】
このような観点から、本発明では基地局が端末からＢＳＲを受信しなくても端末に発生したＵＬデータの大きさを大略的に把握するようにする。
【００６２】
これは端末がＳＲ送信後の第１のＵＬ送信で自分に発生した全てのＵＬデータを基地局に送信できる可能性を提供することによって全体的なＵＬ送受信遅延を減らす効果がある。
【００６３】
基地局が端末からＢＳＲを受信しなくても端末に発生したＵＬデータの大きさの把握を可能にすることにより、本発明ではＳＲ送受信動作を改善する方法を提案する。
【００６４】
本発明で提案する方法は次の通りである。
【００６５】
本発明の第１実施形態は、基地局が端末からＢＳＲを受信しなくてもＳＲ送信時点に基づいて端末に発生したＵＬデータの大きさの把握を可能にする方法に関する。
【００６６】
本発明の第２−１実施形態は、基地局が端末からＢＳＲを受信しなくてもＳＲ送信回数に基づいて端末に発生したＵＬデータの大きさの把握を可能にする方法に関する。
【００６７】
本発明の第２−２実施形態は、基地局が端末からＢＳＲを受信しなくてもＳＲ送信回数の解釈方法に基づいて端末に発生したＵＬデータの大きさの把握を可能にする方法に関する。
【００６８】
本発明の第３実施形態は、基地局が端末からＢＳＲを受信しなくても「Ｍｕｌｔｉｐｌｅ＿ＳＲ＿ｂｉｔ」（以下、「多重ＳＲビット」ともいう）に基づいて端末に発生したＵＬデータの大きさの把握を可能にする方法に関するものである。
【００６９】
本発明では次を仮定する。これは説明の便宜のためであって、他の仮定も同様な原理に基づいて適用できる。
【００７０】
１．  各端末はサブフレーム（ｓｕｂｆｒａｍｅ）ごとにＳＲ機会を有する。これは低レイテンシサービスを用いる端末に対する妥当な仮定と見られる。
【００７１】
２．  各端末はＵＬデータが発生した時点において、ＵＬに同期した（ｓｙｎｃｈｒｏｎｉｚｅｄ）状態なのでＳＲ送信前に別途のＲＡＣＨ（Ｒａｎｄｏｍ＿Ａｃｃｅｓｓ＿Ｃｈａｎｎｅｌ）手続きを行う必要がない。
【００７２】
［第１実施形態］
【００７３】
図３乃至図６は本発明の第１実施形態を説明するための図面である。前記第１実施形態は、端末のＳＲ送信時点とバッファ状態（ｂｕｆｆｅｒ  ｓｔａｔｕｓ、以下、ＢＳと略す）との間の関係を設定して端末は自分のバッファ状態ＢＳに従ってＳＲ送信時点を調節する方法に関する。
【００７４】
ここで「バッファ状態」（ｂｕｆｆｅｒ  ｓｔａｔｕｓ、ＢＳ）という用語は端末に発生したＵＬデータの大きさ又は端末が送信すべきＵＬデータの大きさを意味する。これはＬＴＥ標準で用いられる用語である。
【００７５】
端末及び基地局は現在サブフレームインデクス（ｓｕｂｆｒａｍｅ  ｉｎｄｅｘ）に対応する予備的バッファ状態インデクス（ｐｒｅｌｉｍｉｎａｒｙ  ｂｕｆｆｅｒ  ｓｔａｔｕｓ  ｉｎｄｅｘ、以下  Ｐ−ＢＳＩと言う）を定義する。ここで、Ｐ−ＢＳＩは以下の数１のようにモジュロ（ｍｏｄｕｌｏ）演算を介してＭ段階で表現できる。
【００７６】
【数１】
2019532538.tif 000004
【００７７】
例えば、Ｐ−ＢＳＩは図３及び図４のように４段階（Ｍ＝４）で表現できる。
【００７８】
端末及び基地局はＲＲＣ（Ｒａｄｉｏ＿Ｒｅｓｏｕｒｓｅ＿Ｃｏｎｔｒｏｌ）  ｓｉｇｎａｌｉｎｇなどを介して各段階（ｍ）のＰ−ＢＳＩに該当するバッファ状態ＢＳを設定する。
【００７９】
図３は、本発明の第１実施形態によるＵＬデータ送受信方法を説明する図面である。
【００８０】
図３を参照すれば、１０個のサブフレームが構成されて１０個のサブフレームインデクス（０〜９）が設定され、予め定義された４個のＰ−ＢＳＩが設定され得る。この時、Ｐ−ＢＳＩとＵＬデータの関係は例えばマッピング関係により予め設定されている。
【００８１】
図４は、本発明の第１実施形態によってバッファ状態（ＢＳ）インデクスとＵＬデータのマッピング関係の例示を示す。
【００８２】
図４を参照すれば、ｍ＝０であれば端末のバッファ（ｂｕｆｆｅｒ）に０〜３００バイト（ｂｙｔｅｓ）のＵＬデータが存在し、ｍ＝１であれば端末のバッファに３００〜６００バイトのＵＬデータが存在し、ｍ＝２であれば端末のバッファに６００〜９００バイトのＵＬデータが存在し、ｍ＝３であれば端末のバッファに９００〜１２００バイトのＵＬデータが存在することを意味する。
【００８３】
図３及び図４を参照すれば、第３サブフレーム（ｍ＝２）でＵＬデータ（例えば、７００バイト）が発生すれば、第３サブフレーム（ｍ＝２）は第３Ｐ−ＢＳＩ（ｋ＝２）にマッピングされるので、端末は第３サブフレーム（ｍ＝２）で直ちにＳＲ（スケジューリング要求）を送信できる。
【００８４】
さらに、第９サブフレーム（ｍ＝８）でＵＬデータ（例えば、１０００バイト）が発生すれば、第９サブフレーム（ｍ＝８）は第１Ｐ−ＢＳＩ（ｋ＝０）にマッピングされるので、端末は第９サブフレーム（ｍ＝８）でＳＲを送信しない。前記端末はＵＬデータ（例えば、１０００バイト）に相応する第４Ｐ−ＢＳＩ（ｋ＝３）を認知し、第４Ｐ−ＢＳＩ（ｋ＝３）に相応する第２サブフレーム（ｍ＝１）でＳＲを送信できる。
【００８５】
さらに、第７サブフレーム（ｍ＝６）でＵＬデータ（例えば、１００バイト）が発生すれば、第７サブフレーム（ｍ＝６）は第４Ｐ−ＢＳＩ（ｋ＝３）にマッピングされるので、端末は、第７サブフレーム（ｍ＝６）でＳＲを送信しない。前記端末はＵＬデータ（例えば、１００バイト）に相応する第１Ｐ−ＢＳＩ（ｋ＝０）を認知し、第１Ｐ−ＢＳＩ（ｋ＝０）に相応する第８サブフレーム（ｍ＝７）でＳＲを送信できる。
【００８６】
図５は、本発明の第１実施形態による基地局と端末間のＵＬリソース割り当てを説明するフローチャートである。
【００８７】
第１実施形態によって端末及び基地局が各段階のＰ−ＢＳＩに該当するバッファ状態ＢＳを設定できる。
【００８８】
Ｓ５００段階で、端末は自身が低レイテンシサービスをサポートするというｐｒｏｆｉｌｅ情報を基地局に通知できる。又は、端末は基地局にＰ−ＢＳＩの設定をリクエストできる。
【００８９】
Ｓ５１０段階で、基地局は端末にバッファ状態レベル（即ち、Ｐ−ＢＳＩレベル、Ｍ値）を通知できる。ここで、ＲＲＣメッセージ内のＭＡＣ−ＭａｉｎＣｏｎｆｉｇ  ＩＥなどが使用できる。
【００９０】
Ｓ５２０段階で、端末は基地局に好むバッファ状態レベル（即ち、Ｐ−ＢＳＩレベル、Ｍ値）を通知できる。ここで、新たに定義されたｎｅｗ  ＩＥなどが使用できる。
【００９１】
Ｓ５３０段階で、端末はＳＲのように各段階のＰ−ＢＳＩに該当するＢＳＲ（バッファ状態情報）を決定して基地局に報告する。
【００９２】
ここで、各段階のＰ−ＢＳＩに該当するバッファ状態情報ＢＳＲは次によって表現できる。
【００９３】
１．  バッファ状態ＢＳのｌｏｗｅｒ    ｂｏｕｎｄ及びｕｐｐｅｒ  ｂｏｕｎｄ
【００９４】
（例示）  ｍ＝１：Ｘｌｏｗｅｒ＿ｂｏｕｎｄ＜バッファ状態ＢＳ＜Ｘｕｐｐｅｒ＿ｂｏｕｎｄ
【００９５】
２．  バッファ状態ＢＳの中間値及び範囲
【００９６】
（例示）  ｍ＝２：ｍｅｄｉａｎ＝Ｘｍｅｄｉａｎ及びｒａｎｇｅ＝Ｒ  →
Ｘｍｅｄｉａｎ−Ｒ／２＜バッファ状態ＢＳ＜Ｘｍｅｄｉａｎ＋Ｒ／２
【００９７】
従って、端末は基地局に各段階のＰ−ＢＳＩに該当するバッファ状態ＢＳのｌｏｗｅｒ  ｂｏｕｎｄ及びｕｐｐｅｒ  ｂｏｕｎｄ又は中間値及び範囲などを決定して報告できる。
【００９８】
他の方法として端末は各段階のＰ−ＢＳＩに該当するバッファ状態情報ＢＳＲとして既存の  ＬＴＥ  ＭＡＣ標準（ＴＳ３６．３２１）に定義されているＢＳＲ向けバッファサイズ（ｔａｂｌｅ６．１．３．１−１）及びＢＳＲ向け拡張バッファサイズ（ｔａｂｌｅ６．１．３．１−２）にあるインデクスを基地局に報告できる。
【００９９】
Ｓ５４０段階で、基地局は端末が送信したバッファ状態情報ＢＳＲに相応するＵＬグラントを端末で送信できる。基地局は自分とＰ−ＢＳＩを設定した端末からＳＲを受信すればＳＲを受信したサブフレームのＰ−ＢＳＩを識別して端末のバッファ状態ＢＳを把握する。そして、端末のバッファ状態ＢＳを考慮してＵＬ  ｓｃｈｅｄｕｌｉｎｇを行う。
【０１００】
基地局のＵＬ  ｓｃｈｅｄｕｌｉｎｇは具現事項だが本発明が效果を得るためには、基地局のｓｃｈｅｄｕｌｅｒが端末に対して全てのＵＬデータを第１のＵＬグラントを介して送信できるほどのリソースを割り当てられることが好ましい。
【０１０１】
図６は、本発明の第１実施形態による端末の動作を示すフローチャートである。
【０１０２】
Ｓ６００段階で、端末が基地局に送信すべきＵＬデータが発生する。Ｓ６１０段階で、前記端末は自分のバッファ状態ＢＳを識別する。
【０１０３】
Ｓ６２０段階で、前記端末は識別されたバッファ状態ＢＳがどんなＰ−ＢＳＩに対応されるか識別し、識別されたＰ−ＢＳＩに対応するサブフレームを選択できる。
【０１０４】
Ｓ６３０段階で、前記端末は現在時点から識別されたサブフレームまで待機して当該サブフレームでＳＲを送信できる。
【０１０５】
本発明の第１実施形態に必要となる時間が総９〜１２サブフレームが所要されることを分かる。
Ｐ−ＢＳＩを４段階で設定した例ではＳＲ送信遅延が最大４サブフレームまで発生ができるからである。前記表１を参照すれば、第１実施形態で所要される９〜１２サブフレームは第１方法で所要された１７サブフレーム対比約３０〜４７％減少した値に該当する。
【０１０６】
第１実施形態では各Ｐ−ＢＳＩに該当するバッファ状態ＢＳが全てｌｏｗｅｒ  ｌｉｍｉｔ及びｕｐｐｅｒ  ｌｉｍｉｔが存在する例示に対して説明した。しかし、端末に発生するトラフィック（ｔｒａｆｆｉｃ）の大きさはランダム（ｒａｎｄｏｍ）であるのでここに対応するＰ−ＢＳＩが存在しないこともある。例えば、端末に発生したｔｒａｆｆｉｃの大きさが２０００バイトの場合にはここに対応するＰ−ＢＳＩが存在しない。このような場合、端末は下記のように動作するようにする。
【０１０７】
−各ＳＲリソースに割り当てられたＰ−ＢＳＩと関係なくｔｒａｆｆｉｃ発生時点から最も早いＳＲリソースでＳＲを送信する。
【０１０８】
−端末に発生したｔｒａｆｆｉｃの大きさと正確に一致しないがこれと最も類似なＰ−ＢＳＩに該当するＳＲリソースで  ＳＲを送信する。
【０１０９】
提案方案で端末は既存方案と同様にＳＲ送信後に受信したＵＬグラントを介して基地局にデータ及びＢＳＲを送信するようになる。この時、基地局は端末からＢＳＲを受信することによって端末のバッファ状態ＢＳを把握できる。
【０１１０】
従って、端末に発生するｔｒａｆｆｉｃの大きさに対応するＰ−ＢＳＩが存在しなくても提案方案は問題なく動作できる。
【０１１１】
［第２−１実施形態］
【０１１２】
図７乃至図９は、本発明の第２−１実施形態を説明するための図面である。前記第２−１実施形態は端末の連続されたＳＲ送信回数とバッファ状態ＢＳとの間の関係を設定して端末は自分のバッファ状態ＢＳによって連続されたＳＲ送信回数を調節する方法に関するものである。
【０１１３】
図７は、本発明の第２−１実施形態によるＵＬデータ送受信方法を説明する図面である。
【０１１４】
端末及び基地局はＲＲＣ  ｓｉｇｎａｌｉｎｇなどを介して連続されたＳＲ送信回数（Ｎ）に対応するＰ−ＢＳＩを設定する。ここで、Ｐ−ＢＳＩは第１実施形態でのＰ−ＢＳＩと同一の意味を有する。即ち、端末が送信すべきＵＬデータの大きさがどの範囲に属するかに対する情報を示す。
【０１１５】
図８は、本発明の第２−１実施形態によってＳＲ送信回数とＵＬデータ大きさのマッピング関係の例示を示す。
【０１１６】
図８を参照すれば、当該例示で連続されたＳＲ送信回数が１（Ｎ＝１）であれば端末のバッファに０〜３００バイトのＵＬデータが存在することを意味し、連続されたＳＲ送信回数が２（Ｎ＝２）であれば端末のバッファに３００〜６００バイトのＵＬデータが存在することを意味し、連続されたＳＲ送信回数が３（Ｎ＝３）であれば端末のバッファに６００〜９００バイトのＵＬデータが存在することを意味する。
【０１１７】
図７乃至図８を参照すれば、端末が基地局でＳＲを１回送信することで前記端末は０〜３００バイトのＵＬデータが存在することを前記基地局に通知できる。また、端末が基地局でＳＲを２回送信することによって前記端末は３００〜６００バイトのＵＬデータが存在することを前記基地局に通知できる。また、端末が基地局でＳＲを３回送信することによって前記端末は６００〜９００バイトのＵＬデータが存在することを前記基地局に通知できる。
【０１１８】
基地局は端末のＳＲ送信回数に基づいて前記端末が送信しようとするＵＬデータの大きさを把握し、前記ＵＬデータの大きさに相応するＵＬグラントを前記端末で送信できる。前記端末は前記ＵＬグラントに応答して前記ＵＬデータを前記基地局へ送信できる。
【０１１９】
端末及び基地局が連続されたＳＲ送信回数に対応するＰ−ＢＳＩを設定する動作は第１実施形態と類似に図５の手続きを介して成る。先ず、基地局は端末に最大連続ＳＲ送信回数に対する情報を提供する。
【０１２０】
もし、端末が基地局に送信すべきＵＬデータが発生すれば次のように動作する。
【０１２１】
端末は自分のバッファ状態ＢＳを識別し、識別されたバッファ状態ＢＳがどんなＰ−ＢＳＩに対応されるか識別する。前記端末は識別されたＰ−ＢＳＩに対応する連続されたＳＲ送信回数を識別する。前記端末は現在サブフレームから識別された連続されたＳＲ送信回数ほどＳＲを送信する。
【０１２２】
基地局は自分とＰ−ＢＳＩを設定した端末からＳＲを受信すれば何回連続ＳＲが受信されたか識別して端末のバッファ状態ＢＳを把握する。そして、端末のバッファ状態ＢＳを考慮してＵＬ  ｓｃｈｅｄｕｌｉｎｇを行う。
【０１２３】
基地局のＵＬ  ｓｃｈｅｄｕｌｉｎｇは具現事項であるが本発明が効果を得るためには基地局のｓｃｈｅｄｕｌｅｒが、端末の全てのＵＬデータを第１のＵＬグラントを介して送信できるほどのリソースを端末に対して割り当てられることが好ましい。
【０１２４】
図９は、本発明の第２−１実施形態によってＳＲ送信を禁止するタイマーを設定する過程を示す。
【０１２５】
ＬＴＥに基づく第２−１実施形態を具現するためには標準で端末の連続されたＳＲ送信が許容されなければならない。現在ＬＴＥ標準では端末が１回ＳＲを送信すればｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが作動して当該ｔｉｍｅｒが満了する前までさらにＳＲを送信できないように定義されている。
【０１２６】
従って、第２−１実施形態では端末の連続されたＳＲ送信が許容されるようにｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒの作動開始時点が図９のように変更されなければならない。
【０１２７】
−ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒ作動開始時点＝初ＳＲ送信時点から最大連続ＳＲ送信回数ほど遅延された時点
【０１２８】
−図７及び図８では最大連続ＳＲ送信回数が３と設定されているから図９のようにサブフレーム２で初ＳＲ送信が成る場合、３サブフレームが遅延された時点であるサブフレーム５からｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが作動し始める。
【０１２９】
［第２−２実施形態］
【０１３０】
図１０乃至図１１は、本発明の第２−２実施形態を説明するための図面である。
【０１３１】
前記第２−２実施形態は端末の一定区間内ＳＲ送信をビットマップ（ｂｉｔｍａｐ）で形成した後、当該ビットマップとバッファ状態ＢＳとの間の関係を設定して活用する方法である。端末は自分のバッファ状態ＢＳによってＳＲ送信を制御する。
【０１３２】
図１０は、本発明の第２−２実施形態によるＵＬデータ送受信方法を説明する図面である。
【０１３３】
図１０を参照すれば、一定区間内のＳＲ送信をビットマップで形成する構成が開示されている。もし、端末に２サブフレーム間のＳＲ送信が許容されると、ＳＲ送信の有無によって００、０１、１０、１１のビットマップが表現可能である。例えば、第１のサブフレームでＳＲが送信されて第２のサブフレームでＳＲが送信されなければ、前記ビットマップは“１０”と表現できる。
【０１３４】
さらに、もし、端末が３サブフレーム間のＳＲ送信が許容されると、同様に０００、００１、０１０、０１１、１００、１０１、１１０、１１１のビットマップが表現可能である。例えば、第１のサブフレームでＳＲが送信されて第２のサブフレームでＳＲが送信されず第３のサブフレームでＳＲが送信されると、前記ビットマップは“１０１”と表現できる。
【０１３５】
端末及び基地局はＲＲＣ  ｓｉｇｎａｌｉｎｇなどを介して一定区間内のＳＲ送信基盤ビットマップに対応するＰ−ＢＳＩを設定する。ここで、Ｐ−ＢＳＩは第１実施形態でのＰ−ＢＳＩと同一の意味を有する。即ち、端末が送信すべきＵＬデータの大きさがどの範囲に属するかに対する情報を示す。
【０１３６】
図１１は、本発明の第２−２実施形態によってＳＲ送信に係るビットマップＵＬデータのマッピング関係の例示を示す。図１１を参照すれば、ビットマップに端末のバッファ状態ＢＳを対応できる。
【０１３７】
図１１を参照すれば、３サブフレーム内のＳＲ送信基盤ビットマップが１００（ＳＲ送信ｏｎ  →  ｏｆｆ  →  ｏｆｆ）であれば端末のバッファに１２００〜１５００バイトのＵＬデータが存在することを意味する。
【０１３８】
端末及び基地局が一定区間内のＳＲ送信基盤ビットマップに対応するＰ−ＢＳＩを設定する動作は第１実施形態と類似に図５の手続きを介して成る。基地局は端末にＳＲ送信が行なわれる一定区間に対する情報を提供する。
【０１３９】
もし、端末が基地局に送信すべきＵＬデータが発生すれば次のように動作する。
【０１４０】
端末は自分のバッファ状態ＢＳを識別し、識別されたバッファ状態ＢＳがどんなＰ−ＢＳＩに対応されるか識別する。前記端末は識別されたＰ−ＢＳＩに対応する一定区間内のＳＲ送信基盤ビットマップを識別する。前記端末は現在サブフレームから一定区間の間の識別されたビットマップのようにＳＲを送信する。
【０１４１】
もし、端末のバッファ状態ＢＳが１２００〜１５００バイト間の場合、端末はこれから３サブフレーム間のＳＲ送信をｏｎ  →ｏｆｆ→ｏｆｆ形態で行う。
【０１４２】
基地局は自分とＰ−ＢＳＩを設定した端末からＳＲを受信すると、一定区間の間のどんなビットマップ形態でＳＲが受信されたか識別して端末のバッファ状態ＢＳを把握する。
【０１４３】
そして、端末のバッファ状態ＢＳを考慮してＵＬ  ｓｃｈｅｄｕｌｉｎｇを行う。
【０１４４】
基地局のＵＬ  ｓｃｈｅｄｕｌｉｎｇは具現事項であるが本発明が効果を得るためには、基地局のｓｃｈｅｄｕｌｅｒが、端末の全てのＵＬデータを第１のＵＬグラントを介して送信できるほどのリソースを端末に対して割り当てられることが好ましい。
【０１４５】
［第３実施形態］
【０１４６】
図１２乃至図１３は、本発明の第３実施形態を説明するための図面である。前記第３実施形態は多重ビットから構成されたＳＲ信号を用いてＵＬ送受信手続きを行う方法に関する。
【０１４７】
図１２は、本発明の第３実施形態によるＵＬデータ送受信方法を説明する図面である。図１２を参照すれば、ＰＵＣＣＨフォーマット４でバッファ状態情報ＢＳＲを示すＳＲを多重ビットで設定できる。
【０１４８】
現在ＬＴＥはＳＲ信号としてｏｎ−ｏｆｆ  ｋｅｙｉｎｇ  ｂａｓｅｄ  ｓｉｇｎａｌｉｎｇを用いる。これと異なり本発明ではＳＲ信号として多重ビットから構成されたＳＲ信号を提案する。これは端末のＳＲビットとバッファ状態ＢＳとの間の関係を設定して端末は自分のバッファ状態ＢＳによって特定ＳＲビットを送信する方法である。このために多様なｃｏｄｅ、ｓｅｑｕｅｎｃｅなどを活用できる。本発明はここに活用されるＳＲビット、ｃｏｄｅ、ｓｅｑｕｅｎｃｅなどに限定されない。
【０１４９】
端末及び基地局はＲＲＣ  ｓｉｇｎａｌｉｎｇなどを介してＳＲビットに対応するＰ−ＢＳＩを設定する。ここで、Ｐ−ＢＳＩは第１実施形態でのＰ−ＢＳＩと同一意味を有する。即ち、端末が送信すべきＵＬデータの大きさがどの範囲に属するかに対する情報を示す。
【０１５０】
図１３（Ａ）は、本発明の第３−１実施形態によって多重ビットから構成されたＳＲとＵＬデータのマッピング関係の例示を示す図面である。
【０１５１】
図１３（Ａ）を参照すれば、当該例示でＳＲビットが“０１００”であれば端末のバッファに２０００〜２５００バイトのＵＬデータが存在することを意味する。
【０１５２】
端末及び基地局がＳＲビットに対応するＰ−ＢＳＩを設定する動作は第１実施形態と類似に図５の手続きを介してなる。基地局は端末にＳＲ信号が何のビットから構成されているかに対する情報を提供する。
【０１５３】
もし、端末が基地局に送信すべきＵＬデータが発生すれば次のように動作する。端末は自分のバッファ状態ＢＳを識別し、識別されたバッファ状態ＢＳがどんなＰ−ＢＳＩに対応されるか識別する。前記端末は識別されたＰ−ＢＳＩに対応するＳＲビットを識別し、識別されたＳＲビットから構成されたＳＲ信号を送信する。
【０１５４】
端末が送信すべきＵＬデータが２０００〜２５００バイト範囲内に存在すれば端末はＳＲビット０１００から構成されたＳＲ信号を送信する。
【０１５５】
本発明で端末が多重ビットから構成されたＳＲ信号を送信する時、ＢＰＳＫ、ＱＰＳＫ、ＱＡＭ  など多様なｍｏｄｕｌａｔｉｏｎ方法を適用できる。本発明はこれを送信する時、適用されるｍｏｄｕｌａｔｉｏｎ  及びｃｏｄｉｎｇ方法によって限定されない。
【０１５６】
基地局はＳＲ信号を受信してＳＲビットを識別して端末のバッファ状態ＢＳを把握する。
【０１５７】
そして、端末のバッファ状態ＢＳを考慮してＵＬ  ｓｃｈｅｄｕｌｉｎｇを行う。
【０１５８】
＜追加１＞
【０１５９】
本発明ではＳＲ信号が多重ビットから構成されている時、当該ビットの組合せを端末のバッファ状態ＢＳに対応させる方案を提案した。従って、基地局がＳＲ信号を受信した時端末のＵＬ送信必要可否だけではなくバッファ状態情報ＢＳＲまで把握するようにして基地局が端末に適合した大きさのＵＬリソースを迅速に割り当てできるようにした。これと同様な原理で本発明ではＳＲ信号を構成する多重ビットの組合せをバッファ状態ＢＳだけでなく多様な情報に対応できるようにする。これは次の例を含む。
【０１６０】
Ｉ．ＳＲ信号を構成する多数ビットの組合せは端末が送信しようとするｔｒａｆｆｉｃの種類に対応できる。
【０１６１】
ａ．ここでｔｒａｆｆｉｃ種類とは、ｖｏｉｃｅ、ｖｉｄｅｏ、ｔｅｘｔ  ｍｅｓｓａｇｅ、ＦＴＰ、ＨＴＴＰなどになり得る。
【０１６２】
ｂ．基地局が特定ｔｒａｆｆｉｃ種類に対応するＳＲ信号を端末から受信すれば基地局は端末が当該ｔｒａｆｆｉｃを送信するのに適合した時間／周波数／空間／ｎｕｍｅｒｏｌｏｇｙ／ＴＴＩリソースを端末に割り当てる。
【０１６３】
ＩＩ．ＳＲ信号を構成する多重ビットの組合せは端末が送信しようとするＵＬ  ｄａｔａを生成したサービス又はａｐｐｌｉｃａｔｉｏｎの種類に対応できる。
【０１６４】
ａ．ここでサービス又はａｐｐｌｉｃａｔｉｏｎ種類とは、例えば、ＳＮＳ（Ｓｏｃｉａｌ  Ｎｅｔｗｏｒｋｉｎｇ  Ｓｅｒｖｉｃｅ）、Ｖ２Ｖ（Ｖｅｈｉｃｌｅ−ｔｏ−Ｖｅｈｉｃｌｅ）、Ｖ２Ｉ（Ｖｅｈｉｃｌｅ−ｔｏ−Ｉｎｆｒａ  ｓｔｒｕｃｔｕｒｅ）、Ｖ２Ｐ  （Ｖｅｈｉｃｌｅ−ｔｏ−Ｐｅｒｓｏｎ）、ニュースなどになり得る。
【０１６５】
ｂ．基地局が特定サービス又はａｐｐｌｉｃａｔｉｏｎ種類に対応するＳＲ信号を端末から受信すれば基地局は端末が当該サービス又はａｐｐｌｉｃａｔｉｏｎから発生したｄａｔａを送信するのに適合した時間／周波数／空間／ｎｕｍｅｒｏｌｏｇｙ／ＴＴＩリソースを端末に割り当てる。
【０１６６】
ＩＩＩ．ＳＲ信号を構成する多重ビットの組合せは端末が送信しようとするＵＬ  ｄａｔａが属した  Ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌに対応できる。
【０１６７】
ａ．基地局が特定Ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌに対応するＳＲ信号を端末から受信すれば基地局は端末が当該ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌで発生したｄａｔａを送信するのに適合した時間／周波数／空間／ｎｕｍｅｒｏｌｏｇｙ／ＴＴＩリソースを端末に割り当てる。
【０１６８】
ＩＶ．ＳＲ信号を構成する多重ビットの組合せは端末が送信しようとするＵＬ  ｄａｔａが属したｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ｇｒｏｕｐに対応できる。
【０１６９】
ａ．基地局が特定ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ｇｒｏｕｐに対応するＳＲ信号を端末から受信すれば基地局は端末が当該ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ｇｒｏｕｐで発生したｄａｔａを送信するのに適合した時間／周波数／空間／ｎｕｍｅｒｏｌｏｇｙ／ＴＴＩリソースを端末に割り当てる。
【０１７０】
Ｖ．ＳＲ信号を構成する多重ビットの組合せは端末が送信しようとするＵＬ  ｄａｔａが属したｎｅｔｗｏｒｋ  ｓｌｉｃｅに対応できる。ここでｎｅｔｗｏｒｋ  ｓｌｉｃｅとは、例えば、ｅＭＢＢ（ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  ＢｒｏａｄＢａｎｄ）  ｓｌｉｃｅ、ＵＲＬＬＣ（Ｕｌｔｒａ  Ｒｅｌｉａｂｌｅ＆Ｌｏｗ  Ｌａｔｅｎｃｙ（低レイテンシ）  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）ｓｌｉｃｅ、ｍＭＴＣ  （ｍａｓｓｉｖｅ  Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）ｓｌｉｃｅ  などになり得る。
【０１７１】
ａ．基地局が特定ｎｅｔｗｏｒｋ  ｓｌｉｃｅに対応するＳＲ信号を端末から受信すれば基地局は端末が当該ｎｅｔｗｏｒｋ  ｓｌｉｃｅで発生したｄａｔａを送信するのに適合した時間／周波数／空間／ｎｕｍｅｒｏｌｏｇｙ／ＴＴＩリソースを端末に割り当てる。
【０１７２】
ＶＩ．ＳＲ信号を構成する多重ビットの組合せは端末が送信しようとするＵＬ  ｄａｔａの送受信に適合したｎｕｍｅｒｏｌｏｇｙに対応できる。
【０１７３】
ａ．ここで、ｎｕｍｅｒｏｌｏｇｙとはｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇなどを意味するのに（１５＊２）ｍｋＨｚ、即ち、１５ｋＨｚ（ｍ＝０）、３０ｋＨｚ（ｍ＝１）、６０ｋＨｚ（ｍ＝２）、１２０ｋＨｚ（ｍ＝３）などになり得、１５＊ｎｋＨｚ、即ち、１５ｋＨｚ（ｎ＝１）、３０ｋＨｚ（ｎ＝２）、４５ｋＨｚ（ｎ＝３）、６０ｋＨｚ（ｎ＝４）など多様な方法に表現される値のうちの一部となり得る。
【０１７４】
ｂ．基地局が特定ｎｕｍｅｒｏｌｏｇｙに対応するＳＲ信号を端末から受信すれば基地局は当該ｎｕｍｅｒｏｌｏｇｙに対応する時間／周波数／空間リソースを端末に割り当てる。
【０１７５】
ＶＩＩ．ＳＲ信号を構成する多重ビットの組合せは端末が送信しようとするＵＬ  ｄａｔａの送受信に適合したＴＴＩ長さに対応できる。
【０１７６】
ａ．ここで、ＴＴＩ長さとはサブフレーム長さ、ｓｌｏｔ長さ、ｍｉｎｉ−ｓｌｏｔ長さ、ＰＤＣＣＨのような制御チャンネルの送信周期などを意味するのに例えば  １／２ｍｍｓ、即ち、１ｍｓ（ｍ＝０）、０．５ｍｓ（ｍ＝１）、０．２５ｍｓ（ｍ＝２）、０．１２５ｍｓ（ｍ＝３）など多様な方法に表現される値のうちの一部となり得る。
【０１７７】
ｂ．基地局が特定ＴＴＩ長さに対応するＳＲ信号を端末から受信すれば基地局は当該ＴＴＩ長さに対応する時間／周波数／空間リソースを端末に割り当てる。
【０１７８】
ＶＩＩＩ．ＳＲ信号を構成する多重ビットの組合せは端末が送信しようとするＵＬ  ｄａｔａのレイテンシ（ｌａｔｅｎｃｙ）要求事項に対応できる。
【０１７９】
ａ．ここで、レイテンシ要求事項は時間単位（ｓ又はｍｓ）又はサブフレーム単位などで表現できる。これは（ｉ）端末がＳＲ信号を送信する時点から基地局からＵＬリソースを割り当てられる時点の間の最大許容時間又は（ｉｉ）端末がＳＲ信号を送信する時点から端末がＵＬ  ｄａｔａを送信する時点の間の最大許容時間などを意味し得る。
【０１８０】
ｂ．基地局が特定のレイテンシ要求事項に対応するＳＲ信号を端末から受信すれば基地局は端末がＵＬ  ｄａｔａ送信時のレイテンシ要求事項を満足するのに適合した時間／周波数／空間／ｎｕｍｅｒｏｌｏｇｙ／ＴＴＩリソースを端末に割り当てる。
【０１８１】
ＩＸ．ＳＲ信号を構成する多重ビットの組合せは端末が送信しようとするＵＬ  ｄａｔａのＱＣＩ（ＱｏＳ  Ｃｌａｓｓ  Ｉｄｅｎｔｉｆｉｅｒ）に対応できる。
【０１８２】
ａ．ここで、ＱＣＩは以下の表６のようにＬＴＥに定義されているＱＣＩを包含できる。
【０１８３】
【表６】
2019532538.tif 000005
【０１８４】
ｂ．基地局が特定ＱＣＩに対応するＳＲ信号を端末から受信すれば基地局は端末が当該ＱＣＩを満足するのに適合した時間／周波数／空間／ｎｕｍｅｒｏｌｏｇｙ／ＴＴＩリソースを端末に割り当てる。
【０１８５】
Ｘ．ＳＲ信号を構成する多重ビットの組合せは今まで説明した多様な要素（即ち、端末のバッファ状態ＢＳ、ＵＬ  ｔｒａｆｆｉｃ種類、ｓｅｒｖｉｃｅ又はａｐｐｌｉｃａｔｉｏｎ  種類、ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ、ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ｇｒｏｕｐ、ｎｅｔｗｏｒｋ  ｓｌｉｃｅ、ｎｕｍｅｒｏｌｏｇｙ、ＴＴＩ  長さ、レイテンシ要求事項、ＱｏＳ  ｃｌａｓｓ  ｉｄｅｎｔｉｆｉｅｒ）の組合せに対応できる。
【０１８６】
＜追加２＞
【０１８７】
本発明ではＳＲ信号が多重ビットから構成されている時に当該ビットの組合せを端末のバッファ状態ＢＳに対応させる方法を提案した。また＜追加１＞でＳＲ信号を構成する多重ビットの組合せが多様な情報に対応できるようにした。  このような拡張を本発明で提案した全ての方法に適用しようとする。
【０１８８】
本発明では多重ビットから構成されたＳＲ信号を用いる方法外にも（ａ）ＳＲ信号を互いに異なる時間又は周波数又はｃｏｄｅリソースを介して送信する方法及び（ｂ）ＳＲ信号を連続的に送信する方法を提案した。
従って、本発明では互いに異なるＳＲ時間又は周波数又はｃｏｄｅリソース各々が端末のバッファ状態ＢＳ、ＵＬ  ｔｒａｆｆｉｃ  種類、ｓｅｒｖｉｃｅ又はａｐｐｌｉｃａｔｉｏｎ種類、ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ、ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ｇｒｏｕｐ、ｎｅｔｗｏｒｋ  ｓｌｉｃｅ、ｎｕｍｅｒｏｌｏｇｙ、ＴＴＩ  長さ、レイテンシ要求事項、ＱｏＳ  ｃｌａｓｓ  ｉｄｅｎｔｉｆｉｅｒ又はこれらの組合せなどに対応できる。
【０１８９】
さらに、ＳＲ信号の連続送信回数が端末のバッファ状態ＢＳ、ＵＬ  ｔｒａｆｆｉｃ種類、ｓｅｒｖｉｃｅ又はａｐｐｌｉｃａｔｉｏｎ種類、ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ、ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ｇｒｏｕｐ、ｎｅｔｗｏｒｋ  ｓｌｉｃｅ、ｎｕｍｅｒｏｌｏｇｙ、ＴＴＩ長さ、レイテンシ要求事項、ＱｏＳ  ｃｌａｓｓ  ｉｄｅｎｔｉｆｉｅｒ又はこれらの組合せなどに対応できる。このような対応関係が図１３（Ｃ）に表現されている。
【０１９０】
基地局のＵＬスケジューリングは、システムの具現化状況に依存する事項だが、本発明が効果を得るためには、基地局のスケジューラが、端末の全てのＵＬデータを最初のＵＬグラントを介して送信できるほどのリソースを端末に対して割り当てられることが好ましい。
【０１９１】
今まで本発明を説明する時、毎サブフレームごとに端末に割り当てられたＳＲリソースがあることを仮定した。しかし、本発明はサブフレームごとに端末に割り当てられたＳＲリソースが存在しなくてもＳＲリソースごとにＰ−ＢＳＩを割り当てることによって適用できる。
【０１９２】
図１３（Ｂ）は、本発明の第３−２実施形態によってコード基盤ＳＲとＵＬデータのマッピング関係の例示を示す。
【０１９３】
図１３（Ｂ）を参照すれば、ｃｏｄｅ基盤ＳＲを活用して自分のバッファ状態ＢＳに従って特定ｃｏｄｅを送信できる。例えば、Ｃｏｄｅ２がＳＲで用いられる端末のバッファに５００〜１０００バイトのＵＬデータが存在することを意味する。
【０１９４】
端末及び基地局はＲＲＣ  ｓｉｇｎａｌｉｎｇなどを介してｃｏｄｅ基盤ＳＲに対応するＰ−ＢＳＩを設定する。ここで、Ｐ−ＢＳＩは第１実施形態でのＰ−ＢＳＩと同一の意味を有する。即ち、端末が送信すべきＵＬデータの大きさがどの範囲に属するかに対する情報を示す。
【０１９５】
端末及び基地局が各ｃｏｄｅに対応するＰ−ＢＳＩを設定する動作は実施形態１と同様に以下の手続きを介してなる。
【０１９６】
基地局は端末にＳＲ−ｂａｓｅｄ  ＢＳ  ｌｅｖｅｌ数を決定して各ＢＳ  ｌｅｖｅｌに対応するｃｏｄｅを割り当てる。端末は各ＢＳｌｅｖｅｌに対応するバッファ状態ＢＳの範囲を基地局に通知する。
【０１９７】
もし、端末が基地局に送信すべきＵＬデータが発生すれば次のように動作する。端末は自分のバッファ状態ＢＳを識別し、識別されたバッファ状態ＢＳがどんなＰ−ＢＳＩに対応されるか識別する。前記端末は識別されたＰ−ＢＳＩに対応するＳＲ用ｃｏｄｅを識別し、識別されたｃｏｄｅから構成されたＳＲ信号を送信する。
【０１９８】
基地局はＳＲ用ｃｏｄｅを受信してこれを識別して端末のバッファ状態ＢＳを把握する。そして、端末のバッファ状態ＢＳを考慮してＵＬ  ｓｃｈｅｄｕｌｉｎｇを行う。
【０１９９】
基地局のＵＬ  ｓｃｈｅｄｕｌｉｎｇは具現事項だが本発明が効果を得るためには、基地局のｓｃｈｅｄｕｌｅｒが、端末の全てのＵＬデータを第１のＵＬグラントを介して送信できるほどのリソースを端末に対して割り当てられることが好ましい。
【０２００】
図１４乃至図２０は、本発明の実施形態によってＳＲリソースにバッファ状態（ＢＳ）インデクスを設定する過程を説明する図面である。
【０２０１】
図１４は、本発明の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す。この時、前記ＢＳインデクスは前述したＰ−ＢＳＩを意味する。
【０２０２】
図１４では端末に２サブフレームごとにＳＲリソースが割り当てられた状態を示す。サブフレーム内で割り当てられるＳＲリソース（１４０１〜１４１１）各々に順次にＰ−ＢＳＩを割り当てできる。
【０２０３】
図１５は、本発明の他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【０２０４】
図１５ではｎｏｒｍａｌ  ＴＴＩとｓｈｏｒｔ  ＴＴＩが一つのサブフレームに共存して１ｎｏｒｍａｌ  ＴＴＩごとにＳＲリソース（１５０１〜１５０５）が割り当てられ、２ｓｈｏｒｔ  ＴＴＩ  ごとにＳＲリソース（１５０７〜１５１７）が割り当てられた状態を示す。もし、総Ｐ−ＢＳＩ  ｌｅｖｅｌの数が６の場合には一つのサブフレーム内でｓｈｏｒｔ  ＴＴＩのＳＲリソース（例えば、１５０７、１５０９）にＰ−ＢＳＩが優先的に割り当てられ、ｎｏｒｍａｌ  ＴＴＩのＳＲリソース（例えば、１５０１）にＰ−ＢＳＩを後で割り当てできる。
【０２０５】
図１６は、本発明のまた他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す。
【０２０６】
図１６ではｎｏｒｍａｌ  ＴＴＩとｓｈｏｒｔ  ＴＴＩが一つのサブフレームに共存して１ｎｏｒｍａｌ  ＴＴＩごとにＳＲリソース（１６０１〜１６０５）が割り当てられ、２ｓｈｏｒｔ  ＴＴＩごとにＳＲリソース（１６０４〜１６１７）が割り当てられた状態を示す。総Ｐ−ＢＳＩ  ｌｅｖｅｌの数が６の場合には一つのサブフレーム内でｎｏｒｍａｌ  ＴＴＩのＳＲリソース（例えば、１６０１）にＰ−ＢＳＩが優先的に割り当てられ、ｓｈｏｒｔ  ＴＴＩのＳＲリソース（例えば、１６０７、１６０９）に  Ｐ−ＢＳＩを後で割り当てできる。
【０２０７】
図１７は、本発明のまた他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す。
【０２０８】
図１７は、ｎｏｒｍａｌ  ＴＴＩとｓｈｏｒｔ  ＴＴＩが一つのサブフレームに共存して１ｎｏｒｍａｌ  ＴＴＩごとにＳＲリソース（１７０１〜１７０５）が割り当てられ、２ｓｈｏｒｔ  ＴＴＩごとにＳＲリソース（１７０７〜１７１７）が割り当てられた状態を示す。
【０２０９】
もし、総Ｐ−ＢＳＩｌｅｖｅｌの数が６の場合には一つのサブフレーム内で時間的に先ず存在するＳＲリソースのうちでｓｈｏｒｔ  ＴＴＩのＳＲリソース（例えば、１７０７）にＰ−ＢＳＩが優先的に割り当てられてｎｏｒｍａｌ  ＴＴＩのＳＲリソース（例えば、１７０１）にＰ−ＢＳＩを後で割り当てできる。
【０２１０】
図１８は、本発明のまた他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【０２１１】
図１８はｎｏｒｍａｌ  ＴＴＩとｓｈｏｒｔ  ＴＴＩが一つのサブフレームに共存して１ｎｏｒｍａｌ  ＴＴＩごとにＳＲリソース（１８０１〜１８０５）が割り当てられ、２ｓｈｏｒｔ  ＴＴＩごとにＳＲリソース（１８０７〜１８１７）が割り当てられた状態を示す。
【０２１２】
もし、総Ｐ−ＢＳＩ  ｌｅｖｅｌの数が６の場合には時間的に先ず存在するＳＲリソース（例えば、１８０７、１８０９）にＰ−ＢＳＩが優先的に割り当てられて時間的に後で存在するＳＲリソースに  Ｐ−ＢＳＩ（例えば、１８０１）を後で割り当てできる。
【０２１３】
図１９は、本発明のまた他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【０２１４】
図１９ではｎｏｒｍａｌ  ＴＴＩとｓｈｏｒｔ  ＴＴＩが一つのサブフレームに共存して１ｎｏｒｍａｌ  ＴＴＩごとにＳＲリソース（１９０１〜１９０５）が割り当てられ、２ｓｈｏｒｔ  ＴＴＩごとにＳＲリソース（１９０７〜１９１７）が割り当てられた状態を示す。もし、総Ｐ−ＢＳＩ  ｌｅｖｅｌの数が４の場合にはｓｈｏｒｔ  ＴＴＩに存在するＳＲリソース（例えば、１９０７、１９０９）には  Ｐ−ＢＳＩが割り当てられてｎｏｒｍａｌ  ＴＴＩに存在するＳＲリソース（例えば、１９０１）には  Ｐ−ＢＳＩが割り当てられないこともある。
【０２１５】
図２０は、本発明のまた他の実施形態によってＳＲリソースにＢＳインデクスを設定する過程を示す図面である。
【０２１６】
図２０ではｎｏｒｍａｌ  ＴＴＩとｓｈｏｒｔ  ＴＴＩが一つのサブフレームに共存して１ｎｏｒｍａｌ  ＴＴＩごとにＳＲリソース（２００１〜２００５）が割り当てられ、２ｓｈｏｒｔ  ＴＴＩごとにＳＲリソース（２００７〜２０１７）が割り当てられた状態を示す。
【０２１７】
もし、総Ｐ−ＢＳＩ  ｌｅｖｅｌの数が４の場合には前記の図のようにｎｏｒｍａｌ  ＴＴＩに存在するＳＲリソース（例えば、２００１）にはＰ−ＢＳＩが割り当てられてｓｈｏｒｔ  ＴＴＩに存在するＳＲリソース（例えば、２００７、２００９）にはＰ−ＢＳＩが割り当てられないこともある。
【０２１８】
図１４乃至図２０ではｎｏｒｍａｌ  ＴＴＩとｓｈｏｒｔ  ＴＴＩが共存する時、Ｐ−ＢＳＩがどんな規則によって割り当てられるかに対する多様な例示を説明した。
【０２１９】
これを要約すれば次の通りである。
【０２２０】
＜一つのＴＴＩ種類だけ用いられる場合＞
【０２２１】
割り当てられたＳＲリソース順にＰ−ＢＳＩを割り当てる。
【０２２２】
＜Ｎｏｒｍａｌ  ＴＴＩとｓｈｏｒｔ    ＴＴＩが共に用いられる場合＞
【０２２３】
規則１：一つのサブフレーム（又は一つのｎｏｒｍａｌ  ＴＴＩ）内で先ずｓｈｏｒｔ  ＴＴＩに割り当てられたＳＲリソース順にＰ−ＢＳＩを割り当てて、その後にｎｏｒｍａｌ  ＴＴＩに割り当てられたＳＲリソース順にＰ−ＢＳＩを割り当てる。
【０２２４】
規則２：一つのサブフレーム（又は一つのｎｏｒｍａｌ  ＴＴＩ）内で先ずｎｏｒｍａｌ  ＴＴＩに割り当てられたＳＲリソース順にＰ−ＢＳＩを割り当てて、その後にｓｈｏｒｔ  ＴＴＩに割り当てられたＳＲリソース順にＰ−ＢＳＩを割り当てる。
【０２２５】
規則３：一つのサブフレーム（又は一つのｎｏｒｍａｌ  ＴＴＩ）内で時間的に先ず割り当てられたＳＲリソース順にＰ−ＢＳＩを割り当てるがｓｈｏｒｔ  ＴＴＩのＳＲリソースとｎｏｒｍａｌ  ＴＴＩのＳＲリソースが同時に存在する場合、ｓｈｏｒｔ  ＴＴＩのＳＲリソースに先ずＰ−ＢＳＩを割り当てる。
【０２２６】
規則４：一つのサブフレーム（又は一つのｎｏｒｍａｌ  ＴＴＩ）内で時間的に先ず割り当てられたＳＲリソース順にＰ−ＢＳＩを割り当てるがｓｈｏｒｔ  ＴＴＩのＳＲリソースとｎｏｒｍａｌ  ＴＴＩのＳＲリソースが同時に存在する場合、ｎｏｒｍａｌ  ＴＴＩのＳＲリソースに先ずＰ−ＢＳＩを割り当てる。
【０２２７】
規則５：Ｓｈｏｒｔ  ＴＴＩに割り当てられたＳＲリソースにだけその順にＰ−ＢＳＩを割り当てる。
【０２２８】
規則６：Ｎｏｒｍａｌ  ＴＴＩに割り当てられたＳＲリソースにだけその順にＰ−ＢＳＩを割り当てる。
【０２２９】
本発明では基地局と端末が前記の規則を互いに共有するようにする。これはＲＲＣｓｉｇｎａｌｉｎｇ（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージなど）などを介して基地局が現在運営中のｆｒａｍｅ  ｓｔｒｕｃｔｕｒｅ及び端末に割り当てられたＳＲリソースに従って規則インデクスを端末に伝達されるようにする。
【０２３０】
ここで、基地局と端末は各インデクスに該当する規則の内容を予め定められた規格などを介して事前に分かっている場合もある。
【０２３１】
［第４実施形態］
【０２３２】
図２１乃至図２２は、本発明の第４実施形態を説明するための図面である。
【０２３３】
今まで本発明は時間領域でＳＲ送信時点とＰ−ＢＳＩ間の関係を設定して端末が自分のバッファ状態ＢＳによってＳＲ送信時点を調節するようにした。
【０２３４】
同様な原理を介して本発明は周波数領域で端末に割り当てられた多重ＳＲリソースが存在する時に同一時点及び互いに異なる周波数に存在する各ＳＲリソースとＰ−ＢＳＩ間の関係を設定して端末が自分のバッファ状態ＢＳに従ってＳＲ送信リソースを選択するようにする。
【０２３５】
図２１は、本発明の第４−１実施形態によるＵＬデータ送受信方法を説明する図面である。
【０２３６】
図２１を参照すれば、端末は一つのサブフレーム  私の同一時点及び互いに異なる周波数に４個のＳＲリソースを割り当てできる。各ＳＲリソースは  ０＜ＢＳ（バッファ状態）＜１０００バイト、１０００＜ＢＳ＜２０００バイト、２０００＜ＢＳ＜３０００バイト、３０００＜ＢＳ＜４０００バイトの  Ｐ−ＢＳＩ各々に対応される。
【０２３７】
もし、端末に２５００バイトのＵＬデータが発生した場合、端末は４個のリソース（２１０１〜２１０７）のうちで第３ＳＲリソース２１０５を介してＳＲを送信する。基地局は端末から第３ＳＲリソース２０１５を介してＳＲを受信すれば端末のバッファ状態ＢＳを把握し、これを考慮してＵＬ  ｓｃｈｅｄｕｌｉｎｇを行うことができる。
【０２３８】
ここで端末及び基地局は第１実施形態の図５のように各々のＳＲリソースに対応するＰ−ＢＳＩを設定する過程を行うことができる。この時、基地局は端末に周波数領域で総幾のＳＲリソースが割り当てられるかに対する情報を通知するようにする。
【０２３９】
図２２は、本発明の第４−２実施形態によるＵＬデータ送受信方法を説明する図面である。
【０２４０】
同様な原理を介して本発明は時間及び周波数領域で端末に割り当てられた多重ＳＲリソースが存在する時、互いに異なる時間及び周波数に存在する各ＳＲリソースとＰ−ＢＳＩ間の関係を設定して端末が自分のバッファ状態ＢＳによってＳＲ送信リソースを選択するようにできる。
【０２４１】
図２２を参照すれば、端末は一つのサブフレーム内の互いに異なる時間及び周波数に８個のＳＲリソースを割り当てられた。また、各ＳＲリソース（２２０１〜２２１５）は０＜ＢＳ＜５００バイト、５００＜ＢＳ＜１０００バイト、１０００＜ＢＳ＜１５００バイト、１５００＜ＢＳ＜２０００バイト、２０００＜ＢＳ＜２５００バイト、２５００＜ＢＳ＜３０００バイト、３０００＜ＢＳ＜３５００バイト、３５００＜ＢＳ＜４０００バイトの  Ｐ−ＢＳＩに対応される。
【０２４２】
もし、端末が３３００バイトのＵＬデータが発生した場合、８個のＳＲリソース（２２０１〜２２１５）のうちの第７ＳＲリソース２２１３を介してＳＲを送信するようになる。基地局は端末から第７ＳＲリソース２２１３を介してＳＲを受信すれば端末のバッファ状態ＢＳを把握し、これを考慮してＵＬ    ｓｃｈｅｄｕｌｉｎｇを行う。
【０２４３】
この時、端末及び基地局は第１実施形態の図５のように各々のＳＲリソースに対応するＰ−ＢＳＩを設定する過程を行うことができる。
【０２４４】
この時、基地局は端末に時間及び周波数領域で総幾のＳＲリソースが割り当てられるかに対する情報を通知するようにする。
【０２４５】
［第５実施形態］
【０２４６】
図２３乃至図２７は、本発明の第５実施形態を説明するための図面である。
【０２４７】
本発明で端末はＳＲ送信後に基地局からＵＬグラントを受信して自分に割り当てられたＵＬリソースを介してＢＳＲ又はデータを送信する動作を考慮した。しかし、最近ｎｏｎ−ｏｒｔｈｏｇｏｎａｌ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ（ＮＯＭＡ、ｐｏｗｅｒ  ｄｏｍａｉｎ、ｃｏｄｅ  ｄｏｍａｉｎ、その他のｄｏｍａｉｎ  ＮＯＭＡ全部含み）  技術が活発に研究されているので端末はＳＲ送信なしに基地局にＢＳＲ又はデータを送信なし得る。
【０２４８】
図２３は、本発明の第５−１実施形態によるＵＬ送受信方法を説明する図面である。第５−１実施形態はＮＯＭＡを用いたＳＲを送信してＵＬグラントを受信する方法に関する。
【０２４９】
図２３を参照すれば、各端末にＳＲリソースをｄｅｄｉｃａｔｅｄするように割り当てるのではなく多重端末が（基地局によって事前にｐａｉｒｉｎｇされた端末ｇｒｏｕｐ又は事前にｐａｉｒｉｎｇされない任意の端末）共通のリソースを介してＳＲ信号を送信する動作を示す。各端末にＳＲリソースをｄｅｄｉｃａｔｅｄするように割り当てることはリソース活用側面でｏｖｅｒｈｅａｄと見られる。従って、ＳＲリソースをＮＯＭＡ基盤で送信するようになればこのようなｏｖｅｒｈｅａｄを減らすことができるという長所がある。
【０２５０】
図２４は、本発明の第５−２実施形態によるＵＬ送受信方法を説明する図面である。第５−２実施形態はＮＯＭＡを用いたＢＳＲを送信してＵＬグラントを受信する方法に関する。
【０２５１】
図２５は、本発明の第５−３実施形態によるＵＬ送受信方法を説明する図面である。第５−３実施形態はＮＯＭＡを用いて全てのデータを送信する方法に関する。
【０２５２】
このような動作のために先ず基地局は一つ以上の端末をｐａｉｒｉｎｇする動作を行う。Ｐａｉｒｉｎｇされた端末は同一時間及び周波数リソースを介して信号を送信しても基地局がｃｏｄｅ  ｄｏｍａｉｎ、ｐｏｗｅｒ  ｄｏｍａｉｎ又はその他のｄｏｍａｉｎでＳＩＣ（Ｓｕｃｃｅｓｓｉｖｅ  Ｉｎｔｅｒｆｅｒｅｎｃｅ  Ｃａｎｃｅｌｌａｔｉｏｎ）を行ってｐａｉｒｉｎｇされた端末が送信した信号を互いに区分した後にｄｅｃｏｄｉｎｇできる。しかし、ＮＯＭＡ技術によって端末ｐａｉｒｉｎｇ  過程が必要ではない場合もあり得る。
【０２５３】
ＮＯＭＡ技術を用いると、ＳＲ及びＵＬグラント手続きなしでもＵＬデータを送信できる。もし、送信すべきＵＬデータの大きさが第１のＮＯＭＡ送信のために割り当てられたリソースで送信するのに相対的に大きければ端末は送信すべきＵＬデータの一部とＢＳＲを、ＮＯＭＡ送信を介して基地局に送信する。これを受信した基地局はＢＳＲに含まれた端末のバッファ状態情報ＢＳＲを基盤で端末に十分な量のリソースを割り当てて端末が迅速にＵＬ送信を完了するようにする。
【０２５４】
図２６は、本発明の実施形態によってＳＲリソースとＮＯＭＡ基盤ＳＲリソースが共存する状況を示す図面であり、図２７は、本発明の他の実施形態によってＳＲリソースとＮＯＭＡ基盤ＳＲリソースが共存する状況を示す図面である。
【０２５５】
この時、（ａ）特定端末に専用に割り当てられた既存のＳＲリソースと（ｂ）ＮＯＭＡ基盤とするが１つ以上の端末に共通に割り当てられた新規ＳＲリソースが  サブフレーム別に（図２６）又はサブフレーム内のｓｈｏｒｔ／ｎｏｒｍａｌ  ＴＴＩ別に（図２７）共存する状況を示す。このために基地局は端末に（ａ）のようなＳＲリソースに対するｃｏｎｆｉｇｕｒａｔｉｏｎ情報と（ｂ）のようなＳＲリソースに対するｃｏｎｆｉｇｕｒａｔｉｏｎ情報を通知する。ここで、ｃｏｎｆｉｇｕｒａｔｉｏｎ情報とはＳＲリソースが存在する時間（ｓｙｍｂｏｌ、ｓｌｏｔ、ＴＴＩ、サブフレーム、ｆｒａｍｅなど）、周波数（ｓｕｂｃａｒｒｉｅｒ、ＲＥ、ＲＢ、ｓｕｂｂａｎｄなど）、周期及び種類  （ａ又はｂ）などであり得る。
【０２５６】
本発明では５Ｇ移動通信システムでのＳＲ動作に対して説明している。５Ｇ移動通信システムでは一つのｒａｄｉｏ  ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ及びｃｏｒｅ  ｎｅｔｗｏｒｋで多数のサービスがサポートされることで予想される。例えば、サービス１はｅＭＢＢ（ｅｎｈａｎｃｅｄ  ｍｏｂｉｌｅ  ｂｒｏａｄｂａｎｄ）、サービス２はＵＲＬＬＣ  （ｕｌｔｒａ−ｒｅｌｉａｂｌｅ  ａｎｄ  ｌｏｗ−Ｌａｔｅｎｃｙ（低レイテンシ）  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、サービス３はｅＭＴＣ  （ｅｎｈａｎｃｅｄ  ＭＴＣ）であり得る。この外にも他のサービスが追加にサポートされ得る。これら各々のサービスは互いに異なるｐｈｙｓｉｃａｌ  ｌａｙｅｒ特性を有し得る（例えば、ｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇ）。従って、基地局は端末にサービス別の独立的なＳＲリソースが割り当てでき、全てのサービスに共通的に使用できるＳＲリソースを割り当てできる。
【０２５７】
図２８は、本発明の実施形態によってサービス別でＳＲリソースが用いられることを説明する図面である。図２８を参照すれば、端末に割り当てられた全てのＳＲリソース（２８０１〜２８１９）は全てのサービスに共通的に使用できる。
【０２５８】
図２９は、本発明の他の実施形態によってサービス別でＳＲリソースが用いられることを説明する図面である。図２９を参照すれば、端末に割り当てられた各々のＳＲリソース（２９０１〜２９１９）を当該サービスに対応して使用できる。
【０２５９】
図３０は、本発明のまた他の実施形態によってサービス別でＳＲリソースが用いられることを説明する図面である。図３０を参照すれば、互いに異なる種類のＴＴＩに存在するＳＲリソースのうちの一部は全てのサービスに共通的に用いられるように設定されており、一部は各サービスに対応して用いられるように設定できる。
【０２６０】
図３１は、本発明の実施形態によるＳＲ送受信手続きを説明する図面である。
【０２６１】
図３１を参照すれば、Ｓ３１００段階で端末はＵＥｃａｐａｂｉｌｉｔｙ情報交換時自分が使用する（又は使用できる）サービス情報を基地局に提供する。
【０２６２】
Ｓ３１１０段階で、基地局は端末が用いるサービスを把握した後、ｃｏｍｍｏｎ  ＳＲ又はｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ情報を端末に提供する。これは以下の表６に示す「ＳｃｈｅｄｕｌｉｎｇＲｅｑｕｅｓｔＣｏｎｆｉｇ」（ＳＲ（スケジューリング要求）構成）のような形式を介して実行できる。
【０２６３】
【表７】
2019532538.tif 000006
【０２６４】
もし、端末がＮ個の互いに異なるサービスを用いると、基地局は端末に各サービス別で１個又はその以上又はその以下のｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソースを割り当てできる。
【０２６５】
また、０個又は１個又はその以上のｃｏｍｍｏｎ  ＳＲリソースを割り当てできる。
【０２６６】
Ｓ３１２０段階で、端末は基地局からＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ情報を受信した後、特定サービスに該当するＵＬ  ｔｒａｆｆｉｃが発生すれば自分に割り当てられたＳＲリソースのうちで一つを選択して基地局にＳＲを送信する。
【０２６７】
＜端末が１個のサービスを用いる場合＞
【０２６８】
端末は当該サービスのために割り当てられたｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソースを介して基地局にＳＲを送信できる。
【０２６９】
また、端末はｃｏｍｍｏｎ  ＳＲリソースを介して基地局にＳＲを送信できる。
【０２７０】
Ｃｏｍｍｏｎ  ＳＲリソースの活用は、例えば、端末にＴ１サブフレーム後のｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソースが割り当てられているのにＴ１より短いＴ２サブフレーム後のｃｏｍｍｏｎ  ＳＲリソースが割り当てられていると、端末はｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソースの待機時間を減らすためにｃｏｍｍｏｎ  ＳＲを用いる。
【０２７１】
＜端末が２個以上のサービスを用いて端末のバッファに１個サービスのｔｒａｆｆｉｃが存在する場合＞
【０２７２】
端末は当該サービスのために割り当てられたｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソースを介して基地局にＳＲを送信できる。
【０２７３】
また、端末はｃｏｍｍｏｎ  ＳＲリソースを介して基地局にＳＲを送信できる。
【０２７４】
＜端末が２個以上のサービスを用いて端末のバッファに２個サービス以上のｔｒａｆｆｉｃが存在する場合＞
【０２７５】
端末は優先順位が高いサービスのｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソースを介して基地局にＳＲを送信できる。
【０２７６】
基地局はサービス別で優先順位を設定して端末に通知できる。
【０２７７】
例えば、サービス１が第１の優先順位に該当し、サービス２が第２の優先順位、サービス３が第３の優先順位に該当し得る。
【０２７８】
端末はサービス別で優先順位を設定して基地局に通知できる。
【０２７９】
端末は現在自分のバッファに存在する全てのサービス種類に該当するｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソースのうちで最も先ずに存在するＳＲリソースで基地局にＳＲを送信できる。
【０２８０】
また、端末は現在自分のバッファに存在する全てのサービス種類に該当するｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソースのうちで任意に一つを選択して基地局にＳＲを送信できる。
【０２８１】
また、端末は現在自分のバッファに存在する全てのサービス種類に該当するｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソース各々で基地局にＳＲを送信できる。
【０２８２】
端末はｃｏｍｍｏｎ  ＳＲリソースを介して基地局にＳＲを送信できる。
【０２８３】
Ｓ３１３０段階で、基地局は端末からＳＲを受信した後に端末にＵＬグラントを割り当てる。
【０２８４】
＜基地局がＳＲをｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソースで受信した場合＞
【０２８５】
基地局は端末が特定サービスを用いていることを把握できるしここに相応しいＵＬグラントを端末に割り当てる。
【０２８６】
＜基地局がＳＲをｃｏｍｍｏｎ  ＳＲリソースで受信した場合＞
【０２８７】
基地局は端末が用いているサービス種類を把握できないので任意のリソース大きさを含んだＵＬグラントを端末に割り当てる。
【０２８８】
端末は基地局からＵＬグラントを受信した後に基地局にデータを送信する。
【０２８９】
端末はサービス別で優先順位によって優先順位が高いサービスのｔｒａｆｆｉｃ先ず割り当てられたリソースに含ませる。
【０２９０】
また、端末が特定サービスのｔｒａｆｆｉｃを送信するために当該サービスのためのｓｅｒｖｉｃｅ−ｓｐｅｃｉｆｉｃ  ＳＲリソースを介して基地局にＳＲを送信した場合、端末は当該サービスのｔｒａｆｆｉｃ先ず割り当てられたリソースに含ませる。
【０２９１】
本発明では端末が基地局にＢＳＲを送信する時、基地局が各サービス別でＢＳＲを区分するようにする。これに対する例示は以下の通りである。
【０２９２】
以下の表２は端末が基地局に自分が使用している全てのサービス及び当該サービスに属した全てのＬＣＧに対するバッファのサイズを報告する時に適用されるｆｏｒｍａｔの例示である。
【０２９３】
【表２】
2019532538.tif 000007
【０２９４】
以下の表３は、端末が基地局に自分が使用している一部サービス及び当該サービスに属した全ての  ＬＣＧに対するバッファのサイズを報告する時に適用されるｆｏｒｍａｔの例示である。
【０２９５】
【表３】
2019532538.tif 000008
【０２９６】
以下の表４は端末が基地局に自分が使用している一つのサービス及び当該サービスに属した全ての  ＬＣＧに対するバッファのサイズを報告する時に適用されるｆｏｒｍａｔの例示である。
【０２９７】
【表４】
2019532538.tif 000009
【０２９８】
以下の表５は端末が基地局に自分が使用している一つのサービス及び該当サービスに属した一つ又は一部  ＬＣＧに対するバッファのサイズを報告する時に適用されるｆｏｒｍａｔの例示である。
【０２９９】
【表５】
2019532538.tif 000010
【０３００】
端末は全てのサービスに対するＢＳＲを基地局に報告でき、又は、以下のような方法によって選択されたサービスに対するＢＳＲを基地局に報告できる。
【０３０１】
端末はｐａｄｄｉｎｇ  ＢＳＲ送信時に現在用いているサービス種類に該当するＢＳＲを基地局に報告できる。
【０３０２】
さらに、サービス別で優先順位が存在してＢＳＲを送信するリソースの大きさが限定されていると、優先順位が高いサービス順にＢＳＲを送信できる。
【０３０３】
さらに、各サービスに対するＢＳＲを同一の頻度で基地局に報告できる。
【０３０４】
＜追加３＞
【０３０５】
本発明では端末が基地局にバッファ状態ＢＳを報告する時に現在使用している全てのサービスに対するバッファ状態ＢＳを報告する方法及び形式、特定サービスに対するバッファ状態ＢＳを報告する方法及び形式、特定ＬＣＧ  （ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ  Ｇｒｏｕｐ）に対するバッファ状態ＢＳを報告する方法及び形式などについて述べた。
【０３０６】
ＬＴＥではＬＣＧ、即ち、多重ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌから構成される一つのｇｒｏｕｐ単位でバッファ状態ＢＳを報告する。
【０３０７】
本発明では端末がより細密なバッファ状態ＢＳの情報を基地局に提供するためにＬＣＧより下位概念と見られるＬＣＨ  （ｌｏｇｉｃａｌ  ＣＨａｎｎｅｌ）単位でバッファ状態ＢＳを報告する方法を含む。
【０３０８】
これはＬＣＧ単位でバッファ状態ＢＳを報告する方法と原理は同一であるが単位がＬＣＧからＬＣＨに変更されたと見られる。
【０３０９】
以下は端末が基地局に自分が使用している全てのサービス及び当該サービスに属した全てのＬＣＧ及びＬＣＨに対するバッファ状態ＢＳを報告する時に適用されるｆｏｒｍａｔの例示である。
【０３１０】
【表８】
2019532538.tif 000011
【０３１１】
以下は端末が基地局に自分が使用している一部サービス及び当該サービスに属した全てのＬＣＧ及びＬＣＨに対するバッファ状態ＢＳを報告する時に適用されるｆｏｒｍａｔの例示である。
【０３１２】
【表９】
2019532538.tif 000012
【０３１３】
以下は端末が基地局に自分が使用している一部サービス及び当該サービスに属した一部ＬＣＧ及びそのＬＣＧに属した全てのＬＣＨに対するバッファ状態ＢＳを報告する時に適用されるｆｏｒｍａｔの例示である。
【０３１４】
【表１０】
2019532538.tif 000013
【０３１５】
以下は端末が基地局に自分が使用している一部サービス及び当該サービスに属した一部ＬＣＧ及びそのＬＣＧに属した一部ＬＣＨに対するバッファ状態ＢＳを報告する時に適用されるｆｏｒｍａｔの例示である。
【０３１６】
【表１１】
2019532538.tif 000014
【０３１７】
本発明では端末が今まで説明した多くのＢＳＲ  ｆｏｒｍａｔのうちのいずれかを用いてバッファ状態ＢＳを報告することかに関する内容を含む。
【０３１８】
Ｉ．端末がＢＳＲ送信のために基地局から割り当てられたＵＬリソースのｎｕｍｅｒｏｌｏｇｙ又はｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇに従ってＢＳＲ  ｆｏｒｍａｔを決定する。
【０３１９】
ａ．例えば、端末がｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇが６０ｋＨｚであるＵＬリソースが割り当てられると、当該ｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇに対応するＢＳＲ  ｆｏｒｍａｔを用いて基地局にバッファ状態ＢＳを報告する。ここで、ｎｕｍｅｒｏｌｏｇｙ（又はｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇ）とＢＳＲ  ｆｏｒｍａｔ間の対応関係は規格に予め定められているか基地局が端末にＲＲＣ  ｍｅｓｓａｇｅなどを介して予め通知するようにする。
【０３２０】
ＩＩ．端末がＢＳＲ送信のために基地局から割り当てられたＵＬリソースのＴＴＩ長さに従ってＢＳＲ  ｆｏｒｍａｔを決定する。
【０３２１】
ａ．例えば、端末がＴＴＩ長さ０．２５ｍｓであるＵＬリソースを割り当てられると、当該ＴＴＩ  長さに対応するＢＳＲ  ｆｏｒｍａｔを用いて基地局にバッファ状態ＢＳを報告する。
ここで、ＴＴＩ長さとＢＳＲ  ｆｏｒｍａｔ間の対応関係は規格に予め定められているか基地局が端末にＲＲＣ  ｍｅｓｓａｇｅなどを介して予め通知するようにする。
【０３２２】
ＩＩＩ．端末がＢＳＲ送信のために基地局から割り当て受けたＵＬリソースの大きさに従ってＢＳＲ  ｆｏｒｍａｔを決定する。
【０３２３】
ａ．例えば、端末が１０個のＲＢ（Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）が割り当て受けたら当該ＲＢ数に対応するＢＳＲ  ｆｏｒｍａｔを用いて基地局にバッファ状態ＢＳを報告する。ここで、ＵＬリソースの大きさとＢＳＲ  ｆｏｒｍａｔ間の対応関係は規格に予め定められているか基地局が端末に  ＲＲＣ  ｍｅｓｓａｇｅ  などを介して予め通知するようにする。
【０３２４】
ＩＶ．端末がＳＲ信号を送信する時に用いたＵＬリソースの  ｎｕｍｅｒｏｌｏｇｙ又はｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇに従ってＢＳＲ  ｆｏｒｍａｔを決定する。
【０３２５】
ａ．例えば、端末がｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇが６０ｋＨｚであるＵＬリソースを用いてＳＲ信号を送信すると、追後当該ｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇに対応するＢＳＲ  ｆｏｒｍａｔを用いて基地局にバッファ状態ＢＳを報告する。ここで、ｎｕｍｅｒｏｌｏｇｙ（又はｓｕｂｃａｒｒｉｅｒ  ｓｐａｃｉｎｇ）とＢＳＲ  ｆｏｒｍａｔ間の対応関係は規格に予め定められているか基地局が端末にＲＲＣ  ｍｅｓｓａｇｅなどを介して予め通知するようにする。
【０３２６】
Ｖ．端末がＳＲ信号を送信する時に用いたＵＬリソースのＴＴＩ長さに従ってＢＳＲ  ｆｏｒｍａｔを決定する。
【０３２７】
ａ．例えば、端末がＴＴＩ長さ０．２５ｍｓであるＵＬリソースを割り当てられると、当該ＴＴＩ  長さに対応するＢＳＲ  ｆｏｒｍａｔを用いて基地局にバッファ状態ＢＳを報告する。ここで、ＴＴＩ長さとＢＳＲ  ｆｏｒｍａｔ間の対応関係は規格に予め定められているか基地局が端末にＲＲＣ  ｍｅｓｓａｇｅなどを介して予め通知するようにする。
【０３２８】
ＶＩ．基地局が端末がバッファ状態ＢＳを報告する時に用いるＢＳＲ  ｆｏｒｍａｔをＲＲＣ  ｍｅｓｓａｇｅ又はＭＡＣＣＥ（Ｃｏｎｔｒｏｌ  Ｅｌｅｍｅｎｔ）などを介して通知する。
【０３２９】
ＶＩＩ．端末が以前に送信したＢＳＲと現在のバッファ状態ＢＳを比べてバッファ状態ＢＳの変化に従ってＢＳＲ  ｆｏｒｍａｔを決定する。
【０３３０】
ａ．端末は自分が以前に基地局に報告したＢＳＲからＸバイト以上変化が発生したＬＣＨのバッファ状態ＢＳの情報を現在基地局に報告するＢＳＲに含ませる。
【０３３１】
ｂ．端末は自分が以前に基地局に報告したＢＳＲからＹバイト以上変化が発生したＬＣＧに属したＬＣＨのバッファ状態ＢＳの情報を現在基地局に報告するＢＳＲに含ませる。ここで、ＬＣＧのバッファ状態ＢＳは当該ＬＣＧに属した全てのＬＣＨのバッファ状態ＢＳの合計で表現される。
【０３３２】
ｃ．端末は自分が以前に基地局に報告したＢＳＲからＺバイト以上変化が発生したｓｅｒｖｉｃｅに属したＬＣＧ及び当該ＬＣＧに属したＬＣＨの  バッファ状態ＢＳの情報を現在基地局に報告するＢＳＲに含ませる。ここで、ｓｅｒｖｉｃｅの  バッファ状態ＢＳは当該ｓｅｒｖｉｃｅに属した全てのＬＣＧのバッファ状態ＢＳの合計で表現される。
【０３３３】
ＶＩＩＩ．ここで、Ｘ、Ｙ、Ｚは基地局が端末に  ＲＲＣ  ｍｅｓｓａｇｅ又はＭＡＣ  ＣＥなどを介して通知するようにする。
【０３３４】
ＩＸ．端末がＢＳＲを送信する時点から一定時間内にＵＬ  ｄａｔａを発生させたサービス又はＬＣＧ又はＬＣＨの種類によってＢＳＲ  ｆｏｒｍａｔを決定する。
【０３３５】
ａ．端末がＢＳＲを送信する時点から一定時間内に一定大きさ以上のＵＬ  ｄａｔａを発生させたサービス又はＬＣＧ又はＬＣＨのバッファ状態ＢＳの情報を基地局に報告するＢＳＲに含ませる。
【０３３６】
＜追加４＞
【０３３７】
本発明ではＳＲ信号が複数のビットから構成されている時に当該ビットの組合せを端末のバッファ状態ＢＳに対応させる方案を提案した。従って、基地局は多重ビットから構成されたＳＲ信号を受信した時の端末のＵＬ送信必要可否だけではなくバッファ状態ＢＳの情報まで把握できるという長所がある。しかし、これは１ビットから構成されたＳＲ信号対比より多い時間／周波数無線リソース（例えば、ＰＵＣＣＨ又はＰＵＳＣＨ、ＰＲＡＣＨなど）を要するという短所がある。
【０３３８】
また、本発明では１ビットから構成されたＳＲ信号を互いに異なる時間又は周波数又はｃｏｄｅリソースに送信するようにすることで基地局が「１−ｂｉｔ＿ＳＲ」（以下、単一ビットＳＲともいう）を受信した時、これを受信した時間又は周波数又はｃｏｄｅリソースを識別することによって端末のバッファ状態ＢＳの情報を把握する方法を提案した。ここで、単一ビットＳＲ信号を送受信する時間又は周波数又はｃｏｄｅリソースと端末のバッファ状態報告ＢＳＲ間の対応関係は、端末と基地局がＲＲＣ  ｍｅｓｓａｇｅ又はＭＡＣ  ｃｏｎｔｒｏｌ  ｅｌｅｍｅｎｔなどを介した交渉により決定する方法を提案した。
【０３３９】
これは、単一ビットから構成されたＳＲ信号を送信することは多重ビットから構成されたＳＲ信号を送信するより、更により少ない時間／周波数無線リソースを要する長所がある。しかし、単一ビットＳＲ信号とこれを送受信する時間又は周波数又はｃｏｄｅリソースの間の対応を介して表現できるバッファ状態ＢＳのｒｅｓｏｌｕｔｉｏｎ又はｇｒａｎｕｌａｒｉｔｙは「ｍｕｌｔｉ−ｂｉｔ  ｓｃｈｅｄｕｌｉｎｇ  ｒｅｑｕｅｓｔ」（以下、多重ビットＳＲ又は多重ＳＲビットともいう）信号を介して表現できるバッファ状態ＢＳのｒｅｓｏｌｕｔｉｏｎ又はｇｒａｎｕｌａｒｉｔｙより不十分であるという短所がある。
【０３４０】
前記の内容を整理すれば、多重ビットＳＲ信号を用いる方法はバッファ状態ＢＳを細密に表現できる長所があるがｏｖｅｒｈｅａｄが大きいという短所がある。一方、単一ビットＳＲ信号とこれを送受信する時間／周波数／ｃｏｄｅリソースの対応関係を活用する方法はｏｖｅｒｈｅａｄが小さいという長所があるがバッファ状態ＢＳを細密に表現できないという短所がある。従って、本発明ではこのような２つの方法を共に用いる実施例を含むようにする。このために基地局と端末は次の動作を行う。
【０３４１】
基地局と端末は先ず、多重ビットＳＲ信号を設定する。このために基地局は端末に以下の情報をＲＲＣ  ｍｅｓｓａｇｅなどを介して提供する。
【０３４２】
−多重ビットＳＲ信号を構成するビット数
【０３４３】
−多重ビットＳＲ信号を送信するための無線リソース割り当て情報（リソース割り当て周期含み）
【０３４４】
−その他のＬＴＥでＳＲ信号を設定するのに基地局が端末に提供する情報：ｓｒ−ＰＵＣＣＨ−ＲｅｓｏｕｒｃｅＩｎｄｅｘ、ｓｒ−ＣｏｎｆｉｇＩｎｄｅｘ、ｄｓｒ−ＴｒａｎｓＭａｘ、ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＰｒｏｈｉｂｉｔＴｉｍｅｒなど
【０３４５】
ここで、基地局は、多重ビットＳＲ信号の各ビット組合せがどんなバッファ状態ＢＳを意味するか端末に指示できる。例えば、４ビットから構成されたＳＲ信号の場合、基地局は端末に図１３（Ａ）に示すような情報を提供できる。
【０３４６】
【表１２】
2019532538.tif 000015
【０３４７】
図３２は、本発明の実施形態によってマルチ−ビットＳＲ信号に係わる情報を送受信する過程を説明する図面である。
【０３４８】
基地局と端末は多重ビットＳＲ信号の各ビットの組合せがどんなバッファ状態ＢＳを意味するか交渉により決定できる。これは図３２に表現されている。
【０３４９】
図３２で先ず基地局が端末にＳＲ信号を構成するビットの数を通知し、端末が基地局にＲＲＣ  ｍｅｓｓａｇｅ又はＭＡＣｃｏｎｔｒｏｌｅｌｅｍｅｎｔなどを介して図１３（Ａ）のようにビット多重ビットＳＲの各ビットの組合せがどんなバッファ状態ＢＳに属するかを基地局に通知する動作に該当する。
【０３５０】
次に基地局と端末は単一ビットＳＲ信号を設定する。
【０３５１】
−  単一ビットＳＲ信号を送信するための無線リソース割り当て情報（リソース割り当て周期含み）
【０３５２】
−  その他のＬＴＥでＳＲ信号を設定するのに基地局が端末に提供する情報：ｓｒ−ＰＵＣＣＨ−ＲｅｓｏｕｒｃｅＩｎｄｅｘ、ｓｒ−ＣｏｎｆｉｇＩｎｄｅｘ、ｄｓｒ−ＴｒａｎｓＭａｘ、ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＰｒｏｈｉｂｉｔＴｉｍｅｒなど
【０３５３】
図３３及び図３４は各々、本発明の実施形態によって最小初期ＵＬリソース大きさに関する情報を送受信する過程を説明する図面及びフローチャートである。
【０３５４】
基地局と端末は基地局が単一ビットＳＲを受信した時端末に割り当てるＵＬリソースの最小大きさを交渉により決定できる。これは基地局と端末が互いにＲＲＣ  ｍｅｓｓａｇｅ又はＭＡＣ  ｃｏｎｔｒｏｌｅｌｅｍｅｎｔを交換して実行できる。これは図３３に表現されている。
【０３５５】
一つの実施形態として基地局は端末に端末が単一ビットＳＲ信号を送信した時に割り当てられることを希望する最小初期ＵＬリソース大きさ情報の提供をリクエストする。これを受信した端末は自分が単一ビットＳＲ信号を基地局に送信した時に割り当てられることを希望する最小初期ＵＬリソース大きさ情報を基地局に提供する。これは端末が発生させるＵＬ  ｔｒａｆｆｉｃのｐａｔｔｅｒｎ（発生大きさ、発生時間、ｉｎｔｅｒ−ａｒｒｉｖａｌｔｉｍｅなど）を分析することによって経験的に識別及び決定可能である。端末から最小初期ＵＬリソース大きさ情報を受信した基地局はこの情報と基地局の無線リソース所要現況などを考慮して端末に実際に割り当てできる最小初期ＵＬリソース大きさを決定し、その値を端末に通知するようにする。
【０３５６】
追加的な実施形態として、端末は多重ビットから構成されたＳＲ信号を送信する時の多重ビットのうちの一部はＵＬ  ｔｒａｆｆｉｃの種類に係る情報を表現して残りビットはバッファ状態ＢＳに係る情報を表現するようにできる。一つの例として、もし、６ビットから構成されたＳＲ信号の場合、２ビットはＵＬ  ｔｒａｆｆｉｃの種類（ＬＣＨ、ＬＣＧ、ｎｅｔｗｏｒｋ  ｓｌｉｃｅ、ＱｏＳ  ｃｌａｓｓ、ｎｕｍｅｒｏｌｏｇｙ、ＴＴＩ、ａｐｐｌｉｃａｔｉｏｎ種類など）を、残り４ビットは当該ＵＬ  ｔｒａｆｆｉｃの種類に対応するバッファ状態ＢＳを表現することである。基地局が端末からＵＬ  ｔｒａｆｆｉｃの種類及び当該ＵＬ  ｔｒａｆｆｉｃのバッファ状態ＢＳの情報を含んでいるＳＲ信号を受信すると、基地局は端末が当該ＵＬ  ｔｒａｆｆｉｃを送信するのに適合したＵＬリソースが割り当てられる。
【０３５７】
今まで基地局が端末に多重ビットＳＲ信号及び単一ビットＳＲ信号を設定して２種類のＳＲ信号を共に用いる方法を述べた。一般的に、ＵＲＬＬＣサービスのような場合には端末がＳＲ信号を送信できる機会が短い時間間隔でよくなければならない。端末がＳＲ信号を送信するために待機する時間もレイテンシに含まれるからである。このような側面でＵＲＬＬＣサービスのためには単一ビットＳＲ信号送信機会をよく割り当てることが多重ビットＳＲ信号送信機会をよく割り当てることより、更に少ない無線リソースｏｖｅｒｈｅａｄを引き起こす。同様にｅＭＢＢサービスのような場合にはレイテンシが最も重要な要素ではないからＳＲ信号送信機会が非常によくある必要はない。従って、ｅＭＢＢサービスのためには多重ビットＳＲ送信機会を適当な（あまり短くない）時間間隔に割り当てることが有利である。このようにサービス別で適切な種類のＳＲ信号が互いに異なり得る。このような点を考慮して基地局は端末にＳＲ信号を設定する時のどんなＳＲ信号はどんなサービスに対して使用できるか否かを指示して与えることもできる。ここで、サービスはｌｏｇｉｃａｌ  ｃｈａｎｎｅｌに対応されることもできるから、結局、基地局は端末にＳＲ信号を設定する時のどんなＳＲ信号はどんなｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ（又はｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ｇｒｏｕｐ又はｎｅｔｗｏｒｋ  ｓｌｉｃｅ又はＱｏＳ  ｃｌａｓｓ  ｉｄｅｎｔｉｆｉｅｒ  など）に対して使用できるか否かを指示する場合もある。ここに関する情報は以下に表されている。
【０３５８】
【表１３】
2019532538.tif 000016
【０３５９】
前記の「ＳｃｈｅｄｕｌｉｎｇＲｅｑｕｅｓｔＣｏｎｆｉｇ」（スケジューリング要求構成、以下、ｓｒ構成と略す）で見られるようにｓｒ−ＮｕｍｂｅｒＯｆＢｉｔｓ項目はＳＲ信号のビット数を言うことである。この値が１と設定されると、単一ビットＳＲ信号に該当することで、１より大きい値と設定されると、多重ビットＳＲ信号に該当することである。また、ｓｒ−ＰｅｒｉｏｄはＳＲ送信リソースが割り当てられる周期（サブフレーム又はＴＴＩ又は時間単位）を言う。また、ｓｒ−ＳｅｒｖｉｃｅＭａｐｐｉｎｇは各ｓｒ構成−ｔｙｐｅを活用するｓｅｒｖｉｃｅ種類を言う。前記の例では、ｓｅｒｖｉｃｅ１、３、５はＳＲＣｏｎｆｉｇＴｙｐｅ１を従ってｓｅｒｖｉｃｅ２、４、６はＳＲＣｏｎｆｉｇＴｙｐｅ２を従うということを示す。また、ｓｒ−ｌｏｇｉｃａｌＣｈａｎｎｅｌＭａｐｐｉｎｇは各ＳＲ  ｔｙｐｅを活用するｌｏｇｉｃａｌ  ｃｈａｎｎｅｌの種類を言う。前記の例はｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ１、３、５はＳＲＣｏｎｆｉｇＴｙｐｅ１を従ってｓｅｒｖｉｃｅ２、４、６はＳＲＣｏｎｆｉｇＴｙｐｅ２を従うということを示す。これと類似の方式で基地局は端末に各ＳＲ  ｔｙｐｅを活用するｌｏｇｉｃａｌ  ｃｈａｎｎｅｌｇｒｏｕｐの種類、又はｎｅｔｗｏｒｋ  ｓｌｉｃｅの種類、又はＱｏＳ  ｃｌａｓｓ  ｉｄｅｎｔｉｆｉｅｒの種類、又はＵＬ  ｔｒａｆｆｉｃの種類、又はｎｕｍｅｒｏｌｏｇｙの種類、又はＴＴＩの種類、又はａｐｐｌｉｃａｔｉｏｎの種類などを指示できる。
【０３６０】
前記の拡張された形態として基地局は端末にｄｅｆａｕｌｔ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎとｓｐｅｃｉａｌ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎを設定できる。ここで、ｓｐｅｃｉａｌ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎとは基地局が端末に指定した特定ＬＣＨ（又は特定ＬＣＧ、ｎｅｔｗｏｒｋ  ｓｌｉｃｅ、ＱｏＳ  ｃｌａｓｓ、ＵＬｔｒａｆｆｉｃ種類、ｎｕｍｅｒｏｌｏｇｙ、ＴＴＩ、ａｐｐｌｉｃａｔｉｏｎ  種類など）にだけ適用されるＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎを言い、ｄｅｆａｕｌｔ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎとは、ｓｐｅｃｉａｌ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎを介して指定されたＬＣＨ（又はＬＣＧ、ｎｅｔｗｏｒｋ  ｓｌｉｃｅ、ＱｏＳ  ｃｌａｓｓ、ＵＬ  ｔｒａｆｆｉｃ種類、ｎｕｍｅｒｏｌｏｇｙ、ＴＴＩ、ａｐｐｌｉｃａｔｉｏｎ種類など）を除いた残りＬＣＨ（又はＬＣＧ、ｎｅｔｗｏｒｋ  ｓｌｉｃｅ、ＱｏＳ  ｃｌａｓｓ、ＵＬ  ｔｒａｆｆｉｃ種類、ｎｕｍｅｒｏｌｏｇｙ、ＴＴＩ、ａｐｐｌｉｃａｔｉｏｎ種類など）に適用されるＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎを言う。
【０３６１】
例えば、基地局は端末に以下のようにｄｅｆａｕｌｔ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎとｓｅｒｖｉｃｅ２又はＬＣＨ２及びＬＣＨ４に適用されるｓｐｅｃｉａｌ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎを設定して周期と仮定しよう。それなら端末はｓｅｒｖｉｃｅ２又はＬＣＨ２及びＬＣＨ４で発生したＵＬ  ｄａｔａを送信する時にはｓｐｅｃｉａｌ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれた情報、即ち、ＰＵＣＣＨ  ｒｅｓｏｕｒｃｅ  ｉｎｄｅｘ、ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｉｎｄｅｘ、ｍａｘｉｍｕｍ  ｔｒａｎｓｍｉｓｓｉｏｎ  回数、ＳＲ  ビット数、ＳＲ  ｐｅｒｉｏｄなどに従ってＳＲ信号を送信する。また、端末はｓｅｒｖｉｃｅ２又はＬＣＨ及びＬＣＨ４以外の他のｓｅｒｖｉｃｅ又はＬＣＨで発生したＵＬ  ｄａｔａを送信する時にはｄｅｆａｕｌｔ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれた情報、即ち、ＰＵＣＣＨ  ｒｅｓｏｕｒｃｅｉｎｄｅｘ、ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｉｎｄｅｘ、ｍａｘｉｍｕｍ  ｔｒａｎｓｍｉｓｓｉｏｎ回数、ＳＲ  ビット数、ＳＲ  ｐｅｒｉｏｄなどによってＳＲ信号を送信する。
【０３６２】
前記の例で基地局は端末からＳＲ信号を受信すると、当該ＳＲ信号がどんなＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎに従って送信されたか把握する。即ち、基地局は受信されたＳＲ信号のＰＵＣＣＨ  ｒｅｓｏｕｒｃｅ  ｉｎｄｅｘ、ＳＲｃｏｎｆｉｇｒａｔｉｏｎ  ｉｎｄｅｘ、ＳＲビット数、ＳＲ  ｐｅｒｉｏｄ  などを調べて、当該ＳＲ信号がｄｅｆａｕｌｔ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎに従って送信されたか、それともｓｐｅｃｉａｌ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎに従って送信されたかを決定する。もし、ＳＲ信号がｓｐｅｃｉａｌ  ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎに従って送信されたと決定したら、端末はｓｐｅｃｉａｌＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎが割り当てられたｓｅｒｖｉｃｅ又はＬＣＨ（又はＬＣＧ、ｎｅｔｗｏｒｋ  ｓｌｉｃｅ、ＱｏＳ  ｃｌａｓｓ、ＵＬｔｒａｆｆｉｃ種類、ｎｕｍｅｒｏｌｏｇｙ、ＴＴＩ、ａｐｐｌｉｃａｔｉｏｎ種類など）を把握でき、これによって基地局は端末に当該ＵＬ  ｄａｔａを送信するのに適合したＵＬリソースが割り当てできる。
【０３６３】
【表１４】
2019532538.tif 000017
【０３６４】
＜追加５＞
【０３６５】
本発明ではＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎとサービス又はｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ間の対応関係を定義して特定サービス又は特定ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌでデータが発生した時に端末がここに対応するＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎを介してＳＲ信号を送信する方法を提案した。
【０３６６】
このような概念をＬＴＥに定義されているＢＳＲ  及びＳＲ手続きにそのまま適用すれば基地局と端末は次のように動作する。
【０３６７】
これは［図３３（Ｂ）］に表されている。
【０３６８】
Ｉ．基地局は端末にＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎとＬＣＨ間の対応関係を提供する。
【０３６９】
Ａ．ここに関する情報はＲＲＣＩＥのうちのＳＲＣｏｎｆｉｇ又はｌｏｇｉｃａｌＣｈａｎｎｅｌＣｏｎｆｉｇなどを介して送信できる。即ち、ＳＲＣｏｎｆｉｇに各ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎに対応されるＬＣＨ  ＩＤなどを追加でき、ｌｏｇｉｃａｌＣｈａｎｎｅｌＣｏｎｆｉｇに各ＬＣＨに対応されるＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ  ＩＤなどを追加できる。
【０３７０】
Ｂ．端末は特定ＬＣＨでデータが発生した時の現在端末のバッファに他のＬＣＨで発生したデータが予め存在するか否かを識別する。
【０３７１】
ｉ．もし、端末のバッファに他のＬＣＨで発生したデータが存在しなかったら端末はｒｅｇｕｌａｒ  ＢＳＲ送信手続きを開始する。ＲｅｇｕｌａｒＢＳＲ送信手続きが開始されたが端末に割り当てられたＵＬリソースがなくｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが動作していなかったら端末はＳＲ送信手続きを開始する。
【０３７２】
１．ここで、ＳＲ送信手続きはｒｅｇｕｌａｒ  ＳＲ送信手続きを開始したデータが発生したＬＣＨに対応されるＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎに従って行われる。
【０３７３】
ｉｉ．もし、端末のバッファに他のＬＣＨで発生したデータが予め存在したら端末はデータが発生したＬＣＨの優先順位とデータが予め存在するＬＣＨの優先順位を比べる。
【０３７４】
１．もし、データが発生したＬＣＨの優先順位がデータが予め存在するＬＣＨの優先順位より高ければ端末はｒｅｇｕｌａｒ  ＢＳＲ送信手続きを開始する。Ｒｅｇｕｌａｒ  ＢＳＲ手続きが開始されたが端末に割り当てられたＵＬリソースがなくｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが動作していなかったら端末はＳＲ送信手続きを開始する。
【０３７５】
Ａ．ここで、ＳＲ送信手続きはｒｅｇｕｌａｒ  ＢＳＲ送信手続きを開始したデータが発生したＬＣＨに対応されるＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎによって行われる。
【０３７６】
２．もし、データが発生したＬＣＨの優先順位がデータがもう存在するＬＣＨの優先順位より高くなければ端末は  ｒｅｇｕｌａｒ  ＢＳＲ  手続きを開始しない。
【０３７７】
ＬＴＥに定義されているｌｏｇｉｃａｌＣｈａｎｎｅｌＣｏｎｆｉｇ  ＩＥにＳＲＣｏｎｆｉｇのインデクスを含ませる方法でｌｏｇｉｃａｌ  ｃｈａｎｎｅｌとＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ間の対応関係を表現する場合、ｌｏｇｉｃａｌＣｈａｎｎｅｌＣｏｎｆｉｇ  ＩＥとＳＲＣｏｎｆｉｇ  ＩＥには次のように表現されることができる。
【０３７８】
【表１５】
2019532538.tif 000018
【０３７９】
【表１６】
2019532538.tif 000019
【０３８０】
【表１７】
2019532538.tif 000020
【０３８１】
前述したｌｏｇｉｃａｌ  ｃｈａｎｎｅｌとＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ間の対応関係は、先ず各々のＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎに固有のＩＤ（ＳＲＣｏｎｆｉｇＩｎｄｅｘ）を割り当てて各々のｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ｃｏｎｆｉｇｕｒａｔｉｏｎに該当するｌｏｇｉｃａｌ  ｃｈａｎｎｅｌに対応されるＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎのＩＤを挿入する形態で成る。
【０３８２】
また、別の例示としてＬＴＥ規格に既に定義されているｌｏｇｉｃａｌ  ｃｈａｎｎｅｌのＩＤ（ｌｏｇｉｃａｌＣｈａｎｎｅｌＩｄｅｎｔｉｔｙ）をＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎに含ませることによってｌｏｇｉｃａｌ  ｃｈａｎｎｅｌとＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ間の対応関係を表現することもできる。このような例示は以下に表現されている。
【０３８３】
【表１８】
2019532538.tif 000021
【０３８４】
【表１９】
2019532538.tif 000022
【０３８５】
図３４は、本発明による基地局の構成を示す図面である。
【０３８６】
本発明の実施形態による基地局処理部３４１０は基地局受信部３４２０及び基地局送信部３４３０を介して送受信される情報を用いて移動通信システムでＵＬスケジューリング方法を行うことができる。基地局処理部３４１０は基地局受信部３４２０を制御して端末からＳＲ（ＳＲ）を受信し、前記ＳＲを用いて前記端末のバッファに記憶されたデータ量を識別し、前記識別されたデータ量に基づいて前記端末でＵＬリソースを割り当てできる。
【０３８７】
制御部とも表現され得る基地局処理部８１０は基地局受信部８２０及び基地局送信部８３０を制御でき、図１乃至図３３に示された実施形態での基地局動作を行うことができる。この時、基地局受信部８２０及び基地局送信部８３０は送受信部とも表現され得る。
【０３８８】
図３５は、本発明による端末の構成を示す図面である。
【０３８９】
本発明の実施形態による端末処理部３５１０は端末受信部３５２０及び端末送信部３５３０を介して送受信される情報を用いて移動通信システムでＵＬスケジューリング方法を行うことができる。端末処理部３５１０はバッファに記憶されたデータ量を識別し、ＳＲ（ＳＲ）を生成し、基地局からＵＬリソースが割り当てられるように前記基地局で前記識別されたデータ量に基づいて前記ＳＲを送信するように制御できる。
【０３９０】
制御部とも表現され得る端末処理部３５１０は端末受信部３５２０及び端末送信部３５３０を制御でき、図１乃至図３３に示された実施形態での端末動作を行うことができる。この時、端末受信部３５２０及び端末送信部３５３０は送受信部とも表現され得る。
【０３９１】
一方、本明細書と図面には本発明の好ましい実施形態に対して開示し、たとえ特定用語が使用されたが、これはただ本発明の技術内容を容易に説明して発明の理解を助けるための一般的な意味で使用したもので、本発明の範囲を限定しようとするのではない。ここに開示された実施形態外にも本発明の技術的思想に基づいた他の変形例が実施可能ということは本発明が属する技術分野で通常の知識を有した者に自明なものである。
【０３９２】
本開示が例示的な実施形態で述べたが、様々な変更や修正が当業者に提案され得る。本開示は添付された請求範囲の範疇内に属するそのような変更及び修正を含めることで意図される。
【符号の説明】
【０３９３】
ＢＳ      バッファ状態（Ｂｕｆｆｅｒ＿Ｓｔａｔｕｓ）
ＢＳＲ      バッファ状態報告
ＤＬ      ダウンリンク
ＬＴＥ      携帯端末の第４世代データ通信仕様
ＮＢ      基地局
Ｐ−ＢＳＩ      予備的バッファ状態インデクス
ＰＵＣＣＨ      ＵＬ制御情報チャンネル
ＳＲ      スケジューリング要求
ＲＡＣＨ      ランダムアアクセスチャネル
ＲＲＣ      無線リソース制御（レイヤ）
ＴＴＩ      送信時間間隔
ＵＥ      ユーザ装置、端末
ＵＬ      アップリンク
【図１】
2019532538.tif 000023
【図２】
2019532538.tif 000024
【図３】
2019532538.tif 000025
【図４】
2019532538.tif 000026
【図５】
2019532538.tif 000027
【図６】
2019532538.tif 000028
【図７】
2019532538.tif 000029
【図８】
2019532538.tif 000030
【図９】
2019532538.tif 000031
【図１０】
2019532538.tif 000032
【図１１】
2019532538.tif 000033
【図１２】
2019532538.tif 000034
【図１３】
2019532538.tif 000035
【図１４】
2019532538.tif 000036
【図１５】
2019532538.tif 000037
【図１６】
2019532538.tif 000038
【図１７】
2019532538.tif 000039
【図１８】
2019532538.tif 000040
【図１９】
2019532538.tif 000041
【図２０】
2019532538.tif 000042
【図２１】
2019532538.tif 000043
【図２２】
2019532538.tif 000044
【図２３】
2019532538.tif 000045
【図２４】
2019532538.tif 000046
【図２５】
2019532538.tif 000047
【図２６】
2019532538.tif 000048
【図２７】
2019532538.tif 000049
【図２８】
2019532538.tif 000050
【図２９】
2019532538.tif 000051
【図３０】
2019532538.tif 000052
【図３１】
2019532538.tif 000053
【図３２】
2019532538.tif 000054
【図３３】
2019532538.tif 000055
【図３４】
2019532538.tif 000056
【図３５】
2019532538.tif 000057
【図３６】
2019532538.tif 000058
【国際調査報告】
2019532538.tif 000059
2019532538.tif 000060