JP2015201698A - 通信装置、通信方法、及び、プログラム - Google Patents

Abstract

【課題】通信の接続状態に応じて発生する無駄な消費電力を低減することができるようにする。
【解決手段】通信の送信要求が発生した場合に、将来発生する通信予測の結果、及び、通信の接続状態に基づいて、省電力の観点から、送信要求に対する送信処理を実行するタイミングを判断する遅延判断部と、送信処理を実行するタイミングであると判断された場合、送信要求を、送信処理を実行する送信処理部に通知する送信要求制御部とを備える通信装置が提供されるようにする。本技術は、例えば、モバイルネットワークを通じてデータ通信を行うことが可能なモバイル機器に適用することができる。
【選択図】図３

Description

本技術は、通信装置、通信方法、及び、プログラムに関し、特に、通信の接続状態に応じて発生する無駄な消費電力を低減することができるようにした通信装置、通信方法、及び、プログラムに関する。

近年、スマートフォン等のデータ通信を行うモバイル機器が普及している。この種のモバイル機器では、低消費電力の要求があることから、省電力化のための技術が提案されている（例えば、特許文献１参照）。

特表２０１３−５０３５５７号

ところで、この種のモバイル機器では、パケットの送受信をしていないときでも電力を消費している。この電力は、一定ではなく、いつでも通信基地局との間でデータの送受信を行える状態のときは、消費電力は高くなり、逆に、データの送受信の開始前に通信基地局と接続処理を必要とする状態では消費電力は低くなる。そのため、このような通信の接続状態に応じて発生する無駄な消費電力を低減したいという要求がある。

本技術はこのような状況に鑑みてなされたものであり、通信の接続状態に応じて発生する無駄な消費電力を低減することができるようにするものである。

本技術の一側面の通信装置は、通信の送信要求が発生した場合に、将来発生する通信予測の結果、及び、通信の接続状態に基づいて、省電力の観点から、前記送信要求に対する送信処理を実行するタイミングを判断する遅延判断部と、前記送信処理を実行するタイミングであると判断された場合、前記送信要求を、前記送信処理を実行する送信処理部に通知する送信要求制御部とを備える通信装置である。

前記遅延判断部は、将来発生する通信と、データの送受信に続いて発生する接続維持のための電力であるテイルエナジーの予測結果に基づいて、前記送信処理を実行するタイミングを判断することができる。

前記遅延判断部は、あらかじめ定められた判断条件を用い、前記送信処理を実行するタイミングを判断することができる。

前記判断条件は、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含むようにすることができる。

将来発生する通信を予測する通信予測部をさらに備えるようにすることができる。

前記通信予測部は、あらかじめ定められた予測条件を用い、将来発生する通信を予測するようにすることができる。

前記予測条件は、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含むようにすることができる。

特定の判断条件に関する履歴情報に基づいて、前記判断条件を更新する判断条件学習部と、特定の予測条件に関する履歴情報に基づいて、前記予測条件を更新する予測条件学習部とをさらに備えるようにすることができる。

通信の接続状態を監視する通信接続状態監視部をさらに備えるようにすることができる。

前記送信要求を発生させる特定のアプリケーションの動作状態を監視する動作状態監視部をさらに備え、前記通信予測部は、前記特定のアプリケーションの動作状態に基づいて、将来発生する通信を予測するようにすることができる。

本技術の一側面の通信装置は、全要素を単一の装置としてもよいし、有線又は無線の通信を介して複数の装置に要素を分散してもよい。

本技術の一側面の通信方法及びプログラムは、本技術の一側面の通信装置に対応する通信方法及びプログラムである。

本技術の一側面の通信装置、通信方法、及び、プログラムにおいては、通信の送信要求が発生した場合に、将来発生する通信予測の結果、及び、通信の接続状態に基づいて、省電力の観点から、前記送信要求に対する送信処理を実行するタイミングが判断され、前記送信処理を実行するタイミングであると判断された場合、前記送信要求が、前記送信処理を実行する送信処理部に通知される。

本技術の一側面によれば、通信の接続状態に応じて発生する無駄な消費電力を低減することができる。

なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

通信の接続状態の遷移と消費電力の関係を示す図である。 テイルエナジーを説明するための図である。 本技術を適用した通信装置の一実施の形態の構成を示す図である。 図３の通信装置により実行される基本の送信処理を説明するフローチャートである。 本技術を適用したインターネットラジオ専用端末の機能的な構成例を示す図である。 図５のインターネットラジオ専用端末により実行される第１の送信処理の流れを説明するフローチャートである。 図６のステップＳ２０７の判断処理で「Yes」と判断されるケースを示す図である。 図６のステップＳ２０８の判断処理で「Yes」と判断されるケースを示す図である。 図６のステップＳ２０９の判断処理で「Yes」と判断されるケースを示す図である。 図６のステップＳ２０９の判断処理で「Yes」と判断される他のケースを示す図である。 本技術を適用したスマートフォンの機能的な構成例を示す図である。 図１１のスマートフォンにより実行される第２の送信処理の流れを説明するフローチャートである。 判断条件更新処理の流れを説明するフローチャートである。 予測条件更新処理の流れを説明するフローチャートである。 本技術を適用したスマートフォンの機能的な構成例を説明する図である。 図１５のスマートフォンにより実行される第３の送信処理の流れを説明するフローチャートである。 コンピュータの構成例を示す図である。

以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。

１．テイルエナジーの発生原理
２．システム構成
３．第１の実施の形態
４．第２の実施の形態
５．第３の実施の形態
６．コンピュータの構成

＜１．テイルエナジーの発生原理＞

（通信の接続状態の遷移と消費電力の関係）
図１は、通信の接続状態の遷移と消費電力の関係を示す図である。

図１には、現在普及しているLTE(Long Term Evolution)の場合における、モバイル機器の接続状態の遷移を示している。図１においては、「RRC Connected」が通信基地局との間で、パケット（データ）の送受信を行える状態を示し、「RRC Idle」がパケットの送受信の開始前に接続処理を必要とする状態を示している。したがって、RRC Idle状態である場合に、通信の送信要求が発生したときは、RRC Idle状態からRRC Connected状態に遷移する必要がある。また、図１に示すように、RRC Connected状態では、消費電力が高くなる一方、RRC Idle状態では、消費電力が低くなる。

モバイル機器において、パケットの送受信が発生すると、それに引き続いてさらにパケットの送受信が発生する可能性が高い。そのため、一旦、RRC Connected状態になると、当該モバイル機器では、しばらくの間、そのまま通信基地局との接続を維持する。そして、RRC Connected状態が一定時間（例えば、数十秒）継続した後に、RRC Idle状態に遷移することになる。

このような、パケットの送受信に続いて発生する接続維持のための電力は、「テイルエナジー」と称されている。図２には、ある１パケットを送信したときの消費電力を模式的に示しているが、当該パケットの送受信後のRRC Connected状態を維持するための電力が、テイルエナジーとされる。

このテイルエナジーが発生すると、消費電力が高くことなることから、省電力の観点からすれば、できるだけテイルエナジーが発生しないようにすることが望ましい。そこで、本技術は、テイルエナジーの発生を抑制して、消費電力を低減することができるようにする。

なお、第3世代移動通信システム(3G：3rd Generation)の場合には、上述のLTEの場合と比べてもう少し複雑な状態遷移が行われるが、通信基地局との接続状態で消費電力が高くなり、切断状態となると消費電力が低くなって、接続状態になった後に、接続を一定時間維持することは、同様に行われている。

＜２．システム構成＞

（通信装置の基本構成）
図３は、本技術を適用した通信装置の一実施の形態の構成を示す図である。

通信装置１０は、例えば、スマートフォンや携帯電話機、携帯型のインターネットラジオ専用端末、携帯音楽プレーヤ、タブレット端末装置等のモバイルネットワークを通じてデータ通信を行うことが可能なモバイル機器である。図３に示すように、通信装置１０は、送信要求部１０１、送信要求制御部１０２、遅延判断部１０３、通信予測部１０４、通信接続状態監視部１０５、及び、送信処理部１０６から構成される。

送信要求部１０１は、ユーザ操作やアプリケーション、システム等の要求に応じて、通信の送信要求を、送信要求制御部１０２に供給する。

送信要求制御部１０２は、送信要求部１０１から通信の送信要求が供給された場合、その送信要求の遅延判断を、遅延判断部１０３に問い合わせる。送信要求制御部１０２は、遅延判断部１０３から、通信の送信要求に対する送信処理を実行すべき判断（以下、「処理判断」という。）を受け取るまで待機し、処理判断を受け取った時点で、通信の送信要求を送信処理部１０６に供給する。

遅延判断部１０３は、送信要求制御部１０２から、通信の送信要求に対する遅延判断の問い合わせを受けた場合、省電力の観点からその送信要求に対する送信処理を今処理するのか、あるいは遅延させて処理するのかを判断する。遅延判断部１０３は、通信の送信要求に対する送信処理を今処理すると判断した場合、そのタイミングで、処理判断を、送信要求制御部１０２に通知する。また、遅延判断部１０３は、通信の送信要求に対する送信処理を遅延させて処理すると判断した場合には、次にどのような条件で処理判断を通知するのかという遅延終了条件を確定する。そして、遅延判断部１０３は、遅延終了条件を満たした場合には、そのタイミングで、処理判断を、送信要求制御部１０２に通知する。

ここで、遅延判断部１０３で用いられる判断条件であるが、通信予測部１０４から供給される将来の通信予測の結果と、通信接続状態監視部１０５から供給される通信の接続状態の監視結果を用いることができる。なお、通信予測の結果や通信の接続状態の監視結果は、判断条件の一例であって、通信の送信要求に対する送信処理を行うタイミングを判断できる情報であれば、他の情報を用いることができる。

通信予測部１０４は、将来発生する通信を予測し、その予測の結果を、遅延判断部１０３に供給する。この通信予測処理では、例えば、通信の状態、アプリケーションの動作状態等のシステム内部の状態、ユーザの操作状態、位置情報等のセンシング情報、操作履歴等の履歴情報、学習結果、設定条件や設定値などの各種の情報を用いた予測が行われる。

通信接続状態監視部１０５は、モバイルネットワークを通じた通信基地局との通信の接続状態を常に監視し、その監視の結果を、遅延判断部１０３に供給する。この監視処理では、例えば、ある時点において電力が低い非接続状態（RRC Idle状態）であるか、あるいは電力が高い接続状態（RRC Connected状態）であるかが監視され、さらに、接続状態（RRC Connected状態）である場合には、その状態がどの時点まで継続するかなどが監視される。

送信処理部１０６は、送信要求制御部１０２から供給される通信の送信要求を取得して、当該送信要求に応じて送信処理を実行する。

（基本の送信処理）
次に、図４のフローチャートを参照して、図３の通信装置１０により実行される基本の送信処理の流れを説明する。

ステップＳ１０１において、送信要求部１０１は、送信要求制御部１０２に、通信の送信要求を伝える。そして、送信要求部１０１からの通信の送信要求が、送信要求制御部１０２に伝えられると、ステップＳ１０２において、送信要求制御部１０２は、その送信要求に対する遅延判断を、遅延判断部１０３に問い合わせる。

ステップＳ１０３において、遅延判断部１０３は、送信要求制御部１０２からの問い合わせに応じて、その送信要求に対する送信処理を今処理するか、あるいは、遅らせて処理するかを判断する。ステップＳ１０３において、通信の送信要求に対する送信処理を今処理すると判断された場合、処理はステップＳ１０４に進められる。

ステップＳ１０４において、遅延判断部１０３は、ステップＳ１０３の判断結果に従い、送信要求制御部１０２に、処理判断を伝える。そして、遅延判断部１０３からの処理判断が、送信要求制御部１０２に伝えられると、ステップＳ１０５において、送信要求制御部１０２は、送信処理部１０６に、通信の送信要求を伝える。

ステップＳ１０６において、送信処理部１０６は、送信要求制御部１０２から伝えられる通信の送信要求に応じて、送信処理を実行する。このように、遅延判断部１０３による処理判断が、今処理すべきとの判断であった場合には、送信処理部１０６による送信処理は遅延されずに、直ちに実行されることになる。

一方、ステップＳ１０３において、通信の送信要求に対する送信処理を遅らせて処理すると判断された場合、処理は、ステップＳ１０７に進められる。ステップＳ１０７において、遅延判断部１０３は、次にどのような条件で処理を行うかの遅延終了条件を確定する。ステップＳ１０７で、遅延終了条件が確定されると、処理は、ステップＳ１０８に進められる。

ステップＳ１０８において、遅延判断部１０３は、ステップＳ１０７で確定された遅延終了条件を満たしたかどうかを判断する。ステップＳ１０８において、遅延終了条件を満たしていないと判断された場合、ステップＳ１０８の判断処理が繰り返し実行される。一方、ステップＳ１０８において、遅延終了条件を満たしたと判断された場合、処理は、ステップＳ１０４に進められる。

ステップＳ１０４乃至Ｓ１０６においては、上述したように、送信要求制御部１０２からの通信の送信要求が、送信処理部１０６に伝えられるので、送信処理部１０６は、通信の送信要求に応じて、送信処理を実行することになる。このように、遅延判断部１０３による処理判断が、遅らせて処理すべきとの判断であった場合には、所定の遅延終了条件を満たすまで送信処理が遅延され、所定の遅延終了条件を満たしてから、送信処理が実行されることになる。

ステップＳ１０６の処理が終了すると、図４の基本の送信処理は終了する。

以上、図３及び図４を参照して、基本の送信処理を実行する通信装置１０について説明したが、以下、より具体的な送信処理を実行する通信装置の構成について説明する。ここでは、本技術を適用した通信装置として、携帯型のインターネットラジオ専用端末と、スマートフォンの構成を説明する。

＜３．第１の実施の形態＞

まず、第１の実施の形態においては、本技術を適用した通信装置として、携帯型のインターネットラジオ専用端末について説明する。

ここでは、インターネットラジオ専用端末が、LTE(Long Term Evolution)等のモバイルネットワークを通じて、主として音声で番組が配信されるインターネットラジオ放送を受信する場合に、30秒に1回のサイクルでモバイルネットワークに接続して消費電力の高い、RRC Connected状態に遷移すると想定する。また、インターネットラジオ専用端末は、RRC Connected状態に遷移すると、インターネットラジオ放送の放送コンテンツのリクエスト送信と、放送コンテンツ受信の通信処理を行い、通信処理を終了してから、10秒間はRRC Connected状態を維持し、その後、消費電力の低い、RRC Idle状態に遷移すると想定する。

また、ユーザは、インターネットラジオ放送の放送内容に対して、例えば「好き」や「嫌い」等のフィードバック用の評価を、インターネットラジオ専用端末によって入力し、モバイルネットワークを通じて、放送コンテンツを提供するプロバイダのサーバに送信することができる。

しかしながら、インターネットラジオ専用端末において、通信の接続状態がRRC Idle状態のタイミングで、フィードバックの送信処理を実行すると、通信の接続状態がRRC Idle状態からRRC Connected状態に遷移することになって、RRC Connected状態に留まる時間を増やしてしまい、消費電力を増大させてしまうことになる。また、インターネットラジオ専用端末において、通信の接続状態がRRC Connected状態であっても、RRC Idle状態に遷移する直前に、フィードバックの送信処理を実行すると、やはり、RRC Connected状態に留まる時間を増やしてしまい、消費電力を増大させてしまうことになる。

そこで、本技術を適用したインターネットラジオ専用端末においては、将来発生する通信を予測し、通信の送信要求に対する送信処理を今処理するか、あるいは、遅らせて、次にどのような条件で処理するかを判断する仕組みを提供することで、インターネットラジオ放送の放送コンテンツの通信処理と、フィードバックの通信処理を同時に実行することによる、通信の接続状態がRRC Connected状態に留まる時間を抑制できるようにする。

（インターネットラジオ専用端末の構成例）
図５は、本技術を適用したインターネットラジオ専用端末の機能的な構成例を示す図である。

インターネットラジオ専用端末１０Ａは、モバイルネットワークを通じてインターネットラジオ放送の放送コンテンツを受信可能な携帯型の専用端末である。図５に示すように、インターネットラジオ専用端末１０Ａは、送信要求部１０１、送信要求制御部１０２、遅延判断部１０３、通信予測部１０４、通信接続状態監視部１０５、及び、送信処理部１０６から構成される。

すなわち、インターネットラジオ専用端末１０Ａの構成は、基本的に、図３の通信装置１０と同様の構成とされるが、送信要求部１０１は、ラジオ放送受信アプリケーション１２１及びフィードバックアプリケーション１２２を含んで構成されている。また、インターネットラジオ専用端末１０Ａにおいて、遅延判断部１０３は、判断条件１３１を用いて遅延の判断処理を行い、通信予測部１０４は、予測条件１３２を用いて通信の予測処理を行うことになる。

ラジオ放送受信アプリケーション１２１は、インターネットラジオ放送の放送コンテンツを受信するための専用のアプリケーションである。ラジオ放送受信アプリケーション１２１は、ユーザ操作等に応じて、放送コンテンツのリクエストをするための通信の送信要求を、送信要求制御部１０２に供給する。

フィードバックアプリケーション１２２は、放送コンテンツの内容に対する、例えば、「好き」や「嫌い」等のユーザの評価をフィードバックするためのアプリケーションである。フィードバックアプリケーション１２２は、ユーザ操作に応じて、ユーザの評価をフィードバックするための通信の送信要求を、送信要求制御部１０２に供給する。

送信要求制御部１０２には、ラジオ放送受信アプリケーション１２１からの放送コンテンツのリクエストの通信の送信要求、又は、フィードバックアプリケーション１２２からの評価のフィードバックの通信の送信要求が供給される。送信要求制御部１０２は、放送コンテンツのリクエストの通信の送信要求、又は、評価のフィードバックの通信の送信要求を、送信処理部１０６に供給するに際して、通信の送信要求のフロー制御を行う。

送信要求制御部１０２は、ラジオ放送受信アプリケーション１２１又はフィードバックアプリケーション１２２から通信の送信要求が供給された場合、その送信要求に対する遅延判断を、遅延判断部１０３に問い合わせる。送信要求制御部１０２は、遅延判断部１０３からの処理判断が通知されるまで、その送信要求を滞留させる。送信要求制御部１０２は、遅延判断部１０３からの処理判断が通知された場合、当該処理判断が通知されたタイミングで、滞留（遅延）させていた通信の送信要求を、送信処理部１０６に供給する。

遅延判断部１０３は、送信要求制御部１０２から、通信の送信要求に対する遅延判断の問い合わせを受けた場合、省電力の観点からその送信要求に対する送信処理を今処理するのか、あるいは遅延させて処理するのかを判断する。遅延判断部１０３は、通信の送信要求に対する送信処理を今処理すると判断した場合、そのタイミングで、処理判断を、送信要求制御部１０２に通知する。また、遅延判断部１０３は、通信の送信要求に対する送信処理を遅延させて処理すると判断した場合には、遅延終了条件を確定する。そして、遅延判断部１０３は、遅延の終了条件を満たした場合には、そのタイミングで、処理判断を、送信要求制御部１０２に供給する。

ここで、遅延判断部１０３は、通信予測部１０４から供給される将来の通信予測の結果と、通信接続状態監視部１０５から供給される通信の接続状態の監視結果を用いて判断を行う。また、遅延判断部１０３は、判断条件１３１を用いて判断を行うことができる。

判断条件１３１には、例えば、以下の判断条件が列挙されている。

（１）判断条件１：ラジオ放送受信アプリケーション１２１からの通信の送信要求に対する送信処理は遅延させない。
（２）判断条件２：通信接続状態監視部１０５から取得される通信の接続状態が、RRC Connected状態で、その後6秒以上、RRC Connected状態が継続するのであれば、通信の送信要求に対する送信処理を直ぐに実行する。
（３）判断条件３：通信接続状態監視部１０５から取得される通信の接続状態が、RRC Idle状態で、次の通信予測が4秒後以内であれば、通信の送信要求に対する送信処理を直ぐに実行する。また、次の通信予測が4秒後以降であれば、通信の送信要求に対する送信処理を遅延させる。
（４）判断条件４：フィードバックアプリケーション１２２の最大遅延許容時間は、10秒とする。
（５）判断条件５：通信の送信要求に対する送信処理の遅延中に、通信接続状態監視部１０５から取得される通信の接続状態が、RRC Idle状態からRRC Connected状態に遷移した場合には、直ぐに遅延を終了する。

なお、ここに列挙された判断条件は、判断条件１３１の一例であって、通信の送信要求に対する送信処理を行うタイミングを判断可能な情報であれば、他の判断条件を用いることができる。例えば、判断条件には、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含むようにすることができる。

通信予測部１０４は、将来発生する通信を予測し、その予測の結果を、遅延判断部１０３に供給する。ここで、通信予測部１０４は、遅延判断部１０３による、ラジオ放送受信アプリケーション１２１からの通信の送信要求に対する処理判断を用いて通信の予測を行うことができる。また、通信予測部１０４は、予測条件１３２を用いて通信の予測を行うことができる。

予測条件１３２には、例えば、以下の予測条件が挙げられている。

（１）予測条件１：通信の送信要求の処理判断から11秒間は、通信の接続状態がRRC Connected状態になると仮定する。通信の送信要求の処理判断から11秒以降で、30秒後までは、通信の接続状態がRRC Idle状態となり、30秒後に、再度、RRC Connected状態に遷移するサイクルを繰り返すと仮定する。

なお、ここに挙げた予測条件は、予測条件１３２の一例であって、将来発生する通信を予測可能な情報であれば、他の予測条件を用いることができる。例えば、予測条件には、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含むようにすることができる。

通信接続状態監視部１０５は、通信基地局との接続状態を常に監視し、その監視の結果を、遅延判断部１０３に供給する。この監視処理では、例えば、ある時点においてRRC Idle状態であるか、あるいはRRC Connected状態であるかが監視され、さらに、RRC Connected状態である場合には、その状態がどの時点まで継続するかが監視される。

送信処理部１０６は、送信要求制御部１０２から供給される通信の送信要求を取得して、当該送信要求に応じて送信処理を実行する。

インターネットラジオ専用端末１０Ａは、以上のように構成されるが、図５の構成は機能的な構成の一部を示しているため、実際には、インターネットラジオ放送の再生と、フィードバック用の評価を実現するための機能として、放送コンテンツ再生部や入力部、スピーカ、表示部などが設けられている。

（第１の送信処理）
次に、図６のフローチャートを参照して、図５のインターネットラジオ専用端末１０Ａにより実行される第１の送信処理の流れについて説明する。

ステップＳ２０１において、送信要求部１０１は、ラジオ放送受信アプリケーション１２１又はフィードバックアプリケーション１２２等からの通信の送信要求を、送信要求制御部１０２に伝える。そして、送信要求部１０１からの通信の送信要求が、送信要求制御部１０２に伝えられると、ステップＳ２０２において、送信要求制御部１０２は、その送信要求に対する遅延判断を、遅延判断部１０３に問い合わせる。

ステップＳ２０３において、遅延判断部１０３は、送信要求制御部１０２からの問い合わせに応じて、ラジオ放送受信アプリケーション１２１からの通信の送信要求であるかどうかを判断する。すなわち、ステップＳ２０３の判断処理では、判断条件１３１の判断条件１が用いられている。

ステップＳ２０３において、ラジオ放送受信アプリケーション１２１からの通信の送信要求であると判断された場合、処理は、ステップＳ２０４に進められる。ステップＳ２０４乃至Ｓ２０６においては、図４のステップＳ１０４乃至Ｓ１０６と同様に、送信要求制御部１０２からの通信の送信要求が、送信処理部１０６に伝えられるので、送信処理部１０６は、送信処理を実行することになる。これにより、遅延することなく直ちに、ラジオ放送受信アプリケーション１２１からの送信要求に応じて、送信処理が行われることになる。

一方、ステップＳ２０３において、ラジオ放送受信アプリケーション１２１からの通信の送信要求ではないと判断された場合、処理は、ステップＳ２０７に進められる。ステップＳ２０７において、遅延判断部１０３は、通信接続状態監視部１０５から取得される通信の接続状態に基づいて、接続状態が、RRC Connected状態で、かつ、RRC Connected状態が6秒以上継続するかどうかを判断する。すなわち、ステップＳ２０７の判断処理では、判断条件１３１の判断条件２が用いられている。

ステップＳ２０７において、接続状態が、RRC Connected状態で、かつ、RRC Connected状態が6秒以上継続すると判断された場合、処理は、ステップＳ２０４に進められる。この場合、ステップＳ２０４乃至Ｓ２０６においては、送信要求制御部１０２からの通信の送信要求が、送信処理部１０６に伝えられるので、送信処理部１０６は、通信の送信要求に応じて、送信処理を実行することになる。

また、ステップＳ２０７の判断条件を満たさない場合には、処理は、ステップＳ２０８に進められる。ステップＳ２０８において、遅延判断部１０３は、通信接続状態監視部１０５から取得される通信の接続状態に基づいて、RRC Idle状態で、次の通信が4秒後以内に発生すると予測されるかどうかを判断する。すなわち、ステップＳ２０８の判断処理では、判断条件１３１の判断条件３が用いられている。

ステップＳ２０８において、RRC Idle状態で、次の通信が4秒後以内に発生すると予測される場合、処理は、ステップＳ２０４に進められる。この場合、ステップＳ２０４乃至Ｓ２０６においては、送信要求制御部１０２からの通信の送信要求が、送信処理部１０６に伝えられるので、送信処理部１０６は、通信の送信要求に応じて、送信処理を実行することになる。

また、ステップＳ２０８の判断条件を満たさない場合には、処理は、ステップＳ２０９に進められる。ステップＳ２０９において、遅延判断部１０３は、通信の送信要求がフィードバックアプリケーション１２２から伝えられた場合に、その最大遅延許容時間（10秒）に達したか、あるいは、通信の送信要求に対する送信処理の遅延中に、通信接続状態監視部１０５から取得される通信の接続状態が、RRC Idle状態からRRC Connected状態に遷移したかどうかを判断する。すなわち、ステップＳ２０９の判断処理では、判断条件１３１の判断条件４と判断条件５が用いられている。

ステップＳ２０９において、最大遅延許容時間（10秒）に達したと判断された場合、あるいは、接続状態が、RRC Idle状態からRRC Connected状態に遷移したと判断された場合、処理は、ステップＳ２０４に進められる。この場合、ステップＳ２０４乃至Ｓ２０６においては、送信要求制御部１０２からの通信の送信要求が、送信処理部１０６に伝えられるので、送信処理部１０６は、通信の送信要求に応じて、送信処理を実行することになる。

また、ステップＳ２０９の判断条件を満たさない場合には、ステップＳ２０９の判断処理が繰り返される。そして、ステップＳ２０９の判断条件を満たした場合には、処理は、ステップＳ２０４に進められ、通信の送信要求に対する送信処理が実行されることになる（ステップＳ２０４乃至Ｓ２０６）。

ステップＳ２０６の処理が終了すると、図６の第１の送信処理は終了する。

以上、インターネットラジオ専用端末１０Ａにより実行される第１の送信処理について説明した。この第１の送信処理においては、ラジオ放送受信アプリケーション１２１又はフィードバックアプリケーション１２２等からの通信の送信要求が発生した場合に、遅延判断部１０３によって、判断条件１乃至判断条件５等の判断条件１３１に基づいた判断処理が行われて、当該送信要求に対する送信処理を今処理すべきと判断された場合に送信処理が行われる一方、遅らせて処理すべきと判断された場合には、遅延終了条件を満たすまで、送信処理が遅延されることになる。

例えば、通信の接続状態がRRC Idle状態のタイミングで、フィードバックの送信処理を実行すると、通信の接続状態がRRC Idle状態からRRC Connected状態に遷移することになって、消費電力を増大させてしまうことになるが、このような遅延判断処理が行われることで、RRC Connected状態に留まる時間を可能な限り短くして、無駄な消費電力を低減することができる。

また、例えば、通信の接続状態がRRC Connected状態であっても、RRC Idle状態に遷移する直前に、フィードバックの送信処理を実行すると、やはり、消費電力を増大させてしまうことになるが、このような遅延判断処理が行われることで、RRC Connected状態に留まる時間を可能な限り短くして、無駄な消費電力を低減することができる。

すなわち、このような遅延判断処理が行われることで、通信の応答性を損なうことなく、テイルエナジーの発生を抑制して、無駄な消費電力を低減することができる。また、通信の応答性を損なわないことから、ユーザが通信応答性に不便に感じることはない。さらに、ユーザ操作に制約を与えずに、省電力を実現することができる。

（遅延判断結果とその時点での通信の接続状態の関係）
ここで、図７乃至図１０を参照して、遅延判断部１０３による遅延判断結果とその時点での通信の接続状態の関係を、具体的なケースを例示して説明する。

（１）ケース１
まず、図７のタイミングチャートを参照して、図６のステップＳ２０７の判断処理で、「Yes」と判断されるケースについて説明する。

図７において、図７Ａと、図７Ｃは、ラジオ放送受信アプリケーション１２１からの通信の送信要求と、フィードバックアプリケーション１２２からの通信の送信要求の発生のタイミングを矢印により示している。また、図７Ｂと、図７Ｄはともに、通信の接続状態を表しているが、図７Ｂが現時点での通信の接続状態を表しているのに対して、図７Ｄが遅延判断部１０３による遅延判断処理の結果得られる通信の接続状態を表している点で異なる。また、図７において、時間の方向は、図中の左側から右側に向かう方向とされる。なお、これらの関係は、基本的に後述する他の図でも同様とされる。

図７Ｃに示すように、現時点において、フィードバックアプリケーション１２２による通信の送信要求が発生したとき、図７Ａに示すように、現時点を基準にして、過去となる3秒前に、ラジオ放送受信アプリケーション１２１からの通信の送信要求が発生しており、さらに、27秒後と57秒後にもラジオ放送受信アプリケーション１２１からの通信の送信要求が発生すると予測されている。

また、図７Ｂに示すように、判断条件１３１の判断条件１によって、ラジオ放送受信アプリケーション１２１からの通信の送信要求は遅延させないため、当該送信要求が発生すると、通信の接続状態は、RRC Idle状態からRRC Connectedに遷移する。そして、現時点においては、通信の接続状態は、RRC Connectedで、かつ、RRC Connected状態が6秒以上継続するので、図６のステップＳ２０７の判断処理において、「Yes」と判断されることになる。

その結果、フィードバックアプリケーション１２２からの通信の送信要求に応じて、送信処理を実行することになるが、図７Ｄに示すように、この場合、フィードバックアプリケーション１２２からの通信の送信要求がなかった場合と比べて、RRC Connected状態が3秒だけ長くなるだけで済むと予測されるため、直ぐに処理してもテイルエナジーはそれほど増大しないので、消費電力を低減することができる。

（２）ケース２
次に、図８のタイミングチャートを参照して、図６のステップＳ２０８の判断処理で、「Yes」と判断されるケースについて説明する。

図８Ｃに示すように、現時点において、フィードバックアプリケーション１２２による通信の送信要求が発生したとき、図８Ａに示すように、現時点を基準にして、2秒後と32秒後にラジオ放送受信アプリケーション１２１からの通信の送信要求が発生すると予測されている。

また、図８Ｂに示すように、現時点での通信の接続状態はRRC Idle状態となるが、2秒後にラジオ放送受信アプリケーション１２１からの通信の送信要求が発生して、通信の接続状態がRRC Idle状態からRRC Connected状態に遷移することになるので、図６のステップＳ２０８の判断処理において、「Yes」と判断されることになる。

その結果、フィードバックアプリケーション１２２からの通信の送信要求に応じて、送信処理を実行することになるが、図８Ｄに示すように、この場合、フィードバックアプリケーション１２２からの通信の送信要求がなかった場合と比べて、RRC Connected状態が2秒だけ長くなるだけで済むと予測されるため、直ぐに処理してもテイルエナジーはそれほど増大しないので、消費電力を低減することができる。

（３）ケース３
次に、図９のタイミングチャートを参照して、図６のステップＳ２０９の判断処理で、「Yes」と判断されるケースについて説明する。

図９Ｃに示すように、現時点においてフィードバックアプリケーション１２２による通信の送信要求が発生したとき、図９Ａに示すように、現時点を基準にして、過去となる16秒前に、ラジオ放送受信アプリケーション１２１からの通信の送信要求が発生しており、さらに、14秒後と44秒後にもラジオ放送受信アプリケーション１２１からの通信の送信要求が発生すると予測されている。

また、図９Ｂに示すように、現時点での通信の接続状態はRRC Idle状態であって、通信の接続状態がRRC Connected状態に遷移するのは、ラジオ放送受信アプリケーション１２１からの通信の送信要求が発生する14秒後であると予測される。また、判断条件１３１に、判断条件４として列挙されているように、フィードバックアプリケーション１２２の最大遅延許容時間は10秒とされている。

すなわち、この場合、フィードバックアプリケーション１２２からの通信の送信要求に応じた送信処理を直ぐには実行せず、図６のステップＳ２０９の判断条件を満たすまで、ステップＳ２０９のループが繰り返される。そして、図９Ｄに示すように、通信の接続状態がRRC Idle状態からRRC Connected状態に遷移する14秒後よりも先に、フィードバックアプリケーション１２２の最大遅延許容時間である10秒後に達するので、その時点で、遅延させていた通信の送信要求に応じて、送信処理を実行する。

この場合、図９Ｅに示すように、フィードバックアプリケーション１２２からの通信の送信要求がなかった場合と比べて、RRC Connected状態が4秒だけ長くなるだけで済むと予測されるため、テイルエナジーはそれほど増大しないので、消費電力を低減することができる。

（４）ケース４
最後に、図１０のタイミングチャートを参照して、図６のステップＳ２０９の判断処理で、「Yes」と判断される他のケースについて説明する。

図１０Ｃに示すように、現時点においてフィードバックアプリケーション１２２による通信の送信要求が発生したとき、図１０Ａに示すように、現時点を基準にして、過去となる10秒前に、ラジオ放送受信アプリケーション１２１からの通信の送信要求が発生しており、さらに、20秒後と50秒後にもラジオ放送受信アプリケーション１２１からの通信の送信要求が発生すると予測されている。

また、図１０Ｂに示すように、現時点での通信の接続状態はRRC Connected状態であるが、RRC Connected状態は6秒以上継続せず、次に、通信の接続状態がRRC Connected状態に遷移するのは、ラジオ放送受信アプリケーション１２１からの通信の送信要求が発生する20秒後であると予測される。つまり、次の通信予測が4秒後以内でもない。また、判断条件１３１に、判断条件４として列挙されているように、フィードバックアプリケーション１２２の最大遅延許容時間は10秒とされる。

すなわち、この場合、フィードバックアプリケーション１２２からの通信の送信要求に応じた送信処理を直ぐには実行せず、図６のステップＳ２０９の判断条件を満たすまで、ステップＳ２０９のループが繰り返される。そして、図１０Ｄに示すように、通信の接続状態がRRC Idle状態からRRC Connected状態に遷移する20秒後よりも先に、フィードバックアプリケーション１２２の最大遅延許容時間である10秒後に達するので、その時点で、遅延させていた通信の送信要求に応じて、送信処理を実行する。

この場合、図１０Ｅに示すように、フィードバックアプリケーション１２２からの通信の送信要求がなかった場合と比べて、RRC Connected状態が10秒だけ長くなってしまうが、フィードバックアプリケーション１２２の最大遅延許容時間をキープすることができるので、例えば、インターネットラジオ放送の放送内容に対する「好き」や「嫌い」等の評価を、最大限許容できる遅延時間内で、プロバイダのサーバに送信することができる。つまり、この場合、通信の応答性を損なわないことから、ユーザが通信応答性に不便に感じることはない。

＜４．第２の実施の形態＞

次に、第２の実施の形態においては、本技術を適用した通信装置として、複数のアプリケーションを実行するスマートフォンについて説明する。

ところで、従来のスマートフォンでは、複数のアプリケーションが通信の接続状態に関係なく、通信の送信要求を発生させることから、通信の送信要求の度に送信処理を実行してしまうと、通信の接続状態が、RRC Idle状態からRRC Connected状態に遷移し、パケット（データ）の送受信を終えた後、しばらくの間、パケットの送受信を行っていないにもかかわらず、RRC Connected状態を維持してしまうという状況が高い頻度で発生する可能性があった。このような場合に、RRC Connected状態を維持すると、RRC Connected状態における消費電力の多くが無駄な消費電力となってしまう。

そこで、本技術を適用したスマートフォンにおいては、将来発生する通信を予測し、通信の送信要求に対する送信処理を今処理するか、あるいは、遅らせて、次にどのような条件で処理するかを判断する仕組みを提供することで、複数のアプリケーションで行われる通信処理が、なるべく近いタイミングで実行されるようにする。その結果、RRC Connected状態を維持することによる無駄な消費電力を抑制することができる。また、本技術を適用したスマートフォンにおいては、履歴の学習によって、さらなる省電力通信を実現できるようにする。

（スマートフォンの構成例）
図１１は、本技術を適用したスマートフォンの機能的な構成例を示す図である。

スマートフォン１０Ｂは、モバイルネットワークを通じて各種のサービスを提供するサーバ等との間で、パケット（データ）の送受信を行うことが可能な携帯通信端末である。図１１に示すように、スマートフォン１０Ｂは、送信要求部１０１、送信要求制御部１０２、遅延判断部１０３、通信予測部１０４、送信処理部１０６、状態監視部１０７、履歴保持部１０８、判断条件学習部１０９、及び、予測条件学習部１１０から構成される。

すなわち、スマートフォン１０Ｂは、基本的に、図３の通信装置１０と同様の構成とされるが、送信要求部１０１は、アプリケーション１４１−１乃至１４１−Ｎを含んで構成される。また、スマートフォン１０Ｂにおいては、図３の通信接続状態監視部１０５の代わりに、状態監視部１０７が設けられ、さらに、履歴保持部１０８、判断条件学習部１０９、及び、予測条件学習部１１０が新たに設けられている。さらにまた、スマートフォン１０Ｂにおいて、遅延判断部１０３は、判断条件１５１を用いて遅延の判断処理を行い、通信予測部１０４は、予測条件１５２を用いて通信の予測処理を行うことになる。

アプリケーション１４１−１乃至１４１−Ｎ（Ｎは１以上の整数）は、スマートフォン１０Ｂが実行可能な各種のアプリケーションである。アプリケーション１４１−１乃至１４１−Ｎは、ユーザ操作等に応じて、通信の送信要求を、送信要求制御部１０２に供給する。

なお、アプリケーション１４１−１乃至１４１−Ｎは、スマートフォン１０Ｂにあらかじめインストールされているか、あるいは、モバイルネットワークを通じて各種のサービスを提供する専用のサーバからダウンロードされる。また、以下、アプリケーション１４１−１乃至１４１−Ｎを区別する必要がない場合、単に、アプリケーション１４１と称して説明する。

送信要求制御部１０２は、アプリケーション１４１からの通信の送信要求を、送信処理部１０６に供給するに際して、通信の送信要求のフロー制御を行う。すなわち、送信要求制御部１０２は、アプリケーション１４１から通信の送信要求が供給された場合、その送信要求に対する遅延判断を、遅延判断部１０３に問い合わせる。送信要求制御部１０２は、遅延判断部１０３からの処理判断が通知されるまで、その送信要求を滞留させる。送信要求制御部１０２は、遅延判断部１０３からの処理判断が通知された場合、当該処理判断が通知されたタイミングで、滞留（遅延）させていた通信の送信要求を、送信処理部１０６に供給する。

送信処理部１０６は、送信要求制御部１０２から供給される通信の送信要求を取得して、当該送信要求に応じて送信処理を実行する。

遅延判断部１０３は、送信要求制御部１０２から、通信の送信要求に対する遅延判断の問い合わせを受けた場合、省電力の観点からその送信要求に対する送信処理を今処理するのか、あるいは遅延させて処理するのかを判断する。遅延判断部１０３は、通信の送信要求に対する送信処理を今処理すると判断した場合、そのタイミングで、処理判断を、送信要求制御部１０２に通知する。また、遅延判断部１０３は、通信の送信要求に対する送信処理を遅延させて処理すると判断した場合には、遅延終了条件を確定する。そして、遅延判断部１０３は、遅延終了条件を満たした場合には、そのタイミングで、処理判断を、送信要求制御部１０２に供給する。

ここで、遅延判断部１０３は、通信予測部１０４から供給される将来の通信予測の結果と、状態監視部１０７から供給される各種の状態の監視結果を用いて判断を行う。なお、各種の状態の監視結果には、通信の状態（例えば通信の接続状態）、アプリケーション１４１の状態、ユーザの視線、及び、現在位置、定義情報等のスマートフォン１０Ｂやそのユーザに関する各種の状態に関する情報が含まれる。また、遅延判断部１０３は、判断条件１５１を用いて判断を行うことができる。

判断条件１５１には、例えば、以下の判断条件が列挙されている。

（１）判断条件６：特定のアプリケーション１４１（例えば、アプリケーション１４１−１）からの通信の送信要求に対する送信処理は、次の通信予測が3秒以内ならば直ぐに送信し、3秒を超える場合には遅延させる。
（２）判断条件７：スマートフォン１０Ｂの表示部（不図示）の画面を、ユーザが見ていないことが検知された場合には、最大遅延許容時間を、1分まで引き延ばす。
（３）判断条件８：特定の場所で通信を実行するアプリケーション１４１が複数ある場合に、それらのアプリケーション１４１（例えば、アプリケーション１４１−２乃至１４１−４）をグルーピングし、ユーザが特定の場所に来たときには、グルーピングされたすべてのアプリケーション１４１のリクエストの準備ができるまで、その通信の送信要求に対する送信処理を遅延させる。
（４）判断条件９：画像データのリクエストの通信の送信要求は、最大遅延許容時間を10秒とする。
（５）判断条件１０：特定のアプリケーション１４１（例えば、アプリケーション１４１−４）からの通信の送信要求に対する送信処理は遅延させない。
（６）判断条件１１：状態監視部１０７から取得される通信の接続状態が、RRC Connected状態で、その後6秒以上、RRC Connected状態が継続するのであれば、通信の送信要求に対する送信処理を直ぐに実行する。
（７）判断条件１２：状態監視部１０７から取得される通信の接続状態が、RRC Idle状態で、次の通信予測が4秒後以内であれば、通信の送信要求に対する送信処理を直ぐに実行する。また、次の通信予測が4秒後以降であれば、通信の送信要求に対する送信処理を遅延させる。
（８）判断条件１３：特定のアプリケーション１４１（例えば、アプリケーション１４１−５）の最大遅延許容時間は、10秒とする。
（９）判断条件１４：通信の送信要求に対する送信処理の遅延中に、状態監視部１０７から取得される通信の接続状態が、RRC Idle状態からRRC Connected状態に遷移した場合には、直ぐに遅延を終了する。

なお、ここに列挙された判断条件は、判断条件１５１の一例であって、通信の送信要求に対する送信処理を行うタイミングを判断可能な情報であれば、他の判断条件を用いることができる。例えば、判断条件には、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含むようにすることができる。

例えば、判断条件６では、判断条件の時間を3秒としたが、例えば5秒など、アプリケーション１４１ごとに異なる判断条件を保持しておくことができる。また、判断条件７の引き延ばし時間は、1分に限らず、30秒など、アプリケーション１４１ごとに異なる判断条件を保持しておくことができる。さらに、判断条件７のユーザが画面を見ていないことを検知する方法としては、視線センサ等によるセンシング情報やユーザの行動の認識情報などを用いることができる。

また、例えば、判断条件８では、ユーザが特定の場所に来たかどうかは、GPS(Global Positioning System)などの位置情報を用いて判断することができる。また、複数のアプリケーションをグルーピングする条件は、特定の場所で通信を実行することに限らず、他の条件を用いてもよい。さらに、判断条件９において、画像データはデータの種別の一例であって、画像データのほか、例えばテキストや音声データなど、データの種別ごとに、最大遅延許容保持時間を保持しておくことができる。

通信予測部１０４は、状態監視部１０７から供給される各種の状態の監視結果を用いて、将来発生する通信の予測を行う。ここで、各種の状態の監視結果には、通信の状態（例えば通信の接続状態）、アプリケーション１４１の状態、ユーザの視線、及び、現在位置、定義情報等のスマートフォン１０Ｂやそのユーザに関する各種の状態に関する情報が含まれる。また、通信予測部１０４は、予測条件１５２を用いて通信の予測を行うことができる。

予測条件１５２には、例えば、以下の予測条件が列挙されている。

（１）予測条件２：特定のアプリケーション（例えば、アプリケーション１４１−２）において、その状態が状態Ａである場合、通信パターンＡ１、通信パターンＡ２、又は、通信パターンＡ３のいずれかの通信パターンが発生し、その状態が状態Ｂである場合には、通信パターンＢ１、通信パターンＢ２、又は、通信パターンＢ３のいずれかの通信パターンが発生すると仮定する。
（２）予測条件３：現在の時間は、モバイルネットワークを通じてリクエストを送信した特定のサーバからのレスポンスには、3秒かかると仮定する。

なお、ここに列挙された予測条件は、予測条件１５２の一例であって、将来発生する通信を予測可能な情報であれば、他の予測条件を用いることができる。例えば、予測条件には、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含むようにすることができる。

例えば、予測条件２では、特定のアプリケーション１４１の状態に応じた通信パターンを一例に説明したが、他のアプリケーション１４１についても同様に、状態に応じた通信パターンを予測条件とすることができる。つまり、アプリケーション１４１ごとに、予測条件を保持することができる。また、例えば、予測条件３では、現在の時間において、特定のサーバからのレスポンスは3秒かかるとしたが、このレスポンスにかかる時間は時間帯ごとに変動するものである。つまり、時間帯ごとに変動する予測条件を保持することができる。

状態監視部１０７は、通信の状態（例えば通信の接続状態）、アプリケーション１４１の状態、ユーザの視線、及び、現在位置等のスマートフォン１０Ｂやそのユーザに関する各種の状態を常に監視し、その監視の結果を、遅延判断部１０３、通信予測部１０４、及び、履歴保持部１０８に供給する。例えば、ユーザの視線情報は、視線センサ等によるセンシング情報により得られる。また、現在位置は、GPSなどの位置情報から得られる。

履歴保持部１０８は、状態監視部１０７から供給される各種の状態の監視結果を、履歴情報として時系列で保持する。履歴保持部１０８は、判断条件学習部１０９又は予測条件学習部１１０からの要求に応じて、保持している履歴情報を、判断条件学習部１０９又は予測条件学習部１１０に供給する。

判断条件学習部１０９は、履歴保持部１０８から供給される履歴情報に基づいて、現時点での判断条件１５１の内容とは別の判断条件を用いた場合に、より省電力となるかどうかを解析して学習する。判断条件学習部１０９は、判断条件の解析結果に従い、現時点での判断条件１５１の内容とは別の判断条件を用いた場合に、より省電力になるとの解析結果が得られたときには、判断条件１５１の内容を、別の判断条件の内容に更新する。

予測条件学習部１１０は、履歴保持部１０８から供給される履歴情報に基づいて、各種の状態の監視結果についての履歴の統計を取って、これまでの予測条件がもっとも起こりうるパターンであったかどうかを解析して学習する。予測条件学習部１１０は、予測条件の解析結果に従い、必要に応じて、予測条件１５２の内容を、別の予測条件の内容に更新する。

スマートフォン１０Ｂは、以上のように構成されるが、図１１の構成は機能的な構成の一部を示しているため、実際には、例えば音声通話や画像撮影などを実現するための機能として、音声通話部やカメラ部、入力部、スピーカ、表示部などが設けられる。

また、図１１の構成では、履歴保持部１０８、判断条件学習部１０９、及び、予測条件学習部１１０は、スマートフォン１０Ｂの内部に設けられるとして説明したが、例えば、履歴保持部１０８、判断条件学習部１０９、及び、予測条件学習部１１０の機能の一部又は全部を外部のサーバに設けるようにしてもよい。

この場合、例えば、スマートフォン１０Ｂにおいて、状態監視部１０７により取得される各種の状態の監視結果が、モバイルネットワークを通じて外部のサーバに記録され、更新用の判断条件や予測条件は、所定の更新のタイミングで、外部のサーバから取得されることになる。また、外部のサーバは、スマートフォン１０Ｂについての履歴情報だけでなく、例えば他のスマートフォンについての履歴情報も管理することで、複数のスマートフォンから得られる履歴情報をまとめて学習して、最適な判断条件や予測条件を提供できるようにしてもよい。

（第２の送信処理）
次に、図１２のフローチャートを参照して、図１１のスマートフォン１０Ｂにより実行される第２の送信処理の流れについて説明する。

ステップＳ３０１において、送信要求部１０１は、アプリケーション１４１からの通信の送信要求を、送信要求制御部１０２に伝える。そして、送信要求部１０１からの通信の送信要求が、送信要求制御部１０２に伝えられると、ステップＳ３０２において、送信要求制御部１０２は、その送信要求に対する遅延判断を、遅延判断部１０３に問い合わせる。

ステップＳ３０３において、遅延判断部１０３は、送信要求制御部１０２からの問い合わせに応じて、特定のアプリケーション１４１からの通信の送信要求であるかどうかを判断する。すなわち、ステップＳ３０３の判断処理では、判断条件１５１の判断条件１０が用いられている。

ステップＳ３０３において、特定のアプリケーション１４１からの通信の送信要求であると判断された場合、処理は、ステップＳ３０４に進められる。ステップＳ３０４乃至Ｓ３０６においては、図４のステップＳ１０４乃至Ｓ１０６と同様に、送信要求制御部１０２からの送信要求が、送信処理部１０６に伝えられるので、送信処理部１０６は、送信処理を実行することになる。これにより、遅延することなく直ちに、特定のアプリケーション１４１からの要求に応じて、送信処理が行われることになる。

一方、ステップＳ３０３において、特定のアプリケーション１４１からの通信の送信要求ではないと判断された場合、処理は、ステップＳ３０７に進められる。ステップＳ３０７において、遅延判断部１０３は、状態監視部１０７から取得される通信の接続状態に基づいて、接続状態が、RRC Connected状態で、かつ、RRC Connected状態が6秒以上継続するかどうかを判断する。すなわち、ステップＳ３０７の判断処理では、判断条件１５１の判断条件１１が用いられている。

ステップＳ３０７において、接続状態が、RRC Connected状態で、かつ、RRC Connected状態が6秒以上継続すると判断された場合、処理は、ステップＳ３０４に進められる。この場合、ステップＳ３０４乃至Ｓ３０６においては、送信要求制御部１０２からの通信の送信要求が、送信処理部１０６に伝えられるので、送信処理部１０６は、通信の送信要求に応じて、送信処理を実行することになる。

また、ステップＳ３０７の判断条件を満たさない場合には、処理は、ステップＳ３０８に進められる。ステップＳ３０８において、遅延判断部１０３は、状態監視部１０７から取得される通信の接続状態に基づいて、RRC Idle状態で、次の通信が4秒後以内に発生すると予測されるかどうかを判断する。すなわち、ステップＳ３０８の判断処理では、判断条件１５１の判断条件１２が用いられている。

ステップＳ３０８において、RRC Idle状態で、次の通信が4秒後以内に発生すると予測される場合、処理は、ステップＳ３０４に進められる。この場合、ステップＳ３０４乃至Ｓ３０６においては、送信要求制御部１０２からの通信の送信要求が、送信処理部１０６に伝えられるので、送信処理部１０６は、通信の送信要求に応じて、送信処理を実行することになる。

また、ステップＳ３０８の判断条件を満たさない場合には、処理は、ステップＳ３０９に進められる。ステップＳ３０９において、遅延判断部１０３は、通信の送信要求が特定のアプリケーション１４１から伝えられた場合に、その最大遅延許容時間（10秒）に達したか、あるいは、通信の送信要求に対する送信処理の遅延中に、状態監視部１０７から取得される通信の接続状態が、RRC Idle状態からRRC Connected状態に遷移したかどうかを判断する。すなわち、ステップＳ３０９の判断処理では、判断条件１５１の判断条件１３と判断条件１４が用いられている。

ステップＳ３０９において、最大遅延許容時間（10秒）に達したと判断された場合、あるいは、接続状態が、RRC Idle状態からRRC Connected状態に遷移したと判断された場合、処理は、ステップＳ３０４に進められる。この場合、ステップＳ３０４乃至Ｓ３０６においては、送信要求制御部１０２からの通信の送信要求が、送信処理部１０６に伝えられるので、送信処理部１０６は、通信の送信要求に応じて、送信処理を実行することになる。

また、ステップＳ３０９の判断条件を満たさない場合には、ステップＳ３０９の判断処理が繰り返される。そして、ステップＳ３０９の判断条件を満たした場合には、処理は、ステップＳ３０４に進められ、通信の送信要求に対する送信処理が実行されることになる（ステップＳ３０４乃至Ｓ３０６）。

なお、図１２の第２の送信処理においては、ステップＳ３０３，Ｓ３０７，Ｓ３０８，Ｓ３０９の判断処理において、判断条件１５１の判断条件１０乃至１４が用いられる例を説明したが、他の判断条件が用いられるようにしてもよい。例えば、遅延判断部１０３は、判断条件１５１の判断条件６を用いて、特定のアプリケーション１４１からの通信の送信要求である場合には、次の通信予測が3秒以内であるかどうかを判断することができる。これにより、次の通信予測が3秒以内ならば直ぐに送信処理を実行する一方、3秒を超える場合には送信処理を遅延させることができる。

また、遅延判断部１０３は、判断条件１５１の判断条件７を用いて、スマートフォン１０Ｂの表示部（不図示）の画面を、ユーザが見ていないことが検知された場合に、引き延ばされた最大遅延許容時間（例えば1分）に達したかどうかを判断することができる。これにより、当該最大遅延許容時間に達したと判断された場合には、遅延させていた送信処理を実行させることができる。

さらに、遅延判断部１０３は、判断条件１５１の判断条件８を用いて、特定の場所で通信を実行するアプリケーション１４１が複数ある場合に、ユーザの現在位置がその特定の場所の範囲内にあって、かつ、グルーピングされた複数のアプリケーション１４１のすべてのリクエストの準備ができたかどうかを判断することができる。そして、ユーザの現在位置が特定の場所の範囲内にあって、かつ、グルーピングされた複数のアプリケーションのすべてのリクエストが準備できたと判断された場合には、遅延させていた送信処理を実行させることができる。

さらにまた、遅延判断部１０３は、判断条件１５１の判断条件９を用いて、画像データのリクエストの通信の送信要求が伝えられた場合に、最大遅延許容時間（例えば10秒）に達したかどうかを判断することができる。これにより、画像データのリクエストの通信の送信要求が伝えられた場合に、最大遅延許容時間に達したと判断された場合には、遅延させていた送信処理を実行させることができる。

ステップＳ３０６の処理が終了すると、図１２の第２の送信処理は終了する。

以上、スマートフォン１０Ｂにより実行される第２の送信処理について説明した。この第２の送信処理においては、複数のアプリケーション１４１−１乃至１４１−Ｎからの通信の送信要求が発生した場合に、遅延判断部１０３によって、判断条件６乃至判断条件１４等の判断条件１５１に基づいた判断処理が行われて、当該送信要求に対する送信処理を今処理すべきと判断された場合に送信処理が行われる一方、遅らせて処理すべきと判断された場合には、遅延終了条件を満たすまで、送信処理が遅延されることになる。

例えば、通信の接続状態がRRC Idle状態のタイミングで、特定のアプリケーション１４１からの通信の送信要求に対する送信処理を実行すると、通信の接続状態がRRC Idle状態からRRC Connected状態に遷移することになって、消費電力を増大させてしまうことになるが、このような遅延判断処理が行われることで、RRC Connected状態に留まる時間を可能な限り短くして、無駄な消費電力を低減することができる。

また、例えば、通信の接続状態がRRC Connected状態であっても、RRC Idle状態に遷移する直前に、通信の送信要求に対する送信処理を実行すると、やはり、消費電力を増大させてしまうことになるが、このような遅延判断処理が行われることで、RRC Connected状態に留まる時間を可能な限り短くして、無駄な消費電力を低減することができる。

すなわち、このような遅延判断処理が行われることで、通信の応答性を損なうことなく、テイルエナジーの発生を抑制して、消費電力を低減することができる。また、通信の応答性を損なわないことから、ユーザが通信応答性に不便に感じることはない。さらに、ユーザ操作に制約を与えずに、省電力を実現することができる。

（判断条件更新処理）
次に、図１３のフローチャートを参照して、判断条件学習部１０９が履歴情報を用いた学習を行った結果、判断条件１５１の内容を更新する際に実行される判断条件更新処理の流れについて説明する。なお、この判断条件更新処理は、例えばユーザの設定などに応じて定期的に繰り返し実行される。

ステップＳ３４１において、判断条件学習部１０９は、履歴保持部１０８から、判断条件１５１に含まれる特定の判断条件（例えば、判断条件６乃至判断条件１４など）に関する履歴情報を取り出す。

ステップＳ３４２において、判断条件学習部１０９は、ステップＳ３４１の処理で取り出した履歴情報に基づいて、特定の判断条件について、閾値のパラメータを少し大きくした場合と、小さくした場合を想定し、閾値のパラメータを少し大きくした場合と、小さくした場合とで、現在の閾値よりも省電力となるケースが多いか、あるいは少ないかを判断する。

ステップＳ３４２において、閾値を変更した場合に、省電力となるケースが多いと判断された場合、処理は、ステップＳ３４３に進められる。ステップＳ３４３において、判断条件学習部１０９は、省電力となるケースが多い閾値で、判断条件１５１に含まれる特定の判断条件（例えば、判断条件６乃至判断条件１４など）を更新する。ステップＳ３４３の処理が終了すると、図１３の判断条件更新処理は終了する。

一方、ステップＳ３４２において、特定の判断条件についての閾値の変更と、省電力の因果関係が不明であると判断された場合、ステップＳ３４３の処理はスキップされ、図１３の判断条件更新処理は終了する。この場合、判断条件１５１に含まれる特定の判断条件は更新されないことになる。

以上、スマートフォン１０Ｂにより実行される判断条件更新処理について説明した。この判断条件更新処理においては、定期的に判断条件１５１に含まれる判断条件の内容を最適な内容に更新できるので、遅延判断部１０３による遅延判断処理の精度を向上させることになり、結果としてさらなる省電力通信を実現することができる。

（予測条件更新処理）
次に、図１４のフローチャートを参照して、予測条件学習部１１０が履歴情報を用いた学習を行った結果、予測条件１５２の内容を更新する際に実行される予測条件更新処理の流れについて説明する。なお、この予測条件更新処理は、例えばユーザの設定などに応じて定期的に繰り返し実行される。

ステップＳ３８１において、予測条件学習部１１０は、履歴保持部１０８から、予測条件１５２に含まれる特定の予測条件（例えば、予測条件２乃至予測条件３など）に関する履歴情報を取り出す。

ステップＳ３８２において、予測条件学習部１１０は、ステップＳ３８１の処理で取り出した履歴情報に基づいて、特定の予測条件について、通信結果の統計を取り、これまでの予測条件が、最も起こりうる通信発生パターンであったかどうかを判断する。

ステップＳ３８２において、これまでの予測条件が、最も起こりうる通信発生パターンではなかったと判断された場合、処理は、ステップＳ３８３に進められる。ステップＳ３８３において、予測条件学習部１１０は、最も起こりうる通信発生パターンで、予測条件１５２に含まれる特定の予測条件（例えば、予測条件２乃至予測条件３など）を更新する。ステップＳ３８３の処理が終了すると、図１４の予測条件更新処理は終了する。

一方、ステップＳ３８２において、最も起こりうる通信発生パターンであると判断された場合、ステップＳ３８３の処理はスキップされ、図１４の予測条件更新処理は終了する。この場合、予測条件１５２に含まれる特定の予測条件は更新されないことになる。

以上、スマートフォン１０Ｂにより実行される予測条件更新処理について説明した。この予測条件更新処理においては、定期的に予測条件１５２に含まれる予測条件の内容を最適な内容に更新できるので、遅延判断部１０３による遅延判断処理の精度を向上させることになり、結果としてさらなる省電力通信を実現することができる。

＜５．第３の実施の形態＞

最後に、第３の実施の形態においては、本技術を適用した通信装置として、ソーシャルネットワーキングサービスを利用するためのアプリケーション（以下、「SNSアプリケーション」という。）を実行するスマートフォンについて説明する。

近年、インターネット上の交流を通して社会的なネットワークを構築する、ソーシャルネットワーキングサービス(SNS：Social Networking Service)が普及している。この種のサービスを利用するためのSNSアプリケーションが、スマートフォン等の携帯通信端末向けにも提供されている。

ここで、スマートフォンにおいて、SNSアプリケーションを実行し、例えば友人の最新の投稿から過去の投稿までを閲覧するに際して、ユーザが、スクロール操作を行う場合を想定する。SNSアプリケーションを使用するユーザが、どれだけ過去の投稿に遡って投稿を閲覧するかは、SNSアプリケーションにとっては未知であること、また、友人の最新の投稿から過去のすべての投稿を一度に取得するには、膨大な通信量が必要となることから、この種のSNSアプリケーションでは、ユーザがスクロール操作を行う度に、一定量の先読み通信を行うことが想定される。この先読み通信によって、ユーザがスクロール操作を行うと、直ぐに過去の投稿などの情報が表示されるという利便性と、通信量の抑制を両立させることを実現している。

しかしながら、従来のスマートフォンでは、通信の接続状態や今後の通信に関係なく、ユーザによるスクロール操作に合わせて通信の送信要求を発生させていたことから、スクロール操作の度に、テイルエナジーが発生し、無駄に電力を消費してしまう可能性があった。また、スマートフォンでは、例えば新着メッセージの定期確認用のアプリケーション（以下、「メッセージ確認アプリケーション」という。）や、ユーザが特定の場所にいることを定期的にクラウド上の地図を管理する専用のサーバに記録するアプリケーション（以下、「位置記録確認アプリケーション」という。）など、他のアプリケーションが同時に実行されていることがあり、それらのアプリケーションが別個に通信の送信要求を発生させると、それぞれテイルエナジーが発生し、電力を無駄に消費してしまうことになる。

そこで、本技術を適用したスマートフォンにおいては、将来発生する通信を予測し、通信の送信要求に対する送信処理を今処理するか、あるいは、遅らせて、次にどのような条件で処理するかを判断する仕組みを提供することで、SNSアプリケーションのスクロール操作に応じた通信と、メッセージ確認アプリケーションや位置記録確認アプリケーション等の他のアプリケーションによる複数の通信を時間的に近いタイミングで処理することができるようにする。その結果、テイルエナジーの発生を抑制することができる。

（スマートフォンの構成例）
図１５は、本技術を適用したスマートフォンの機能的な構成例を示す図である。

スマートフォン１０Ｃは、モバイルネットワークを通じて各種のサービスを提供するサーバ等との間で、パケット（データ）の送受信を行うことが可能な携帯通信端末である。図１５に示すように、スマートフォン１０Ｃは、送信要求部１０１、送信要求制御部１０２、遅延判断部１０３、通信予測部１０４、通信接続状態監視部１０５、送信処理部１０６、及び、SNSアプリ動作状態監視部１１１から構成される。

すなわち、スマートフォン１０Ｃは、基本的に、図３の通信装置１０と同様の構成とされるが、送信要求部１０１は、SNSアプリケーション１６１と、アプリケーション１６２−１乃至１６２−Ｍを含んで構成される。また、SNSアプリ動作状態監視部１１１が新たに設けられている。さらにまた、スマートフォン１０Ｃにおいて、遅延判断部１０３は、判断条件１７１を用いて遅延の判断処理を行い、通信予測部１０４は、予測条件１７２を用いて通信の予測処理を行うことになる。

SNSアプリケーション１６１は、SNSサービスを利用するためのアプリケーションである。SNSアプリケーション１６１は、ユーザ操作等に応じて、通信の送信要求を、送信要求制御部１０２に供給する。また、SNSアプリケーション１６１は、友人の最新の投稿から過去の投稿までを、ユーザがスクロール操作によって閲覧する際に、スクロール操作の度に、一定量の先読み通信を行う機能を有している。

アプリケーション１６２−１乃至１６２−Ｍ（Ｍは１以上の整数）は、スマートフォン１０Ｃが実行可能な各種のアプリケーションである。アプリケーション１６２−１乃至１６２−Ｍは、ユーザ操作等に応じて、通信の送信要求を、送信要求制御部１０２に供給する。

ここでは、アプリケーション１６２−１は、新着メッセージを2分に1回の周期で確認する機能を有するメッセージ確認アプリケーション１６２−１であるとして説明する。また、アプリケーション１６２−２は、スマートフォン１０Ｃの所在する場所を示す位置情報を、5分に1回の周期でクラウド上の地図を管理する専用のサーバに通知する位置記録確認アプリケーション１６２−２であるとして説明する。

なお、SNSアプリケーション１６１、メッセージ確認アプリケーション１６２−１、及び、位置記録確認アプリケーション１６２−２は、スマートフォン１０Ｃにあらかじめインストールされているか、あるいは、モバイルネットワークを通じて各種のサービスを提供する専用のサーバからダウンロードされる。また、以下、メッセージ確認アプリケーション１６２−１と、位置記録確認アプリケーション１６２−２と、アプリケーション１６２−３乃至１６２−Ｍを区別する必要がない場合、単に、アプリケーション１６２と称して説明する。

送信要求制御部１０２は、SNSアプリケーション１６１又はアプリケーション１６２からの通信の送信要求を送信処理部１０６に供給するに際して、通信の送信要求のフロー制御を行う。すなわち、送信要求制御部１０２は、SNSアプリケーション１６１又はアプリケーション１６２から通信の送信要求が供給された場合、その送信要求に対する遅延判断を、遅延判断部１０３に問い合わせる。送信要求制御部１０２は、遅延判断部１０３からの処理判断が通知されるまで、その送信要求を滞留させる。送信要求制御部１０２は、遅延判断部１０３からの処理判断が通知された場合、当該処理判断が通知されたタイミングで、滞留（遅延）させていた送信要求を、送信処理部１０６に供給する。

送信処理部１０６は、送信要求制御部１０２から供給される通信の送信要求を取得して、当該送信要求に応じて送信処理を実行する。

遅延判断部１０３は、送信要求制御部１０２から、通信の送信要求に対する遅延判断の問い合わせを受けた場合、省電力の観点からその送信要求に対する送信処理を今処理するのか、あるいは遅延させて処理するのかを判断する。遅延判断部１０３は、通信の送信要求に対する送信処理を今処理すると判断した場合、そのタイミングで、処理判断を、送信要求制御部１０２に通知する。また、遅延判断部１０３は、通信の送信要求に対する送信処理を遅延させて処理すると判断した場合には、遅延終了条件を確定する。そして、遅延判断部１０３は、遅延終了条件を満たした場合には、そのタイミングで、処理判断を、送信要求制御部１０２に供給する。

ここで、遅延判断部１０３は、通信予測部１０４から供給される将来の通信予測の結果と、通信接続状態監視部１０５から供給される通信の接続状態の監視結果を用いて判断を行う。また、遅延判断部１０３は、判断条件１７１を用いて判断を行うことができる。

判断条件１７１には、例えば、以下の判断条件が列挙されている。

（１）判断条件１５：SNSアプリケーション１６１からの通信の送信要求に対する送信処理は、次の通信予測が3秒以内ならば直ぐに送信し、3秒を超える場合には遅延させる。ただし、画像データのリクエストの通信の送信要求は、最大遅延許容時間を10秒とし、その他のデータのリクエストの通信の送信要求は、最大遅延許容時間を5秒とする。
（２）判断条件１６：メッセージ確認アプリケーション１６２−１からの通信の送信要求に対する送信処理は遅延させない。
（３）判断条件１７：位置記録確認アプリケーション１６２−２からの通信の送信要求に対する送信処理は、次の通信予測が2秒以内ならば直ぐに送信し、2秒を超える場合には遅延させる。ただし、最大遅延許容時間は1分とする。
（４）判断条件１８：通信接続状態監視部１０５から取得される通信の接続状態が、RRC Connected状態で、その後6秒以上、RRC Connected状態が継続するのであれば、通信の送信要求に対する送信処理を直ぐに実行する。
（５）判断条件１９：通信接続状態監視部１０５から取得される通信の接続状態が、RRC Idle状態で、次の通信予測が4秒後以内であれば、通信の送信要求に対する送信処理を直ぐに実行する。また、次の通信予測が4秒後以降であれば、通信の送信要求に対する送信処理を遅延させる。
（６）判断条件２０：通信の送信要求に対する送信処理の遅延中に、通信接続状態監視部１０５から取得される通信の接続状態が、RRC Idle状態からRRC Connected状態に遷移した場合には、直ぐに遅延を終了する。

なお、ここに列挙された判断条件は、判断条件１７１の一例であって、通信の送信要求に対する送信処理を行うタイミングを判断可能な情報であれば、他の判断条件を用いることができる。例えば、判断条件には、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含むようにすることができる。

通信予測部１０４は、将来発生する通信を予測し、その予測の結果を、遅延判断部１０３に供給する。ここで、通信予測部１０４は、遅延判断部１０３による、SNSアプリケーション１６１又はアプリケーション１６２からの通信の送信要求に対する処理判断を用いて通信の予測を行う。また、通信予測部１０４は、SNSアプリ動作状態監視部１１１から供給されるSNSアプリケーション１６１の動作状態を用いて通信の予測を行う。さらにまた、通信予測部１０４は、予測条件１７２を用いて通信の予測を行うことができる。

予測条件１７２には、例えば、以下の予測条件が列挙されている。

（１）予測条件４：SNSアプリケーション１６１において、友人の投稿の閲覧状態にある場合に、SNSアプリケーション１６１からの画像データ（パケット）の先読み要求（通信の送信要求）に対する送信処理が実行されたときには、その後、Ｃ１，Ｃ２，Ｃ３，Ｃ４，Ｃ５の通信がそれぞれ、Ｄ１，Ｄ２，Ｄ３，Ｄ４，Ｄ５のタイミングで発生すると仮定する。
（２）予測条件５：SNSアプリケーション１６１において、友人の投稿の閲覧状態にある場合に、SNSアプリケーション１６１から投稿テキストの送信要求（通信の送信要求）に対する送信処理が実行されたときには、その後、Ｃ６，Ｃ７，Ｃ８の通信がそれぞれ、Ｄ６，Ｄ７，Ｄ８のタイミングで発生すると仮定する。
（３）予測条件６：メッセージ確認アプリケーション１６２−１は、前回の通信から2分後に次の通信を行うと仮定する。
（４）予測条件７：位置記録確認アプリケーション１６２−２は、前回の通信から5分後に次の通信を行うと仮定する。

なお、ここに列挙された予測条件は、予測条件１７２の一例であって、将来発生する通信を予測可能な情報であれば、他の予測条件を用いることができる。例えば、予測条件には、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含むようにすることができる。

通信接続状態監視部１０５は、通信基地局との接続状態を常に監視し、その監視の結果を、遅延判断部１０３に供給する。この監視処理では、例えば、ある時点においてRRC Idle状態であるか、あるいはRRC Connected状態であるかが監視され、さらに、RRC Connected状態である場合には、その状態がどの時点まで継続するかが監視される。

SNSアプリ動作状態監視部１１１は、SNSアプリケーション１６１の動作状態を常に監視し、その動作状態を、通信予測部１０４に供給する。例えば、SNSアプリ動作状態監視部１１１は、SNSアプリケーション１６１が投稿の閲覧状態にあるかどうかを監視する。

スマートフォン１０Ｃは、以上のように構成されるが、図１５の構成は機能的な構成の一部を示しているため、実際には、例えば音声通話や画像撮影などを実現するための機能として、音声通話部やカメラ部、入力部、スピーカ、表示部などが設けられる。

なお、図１５の構成には示していないが、スマートフォン１０Ｃにおいては、上述したスマートフォン１０Ｂ（図１１）と同様に、履歴保持部１０８、判断条件学習部１０９、及び、予測条件学習部１１０を設けることで、履歴の学習によって、さらなる省電力通信を実現することができる。

（第３の送信処理）
次に、図１６のフローチャートを参照して、図１５のスマートフォン１０Ｃにより実行される第３の送信処理の流れについて説明する。ここでは、第３の送信処理が、例えば、スマートフォン１０Ｃを所持しているユーザが、SNSアプリケーション１６１を使用して、友人の最新の投稿から過去の投稿までを、スクロール操作をしながら閲覧している際に、当該スクロール操作によって、SNSアプリケーション１６１から画像データ（パケット）の先読み要求が発生したときに実行される場合を一例に説明する。

ステップＳ４０１において、送信要求部１０１は、SNSアプリケーション１６１で画像データの先読み要求が発生した場合、SNSアプリケーション１６１からの画像データの先読み要求（通信の送信要求）を、送信要求制御部１０２に伝える。そして、送信要求部１０１からの通信の送信要求が、送信要求制御部１０２に伝えられると、ステップＳ４０２において、送信要求制御部１０２は、その送信要求に対する処理判断を、遅延判断部１０３に問い合わせる。

ステップＳ４０３において、遅延判断部１０３は、送信要求制御部１０２からの問い合わせに応じて、メッセージ確認アプリケーション１６２−１からの通信の送信要求であるかどうかを判断する。すなわち、ステップＳ４０３の判断処理では、判断条件１７１の判断条件１６が用いられている。

ここでは、SNSアプリケーション１６１から、画像データの先読み要求（通信の送信要求）が伝えられた場合を例に説明しているので、ステップＳ４０３において、メッセージ確認アプリケーション１６２−１からの通信の送信要求ではないと判断され、処理はステップＳ４０７に進められる。なお、メッセージ確認アプリケーション１６２−１からの通信の送信要求が伝えられた場合には、処理は、ステップＳ４０４に進められ、直ちに送信処理が実行されることになる（ステップＳ４０４乃至Ｓ４０６）。

ステップＳ４０７において、遅延判断部１０３は、通信接続状態監視部１０５から取得される通信の接続状態に基づいて、接続状態が、RRC Connected状態で、かつ、RRC Connected状態が6秒以上継続するかどうかを判断する。すなわち、ステップＳ４０７の判断処理では、判断条件１７１の判断条件１８が用いられている。

ステップＳ４０７において、接続状態が、RRC Connected状態で、かつ、RRC Connected状態が6秒以上継続すると判断された場合、処理は、ステップＳ４０４に進められ、送信処理が実行されることになる（ステップＳ４０４乃至Ｓ４０６）。

また、ステップＳ４０７の判断条件を満たさない場合には、処理は、ステップＳ４０８に進められる。ステップＳ４０８において、遅延判断部１０３は、通信接続状態監視部１０５から取得される通信の接続状態に基づいて、RRC Idle状態で、次の通信が4秒後以内に発生すると予測されるかどうかを判断する。すなわち、ステップＳ４０８の判断処理では、判断条件１７１の判断条件１９が用いられている。

ステップＳ４０８において、RRC Idle状態で、次の通信が4秒後以内に発生すると予測される場合、処理は、ステップＳ４０４に進められ、送信処理が実行されることになる（ステップＳ４０４乃至Ｓ４０６）。

また、ステップＳ４０８の判断条件を満たさない場合には、処理は、ステップＳ４０９に進められる。ステップＳ４０９において、遅延判断部１０３は、通信の送信要求がSNSアプリケーション１６１から伝えられた場合に、その最大遅延許容時間（10秒等）に達したか、あるいは、通信の送信要求の遅延中に、通信接続状態監視部１０５から取得される通信の接続状態が、RRC Idle状態からRRC Connected状態に遷移したかどうかを判断する。すなわち、ステップＳ４０９の判断処理では、判断条件１７１の判断条件１５と判断条件２０が用いられている。なお、通信の送信要求が位置記録確認アプリケーション１６２−２から伝えられた場合には、最大遅延許容時間は、1分とされる（判断条件１７１の判断条件１７）。

ステップＳ４０９において、最大遅延許容時間に達したと判断された場合、あるいは、接続状態が、RRC Idle状態からRRC Connected状態に遷移したと判断された場合、処理は、ステップＳ４０４に進められ、送信処理が実行されることになる（ステップＳ４０４乃至Ｓ４０６）。また、ステップＳ４０９の判断条件を満たさない場合には、ステップＳ４０９の判断処理が繰り返される。そして、ステップＳ４０９の判断条件を満たした場合には、処理は、ステップＳ４０４に進められ、送信処理が実行されることになる（ステップＳ４０４乃至Ｓ４０６）。

ステップＳ４０６の処理が終了すると、図１６の第３の送信処理は終了する。

以上、スマートフォン１０Ｃにより実行される第３の送信処理について説明した。この第３の送信処理においては、SNSアプリケーション１６１又はアプリケーション１６２等から通信の送信要求が発生した場合に、遅延判断部１０３によって、判断条件１５至判断条件２０等の判断条件１７１に基づいた判断処理が行われて、当該送信要求に対する送信処理を今処理すべきと判断された場合に送信処理が行われる一方、遅らせて処理すべきと判断された場合には、遅延終了条件を満たすまで、送信処理が遅延されることになる。

例えば、通信の接続状態がRRC Idle状態のタイミングで、SNSアプリケーション１６１又はアプリケーション１６２からの通信の送信要求に対する送信処理を実行すると、通信の接続状態がRRC Idle状態からRRC Connected状態に遷移することになって、消費電力を増大させてしまうことになるが、このような遅延判断処理が行われることで、RRC Connected状態に留まる時間を可能な限り短くして、無駄な消費電力を低減することができる。

また、例えば、通信の接続状態がRRC Connected状態であっても、RRC Idle状態に遷移する直前に、通信の送信要求に対する送信処理を実行すると、やはり、消費電力を増大させてしまうことになるが、このような遅延判断処理が行われることで、RRC Connected状態に留まる時間を可能な限り短くして、無駄な消費電力を低減することができる。

すなわち、このような判断処理が行われることで、通信の応答性を損なうことなく、テイルエナジーの発生を抑制して、消費電力を低減することができる。また、通信の応答性を損なわないことから、ユーザが通信応答性に不便に感じることはない。さらに、ユーザ操作に制約を与えずに、省電力を実現することができる。

＜６．コンピュータの構成＞

上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

図１７は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。

コンピュータ９００において、CPU（Central Processing Unit）９０１，ROM（Read Only Memory）９０２，RAM（Random Access Memory）９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及びドライブ９１０が接続されている。

入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。

以上のように構成されるコンピュータ９００では、CPU９０１が、例えば、記録部９０８に記憶されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ９００（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。

コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。

なお、コンピュータ９００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

ここで、本明細書において、コンピュータ９００に各種の処理を行わせるためのプログラムを記述する処理ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。

また、プログラムは、１のコンピュータにより処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであってもよい。

さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。

また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。

なお、本技術は、以下のような構成をとることができる。

（１）
通信の送信要求が発生した場合に、将来発生する通信予測の結果、及び、通信の接続状態に基づいて、省電力の観点から、前記送信要求に対する送信処理を実行するタイミングを判断する遅延判断部と、
前記送信処理を実行するタイミングであると判断された場合、前記送信要求を、前記送信処理を実行する送信処理部に通知する送信要求制御部と
を備える通信装置。
（２）
前記遅延判断部は、将来発生する通信と、データの送受信に続いて発生する接続維持のための電力であるテイルエナジーの予測結果に基づいて、前記送信処理を実行するタイミングを判断する
（１）に記載の通信装置。
（３）
前記遅延判断部は、あらかじめ定められた判断条件を用い、前記送信処理を実行するタイミングを判断する
（２）に記載の通信装置。
（４）
前記判断条件は、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含む
（３）に記載の通信装置。
（５）
将来発生する通信を予測する通信予測部をさらに備える
（１）乃至（４）のいずれか一項に記載の通信装置。
（６）
前記通信予測部は、あらかじめ定められた予測条件を用い、将来発生する通信を予測する
（５）に記載の通信装置。
（７）
前記予測条件は、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含む
（６）に記載の通信装置。
（８）
特定の判断条件に関する履歴情報に基づいて、前記判断条件を更新する判断条件学習部と、
特定の予測条件に関する履歴情報に基づいて、前記予測条件を更新する予測条件学習部と
をさらに備える（７）に記載の通信装置。
（９）
通信の接続状態を監視する通信接続状態監視部をさらに備える
（１）乃至（８）のいずれか一項に記載の通信装置。
（１０）
前記送信要求を発生させる特定のアプリケーションの動作状態を監視する動作状態監視部をさらに備え、
前記通信予測部は、前記特定のアプリケーションの動作状態に基づいて、将来発生する通信を予測する
（５）乃至（９）のいずれか一項に記載の通信装置。
（１１）
通信装置の通信方法において、
前記通信装置が、
通信の送信要求が発生した場合に、将来発生する通信予測の結果、及び、通信の接続状態に基づいて、省電力の観点から、前記送信要求に対する送信処理を実行するタイミングを判断し、
前記送信処理を実行するタイミングであると判断された場合、前記送信要求を、前記送信処理を実行する送信処理部に通知する
ステップを含む通信方法。
（１２）
コンピュータを、
通信の送信要求が発生した場合に、将来発生する通信予測の結果、及び、通信の接続状態に基づいて、省電力の観点から、前記送信要求に対する送信処理を実行するタイミングを判断する遅延判断部と、
前記送信処理を実行するタイミングであると判断された場合、前記送信要求を、前記送信処理を実行する送信処理部に通知する送信要求制御部と
として機能させるためのプログラム。

１０ 通信装置， １０Ａ インターネットラジオ専用端末， １０Ｂ スマートフォン， １０Ｃ スマートフォン， １０１ 送信要求部， １０２ 送信要求制御部， １０３ 遅延判断部， １０４ 通信予測部， １０５ 通信接続状態監視部， １０６ 送信処理部， １０７ 状態監視部， １０８ 履歴保持部， １０９ 判断条件学習部， １１０ 予測条件学習部， １２１ ラジオ放送受信アプリケーション， １２２ フィードバックアプリケーション， １３１ 判断条件， １３２ 予測条件， １４１，１４１−１乃至１４１−Ｎ アプリケーション， １５１ 判断条件， １５２ 予測条件， １６１ SNSアプリケーション， １６２，１６２−１乃至１６２−Ｍ アプリケーション， １１１ SNSアプリ動作状態監視部， １７１ 判断条件， １７２ 予測条件， ９００ コンピュータ， ９０１ CPU

Claims (12)

1. 通信の送信要求が発生した場合に、将来発生する通信予測の結果、及び、通信の接続状態に基づいて、省電力の観点から、前記送信要求に対する送信処理を実行するタイミングを判断する遅延判断部と、
   前記送信処理を実行するタイミングであると判断された場合、前記送信要求を、前記送信処理を実行する送信処理部に通知する送信要求制御部と
   を備える通信装置。
2. 前記遅延判断部は、将来発生する通信と、データの送受信に続いて発生する接続維持のための電力であるテイルエナジーの予測結果に基づいて、前記送信処理を実行するタイミングを判断する
   請求項１に記載の通信装置。
3. 前記遅延判断部は、あらかじめ定められた判断条件を用い、前記送信処理を実行するタイミングを判断する
   請求項２に記載の通信装置。
4. 前記判断条件は、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含む
   請求項３に記載の通信装置。
5. 将来発生する通信を予測する通信予測部をさらに備える
   請求項４に記載の通信装置。
6. 前記通信予測部は、あらかじめ定められた予測条件を用い、将来発生する通信を予測する
   請求項５に記載の通信装置。
7. 前記予測条件は、通信の状態、アプリケーションの動作状態、ユーザ操作の状態、及び、センシング情報のうちの１つを少なくとも含む
   請求項６に記載の通信装置。
8. 特定の判断条件に関する履歴情報に基づいて、前記判断条件を更新する判断条件学習部と、
   特定の予測条件に関する履歴情報に基づいて、前記予測条件を更新する予測条件学習部と
   をさらに備える請求項７に記載の通信装置。
9. 通信の接続状態を監視する通信接続状態監視部をさらに備える
   請求項３に記載の通信装置。
10. 前記送信要求を発生させる特定のアプリケーションの動作状態を監視する動作状態監視部をさらに備え、
    前記通信予測部は、前記特定のアプリケーションの動作状態に基づいて、将来発生する通信を予測する
    請求項５に記載の通信装置。
11. 通信装置の通信方法において、
    前記通信装置が、
    通信の送信要求が発生した場合に、将来発生する通信予測の結果、及び、通信の接続状態に基づいて、省電力の観点から、前記送信要求に対する送信処理を実行するタイミングを判断し、
    前記送信処理を実行するタイミングであると判断された場合、前記送信要求を、前記送信処理を実行する送信処理部に通知する
    ステップを含む通信方法。
12. コンピュータを、
    通信の送信要求が発生した場合に、将来発生する通信予測の結果、及び、通信の接続状態に基づいて、省電力の観点から、前記送信要求に対する送信処理を実行するタイミングを判断する遅延判断部と、
    前記送信処理を実行するタイミングであると判断された場合、前記送信要求を、前記送信処理を実行する送信処理部に通知する送信要求制御部と
    として機能させるためのプログラム。

Images