(57)【要約】【課題】災害発生時において、発信処理のリトライによる輻輳の増長を抑制することが可能な通信端末装置およびその制御方法を提供する。【解決手段】通信端末装置１０は、基地局との間で無線通信を行なう無線通信部３０，４０と、無線通信部３０，４０を用いた通信を制御する制御部５０とを備える。制御部５０は、発信処理において無線通信網への接続が失敗した場合に、発信処理をリトライするリトライ実行部５８と、リトライ実行部５８によるリトライを許容する最大リトライ回数を設定するリトライ回数設定部５２とを含む。リトライ回数設定部５２は、基地局が緊急時に配信する緊急速報を無線通信部が受信した場合には、通常時よりも最大リトライ回数を低減する。【選択図】図３
2016086268.tif 000002
【特許請求の範囲】
【請求項１】
基地局との間で無線通信を行なう無線通信部と、
前記無線通信部を用いた通信を制御する制御部とを備え、
前記制御部は、
発信処理において無線通信網への接続が失敗した場合に、前記発信処理をリトライするリトライ実行部と、
前記リトライ実行部によるリトライを許容する最大リトライ回数を設定するリトライ回数設定部とを含み、
前記リトライ回数設定部は、前記基地局が緊急時に配信する緊急速報を前記無線通信部が受信した場合には、通常時よりも前記最大リトライ回数を低減する、通信端末装置。
【請求項２】
前記リトライ回数設定部は、前記無線通信部が前記緊急速報を受信した時点からの経過時間が短いほど、前記最大リトライ回数を小さくする、請求項１に記載の通信端末装置。
【請求項３】
前記制御部は、前記リトライ実行部におけるリトライ間隔を設定するリトライ間隔設定部をさらに含み、
前記リトライ間隔設定部は、前記無線通信部が前記緊急速報を受信した場合には、通常時よりも前記リトライ間隔を長くする、請求項１または２に記載の通信端末装置。
【請求項４】
前記制御部は、前記リトライ実行部におけるリトライ回数が増えるに従って、前記無線通信部から送信される信号の送信電力を増加させるように構成された送信電力制御部をさらに含み、
前記送信電力制御部は、前記無線通信部が前記緊急速報を受信した場合には、リトライごとの送信電力の増加量を通常時よりも大きくする、請求項１から３のいずれか１項に記載の通信端末装置。
【請求項５】
前記リトライ実行部におけるリトライ回数が前記最大リトライ回数に達したときの発信処理において前記無線通信網への接続が失敗したときに、通信エラーをユーザに報知する報知部をさらに備える、請求項１から４のいずれか１項に記載の通信端末装置。
【請求項６】
ユーザに対して、前記リトライ回数設定部による前記最大リトライ回数の低減を許可するか否かの選択を促す通知を行なう通知部と、
ユーザによる前記最大リトライ回数の制限を許可するか否かの選択を受け付ける入力部とをさらに備える、請求項１から５のいずれか１項に記載の通信端末装置。
【請求項７】
前記リトライ回数設定部はさらに、予め指定された日時において、通常時よりも前記最大リトライ回数を低減する、請求項１から６のいずれか１項に記載の通信端末装置。
【請求項８】
基地局との間で無線通信が可能な通信端末装置の制御方法であって、
発信処理において無線通信網への接続が失敗した場合に、前記発信処理のリトライを実行するステップと、
前記リトライを実行するステップによる前記発信処理のリトライを許容する最大リトライ回数を設定するステップとを備え、
前記最大リトライ回数を設定するステップは、前記基地局が緊急時に配信する緊急速報を受信した場合には、通常時よりも前記最大リトライ回数を低減する、通信端末装置の制御方法。
【請求項９】
前記最大リトライ回数を設定するステップは、前記無線通信部が前記緊急速報を受信した時点からの経過時間が短いほど、前記最大リトライ回数を小さくする、請求項８に記載の通信端末装置の制御方法。
【請求項１０】
前記リトライを実行するステップにおけるリトライ間隔を設定するステップをさらに備え、
前記リトライ間隔を設定するステップは、前記緊急速報を受信した場合には、通常時よりも前記リトライ間隔を長くする、請求項８または９に記載の通信端末装置の制御方法。
【請求項１１】
前記リトライ実行部におけるリトライ回数が増えるに従って、前記基地局に送信される信号の送信電力を増加させるように送信電力を制御するステップをさらに備え、
前記送信電力を制御するステップは、前記緊急速報を受信した場合には、リトライごとの送信電力の増加量を通常時よりも大きくする、請求項８から１０のいずれか１項に記載の通信端末装置の制御方法。
【請求項１２】
前記リトライを実行するステップにおけるリトライ回数が前記最大リトライ回数に達したときの発信処理において前記無線通信網への接続が失敗したときに、通信エラーをユーザに報知するステップをさらに備える、請求項８から１１のいずれか１項に記載の通信端末装置の制御方法。
【請求項１３】
ユーザに対して、前記リトライ回数を設定するステップによる前記最大リトライ回数の低減を許可するか否かの選択を促す通知を行なうステップと、
ユーザによる前記最大リトライ回数の制限を許可するか否かの選択を受け付けるステップとをさらに備える、請求項８から１２のいずれか１項に記載の通信端末装置の制御方法。
【請求項１４】
前記リトライ回数を設定するステップはさらに、予め指定された日時において、通常時よりも前記最大リトライ回数を低減する、請求項８から１３のいずれか１項に記載の通信端末装置の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、通信端末装置およびその制御方法に関する。
【背景技術】
【０００２】
災害発生などによる通信の輻輳を回避するため、電気通信事業者は、特定の地域（災害発生時の場合は被災地域）内の設備に対して、適切な通信規制を行なうことにより、設備を保護するとともに重要通信を確保する。このような通信規制の一形態として、基地局が行なう、通信端末装置との基地局との間の無線区間における通信規制（発信規制）がある。
【０００３】
たとえば、非特許文献１には、特定の地域への通話で通信回線がすべて塞がると、その他の地域への通話に対しても妨げとなるため、通話が集中した地域への接続量を抑える発信規制の技術が記載されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】「ＣＤＭＡ方式自動車電話システム標準規格  Section 6.6.3.1.1.1  Access  Chanel  Request  and  Response  Attempts」、ＡＲＩＢ  ＳＴＤ−Ｔ５３、２００８年１２月１２日、社団法人電波産業会
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、基地局による発信規制は、電気通信事業者側の判断に基づいて発動されるため、輻輳時であっても発信規制が発動されない場合があり得る。あるいは、災害発生後、基地局に何らかの障害が生じたことに起因して、基地局が発動した発信規制が通信端末装置に通知されない場合も起こり得る。そのため、通信端末装置においては、発信規制が正常に作動しないため、発信処理において無線通信網への接続が失敗したことを受けて、発信処理の再試行（リトライ）が繰り返し実行される。その結果、輻輳が増長されてしまい、輻輳を早期に解消することが困難となる。
【０００６】
本発明は、このような問題を解決するためになされたものであって、その目的は、災害発生時において、発信処理のリトライによる輻輳の増長を抑制することが可能な通信端末装置およびその制御方法を提供することである。
【課題を解決するための手段】
【０００７】
この発明のある局面では、通信端末装置は、基地局との間で無線通信を行なう無線通信部と、無線通信部を用いた通信を制御する制御部とを備える。制御部は、発信処理において無線通信網への接続が失敗した場合に、発信処理をリトライするリトライ実行部と、リトライ実行部によるリトライを許容する最大リトライ回数を設定するリトライ回数設定部とを含む。リトライ回数設定部は、基地局が緊急時に配信する緊急速報を無線通信部が受信した場合には、通常時よりも最大リトライ回数を低減する。
【０００８】
この発明の他の局面では、基地局との間で無線通信が可能な通信端末装置の制御方法であって、発信処理において無線通信網への接続が失敗した場合に、発信処理のリトライを実行するステップと、リトライを実行するステップによる発信処理のリトライを許容する最大リトライ回数を設定するステップとを備える。最大リトライ回数を設定するステップは、基地局が緊急時に配信する緊急速報を受信した場合には、通常時よりも最大リトライ回数を低減する。
【発明の効果】
【０００９】
この発明の一態様によれば、災害発生時において、発信処理のリトライによる輻輳の増長を抑制することができる通信端末装置を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】この発明の実施の形態１に係る通信端末装置が適用される通信システムの構成を示す図である。
【図２】実施の形態１に係る通信端末装置のハードウェア構成の一例を示す図である。
【図３】実施の形態１に係る通信端末装置の制御構造を示すブロック図である。
【図４】通常時における発信リトライ動作を説明する図である。
【図５】緊急速報を受信した場合における最大リトライ回数の時間的な変化を示す図である。
【図６】緊急速報を受信した場合における発信リトライ動作を説明する図である。
【図７】緊急速報を受信した場合における発信リトライ動作を説明する図である。
【図８】緊急速報を受信した場合における発信リトライ動作を説明する図である。
【図９】緊急速報を受信した場合における発信リトライ動作を説明する図である。
【図１０】実施の形態１に係る通信端末装置における発信処理の流れを示すフローチャートである。
【図１１】実施の形態１の変形例に係る通信端末装置における発信処理の流れを示すフローチャートである。
【図１２】実施の形態２に係る通信端末装置の制御構造を示すブロック図である。
【図１３】実施の形態２に係るユーザインタフェイス画面の一例を示す図である。
【図１４】実施の形態２に係る通信端末装置における発信処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本発明の実施の形態について図面を参照して詳細に説明する。なお、以下図中の同一または相当部分には同一符号を付して、その説明は原則的に繰返さないものとする。
【００１２】
［実施の形態１］
図１は、この発明の実施の形態１に係る通信端末装置が適用される通信システムの構成を示す図である。通信端末装置の一実施の形態として、スマートフォンを想定するが、携帯電話、ＰＤＡ（Personal  Digital  Assistant）、タブレットＰＣ（Tablet  PC）などのような他の通信端末装置であってもよい。
【００１３】
図１を参照して、実施の形態１に係る通信システムは、通信端末装置１０と、基地局２０とにより構成されている。通信端末装置１０は、基地局２０の通信エリア２００内に存在しており、無線通信網を利用して基地局２０との無線通信が可能である。通信端末装置１０は、基地局２０を経由して他の通信端末装置１０と通信することができる。
【００１４】
ここで、災害などで過度の通信の輻輳を回避するため、電気通信事業者は、特定の地域（災害発生時の場合は被災地域）内の設備に対して、適切な通信規制を行なうことにより、設備を保護するとともに重要通信を確保する。通信規制には、システムダウンを防止するため、自動規制と、トラフィック量に応じて人為的に行なう手動規制とがある。地震などの災害時には複数の基地局２０において発信が集中するとともに、安否確認の電話やメールが全国から被災地域に集中する。この場合、電気通信事業者は、輻輳状態に応じて下記の方法を組み合わせて通信規制を行なっている。
・基地局での発信規制（音声、パケット通信）
・交換設部での発着信規制（音声、パケット通信）
・電子メール新着通知などのＳＭＳ（Short  Message  Service）規制
輻輳は、通信端末装置１０と基地局２０との間の無線区間のみならず、インフラネットワーク部分で発生することもある。通信規制のうち、無線区間における通信規制は「発信規制」と呼ばれる。災害時以外にも、コンサートや花火大会などのイベント時においても、特定の狭いエリアに通信トラフィックが集中することがある。このような場合にも、基地局２０において発信規制を行なうことができる。
【００１５】
上記のように、基地局２０における発信規制は、通信の輻輳を回避するために、災害時やイベント時などに電気通信事業者側の判断に基づいて発動される。そのため、輻輳時であっても発信規制が発動されない場合があり得る。または、災害発生後、基地局２０に何らかの障害が生じたことに起因して、基地局２０が発動した発信規制が通信端末装置１０に通知されない場合も起こり得る。このような場合、通信端末装置１０のユーザは、自己の通信環境が輻輳状態にあること、または発信規制の対象であることを知ることができない。そのため、通信端末装置１０においては、発信規制が正常に作動せず、発信処理において無線通信網への接続が失敗したことを受けて、発信処理のリトライが繰り返し実行される。この結果、輻輳が増長されてしまい、輻輳を早期に解消することが困難となる。
【００１６】
そこで、実施の形態１に係る通信システムでは、通信端末装置１０側において、通信の輻輳が発生する可能性があると判断される場合には、基地局２０による発信規制の発動を待たずに、自主的に発信を抑制する。
【００１７】
図２は、実施の形態１に係る通信端末装置１０のハードウェア構成の一例を示す図である。図２を参照して、通信端末装置１０は、主たる構成要素として、ＣＰＵ（Central  Processing  Unit）１００と、メモリ１０２と、無線通信部１０４と、通信アンテナ１０６と、通信Ｉ／Ｆ（Interface）１０８と、電源回路１１０と、タッチスクリーン１１２と、スピーカ１１８と、マイク１２０とを備える。各構成要素は、図示しないデータバスによって相互に接続されている。
【００１８】
ＣＰＵ１００は、プログラムを実行する。ＣＰＵ１００は、通信端末装置１０の各部を統括的に制御する制御部を構成する。制御部の主な制御構成については、後述する。
【００１９】
メモリ１０２は、ＲＯＭ（Read  Only  Memory）、ＲＡＭ（Random  Access  Memory）および記憶装置により実現される。ＲＯＭは、通信端末装置１０で実行される制御プログラムを不揮発的に格納する。ＲＡＭは、ＣＰＵ１００によるプログラムの実行により生成されたデータ、または入力装置を介して入力されたデータを揮発的に格納する。記憶装置は、たとえばフラッシュメモリなどの不揮発性メモリにより構成され、データを不揮発的に格納する。記憶装置に格納されるデータは、通信端末装置１０の各部を制御するためのプログラムの他、各種アプリケーションを含んでいる。
【００２０】
無線通信部１０４は、基地局２０（図１）との間で無線通信を行なう。具体的には、無線通信部１０４は、通信アンテナ１０６を介して無線通信網に接続し無線通信のための信号を送受信する。これにより、通信端末装置１０は、無線通信網を利用して、基地局２０を経由して他の通信端末装置１０と通信を行なうことができる。無線通信部１０４は、典型的には、ＲＦ（Radio  Frequency）回路と、ベースバンド回路とを含む。
【００２１】
通信Ｉ／Ｆ１０８は、外部装置との間で各種データをやり取りするものであり、アダプタやコネクタなどによって実現される。なお、通信方式としては、たとえば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、無線ＬＡＮ（Local  Area  Network）などの無線通信であってもよいし、ＵＳＢ（Universal  Serial  Bus）などを利用した有線通信であってもよい。
【００２２】
電源回路１１０は、商用電源などの外部電源から電圧の供給を受けて通信端末装置１０の各部の電源電圧を生成する回路である。
【００２３】
タッチスクリーン１１２は、各種のデータの表示とともに、ユーザの入力操作を受け付ける、表示一体型入力装置である。具体的には、タッチスクリーン１１２は、ディスプレイ１１４（表示部）とタッチパネル１１６（入力部）とにより構成される。ディスプレイ１１４は、画像を表示するための表示画面を含んでいる。
【００２４】
スピーカ１１８は、ＣＰＵ１００から出力されるデータを表わす音のデータを出力する。スピーカ１１８が出力する音データには、人間の発する音声の周波数帯域に含まれる音のデータ（音声データ）が含まれる。
【００２５】
マイク１２０は、外部からの音の入力を受け付ける。マイク１２０は、主に音声データの入力を受け付ける。マイク１２０は、入力された音声データをＣＰＵ１００へ出力する。
【００２６】
通信端末装置１０における処理は、各ハードウェアおよびＣＰＵ１００により実行されるソフトウェアによって実現される。このようなソフトウェアは、メモリ１０２に予め格納されている場合がある。また、ソフトウェアは、その他の記憶媒体に格納されて、プログラムプロダクトとして流通している場合もある。あるいは、ソフトウェアは、いわゆるインターネットに接続されている情報提供事業者によってダウンロード可能なプログラムプロダクトとして提供される場合がある。このようなソフトウェアは、読取装置によってその記憶媒体から読み取られて、あるいは通信Ｉ／Ｆ１０８等を介してダウンロードされた後、実行可能なプログラムの形式でメモリ１０２に一旦格納される。当該ソフトウェアは、ＣＰＵ１００によってメモリ１０２から読み出され、実行可能なプログラムの形式でＲＡＭに格納される。ＣＰＵ１００はそのプログラムを実行する。
【００２７】
同図に示される通信端末装置１０を構成する各構成要素は、スマートフォンの構成要素として一般的なものである。したがって、本実施形態の本質的な部分は、メモリ１０２、メモリ１０２に格納されたソフトウェア、あるいはネットワークを介してダウンロード可能なソフトウェアであるともいえる。
【００２８】
図３は、実施の形態１に係る通信端末装置１０の制御構造を示すブロック図である。図３を参照して、通信端末装置１０は、無線送信部３０と、無線受信部４０と、制御部５０と、入力部７０と、報知部８０とを備える。図３に示す制御構造は、基本的には、通信端末装置１０のＣＰＵ１００（図２）がメモリ１０２に格納されたオペレーションシステムおよびアプリケーションプログラムを実行し、通信端末装置１０の構成要素へ指示を与えることなどによって実現される。すなわち、ＣＰＵ１００は、通信端末装置１０の動作を統括的に制御する制御部としての機能を実現する。
【００２９】
無線送信部３０は、基地局２０に向けてデータを送信する。無線受信部４０は、基地局２０からデータを受信する。無線受信部４０が受信するデータには、基地局２０により配信される発信規制通知および緊急速報が含まれる。緊急速報とは、気象庁が配信する「緊急地震速報」や「津波警報」、国・地方公共団体が配信する「災害・避難情報」などである。無線送信部３０および無線受信部４０は、無線通信部１０４および通信アンテナ１０６により実現される。
【００３０】
入力部７０は、通信端末装置１０に対するユーザからの操作を受け付ける。入力部７０は、主に、ＣＰＵ１００とタッチパネル１１６とが連係して動作することで実現される。
【００３１】
報知部８０は、制御部５０からの指示に基づいて情報をユーザに報知する。報知部８０は、ディスプレイ１１４およびスピーカ１１８の少なくともいずれかにより実現される。すなわち、報知部８０は、視覚的もしくは聴覚的あるいはこれらの組み合わせによって、情報をユーザに報知する。
【００３２】
制御部５０は、無線送信部３０および無線受信部４０を用いた各種通信を制御するための制御するためのブロックである。制御部５０は、通信プロトコルに従った、送受信制御を含めたデータ処理を行なう。たとえば、制御部５０は、送信用のデータを生成し、無線送信部３０に送る。制御部５０は、入力部７０を介して発信要求を受け付けると、基地局２０にデータを送信するのに先立って、無線通信網に接続するための発信処理を実行する。
【００３３】
発信処理において、基地局２０は、通信端末装置１０からの信号を受信すると、当該信号の受信を示す応答信号を通信端末装置１０へ送信する。この応答信号を無線受信部４０が受信したときに、制御部５０は、無線通信網への接続が成功したと判断する。一方、基地局２０に信号を送信した時点から所定時間内に無線受信部４０が応答信号を受信しないときには、制御部５０は、無線通信網への接続が失敗したと判断する。あるいは、発信要求の拒絶を示す応答信号を無線受信部４０が受信したとき、制御部５０は、無線通信網への接続が失敗したと判断する。
【００３４】
発信処理において無線通信網への接続が失敗した場合、制御部５０は発信処理をリトライする。具体的には、制御部５０は、発信リトライを実行するための構成として、リトライ回数設定部５２と、リトライ間隔設定部５６と、リトライ実行部５８と、送信電力制御部６０とを含む。
【００３５】
リトライ実行部５８は、発信処理において無線通信網への接続が失敗した場合には、無線送信部３０に対して、発信リトライを指示する。リトライ実行部５８は、リトライ回数Ｒｎをカウントするカウンタを有している。カウンタは、リトライ回数Ｒｎのカウント値を送信電力制御部６０に送る。
【００３６】
送信電力制御部６０は、カウンタから与えられるリトライ回数Ｒｎに基づいて、発信リトライごとに無線送信部３０から送信される信号の送信電力を制御する。送信電力制御部６０については、後述する。
【００３７】
リトライ回数設定部５２は、リトライ実行部５８による発信リトライを許容する最大リトライ回数Ｒｎ＿ｍａｘを設定する。リトライ実行部５８は、リトライ回数設定部５２により設定された最大リトライ回数Ｒｎ＿ｍａｘを上限として、無線送信部３０に発信リトライを指示する。具体的には、リトライ回数設定部５２は、最大リトライ回数Ｒｎ＿ｍａｘについて、初期設定値としてデフォルト値αを有している。基地局２０が緊急速報を配信していない通常時には、リトライ回数設定部５２は、最大リトライ回数Ｒｎ＿ｍａｘをデフォルト値αに設定する。一方、緊急時に基地局２０が配信する緊急速報を無線受信部４０が受信した場合には、リトライ回数設定部５２は、緊急速報を受信した時点からの経過時間に応じて、最大リトライ回数Ｒｎ＿ｍａｘを可変に設定する。
【００３８】
リトライ間隔設定部５６は、リトライ実行部５８による発信リトライを実行する間隔（リトライ間隔）Ｒｉを設定する。リトライ実行部５８は、リトライ間隔設定部５６により設定されたリトライ間隔Ｒｉに従ったタイミングで無線送信部３０に発信リトライを指示する。
【００３９】
リトライ実行部５８は、リトライ回数Ｒｎのカウント値が最大リトライ回数Ｒｎ＿ｍａｘに達した場合において基地局２０との接続が失敗したときには、報知部８０を用いて、通信システムにおける通信エラーの発生をユーザに報知する。報知部８０は、一例として、通信エラーというメッセージを含む画像で構成されたユーザインタフェイスをディスプレイ１１４の表示画面の一番手前に表示（ポップアップ）させる。
【００４０】
図４は、通常時における発信リトライ動作を説明する図である。図４は、通常時に発信リトライを実行する場合における、リトライ回数と発信リトライごとの送信電力との関係を示す図である。
【００４１】
図４を参照して、たとえば、最大リトライ回数Ｒｎ＿ｍａｘのデフォルト値αは「１２回」に設定されている。通常時、リトライ実行部５８は、デフォルト値αである１２回を上限として発信リトライを実行する。具体的には、図４に示すように、リトライ実行部５８は、リトライ回数４回を１セットとして、合計３セット（４×３＝１２回）の発信リトライを実行することができる。
【００４２】
各セットでは、リトライ間隔設定部５６によって設定されたリトライ間隔Ｒｉに従ったタイミングで発信リトライが実行される。なお、リトライ間隔Ｒｉは、１回の発信リトライにおいて無線送信部３０が信号を送信してから無線受信部４０が基地局２０からの応答信号を受信するまでに要する時間よりも長い時間に設定されている。
【００４３】
各セットにおいて、発信リトライごとに無線送信部３０から送信される信号の送信電力は、送信電力制御部６０によって制御される。図４に示すように、送信電力制御部６０は、リトライ回数Ｒｎが増えるに従って送信電力を増加させるように構成されている。
【００４４】
セットとセットとの間の時間間隔は、前回のセットにおいて通信端末装置１０から処理信号を送信した基地局２０とは別の通信エリア２００に存在する基地局２０を探すために設けられている。この時間間隔において、通信端末装置１０は、別の通信エリア２００の電波状態が良い基地局２０に切り替えを行なうことができる。したがって、次回のセットでは、無線送信部３０は切り替え後の基地局２０に対して信号を送信する。このとき、送信電力制御部６０は、切り替え後の基地局２０に対して、改めてリトライ回数Ｒｎに応じた送信電力の制御を実行する。
【００４５】
一方、基地局２０から配信された緊急速報を無線受信部４０が受信した場合には、制御部５０は、自主的に発信を抑制する。その手法として、制御部５０は、上述した通常時の発信リトライ動作に比較して、発信リトライに対する制限を強化する。本実施の形態では、リトライ回数設定部５２は、無線受信部４０が緊急速報を受信した場合には、通常時よりも最大リトライ回数Ｒｎ＿ｍａｘを低減するように構成されている。
【００４６】
図５は、緊急速報を受信した場合における最大リトライ回数Ｒｎ＿ｍａｘの時間的な変化を示す図である。図５では、無線受信部４０が緊急速報を受信した時点をｔ＝０とし、当該時点からの経過時間ｔ（以下「経過時間」と略す）を横軸に表示するとともに、経過時間ｔに対する最大リトライ回数Ｒｎ＿ｍａｘを縦軸に表示している。
【００４７】
図５を参照して、最大リトライ回数Ｒｎ＿ｍａｘは、経過時間ｔが短いほど回数が小さくなるように設定される。たとえば、最大リトライ回数Ｒｎ＿ｍａｘは、経過時間ｔを変数とした計算式（１）を用いて算出される。
【００４８】
Ｒｎ＿ｍａｘ（ｔ）＝α×（ｔ＋１）／４  ・・・（１）
上記の計算式（１）において、αはデフォルト値（たとえば１２回）である。また、経過時間ｔは１時間を単位時間として、１時間未満を切り捨てるものとする。
【００４９】
これにより、図５に示すように、経過時間ｔが１時間未満となる場合（ｔ＜１ｈ）、上記計算式（１）にｔ＝０を代入することにより、最大リトライ回数Ｒｎ＿ｍａｘはα×１／４回に設定される。たとえば、デフォルト値αが１２回であれば、経過時間ｔが１時間未満となる場合の最大リトライ回数Ｒｎ＿ｍａｘは３回となる。図６は、経過時間が１時間未満となる場合における、リトライ回数と発信リトライごとの送信電力との関係を示す図である。図６に示すように、リトライ実行部５８は、リトライ間隔Ｒｉに従ったタイミングで３回を上限として発信リトライを実行する。発信リトライごとの送信電力は、リトライ回数Ｒｎが増えるにつれて大きくなるように制御される。
【００５０】
図５に戻って、経過時間ｔが１時間以上２時間未満となる場合（１ｈ≦ｔ＜２ｈ）には、上記計算式（１）にｔ＝１を代入することにより、最大リトライ回数Ｒｎ＿ｍａｘはα×１／２回に設定される。したがって、デフォルト値αが１２回であれば、経過時間が１時間以上２時間未満となる場合の最大リトライ回数Ｒｎ＿ｍａｘは６回となる。図７は、経過時間ｔが１時間以上２時間未満となる場合における、リトライ回数と発信リトライごとの送信電力との関係を示す図である。図７に示すように、リトライ実行部５８は、リトライ間隔Ｒｉに従ったタイミングで６回を上限として発信リトライを実行する。発信リトライごとの送信電力は、通常時と同様に、リトライ回数４回を１セットとして、リトライ回数Ｒｎが増えるにつれて大きくなるように制御される。
【００５１】
さらに経過時間ｔが２時間以上３時間未満となる場合（２ｈ≦ｔ＜３ｈ）には、上記計算式（１）にｔ＝２を代入することにより、最大リトライ回数Ｒｎ＿ｍａｘはα×３／４回に設定される。デフォルト値αが１２回であれば、経過時間が２時間以上３時間未満となる場合の最大リトライ回数Ｒｎ＿ｍａｘは９回となる。図８は、経過時間が２時間以上３時間未満となる場合における、リトライ回数と発信リトライごとの送信電力との関係を示す図である。図８に示すように、リトライ実行部５８は、リトライ間隔Ｒｉに従ったタイミングで９回を上限として発信リトライを実行する。発信リトライごとの送信電力は、通常時と同様に、リトライ回数４回を１セットとして、リトライ回数Ｒｎが増えるにつれて大きくなるように制御される。
【００５２】
最後に、経過時間ｔが３時間以上となると（ｔ≧３ｈ）、上記計算式（１）にｔ＝３を代入することにより、最大リトライ回数Ｒｎ＿ｍａｘはデフォルト値αと等しくなる。すなわち、経過時間が３時間以上に及ぶと、最大リトライ回数Ｒｎ＿ｍａｘは通常時の最大リトライ回数Ｒｎ＿ｍａｘに戻される。図９は、経過時間が３時間以上となる場合における、リトライ回数と発信リトライごとの送信電力との関係を示す図である。図９に示す関係は、図４に示した通常時のリトライ回数と発信リトライごとの送信電力との関係と同じものである。
【００５３】
リトライ回数設定部５２は、図５に示す最大リトライ回数Ｒｎ＿ｍａｘの時間的な変化をテーブル５４として格納している。リトライ回数設定部５２は、テーブル５４を参照することにより、経過時間ｔに応じて最大リトライ回数Ｒｎ＿ｍａｘを設定する。あるいは、リトライ回数設定部５２は、経過時間ｔを上記計算式（１）に代入することにより、最大リトライ回数Ｒｎ＿ｍａｘを算出することができる。
【００５４】
なお、図５では、緊急速報を受信した時点から１時間おきに最大リトライ回数Ｒｎ＿ｍａｘを切り替える構成について例示したが、最大リトライ回数Ｒｎ＿ｍａｘを切り替える時間間隔は１時間より長くてもよいし、１時間より短くてもよい。
【００５５】
以上のように、最大リトライ回数Ｒｎ＿ｍａｘは、緊急速報を受信した時点から１時間が経過するまでの間、通常時の１／４の回数に制限され、時間の経過に応じて徐々にその制限が緩和される。緊急速報が配信された直後は、通信トラフィックが集中するため、通信の輻輳が発生する可能性が高くなる。本実施の形態１によれば、このときの最大リトライ回数Ｒｎ＿ｍａｘを通常時の最大リトライ回数Ｒｎ＿ｍａｘよりも小さくすることで、実質的に通信端末装置１０が自ら発信を抑制することになる。
【００５６】
以上のような制御構造によって、実施の形態１に係る発信処理のリトライが実現される。これらの処理は、次のような処理フローにまとめることができる。
【００５７】
図１０は、実施の形態１に係る通信端末装置１０における発信処理の流れを示すフローチャートである。なお、図１０に示すフローチャートは、ＣＰＵ１００がメモリ１０２に予め格納されるプログラムを実行することによって実現される。
【００５８】
図１０を参照して、まず、発信処理を実行するために、ＣＰＵ１００は、ステップＳ０１により、基地局２０から配信される発信規制通知を受信したか否かを判定する。発信規制通知を受信したと判定されると（Ｓ０１のＹＥＳ判定時）、ＣＰＵ１００は処理を終了する。この場合、基地局２０が実行する輻輳制御に従った発信処理が行なわれることによって、通信端末装置１０における発信が抑制される。
【００５９】
一方、発信規制通知を受信していないと判定された場合（Ｓ０１のＮＯ判定時）、ＣＰＵ１００は、ステップＳ０２により、通信端末装置１０に対するユーザからの発信要求を受け付けたことに応答して、ステップＳ０３に進み、発信処理を実行する。
【００６０】
ＣＰＵ１００は、ステップＳ０４では、発信処理の実行後、基地局２０から送られてくる応答信号に基づいて、無線通信網への接続が失敗したか否かを判定する。基地局２０から応答信号が送られてきた場合、ＣＰＵ１００は、無線通信網への接続が成功したと判定し（Ｓ０４のＮＯ判定時）、処理を終了する。
【００６１】
これに対して、基地局２０に向けて信号を送信した時点から所定期間内に応答信号を受信できない場合、または発信要求の拒絶を示す応答信号を受信した場合には、ＣＰＵ１００は、無線通信網への接続が失敗したと判定する（Ｓ０４のＹＥＳ判定時）。この場合、ＣＰＵ１００は、ステップＳ０５により、発信処理のリトライを実行する。ＣＰＵ１００は、発信リトライを行なうにあたり、リトライ回数Ｒｎをカウントするカウンタをカウントアップする。さらにＣＰＵ１００は、リトライ回数Ｒｎのカウント値に基づいて、基地局２０に送信する信号の送信電力を決定する。
【００６２】
ＣＰＵ１００は、ステップＳ０６により、今回の発信リトライが、緊急速報を受信した後、所定期間内での発信リトライに該当するか否かを判定する。所定期間は、図５に基づく最大リトライ回数Ｒｎ＿ｍａｘの設定において、最大リトライ回数Ｒｎ＿ｍａｘがデフォルト値αに回復するまでの時間（たとえば３時間）よりも長い時間に設定される。発信リトライが緊急速報を受信した後、所定期間内の発信リトライに該当すると判定された場合（Ｓ０６のＹＥＳ判定時）、ＣＰＵ１００は、ステップＳ０７により、緊急速報を受信した時点からの経過時間に基づいて設定された最大リトライ回数Ｒｎ＿ｍａｘ（図５参照）と、リトライ回数Ｒｎとを比較する。リトライ回数Ｒｎが最大リトライ回数Ｒｎ＿ｍａｘ以下であると判定された場合（Ｓ０７のＹＥＳ判定時）、ＣＰＵ１００は、処理をステップＳ０３に戻すことにより、発信処理を実行（リトライ）する。
【００６３】
一方、リトライ回数Ｒｎが最大リトライ回数Ｒｎ＿ｍａｘを超えていると判定された場合（Ｓ０７のＮＯ判定時）、ＣＰＵ１００は、発信リトライを終了し、ステップＳ０８により、通信システムにおける通信エラーの発生をユーザに報知する。
【００６４】
ステップＳ０６に戻り、今回の発信リトライが緊急速報を受信した後、所定期間内の発信リトライに該当しない場合、すなわち通常時の発信リトライに該当する場合（Ｓ０６のＮＯ判定時）、ＣＰＵ１００は、ステップＳ０９により、最大リトライ回数Ｒｎ＿ｍａｘのデフォルト値αと、リトライ回数Ｒｎとを比較する。リトライ回数Ｒｎが最大リトライ回数Ｒｎ＿ｍａｘ以下であると判定された場合（Ｓ０９のＹＥＳ判定時）、ＣＰＵ１００は、処理をステップＳ０３に戻すことにより、発信処理を実行（リトライ）する。一方、リトライ回数Ｒｎが最大リトライ回数Ｒｎ＿ｍａｘを超えていると判定された場合（Ｓ０９のＮＯ判定時）、ＣＰＵ１００は、発信リトライを終了し、ステップＳ０８により、通信システムにおける通信エラーの発生をユーザに報知する。
【００６５】
この発明の実施の形態１によれば、緊急速報を受信した通信端末装置１０が、基地局２０からの発信規制の通知を待たず、自主的に発信を抑制することができる。したがって、万一基地局２０が発信規制を正常に発動できないような状況であっても、通信端末装置１０が主導して輻輳制御を行なうことが可能となる。
【００６６】
これにより、通信が輻輳しているにも拘らず発信処理のリトライを無駄に実行することによって、通信端末装置１０において電力が無駄に消費されるのを抑えることができる。また、通信エリア２００内の複数の通信端末装置１０の各々が自主的に送信を抑制することで、基地局２０に発信が集中するのが緩和されるため、輻輳が増長するのを抑制することができる。その結果、通信の輻輳状態を解消することが可能となり、通信端末装置１０の無線通信網への接続率を改善することができる。
【００６７】
なお、図５では、緊急速報を受信した時点から１時間おきに最大リトライ回数Ｒｎ＿ｍａｘを切り替える構成について例示したが、緊急速報を受信した時点からデフォルト値αに戻るまでの時間Ｔと、時間Ｔの間に最大リトライ回数Ｒｎ＿ｍａｘを切り替える回数Ｍとによって、最大リトライ回数Ｒｎ＿ｍａｘを切り替える時間間隔は適宜変更可能である。例えば、最大リトライ回数Ｒｎ＿ｍａｘが、切り替わる度に同じ回数だけ増加すると仮定し、緊急速報を受信した時点の最大リトライ回数Ｒｎ＿ｍａｘをｋとすると、緊急速報を受信した時点から時間Ｔ／Ｍが経過するごとに、最大リトライ回数Ｒｎ＿ｍａｘが（α−ｋ）／Ｍずつ増加していく。
【００６８】
なお、実施の形態１では、緊急速報を受信した時点から一定時間おきに最大リトライ回数Ｒｎ＿ｍａｘを切り替える構成について例示したが、最大リトライ回数Ｒｎ＿ｍａｘを切り替える時間間隔は等間隔でなくてもよい。例えば、緊急速報を受信した時点からの経過時間が短いほど、その時間間隔を長く、緊急速報を受信した時点からの経過時間が長いほど、その時間間隔を短くしてもよい。
【００６９】
また、図５では、最大リトライ回数Ｒｎ＿ｍａｘは、切り替わる度に増加する回数は同じであるが、この回数も緊急速報を受信した時点からの経過時間に応じて変更することも可能である。
【００７０】
［実施の形態１の変形例］
（リトライ間隔の変更）
上述の実施の形態１では、発信処理のリトライにおいて、緊急速報を受信した場合におけるリトライ間隔Ｒｉを、通常時におけるリトライ間隔Ｒｉと同じ長さに設定する構成について例示したが、緊急速報を受信した場合におけるリトライ間隔Ｒｉを、通常時におけるリトライ間隔Ｒｉよりも長くする構成としてもよい。緊急速報が配信された後は、基地局２０に発信が集中するため、通信端末装置１０が基地局２０からの応答信号を受信するのに通常時よりも長い時間がかかる可能性がある。したがって、緊急速報を受信した後は、リトライ間隔Ｒｉを通常時よりも長くすることで、通信端末装置１０において無線通信網への接続が失敗したか否かの判定を正確に行なうことができる。その結果、誤った判定に基づいて発信処理がリトライされるのを防止できるため、輻輳の増長および電力消費の増加を抑制することができる。
【００７１】
（送信電力の変更）
また、上述の実施の形態１では、緊急速報を受信した場合における発信リトライごとの送信電力の制御を、通常時における送信電力の制御と同様の方法によって、リトライ回数Ｒｎが増えるに従って送信電力を増加させる構成について例示したが、緊急速報を受信した場合には、発信リトライごとの送信電力の増加量を通常時よりも大きくするようにしてもよい。これによれば、１回の発信リトライで無線通信網への接続が成功する確率を上げることができるため、リトライ回数が増えるのを抑制するのに有効である。
【００７２】
（日時指定）
上述の実施の形態１では、基地局２０が配信する緊急速報を受信した場合に、通常時よりも最大リトライ回数Ｒｎ＿ｍａｘを低減する構成について説明したが、予め指定された日時において、最大リトライ回数Ｒｎ＿ｍａｘを低減するようにしてもよい。たとえば、コンサートや花火大会などのイベント時や年末年始などは、輻輳が発生することを事前に予測することができる。したがって、イベントの日時や年末年始などの日時を予め指定しておくことで、通信端末装置１０は、指定された日時にて、基地局２０からの発信規制通知を待たず、自主的に発信を抑制することができる。
【００７３】
具体的には、図３に示す通信端末装置１０の制御構造において、リトライ回数設定部５２は、指定日時に到達した時点からの経過時間に応じて、最大リトライ回数Ｒｎ＿ｍａｘを可変に設定する。このとき、リトライ回数設定部５２は、最大リトライ回数Ｒｎ＿ｍａｘを、指定日時に到達した時点からの経過時間が短いほど回数が小さくなるように設定される。たとえば、最大リトライ回数Ｒｎ＿ｍａｘは、指定日時に到達した時点からの経過時間ｔを上記計算式（１）に代入することによって設定することができる。
【００７４】
図１１は、実施の形態１の変形例に係る通信端末装置１０における発信処理の流れを示すフローチャートである。図１１を参照して、実施の形態１の変形例に係る発信処理は、図１０に示す実施の形態１における発信処理において、ステップＳ０６をステップＳ０６１に代えたものである。
【００７５】
図１１に示すように、ＣＰＵ１００は、ステップＳ０６１により、今回の発信リトライが指定日時に到達した後、所定期間内の発信リトライに該当するか否かを判定する。所定期間は、図１０のステップＳ０６と同様に、最大リトライ回数Ｒｎ＿ｍａｘの設定において、最大リトライ回数Ｒｎ＿ｍａｘがデフォルト値αに回復するまでの時間（たとえば３時間）よりも長い時間に設定される。発信リトライが指定日時に到達した後、所定期間内の発信リトライに該当すると判定された場合（Ｓ０６１のＹＥＳ判定時）、ＣＰＵ１００は、ステップＳ０７により、指定日時に到達した時点からの経過時間に基づいて設定された最大リトライ回数Ｒｎ＿ｍａｘと、リトライ回数Ｒｎとを比較する。リトライ回数Ｒｎが最大リトライ回数Ｒｎ＿ｍａｘ以下であると判定された場合（Ｓ０６１のＹＥＳ判定時）、ＣＰＵ１００は、処理をステップＳ０３に戻すことにより、発信処理を実行（リトライ）する。
【００７６】
一方、リトライ回数Ｒｎが最大リトライ回数Ｒｎ＿ｍａｘを超えていると判定された場合（Ｓ０７のＮＯ判定時）、ＣＰＵ１００は、発信リトライを終了し、ステップＳ０８により、通信システムにおける通信エラーの発生をユーザに報知する。
【００７７】
ステップＳ０６１に戻り、今回の発信リトライが指定日時に到達した後、所定期間内の発信リトライに該当しない場合、すなわち通常時の発信リトライに該当する場合（Ｓ０６１のＮＯ判定時）、ＣＰＵ１００は、ステップＳ０９により、最大リトライ回数Ｒｎ＿ｍａｘのデフォルト値αと、リトライ回数Ｒｎとを比較する。リトライ回数Ｒｎが最大リトライ回数Ｒｎ＿ｍａｘ以下であると判定された場合（Ｓ０９のＹＥＳ判定時）、ＣＰＵ１００は、処理をステップＳ０３に戻すことにより、発信処理を実行（リトライ）する。一方、リトライ回数Ｒｎが最大リトライ回数Ｒｎ＿ｍａｘを超えていると判定された場合（Ｓ０９のＮＯ判定時）、ＣＰＵ１００は、発信リトライを終了し、ステップＳ０８により、通信システムにおける通信エラーの発生をユーザに報知する。
【００７８】
［実施の形態２］
上述の実施の形態１に係る通信端末装置１０では、基地局２０が配信する緊急速報を受信した場合に、自動的に通常時よりも最大リトライ回数Ｒｎ＿ｍａｘを低減する構成について説明したが、最大リトライ回数Ｒｎ＿ｍａｘの低減を許可するか否かを通信端末装置１０のユーザが選択できるようにしてもよい。
【００７９】
実施の形態２では、ユーザによる最大リトライ回数Ｒｎ＿ｍａｘの低減を許可するか否かの選択を実現する構成について説明する。なお、実施の形態２に係る通信端末装置１０のハードウェア構成は、図１と同様であるので詳細な説明は繰り返さない。
【００８０】
図１２は、実施の形態２に係る通信端末装置１０Ａの制御構造を示すブロック図である。図１２を参照して、通信端末装置１０Ａにおける制御構造は、図３に示す制御構造において、通知部９０をさらに設けたものである。
【００８１】
通知部９０は、無線受信部４０が緊急速報を受信したとき、ユーザに対して、リトライ回数設定部５２による最大リトライ回数Ｒｎ＿ｍａｘの低減を許可するか否かの選択を促す通知を行なう。通知部９０は、ディスプレイ１１４およびスピーカ１１８の少なくともいずれかにより実現される。たとえば、通知部９０は、ユーザに対して最大リトライ回数Ｒｎ＿ｍａｘを制限することについての許可を求めるユーザインタフェイス画面をディスプレイ１１４の表示画面に表示する。
【００８２】
図１３は、実施の形態２に係るユーザインタフェイス画面の一例を示す図である。図１３を参照して、ユーザインタフェイス画面２１０は、「発信リトライ回数を低減することを許可しますか」といったメッセージ２１２と、ＹＥＳボタン２１４と、ＮＯボタン２１６とを含む。リトライ実行部５８は、タッチパネル１１６を介してユーザからの指示を受け付ける。リトライ実行部５８は、ユーザからの入力に基づいて、最大リトライ回数Ｒｎ＿ｍａｘの低減が許可されている否かを判断する。具体的には、リトライ実行部５８は、ユーザからＹＥＳボタン２１４の入力を受け付けた場合には、最大リトライ回数Ｒｎ＿ｍａｘの低減が許可されていると判断し、ユーザからＮＯボタン２１６の入力を受け付けた場合には、最大リトライ回数Ｒｎ＿ｍａｘの低減が許可されていないと判断する。
【００８３】
図１４は、実施の形態２に係る通信端末装置１０Ａにおける発信処理の流れを示すフローチャートである。図１４を参照して、実施の形態２に係る発信処理は、図１０に示す実施の形態１に係る発信処理のフローチャートにおいて、ステップＳ０６とステップＳ０７との間に、ステップＳ０６２を追加したものである。
【００８４】
ステップＳ０６２では、ＣＰＵ１００は、ユーザインタフェイス画面（図１３）に対するユーザからの入力に基づいて、最大リトライ回数Ｒｎ＿ｍａｘの低減が許可されているか否かを判断する。最大リトライ回数Ｒｎ＿ｍａｘの低減が許可されていると判断された場合（Ｓ０６２のＹＥＳ判定時）には、ＣＰＵ１００は、ステップＳ０７に進み、緊急速報を受信した時点からの経過時間に基づいて設定された最大リトライ回数Ｒｎ＿ｍａｘと、リトライ回数Ｒｎとを比較する。そして、リトライ回数Ｒｎが最大リトライ回数Ｒｎ＿ｍａｘ以下であると判定された場合（Ｓ０７のＹＥＳ判定時）、ＣＰＵ１００は、処理をステップＳ０３に戻すことにより、発信処理を実行（リトライ）する。
【００８５】
これに対して、最大リトライ回数Ｒｎ＿ｍａｘの低減が許可されていないと判断された場合（Ｓ０６２のＮＯ判定時）には、ＣＰＵ１００は、ステップＳ０９により、最大リトライ回数Ｒｎ＿ｍａｘのデフォルト値αと、リトライ回数Ｒｎとを比較する。リトライ回数Ｒｎが最大リトライ回数Ｒｎ＿ｍａｘ以下であると判定された場合（Ｓ０９のＹＥＳ判定時）、ＣＰＵ１００は、処理をステップＳ０３に戻すことにより、発信処理を実行（リトライ）する。
【００８６】
この発明の実施の形態２によれば、通信端末装置１０Ａは、緊急速報を受信した場合には、最大リトライ回数Ｒｎ＿ｍａｘを低減することを許可するか否かをユーザに確認する。そのため、緊急速報を受信した後、ユーザの認識がないまま、最大リトライ回数Ｒｎ＿ｍａｘが低減されてしまうことを防ぐことができる。
【００８７】
あるいは、実施の形態２によれば、緊急速報を受信した後であっても、ユーザは、最大リトライ回数Ｒｎ＿ｍａｘを低減させないようにすることができる。この場合、基地局２０から発信規制通知が配信されるまでの間、通常時における最大リトライ回数Ｒｎ＿ｍａｘを用いて発信リトライが実行されることになる。
【００８８】
なお、実施の形態２では、緊急速報を受信したときに、ユーザに対して最大リトライ回数Ｒｎ＿ｍａｘを低減することについての許可を求めるユーザインタフェイス画面（図１３）を表示する構成を例示したが、緊急速報が配信されていない通常時においても、たとえばユーザからの発信要求を受け付けたことに応答して、図１３に示すユーザインタフェイス画面を表示する構成としてもよい。これによれば、ユーザが指定する任意のタイミングで、最大リトライ回数Ｒｎ＿ｍａｘを低減することが可能となるため、通信端末装置１０Ａにおける電力消費の低減に有効である。
【００８９】
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【００９０】
１０，１０Ａ  通信端末装置、２０  基地局、３０  無線送信部、４０  無線受信部、５０  制御部、５２  リトライ回数設定部、５４  テーブル、５６  リトライ間隔設定部、５８  リトライ実行部、６０  送信電力制御部、７０  入力部、８０  報知部、９０  通知部、１００  ＣＰＵ、１０２  メモリ、１０４  無線通信部、１０６  通信アンテナ、１０８  通信Ｉ／Ｆ、１１０  電源回路、１１２  タッチスクリーン、１１４  ディスプレイ、１１６  タッチパネル、１１８  スピーカ、１２０  マイク、２００  通信エリア、２１０  ユーザインタフェイス画面、２１２  メッセージ、２１４  ＹＥＳボタン、２１６  ＮＯボタン。
【図１】
2016086268.tif 000003
【図２】
2016086268.tif 000004
【図３】
2016086268.tif 000005
【図４】
2016086268.tif 000006
【図５】
2016086268.tif 000007
【図６】
2016086268.tif 000008
【図７】
2016086268.tif 000009
【図８】
2016086268.tif 000010
【図９】
2016086268.tif 000011
【図１０】
2016086268.tif 000012
【図１１】
2016086268.tif 000013
【図１２】
2016086268.tif 000014
【図１３】
2016086268.tif 000015
【図１４】
2016086268.tif 000016