JP6477446B2 - 通信装置 - Google Patents

Description

本発明は、ユーザ側の通信装置がバッファに滞留しているデータの量を無線基地局に報告することで、無線基地局がその滞留しているデータの量に応じた通信リソースを割り当てる無線通信システムで用いられる通信装置に関する。

近年、ＨＳＰＡ（High Speed Packet Access）やＬＴＥ（Long Term Evolution）等といった広域無線通信規格の登場により、高速な無線通信サービスが広く提供されるようになった。

ＬＴＥのアップリンク通信では、ＦＤＭＡ（Frequency-Division Multiple Access）ベースの無線アクセス方式が採用されている。すなわち、無線基地局（いわゆるｅＮｏｄｅＢ：evolved NodeB）が、ユーザ側の通信装置（以降、ＵＥ：User Equipment）に対し、ＵＥが保持している未送信のデータ量に応じた通信帯域を与えることで、通信リソースの効率的な運用を実現する。

具体的には、ＵＥは、自分自身が備えるバッファにアップリンクで送信すべきデータが到着した場合、グラントの割り当てを要求するスケジューリングリクエスト（ＳＲ：Scheduling Request）を、アップリンク制御チャネル（以降、ＰＵＣＣＨ：Physical Uplink Control Channel）で送信する。ここでのグラントとは、アップリンクデータを送信する際に利用する周波数やタイミング、変調方式等を指す。ＰＵＣＣＨは、通信の接続制御のためのアップリンク通信に用いられる通信チャネルである。

無線基地局は、ＵＥからのＳＲを受信するとグラントを割り当てて、当該割り当てたグラントでデータの送信を実施するように、ダウンリンク制御チャネル（ＰＤＣＣＨ：Physical Downlink Control Channel）で指示する。なお、ＰＤＣＣＨは、通信の接続制御のためのダウンリンク通信に用いられる通信チャネルである。

ＵＥは、無線基地局から指示されたグラントに対応するＰＵＳＣＨ（Physical Uplink Shared Channel）を用いて、送信待ち状態のデータとしてバッファに蓄積されているデータの量を示すバッファ状態報告（以降、ＢＳＲ：Buffer Status Report）を送信する。ＰＵＳＣＨは、アップリンクのデータを送信するための共有データチャネルである。

無線基地局は、ＢＳＲを受信すると、当該ＢＳＲに示されているデータ量に応じたグラントを再度割り当てて、当該割り当てたグラントにてバッファに格納されているデータを送信するようにＰＤＣＣＨで指示する。そして、ＵＥは、指示されたグラントを用いて順次バッファ中のデータを送信していく。

また、ＵＥは、ＢＳＲの送信をトリガとして、再送ＢＳＲタイマ（いわゆるretx-BSR-timer）を起動する。この再送ＢＳＲタイマは、ＢＳＲが欠損したと見なして、ＢＳＲを再度送信するためのタイマである。再送ＢＳＲタイマが満了するまでにグラントを指示する無線基地局からの制御データを受信しなければ、ＵＥは、ＳＲの送信、グラントの受信、ＢＳＲの再送といった処理を実施する。

なお、ＢＳＲは、再送ＢＳＲタイマが満了した時だけでなく、特許文献１に開示のように、Periodic BSRタイマが満了した時などにも送信される。

特開２０１４−１３８３１０号公報

近年は、スマートフォン等の携帯端末だけでなく、車両や、工作機器、自動販売機等にも、こういった高速なデータ通信を実現する広域無線通信規格に準拠した無線通信を実施する機能（以降、広域無線通信機能）を備えさせようとする動きがある。種々の物体に無線通信機能を付加することで、製品／サービスの付加価値を向上させたり、アフターサービスを充実させたり、業務効率を改善したりすることが可能となるためである。

例えば工作機器に広域無線通信機能を付与すれば、稼働時間、状態、位置を遠隔で監視することが出来るようになる。また、車両に広域無線通信機能を付与することで、交通情報やナビゲーション等の情報サービスをリアルタイムに提供したり、位置情報、運行状況、車室内温度などを遠隔でリアルタイムに監視したりすることができる。

このような無線通信機能の利用目的（換言すれば用途）が多様化するにつれて、より一層、通信のリアルタイム性（換言すれば、より低遅延な通信）を要求するサービス、及び、当該サービスを実現するためのアプリケーションソフトウェア（以降、アプリ）の登場が想定される。

しかしながら、ＵＥは、送信したＢＳＲが欠損してしまった場合、再送ＢＳＲタイマが満了するまではアップリンク通信を再開できない。つまり、再送ＢＳＲタイマが起動してから満了するまでの時間が、通信遅延の要因となりうる。

そのような事情を鑑みると、低遅延な通信を要求するアプリに対しては、再送ＢＳＲタイマの設定値は相対的に小さい値に設定することが好ましい。一方、リアルタイム性の要求がそこまで高くないアプリに対しては、ＢＳＲが過剰に送信されること抑制するために、再送ＢＳＲタイマは相対的に大きい値に設定されていることが望ましい。

つまり、或るＵＥにおける再送ＢＳＲタイマの設定値は、当該ＵＥが提供する無線通信機能を利用するアプリが要求するリアルタイム性に応じた値に設定されることが好ましい。しかしながら、現状、再送ＢＳＲタイマの設定値は、無線基地局から通知される値（以降、通知設定値）が適用される構成となっている。

本発明は、この事情に基づいて成されたものであり、その目的とするところは、所定のサービスを提供するアプリケーションソフトウェアが要求するリアルタイム性に応じた値を再送ＢＳＲタイマの設定値として適用可能な通信装置を提供することにある。

その目的を達成するための本発明は、バッファに滞留しているデータの量を示すバッファ状態報告を、無線基地局に送信する送信処理部（Ｆ１）と、バッファ状態報告を送信してからの経過時間が、タイマ設定値として設定されている時間となった場合にバッファ状態報告を再送するための処理を実行する再送処理部（Ｆ３）と、を備える通信装置と、通信装置から送信されてくるバッファ状態報告に示されているデータ量に応じて、当該通信装置に対して通信リソースを割り当てる無線基地局と、を備える無線通信システムで用いられる通信装置であって、無線基地局から配信される、タイマ設定値として採用すべき値である配信値を取得し、当該配信値を、所定の記憶媒体を用いて実現される配信値記憶部
（Ｍ２）に格納する配信値格納処理部（Ｆ２）と、配信値の代わりにタイマ設定値として設定可能な値である代理値を予め記憶している代理値記憶部（Ｍ３）と、タイマ設定値として代理値を採用するための条件である代理値適用条件が充足されているか否かを判定する判定部（Ｆ４）と、判定部の判定結果に基づいてタイマ設定値を変更する設定値変更部（Ｆ５）と、を備え、判定部は、バッファにデータが存在しているか否かを代理値適用条件の１つとして判定するように構成されており、設定値変更部は、判定部によってバッファにデータ存在していると判定されている場合には、配信値を取得している場合であっても代理値をタイマ設定値に設定する一方、判定部によってバッファにデータが存在していないと判定されている場合には、配信値をタイマ設定値に設定するように構成されていることを特徴とする。

以上の構成を備える通信装置としてのＵＥは、代理値適用条件が充足されている場合には、タイマ設定値として代理値を適用する。したがって、代理値として、当該ＵＥと協働する所定のアプリケーションソフトウェア（以降、アプリ）が要求する低遅延性を実現する値を設定しておけば、所定のサービスを提供するアプリケーションソフトウェアが要求するリアルタイム性に応じた値を再送ＢＳＲタイマの設定値として適用することができる。

なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

本実施形態に係る無線通信システム１００の概略的な構成を示す図である。 ＵＥ１０と無線基地局２０との通信手順を説明するための図である。 ＵＥ１０と無線基地局２０との通信手順を説明するための図である。 ＵＥ１０の概略的な構成の一例を示すブロック図である。 バッファＭ１の使われ方を説明するための概念図である。 アプリ毎の代理値Ｔｒｅｐの一例を示す図である。 設定値変更関連処理のフローチャートである。 設定値変更処理のフローチャートである。 実施形態の作動を説明するための概念図である。 実施形態の作動を説明するための概念図である。 変形例３における設定値変更関連処理について説明するためのフローチャートである。 ＵＥ１０の使われ方に応じた代理値Ｔｒｅｐについて説明するための図である。 ＵＥ１０の用途に応じた代理値Ｔｒｅｐの一例を示す図である。

以下、本発明の実施形態について図を用いて説明する。図１は、本発明に係る無線通信システム１００の概略的な構成の一例を示す図である。無線通信システム１００は、広域無線通信規格としてのＬＴＥに準拠した無線通信を提供するシステムである。

無線通信システム１００は、図１に示すように、ユーザ側の通信装置としてのユーザ装置（以降、ＵＥ）１０と、無線基地局２０とを備える。無線基地局２０は、いわゆるｅＮｏｄｅＢとして機能する設備であり、各ＵＥ１０に対する通信リソースの割り当て（つまりスケジューリング）を行う。

ＵＥ１０が請求項に記載の通信装置に相当する。なお、図１においては便宜上、ＵＥ１０を１つしか図示していないが、実際には複数のＵＥ１０が存在しうる。また、無線基地局２０も同様に、複数存在しうる。

ＵＥ１０は、スマートフォンやタブレット端末等の携帯型通信端末であってもよいし、車両に搭載された通信端末であっても良い。さらに、ＵＥ１０は、工作機器や、重機、飲料缶等の自動販売機などに備えられていても良い。ここでは一例として、ＵＥ１０は車両で用いられる通信装置とし、当該ＵＥ１０が用いられている車両を自車両とも記載する。

＜無線通信システム１００の概要＞
まずは、ＵＥ１０と無線基地局２０との通信手順の概要について述べる。なお、以降では、ＵＥ１０から無線基地局２０へ向かう通信回線をアップリンク、無線基地局２０からＵＥ１０へ向かう通信回線をダウンリンクと記載する。ＬＴＥのアップリンク通信では、ＦＤＭＡベースの無線アクセス方式が採用されており、無線基地局２０が、各ＵＥ１０に対して、ＵＥ１０が保持している未送信のデータ量に応じた通信リソースを与える。

より具体的には、次の通りである。まず、ＵＥ１０は、自分自身が備えるバッファに、アップリンクで送信するためのデータが到着した場合、図２に示すように、当該データの送信許可を要求するＳＲを、ＰＵＣＣＨで無線基地局２０に送信する。図２中の時刻Ｔａは、ＵＥ１０がＳＲを送信するタイミングを表している。

なお、バッファに到着するデータの提供元としては、ＵＥ１０自分自身、又は、ＵＥ１０と相互通信可能に接続されているコンピュータにインストールされているアプリケーションソフトウェア（以降、アプリ）である。便宜上、ここでは一例として、ＵＥ１０自分自身にアプリがインストールされているものとする。また、バッファに到着するデータには、通信の接続制御用のデータも含まれる。

無線基地局２０は、ＵＥ１０からのＳＲを受信すると、当該ＵＥ１０に対してバッファ状態報告（以降、ＢＳＲ：Buffer Status Report）を送信するためのグラントを割り当てる。ＢＳＲは、送信待ち状態のデータとしてバッファに蓄積されているデータ量を示すデータである。また、ここでのグラントとは、前述の通信リソースに相当するものであって、データを送信する際に利用する周波数やタイミング、変調方式等を指す。

なお、ＵＥ１０によるＢＳＲやデータの送信には、ＰＵＳＣＨが利用される。つまり、ＳＲの受信に基づいて無線基地局２０が割り当てるグラントは、ＰＵＳＣＨのグラントである。

そして、無線基地局２０は、ＵＥ１０に対して当該割り当てたグラントを、ＰＤＣＣＨで通知する。以降では便宜上、無線基地局２０が送信する、アップリンク通信のためのグラントを示す通信パケットを、グラント指定データと記載する。図２中の時刻Ｔｂは、無線基地局２０がグラント指定データを送信するタイミングを表している。

ＵＥ１０は、無線基地局２０から送信されたグラント指定データを受信すると、無線基地局２０から指定されたグラントに対応するＰＵＳＣＨを使用してＢＳＲを送信する。図２中の時刻Ｔｃは、ＵＥ１０がＢＳＲを送信するタイミングを表している。

なお、ＢＳＲ送信用に割り当てられたグラントが、ＢＳＲの送信に必要な通信リソースに対して余裕がある場合、ＵＥ１０は、当該余剰分の通信リソースを用いてバッファに格納されているデータの一部又は全部を送信することができる。

無線基地局２０は、ＵＥ１０からのＢＳＲを受信すると、当該ＢＳＲに示されているデータ量に応じたグラントを再度割り当てて、当該割り当てたグラントを通知するグラント通知データを送信する。図中の時刻Ｔｄは、ＢＳＲに対する応答としてのグラント通知データを送信するタイミングを表している。そして、ＵＥ１０は、時刻Ｔｅ以降において、指示されたグラントを用いてバッファに滞留しているデータを順次送信していく。

なお、ＬＴＥではアップリンク通信に複数の論理チャネルが用いられる。複数の論理チャネルは、複数の論理チャネルグループ（以降、ＬＣＧ：Logical Channel Group）に分類されている。ここでは一例として、論理チャネルは、ＬＣＧ１、ＬＣＧ２、ＬＣＧ３、ＬＣＧ４の４つのＬＣＧに分類されているものとする。どの論理チャネルがどの論理チャネルグループに属するかに関しては適宜設計さればよい。

各ＬＣＧにはＬＣＧ番号が割り当てられており、当該ＬＣＧ番号によって種々のＬＣＧは互いに区別される。各論理チャネルには、固有の論理チャネル識別子（以降、ＬＣＩＤ：Logical Channel ID）が割り当てられており、当該ＬＣＩＤによって当該論理チャネルが何れのＬＣＧに属するかも識別される。つまり、各ＬＣＩＤは４つのＬＣＧ番号の何れかと対応付けられている。

また、データのヘッダには、データ送信に用いる論理チャネルのＬＣＩＤが記述されている。データが何れの論理チャネルを用いるかは、当該データを生成したアプリに応じて決定される。どのアプリのデータ送信にどの論理チャネルを使用するかに関しても適宜設計さればよい。種々のアプリのそれぞれに対して、そのアプリが使用すべき論理チャネルのＬＣＩＤが割り当てられている。

ところで、ＵＥ１０は、時刻ＴｃでのＢＳＲの送信をトリガとして、再送ＢＳＲタイマ（いわゆるretx-BSRタイマ）を起動する。この再送ＢＳＲタイマは、ＢＳＲが欠損したと見なして、ＢＳＲを再度送信する必要があると判定するためのタイマである。再送ＢＳＲタイマが計測する時間の設定値（以降、タイマ設定値Ｔｒｅｔｘ）として採用すべき値は、無線基地局２０から配信される。便宜上、無線基地局２０から配信される、再送ＢＳＲタイマの設定値として採用すべき値のことを、配信値Ｔｄｌｖと称する。

上述した図２は、再送ＢＳＲタイマが満了となるまでに、グラント通知データを受信できた場合のＵＥ１０の作動を表していた。他の事例として、再送ＢＳＲタイマが満了となるまでに、グラント通知データを受信できなかった場合のＵＥ１０の作動を図３に示す。

ＵＥ１０は、再送ＢＳＲタイマが満了となるまでにグラント通知データを受信できなかった場合、データを送信するためのグラントを取得するための一連の処理を、ＳＲの送信からやり直す。つまり、時刻ＴｘにてＳＲを再度送信し、グラント指示データを受信することができれば、時刻Ｔｃの時と同様に、時刻ＴｚにてＢＳＲを再送する。なお、図３中の時刻Ｔｙは、無線基地局２０が、ＵＥ１０が再送したＳＲに対するグラント指示データを送信したタイミングを表している。

＜ＵＥ１０の構成について＞
次に本実施形態にかかるＵＥ１０の構成及び作動について説明する。本実施形態に係るＵＥ１０は、図４に示すように、アンテナ１１、トランシーバ１２、アプリケーション部１３、及び通信制御部１４を備える。

アンテナ１１は、無線基地局２０と通信するためのアンテナである。アンテナ１１は、ＬＴＥで用いられる周波数帯の電波を送受信可能に構成されている。アンテナ１１は、トランシーバ１２と電気的に接続されている。

トランシーバ１２は、ＬＴＥの無線通信プロトコルにおける物理レイヤを担当する通信モジュールである。トランシーバ１２は、アンテナ１１にて受信した受信信号に対して、アナログデジタル変換処理や復調処理といった所定の処理を施すことでデジタル値によって表現された情報系列（つまりデジタルデータ）に変換する。そして、その受信信号に対応するデータを、通信制御部１４に提供する。

また、トランシーバ１２は、通信制御部１４から入力されたデータに対して、符号化や、変調、デジタルアナログ変換等の処理を施すことで、入力されたデータに対応する搬送波信号を生成する。そして、生成した搬送波信号をアンテナ１１に出力し、電波して放射させる。

アプリケーション部１３は、ＣＰＵ、ＲＡＭ、フラッシュメモリ、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備えている。フラッシュメモリには、種々のアプリがインストールされている。アプリケーション部１３は、当該インストールされているアプリを実行して、アップリンク送信用のデータを生成する。そして、生成したデータを通信制御部１４に提供する。アプリケーション部１３にインストールされているアプリの内容は適宜設計されれば良い。

便宜上、アプリケーション部１３には、アプリＷ、アプリＸ、アプリＹ、及びアプリＺの、４種類のアプリがインストールされているものとする。また、アプリＸは、他のアプリＷ、アプリＹ、及びアプリＺよりも相対的に高いリアルタイム性（換言すれば、より低遅延な通信）を要求するアプリとする。例えばアプリＸは、ドライバの運転操作を支援するアプリであって、所定のサーバと逐次無線通信することで、ドライバの運転操作の手助けとなるリアルタイムな情報（以降、運転支援情報）を取得する。運転支援情報は、例えば、自車両周辺に存在する他車両の現在位置や車速、進行方向などを示す情報などとすればよい。

通信制御部１４は、通常のコンピュータを主体として構成されており、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備えている。ＲＯＭには、通常のコンピュータを、本実施形態におけるＵＥ１０として機能させるためのプログラム（以降、通信制御プログラム）等が格納されている。

なお、上述の通信制御プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよい。ＣＰＵが通信制御プログラムを実行することは、通信制御プログラムに対応する方法が実行されることに相当する。

通信制御部１４は、機能ブロックとして、送信処理部Ｆ１、受信データ取得部Ｆ２、ＢＳＲ再送処理部Ｆ３、判定部Ｆ４、設定値変更部Ｆ５、バッファＭ１、配信値記憶部Ｍ２、及び代理値記憶部Ｍ３を備える。

送信処理部Ｆ１、受信データ取得部Ｆ２、ＢＳＲ再送処理部Ｆ３、判定部Ｆ４、及び設定値変更部Ｆ５のそれぞれは、ＣＰＵが当該通信制御プログラムを実行することによって（換言すればソフトウェアとして）実現されればよい。なお、他の態様として、送信処理部Ｆ１、受信データ取得部Ｆ２、ＢＳＲ再送処理部Ｆ３、判定部Ｆ４、及び設定値変更部Ｆ５のそれぞれは、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組み合わせ等のいずれかによって実現されてもよい。ハードウェアによる実現には、１つ又は複数のＩＣを用いて実現される態様も含む。

バッファＭ１、配信値記憶部Ｍ２、及び代理値記憶部Ｍ３のそれぞれは、ＲＡＭ等の書き換え可能な記憶媒体を用いて実現されればよい。なお、代理値記憶部Ｍ３として用いられる記憶領域は、配信値記憶部Ｍ２として用いられる記憶領域とは異なる記憶領域である。

配信値記憶部Ｍ２は、無線基地局２０から配信される配信値Ｔｄｌｖを記憶する。また、代理値記憶部Ｍ３は、配信値Ｔｄｌｖの代わりにタイマ設定値Ｔｒｅｔｘとして採用する値である代理値Ｔｒｅｐを記憶している。代理値Ｔｒｅｐは、アプリケーション部１３にインストールされているアプリが要求する無線通信のリアルタイム性（換言すれば低遅延性）を提供するための値となっている。

ここでは一例として代理値Ｔｒｅｐは、アプリＸが要求するリアルタイム性を提供するために、適宜設計された値に設定されている。代理値Ｔｒｅｐの具体的な値は、ＵＥ１０のユーザや、ＵＥ１０の設計者、アプリＸの開発者等によって適宜決定されれば良い。アプリ毎の代理値Ｔｒｅｐの一例を図６に示す。

図６に示すように、例えばアプリＸのような運転支援を実施するアプリや、予防安全系のアプリなどといった、より安全な交通社会の実現に寄与するアプリに対する代理値Ｔｒｅｐは、相対的に小さい値（例えば１０）に設定することが好ましい。また、自動販売機や工作機器等の稼働状況を監視するアプリに対する代理値Ｔｒｅｐは、相対的に大きい値（例えば６４０）に設定する。ウェブブラウジングなどといった、安全性の向上というよりかはむしろ当該ＵＥ１０のユーザのみの快適性や利便性を提供するアプリにおける代理値Ｔｒｅｐは、中間的な値（例えば３２０）に設定することが好ましい。

なお、本実施形態では一例として代理値Ｔｒｅｐは、アプリＸが要求するリアルタイム性に応じた値に設定されているものとするが、これに限らない。代理値Ｔｒｅｐは、ＵＥ１０にインストールされている特定のアプリが要求するリアルタイム性に応じた値となっていることが好ましい。便宜上、本実施形態における代理値Ｔｒｅｐは、無線基地局２０から配信される配信値Ｔｄｌｖの想定値（例えば平均値や中央値等）よりも小さい値とする。なお、代理値Ｔｒｅｐは、配信値Ｔｄｌｖが取りうる値の範囲の最小値としてもよい。

バッファＭ１は、種々のアプリが生成したデータを一時的に格納する記憶領域である。バッファＭ１に格納されるデータは、そのデータに対応するＬＣＧによって区別されて管理される。データに対応するＬＣＧとは、当該データに割り当てられているＬＣＩＤの論理チャネルが属するＬＣＧである。

換言すれば、バッファＭ１は、仮想的にＬＣＧで分割されて運用される。図５は、ＬＣＧ毎のバッファを概念的に表した図である。図５に示すように、バッファＭ１は、ＬＣＧ１用のバッファＭ１１、ＬＣＧ２用のバッファＭ１２、ＬＣＧ３用のバッファＭ１３、及びＬＣＧ４用のバッファＭ１４を備える。各ＬＣＧ用のバッファを個別バッファとも記載する。

なお、前述の通り、各ＬＣＩＤとＬＣＧとの対応関係は予め設定されている。したがって、アプリ等によって生成されたデータが、どの個別バッファに収容されるかは定まっている。ここでは一例として、アプリＸが生成するデータは、ＬＣＧ４用バッファＭ１４に収容されるように、アプリＸに対してＬＣＩＤが割り当てられているものとする。換言すれば、ＬＣＧ４用バッファＭ１４にデータが存在するということは、アプリＸによって生成されたデータがバッファＭ１に存在している可能性があることを示唆している。

送信処理部Ｆ１は、トランシーバ１２と協働し、所定のデータに対応する通信パケットを所定の通信リソースを用いて無線基地局２０に送信する。具体的には、ＳＲや、ＢＳＲ、データに相当するベースバンド信号をトランシーバ１２に出力し、アンテナ１１から送信させる。

送信処理部Ｆ１がＳＲを送信する場合とは、バッファＭ１が空の状態においてデータがバッファＭ１に到着した場合などである。なお、前提として送信処理部Ｆ１は、バッファＭ１に滞留しているデータの量を監視する機能を備えているものとする。

また、送信処理部Ｆ１は、ＢＳＲを送信するべき条件が充足された場合に、ＢＳＲを送信する。ＢＳＲは、ＬＣＧ毎のデータの滞留量を無線基地局２０が認識できるデータフォーマットとなっている。なお、送信処理部Ｆ１がＢＳＲを送信する場合とは、ＳＲに対する応答としてのグラント指示データを受信した場合に限らない。

また、Periodic BSRタイマが満了した場合や、再送ＢＳＲタイマが満了した場合などにも送信する。なお、Periodic BSRタイマは、ＢＳＲを定期的に送信するためのタイマである。Periodic BSRタイマは、送信処理部Ｆ１がＢＳＲを送信したことをトリガとして起動し、当該ＢＳＲを送信してから経過時間を計測し始める。そして、計測している経過時間が所定の周期送信時間となった場合に満了となる。Periodic BSRタイマは送信処理部Ｆ１が備えていても良いし、後述するＢＳＲ再送処理部Ｆ３が備えていてもよい。

受信データ取得部Ｆ２は、トランシーバ１２が受信したデータを取得する。受信データ取得部Ｆ２は、配信値Ｔｄｌｖを含むデータを取得した場合には、当該配信値Ｔｄｌｖを配信値記憶部Ｍ２に保存する。したがって、受信データ取得部Ｆ２が請求項に記載の配信値格納処理部に相当する。

ＢＳＲ再送処理部Ｆ３は、再送ＢＳＲタイマＦ３１を備えており、送信処理部Ｆ１にＢＳＲを再送させる処理を行う。再送ＢＳＲタイマＦ３１は、送信処理部Ｆ１がＢＳＲをトランシーバ１２に出力したことをトリガとして起動し、当該ＢＳＲを送信してからの経過時間を計測し始める。そして、計測している経過時間がタイマ設定値Ｔｒｅｔｘに対応する時間となった場合に、再送ＢＳＲタイマＦ３１は満了となる。

再送ＢＳＲタイマＦ３１が満了となると、ＢＳＲ再送処理部Ｆ３は、その時点においてＢＳＲを送信するためのグラントが割り当てられていない場合には、送信処理部Ｆ１はＳＲの送信から実施する。

なお、再送ＢＳＲタイマＦ３１をカウントダウン方式のタイマとする場合には、タイマ設定値Ｔｒｅｔｘは初期値として機能する。カウントダウン方式は、初期値としてのタイマ設定値Ｔｒｅｔｘから経過時間を減算した値をカウント値として保持及び逐次更新していき、カウント値が０となった場合に満了と判定する方式である。

また、再送ＢＳＲタイマＦ３１をカウントアップ方式のタイマとする場合には、タイマ設定値Ｔｒｅｔｘは、その上限値として機能する。カウントアップ方式は、ＢＳＲを送信してからの経過時間をカウント値として保持及び逐次更新していき、カウント値がタイマ設定値Ｔｒｅｔｘとなった場合に満了と判定する方式である。

再送ＢＳＲタイマＦ３１をカウントダウン方式のタイマとする場合には、カウント値そのものが、当該タイマが満了となるまでの残り時間Ｔｒｓｔに相当する。また、再送ＢＳＲタイマＦ３１をカウントアップ方式のタイマとする場合には、タイマ設定値から現在のカウント値を減算した値が、タイマ満了となるまでの残り時間Ｔｒｓｔに相当する。再送ＢＳＲタイマＦ３１をカウントアップ方式とするか、カウントダウン方式とするかは設計事項である。ここでは一例としてカウントダウン方式を採用しているものとする。

判定部Ｆ４は、バッファＭ１の状態に基づいて、タイマ設定値Ｔｒｅｔｘとして代理値Ｔｒｅｐを適用する必要があるか否かを判定する。本実施形態では一例として、アプリＸに対応するＬＣＧ（つまりＬＣＧ４）用のバッファＭ１４に、データが存在する場合に、タイマ設定値Ｔｒｅｔｘとして代理値Ｔｒｅｐを適用する必要があると判定する。

タイマ設定値Ｔｒｅｔｘとして代理値Ｔｒｅｐを適用する条件が請求項に記載の代理値適用条件に相当する。つまり、本実施形態では、ＬＣＧ４にデータが格納されている場合に、代理値適用条件が充足されていると判定する。なお、前提として判定部Ｆ４もまた、送信処理部Ｆ１と同様に、バッファＭ１にアクセスし、バッファＭ１に滞留しているデータの量を監視する機能を備えているものとする。

設定値変更部Ｆ５は、判定部Ｆ４の判定結果に基づいて、タイマ設定値Ｔｒｅｔｘを変更する。つまり、判定部Ｆ４によってタイマ設定値Ｔｒｅｔｘとして代理値Ｔｒｅｐを適用する必要があると判定されている場合には、タイマ設定値Ｔｒｅｔｘを代理値Ｔｒｅｐに設定する。また、判定部Ｆ４によってタイマ設定値Ｔｒｅｔｘとして代理値Ｔｒｅｐを適用する必要があると判定されていない場合には、タイマ設定値Ｔｒｅｔｘを配信値Ｔｄｌｖに設定する。この設定値変更部Ｆ５の作動の詳細については別途後述する。

＜設定値変更関連処理＞
次に、図７に示すフローチャートを用いて、通信制御部１４が実施する設定値変更関連処理について説明する。設定値変更関連処理は、タイマ設定値Ｔｒｅｔｘを、バッファＭ１の状態に基づいて動的に変更する処理である。この図７に示すフローチャートは、例えば、ＵＥ１０が動作している間逐次（例えば１０ミリ秒毎に）実施されればよい。

まずステップＳ１０では、タイマ設定値Ｔｒｅｔｘを変更するための所定のトリガとするイベントが発生したか否かを判定する。トリガとするイベントは適宜設計されれば良い。例えば、送信処理部Ｆ１によるＳＲの送信や、バッファＭ１内のデータ量の変化を、トリガとすればよい。

所定のトリガとするイベントが発生している場合には、ステップＳ１０が肯定判定されてステップＳ２０に移る。一方、トリガとするイベントが発生していない場合には、ステップＳ１０が否定判定されて本フローを終了する。

ステップＳ２０では、代理値適用バッファが空となっているか否かを判定する。ここでの代理値適用バッファとは、アプリＸが属しているＬＣＧ（つまりＬＣＧ４）用のバッファＭ１４である。代理値適用バッファとしてのＬＣＧ４用バッファＭ１４が空となっている場合には、ステップＳ２０が肯定判定されてステップＳ３０に移る。一方、ＬＣＧ４用バッファＭ１４が空となっていない場合には、ステップＳ２０が否定判定されてステップＳ４０に移る。なお、このステップＳ２０の判定処理は、特定のアプリ（ここではアプリＸ）が属するＬＣＧのデータが、バッファＭ１に格納されているか否かを判定する処理に相当する。

ステップＳ３０では、タイマ設定値Ｔｒｅｔｘを配信値Ｔｄｌｖに設定して本フローを終了する。ステップＳ４０では、代理値適用バッファにデータが到着しているか否かを判定する。代理値適用バッファにデータが到着している場合にはステップＳ４０が肯定判定されてステップＳ５０に移る。一方、代理値適用バッファにデータが到着している場合にはステップＳ４０が否定判定されて本フローを終了する。

ステップＳ５０では設定値変更部Ｆ５が設定値変更処理を実施して本フローを終了する。この設定値変更処理については、図７に示すフローチャートを用いて説明する。図８に示すフローチャートは、図７のステップＳ５０に移った時に開始される。

まず、ステップＳ５１では再送ＢＳＲタイマＦ３１が起動中であるか否かを判定する。再送ＢＳＲタイマＦ３１が起動中である場合にはステップＳ５１が肯定判定されてステップＳ５３に移る。一方、再送ＢＳＲタイマＦ３１が起動中ではない場合にはステップＳ５１が否定判定されてステップＳ５２に移る。

ステップＳ５２では、タイマ設定値Ｔｒｅｔｘを配信値Ｔｄｌｖに設定して本フローを終了する。なお、本フローを終了すると呼び出し元の設定値変更関連処理も終了する。

ステップＳ５３では、再送ＢＳＲタイマＦ３１が満了となるまでの残り時間Ｔｒｓｔ（つまり現在のカウント値）が、代理値Ｔｒｅｐよりも小さいか否かを判定する。残り時間Ｔｒｓｔが代理値Ｔｒｅｐよりも小さい場合には、ステップＳ５３が肯定判定されて本フローを終了する。一方、残り時間Ｔｒｓｔが代理値Ｔｒｅｐ以上である場合には、ステップＳ５３が否定判定されてステップＳ５４に移る。

ステップＳ５４では、タイマ設定値Ｔｒｅｔｘを代理値Ｔｒｅｐに設定する。そして、再送ＢＳＲタイマＦ３１をリスタート（換言すれば再起動）させて本フローを終了する。ここでのリスタートとは、ＢＳＲを送信してからの経過時間をいったん０に戻して再び計測を開始することである。具体的には、再送ＢＳＲタイマＦ３１のカウント方式としてカウントダウン方式を採用している本実施形態においては、カウント値を代理値Ｔｒｅｐに設定してカウントダウンを再開させることに相当する。なお、再送ＢＳＲタイマＦ３１がカウントアップ方式を採用している場合には、単純にカウント値を０に戻して計測を再開することに相当する。

＜本実施形態のまとめ＞
以上の構成の作動について、図９及び図１０を用いてまとめる。まず、代理値適用バッファにデータが格納されていない場合には、タイマ設定値Ｔｒｅｔｘ＝配信値Ｔｄｌｖとする。そのため、図９において一点鎖線で示すように、再送ＢＳＲタイマＦ３１が満了となるまでに要する時間は、配信値Ｔｄｌｖに対応する時間となる。

一方、代理値適用バッファにデータが格納されている場合には、タイマ設定値Ｔｒｅｔｘ＝代理値Ｔｒｅｐとする。したがって、代理値適用バッファにデータが格納されている場合に起動した再送ＢＳＲタイマＦ３１が満了となるまでに要する時間は、図９の二点鎖線で示すように、代理値Ｔｒｅｐに対応する時間となる。

また、代理値適用バッファにデータが格納されていない状態において再送ＢＳＲタイマＦ３１が起動した場合であっても、代理値適用バッファにデータが到着した場合には、現在のカウント値と代理値Ｔｒｅｐのうちの小さい方を、次の瞬間からのカウント値として採用する。

具体的には、カウント値がまだ代理値Ｔｒｅｐよりも大きい状態において代理値適用バッファにデータが到着した場合には（ステップＳ５３ ＹＥＳ）、カウント値＝代理値Ｔｒｅｐとして次の瞬間からのカウントをリスタートさせる（ステップＳ５４）。これにより、図１０に示すように、再送ＢＳＲタイマＦ３１が満了となるまでに要する時間は配信値Ｔｄｌｖよりも短縮することができる。

以上の構成によれば、代理値適用バッファにデータが存在していない場合には、配信値Ｔｄｌｖを用いて従来通りに作動する。一方、代理値適用バッファにデータが存在する場合には、相対的に小さい代理値Ｔｒｅｐをタイマ設定値Ｔｒｅｔｘとして用いてＢＳＲの再送を実行する。

つまり、代理値適用バッファにデータが存在する場合のみ代理値Ｔｒｅｐを用いてＢＳＲの再送を実行するため、ＳＲやＢＳＲの過剰な再送を抑制することができる。また、代理値適用バッファにデータが存在する場合には、代理値Ｔｒｅｐを用いてＢＳＲの再送を実行するため、再送ＢＳＲタイマＦ３１が満了となるまでの待機時間を短縮することができる。これにより、通信制御部１４は、代理値適用バッファを利用するアプリＸに対して、当該アプリＸが要求するリアルタイム性を提供することができる。

以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。

なお、前述の実施形態で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略する。また、構成の一部のみに言及している場合、他の部分については先に説明した実施形態の構成を適用することができる。

［変形例１］
以上では、判定部Ｆ４が、特定のＬＣＧに属するデータがバッファＭ１に格納されている場合に、タイマ設定値Ｔｒｅｔｘとして代理値Ｔｒｅｐを適用する必要があると判定する態様を例示したがこれに限らない。

例えば、判定部Ｆ４は、特定のアプリ（例えばアプリＸ）に対応するＬＣＩＤが割り当てられているデータがバッファＭ１に格納されている場合に、タイマ設定値Ｔｒｅｔｘとして代理値Ｔｒｅｐを適用する必要があると判定してもよい。換言すれば、特定のＬＣＩＤが割り当てられているデータがバッファＭ１に格納されている場合に、代理値適用条件が充足されていると判定してもよい（これを変形例１とする）。

この変形例１は、例えば次のように実現すれば良い。まず、図７のステップＳ２０での判定処理の内容を、特定のＬＣＩＤが割り当てられたデータが格納されているか否かを判定する処理に置き換える。また、ステップＳ４０での判定処理の内容を、特定のＬＣＩＤが割り当てられたデータが到着したか否かを判定する処理に置き換えればよい。なお、データに割り当てられているＬＣＩＤは、ヘッダ等の識別子を参照することで特定できる。

このような態様によっても上述した実施形態と同様の効果を奏することができる。

［変形例２］
上述した実施形態や変形例１では、ＬＣＧやＬＣＩＤを用いて間接的に、特定のアプリ（ここではアプリＸ）が生成したデータが、バッファＭ１に格納されているか否かを推定する態様を例示したが、これに限らない。

仮に、バッファＭ１に格納されているデータの特定のフィールド（例えばヘッダ等）を参照することで、当該データの生成元を特定できる構成となっている場合には、判定部Ｆ４は特定のアプリが生成したデータがバッファＭ１に格納されている場合に、代理値適用条件が充足されていると判定する態様としてもよい。ここでのフィールドは、特定の位置に設けられたビット列を指す。

［変形例３］
以上では、判定部Ｆ４が、特定のＬＣＧやＬＣＩＤに対応するデータがバッファＭ１に格納されている場合に、タイマ設定値Ｔｒｅｔｘとして代理値Ｔｒｅｐを適用する必要があると判定する態様を例示したがこれに限らない。例えば、バッファＭ１にデータが格納されている場合に、タイマ設定値Ｔｒｅｔｘとして代理値Ｔｒｅｐを適用する必要があると判定してもよい（これを変形例３とする）。

この変形例３の作動について図１１に示すフローチャートを用いて説明する。図１１に示すフローチャートは、変形例３における通信制御部１４が実施する設定値変更関連処理の流れを表したものである。つまり、図１１は、図７に相当するフローチャートである。

まず、ステップＳ１１０では、タイマ設定値Ｔｒｅｔｘを変更するための所定のトリガとするイベントが発生したか否かを判定する。トリガとするイベントは、前述の通り、適宜設計されれば良い。所定のトリガとするイベントが発生している場合には、ステップＳ１１０が肯定判定されてステップＳ１２０に移る。一方、トリガとするイベントが発生していない場合には、ステップＳ１１０が否定判定されて本フローを終了する。

ステップＳ１２０では、バッファＭ１が空となっているか否かを判定する。バッファＭ１が空となっている場合には、ステップＳ１２０が肯定判定されてステップＳ１３０に移る。一方、バッファＭ１が空となっていない場合には、ステップＳ１２０が否定判定されてステップＳ１４０に移る。

ステップＳ１３０では、タイマ設定値Ｔｒｅｔｘを配信値Ｔｄｌｖに設定して本フローを終了する。ステップＳ１４０では、設定値変更部Ｆ５が設定値変更処理を実施して本フローを終了する。このステップＳ１４０の設定値変更処理は、図７に示すフローチャートを用いて説明した通りである。

以上で述べた変形例３は、ＵＥ１０にインストールされているアプリが１種類である場合に、特に有用となる。インストールされているアプリが１種類である場合、バッファＭ１に到着するデータは、主として当該アプリが生成したものとなる。また、ＵＥ１０にインストールされているアプリが１種類である場合、当該ＵＥ１０に要求される無線通信のリアルタイム性は、当該アプリが要求するリアルタイム性そのものである。

したがって、ＵＥ１０にインストールされているアプリが１種類である場合には当該変形例３を適用することで、ＵＥ１０が提供する無線通信機能に対してアプリが要求するリアルタイム性に適した値をタイマ設定値Ｔｒｅｔｘに設定することができる。

もちろん、この変形例３は、ＵＥ１０に複数種類のアプリがインストールされている場合にも適用できるものである。ただし、その場合にも、インストールされている種々のアプリが要求するリアルタイム性が同じ程度となっていることが好ましい。換言すれば、複数存在するアプリの要求遅延値が共通している場合にも変形例３は有用となる。

［変形例４］
上述した実施形態では、タイマ設定値Ｔｒｅｔｘの代理値Ｔｒｅｐを、配信値よりも小さい値とする態様を例示したが、これに限らない。代理値Ｔｒｅｐは、ＵＥ１０が無線通信を実施する主たる目的に対応するアプリ（以降、メインアプリ）が要求するリアルタイム性に応じた値となっていればよい。

たとえば、ＵＥ１０のメインアプリが、リアルタイム性を要求しない（換言すれば静的な）アプリである場合には、代理値Ｔｒｅｐは、再送ＢＳＲタイマＦ３１が満了となるまでに要する時間を、無線基地局２０が指定する時間（つまり配信値Ｔｄｌｖ）よりも長くするような値であってもよい。例えば代理値Ｔｒｅｐは、配信値Ｔｄｌｖが取りうる範囲の最大値や、それよりも長い値とすることができる。

なお、リアルタイム性を要求しないアプリとは、換言すれば、そこまで頻繁に無線通信を実施する必要性がないアプリである。例えば、重機などの工作機器の稼働状態や、自動販売機の在庫状況を遠隔監視するためのアプリ等が該当しうる。それらのアプリにおいては、監視対象とする機器等の稼動状態を示すデータを、数分や数十分といった間隔で所定のサーバにアップロードできればよい。そのため、再送ＢＳＲタイマＦ３１が満了するまでの待機時間に伴う通信遅延は、アプリに応じたサービスを提供する上で問題となりにくい。

ところで、この変形例４の思想によれば、ＵＥ１０の使われ方に応じた代理値Ｔｒｅｐを適用することができる。その一例について図１２を用いて説明する。図１２に示すＵＥ１０Ａは、車両で用いられるＵＥ１０であって、メインアプリとして相対的にリアルタイム性を要求するアプリがインストールされている。ＵＥ１０Ｂは、自動販売機で用いられているＵＥ１０であって、相対的静的なアプリ（例えば在庫管理用のアプリ）のみがインストールされている。

このような態様において、仮にＵＥ１０Ａにおける代理値Ｔｒｅｐを相対的に小さい値に設定しておけば、ＵＥ１０ＡにおけるＢＳＲの再送遅延を低減することができ、リアルタイム性を高める事ができる。また、仮にＵＥ１０Ｂにおける代理値Ｔｒｅｐを相対的に大きい値に設定し、かつ、その制御態様を変形例３で述べた態様としておけば、ＢＳＲの再送を抑制することができる。なお、ＵＥ１０Ａにおける設定値変更関連処理の態様は、実施形態、変形例１、変形例３の何れの態様でもよい。

また、代理値Ｔｒｅｐの値は、例えば図１３に示すように、ＵＥ１０の用途に応じた値に設定されても良い。例えば、自動車で用いられるＵＥ１０の代理値Ｔｒｅｐは、相対的に小さい値（例えば１０）に設定し、自動販売機等の代理値Ｔｒｅｐは、相対的に大きい値（例えば６４０）に設定する。また、様々なアプリがインストールされることが想定される携帯電話機やタブレット端末の代理値Ｔｒｅｐは、中間的な値（例えば３２０）に設定しておけばよい。なお、このときの制御態様は、変形例３で述べた態様を採用すればよい。このような態様によれば、ＵＥ１０の用途に応じた時間をタイマ設定値Ｔｒｅｔｘとして適用させることができる。

［変形例５］
以上では、特定のアプリに対応する代理値Ｔｒｅｐを、ＬＴＥに準拠した無線通信を実施する上で利用される種々の時間パラメータ（以降、既存パラメータ）とは独立して、予め登録しておく態様を例示したが、これに限らない。既存パラメータのうち、配信値以外の所定の時間パラメータを、代理値Ｔｒｅｐとして流用する態様としてもよい。

なお、ここでの時間パラメータとは、時間の概念に属するパラメータである。例えば、種々のタイマの設定値が、時間パラメータに属する。例えばPeriodic BSRタイマの設定値などといった、再送ＢＳＲタイマ以外のタイマの設定値等である。この変形例５を採用する場合には、当該代理値として採用する既存パラメータを記憶している記憶領域が、請求項に記載の代理値記憶部に相当する。

［変形例６］
以上では、無線通信システム１００を、ＬＴＥに準拠した無線通信を提供するシステムとする態様を例示したがこれに限らない。無線通信システム１００は、ＨＳＰＡなどといった、ＬＴＥ以外の通信規格に準拠した無線通信を提供するシステムであってもよい。

１００ 無線通信システム、１０・１０Ａ・１０Ｂ ＵＥ（通信装置）、２０ 無線基地局、１１ アンテナ、１２ トランシーバ、１３ アプリケーション部、１４ 通信制御部、Ｆ１ 送信処理部、Ｆ２ 受信データ取得部（配信値格納処理部）、Ｆ３ ＢＳＲ再送処理部（再送処理部）、Ｆ３１ 再送ＢＳＲタイマ、Ｆ４ 判定部、Ｆ５ 設定値変更部、Ｍ１ バッファ、Ｍ２ 配信値記憶部、Ｍ３ 代理値記憶部

Claims (8)

1. バッファに滞留しているデータの量を示すバッファ状態報告を、無線基地局に送信する送信処理部（Ｆ１）と、前記バッファ状態報告を送信してからの経過時間が、タイマ設定値として設定されている時間となった場合に前記バッファ状態報告を再送するための処理を実行する再送処理部（Ｆ３）と、を備える通信装置と、
   前記通信装置から送信されてくる前記バッファ状態報告に示されているデータ量に応じて、当該通信装置に対して通信リソースを割り当てる前記無線基地局と、を備える無線通信システムで用いられる前記通信装置であって、
   前記無線基地局から配信される、前記タイマ設定値として採用すべき値である配信値を取得し、当該配信値を、所定の記憶媒体を用いて実現される配信値記憶部（Ｍ２）に格納する配信値格納処理部（Ｆ２）と、
   前記配信値の代わりに前記タイマ設定値として設定可能な値である代理値を予め記憶している代理値記憶部（Ｍ３）と、
   前記タイマ設定値として前記代理値を採用するための条件である代理値適用条件が充足されているか否かを判定する判定部（Ｆ４）と、
   前記判定部の判定結果に基づいて前記タイマ設定値を変更する設定値変更部（Ｆ５）と、を備え、
   前記判定部は、前記バッファにデータが存在しているか否かを前記代理値適用条件の１つとして判定するように構成されており、
   前記設定値変更部は、前記判定部によって前記バッファにデータが存在していると判定されている場合には、前記配信値を取得している場合であっても前記代理値を前記タイマ設定値に設定する一方、前記判定部によって前記バッファにデータが存在していないと判定されている場合には、前記配信値を前記タイマ設定値に設定するように構成されている通信装置。
2. 請求項１において、
   前記代理値は、当該通信装置が提供する無線通信機能を利用する特定のアプリケーションソフトウェアが要求する低遅延性を実現するための値に予め設定されていることを特徴とする通信装置。
3. 請求項２において、
   前記無線基地局との通信制御のために利用される時間パラメータのうち、前記配信値とは異なる前記時間パラメータを、前記代理値として採用することを特徴とする通信装置。
4. 請求項２又は３において、
   前記無線基地局へのデータ送信を制御するための複数の論理チャネル識別子が予め用意されており、
   前記アプリケーションソフトウェアには、所定の前記論理チャネル識別子が予め対応付
   けられており、
   前記バッファに格納されるデータには、当該データの生成元の前記アプリケーションソフトウェアに対応付けられている前記論理チャネル識別子を示すフィールドが設けられてあって、
   前記判定部は、前記アプリケーションソフトウェアに対応付けられている前記論理チャネル識別子のデータが前記バッファに存在している場合に、前記代理値適用条件が充足していると判定することを特徴とする通信装置。
5. 請求項２又は３において、
   前記無線基地局への送信されるデータは、前記無線基地局へのデータ送信を制御するために予め用意されている複数の論理チャネル識別子の何れかと対応付けられてあって、
   前記論理チャネル識別子は、予め設定されている複数の論理チャネルグループの何れかに属するように構成されており、
   前記アプリケーションソフトウェアには、所定の前記論理チャネル識別子が予め対応付けられており、
   前記バッファに格納されるデータには、当該データの生成元の前記アプリケーションソフトウェアに対応付けられている前記論理チャネル識別子を示すフィールドが設けられてあって、
   前記判定部は、前記アプリケーションソフトウェアに対応する前記論理チャネル識別子が属する前記論理チャネルグループのデータが、前記バッファに存在している場合に、前記代理値適用条件が充足していると判定することを特徴とする通信装置。
6. 請求項２又は３において、
   前記判定部は、前記アプリケーションソフトウェアが生成したデータが、前記バッファに存在している場合に、前記代理値適用条件が充足していると判定することを特徴とする通信装置。
7. 請求項１において、
   前記代理値は、当該通信装置の用途に応じた値に予め設定されており、
   前記判定部は、データが前記バッファに存在している場合に、前記代理値適用条件が充足していると判定することを特徴とする通信装置。
8. 請求項１から５の何れか１項において、
   前記バッファ状態報告を送信してからの経過時間を計測するとともに、前記経過時間が前記タイマ設定値となったか否かを判定する再送ＢＳＲタイマ（Ｆ３１）を備え、
   前記再送ＢＳＲタイマは、前記送信処理部が前記バッファ状態報告を送信したことをトリガとして起動するものであって、
   前記再送ＢＳＲタイマが起動中に前記判定部によって前記代理値適用条件が充足されたと判定され、かつ、前記経過時間が前記タイマ設定値となるまでの残り時間が前記代理値よりも大きい場合、前記設定値変更部は前記代理値を前記タイマ設定値に設定するとともに、前記再送ＢＳＲタイマは再起動することを特徴とする通信装置。
   

Images