(57)【要約】      （修正有）【課題】受信局宛データ送信用の無線リソースにおける余剰リソースの発生を回避又は削減することで、無線リソースの利用効率を向上する。【解決手段】送信局は、少なくとも一つの受信局を宛先とするデータの送信用リソースとして、第一の時間帯に対応する第一の無線リソース、および前記第一の時間帯より後の第二の時間帯に対応する第二の無線リソースを、前記少なくとも一つの前記受信局と対応付け、さらに、前記受信局と前記対応付けられた、前記第一の無線リソースもしくは前記第二の無線リソースの、少なくとも何れか一方を用いて、前記第一の時間帯において送信可能なデータである第一のデータの送信を行う構成とする。【選択図】図１０
2011071799.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システムであって、
送信局と、前記送信局と無線通信を行う受信局と、を有し、
前記送信局は、
前記受信局を宛先とするデータの送信用リソースとして、第一の時間帯によって構成される第一の無線リソース、および前記第一の時間帯より後の第二の時間帯によって構成される第二の無線リソースを、前記受信局と対応付けて記憶し、
前記第一の時間帯以前に前記送信局が保持している、前記対応付けがなされた前記受信局を宛先とするデータである第一のデータを送信する場合に、前記受信局と対応付けられた、前記第一の無線リソースあるいは前記第二の無線リソースの、何れを使用するかの選択を、
前記第一のデータのデータ量に基づいて行うこと、
を特徴とする無線通信システム。
【請求項２】
請求項１に記載の無線通信システムであって、
前記送信局は、
前記第二の無線リソースを使用して前記第一のデータを送信することを選択した場合に、
前記第一の時間帯以後に前記送信局が保持した、前記対応付けがなされた前記受信局を宛先とするデータである第二のデータとともに、前記第一のデータを送信すること、
を特徴とする無線通信システム。
【請求項３】
請求項１に記載の無線通信システムであって、
前記送信局は、
前記第一のデータのデータ量と前記第一の無線リソースの容量との比較に基づいて前記選択を行なうこと、
を特徴とする無線通信システム。
【請求項４】
請求項３に記載の無線通信システムであって、
前記送信局は、
前記選択において、前記第一のデータのデータ量と前記第一の無線リソースの容量との間の差が既定の閾値以上の場合に、前記第一のデータの送信に前記第二の無線リソースを選択し、
前記選択された前記第二のリソースを用いて前記第一のデータを前記対応付けがなされた前記受信局に送信すること、
を特徴とする無線通信システム。
【請求項５】
請求項３に記載の無線通信システムであって、
前記送信局は、
前記選択において、前記第一のデータのデータ量が前記第一の無線リソースの容量未満となる回数が既定の閾値以上の場合に、前記第一のデータの送信に前記第二の無線リソースを選択し、
前記選択された前記第二のリソースを用いて前記第一のデータを前記対応付けがなされた前記受信局に送信すること、
を特徴とする無線通信システム。
【請求項６】
請求項１に記載の無線通信システムであって、
前記送信局は、
前記第一の無線リソースの容量が、前記第一の無線リソースを用いて送信する前記対応付けがなされた前記受信局を宛先とするデータのデータ量よりも大きい場合は、前記対応付けがなされた前記受信局を宛先とするデータとともに、無意味なデータを前記第一の無線リソースを用いて送信し、
前記第二の無線リソースの容量が、前記第二の無線リソースを用いて送信する前記対応付けがなされた前記受信局を宛先とするデータのデータ量よりも大きい場合は、前記対応付けがなされた前記受信局を宛先とするデータとともに、無意味なデータを前記第一の無線リソースを用いて送信する、こと、
を特徴とする無線通信システム。
【請求項７】
請求項６に記載の通信システムであって、
前記無意味なデータの送信はゼロパディングであること、
を特徴とする通信システム。
【請求項８】
請求項１に記載の無線通信システムであって、
前記第一の無線リソースの容量および第二の無線リソースの容量は、それぞれの無線リソースを構成する周波数帯域の幅と、それぞれの無線リソースを構成する時間帯の長さと、に基づいて決定され、
前記第一の無線リソースおよび前記第二の無線リソースは、同一の周波数帯域によって構成され、
前記第一の時間帯の長さと前記第二の時間帯の長さは同一であり、
前記第一の時間帯と、前記第二の時間帯と、の最初の時点の間隔は一定の値である、こと、
を特徴とする無線通信システム。
【請求項９】
請求項１に記載の無線通信システムであって、
前記送信局は、
前記第一のデータの送信を、前記第一の無線リソースを使用せずに、前記第二の無線リソースを使用して行う場合に、
前記第一の無線リソースおよび前記第二の無線リソース、と前記対応付けがなされていない前記受信局を宛先とするデータの送信を、前記第一の無線リソースを使用して行なうこと、
を特徴とする無線通信システム。
【請求項１０】
請求項１に記載の無線通信システムであって、
前記送信局は、
前記第一の無線リソースおよび前記第二の無線リソースを、複数の前記受信局を宛先とするデータの送信用リソースとして、複数の前記受信局と前記対応付けて前記記憶し、
複数の前記対応付けがなされた前記受信局の各々を宛先とするデータのデータ量に基づいて、
複数の前記受信局と前記対応付けられた前記第一の無線リソースを用いたデータ送信の宛先、および複数の前記受信局と前記対応付けられた前記第二の無線リソースを用いたデータ送信の宛先、を複数の前記対応付けがなされた前記受信局から選択すること、
を特徴とする無線通信システム。
【請求項１１】
請求項１０に記載の無線通信システムであって、
前記送信局は、
前記対応付けがなされた前記受信局を宛先とするデータの送信に使用しない、前記第一の無線リソースおよび前記第二の無線リソース、の数に基づいて、
前記対応付けを行う前記受信局の数、または前記対応付けを行う前記受信局の組合せ、を決定すること、
を特徴とする無線通信システム。
【請求項１２】
請求項１に記載の無線通信システムであって、
前記受信局は、
前記送信局から受信するデータを保持するバッファを有し、
前記第一の時間帯と、前記第二の時間帯と、の最初の時点の間隔は前記バッファの容量に基づく閾値以下であること
を特徴とする無線通信システム。
【請求項１３】
無線端末装置と無線通信を行う無線基地局装置であって、
前記無線端末装置を宛先とするデータを保持するデータ保持部と、
前記無線端末装置を宛先とするデータの送信用リソースとして、第一の時間帯によって構成される第一の無線リソース、および前記第一の時間帯より後の第二の時間帯によって構成される第二の無線リソースを、前記少なくとも一つの前記無線端末装置と対応付けて記憶するリソース記憶部と、
前記対応付けがなされた前記無線端末装置を宛先として前記第一の時間帯以前に前記データ保持部で保持しているデータである第一のデータを、前記第二の無線リソースを用いて送信するデータ送信部と、を備えること、
を特徴とする無線基地局装置。
【請求項１４】
請求項１３に記載の無線基地局装置であって、
前記データ送信部は、
前記対応付けがなされた前記無線端末装置を宛先として前記第一の時間帯以後に前記データ保持部で保持しているデータである第二のデータとともに前記第一のデータを前記第二の無線リソースを用いて送信すること、
を特徴とする無線基地局装置。
【請求項１５】
請求項１３に記載の無線基地局装置であって、
前記データ送信部は、
前記第一の無線リソースの容量が、前記第一の無線リソースを用いて送信する前記対応付けがなされた前記無線端末装置を宛先とするデータのデータ量よりも大きい場合は、前記対応付けがなされた前記無線端末装置を宛先とするデータとともに、無意味なデータを前記第一の無線リソースを用いて送信し、
前記第二の無線リソースの容量が、前記第二の無線リソースを用いて送信する前記対応付けがなされた前記無線端末装置を宛先とするデータのデータ量よりも大きい場合は、前記対応付けがなされた前記無線端末装置を宛先とするデータとともに、無意味なデータを前記第一の無線リソースを用いて送信する、こと、
を特徴とする無線基地局装置。
【請求項１６】
請求項１４に記載の無線基地局装置であって、
前記無意味なデータの送信はゼロパディングであること、
を特徴とする無線基地局装置。
【請求項１７】
請求項１３に記載の無線基地局装置であって、
前記リソース記憶部が前記前記無線端末装置と前記対応付けて記憶する、前記第一の無線リソースおよび前記第二の無線リソースは、
同一の周波数帯域によって構成され、
前記第一の時間帯の長さと前記第二の時間帯の長さは同一であり、
前記第一の時間帯と、前記第二の時間帯と、の最初の時点の間隔は一定の値である、こと、
を特徴とする無線基地局装置。
【請求項１８】
無線基地局装置と無線通信を行う無線端末装置であって、
第一の時間帯に対応する第一の無線リソース、および前記第一の時間帯より後の第二の時間帯に対応する第二の無線リソース、が前記無線端末装置を宛先とする無線端末装置宛データの受信用リソースとして前記無線端末装置に対応付けがなされていることを示す、前記無線基地局装置から通知されたリソース割当情報、を記憶するリソース割当記憶部と、
前記リソース割当情報を参照し、前記リソース割当情報で前記無線端末装置に前記対応付けがなされた前記第二の無線リソースを使用して、前記無線基地局装置が前記第一の時間帯以前に保持していた前記無線端末装置宛データである第一のデータの受信を行う受信部と、を備えること、
を特徴とする無線端末装置。
【請求項１９】
請求項１８に記載の無線端末装置であって、
前記受信部は、
前記第一のデータの受信を、前記第二の無線リソースを使用して、前記無線基地局装置が前記第一の時間帯以後に保持していた第二のデータの受信とともに行なうこと、
を特徴とする無線端末装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、基地局、端末及び通信システム、通信方法に係り、特に、無線通信システム、および無線通信システムを構成する無線基地局装置および無線端末装置に関する。
【背景技術】
【０００２】
ディジタル通信における音声通話のため、様々な音声符号化方式が検討されている。例えば、非特許文献１で開示されているように、セルラ通信システムの標準化団体である３ＧＰＰではＡＭＲ（Ａｄａｐｔｉｖｅ  Ｍｕｌｔｉ  Ｒａｔｅ）などが標準化されている。また、非特許文献２で開示されているように、同じくセルラ通信システムの標準化団体である３ＧＰＰ２ではＥＶＲＣ（Ｅｎｈａｎｃｅｄ  Ｖａｒｉａｂｌｅ  Ｒａｔｅ  Ｃｏｄｅｃ）などが標準化されている。ここで、音声符号化器（ボコーダー）は、入力された音声信号を標本化し、量子化などの処理を行い、音声フレームとして出力する。例えば、上記のＡＭＲやＥＶＲＣといった音声符号化方式では、音声フレームは一定の周期で出力される。
【０００３】
一方、パケット交換網では、回線を占有して通信を行う回線交換網と異なり、パケット送信時のみ通信リソースを使用する。従って、前述の音声フレームをパケット交換網で送信するため、予め通信リソースを確保する必要がある。そこで、非特許文献３〜５で開示されているように、標準化団体３ＧＰＰでは、Ｅ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）としてＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）を採用する無線アクセスインタフェースが規格化されており、ＳＰＳ（Ｓｅｍｉ−Ｐｅｒｓｉｓｔｅｎｔ  Ｓｃｈｅｄｕｌｉｎｇ）として一定周期で一定量の通信リソースを予約する機能が定義されている。また、非特許文献６〜１１で開示されているように、標準化団体３ＧＰＰ２では、ＵＭＢ（Ｕｌｔｒａ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）としてＯＦＤＭＡを採用する無線アクセスインタフェースが規格化されており、Ｐｅｒｓｉｓｔｅｎｔ  Ｍｏｄｅとして一定周期で一定量の通信リソースを予約する機能が定義されている。Ｅ−ＵＴＲＡやＵＭＢといったセルラ通信システムでは、パケットあるいはＨＡＲＱ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）送信（サブパケット）ごとに基地局が通信リソースを端末に割当て、通信リソースの割当て情報を制御情報として基地局から端末に通知する。ここで、ＳＰＳやＰｅｒｓｉｓｔｅｎｔ  Ｍｏｄｅでは、パケット送信開始時に基地局が周期的な通信リソースを予約するとともに、予約した通信リソースの情報を端末に通知し、以降のパケット送信には予め予約しておいた周期に従って通信リソースを使用する。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】３ＧＰＰ  ＴＳ  ２６．０７１  Ｖ８．０．０
【非特許文献２】３ＧＰＰ２  Ｃ．Ｓ００１４−Ｂ  ｖ１．０
【非特許文献３】３ＧＰＰ  ＴＳ  ３６．３２１  Ｖ８．４．０  ５．３．１  ＤＬ  Ａｓｓｉｇｎｍｅｎｔ  ｒｅｃｅｐｔｉｏｎ
【非特許文献４】３ＧＰＰ  ＴＳ  ３６．３２１  Ｖ８．４．０  ５．４．１  ＵＬ  Ｇｒａｎｔ  ｒｅｃｅｐｔｉｏｎ
【非特許文献５】３ＧＰＰ  ＴＳ  ３６．３２１  Ｖ８．４．０  ５．１０  Ｓｅｍｉ−Ｐｅｒｓｉｓｔｅｎｔ  Ｓｃｈｅｄｕｌｉｎｇ
【非特許文献６】３ＧＰＰ２  Ｃ．Ｓ００８４−００２−０  Ｖｅｒｓｉｏｎ  ３．０  ６．５．５．１．１．３  Ａｃｃｅｓｓ  Ｔｅｒｍｉｎａｌ  Ａｓｓｉｇｎｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  ｆｏｒ  Ｐｅｒｓｉｓｔｅｎｔ  Ａｓｓｉｇｎｍｅｎｔｓ
【非特許文献７】３ＧＰＰ２  Ｃ．Ｓ００８４−００２−０  Ｖｅｒｓｉｏｎ  ３．０  ６．５．５．１．２．１  Ａｃｃｅｓｓ  Ｔｅｒｍｉｎａｌ  Ａｓｓｉｇｎｍｅｎｔ  Ｐｒｏｃｅｓｓｉｎｇ  ｆｏｒ  Ｐｅｒｓｉｓｔｅｎｔ  Ａｓｓｉｇｎｍｅｎｔｓ
【非特許文献８】３ＧＰＰ２  Ｃ．Ｓ００８４−００２−０  Ｖｅｒｓｉｏｎ  ３．０  ６．５．５．２．２  Ｆ−ＤＣＨ  Ｔｒａｎｓｍｉｓｓｉｏｎｓ  Ａｓｓｏｃｉａｔｅｄ  ｗｉｔｈ  Ｐｅｒｓｉｓｔｅｎｔ  Ａｓｓｉｇｎｍｅｎｔｓ
【非特許文献９】３ＧＰＰ２  Ｃ．Ｓ００８４−００２−０  Ｖｅｒｓｉｏｎ  ３．０  ８．５．５．１．３  Ａｃｃｅｓｓ  Ｔｅｒｍｉｎａｌ  Ａｓｓｉｇｎｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  ｆｏｒ  Ｐｅｒｓｉｓｔｅｎｔ  Ａｓｓｉｇｎｍｅｎｔｓ
【非特許文献１０】３ＧＰＰ２  Ｃ．Ｓ００８４−００２−０  Ｖｅｒｓｉｏｎ  ３．０  ８．５．５．１．６  Ａｃｃｅｓｓ  Ｔｅｒｍｉｎａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｌｏｇｉｃ  ｆｏｒ  Ｐｅｒｓｉｓｔｅｎｔ  Ａｓｓｉｇｎｍｅｎｔｓ
【非特許文献１１】３ＧＰＰ２  Ｃ．Ｓ００８４−００２−０  Ｖｅｒｓｉｏｎ  ３．０  ８．５．５．２  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  Ｒｅｑｕｉｒｅｍｅｎｔｓ  ｆｏｒ  Ｐｅｒｓｉｓｔｅｎｔ  Ａｓｓｉｇｎｍｅｎｔｓ
【発明の概要】
【発明が解決しようとする課題】
【０００５】
通信リソースを予め確保する機能を用いると、送信するデータ量の変動などに応じてリソース量やリソース割り当ての頻度を時々刻々変化させるのは困難である。例えば、Ｅ−ＵＴＲＡにおけるＳＰＳや、ＵＭＢにおけるＰｅｒｓｉｓｔｅｎｔ  Ｍｏｄｅでは、一定の時間周期で、一定の大きさの通信リソースを予約する。
しかしながら、例えばＡＭＲやＥＶＲＣといったマルチレートの音声符号化方式では、音声レートが音声符号化器への入力音声などに応じて可変であるため、音声フレーム毎に大きさすなわちビット量が異なる。
【０００６】
このようにデータサイズが可変のトラヒックを、予め決められた大きさの通信リソースを予約する機能を用いて送信する場合は、発生しうるデータサイズのうち最大のものに合わせて通信リソースを予約する必要がある。このとき、例えばＳＰＳやＰｅｒｓｉｓｔｅｎｔ  Ｍｏｄｅのように一定量の通信リソースを予約する場合、データサイズが最大のデータを送信するときは、予約した通信リソースの量とデータサイズが一致する。しかし、それ以外のデータサイズを持つデータを送信する場合は、データサイズより通信リソースの量が大きくなり、余剰リソースが発生する。この場合、余剰リソースには、例えばゼロパディングなど、特に意味を持たないデータを詰め込むことにより補完し、当該予約した通信リソースを用いてデータ送信することとなる。
【０００７】
このような余剰リソース発生によって、特に意味を持たないデータによる余剰リソースの補完が頻繁に発生したり、特に意味を持たないデータの量が大きい場合、送信される全データ量に占める、特に意味を持たないデータの割合が増加し、無線資源の利用効率が低下してしまう。
【課題を解決するための手段】
【０００８】
上述した課題の少なくとも一の課題を解決するための本発明の一態様として、送信局は、少なくとも一つの受信局を宛先とするデータの送信用リソースとして、第一の時間帯に対応する第一の無線リソース、および前記第一の時間帯より後の第二の時間帯に対応する第二の無線リソースを、前記少なくとも一つの前記受信局と対応付け、さらに、前記受信局と前記対応付けられた、前記第一の無線リソースもしくは前記第二の無線リソースの、少なくとも何れか一方を用いて、前記第一の時間帯において送信可能なデータである第一のデータの送信を行う構成とする。
【０００９】
さらに、その他の態様として、前記第二の無線リソースを用いて前記第一のデータの送信を行なう場合に、前記第一のデータを、前記第一のデータ以外のデータとともに送信することを上記手段の構成とする。
【発明の効果】
【００１０】
本発明の一態様によれば、受信局宛データ送信用の無線リソースにおける余剰リソースの発生を回避または削減することが可能になり、無線リソースの利用効率の向上に供する。
【図面の簡単な説明】
【００１１】
【図１】セルラ無線通信システムの構成図
【図２】リソースの定義を示す図
【図３】ＳＰＳリソースの定義を示す図
【図４】確保されたリソース群を表す図
【図５】ＳＰＳによるデータ通信の手順を示すシーケンス図
【図６】基地局がパディングの有無に基づきデータ送信の遅延を行う判断の手順を示すフロー図
【図７】基地局がパディングの有無および遅延量に基づきデータ送信の遅延を行う判断の手順を示すフロー図
【図８】基地局がパディングの有無および遅延量に基づきデータ送信の遅延や別のリソースでのデータ送信を行う判断の手順を示すフロー図
【図９】ＳＰＳリソースにおけるデータ送信を説明する図
【図１０】データ送信を遅延させる場合のデータ送信を説明する図
【図１１】基地局が空きリソースの発生に基づきリソースを解放する判断の手順を示すフロー図
【図１２】基地局が空きリソースの発生に基づき空きリソースを端末に割り当てる判断の手順を示すフロー図
【図１３】ＳＰＳリソースにおけるデータ送信を説明する図
【図１４】複数の端末が一連のＳＰＳリソースを共有する場合の基地局のデータ送信を説明する図
【図１５】複数の端末が一連のＳＰＳリソースを共有する場合の基地局のデータ通信の手順を示すシーケンス図
【図１６】空きリソースの発生に基づき複数の端末による一連のＳＰＳリソースの共有を開始する基地局の判断の手順を示すフロー図
【図１７】パディングの量に基づき複数の端末による一連のＳＰＳリソースの共有を開始する基地局の判断の手順を示すフロー図
【図１８】過去のデータ送信状況に基づき複数の端末による一連のＳＰＳリソースの共有を開始する基地局の判断の手順を示すフロー図
【図１９】一連のＳＰＳリソースを共有する端末数や端末の組合せを変更する基地局の動作手順を示すフロー図
【図２０】ＳＰＳリソースを使用した音声データ送信を示す図
【図２１】音声データ送信においてデータ送信を遅延させることを示す図
【図２２】基地局がパディングの発生量によりデータ送信の延期を判断する手順を示すフロー図
【図２３】基地局がパディングの発生頻度によりデータ送信の延期を判断する手順を示すフロー図
【図２４】複数の端末が一連のＳＰＳリソースを共有する場合の基地局のデータ送信の手順を示すフロー図
【図２５】割り当てＳＰＳリソース管理テーブルの一例を示す図
【図２６】基地局の構成例を示す図
【図２７】端末の構成例を示す図
【図２８】端末のデータ受信の動作手順を示すフロー図
【発明を実施するための形態】
【００１２】
本発明を適用する通信システム、および前記通信システムにおける基地局、端末について、Ｅ−ＵＴＲＡにおけるＳＰＳを一例として、図面を参照して詳細に説明する。ただし、本発明が実施される形態としては、データ送受信用のリソースが端末へのデータ送信用に予め確保されるものであればＳＰＳに限らないことは明らかである。
【実施例１】
【００１３】
本発明を適用する第１の実施例について以下で説明する。図１は、Ｅ−ＵＴＲＡを採用する無線通信システムの構成例を示している。無線通信システムは、図１に示すように、複数の基地局と複数の端末から構成される。基地局１０１a〜１０１cは、有線回線によって基地局制御装置１０３と接続され、さらに基地局制御装置１０３は、有線回線によってネットワーク１０４に接続する。端末１０２aは基地局１０１aに、端末１０２bは基地局１０１bに、端末１０２cは基地局１０１cに、それぞれ無線によって接続し、基地局制御装置１０３を介しネットワーク１０４と通信できる仕組みになっている。図１のシステムにおいて、基地局１０１a〜１０１cが通信リソースの割り当てを行い、割り当て情報を接続する端末１０２a〜１０２cに通知する。セル１０５a〜１０５cは、それぞれの基地局１０１a〜１０１cと無線接続により、接続する端末１０２a〜１０２cが通信可能な凡その範囲を示している。なお、これ以降の説明において、基地局とは、セル１０５a〜１０５cのそれぞれの基地局１０１a〜１０１cの少なくともいずれか１つを示し、端末とは端末１０２a〜１０２cの少なくともいずれか１つを示すものとする。
【００１４】
図２６は、本発明を実施するための基地局の構成例を示している。ネットワークインタフェース２６０５は、ネットワークからデータを受信し、ＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）２６０４に送信する。ＤＳＰ２６０４は、ネットワークインタフェースから受信したデータをＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）バッファ２６０９に格納する。制御部であるＭＰＵ２６０６は、無線リソースの割り当てを行い、ＭＰＵ２６０６が割り当てた無線リソースを用いたデータパケットの送出をＤＳＰ２６０４に指示する。ＭＰＵ２６０６の決定した無線リソースの割り当て情報は、メモリ２６０７に格納される。ＤＳＰ２６０４は、ＭＰＵ２６０４の指示により、ＲＬＣバッファからデータを取り出し、ベースバンド部２６０３に物理パケットとして送信する。ベースバンド部２６０３は、ＤＳＰ２６０４から受信した物理パケットに対し、ＭＰＵ２６０４の指示に従って、符号化や変調などの信号処理を行う。ベースバンド部２６０３が物理パケットから生成した符号語は、物理パケット送信が完了するまで、ＨＡＲＱバッファ２６０８で保持される。ベースバンド部２６０３で生成されたディジタル信号は、ＲＦ部２６０２においてアナログ信号に変換し、ＭＰＵ２６０６が割り当てた無線リソースの送信周波数帯にアップコンバートし、適当な送信電力まで増幅したあと、アンテナ２６０１から送信される。なお、図２６の構成例において、アンテナ２６０１はハードウェアとして構成される。また、ベースバンド部２６０３、ＤＳＰ２６０４、ネットワークインタフェース２６０５、メモリ２６０７、ＨＡＲＱバッファ２６０８、ＲＬＣバッファ２６０９、ＭＰＵ２６０６、ＲＦ部２６０２を全てハードウェアで構成しても良いし、ベースバンド部２６０３、ＤＳＰ２６０４、ネットワークインタフェース２６０５、ＨＡＲＱバッファ２６０８、ＲＬＣバッファ２６０９、ＭＰＵ２６０６、ＲＦ部２６０２をメモリ２６０７に格納されたプログラムモジュールとして実行する構成としてもよい。
【００１５】
図２７は、本発明を実施するための端末の構成例を示している。アンテナ２７０１は基地局からの無線信号を受信する。受信信号に対しては、ＲＦ部２７０２で、ベースバンド信号へのダウンコンバート、アナログ信号からディジタル信号への変換といった処理が行われる。その後、ベースバンド部２７０３において、復調や復号などの処理が行われ、得られた基地局からの物理パケットがＤＳＰ２７０４に送られる。ベースバンド部２７０３の復調結果は、復号が成功するまで、ＨＡＲＱバッファ２７０８で保持される。ＭＰＵ２７０６は、ＤＳＰ２７０４から、基地局から通知されたリソースの割り当て情報を取り出し、メモリ２７０７に格納する。リソース割り当て情報は、ベースバンド部２７０３において、復調や復号などを行う際に用いられる。ＤＳＰ２７０４で処理されたデータは、一旦ＲＬＣバッファ２７０９に格納された後、アプリケーションインタフェース２７０５に送信される。なお、図２７の構成例において、アンテナ２７０１はハードウェアとして構成される。また、ベースバンド部２７０３、ＤＳＰ２７０４、アプリケーションインタフェース２７０５、メモリ２７０７、ＨＡＲＱバッファ２７０８、ＲＬＣバッファ２７０９、ＭＰＵ２７０６、ＲＦ部２７０２を全てハードウェアで構成しても良いし、ベースバンド部２７０３、ＤＳＰ２７０４、アプリケーションインタフェース２７０５、ＨＡＲＱバッファ２７０８、ＲＬＣバッファ２７０９、ＭＰＵ２７０６、ＲＦ部２７０２をメモリ２７０７に格納されたプログラムモジュールとして実行する構成としてもよい。
【００１６】
図２は、基地局１０１a〜１０１cと端末１０２a〜１０２cの間の通信に用いる通信リソースの割り当て例を示している。図２のように、通信リソース２０１は、周波数帯域２０３と時間スロット２０２によって定義される。Ｅ−ＵＴＲＡでは、通信リソースの割り当てにおける単位時間スロットは、サブフレームと呼ばれる。また、Ｅ−ＵＴＲＡでは、通信リソースの割り当てにおいて、一定の周波数帯域幅とサブフレームからなる時間周波数リソースを、リソースブロック（Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）と呼ぶ。なお、以下の説明ではリソースブロックをＲＢと略して表記する。
【００１７】
Ｅ−ＵＴＲＡにおける通信リソースの割り当ては、ＤＳ（Ｄｙｎａｍｉｃ  Ｓｃｈｅｄｕｌｉｎｇ）またはＳＰＳのいずれかの方式により行われる。Ｅ−ＵＴＲＡにおける通信リソースの割当て情報の基地局から端末への通知は、下りリンクではＨＡＲＱ送信ごとに、上りリンクではパケット毎に行われる。この方式はＤＳ（Ｄｙｎａｍｉｃ  Ｓｃｈｅｄｕｌｉｎｇ）と呼ばれる。一方、ＳＰＳでは、各パケットの最初のＨＡＲＱ送信に使用する通信リソースを、予め周期的に予約することができる。ＳＰＳにより確保される通信リソースを、本実施例ではＳＰＳリソースと定義する。
【００１８】
図３は、Ｅ−ＵＴＲＡにおけるＳＰＳにおける通信リソースであるＳＰＳリソース３００の割り当て例を示している。図３のように、Ｅ−ＵＴＲＡにおけるＳＰＳでは、通信リソース３００は一定の時間周期であるＳＰＳ周期３０１で、一定の周波数上の一定の周波数帯域幅で予約される。一方、図４は、一定でない時間間隔、一定でない周波数上の一定でない周波数帯域幅でのリソース群４００の割り当て例を示している。図４のように、通信リソースが一定でない時間間隔、一定でない周波数上の一定でない周波数帯域幅で予約されたものであっても、通信リソースが予め確保されたものである限り、本発明が適用可能であることは明らかである。
【００１９】
基地局から端末へ向かう下りリンクでのデータ送信を例に、Ｅ−ＵＴＲＡにおけるＳＰＳを用いたデータ送信手順を、図５を用いて説明する。図５は、ＳＰＳを用いたデータ送信手順を示すシーケンス図である。まず、シーケンス５０１において、基地局は端末に対してＲＮＴＩ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｉｅｒ）と呼ばれるＩＤを端末に割り当てる。基地局は、割り当てたＲＮＴＩを、ＳＰＳでデータ送信を行う際のスクランブル処理などに使用する。ここでは、送信するデータを予め端末に割り当てたＲＮＴＩでスクランブルしておくことにより、当該ＲＮＴＩを割り当てられた端末のみがデータを復号できるようにする。さらに、シーケンス５０２において、基地局は端末に対してＳＰＳの時間周期情報を通知する。ＳＰＳリソースを用いてデータ送信を行う際は、基地局から端末に、シーケンス５０３のＳＰＳリソースの使用開始の通知を行う。この際、シーケンス５０３で通知される情報は、端末に対して割り当てたＲＮＴＩによりスクランブルされている。シーケンス５０３で通知される情報には、ＳＰＳで確保されるリソースの周波数や変調方式などの情報が含まれる。
【００２０】
なお、シーケンス５０２で端末に通知したＳＰＳリソースの時間周期や、シーケンス５０３で端末に通知したＳＰＳリソースの周波数すなわちＲＢのＩｎｄｅｘや、符号化・変調方式すなわちＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ  ａｎｄ  Ｃｏｄｉｎｇ  Ｓｃｈｅｍｅ）といった情報は、基地局において、ＭＰＵ２６０６によって決定され、Memory２６０７中の図２５のような割当ＳＰＳリソース管理テーブル２５００に保持される。割当ＳＰＳリソース管理テーブル２５００では、割当てたＲＢのインデックスであるＲＢインデックス２５０２、ＭＣＳのインデックスであるＭＣＳインデックス２５０３、割当てたリソースのサイズ２５０４、ＳＰＳリソースの時間周期２５０５、オフセット２５０６が、各端末のＩＤ２５０１に対応付けられている。割当ＳＰＳリソース管理テーブル２５００におけるリソースのサイズ２５０４は、ＳＰＳリソースで送信する物理パケットのサイズであり、割り当てた周波数帯域幅やＭＣＳから決まる。また、図２５のテーブルにおけるオフセット２５０６は、基地局がＳＰＳのタイミングを管理するためのＳＰＳリソースの時間オフセット、つまりＳＰＳを開始する時間枠（subframe）であり、シーケンス５０３の通知を行うタイミングによって決定される。なお、図２５で説明したような割当ＳＰＳリソース管理テーブル２５００は、シーケンス５０３で通知される情報に含まれ、リソース割り当て情報として端末のメモリ２７０７に保持される。ここで、端末は、オフセット２５０６を示す情報としてシーケンス５０３のタイミングをメモリ２７０７に保持する構成としてもよい。
【００２１】
シーケンス５０３でＳＰＳリソースの使用開始の通知を行うと同時または通知後に、シーケンス５０４でＳＰＳリソースを用いて基地局から端末にデータを送信する。この際、シーケンス５０４で送信されるデータは、端末に対して割り当てたＲＮＴＩによりスクランブルされている。端末はシーケンス５０２およびシーケンス５０３で通知されたＳＰＳリソースの情報を用いて、シーケンス５０４で受信したデータを復号する。復号結果として、復号に成功した場合はＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を、復号に失敗した場合はＮＡＣＫ（Ｎｅｇａｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を、端末から基地局に通知する。図５の例では復号に成功しており、シーケンス５０５で端末から基地局にＡＣＫを通知している。後続のデータは、シーケンス５０２で設定される時間周期に従い送信される。
【００２２】
図５のシーケンス５０６では、後続のデータをＳＰＳリソースで送信している。図５の例では、シーケンス５０６で送信されたデータの復号は失敗し、シーケンス５０７で復号結果として端末から基地局にＮＡＣＫを通知している。ＮＡＣＫを受信した基地局は、ＨＡＲＱに基づくデータの再送を行う。ＨＡＲＱによるデータの再送は、ＤＳリソースを使用して行う。シーケンス５０８で、基地局は端末にＤＳリソースの割り当て情報を通知すると同時に、ＤＳリソースを使用してシーケンス５０６で送信したデータの再送を行う。端末は、シーケンス５０６およびシーケンス５０８で受信したデータの復号を試みる。図５の例では、復号に成功し、シーケンス５０９で復号結果として端末から基地局にＡＣＫを通知している。
【００２３】
本実施例においては、図５のシーケンス５０４やシーケンス５０６でＳＰＳリソースを使用してデータ送信を行うのに先立ち、基地局はデータ送信を延期するか否かの判断を行う。この判断は、当該ＳＰＳリソースに対する無意味なデータによる補完であるパディングの発生の有無や、発生量、発生頻度などに基づいて行う。ここで、パディングの発生量とは、１つの物理パケットに挿入するパディングビット量であり、パディングの発生頻度とは、パディングが行われる物理パケットの発生する時間的な頻度を指す。また、パディングの一例として、全ての値が０であるデータを基地局が生成し、基地局が当該データを無意味なデータとしてＳＰＳリソースを補完するゼロパディングが挙げられる。また、補完の一例としては、図２６で、ＤＳＰ２６０４がデータをベースバンド部２６０３に物理パケットとして送信する際に無意味なデータを付加する。
【００２４】
図６は、基地局のＭＰＵ２６０６においてパディングの有無によりデータ送信を延期するか否かを判断する手順の一例を示すフロー図である。図６のフローは、ある端末に対して予約されたＳＰＳリソースが存在する時点に先立って、すなわち図５のシーケンス５０４に先立って、基地局のＭＰＵ２６０６において行われる。図６を用いて、判断方法を説明する。まず、基地局は、図２５のテーブルの周期およびオフセットを参照し、当該ＳＰＳリソースで、当該ＳＰＳリソースを割り当てた端末に対し送信すべきユーザデータが存在するか否かを確認する（６０１）。送信すべきユーザデータが存在しない場合は、ＳＰＳリソースでデータを送信せずに（６０５）処理を終了する。送信すべきユーザデータが存在する場合は、ユーザデータのサイズと、図２５のテーブル中のリソースのサイズを比較し、基地局はパディングの有無を確認する（６０２）。パディングが発生する場合は、当該ＳＰＳリソースを割り当てた端末に対し送信すべきユーザデータの送信を、当該ＳＰＳリソースより後の時間スロットのＳＰＳリソースを用いて行うことを決定し、データ送信を遅延させ（６０４）、処理を終了する。このとき、送信が延期されたデータは、図２６のＲＬＣバッファ２６０９に格納される。パディングが発生しない場合は、当該ＳＰＳリソースを使用して、データ送信を行い（６０３）、処理を終了する。本実施例では、ＳＰＳリソースで、当該ＳＰＳリソースの予約対象である端末に対しデータ送信を行わない状態のとき、この状態のＳＰＳリソースを空きリソースと呼ぶ。
【００２５】
図２２は、基地局のＭＰＵ２６０６においてパディングの発生量によりデータ送信を延期するか否かを判断する手順の一例を示すフロー図である。図２２を用いて、判断方法を説明する。まず、ステップ２２０１では、基地局は、当該ＳＰＳリソースで、当該ＳＰＳリソースを割り当てた端末に対し送信すべきユーザデータが存在するかを確認する。送信すべきユーザデータが存在しない場合は、ステップ２２０２に移行して、ＳＰＳリソースでデータを送信せず処理を終了する。送信すべきユーザデータが存在する場合は、ステップ２２０３に移行して、基地局はパディングの発生量を確認する。パディングの発生量が既定の閾値を超える場合は、ステップ２２０４に移行して、当該ＳＰＳリソースを割り当てた端末に対し送信すべきユーザデータの送信を、当該ＳＰＳリソースより後の時間スロットのＳＰＳリソースを用いて行うことで、データ送信を遅延させ、処理を終了する。パディングの発生量が既定の閾値未満である場合は、ステップ２２０５に移行して、当該ＳＰＳリソースを使用して、データ送信を行い、処理を終了する。
【００２６】
図２３は、基地局のＭＰＵ２６０６においてパディングの発生頻度によりデータ送信を延期するか否かを判断する手順の一例を示すフロー図である。図２３を用いて、判断方法を説明する。まず、ステップ２３０１では、基地局は、当該ＳＰＳリソースで、当該ＳＰＳリソースを割り当てた端末に対し送信すべきユーザデータが存在するかを確認する。送信すべきユーザデータが存在しない場合は、ステップ２３０２に移行して、ＳＰＳリソースでデータを送信せずに処理を終了する。送信すべきユーザデータが存在する場合は、ステップ２３０３に移行して、基地局はパディングの発生頻度を確認する。パディングの発生頻度が既定の閾値を超える場合は、ステップ２３０４に移行して、当該ＳＰＳリソースを割り当てた端末に対し送信すべきユーザデータの送信を、当該ＳＰＳリソースより後の時間スロットのＳＰＳリソースを用いて行うことで、データ送信を遅延させ、処理を終了する。パディングの発生頻度が既定の閾値未満である場合は、ステップ２３０５に移行して、当該ＳＰＳリソースを使用して、データ送信を行い、処理を終了する。
【００２７】
トラヒックが音声通話や動画ストリーミング等の、即時性の高いものである場合、データ送信の遅延量が大きくなると、サービス品質が劣化してしまう。これを防ぐため、データ送信の遅延量に制限をかけてもよい。例えば、音声通話の場合は、受信側の音声復号における遅延ジッタ吸収のためのバッファの許容する範囲で、最大遅延量を決定すればよい。
【００２８】
図７および図８を用いて、遅延量に制限をかけた場合の動作について説明する。なお、図７および図８は、基地局はパディングの有無によりデータ送信を延期するか否かを判断する場合の一例であるが、７０３や８０２の判断フローにおいてパディングの発生頻度が閾値を超えるか否か、もしくはパディングの発生量が閾値を超えるか否か、に基づいてデータ送信を延期するか否かを判断を行っても良い。また、図７および図８で、遅延量が最大遅延量を超過しているか否かの判断は、音声フレームなどのトラヒックの発生からの経過時間に基づいて行っても良いし、データ送信の延期を行った回数に基づいて行っても良い。
【００２９】
図７は、遅延量が最大遅延量を超過する場合、基地局のＭＰＵ２６０６が、パディングの発生の有無に関わらずＳＰＳリソースでデータ送信を行う手順を示すフロー図である。ステップ７０１において当該ＳＰＳリソースを割り当てた端末に対し送信すべきユーザデータが存在する場合、基地局は最大遅延量を超過するか否かの確認を行う（７０２）。最大遅延量を超過する場合、当該ＳＰＳリソースでデータ送信を行う（７０４）。最大遅延量を超過しない場合は、基地局は、パディングの発生の有無を確認し（７０３）、パディングの有無により、当該ＳＰＳリソースでデータを送信するか、送信を遅延させるかを決定する。
【００３０】
図８は、遅延量が最大遅延量を超過する場合、基地局のＭＰＵ２６０６が、別途当該ＳＰＳリソースと同じ時間スロットのリソースを確保してデータ送信を行う手順を示すフロー図である。ステップ８０１において、当該ＳＰＳリソースを割り当てた端末に対し送信すべきユーザデータが存在する場合、基地局は、パディングの発生の有無を確認し（８０２）、パディングの発生の有無により、当該ＳＰＳリソースでデータを送信するか否かを決定する。パディングが発生するため当該ＳＰＳリソースでデータ送信を行わないと基地局が決定した場合、基地局は最大遅延量を超過するか否かの確認を行う（８０４）。最大遅延量を超過する場合、当該ＳＰＳリソースと同じ時間スロットである別のリソースでデータ送信を行う（８０６）。別のリソースは、ＤＳ方式により確保することができる。最大遅延量を超過しない場合は、基地局は、データ送信を延期する（８０５）。
【００３１】
上述のようにデータ送信を遅延させることにより、無線利用効率が向上することを、図９および図１０を用いて説明する。図９は、本発明を適用しない場合の、ＳＰＳリソースにおけるデータ送信の様子を表す図である。図９では、初めのＳＰＳリソースＡ９０１でユーザデータ１（９０３）が、次のＳＰＳリソースＢ９０４でユーザデータ２（９０６）が送信されている。どちらのＳＰＳリソースにおいても、ユーザデータの大きさがＳＰＳリソースの大きさに満たないため、パディングにより補完を行っている。一方、図１０は、本発明によりデータ送信を遅延させる場合の、ＳＰＳリソースにおけるデータ送信の様子の一例を表す図である。ユーザデータ１（１００６）を初めのＳＰＳリソース１００１を用いて送信する場合はパディングが発生するため、例えば図６で説明したフローにおいては、図１０に示すように、データ送信を次のＳＰＳリソース１００３まで遅延させるように判断する。図１０では、次のＳＰＳリソース１００３で、ユーザデータ１（１００５）およびユーザデータ２（１００６）をまとめて送信しており、パディングの量は図９に比べて減少している。なお、例えばユーザデータに優先度が設定されている場合は、優先度が高いデータを先に端末に送信する構成としてもよい。また、例えば端末側がユーザデータを復号するためにユーザデータ受信順序が基地局が保持した順である必要がある場合は、ユーザデータ１をユーザデータ２より優先して先に送信する構成としても良い。このように、本実施例によりデータ送信を遅延させることによって、ユーザデータの送信に用いない余剰リソースの発生を回避または削減することで、無意味なデータによる補完（パディング）を削減することが可能であり、無線利用効率を向上させることができる。
【００３２】
図２８は、端末におけるデータ受信の手順の一例を示すフロー図である。図２８のフローは、図５のシーケンスにおいて端末が当該サブフレームで基地局から送信される可能性のあるリソース割り当て情報の取得（５０３）を行ったあとに、当該リソース割り当て情報に基づいて行われる。端末において、まずステップ２８０１において当該端末に対して当該サブフレームでＤＳ方式によるリソース割り当てがあるかないかを確認する。ＤＳ方式によるリソース割り当てがある場合は、割り当てられたリソースにおいてデータ受信処理を行う（２８０３）。ＤＳ方式によるリソース割り当てがない場合は、ステップ２８０２において、当該端末に対して予約されたＳＰＳリソースが当該サブフレームに存在するか否かを確認する。予約されたＳＰＳリソースが存在しない場合は、当該サブフレームで受信すべきデータが無いと判断し、処理を終了する。一方、予約されたＳＰＳリソースが存在する場合、予約されたリソースにおいてデータ受信処理を行う（２８０３）。ステップ２８０３でデータ受信処理を行った後、復号結果の判定を行う（２８０４）。復号が失敗した場合は、端末はＮＡＫ応答を基地局に通知する（２８０５）。復号が成功した場合は、端末はＡＣＫ応答を基地局に通知する（２８０６）。
【００３３】
以下において、本発明を適用する通信システム、および前記無線システムにおける無線基地局、無線端末についての他の実施例について説明する。なお、上述の本実施例において無線通信システム、基地局、端末の構成例、基地局および端末が行う処理例、各リソースおよび各データに関する特徴、などは、特に別途説明が無い限りは、以下の各実施例においても共通である。
【実施例２】
【００３４】
本発明を適用する第２の実施例を、図１１および図１２を用いて説明する。本実施例では、空きリソースが発生した場合に、当該ＳＰＳリソースを解放する。ここで、本実施例では、ＳＰＳリソースの解放とは、ＳＰＳリソースを、当該ＳＰＳリソースの予約対象の端末に対するデータ送信に使わないことを基地局が決定することを意味する。
【００３５】
図１１のように、ステップ１１０１で空きリソースが発生した場合、基地局は当該ＳＰＳリソースを解放して（１１０２）判断を終了する。また、空きリソースが発生しなかった場合、そのまま判断を終了する。解放したリソースは、他の端末へのデータ送信に使用してもよい。図１２は、基地局が、解放したリソースを、他の端末へ割り当て、データの送信を行う手順の一例を示すフロー図である。図１２では、ステップ１２０１で空きリソースが発生しなかった場合、処理を終了する。一方、ステップ１２０１で空きリソースが発生した場合、基地局は、ＳＰＳリソースを割り当てられていない他の端末が、送信すべきユーザデータを持っているかを確認する（１２０２）。他の端末が送信すべきユーザデータを持っている場合、基地局はＤＳ方式により、解放されたリソースに該当する周波数帯域、すなわちＲＢ（Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）を他の端末に割り当てる（１２０３）。他の端末が送信すべきユーザデータを持っていない場合、処理を終了する。ＳＰＳリソースを解放し、他の端末にデータ送信を行う場合、当該他の端末に対しＤＳ方式によるリソース割り当ての通知を行い（１２０４）、当該リソースを用いてデータを送信する（１２０５）。なお、空きリソースを必ずしも他の端末に割り当てる必要はなく、ＳＰＳリソースの解放が行われた端末に対し、別のトラヒックの送信すべきデータが存在する場合、ＳＰＳリソースの解放を中止し、別のトラヒックのデータを送信するために使用しても良い。この場合は新たにリソース割り当ての通知を行う必要はない。なお、図１１および図１２で説明した制御は、基地局のＭＰＵ２６０６が行なう。
【００３６】
上記のように、空きリソースを他の端末に対するデータ送信、あるいは同一端末の別のトラヒックのデータ送信に使用することにより、無線リソースにおける余剰リソースの発生を回避または削減することが可能になり、無線リソースの利用効率の向上に供する。
【実施例３】
【００３７】
本発明を適用する第３の実施例では、一連のＳＰＳリソースを複数の端末で共有する。ここで、一連のＳＰＳリソースとは、図５において説明した様に、ある端末に対して割り当てられる、特定の時間周期で、特定の周波数帯域幅として割り当てられる複数のＳＰＳリソースからなるリソース群を指す。
【００３８】
図１３は、本実施例を適用しない場合に、ＳＰＳリソースを使用して、基地局が端末Ａおよび端末Ｂにデータ送信を行う様子を表す図である。図１３では、それぞれの端末に対して確保した一連のＳＰＳリソースを使用して、それぞれの端末に対するデータ送信を行っている。例えば、図１３の端末Ａに対しては、初めの端末Ａ用のＳＰＳリソース１３０１でユーザデータＡ１（１３０３）が、次の端末Ａ用のＳＰＳリソース１３０７でユーザデータＡ２（１３０９）が送信されている。どちらのＳＰＳリソースにおいても、ユーザデータの大きさがＳＰＳリソースの大きさに満たないため、パディングにより補完を行っている。端末Ｂについても同様である。
【００３９】
一方、本実施例を適用して、複数の端末で一連のＳＰＳリソースを共有する場合の、データ送信の様子を図１４を用いて説明する。図１４は、本実施例を適用する場合に、ＳＰＳリソースを使用して、基地局が端末Ａおよび端末Ｂにデータ送信を行う様子の一例を表す図である。図１４では、端末Aと端末Bで共有する一連のＳＰＳリソース１４００において、基地局は端末Ａと端末Ｂのどちらにもデータ送信を行っている。図１４のＳＰＳリソースｍ１４１１では、基地局は、ユーザデータＡ１（１４０３）とユーザデータＡ２（１４０２）を、端末Ａに送信する。次のＳＰＳリソースｎ１４１２では、基地局は、ユーザデータＢ１（１４０６）とユーザデータＢ２（１４０５）を、端末Ｂに送信する。このことは、例えば端末Ａ、端末ＢがＳＰＳリソースを共有するとしたとき、端末Ａへのデータ送信を、共有するＳＰＳリソースを使用して行うサブフレームでは、端末Ｂへのデータ送信を遅延させる、あるいは、端末Ｂへのデータ送信を、共有するＳＰＳリソースを使用して行うサブフレームでは、端末Ａへのデータ送信を遅延させることにより可能である。このとき、一連のＳＰＳリソースを共有する端末には、互いに異なるＲＮＴＩを適用するものとする。
【００４０】
本実施例におけるデータ送信の手順は図５で説明したものと異なり、図１５を用いて説明する。図１５では、図１４と同じく、端末Ａと端末Ｂが、一連のＳＰＳリソースを共用するとする。まず、シーケンス１５０１およびシーケンス１５０２において、基地局は各端末に対してそれぞれ、端末固有のＲＮＴＩを割り当てる。さらに、シーケンス１５０３およびシーケンス１５０４において、基地局は各端末に対して個別に、ＳＰＳの時間周期情報を通知しておく。このとき、端末Ａと端末Ｂに通知する時間周期は同じであることが望ましい。ＳＰＳリソースを用いてデータ送信を行うのに先立ち、基地局から各端末に対し個別に、シーケンス１５０５およびシーケンス１５０６でＳＰＳリソースの使用開始の通知を行う。この際、ＳＰＳリソースの使用開始の通知タイミングは同じであることが望ましい。
【００４１】
シーケンス１５０５およびシーケンス１５０６で通知される情報は、端末に対して割り当てたＲＮＴＩによりスクランブルされている。シーケンス１５０５およびシーケンス１５０６で通知される情報には、図２５で説明したような割当ＳＰＳリソース管理テーブル２５００内の、当該端末に対応する情報が含まれる。シーケンス１５０５およびシーケンス１５０６でＳＰＳリソースの使用開始の通知を行うと同時または通知後に、基地局はＳＰＳリソースを用いて端末にデータを送信する。図１５の例では、シーケンス１５０７において、基地局は端末Ａに対し、ＳＰＳリソースを用いてデータ送信を行っている。この際、シーケンス１５０７で送信されるデータは、端末Ａに対して割り当てたＲＮＴＩによりスクランブルされている。従って、データ送信の際、基地局からの送信信号はどちらの端末でも受信されるが、端末Ｂはこの送信信号に含まれるデータのスクランブルコード（端末ＡのＲＮＴＩ）を知らないから、端末Ｂは、端末Ａに宛てて送信されたデータを復号することはできない。一方、端末Ａは自らに予め割り当てられたＲＮＴＩを用いて、シーケンス１５０７で送信されたデータを復号することができる。
【００４２】
図１５の例では、端末Ａはシーケンス１５０７で送信されたデータの復号に成功し、シーケンス１５０８において復号結果としてＡＣＫを基地局に通知している。端末Ｂは、前述の理由から復号に失敗するから、シーケンス１５０９において復号結果としてＮＡＣＫを基地局に通知している。次のＳＰＳリソースでは、シーケンス１５１０において、基地局は端末Ｂに対し、ＳＰＳリソースを用いてデータ送信を行っている。この際、シーケンス１５１０で送信されるデータは、端末Ｂに対して割り当てたＲＮＴＩによりスクランブルされている。このため、端末Ａはシーケンス１５１０で送信されるデータを復号できず、シーケンス１５１１で復号結果としてＮＡＣＫを基地局に通知している。図１５の例では、端末Ｂはシーケンス１５１０で送信されるデータの復号に成功し、シーケンス１５１２で復号結果としてＡＣＫを基地局に通知している。
【００４３】
ところで、図１５で、基地局は、シーケンス１５０７では端末Ａに宛てて、シーケンス１５１０では端末Ｂに宛てて、データを送信している。従って、基地局は、シーケンス１５０９およびシーケンス１５１１で通知されるＮＡＣＫが、データの宛先ではない端末からのものであることを予め知っている。よって、基地局はシーケンス１５０９およびシーケンス１５１１で通知されるＮＡＣＫを無視してよい。
【００４４】
図２４は、同一のＳＰＳリソースを複数の端末が共有する場合の、基地局におけるデータ送信の手順の一例を示す例である。図２４の処理は、当該サブフレームにおいて送信するデータを決定する際に用い、例えば図１５のシーケンス１５０７や、シーケンス１５１０に先立って行われる。また、図２４では、図１５と同様に、端末Ａと端末Ｂが、一連のＳＰＳリソースを共用するとする。図２４において、基地局はまず、端末Ａに送信すべきデータの有無の確認（２９０１）、端末Ｂに送信すべきデータの有無の確認（２９０２および２９０３）を行う。この結果、どちらか一方の端末に対してのみ送信すべきデータがある場合は、送信すべきデータがある端末に対してデータ送信を行う。すなわち、ステップ２９０１でＹｅｓ、ステップ２９０２でＮｏと判定されれば、ステップ２９０５において端末Ａにデータ送信を行う。あるいは、ステップ２９０１でＮｏ、ステップ２９０３でＹｅｓと判定されれば、ステップ２９０６において端末Ｂにデータ送信を行う。いずれの端末に対しても送信すべきデータが無い場合は、データ送信は行わない（２９０７）。いずれの端末に対しても送信すべきデータがある場合は、どの端末に対してデータ送信を行うべきか判定する。図２４の例では、データサイズにより判定するものとしている。ステップ２９０４において、端末Ａに送信すべきデータのサイズが、端末Ｂに送信すべきデータのサイズより大きければ、ステップ２９０５において端末Ａにデータ送信を行う。ステップ２９０４において、端末Ａに送信すべきデータのサイズが、端末Ｂに送信すべきデータのサイズより小さければ、ステップ２９０６において端末Ｂにデータ送信を行う。
上記のように、同一の一連のＳＰＳリソースを複数の端末で共有することにより、無線リソースにおける余剰リソースの発生を回避または削減することが可能になり、無線リソースの利用効率の向上に供する。
【実施例４】
【００４５】
本発明を適用する第４の実施例を、図１６を用いて説明する。本実施例では、空きリソースの有無、発生量、または発生頻度を基準として、一連のＳＰＳリソースの、複数の端末による共用を開始する。ここで、一連のＳＰＳリソースとは、第３の実施例と同様に、特定の時間周期で、特定の周波数帯域幅として割り当てられる複数のＳＰＳリソースからなる一連のリソース群を指す。
【００４６】
図１６は、基地局のＭＰＵ２６０６が、各端末の空きリソースの有無を基準として、一連のＳＰＳリソースの、複数の端末による共用を開始するか否かを判断する手順の一例を示している。図１６で、基地局は各端末が空きリソースを持つか否かを確認し（１６０２）、空きリソースを持つ端末の数ａをカウントする（１６０３）。そして、基地局は、空きリソースを持つ端末の数ａが予め定められた閾値以上であるか否かを判定する（１６０４）。ａが予め定められた閾値以上であれば、空きリソースが十分多いと判断し、一連のＳＰＳリソースを、複数の端末で共用することを開始すると決定する（１６０５）。ａが予め定められた閾値未満であれば、空きリソースが不十分であると判断し、処理を終了する。ここで、一連のＳＰＳリソースを複数の端末で共用しない場合は、一連のＳＰＳリソースを単一の端末へのデータ送信に利用することとなる。なお、本実施例における、一連のＳＰＳリソースを共有する複数の端末と基地局とのデータ送受信の一例は、実施例３で図１４、図１５、図２４を用いて説明した通りである。
【００４７】
図１６の例では、基地局は各端末について空きリソースの有無を確認しているが、１６０２における判定において、特定の端末が使用する一連のＳＰＳリソースにおける、空きリソースの発生量または発生頻度が閾値以上であるか否かを基準として、一連のＳＰＳリソースの共用開始を決定しても良い。
上記のように、空きリソースを解消するように同一の一連のＳＰＳリソースを複数の端末で共有することにより、無線リソースにおける余剰リソースの発生を回避または削減することが可能になり、無線リソースの利用効率の向上に供する。
【実施例５】
【００４８】
本発明を適用する第５の実施例を、図１７を用いて説明する。本実施例では、無意味なデータでの補完（パディング）の有無、発生量、または発生頻度を基準として、一連のＳＰＳリソースの、複数の端末による共用を開始する。ここで、一連のＳＰＳリソースとは、第３の実施例と同様に、特定の時間周期で、特定の周波数帯域幅として割り当てられる複数のＳＰＳリソースからなるリソース群を指す。
【００４９】
図１７は、基地局のＭＰＵ２６０６が、各端末のパディングの発生量を基準として、一連のＳＰＳリソースの、複数の端末による共用を開始するか否かを判断する手順の一例を示している。図１７で、基地局のＭＰＵ２６０６は各端末に対してパディングの発生量を確認し（１７０２）、パディングの発生量が予め定められた発生量の閾値以上である端末の数ａをカウントする（１７０３および１７０４）。そして、基地局のＭＰＵ２６０６は、発生量の閾値以上の量のパディングが発生する端末の数ａが、予め定められた端末数の閾値以上か否かを判定する（１７０５）。ここで、パディングの発生量は、例えばリソースのサイズ２５０４とデータの容量の比較によって行う。数ａが、予め定められた端末数の閾値以上であれば、無意味なデータでの補完が多いと判断し、一連のＳＰＳリソースを、複数の端末で共用することを開始すると決定する（１７０６）。一方、数ａが予め定められた端末数の閾値未満であれば、一連のＳＰＳリソースを複数の端末で共用を開始せずに処理を終了する。ここで、一連のＳＰＳリソースを複数の端末で共用しない場合は、一連のＳＰＳリソースを単一の端末へのデータ送信に利用することとなる。なお、本実施例における、一連のＳＰＳリソースを共有する複数の端末と基地局とのデータ送受信の一例は、実施例３で図１４、図１５、図２４を用いて説明した通りである。
【００５０】
図１７の例では、基地局は各端末についてパディングの量を確認しているが、１７０３における判定において、特定の端末が使用する一連のＳＰＳリソースにおける、パディングの有無や発生頻度を基準として、一連のＳＰＳリソースの共用開始を決定しても良い。
上記のように、パディングを抑制するように同一の一連のＳＰＳリソースを複数の端末で共有することにより、無線リソースにおける余剰リソースの発生を回避または削減することが可能になり、無線リソースの利用効率の向上に供する。
【実施例６】
【００５１】
本発明の上記実施形態適用する第６の実施例を、図１８を用いて説明する。本実施例では、過去のデータ送信状況を基準として、一連のＳＰＳリソースの、複数の端末による共用を開始する。ここで、一連のＳＰＳリソースとは、第３の実施例と同様に、特定の時間周期で、特定の周波数帯域幅として割り当てられる複数のＳＰＳリソースからなる一連のリソース群を指す。
【００５２】
図１８は、基地局のＭＰＵ２６０６が、各端末に対する過去のデータ送信状況を基準として、一連のＳＰＳリソースの、複数の端末による共用を開始するか否かを判断する手順の一例を示している。図１８で、基地局のＭＰＵ２６０６は各端末に対して、過去の時間ｎの間にデータを送信したか否かを確認し（１８０２）、過去の時間ｎの間にデータを送信しなかった端末の数ａをカウントする（１８０３）。なお、例えば、ＭＰＵ２６０６が図２２の２２０２のようなデータ送信しないという判断を行なう度にメモリ２６０７にカウント数を加えて保持し、１８０２において過去の時間ｎの間のカウント数をＭＰＵ２６０６が確認する構成としてもよい。そして、基地局は、過去の時間ｎの間にデータを送信しなかった端末の数ａが予め定められた閾値以上であれば（１８０４のＹｅｓ）、ＳＰＳで確保したリソース群に対して送信すべきユーザデータ量が少ないと判断し、一連のＳＰＳリソースを、複数の端末で共用することを開始すると決定する（１８０５）。ここで、過去の時間ｎの間というのは、ステップ１８０２の時点から時間ｎだけ遡った時点までの期間、を意味する。また、時間ｎは基地局に予め設定されている。なお、本実施例における、一連のＳＰＳリソースを共有する複数の端末と基地局とのデータ送受信の一例は、実施例３で図１４、図１５、図２４を用いて説明した通りである。
【００５３】
図１８の例では、基地局は各端末について過去のデータ送信状況を確認しているが、特定の端末が使用する一連のＳＰＳリソースにおける、過去のデータ送信状況を基準として、一連のＳＰＳリソースの共用開始を決定しても良い。
【００５４】
ＡＭＲなどの音声符号化方式では、無音区間におけるデータ量や音声フレーム発生頻度は、有音区間に対して小さい。そこで、本実施例において、音声データを送信する場合は、無音区間である端末によって、一連のＳＰＳリソースを共有しても良い。
上記のように、送信すべきデータ量が少ない場合に、同一の一連のＳＰＳリソースを複数の端末で共有することにより、無線リソースにおける余剰リソースの発生を回避または削減することが可能になり、無線リソースの利用効率の向上に供する。
【実施例７】
【００５５】
本発明を適用する第７の実施例では、実施例３〜６において説明した様な一連のＳＰＳリソースを共用する構成において、端末の数や、端末の組合せを、動的に変更することを特徴とする。
図１９は、一連のＳＰＳリソースを複数の端末で共有している場合に、基地局のＭＰＵ２６０６が、空きリソースやリソース不足の発生状況を基準として、一連のＳＰＳリソースを共有する端末数を増減させる手順の一例を表したものである。図１９において、基地局はまず、複数の端末が共有する一連のＳＰＳリソースで、空きリソースが発生するか否かを確認する（１９０１）。空きリソースが発生する場合は、基地局はＳＰＳリソースに余裕があると判断し、一連のＳＰＳリソースを共有する端末数を増加させる（１９０２）。空きリソースが発生しない場合は、基地局は、複数の端末が共有する一連のＳＰＳリソースで、送信すべきデータ量に対してリソースの不足が発生するか否かを確認する（１９０３）。リソース不足が発生する場合は、基地局はＳＰＳリソースが端末数に対して余裕がないと判断し、一連のＳＰＳリソースを共有する端末数を減少させる（１９０４）。
【００５６】
図１９の例では、空きリソースの有無やリソース不足を基準とし端末数を変更しているが、データ送信状況や、パディングの発生状況、トラヒック発生状況を基準としてもよい。例えば、ＡＭＲなどの音声符号化方式では、無音区間におけるデータ量や音声フレーム発生頻度は、有音区間に対して小さい。そこで、本実施例において、音声データを送信する場合は、端末が無音区間か有音区間であるかを基準として、一連のＳＰＳリソースを共有する端末数や組合せを変更しても良い。
【００５７】
なお、本実施例における、一連のＳＰＳリソースを共有する複数の端末と基地局とのデータ送受信の一例は、実施例３で図１４、図１５、図２４を用いて説明した通りである。ただし、一連のＳＰＳリソースを共用する構成において、端末の数や、端末の組合せを変更する際に、端末に割り当てたＳＰＳリソースを変更する必要がある場合は、基地局はＳＰＳリソースの更新を端末に通知する。ＳＰＳリソースの更新は、例えば、ＳＰＳリソースの時間オフセットや周波数リソースを変更する場合は図１５のシーケンス１５０５またはシーケンス１５０６と同様の方法を用いてもよいし、あるいは、ＳＰＳリソースの時間周期を変更する場合は図１５のシーケンス１５０３またはシーケンス１５０４と同様の方法を用いてもよい。この際、端末は、１５０３〜１５０６等で通知されたＳＰＳリソースの更新内容を図２５で説明したような割当ＳＰＳリソース管理テーブル２５００に反映させる。
上記のように、同一の一連のＳＰＳリソースを複数の端末で共有しつつ、共有する端末数を状況に応じて変更することにより、空きリソースの発生およびリソース不足の両方を抑制し、無線利用効率の向上に寄与する。
【実施例８】
【００５８】
本発明を適用する第８の実施例では、基地局が端末に送信するデータが音声データである、ＳＰＳリソースで音声データを送信する。以下において、本実施例の説明を音声データの特徴に基づいて行うが、音声データ以外のデータに対しても、本実施例で説明する処理と同様の処理を行うことは可能である。ここで、音声データの特徴とは、送信側のボコーダが一定の時間周期で音声フレームを出力することを指す。また、受信側のボコーダも一定の時間周期で音声フレームを入力する必要があるため、無線通信区間の遅延ジッタを吸収するため、通常、受信側のボコーダの前にデジッタバッファが設けられる。すなわち、デジッタバッファで吸収することができる遅延は、許容される。一方、デジッタバッファで許容する遅延量を超えた音声フレームは、破棄される。
【００５９】
図２０および図２１を用いて、本実施例を適用し、音声データを送信する手順を説明する。図２０は、ＳＰＳを使用した音声データ送信の様子を表している。図２０では、ＡＭＲやＥＶＲＣのように、一定の時間周期で音声フレームを出力し、音声フレーム毎にサイズが異なる音声符号化方式を仮定している。また、図２０では、ＳＰＳの周期を、音声フレームの周期に一致させている。従って、図２０では各ＳＰＳリソースにおいて、音声フレームが送信されている。音声フレーム毎にサイズが異なるため、最大サイズの音声フレームを送信するのに充分なＳＰＳリソースを確保している。従って、最大サイズの音声フレームを送信する場合以外では、パディングを行う必要がある。
【００６０】
図２１は、本実施例を音声データ送信に適用した場合のデータ送信の様子を示している。図２１では、初めのＳＰＳリソース（２１０１）ではデータ送信を行わず、次のＳＰＳリソース（２１０２）へデータ送信を遅延させている。次のＳＰＳリソース（２１０２）では、２つのユーザデータ（２１０３および２１０４）をまとめて送信している。このように、本実施例を適用することにより、音声データの特徴を活用して、無線利用効率を向上させることができる。ここで、デジッタバッファで許容する遅延量を超えない遅延時間２１１０の範囲でデータ送信の遅延を行うように設定することが望ましい。例えば、図７および図８を用いて説明した様に、遅延量に制限をかけ、最大遅延量をデジッタバッファで許容する遅延量に設定する。
【００６１】
図２１で発生した空きリソース（２１０１）は、第２の実施例のように他の端末に割り当てても良い。また、第３から第７の実施例のように、一連のＳＰＳリソースを複数の端末で共有しても良い。
【００６２】
ここで、一連のＳＰＳリソースを複数の端末で共有する場合、トラヒック量の変動などにより、送信すべきユーザデータ量に対して、確保したリソースの量が不足する場合がある。特に音声トラヒックなどの即時性の高いサービスの場合、リソースの不足により、データ送信を遅延させ続けると、サービス品質の劣化を招く。そこで、リソースが不足する場合は、一定以上遅延させたパケット、例えば受信側の音声復号における遅延ジッタ吸収のためのデジッタバッファの許容する範囲を超過する遅延を行うパケットを廃棄してもよいし、第７の実施例のように、一連のＳＰＳリソースを共有する端末数や端末の組合せを変更しても良い。あるいは、リソースが不足する場合はＤＳ方式により一時的にリソースを追加で割り当てても良い。
また、リソースの不足によるパケットの廃棄などを避けるため、一連のＳＰＳリソースの共有を、基地局に接続する端末数が多い場合に限り、基地局に接続する端末数が少ない場合は一連のＳＰＳリソースの共有を中止するといった切り替えを行っても良い。
上記のように、デジッタバッファで許容される範囲で音声フレームの送信を遅延させることにより、パディングの量を低減し、無線利用効率の向上に寄与するとともに、サービス品質の劣化を防ぐことに寄与する。
【産業上の利用可能性】
【００６３】
本発明によれば、データ送信を遅延させることにより、無意味なデータによる補完の発生やその量を抑制することができ、無線通信システムにおける無線利用効率を向上させることができる。
【符号の説明】
【００６４】
１０１a、１０１b、１０１c : 基地局
１０２a、１０２b、１０２c : 端末
３００：ＳＰＳリソース
１００１：ＳＰＳリソースＡ
１００２、１００４：パディング
１００３：ＳＰＳリソースＢ
１００５：ユーザデータ１
１００６：ユーザデータ２
２５００：割当ＳＰＳリソース管理テーブル
２５０１：端末ＩＤ
２５０２：ＲＢインデックス
２５０５：ＳＰＳリソースの時間周期
２５０６：ＳＰＳリソースの時間オフセット
２６０６：基地局の制御部
２６０７：基地局のメモリ
２７０６：端末の制御部
２７０７：端末のメモリ
【図１】
2011071799.tif 000003
【図２】
2011071799.tif 000004
【図３】
2011071799.tif 000005
【図４】
2011071799.tif 000006
【図５】
2011071799.tif 000007
【図６】
2011071799.tif 000008
【図７】
2011071799.tif 000009
【図８】
2011071799.tif 000010
【図９】
2011071799.tif 000011
【図１０】
2011071799.tif 000012
【図１１】
2011071799.tif 000013
【図１２】
2011071799.tif 000014
【図１３】
2011071799.tif 000015
【図１４】
2011071799.tif 000016
【図１５】
2011071799.tif 000017
【図１６】
2011071799.tif 000018
【図１７】
2011071799.tif 000019
【図１８】
2011071799.tif 000020
【図１９】
2011071799.tif 000021
【図２０】
2011071799.tif 000022
【図２１】
2011071799.tif 000023
【図２２】
2011071799.tif 000024
【図２３】
2011071799.tif 000025
【図２４】
2011071799.tif 000026
【図２５】
2011071799.tif 000027
【図２６】
2011071799.tif 000028
【図２７】
2011071799.tif 000029
【図２８】
2011071799.tif 000030