JP6488528B2 - 通信装置、通信方法、通信プログラム、及びプロセッサ - Google Patents

Description

本発明は、通信装置、通信方法、通信プログラム、及びプロセッサに関する。

無線通信において、ある無線リンクの品質が低下した際、品質低下を検知して、異なる無線リンクへ切り換える技術が知られてきている（例えば、特許文献１、２、非特許文献１、２）。

特開２００５−２２３８１１号公報 特開２００７−３３６３３５号公報

"ワイヤレスジャパン ２０１２：実効速度が２倍以上に−ＫＤＤＩの「リンクアグリゲーション無線技術」"、［online］、平成２４年５月３０日、ＩＴｍｅｄｉａ＋Ｄモバイル、［平成２６年１１月１３日検索］、インターネット（ＵＲＬ：http://plusd.itmedia.co.jp/mobile/articles/1205/30/news066.html） 蕨野貴之 Takayuki WARABINO他,端末間のシームレスな切り換えを実現するデバイスハンドオフ方式の提案 Proposal of a device handoff methods for seamless communications, 情報処理学会研究報告 Vol.2003 No. 114 IPSJ SIG Technical Reports, 日本, 社団法人情報処理学会 Information Processing Society of Japan, 2003年11月14日,第2003巻,第105-112頁

例えば、特許文献１に記載の技術では、フォールバック動作において、リンク１の接続が切れた場合をターゲットとし、通信の途中からリンク２を使用するための手段が提案されているが、リンク１の接続性確認の手段に関しては記載されていない。
例えば、ＴＣＰ（Ｔｒａｎｓｉｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ)）通信では、接続要求に対する応答をもって通信経路の接続が完了したとみなされる。そのため、接続要求に対する応答が所定の時間ない状態であれば、該当の通信経路では論理接続が成立しないと見做し、別の通信経路を利用する経路制御の手法が一般的に行われている。
しかしながら、前述の場合、経路制御により通信経路を切り替えてしまうと、以降の通信は切り替え後の通信経路で実施することが一般的である。この場合、通信端末は、偶然あるサーバへの接続を行う際に接続要求に対する応答が遅延した場合でも、通信経路を切り替えてしまう可能性がある。また、通信経路を切り替える判定条件として設定された上記応答の遅延量の閾値が、通信端末が属するネットワークに対して適切な遅延量でない場合、通信端末は、常に通信経路を切り替えてしまい、切り替え前の通信経路を使うことができないことがある。

本発明は上記の点に鑑みてなされたものであり、適切に無線リンクの切り換えを制御できる通信装置、通信方法、通信プログラム、及びプロセッサを提供する。

本発明は上記の課題を解決するためになされたものであり、本発明の一態様は、第１通信を行う第１通信部と、第２通信を行う第２通信部と、前記第１通信から前記第２通信への切り替え条件を満たしたか否かを、予め定めた一連の通信毎に判定し、判定結果に基づいて、前記一連の通信毎に、前記第１通信から前記第２通信への切り替えを制御する選択部と、前記第１通信から前記第２通信へ切り換えている前記一連の通信の数を計数する計数部と、を備え、前記選択部は、前記第１通信を優先し、前記計数部が計数した前記一連の通信の数が閾値を超えた場合には、その後の前記一連の通信に対して前記第２通信を優先する、通信装置である。

また、本発明の一態様は、上記の通信装置において、前記選択部は、前記第１通信を用いた接続要求に対する応答を所定の時間以上取得できなかった場合、前記切り替え条件を満たしたと判定する。

また、本発明の一態様は、上記の通信装置において、前記選択部は、前記第１通信を用いて取得する通信データの送信元を識別可能な情報を所定の時間以上取得できなかった場合、前記切り替え条件を満たしたと判定する。

また、本発明の一態様は、上記の通信装置において、前記選択部は、前記第１通信から前記第２通信へ切り替えた数に応じて、前記所定の時間を変更する。

また、本発明の一態様は、上記の通信装置において、前記選択部は、前記第１通信から前記第２通信へ切り替えた数に応じて、前記所定の時間を増加させる。

また、本発明の一態様は、上記の通信装置において、前記選択部は、前記第１通信から前記第２通信へ切り替えた数に応じて、前記所定の時間を線形的に増加させる。

また、本発明の一態様は、上記の通信装置において、前記選択部は、前記第１通信から前記第２通信へ切り替えた数に応じて、前記所定の時間を非線形的に増加させる。

また、本発明の一態様は、上記の通信装置において、前記第１通信と前記第２通信は、論理的又は物理的な通信のインターフェースが異なり、前記選択部は、前記第１通信のインターフェースから前記第２通信のインターフェースへの切り換えを制御する。

また、本発明の一態様は、通信装置における通信方法おいて、選択部が、第１通信から第２通信への切り替え条件を満たしたか否かを、予め定めた一連の通信毎に判定する判定過程と、前記判定の判定結果に基づいて、前記一連の通信毎に、前記第１通信から前記第２通信への切り替えを制御する選択過程と、計数部が、前記第１通信から前記第２通信へ切り換えている前記一連の通信の数を計数する計数過程と、を有し、前記選択過程において、前記第１通信を優先し、前記計数過程において計数された前記一連の通信の数が閾値を超えた場合には、その後の前記一連の通信に対して前記第２通信を優先する、通信方法である。

また、本発明の一態様は、通信装置のコンピュータに、第１通信から第２通信への切り替え条件を満たしたか否かを、予め定めた一連の通信毎に判定する判定手順と、前記判定の判定結果に基づいて、前記一連の通信毎に、前記第１通信から前記第２通信への切り替えを制御する選択手順と、前記第１通信から前記第２通信へ切り換えている前記一連の通信の数を計数する計数手順と、を実行させ、前記選択手順において、前記第１通信を優先し、前記計数手順において計数された前記一連の通信の数が閾値を超えた場合には、その後の前記一連の通信に対して前記第２通信を優先する、通信プログラムである。

また、本発明の一態様は、第１通信から第２通信への切り替え条件を満たしたか否かを、予め定めた一連の通信毎に判定し、判定結果に基づいて、前記一連の通信毎に、前記第１通信から前記第２通信への切り替えを制御する選択部と、前記第１通信から前記第２通信へ切り換えている前記一連の通信の数を計数する計数部と、を備え、前記選択部は、前記第１通信を優先し、前記計数部が計数した前記一連の通信の数が閾値を超えた場合には、その後の前記一連の通信に対して前記第２通信を優先する、プロセッサである。

本発明によれば、適切に無線リンクの切り換えを制御できる。

本発明の第１実施形態に係る通信システムの構成を示す概略図である。 本実施形態に係る通信装置の構成を示す概略ブロック図である。 本実施形態に係るプロキシ部の構成を示す概略ブロック図である。 本実施形態に係るフォールバックを説明するための説明図である。 本実施形態に係るフェールバックを説明するための説明図である。 本実施形態に係る通信装置の状態遷移を表す図である。 本実施形態に係る通信装置の状態遷移についての説明図である。 本実施形態に係る通信装置の処理フローを示す図である。 本実施形態に係るプロキシ部の処理フローを示す図である。 本実施形態に係るプロキシ部の処理フローを示す図である。 本実施形態に係るプロキシ部の処理フローを示す別の図である。 本実施形態に係るプロキシ部の処理フローを示す別の図である。 本実施形態に係るプロキシ部の処理フローを示す別の図である。 本実施形態に係るプロキシ部の処理フローを示す別の図である。

（第１実施形態）
以下、図面を参照しながら本発明の第１実施形態について詳しく説明する。
図１は、本発明の第１実施形態に係る通信システムの構成を示す概略図である。この図において、通信システムは、通信装置１、アクセスポイントＡＰ１、基地局装置ＢＳ１、及び、サーバ装置Ｓｖ１０１〜１０４を具備する。

通信装置１は、Ｗｉ−Ｆｉ（登録商標。以下同じ）、３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ：第３世代移動通信システム）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）等のように、複数の異なる通信を行うことができる装置である。通信装置１は、複数の物理リンクを束ねて、1つの論理リンクとして扱うこと（リンクアグリゲーション）ができる。通信装置１は、例えば、スマートフォン、タブレット端末、フィーチャーフォン、パーソナルコンピュータ、モバイルルーター等である。

アクセスポイントＡＰ１は、通信装置１からの接続要求を受け付けて、ネットワークへの通信を仲介する機器である。例えば、アクセスポイントＡＰ１は、無線ＬＡＮのアクセスポイントであり、通信装置１とＷｉ−Ｆｉによる通信（無線リンクＬ１と称する。また、Ｗｉ−Ｆｉ通信とも称する）を行うことができる。
基地局装置ＢＳ１は、携帯電話と直接電波を送受信する装置である。基地局装置ＢＳ１は、通信装置１と３Ｇ又はＬＴＥによる通信（無線リンクＬ２と称する）を行うことができる。基地局装置ＢＳ１は、携帯電話網Ｎ１に接続され、携帯電話網Ｎ１を介して、ネットワークＮ２に接続された機器と通信を行うことができる。例えば、ネットワークＮ２はインターネットであり、携帯電話網Ｎ１と通信プロトコルが異なる。

サーバ装置Ｓｖ１０１は、例えば、ゲートウェイサーバであり、携帯電話網Ｎ１とネットワークＮ２の通信プロトコルの変換等を行う。サーバ装置Ｓｖ１０２は、ネットワークＮ１に接続され、基地局装置ＢＳ１を介して、通信装置１と通信を行うことができる。 サーバ装置Ｓｖ１０３、Ｓｖ１０４は、ネットワークＮ２に接続され、アクセスポイントＡＰ１、又は、携帯電話網Ｎ１と基地局装置ＢＳ１を介して、通信装置１と通信を行うことができる。例えば、サーバ装置Ｓｖ１０２、Ｓｖ１０３は、ドメインネームシステム（ＤＮＳ）のサーバ装置（ＤＮＳサーバとも称する）であり、ネットワーク上のホスト名やドメイン名と、ＩＰアドレスとを対応付けたドメインネーム情報を管理する。例えば、サーバ装置Ｓｖ１０４は、コンテンツサーバであり、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ハイパーテキスト・トランスファー・プロトコル）等のプロトコルの通信（ＨＴＴＰ通信と称する）を行う。サーバ装置Ｓｖ１０４は、例えば、ＨＴＭＬ形式のコンテンツを、通信装置１へ提供する。

通信装置１は、無線リンクＬ１を用いて、ＨＴＴＰ通信を行った場合、ＨＴＴＰのヘッダ情報Ｈ１を取得して記憶する。その後、例えば無線リンクＬ１の品質が低下したことを検出した場合、通信装置１は、無線リンクＬ２を用いて、ＨＴＴＰのレンジリクエストを行う。レンジリクエストとは、データの範囲を指定して、データの一部分だけを要求する指令である。具体的には、通信装置１は、ＨＴＴＰのヘッダフィールドで「Ｒａｎｇｅ：ｂｙｔｅｓ＝５０１−」と指定することで、５０１バイトより後のデータを要求して、取得（ダウンロード）できる。

通信装置１は、無線リンクＬ１を用いて取得したヘッダ情報Ｈ１と、無線リンクＬ２を用いて取得したヘッダ情報Ｈ２と、を比較するヘッダ比較処理を行う。ヘッダ比較処理においては、通信装置１は、例えばヘッダ情報のうち、ＨＴＴＰのデータ部分（ボディ情報とも称する）に差分があると判断できる情報（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈなどの情報）を比較する。ヘッダ比較処理の結果、ヘッダ情報Ｈ１とヘッダ情報Ｈ２が同じであると判定した場合、通信装置１は、無線リンクＬ１から無線リンクＬ２の切り換え（フォールバックと称する）を行う。なお、通信装置１は、フォールバックを行う場合、通信のインターフェースを変える。その結果、通信装置１は、例えば、通信に用いるＩＰアドレスやポート番号を変更する。なお、フォールバックは、Ｗｉ−ＦｉとＬＴＥ等、通信種別を変える場合に限られず、Ｗｉ−Ｆｉ通信同士で行われてもよい。つまり、例えば、Ｗｉ−Ｆｉ通信のインターフェースが２個以上ある場合、フォールバックには、Ｗｉ−Ｆｉ通信のままインターフェースを変更することも含まれる。なお、インターフェースは、物理的なインターフェースに限らず、論理的なインターフェースであってもよい。論理的なインターフェースとは、例えば、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）におけるインターフェースである。
一方、ヘッダ比較処理の結果、ヘッダ情報Ｈ１とヘッダ情報Ｈ２の全部又は一部が同じでないと判定した場合、つまり、ＨＴＴＰのデータ部分に差分がある場合、通信装置１は、フォールバックを中止する。これにより、通信装置１は、例えばアクセスの度に異なるコンテンツが返答されるような場合でも、無線リンクＬ１を用いてフォールバック前と同じコンテンツの続きを取得できる。つまり、通信装置１は、フォールバックによって、無線リンクＬ１を用いて取得したデータと無線リンクＬ２を用いて取得したデータを結合してしまい、データの不整合が生じることを防止できる。

なお、ヘッダ比較処理の結果、ヘッダ情報Ｈ１とヘッダ情報Ｈ２が同じでないと判定した場合、通信装置１は、無線リンクＬ２を用いて取得したヘッダ情報に応じて、再度、フォールバックを試みてもよい。例えば、通信装置１は、無線リンクＬ２を用いて取得したヘッダ情報Ｈ２のうち、ステータスコードがリダイレクションを示す場合、再度、リダイレクション先に対して、ＨＴＴＰのレンジリクエストを行う。ここで、ステータスコードがリダイレクションすることを示す場合とは、例えば、ステータスコードに移動先のＵＲＬが付されている場合である。具体的には、そのときのステータスコードは、「３０２」（Ｍｏｖｅｄ Ｐｅｒｍａｎｅｎｔｌｙ：恒久的に移動）、「３０３」（Ｆｏｕｎｄ：発見）、「３０７」（Ｔｅｍｐｏｒａｒｙ Ｒｅｄｉｒｅｃｔ）等である。

通信装置１は、レンジリクエストの結果、リダイレクト先からヘッダ情報Ｈ２’を取得する（ＲＤ先情報取得処理とも称する）。通信装置１は、取得したヘッダ情報Ｈ２’を用いてヘッダ比較処理を行い、ヘッダ情報Ｈ１とヘッダ情報Ｈ２’が同じであると判定した場合、フォールバックを行う。一方、通信装置１は、ヘッダ情報Ｈ１とヘッダ情報Ｈ２’が同じでないと判定した場合、フォールバックを中止する。

また、通信装置１は、例えば、アプリケーションからの要求毎に、セッション単位でフォールバックを行うか否かを判定する。１つのセッションのフォールバック（ＦＢ）を、単一フォールバックとも称する。通信装置１は、単一フォールバックの数（後述するＦＢセッション数）を計数し、予め定めた許容数を超えた場合、無線リンクＬ１を「通信不能」と判定する（この場合の無線リンクＬ１を不要リンクとも称する）。この場合、通信装置１は、アプリケーションからの通信要求があったときには、無線リンクＬ２を用いて通信を行う、「強制フォールバックモード」の状態へ遷移する。

以上により、通信装置１は、フォールバック時にヘッダ情報の内容を比較することで、同一のコンテンツであるかどうかを確認し、想定外のデータ（未更新データなど）をアプリケーションに送信してしまうことを未然に防ぐことができる。
また、通信装置１は、フォールバック時にリダイレクトされた場合でも、ヘッダ情報が同じものを取得できた場合、つまり、最終的にコンテンツが同じである場合、フォールバックを行うことができる。
通信装置１は、「強制フォールバックモード」に遷移させることで、不要リンクへの通信確立を試みるコストが不要となり、すぐに良好な通信を行うことができる。なお、通信装置１は、不要リンクと判断された無線リンクＬ１への接続を復帰させたい場合、ヘッダ比較処理を行ってもよく、それにより、効率的に再利用を開始することができる。

また、通信装置１は、セッション毎に単一フォールバックを行うか否かを制御することで、特定のサーバや通信経路がダウンしている場合や、特定のネットワークで単一フォールバックを行うと判定する閾値以上の応答の遅延が発生する環境において、あるセッションが接続できないだけで、他のすべての通信（接続が成功する可能性のある通信）まで切り替えてしまうことを抑制することができる。例えば、通信装置１は、使用しているシステムに適した応答の遅延量を計算し、フォールバックを行うか否かを判定する閾値として設定することができる。

なお、通信装置１は、各セッション単位で単一フォールバックを行うか否か（通信セッションが確立できるかどうか）を制御するが、一つでも単一フォールバックが行われるセッションが存在する場合、単一フォールバックを行うと判定する閾値に現在の単一フォールバックしているセッション数を用いた重み付けを行い、単一フォールバックしているセッション数が１本よりも２本、２本よりも３本、と、徐々にフォールバックしにくくなるよう調整してもよい。例えば、通信装置１は、接続要求に対する応答が所定の時間ないとき（例えば、セッションがタイムアウトしたとき）にフォールバックを行うと判定する場合、単一フォールバックしているセッション数に応じて、この所定の時間を徐々に長くする。

＜通信装置１について＞
図２は、本実施形態に係る通信装置１の構成を示す概略ブロック図である。通信装置１は、入力部１１、出力部１２、制御部１３、記憶部１４、及び通信部１５を含んで構成される。制御部１３は、アプリケーション部１３１とプロキシ部Ｐ１を含んで構成される。通信部１５は、Ｎ個のインターフェース１５１−１〜１５１−Ｎ、及び信号強度検出部１５２を含んで構成される。

入力部１１は、通信装置１のユーザからの入力を受け付け、受け付けた入力を示す情報を制御部１３へ出力する。例えば、入力部１１は、ユーザからフォールバックを許可することを示す情報、又は、フォールバックを許可しないことを示す情報を受け付け、フォールバックへ出力する。入力部１１は、例えば、タッチパネルやボタン、キーボード、カメラである。
出力部１２は、制御部１３の制御に基づいて、出力を行う。出力部１２は、例えば、ディスプレイやスピーカー、振動子、発光素子である。

制御部１３は、入力部１１や通信部１５から入力された情報、又は記憶部１４が記憶する情報に基づいて、通信装置１の各部を制御する。制御部１３のうち、アプリケーション部１３１は、記憶部１４からプログラムを読み込み、読み込んだプログラムを実行することで、様々なアプリケーション機能を発揮する。

プロキシ部Ｐ１は、制御部１３が生成した情報を、一又は複数のインターフェース１５１−ｎ（ｎ＝１、２、・・・、Ｎ）を介して、送信させる。例えば、プロキシ部Ｐ１は、入力部１１や通信部１５から入力された情報、又は記憶部１４が記憶する情報に基づいて、通信部１５のインターフェース１５１−１〜１５１−Ｎの中から、一又は複数のインターフェース１５１−ｎを選択する。プロキシ部Ｐ１は、選択した一又は複数のインターフェース１５１−ｎを介して、アプリケーション部１３１が生成した情報を送信する。
また、プロキシ部Ｐ１は、複数のインターフェース１５１−ｎが情報を受信した場合、受信した情報を合成する。例えば、プロキシ部Ｐ１は、複数のインターフェース１５１−ｎを時間的に切り換えた場合、切り換え前後のデータを合成してもよい。プロキシ部Ｐ１の詳細については、後述する。

通信部１５は、複数の通信方式の通信を行うことができる。例えば、インターフェース１５１−１は、Ｗｉ−Ｆｉ通信を行うことができる。インターフェース１５１−２は、ＬＴＥによる通信（ＬＴＥ通信とも称する）を行うことができる。また、インターフェース１５１−３は、３Ｇによる通信（３Ｇ通信とも称する）を行うことができる。なお、インターフェース１５１−ｎは、無線通信に限らず、有線通信を行うものであってもよい。また、インターフェース１５１−ｎは、物理的なインターフェースに限らず、論理的なインターフェースであってもよい。

信号強度検出部１５２は、インターフェース１５１−ｎ毎に、通信信号の受信する信号の強度（受信信号強度）を示す信号強度情報を検出する。例えば、信号強度検出部１５２は、インターフェース１５１−１による通信（Ｗｉ−Ｆｉ通信）では、ＲＳＳＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ（又はＩｎｄｉｃａｔｉｏｎ）を検出する。また、インターフェース１５１−２、１５−３による通信（ＬＴＥ通信、３Ｇ通信）では、ＣＱＩ（Ｃｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｄｉｃａｔｏｒ）を検出してもよい。信号強度検出部１５２は、検出した信号強度情報を、制御部１３（例えば、プロキシ部Ｐ１）へ出力する。

＜プロキシ部Ｐ１について＞
図３は、本実施形態に係るプロキシ部Ｐ１の構成を示す概略ブロック図である。プロキシ部Ｐ１は、セッション管理部Ｐ１１１、ＤＮＳ管理部Ｐ１１２、スループット取得部Ｐ１１３、容量情報取得部Ｐ１１４、信号強度取得部Ｐ１２１、計時部Ｐ１２２、ＡＰ（アクセスポイント）情報取得部Ｐ１２３、通信方式情報取得部Ｐ１２４、位置情報取得部Ｐ１２５、ヘッダ情報取得部Ｐ１３１、リダイレクト情報取得部Ｐ１３２、ＩＦ選択部Ｐ１４、及び、データ合成部Ｐ１５を含んで構成される。

セッション管理部Ｐ１１１は、セッションを管理する。セッションとは、一連の通信のことであり、例えば、接続を確立してから切断するまでの単位である。例えば、セッションは、アプリケーションからのリクエスト毎に生成され、各リクエストに対する応答後に、それぞれのセッションが終了する。具体的には、セッション管理部Ｐ１１１は、セッションの識別情報（セッション識別情報とも称する）、セッションの開始時刻、セッションの終了時刻、リクエストの識別情報、リクエストをしたアプリケーションの識別情報、セッション確立の成否、セッション異常の理由を示すセッション異常理由情報、セッションに用いた無線リンクを示す情報等を、記憶部１４に記憶させ、参照や更新をすることで、セッションを管理する。セッション異常には、セッションの確立に失敗やセッションのタイムアウト等があり、その理由には、接続エラー、通信エラー、ソケットエラー、又はタイムアウト等がある。

セッション管理部Ｐ１１１は、セッションが確立できなかった場合（例えば、接続失敗）やセッションがタイムアウトした場合等、セッション異常が発生したときには、セッション異常を示すセッション異常情報とセッション異常理由情報を、セッション識別情報と対応付けて、ＩＦ選択部Ｐ１４へ出力する。
また、セッション管理部Ｐ１１１は、フォールバックをしているセッション数（ＦＢセッション数とも称する）を計数し、計数したＦＢセッション数を示すＦＢセッション数情報を、ＩＦ選択部Ｐ１４へ出力する。なお、フォールバックは、セッション毎に発生し、セッション単位で発生するフォールバックのことを、「単一フォールバック」とも称する。

ＤＮＳ管理部Ｐ１１２は、通信装置１において、ドメインネーム情報を管理する。ＤＮＳ管理部Ｐ１１２は、例えば、コンテンツサーバのドメイン名をＤＮＳサーバへ送信し、ＩＰアドレスを取得する。このＤＮＳ管理部Ｐ１１２の処理を、名前解決処理とも称する。
ＤＮＳ管理部Ｐ１１２は、名前解決処理に異常が発生したときには、名前解決の異常を示す名前解決異常情報と名前解決の異常の理由を示す名前解決異常理由情報を、セッション識別情報と対応付けて、ＩＦ選択部Ｐ１４へ出力する。名前解決の異常には、名前解決処理の失敗（例えば、接続失敗）や名前解決処理のタイムアウト等があり、その理由には、ホスト名又はドメイン名の不登録、未登録や通信エラー、タイムアウト等がある。

スループット取得部Ｐ１１３は、通信部１５の送受信する情報量に基づいて、通信のスループットを算出する。スループットとは、一定時間内に通信したデータ量のことである。本実施形態のスループットは、下りの通信、つまり、アクセスポイントＡＰ１又は基地局装置ＢＳ１から通信装置１への通信のスループットとするが、本発明は、これに限られない。スループット取得部Ｐ１１３は、算出したスループットを示すスループット情報を、セッション識別情報と対応付けて、ＩＦ選択部Ｐ１４へ出力する。

容量情報取得部Ｐ１１４は、通信に関する各情報の容量を管理し、その容量を示す容量情報を生成する。例えば、容量情報取得部Ｐ１１４は、コンテンツサーバから通信によって取得するコンテンツの容量（コンテンツサイズとも称する）を取得し、また、当該コンテンツについての現在取得済みの容量（ＤＬ済サイズとも称する）を算出する。また、容量情報取得部Ｐ１１４は、フォールバックを許容する容量（ＦＢ許容サイズとも称する）を、予め記憶する記憶部１４から読み出す。容量情報取得部Ｐ１１４は、コンテンツサイズ、ＤＬ済サイズ、又はＦＢ許容サイズを示す容量情報を、ＩＦ選択部Ｐ１４へ出力する。なお、容量情報は、セッション毎の各容量を示す場合、セッション識別情報と対応付けて、ＩＦ選択部Ｐ１４へ出力される。
信号強度取得部Ｐ１２１は、信号強度検出部１５２からインターフェース１５１−ｎ毎の信号強度情報を取得し、取得した信号強度情報をＩＦ選択部Ｐ１４へ出力する。

計時部Ｐ１２２は、計時を行う。例えば、計時部Ｐ１２２は、フォールバック状態Ｃ１３（後述）に遷移してからの経過時間を計時する。計時部Ｐ１２２は、この経過時間が設定値（例えば、１分）を超えた場合、時間超過を示す時間超過情報をセッション識別情報と対応付けて、ＩＦ選択部Ｐ１４へ出力する。
ＡＰ情報取得部Ｐ１２３は、現在通信をしているアクセスポイント或いは基地局の識別情報又はネットワークの識別情報（ＢＳＳＩＤ又はＥＳＳＩＤ等）を取得する。ＡＰ情報取得部Ｐ１２３は、取得した識別情報（ＡＰ識別情報とも称する）を、ＩＦ選択部Ｐ１４へ出力する。

通信方式情報取得部Ｐ１２４は、現在通信に用いている通信方式を示す通信方式情報を生成する。例えば、通信方式情報取得部Ｐ１２４は、ＬＴＥ通信を行っているときにはＬＴＥを示す通信方式情報、３Ｇ通信を行っているときには３Ｇを示す通信方式情報を生成する。通信方式情報取得部Ｐ１２４は、生成した通信方式情報を、ＩＦ選択部Ｐ１４へ出力する。
位置情報取得部Ｐ１２５は、例えば、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ，全地球測位網）機能により、通信装置１の現在位置を測位する。位置情報取得部Ｐ１２５は、測位した通信装置１の現在位置を示す位置情報を、ＩＦ選択部Ｐ１４へ出力する。なお、位置情報取得部Ｐ１２５は、基地局装置ＢＳ１の基地局情報であって通信装置１のおおよその位置を推定可能な基地局情報（例えば、通信装置１が接続中の基地局装置を示す情報や基地局装置の位置を示す情報）を取得し、取得した基地局情報を位置情報として、ＩＦ選択部Ｐ１４へ出力してもよい。

ヘッダ情報取得部Ｐ１３１は、通信部１５の送受信する情報から、セッション毎にＨＴＴＰのヘッダ情報を取得する。ヘッダ情報取得部Ｐ１３１は、取得したヘッダ情報を、セッション識別情報と対応付けて、ＩＦ選択部Ｐ１４へ出力する。なお、ヘッダ情報取得部Ｐ１３１は、インターフェース１５１−ｎ毎に、ＨＴＴＰのヘッダ情報を取得してもよい。
リダイレクト情報取得部Ｐ１３２は、通信部１５の送受信する情報から、セッション毎にＨＴＴＰのステータスコードを取得する。リダイレクト情報取得部Ｐ１３２は、取得しステータスコードを、セッション識別情報と対応付けて、ＩＦ選択部Ｐ１４へ出力する。ここで、ステータスコードがリダイレクションを示す場合、リダイレクト情報取得部Ｐ１３２は、リダイレクション先を示す情報も取得し、ＩＦ選択部Ｐ１４へ出力する。

ＩＦ選択部Ｐ１４は、通信装置１の各部から入力された情報に基づいて、セッション毎に、通信を行うインターフェース１５１−１〜１５１−Ｎを選択する。ＩＦ選択部Ｐ１４は、セッション毎に選択したインターフェース１５１−ｎにより、そのセッションでの通信を行わせる。これにより、ＩＦ選択部Ｐ１４は、各セッションの無線リンクを切り換える。つまり、ＩＦ選択部Ｐ１４は、フォールバックとフェールバックを制御する。
データ合成部Ｐ１５は、通信部１５の受信した情報を合成し、合成後の情報を、例えばアプリケーション部１３１や記憶部１４へ出力する。例えば、データ合成部Ｐ１５は、あるセッションにおいて、少なくとも２つのインターフェース１５１−ｎを時間的に切り換えた場合、切り換え前後のデータを合成する。

＜フォールバックについて＞
図４は、本実施形態に係るフォールバックを説明するための説明図である。
この図において、符号Ｃ１１を付した図は通常状態Ｃ１１を表し、符号Ｃ１２を付した図は単一フォールバックの状態Ｃ１２を表し、符号Ｃ１３を付した図はフォールバックの状態（フォールバック状態とも称する）Ｃ１３を表す。通常状態Ｃ１１から状態Ｃ１２へは、通信が失敗した場合に遷移する。また、状態Ｃ１２から状態Ｃ１３へは、ＦＢセッション数が許容数（単に許容数とも称する）を超えた場合に遷移する。なお、通信部１５からホストへ向かう矢印各々は、各セッションの通信を表す。

通常状態Ｃ１１では、通信部１５とホスト（例えば、アクセスポイントＡＰ１及び基地局装置ＢＳ１）は、全てのセッションにおいて、Ｗｉ−Ｆｉ通信を行う状態である。状態Ｃ１２は、一部のセッションについて、Ｗｉ−Ｆｉ通信Ｃ１２１を止め、ＬＴＥ通信又は３Ｇ通信（セルラー通信とも称する）Ｃ１２２へ切り換わった状態である。つまり、状態Ｃ１２は、あるセッションに対して、通信Ｃ１２１から通信Ｃ１２２へ、単一フォールバックが行われた状態である。
状態Ｃ１３は、全てのセッションにおいて、セルラー通信を行う状態である。状態Ｃ１３は、セルラー通信が優先される状態であり、例えば、許容数を超えた場合、他のＷｉ−Ｆｉ通信からセルラー通信へ遷移される状態である。なお、許容数を超えた場合、Ｗｉ−Ｆｉ通信を行っている最中のセッションがあった場合、そのセッションは、その通信の完了後に、セルラー通信へ遷移される。また、状態Ｃ１３は、新規のセッションに対して、セルラー通信が割り当てられる状態である。

以下、フォールバックについて、図２、３を参照しながら詳細を説明する。なお、以下では、フォールバックを行う元の無線リンクを「ＦＢ元リンク」とも称し、フォールバックを行う先の無線リンクを「ＦＢ先リンク」とも称する。例えば、ＦＢ元リンクはＷｉ−Ｆｉ通信であり、ＦＢ先リンクはＬＴＥ通信である。また、「ＦＢ元リンク」の場合に通信を行うインターフェース１５１−ｉ（ｉ＝１，２，・・・，Ｎのいずれか）をＦＢ元インターフェース１５１−ｉとも称し、「ＦＢ先リンク」の場合に通信を行うインターフェース１５１−ｋ（ｋ＝１，２，・・・，Ｎのいずれか、ｋ≠ｉ）をＦＢ先インターフェース１５１−ｋとも称する。

単一フォールバックを行う条件（単一フォールバック条件とも称する）は、次の（Ａ１）〜（Ａ６）のいずれかである。
（Ａ１）セッションがタイムアウトしたとき
（Ａ２）名前解決処理がタイムアウトしたとき
（Ａ３）スループットが低下したとき
（Ａ４）セッションが確立できなかったとき
（Ａ５）名前解決処理に失敗したとき
（Ａ６）通信中にソケットエラーが発生したとき
以下、これらの（Ａ１）〜（Ａ６）について説明する。

（Ａ１）セッションがタイムアウトしたとき
通信装置１は、ホストとのソケット接続をした時にタイムアウトした場合、単一フォールバックを行う。ここで、ソケット接続とは、接続要求用のインターフェース（例えば、ｓｏｃｋｅｔ（）、ｂｉｎｄ（）等）による接続である。具体的には、ＩＦ選択部Ｐ１４は、入力されたセッション異常情報がタイムアウトを示す場合、セッション識別情報が示すセッションの通信について、ＦＢ先インターフェース１５１−ｋを選択する。これにより、通信装置１は、ＦＢ元インターフェース１５１−ｉでの通信からＦＢ先インターフェース１５１−ｋでの通信へ切り換えることができ、ＦＢ元リンクからＦＢ先リンクへ通信を切り換える。

なお、セッション管理部Ｐ１１１は、ＦＢ元リンクに関連するタイムアウト時間の初期値（初期タイムアウト時間とも称する）、最大タイムアウト時間、単一フォールバックの許容数を、予め記憶する記憶部１４から読み出す。セッション管理部Ｐ１１１は、ＦＢセッション数に比例して、以下の計算によりタイムアウト時間を延ばす。具体的には、セッション管理部Ｐ１１１は、タイムアウト増加時間を、次の式により算出する。
タイムアウト増加時間＝（最大タイムアウト時間−初期タイムアウト時間）÷（許容数−１）
セッション管理部Ｐ１１１は、ＦＢ先リンクに関連する計算方法に応じて、ダイムアウト増加時間を計算する。例えば本実施形態において、セルラー接続の場合には、初期タイムアウト時間が「２０００ミリ秒」、最大タイムアウト時間が「３０００秒」、許容数が「５個」の場合、タイムアウト時間は、１セッションを単一フォールバックする毎に「２５０ミリ秒」ずつ増加することとなる。

すなわち、セッション管理部Ｐ１１１は、ＦＢセッション数に応じて、タイムアウト時間を線形的に増加させることとなる。例えば、タイムアウト時間は、次の式で表すことができる。
タイムアウト時間＝（最大タイムアウト時間−初期タイムアウト時間）÷（許容数−１）×ＦＢセッション数＋初期タイムアウト時間

なお、セッション管理部Ｐ１１１は、タイムアウト時間を非線形的に増加させてもよい。例えば、セッション管理部Ｐ１１１は、ＦＢセッション数に応じて、タイムアウト時間を、二次関数的に増加させてもよい。この場合、例えば、タイムアウト時間は、次の式で表すことができる。
タイムアウト時間＝（（最大タイムアウト時間−初期タイムアウト時間）÷（許容数−１）＾２）×ＦＢセッション数＾２＋初期タイムアウト時間

このように、通信装置１は、通信不能と判定するタイムアウト時間に対して、ＦＢセッション数を用いて重みづけを行うため、ＦＢセッション数が１本よりも２本、２本よりも３本、、徐々にフォールバックしにくくなるようにすることができる。
なお、セッション管理部Ｐ１１１は、ＦＢセッション数に応じて、タイムアウト時間を指数関数的または対数関数的に増加させてもよい。

なお、上述のタイムアウト時間の算出例では、初期タイムアウト時間が予め設定された固定値であるが、ＦＢセッション数が許容数以下の本数で常に安定しているような応答の遅延量をもつシステムの場合には、そのＦＢセッション数に基づいて、初期タイムアウト時間を再設定してもよい。例えば、通信装置１は、ＦＢセッション数が０以外の特定の本数Ｍ（Ｍは、整数）で安定する場合、本数「Ｍ＋１」のときのタイムアウト時間を閾値として、初期タイムアウト時間にフィードバック（再設定）するようにしてもよい。これにより、通信装置１は、無駄にＭ本のフォールバックを繰り返さなくても、システムのもつ応答の遅延量まで、フォールバックを保留することができる。

セッション管理部Ｐ１１１は、セルラー接続（ＬＴＥ通信又は３Ｇ通信の接続）の場合、タイムアウト時間を、予め記憶する記憶部１４から読み出す。セルラー接続の場合、タイムアウト時間は、例えば、固定値（例えば、３０００ミリ秒）である。
セッション管理部Ｐ１１１は、各通信種別（Ｗｉ−Ｆｉ又はセルラーの種別）のソケット接続に対する応答が、その通信種別のタイムアウト時間を超えた場合、セッション異常とする。例えば、セッション管理部Ｐ１１１は、Ｊａｖａ（登録商標。以下同じ）のプログラム（クラス、インスタンス、メソッド、又は属性等も、プログラムと称する）の場合、Ｃｏｎｎｅｃｔ（）にタイムアウト時間を設定し、ＳｏｃｋｅｔＴｉｍｅｏｕｔＥｘｃｅｐｔｉｏｎが発生した場合、セッション異常とする。その場合、セッション管理部Ｐ１１１は、タイムアウトを示すセッション異常情報を、ＩＦ選択部Ｐ１４へ出力する。
なお、セルラー接続の場合も、Ｗｉ−Ｆｉ接続の場合と同様に、ＦＢセッション数に応じてタイムアウト時間を変更してもよい。

（Ａ２）名前解決処理がタイムアウトしたとき
通信装置１は、名前解決でＤＮＳサーバへ接続をした時にタイムアウトした場合に単一フォールバックを行う。なお、Ｗｉ−Ｆｉ通信の場合、ＤＮＳ管理部Ｐ１１２は、ＤＮＳサーバからホスト名等を取得する。具体的には、ＩＦ選択部Ｐ１４は、入力された名前解決異常情報がタイムアウトを示す場合、セッション識別情報が示すセッションの通信について、ＦＢ先インターフェース１５１−ｋを選択する。

なお、ＤＮＳ管理部Ｐ１１２は、ＤＮＳサーバへの接続のタイムアウト時間を、予め記憶する記憶部１４から読み出す。セルラー接続のタイムアウト時間は、例えば、固定値（例えば、１０００ミリ秒）である。また、ＤＮＳ管理部Ｐ１１２は、ＤＮＳサーバへの接続がタイムアウトした場合、例えば１秒後に、再接続（リトライ）を行う。再接続に失敗した場合、ＤＮＳ管理部Ｐ１１２は、名前解決異常とする。また、ＤＮＳ管理部Ｐ１１２は、Ｊａｖａのプログラムの場合、ＩｎｔｅｒｒｕｐｔｅｄＩＯＥｘｃｅｐｔｉｏｎが発生した場合、名前解決異常とする。ＩｎｔｅｒｒｕｐｔｅｄＩＯＥｘｃｅｐｔｉｏｎは、入出力処理で割り込みが発生したことを通知するシグナルを発生させる。ＤＮＳ管理部Ｐ１１２は、名前解決異常とした場合、名前解決異常情報を、ＩＦ選択部Ｐ１４へ出力する。
なお、名前解決処理がタイムアウトしたときに単一フォールバックを行う場合も、セッションがタイムアウトしたときと同様に、ＦＢセッション数に応じてタイムアウト時間を変更してもよい。

（Ａ３）スループットが低下したとき
通信装置１は、スループットが低下した場合、単一フォールバックを行う。具体的には、ＩＦ選択部Ｐ１４は、入力されたスループット情報が示すスループットが、記憶部１４が記憶する閾値（スループット閾値とも称する）以下になった場合、セッション識別情報が示すセッションの通信について、ＦＢ先インターフェース１５１−ｋを選択する。
なお、スループット閾値は、通信方式に応じて異なる値であってもよい。例えば、スループット閾値は、ＬＴＥ通信の場合には５１２Ｋｂｐｓである。一方、ＵＭＴＳ／ＨＳ（Ｄ）ＰＡ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ／Ｈｉｇｈ Ｓｐｅｅｄ （Ｄｏｗｎｌｉｎｋ） Ｐａｃｋｅｔ Ａｃｃｅｓｓ）の場合には、スループット閾値は、２５６Ｋｂｐｓである。

また、スループット取得部Ｐ１１３は、下りの通信のスループットを測定する場合、各セッションについて、受信を開始（例えば、応答を１ｂｙｔｅでも読み込んだ時点）から計測を開始する。ここで、スループット取得部Ｐ１１３は、応答データの読込み開始前にスレッドを生成して、非同期で監視する。スループット取得部Ｐ１１３は、１秒間に取得するレスポンスデータの情報量を、バイトサイズにて計測する。例えば、通信部１５が１秒間に６４ＫＢ（キロバイト）を取得した場合は、スループットは、５１２Ｋｂｐｓ（キロビット／秒）となる。スループット取得部Ｐ１１３は、フォールバック後は、ソケット接続から開始するので、ＦＢ元リンクで取得した応答（既に元アプリに流している応答）の情報量（バイト数）までは読み飛ばし、それ以降に受信した情報量を計測してもよい。

（Ａ４）セッションが確立できなかったとき
通信装置１は、ホストとのソケット接続に失敗した場合、単一フォールバックを行う。具体的には、ＩＦ（インターフェース）選択部Ｐ１４は、入力されたセッション異常情報が接続失敗を示す場合、セッション識別情報が示すセッションの通信について、ＦＢ先インターフェース１５１−ｋを選択する。なお、セッション管理部Ｐ１１１は、Ｊａｖａのプログラムのとき、ソケット接続に時にＩＯＥｘｃｅｐｔｉｏｎを捕えた（キャッチした）場合、セッション異常とする。ＩＯＥｘｃｅｐｔｉｏｎは、ＩＯ（入出力）エラーが発生したときに投げられる例外である。セッション管理部Ｐ１１１は、セッション異常とした場合、セッション異常情報をＩＦ選択部Ｐ１４へ出力する。

（Ａ５）名前解決処理に失敗したとき
通信装置１は、ＤＮＳサーバとのソケット接続に失敗した場合、単一フォールバックを行う。具体的には、ＩＦ選択部Ｐ１４は、入力された名前解決異常情報が接続失敗を示す場合、セッション識別情報が示すセッションの通信について、ＦＢ先インターフェース１５１−ｋを選択する。

なお、ＤＮＳ管理部Ｐ１１２は、ＤＮＳサーバへの接続のタイムアウト時間を、予め記憶する記憶部１４から読み出す。ＤＮＳサーバへの接続に失敗に、例えば１秒後に、再接続を行う。再接続に失敗した場合、ＤＮＳ管理部Ｐ１１２は、名前解決異常とする。例えば、ＤＮＳ管理部Ｐ１１２は、Ｊａｖａのプログラムのとき、ソケット接続に時にＩＯＥｘｃｅｐｔｉｏｎを捕えた場合、名前解決異常とする。また、ＤＮＳ管理部Ｐ１１２は、名前解決後のＩＰアドレスをチェックし、例えばＩＰアドレスがｎｕｌｌの場合、名前解決異常とする。ＤＮＳ管理部Ｐ１１２は、名前解決異常とした場合、名前解決異常情報を、ＩＦ選択部Ｐ１４へ出力する。

（Ａ６）通信中にソケットエラーが発生したとき
通信装置１は、ＦＢ元での通信中にソケットエラーが発生した場合、単一フォールバックを行う。具体的には、ＩＦ選択部Ｐ１４は、入力されたセッション異常情報がソケットエラーを示す場合、セッション識別情報が示すセッションの通信について、ＦＢ先インターフェース１５１−ｋを選択する。なお、セッション管理部Ｐ１１１は、Ｊａｖａのプログラムのとき、通信中にＳｏｃｋｅｔＥｘｃｅｐｔｉｏｎが発生した場合、セッション異常とする。ＳｏｃｋｅｔＥｘｃｅｐｔｉｏｎとは、ソケットエラーが発生したときに投げられる例外である。セッション管理部Ｐ１１１は、セッション異常とした場合、ソケットエラーを示すセッション異常情報を、ＩＦ選択部Ｐ１４へ出力する。

フォールバック状態（図４の状態Ｃ１３）へ遷移する条件は、以下のとおりである。
（Ｂ１）ＦＢセッション数が許容数を超えたとき
具体的には、ＩＦ選択部Ｐ１４は、入力されたＦＢセッション数情報が示すＦＢセッション数が、記憶部１４が予め記憶する許容数（例えば「５」個）を超えたと判定した場合、全てのセッションについて、ＬＴＥ通信のインターフェース１５１−２を選択する。これにより、通信部１５は、図４の状態Ｃ１３が表わす通信を行うこととなる。なお、セッション管理部Ｐ１１１は、（Ａ１）セッションがタイムアウトしたとき、（Ａ２）名前解決処理がタイムアウトしたとき、（Ａ３）スループットが低下したときに、単一フォールバックをしたセッション数を、ＦＢセッション数とする。ただし、本発明はこれに限らず、（Ａ１）〜（Ａ６）のすべての場合で、フォールバックをしたセッション数を、ＦＢセッション数としてもよい。
また、ＩＦ選択部Ｐ１４は、あるセッションにおいて、（Ａ４）セッションが確立できなかったとき、又は、（Ａ５）名前解決処理に失敗したとき、（Ａ６）通信中にソケットエラーが発生したときには、全てのセッションについて、ＬＴＥ通信のインターフェース１５１−２を選択してもよい。

＜フェールバックについて＞
図５は、本実施形態に係るフェールバックを説明するための説明図である。なお、フェールバックとは、フォールバックとは逆の切り換えを行うことで、フォールバック前の状態に戻すことをいう。
この図において、通常状態Ｃ１１とフォールバック状態Ｃ１３は、図４のものと同じである。符号Ｃ２２を付した図は、フェールバックの状態（フェールバック状態とも称する）Ｃ２２を表す。フォールバック状態Ｃ１３からフェールバックの状態へは、後述するフェールバック条件を充足した場合に遷移する。また、状態Ｃ２２から状態Ｃ１１へは、順次、遷移する。なお、通信部１５からホストへ向かう矢印各々は、各セッションの通信を表す。

状態Ｃ２２は、一部のセッションについて、セルラー通信Ｃ２２１を止め、Ｗｉ−Ｆｉ通信Ｃ２２２へ切り換わった状態である。つまり、状態Ｃ２２は、あるセッションに対して、通信Ｃ２２１から通信Ｃ２２２へ、フェールバックが行われた状態である。なお、フェールバックを行うときに、セルラー通信を行っている最中のセッションがあった場合、そのセッションは、その通信の完了後に、Ｗｉ−Ｆｉ通信へ移行される。例えば、そのセッションは、通信の完了までは、同じベアラで通信が継続することとなる。また、状態Ｃ２２、Ｃ１１は、新規のセッションに対して、Ｗｉ−Ｆｉ通信が割り当てられる状態である。

以下、フェールバックについて、図２、３を参照しながら詳細を説明する。なお、フェールバックを行う元の無線リンクは上述のＦＢ先リンクであり、フェールバックを行う先の無線リンクは上述のＦＢ元リンクである。

フェールバック条件は、次の（Ｃ１）〜（Ｃ５）のいずれかである。
（Ｃ１）ＦＢ元リンクの信号強度が上昇したとき
（Ｃ２）フォールバックから１分が経過したとき
（Ｃ３）アクセスポイントが変わったとき
（Ｃ４）ＬＴＥ通信が３Ｇ通信に変わったとき
（Ｃ５）通信中にソケットエラーが発生したとき

（Ｃ１）ＦＢ元リンクの信号強度が上昇したとき
通信装置１は、ＦＢ元リンクの信号強度が、フォールバックしたときより予め定めた強度以上に上昇した場合、フェールバックを行う。具体的には、ＩＦ選択部Ｐ１４は、随時入力されるＦＢ元インターフェース１５１−ｉの信号強度情報について、フォールバックしたときの信号強度情報（ＦＢ信号強度情報とも称する）を記憶部１４に記憶し、現在の信号強度情報からＦＢ信号強度情報を差し引く。ＩＦ選択部Ｐ１４は、差し引いた値（強度差とも称する）が予め定めた閾値以上であれば、フェールバックを行う。例えば、ＦＢ元リンクの通信方式がＷｉ−Ｆｉ通信の場合、ＩＦ選択部Ｐ１４は、ＲＳＳＩの強度差が２ランク（アンテナ２本分）以上になった場合、ＦＢ元インターフェース１５１−ｉを選択する。これにより、通信装置１は、ＦＢ先インターフェース１５１−ｋでの通信からＦＢ元ンターフェース１５１−ｉでの通信へ切り換えることができ、ＦＢ先リンクからＦＢ元リンクへ通信を切り換える。なお、ＩＦ選択部Ｐ１４は、現在の信号強度情報とＦＢ信号強度情報との比を算出して閾値と比較してもよい。

なお、ＩＦ選択部Ｐ１４は、ＦＢ信号強度情報が３ランク（アンテナ３本分）のとき、現在の信号強度情報が４ランク（アンテナ４本分：最大ランク）になった場合、強度さが１ランクであっても、フェールバックを行う。また、ＩＦ選択部Ｐ１４は、現在の信号強度情報が予め定めた値以上になった場合、フェールバックを行ってもよく、例えば、最高ランク（アンテナ４本分）になった場合、フェールバックを行ってもよい。
ここで、信号強度検出部１５２は、例えばＷｉｆｉＭａｎａｇｅｒを用いて実現される。ＷｉｆｉＭａｎａｇｅｒは、Ｗｉ−Ｆｉの情報を取得するプログラムであり、ＢＳＳＩＤ、ＩＰアドレス、ネットワークＩＤ等を取得できる。信号強度検出部１５２は、ＦＢ元インターフェース１５１−ｉでのＷｉＦｉ通信のＲＳＳＩを、例えば５秒間隔で検出する。信号強度検出部１５２は、検出したＲＳＳＩを示す信号強度情報を、５秒間隔で信号強度取得部Ｐ１２１を介して、ＩＦ選択部Ｐ１４へ出力する。

（Ｃ２）フォールバックから１分が経過したとき
通信装置１は、フォールバック状態Ｃ１３に遷移してから１分以上経過した場合、フェールバックを行う。具体的には、ＩＦ選択部Ｐ１４は、時間超過情報が入力された場合、つまり、フォールバックした時点から設定値（例えば、１分）の時間が経過した場合、ＦＢ元インターフェース１５１−ｉを選択する。

（Ｃ３）アクセスポイントが変わったとき
通信装置１は、ＦＢ元リンクの基地局の識別情報又はネットワークの識別情報が変更した場合、フェールバックを行う。具体的には、ＩＦ選択部Ｐ１４は、入力されたＡＰ識別情報が、フォールバックの前後で異なるか否かを判定する。フォールバックの前後で異なると判定した場合、ＩＦ選択部Ｐ１４は、ＦＢ元インターフェース１５１−ｉを選択する。なお、ＩＦ選択部Ｐ１４は、強制フォールバックの場合のみ、（Ｃ３）をフェールバック条件としてもよい。
ここで、ＡＰ情報取得部Ｐ１２３は、例えば、ＣＯＮＮＥＣＴＩＶＩＴＹ＿ＡＣＴＩＯＮを受信したときに、ＢＳＳＩＤを取得する。ＣＯＮＮＥＣＴＩＶＩＴＹ＿ＡＣＴＩＯＮは、ネットワークの接続状態が変化したときの通知を取得するプログラムである。

（Ｃ４）ＬＴＥ通信が３Ｇ通信に変わったとき
通信装置１は、ＦＢ先リンクの通信方式がＬＴＥであるときに、その後、その通信方式が３Ｇに変化した場合、フェールバックを行う。具体的には、ＩＦ選択部Ｐ１４は、フォールバックを行った後、入力された通信方式情報がＬＴＥから３Ｇに変わったときに、ＦＢ元インターフェース１５１−ｉを選択する。なお、ＩＦ選択部Ｐ１４は、強制フォールバックの場合のみ、（Ｃ４）をフェールバック条件としてもよい。ここで、通信方式情報取得部Ｐ１２４は、例えば、ＣＯＮＮＥＣＴＩＶＩＴＹ＿ＡＣＴＩＯＮを受信したときに、セルラータイプを取得することで、通信方式を取得する。なお、通信装置１は、通信をＬＴＥから３Ｇに変化させるとき、ヘッダ比較処理を行って、データを最初から取得するか或いは途中から取得するかを制御してもよい。ここで、通信装置１は、ＦＢ元リンク（Ｗｉ−Ｆｉ通信）を用いて取得したヘッダ情報とＦＢ先リンクでの変化後のリンク（３Ｇ通信）を用いて取得したヘッダを比較することで、ヘッダ比較処理を行ってもよい。

（Ｃ５）通信中にソケットエラーが発生したとき
通信装置１は、ＦＢ先での通信中にソケットエラーが発生した場合、フェールバックを行う。具体的には、ＩＦ選択部Ｐ１４は、入力されたセッション異常情報がソケットエラーを示す場合、ＦＢ元インターフェース１５１−ｉを選択する。

なお、フェールバックを行った場合、ＩＦ選択部Ｐ１４は、「強制フォールバックモード」の状態を解除してもよい。解除後は、ＩＦ選択部Ｐ１４は、Ｗｉ−Ｆｉ通信を優先して選択する。
また、フェールバックを行った後、ＦＢ元リンクの通信に失敗した場合、通信装置１は、フォールバックを行ってもよい。さらに、このフォールバックを行った後、ＦＢ先リンクでも通信に失敗した場合、通信装置１は、通信を止めてもよい。これにより、通信装置１は、フォールバックとフェールバックが繰り返され続けることを防止できる。

＜ヘッダ比較処理について＞
上記のフォールバックを行う場合、通信装置１は、ヘッダ比較処理を行う。具体的には、ヘッダ情報取得部Ｐ１３１は、フォールバックを行う前に、ＦＢ元リンクにおいて例えば予め定めたプロトコル（例えばＨＴＴＰ）のヘッダ情報（ＦＢ元ヘッダ情報とも称する）を取得したときに、取得したＦＢ元ヘッダ情報をＩＦ選択部Ｐ１４へ出力する。ＩＦ選択部Ｐ１４は、入力されたＦＢ元ヘッダ情報を、として記憶部１４に記憶させる。ヘッダ情報取得部Ｐ１３１は、フォールバックを行うときに、ＦＢ先リンクにおいてプロトコルのヘッダ情報（ＦＢ先ヘッダ情報）を取得し、取得したＦＢ先ヘッダ情報をＩＦ選択部Ｐ１４へ出力する。ＩＦ選択部Ｐ１４は、ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報を比較する。
ここで、ＩＦ選択部Ｐ１４は、ヘッダ情報のうち、ＨＴＴＰのデータ部分に差分があると判断できる情報を比較する。例えば、ＩＦ選択部Ｐ１４は、ヘッダ情報のうち、コンテンツのサイズを表す情報（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ）やコンテンツのバージョンや更新日時を示す情報を比較する。

比較の結果、ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報が同じであると判定した場合、ＩＦ選択部Ｐ１４は、セッション識別情報が示すセッションの通信について、ＦＢ先インターフェース１５１−ｋを選択する（フォールバックを行う）。
一方、比較の結果、ヘッダ情報Ｈ１とヘッダ情報Ｈ２が同じでないと判定した場合、ＩＦ選択部Ｐ１４は、セッション識別情報が示すセッションの通信について、ＦＢ元インターフェース１５１−ｉのままとする（フォールバックを中止する）。

ＩＦ選択部Ｐ１４は、ヘッダ情報Ｈ１とヘッダ情報Ｈ２が同じでないと判定した場合、リダイレクト情報取得部Ｐ１３２が取得したステータスコードに応じて、再度、フォールバックを試みてもよい。具体的には、ヘッダ情報Ｈ１とヘッダ情報Ｈ２が同じでないと判定した場合、ヘッダ情報取得部Ｐ１３１は、リダイレクト情報取得部Ｐ１３２が取得したリダイレクション先に対して、ＨＴＴＰのレンジリクエストを行う。ヘッダ情報取得部Ｐ１３１は、レンジリクエストの結果、新たなヘッダ情報を取得し、取得したヘッダ情報を、ＦＢ先ヘッダ情報としてＩＦ選択部Ｐ１４へ出力する。ＩＦ選択部Ｐ１４は、新たに取得したＦＢ先ヘッダ情報とＦＢ元ヘッダ情報を比較する。
比較の結果、ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報が同じであると判定した場合、ＩＦ選択部Ｐ１４は、セッション識別情報が示すセッションの通信について、ＦＢ先インターフェース１５１−ｋを選択する（フォールバックを行う）。一方、比較の結果、ヘッダ情報Ｈ１とヘッダ情報Ｈ２が同じでないと判定した場合、ＩＦ選択部Ｐ１４は、セッション識別情報が示すセッションの通信について、ＦＢ元インターフェース１５１−ｉのままとする（フォールバックを中止する）。

図６は、本実施形態に係る通信装置１の状態遷移を表す図である。この図において、Ｓ１１を付した状態Ｓ１１は、Ｗｉ−Ｆｉ通信を行う状態（ＷｉＦｉ通信状態Ｓ１１とも称する）を示す。Ｓ１２を付した状態Ｓ１２は、セルラー通信を行う状態（セルラー通信状態Ｓ１２とも称する）を示す。
通信装置１は、ＷｉＦｉ通信状態Ｓ１１であるとき、Ｗｉ−Ｆｉ通信が良好な場合、例えば、上記の単一フォールバックを行う条件（Ａ１）〜（Ａ６）に該当しない場合、ＷｉＦｉ通信状態Ｓ１１のままである。一方、通信装置１は、ＷｉＦｉ通信状態Ｓ１１であるとき、上記の単一フォールバックを行う条件（Ａ１）〜（Ａ６）に該当した場合、フォールバックを行うことで、セルラー通信状態Ｓ１２へ遷移する。

通信装置１は、セルラー通信状態Ｓ１２であるとき、例えば、上記のフェールバック条件（Ｃ１）〜（Ｃ５）に該当しない場合、セルラー通信状態Ｓ１２のままである。また、通信装置１は、セルラー通信状態Ｓ１２であるとき、セルラー通信に失敗した場合にも、セルラー通信状態Ｓ１２のままである。一方、通信装置１は、セルラー通信状態Ｓ１２であるとき、例えば、上記のフェールバック条件（Ｃ１）〜（Ｃ５）に該当した場合、フェールバックを行うことで、ＷｉＦｉ通信状態Ｓ１１へ遷移する。

図７は、本実施形態に係る通信装置１の状態遷移についての説明図である。この図において、各列は、条件、Ｗｉ−Ｆｉ通信状態Ｓ１１、セルラー通信状態Ｓ１２を表す。符号Ｔ１１を付した情報は、条件が、セッションのタイムアウト（セッション接続タイムアウト）又は名前解決処理のタイムアウト（ＤＮＳ接続タイムアウト）である場合を表す。以下では、セッション又は名前解決処理のタイムアウトを、タイムアウトとも称する。

例えば、行の情報（行情報とも称する）Ｔ１１１は、Ｗｉ−Ｆｉ通信でタイムアウトせず（接続成功）、セルラー通信でもタイムアウトしない（接続成功）ときに、通信装置１がＷｉ−Ｆｉ通信状態Ｓ１１であればＷｉ−Ｆｉ通信状態Ｓ１１を継続し、セルラー通信状態Ｓ１２であればセルラー通信状態Ｓ１２を継続することを表す。行情報Ｔ１１２は、Ｗｉ−Ｆｉ通信でタイムアウトせず（接続成功）、セルラー通信でタイムアウトした（接続失敗）ときに、通信装置１がＷｉ−Ｆｉ通信状態Ｓ１１であればＷｉ−Ｆｉ通信状態Ｓ１１を継続し、セルラー通信状態Ｓ１２であれば通信接続を止めることを表す。行情報Ｔ１１３は、Ｗｉ−Ｆｉ通信でタイムアウトし（接続失敗）、セルラー通信でタイムアウトしない（接続成功）ときに、通信装置１がＷｉ−Ｆｉ通信状態Ｓ１１であればセルラー通信状態Ｓ１２へ遷移し（単一フォールバック条件（Ａ１）、（Ａ２））、セルラー通信状態Ｓ１２であればセルラー通信状態Ｓ１２を継続することを表す。なお、図７において、「フォールバック（※）」のように※を付したフォールバックは、単一フォールバックをした場合、セッション管理部Ｐ１１１がＦＢセッション数として計数するものである。

符号Ｔ１２を付した情報は、条件が、セッションの確立の成否（セッション接続）と名前解決処理の成否（名前解決）である場合を表す。以下では、セッションの確立又は名前解決処理を、接続処理とも称する。例えば、行情報Ｔ１２３は、Ｗｉ−Ｆｉ通信で接続処理に失敗し（接続失敗）、セルラー通信で接続処理に成功した（接続成功）ときに、通信装置１がＷｉ−Ｆｉ通信状態Ｓ１１であればセルラー通信状態Ｓ１２へ遷移し（単一フォールバック条件（Ａ４）、（Ａ５））、セルラー通信状態Ｓ１２であればセルラー通信状態Ｓ１２を継続することを表す。

符号Ｔ１３を付した情報は、条件が状態監視の結果によるものであることを表す。行情報Ｔ１３１は、スループットが低下したときに、通信装置１がＷｉ−Ｆｉ通信状態Ｓ１１であればセルラー通信状態Ｓ１２へ遷移する（単一フォールバック条件（Ａ３））ことを表す。行情報Ｔ１３２は、Ｗｉ−Ｆｉ通信の信号強度が上昇したときに、通信装置１がセルラー通信状態Ｓ１２であればＷｉ−Ｆｉ通信状態Ｓ１１へ遷移する（フェールバック条件（Ｃ１））ことを表す。行情報Ｔ１３３は、アクセスポイントが変わったときに、通信装置１がセルラー通信状態Ｓ１２であればＷｉ−Ｆｉ通信状態Ｓ１１へ遷移する（フェールバック条件（Ｃ３））ことを表す。行情報Ｔ１３４は、ＬＴＥ通信が３Ｇ通信に変わったときに、通信装置１がセルラー通信状態Ｓ１２であればＷｉ−Ｆｉ通信状態Ｓ１１へ遷移する（フェールバック条件（Ｃ４））ことを表す。

符号Ｔ１４を付した情報は、その他の条件を表す。行情報Ｔ１４１は、フォールバックから１分が経過したときに、通信装置１がセルラー通信状態Ｓ１２であればＷｉ−Ｆｉ通信状態Ｓ１１へ遷移する（フェールバック条件（Ｃ２））ことを表す。行情報Ｔ１４２は、通信中にソケットエラー（ＳｏｃｋｅｔＥｘｃｅｐｔｉｏｎ）が発生したときに、通信装置１がＷｉ−Ｆｉ通信状態Ｓ１１であればセルラー通信状態Ｓ１２へ遷移し（単一フォールバック条件（Ａ６））、セルラー通信状態Ｓ１２であればＷｉ−Ｆｉ通信状態Ｓ１１へ遷移する（フェールバック条件（Ｃ５））ことを表す。例えば、ＩＦ選択部Ｐ１４は、セッション管理部Ｐ１１１がソケットエラーを検出した場合、ＦＢ元インターフェース１５１−ｉを選択する。これにより、通信装置１は、ＦＢ先インターフェース１５１−ｋでの通信からＦＢ元ンターフェース１５１−ｉでの通信へ切り換えることができ、ＦＢ先リンクからＦＢ元リンクへ通信を切り換える。

＜処理フロー＞
図８は、本実施形態に係る通信装置１の処理フローを示す図である。なお、この図において、ステップＳ１０３、Ｓ１０４、Ｓ１０５、Ｓ１１１、Ｓ１２１、Ｓ１２２、Ｓ１２８、Ｓ１２９は、Ｗｉ−Ｆｉ通信（ＦＢ元）の情報処理である。ステップＳ１０６、Ｓ１０７、Ｓ１０８、Ｓ１２３、Ｓ１２４、Ｓ１２５は、セルラー通信（ＦＢ先）の情報処理である。

（ステップＳ１０１）ＩＦ選択部Ｐ１４は、全てのセッションでフォールバック中であるか否か、つまり、図４のフォールバック状態Ｓ１３であるか否かを判定する。全てのセッションでフォールバック中であると判定された場合（Ｙｅｓ）、ステップＳ１０２へ進む。一方、少なくとも一部のセッションでフォールバック中ではないと判定した場合（Ｎｏ）、ステップＳ１０３へ進む。

（ステップＳ１０２）ＩＦ選択部Ｐ１４は、通信がＤＬＭ（ＤｏｗｎｌｏａｄＭａｎａｇｅｒ）による情報の取得であるか否かを判定する。ＤｏｗｎｌｏａｄＭａｎａｇｅｒとは、サイズの大きいファイルを取得するときに用いるプログラムである。換言すれば、ＩＦ選択部Ｐ１４は、サイズの大きいファイルを取得するか否かを判定する。ＤＬＭによる情報の取得であると判定された場合（Ｙｅｓ）、ステップＳ１０３へ進む。一方、ＤＬＭによる情報の取得ではないと判定された場合（Ｎｏ）、ステップＳ１０６へ進む。

（ステップＳ１０３）ＤＮＳ管理部Ｐ１１２は、Ｗｉ−Ｆｉ通信を用いたＤＮＳリクエストにより、ドメインネーム情報（例えば、ＩＰアドレス）の取得を要求する。この要求の結果、ドメインネーム情報が取得された場合、ステップＳ１０４へ進む。一方、ドメインネーム情報が取得されなかった場合、ＩＦ選択部Ｐ１４がＦＢ先インターフェース１５１−ｋを選択することで、ステップＳ１０６へ進む。
（ステップＳ１０４）セッション管理部Ｐ１１１は、Ｗｉ−Ｆｉ通信を用いた接続要求（Ｃｏｎｎｅｃｔ）により、コンテンツサーバへの接続を要求する。この要求の結果、セッション管理部Ｐ１１１が接続に失敗した場合、ステップＳ１０６へ進む。一方、セッション管理部Ｐ１１１が接続に成功した場合、ステップＳ１０５へ進む。

（ステップＳ１０５）ヘッダ情報取得部Ｐ１３１は、Ｗｉ−Ｆｉ通信を用いて、ＦＢ元ヘッダ情報の取得を要求する（ヘッダＤＬ（Ｗｉ−Ｆｉ））。ＦＢ元ヘッダ情報が取得された場合、容量情報取得部Ｐ１１４は、ＦＢ元ヘッダ情報を記憶させるとともに、ＦＢ元ヘッダ情報から取得対象のコンテンツサイズを抽出する。また、制御部１３は、コンテンツの取得を開始する。
制御部１３がコンテンツの取得を行っているとき、容量情報取得部Ｐ１１４は、随時、ＤＬ済サイズを算出する。また、容量情報取得部Ｐ１１４は、コンテンツサイズからＤＬ済サイズを差し引くことで、残サイズを算出する。残サイズとは、取得するコンテンツのうち、取得が済んでいないコンテンツの容量である。また、制御部１３がコンテンツの取得を行っているとき、随時、スループット取得部Ｐ１１３は、予め定めた時間間隔で、スループットを算出する。

（ステップＳ１０６）ＤＮＳ管理部Ｐ１１２は、セルラー通信を用いたＤＮＳリクエストにより、ドメインネーム情報の取得を要求する。この要求の結果、ドメインネーム情報が取得された場合、ステップＳ１０７へ進む。一方、ドメインネーム情報が取得されなかった場合、ステップＳ１１０へ進む。
（ステップＳ１０７）セッション管理部Ｐ１１１は、セルラー通信を用いた接続要求により、コンテンツサーバへの接続を要求する。この要求の結果、セッション管理部Ｐ１１１が接続に失敗した場合、ステップＳ１１０へ進む。一方、セッション管理部Ｐ１１１が接続に成功した場合、ステップＳ１０８へ進む。

（ステップＳ１０８）ヘッダ情報取得部Ｐ１３１は、セルラー通信を用いて、ＦＢ先ヘッダ情報の取得を要求する（ヘッダＤＬ（Ｃｅｌｌｕｌａｒ））。ＦＢ先ヘッダ情報が取得された場合、容量情報取得部Ｐ１１４は、ＦＢ先ヘッダ情報から、取得対象のコンテンツサイズを抽出する。その後、ステップＳ１０９へ進む。
（ステップＳ１０９）ＩＦ選択部Ｐ１４は、ステップＳ１０８で抽出したコンテンツサイズが予め定められたＦＢ許容サイズより大きいか否かを判定する。ＦＢ許容サイズとは、フォールバックを許容するコンテンツの容量を示す情報である。コンテンツサイズがＦＢ許容サイズより大きいと判定された場合（Ｙｅｓ）、ステップＳ１１０へ進む。一方、コンテンツサイズがＦＢ許容サイズ以下であると判定された場合（Ｎｏ）、制御部１３は、セルラー通信を用いて、コンテンツの取得を開始する。
（ステップＳ１１０）ＩＯＥｘｃｅｐｔｉｏｎ又はＩｎｔｅｒｒｕｐｔｅｄＩＯＥｘｃｅｐｔｉｏｎが投げられる。この場合、制御部１３は、良好な接続がない又は無条件でのフォールバックが不可能と判定して、通信装置１の通信接続を止める。

（ステップＳ１１１）ＩＦ選択部Ｐ１４は、スループット取得部Ｐ１１３が算出したスループットがスループット閾値以下になったか否かを判定する。スループットがスループット閾値より高い場合、制御部１３は、Ｗｉ−Ｆｉ通信を用いて、コンテンツの取得を継続する。一方、スループットがスループット閾値以下になったと判定された場合、ステップＳ１１２へ進む。

（ステップＳ１１２）ＩＦ選択部Ｐ１４は、ステップＳ１０５で算出された残サイズ、つまり、ステップＳ１１２（又はＳ１１１）の時点で取得が済んでいないコンテンツの容量が、予め定められたＦＢ許容サイズより大きいか否かを判定する。残サイズがＦＢ許容サイズより大きいと判定された場合（Ｙｅｓ）、ステップＳ１１３へ進む。一方、残サイズがＦＢ許容サイズ以下であると判定された場合（Ｎｏ）、ステップＳ１２１へ進む。
（ステップＳ１１３）ＩＦ選択部Ｐ１４は、全てのセッションでフォールバック中であるか否かを判定する。全てのセッションでフォールバック中であると判定された場合（Ｙｅｓ）、ステップＳ１１２へ戻る。この場合、制御部１３は、定期的なポーリング（定期的な問合せ）を行う。なお、全てのセッションでフォールバック中であると判定される（Ｙｅｓ）のは、ステップＳ１０２で、ＤＬＭによる情報の取得であると判定された場合のみである。一方、少なくとも一部のセッションでフォールバック中ではないと判定された場合（Ｎｏ）、ステップＳ１１４へ進む。

（ステップＳ１１４）制御部１３は、出力部１２に対して、ユーザにフォールバックするか否かを確認する情報を出力させる。例えば、出力部１２は、「サイズの大きい通信です。フォールバックをしますか」と表示させる。例えば、コンテンツをセルラー通信で取得する場合とＷｉ−Ｆｉ通信で取得する場合では、料金が異なる場合がある。つまり、通信装置１は、サイズの大きいコンテンツをセルラー通信で取得する場合、Ｗｉ−Ｆｉ通信と比較して高額の料金がかかる場合があるため、コンテンツをセルラー通信で取得してもよいか否かをユーザに確認している。
出力部１２の出力に対して入力部１１からの入力がない場合（未選択）、ステップＳ１１２へ戻る。この場合、制御部１３は、定期的なポーリングを行う。入力があったとき、入力部１１からの入力がフォールバックをすることを示す場合（Ｙｅｓ）、ＩＦ選択部Ｐ１４はフォールバックが許容されたと判定し、ステップＳ１２１へ進む。一方、入力部１１からの入力がフォールバックをしないことを示す場合（Ｎｏ）、ステップＳ１２８へ進む。つまり、ユーザ操作によって、通信装置１は、フォールバックを行わないこととなる。

（ステップＳ１２１）制御部１３は、受信バッファの読み込みを停止する（ＲｅａｄＳｔｏｐ）。その後、ステップＳ１２２へ進む。
（ステップＳ１２２）制御部１３は、アプリバッファへの書き込みを停止する（ＷｒｉｔｅＳｔｏｐ）。つまり、制御部１３は、アプリケーションへのデータの出力を中断する。その後、ステップＳ１２３へ進む。

（ステップＳ１２３）ＤＮＳ管理部Ｐ１１２は、セルラー通信を用いたＤＮＳリクエストにより、ドメインネーム情報の取得を要求する。この要求の結果、ドメインネーム情報が取得された場合、ステップＳ１２４へ進む。一方、ドメインネーム情報が取得されなかった場合、ステップＳ１２８へ進む。
（ステップＳ１２４）セッション管理部Ｐ１１１は、セルラー通信を用いた接続要求により、コンテンツサーバへの接続を要求する。この要求の結果、セッション管理部Ｐ１１１が接続に失敗した場合、ステップＳ１２８へ進む。一方、セッション管理部Ｐ１１１が接続に成功した場合、ステップＳ１２５へ進む。

（ステップＳ１２５）ヘッダ情報取得部Ｐ１３１は、セルラー通信を用いて、ＦＢ先ヘッダ情報を取得する。その後、ステップＳ１２６へ進む。
（ステップＳ１２６）ＩＦ選択部Ｐ１４は、ステップＳ１０５で記憶させたＦＢ元ヘッダ情報と、ステップＳ１２５で取得したＦＢ先ヘッダ情報と、を比較する（ヘッダ比較処理）。比較の結果、ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報が同じでないと判定された場合（Ｙｅｓ）、ステップＳ１２７へ進む。一方、ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報が同じであると判定された場合（Ｎｏ）、制御部１３は、セルラー通信を用いて、コンテンツの取得を再開する。ここで、データ合成部Ｐ１５は、Ｗｉ−Ｆｉ通信で取得済みのコンテンツのデータを読み出し、セルラー通信を用いて、そのデータの続きからデータの取得を再開する。つまり、通信装置１は、フォールバックに成功する。
なお、ＩＦ選択部Ｐ１４は、ステップＳ１２６でＮｏと判定するまでは、フォールバック元の通信（Ｗｉ−Ｆｉ通信）でのセッションを継続させ続ける。

（ステップＳ１２７）ＩＦ選択部Ｐ１４は、リダイレクト情報取得部Ｐ１３２が取得したステータスコードがリダイレクションを示すか否かを判定する。ステータスコードがリダイレクションを示さないと判定された場合、ステップＳ１２８へ進む。
一方、ステータスコードがリダイレクションを示すと判定された場合、ステップＳ１２３へ戻る。この場合、ステップＳ１２３〜Ｓ１２５にて、リダイレクション先へ接続する。例えば、ステップＳ１２５にて、ヘッダ情報取得部Ｐ１３１は、リダイレクション先から取得したヘッダ情報を、ＦＢ先ヘッダ情報とする。その後、ステップＳ１２６で、新たなＦＢ先ヘッダ情報とＦＢ元ヘッダ情報が比較されることとなる。なお、ステップＳ１２７の処理は、１回だけ行われてもよい。つまり、制御部１３は、一度だけ、転送を許容してもよい。この場合、ＩＦ選択部Ｐ１４は、同じセッションにおいて、２回目以降のステップＳ１２７の処理を行わずに、ステップＳ１２８へ進む。

（ステップＳ１２８）制御部１３は、受信バッファの読み込みを再開する（ＲｅａｄＳｔａｒｔ）。つまり、制御部１３は、再度、Ｗｉ−Ｆｉ通信を用いて、コンテンツの取得を再開する。ここで、データ合成部Ｐ１５は、Ｗｉ−Ｆｉ通信で取得済みのコンテンツのデータを読み出し、Ｗｉ−Ｆｉ通信を用いて、そのデータの続きからデータの取得を再開する。つまり、通信装置１は、フォールバックを止めて、元のＦＢ元通信で、データの取得を再開する。
（ステップＳ１２９）制御部１３は、アプリバッファへの書き込みを再開する（ＷｒｉｔｅＳｔａｒｔ）。つまり、制御部１３は、アプリケーションへのデータの出力を再開する。
なお、ＩＦ選択部Ｐ１４は、ステップＳ１０１、Ｓ１１３において、通信装置１が強制フォールバックモードか否かを判定してもよい。

なお、ＤＮＳリクエスト、接続要求、又はヘッダ情報の取得において、制御部１３（セッション管理部Ｐ１１１、ＤＮＳ管理部Ｐ１１２又はヘッダ情報取得部Ｐ１３１）は、異常（失敗）と判断する時間を、ＦＢセッション数に応じて変えてもよい。例えば、制御部１３は、ＦＢセッション数が「０」の場合、通信の応答が「０．２」秒以上ない場合には異常と判定し、ＦＢセッション数が「３」の場合、通信の応答が「２．６」秒以上ない場合には異常と判定する。このように、例えば、制御部１３は、ＦＢセッション数が多くなる程、異常と判断する時間を長くする。これにより、通信装置１は、例えば、使用しているＷｉ−Ｆｉ通信の接続環境が恒常的に遅延しているときに、簡単に全ての通信がフォールバックをされてしまうことを防止できる。
また、ＩＦ選択部Ｐ１４は、ステップＳ１０１、Ｓ１１３において、通信装置１が強制フォールバックモードか否かを判定してもよい。

＜プロキシ部Ｐ１の処理フロー＞
図９及び図１０は、本実施形態に係るプロキシ部Ｐ１の処理フローを示す図である。なお、図１０は、図９の続きである。
（ステップＳ２０１）プロキシ部Ｐ１は、プロキシサービス（ＬａＰｒｏｘｙＳｅｒｖｉｃｅ）ＣＬ２１を生成する（ｏｎＣｒｅａｔｅ（））。その後、ステップＳ２０２へ進む。
（ステップＳ２０２）プロキシサービスＣＬ２１は、フォールバックを管理するＦＢ管理（ＦａｌｌｂａｃｋＭａｎａｇｅｒ）ＣＬ２２を生成する。その後、ステップＳ２０３へ進む。

（ステップＳ２０３）プロキシサービスＣＬ２１は、サーバーソケット（ＳｅｒｖｅｒＳｏｃｋｅｔ）を生成する。サーバーソケットは、ソケット接続を受け付けるプログラムである。その後、ステップＳ２０４へ進む。
（ステップＳ２０４）プロキシサービスＣＬ２１は、例えば通信装置１（アプリケーション部１３１）のアプリケーション（元アプリとも称する）から、ソケット接続のリクエストを受け付ける。その後、ステップＳ２０５へ進む。
（ステップＳ２０５）プロキシサービスＣＬ２１は、セッションを管理するＦＢセッション（ＦａｌｌｂａｃｋＳｅｓｓｉｏｎ）ＣＬ２３を生成する。その後、ステップＳ２０６へ進む。

（ステップＳ２０６）プロキシサービスＣＬ２１は、ＦＢセッションＣＬ２３を開始させる。その後、ステップＳ２０７へ進む。
（ステップＳ２０７）ＦＢセッションＣＬ２３は、入力されたデータを読み込むプログラム（ｒｅａｄ（））を生成する。その後、ステップＳ２０８へ進む。
（ステップＳ２０８）ＦＢセッションＣＬ２３は、ステップＳ２０４で受け付けたリクエストを読み込む。その後、ステップＳ２０９へ進む。

（ステップＳ２０９）ＦＢセッションＣＬ２３は、接続を確立するためのプログラム（ｄｏｃｏｎｎｅｃｔ（））を生成する。その後、ステップＳ２１０へ進む。
（ステップＳ２１０）ＦＢセッションＣＬ２３は、ステップＳ２０８で読み込んだリクエストのＵＲＬを解析する。その後、ステップＳ２１１へ進む。
（ステップＳ２１１）ＦＢセッションＣＬ２３は、ステップＳ２０８で読み込んだリクエストについて、不要なリクエストの修正や削除を行う。その後、ステップＳ２１２へ進む。

（ステップＳ２１２）ＦＢセッションＣＬ２３は、ＬＡ（ＬｉｎｋＡｇｇｒｅｇａｔｉｏｎ：リンクアグリゲーション（同時通信））が有効であるか無効であるかを確認する。その後、ステップＳ２１３へ進む。
（ステップＳ２１３）ＦＢセッションＣＬ２３は、ＦＢ管理ＣＬ２２に、通信方式（ＲＡＴ：Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）を選択させる要求を行う。その後、ステップＳ２１４へ進む。
（ステップＳ２１４）ＦＢ管理ＣＬ２２は、通信方式を選択する（ＲＡＴ選択）。例えば、ＦＢ管理ＣＬ２２は、デフォルトではＷｉ−Ｆｉ通信を選択する。一方、例えば強制フォールバックモードの場合、セルラー通信を選択する。その後、ステップＳ２１５へ進む。

（ステップＳ２１５）ＦＢセッションＣＬ２３は、ホストと接続するためのプログラム（ｃｌｉｅｎｔＣｏｎｎｅｃｔ（））を生成する。その後、ステップＳ２１６へ進む。
（ステップＳ２１６）ＦＢセッションＣＬ２３は、ステップＳ２０８のリクエストに含まれるドメインネーム情報について、名前解決処理を行うことで、ホストのＩＰアドレスを取得する。ここで、ＦＢセッションＣＬ２３は、ステップＳ２１３でＷｉ−Ｆｉ通信が選択された場合、予め定めた規則に従ってＤＮＳサーバ（図１のサーバ装置Ｓｖ１０３）を選択し、選択したＤＮＳサーバへ接続する。ＦＢセッションＣＬ２３は、接続したＤＮＳサーバを使用して、名前解決処理を行う。一方、ＦＢセッションＣＬ２３は、ステップＳ２１３でセルラー通信が選択された場合、所定のＤＮＳサーバ（図１のサーバ装置Ｓｖ１０２）を使用して、名前解決処理を行う。その後、ステップＳ２１７へ進む。
なお、ステップＳ２１６で、ＤＮＳサーバへの接続がタイムアウトした場合やＤＮＳサーバへの接続が失敗した場合、通信装置１は、フォールバック条件（Ａ２）、（Ａ５）に該当すると判定する。

（ステップＳ２１７）ＦＢセッションＣＬ２３は、ソケット接続を行う。ここで、ＦＢセッションＣＬ２３は、ホストへ接続済みで、かつ、ステップＳ２１６で取得したホストのＩＰアドレスと同じ場合には、接続済みのソケット接続を使い廻す。一方、それ以外の場合（例えば未接続の場合）、ＦＢセッションＣＬ２３は、ステップＳ２１６で取得したホストのＩＰアドレスを用いて、そのホストへ接続するためのソケットを生成する。ＦＢセッションＣＬ２３は、生成したソケットを用いて、ホストへ接続する。例えば、ＦＢセッションＣＬ２３は、通常（デフォルト）では、Ｗｉ−Ｆｉ通信により、ホストへ接続する。なお、ステップＳ２１７で、ホストへの接続がタイムアウトした場合やホストへの接続が失敗した場合、通信装置１は、フォールバック条件（Ａ１）、（Ａ４）に該当すると判定する。
ステップＳ２１５〜Ｓ２１７（ｃｌｉｅｎｔＣｏｎｎｅｃｔ（））の処理でエラーが発生した場合、ステップＳ２１８へ進む。一方、ステップＳ２１４〜Ｓ２１７の処理でエラーが発生しなかった場合、図１０のステップＳ２１９へ進む。

（ステップＳ２１８）ＦＢセッションＣＬ２３は、リトライを行う。つまり、ＦＢセッションＣＬ２３は、ステップＳ２１３で選択された通信方式とは異なる通信方式で、再度、ステップＳ２１４〜Ｓ２１７の処理を行う。換言すれば、ＦＢセッションＣＬ２３は、ステップＳ２１３で選択されたインターフェース１５１−ｉとは異なるインターフェース１５１−ｋを用いて、再度、ステップＳ２１４〜Ｓ２１７の処理を行う。すなわち、通信装置１は、フォールバックを行う。ここで、ＦＢセッションＣＬ２３は、リトライを行う前に、ヘッダ比較処理及びＲＤ先情報取得処理を行うことで、リトライを行うか否かを判定する。再度のステップＳ２１５〜Ｓ２１７の処理でエラーが発生しなかった場合、図１０のステップＳ２１９へ進む。
（ステップＳ２１９）ＦＢセッションＣＬ２３は、サーバへＨＴＴＰリクエストを送信するためのプログラム（ｓｅｎｄＲｅｑｕｅｓｔ（））を生成する。その後、ステップＳ２２０へ進む。

（ステップＳ２２０）ＦＢセッションＣＬ２３は、データを要求するリクエストを、バッファへ書き込む。その後、ステップＳ２２１へ進む。
（ステップＳ２２１及びＳ２２２）ＦＢセッションＣＬ２３は、ステップＳ２２０で書き込んだリクエストを、ステップＳ２１７で接続したホストへ送信する。ステップＳ２２１のリクエストに失敗した場合、ステップＳ２２３へ進む。一方、ステップＳ２２１のリクエストに成功した場合、ステップＳ２２４へ進む。
（ステップＳ２２３）ＦＢセッションＣＬ２３は、リトライを行う。すなわち、通信装置１は、フォールバックを行う。このフォールバックの詳細は、図１１を用いて後述する。
（ステップＳ２２４）ＦＢセッションＣＬ２３は、レスポンスを受信するためのプログラム（ｒｅｃｖＲｅｓｐｏｎｓｅ（））を生成する。その後、ステップＳ２２４へ進む。
（ステップＳ２２５）ＦＢセッションＣＬ２３は、スレッド（Ｔｈｒｅａｄ）ＣＬ２４を生成する。スレッドは、データを受信するためのプログラムである。その後、ステップＳ２２６へ進む。
（ステップＳ２２６）ＦＢセッションＣＬ２３は、スレッドＣＬ２４を開始させる。その後、ステップＳ２２７及びステップＳ２３７へ進む。

（ステップＳ２２７）スレッドＣＬ２４は、レスポンスのヘッダ情報を受信するためのプログラム（ｒｅｃｖＲｅｓｐｏｎｓｅＨｅａｄｅｒ（））を生成する。その後、ステップＳ２２８へ進む。
（ステップＳ２２８及びＳ２２９）スレッドＣＬ２４は、ステップＳ２２１で送信したリクエストに対するレスポンスのヘッダ情報を受信し、受信したヘッダ情報を読み込む。その後、ステップＳ２３０へ進む。
（ステップＳ２３０及びＳ２３１）スレッドＣＬ２４は、ステップＳ２２８で読み込んだヘッダ情報を、元アプリのソケットへ書き込む。つまり、スレッドＣＬ２４は、ヘッダ情報を、元アプリへ送信する。その後、スレッドＣＬ２４は、全てのヘッダ情報の受信が完了するまで、ステップＳ２２８〜Ｓ２３１の処理を繰り返す。全てのレスポンスの受信が完了したとき、ステップＳ２３２へ進む。

（ステップＳ２３２）スレッドＣＬ２４は、レスポンスのボディ情報（データ部分）を受信するためのプログラム（ｒｅｃｖＲｅｓｐｏｎｓｅＢｏｄｙ（））を生成する。その後、ステップＳ２３３へ進む。
（ステップＳ２３３及びＳ２３４）スレッドＣＬ２４は、ステップＳ２２３で送信したリクエストに対するレスポンスのボディ情報を受信し、受信したボディを読み込む。その後、ステップＳ２３５へ進む。
（ステップＳ２３５及びＳ２３６）スレッドＣＬ２４は、ステップＳ２３３及びＳ２３４で読み込んだボディ情報を、元アプリのソケットへ書き込む。つまり、スレッドＣＬ２４は、ボディ情報を、元アプリへ送信する。その後、スレッドＣＬ２４は、全てのボディ情報の受信が完了するまで、ステップＳ２３３〜Ｓ２３６の処理を繰り返す。

（ステップＳ２３７）ＦＢセッションＣＬ２３は、スループットを監視する。ＦＢセッションＣＬ２３は、スレッドＣＬ２４が全てのヘッダ情報及びボディ情報の受信が完了するまで、ステップＳ２３１又はＳ２３６の処理を繰り返す。その後、ステップＳ２３９へ進む。ただし、ステップＳ２２９又はＳ２３４で、スループットがスループット閾値以下であると判定された場合、フォールバック条件（Ａ３）に該当すると判断し、後述の図１２のステップＳ２３８へ進む。また、ステップＳ２２８〜Ｓ２３６の処理、つまり、レスポンス取得中に、エラーが発生した場合には、ステップＳ２３９へ進む。
（ステップＳ２３８）ＦＢセッションＣＬ２３は、例えばスループットが低下した場合に、リトライを行う。すなわち、通信装置１は、フォールバックを行う。なお、スループットが低下した場合とは、例えば、ＦＢ元リンクがＷｉ−Ｆｉ通信の場合には５１２Ｋｂｐｓ（キロビット毎秒）であり、ＦＢ元リンクがＬＴＥ通信の場合には５１２Ｋｂｐｓであり、ＦＢ元リンクが３Ｇ通信の場合には２５６である。このフォールバックの詳細は、図１２、図１３を用いて後述する。
（ステップＳ２３９）ＦＢセッションＣＬ２３は、リトライを行う。すなわち、通信装置１は、フォールバックを行う。このフォールバックの詳細は、図１４を用いて後述する。

図１１は、本実施形態に係るプロキシ部Ｐ１の処理フローを示す別の図である。この図は、図１０のステップＳ２１８の続きであり、図１１のステップＳ３０１以降が図１０のステップＳ２２３に対応する。また、図１０のステップ２２３は、図１１のＳ３０４以降に対応する。図１１において、図９又は図１０と同じ符号を付した処理は、図９又は図１０のものと同じであるので、説明を省略する。

（ステップＳ３０１）ＦＢセッションＣＬ２３は、ステップＳ２２１で送信したリクエストに失敗する。なお、このリクエストは、例えば、Ｗｉ−Ｆｉ通信により送信されたものである。その後、ステップＳ３０２へ進む。
（ステップＳ３０２）ＦＢセッションＣＬ２３は、ステップＳ２１７で生成されたソケットを閉じる。その後、ステップＳ３０３へ進む。
（ステップＳ３０３）ＦＢセッションＣＬ２３は、フォールバックを行うためのプログラム（ｄｏＲｅｔｒｙ）を生成する。その後、ステップＳ３０４へ進む。

（ステップＳ３０４）ＦＢセッションＣＬ２３は、フォールバックを行うためのソケットを生成する。その後、ステップＳ３０５へ進む。
（ステップＳ３０５）ＦＢセッションＣＬ２３は、ステップＳ２０８のリクエストに含まれるドメインネーム情報について、名前解決処理を行うことで、ホストのＩＰアドレスを取得する。ここで、ＦＢセッションＣＬ２３は、セルラー通信で用いるＤＮＳサーバ（図１のサーバ装置Ｓｖ１０２）を使用して、名前解決処理を行う。その後、ステップＳ３０６へ進む。なお、ステップＳ３０５で、ＤＮＳサーバへの接続がタイムアウトした場合やＤＮＳサーバへの接続が失敗した場合、通信装置１は、フォールバックも不可能と判断し、通信エラーとする。

（ステップＳ３０６）ＦＢセッションＣＬ２３は、ソケット接続を行う。ここで、ＦＢセッションＣＬ２３は、ステップＳ３０５で取得したホストのＩＰアドレスを用いて、そのホストへ接続するためのソケットを生成する。ＦＢセッションＣＬ２３は、生成されたソケットを用いて、セルラー通信により、ホストへ接続する。その後、ステップＳ３０７へ進む。なお、ステップＳ３０６で、ホストへの接続がタイムアウトした場合やホストへの接続が失敗した場合、通信装置１は、フォールバックも不可能と判断し、通信エラーとする。
（ステップＳ３０７）ＦＢセッションＣＬ２３は、データを要求するリクエストを送信するためのプログラム（ｓｅｎｄＲｅｑｕｅｓｔ（））を生成する。その後、ステップＳ３０８へ進む。
（ステップＳ３０８及びＳ３０９）ＦＢセッションＣＬ２３は、データを要求するリクエストを、ステップＳ３０６で接続したホストへ、セルラー通信により送信する。その後、ステップＳ３１０へ進む。

（ステップＳ３１０）ＦＢセッションＣＬ２３は、レスポンスのヘッダ情報を受信するためのプログラム（ｒｅｃｖＲｅｓｐｏｎｓｅＨｅａｄｅｒ（））を生成する。その後、ステップＳ３１１へ進む。
（ステップＳ３１１及びＳ３１２）ＦＢセッションＣＬ２３は、レスポンスのヘッダ情報を受信し、受信したヘッダ情報を読み込む。その後、ステップＳ３１３へ進む。
（ステップＳ３１３及びＳ３１４）ＦＢセッションＣＬ２３は、ステップＳ３１１で読み込んだヘッダ情報を、元アプリのソケットへ書き込む。つまり、ＦＢセッションＣＬ２３は、ヘッダ情報を、元アプリへ送信する。その後、ＦＢセッションＣＬ２３は、全てのヘッダ情報の受信が完了するまで、ステップＳ３１１〜Ｓ３１４の処理を繰り返す。全てのレスポンスの受信が完了したとき、ステップＳ３１５へ進む。ここで、ＦＢセッションＣＬ２３は、ステップＳ３１４の後、ステップＳ３１５の前に、ヘッダ比較処理（例えば、コンテンツのサイズの比較処理）を行わない。なぜなら、ステップＳ３０１でリクエストに失敗しているため、通信装置１は、ＦＢ元ヘッダ情報を取得していないからである。

（ステップＳ３１５）ＦＢセッションＣＬ２３は、レスポンスのボディ情報（データ部分）を受信するためのプログラム（ｒｅｃｖＲｅｓｐｏｎｓｅＢｏｄｙ（））を生成する。その後、ステップＳ３１６へ進む。
（ステップＳ３１６及びＳ３１７）ＦＢセッションＣＬ２３は、ステップＳ３０９で送信したリクエストに対するレスポンスのボディ情報を受信し、受信したボディを読み込む。その後、ステップＳ３１８へ進む。
（ステップＳ３１８及びＳ３１９）ＦＢセッションＣＬ２３は、ステップＳ３１６及びＳ３１７で読み込んだボディ情報を、元アプリのソケットへ書き込む。つまり、ＦＢセッションＣＬ２３は、ボディ情報を、元アプリへ送信する。その後、ＦＢセッションＣＬ２３は、全てのボディ情報の受信が完了するまで、ステップＳ３１６〜Ｓ３１９の処理を繰り返す。全てのボディ情報の受信が完了した後、ステップＳ３２０へ進む。
（ステップＳ３２０）ＦＢセッションＣＬ２３は、内部情報である、サーバ装置と接続しているソケットの情報に、ＦＢ後のソケット情報を設定（更新）する。

図１２は、本実施形態に係るプロキシ部Ｐ１の処理フローを示す別の図である。この図は、図１０のステップＳ２２３の続きである。図１１において、図９、図１０又は図１１と同じ符号を付した処理は、図９、図１０又は図１１のものと同じであるので、説明を省略する。

（ステップＳ４０１）ＦＢセッションＣＬ２３は、フォールバックを行うためのプログラム（ｄｏＲｅｔｒｙ）を生成する。その後、ステップＳ３０４へ進む。
なお、図１２では、ステップＳ３１２の後、ステップＳ４０２へ進む。また、Ｓ３０４、Ｓ３０６、Ｓ３０９の処理で失敗した場合については、図１３で説明する。
（ステップＳ４０２）ＦＢセッションＣＬ２３は、ステップＳ２２８〜Ｓ２３１で読み込んだヘッダ情報（ＦＢ元ヘッダ情報）とステップＳ３１１〜Ｓ３１２で読み込んだヘッダ情報（ＦＢ先ヘッダ情報）とを比較するヘッダ比較処理（例えば、コンテンツのサイズの比較処理）を行う。ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報が同じ（例えば、コンテンツのサイズが同じ）であると判定された場合、ステップＳ４０３へ進む。なお、ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報が同じでないと判定された場合については、図１３で説明する。

（ステップＳ４０３）ＦＢセッションＣＬ２３は、フォールバックを開始する。その後、ステップＳ４０４へ進む。
（ステップＳ４０４）ＦＢセッションＣＬ２３は、ＦＢ管理ＣＬ２２に対して、ＦＢセッション数に１を加えさせる。また、ＦＢセッションＣＬ２３は、スループットが低下したことを示すスループット低下フラグを設定する。このフラグが設定された場合、スレッドＣＬ２４は、ステップＳ２３３〜Ｓ２３６のループを抜ける。その後、ステップＳ３１５及びＳ４０５へ進む。
（ステップＳ４０５）スレッドＣＬ２４は、図９のステップＳ２１７で生成されたソケットを閉じる。なお、ＦＢセッションＣＬ２３は、図１２の最初のステップＳ３１６において、最後のステップＳ２３６で書き込まれたボディ情報の続きから、ボディ情報を読み込む。

図１３は、本実施形態に係るプロキシ部Ｐ１の処理フローを示す別の図である。この図は、図１０のステップＳ２２３の続きである。図１１において、図９〜図１２と同じ符号を付した処理は、図９〜図１２のものと同じであるので、説明を省略する。なお、図１３のステップＳ３０４、Ｓ３０６、Ｓ３０９の処理で失敗した場合には、ステップＳ５０２へ進む。

（ステップＳ５０１）ＦＢセッションＣＬ２３は、ステップＳ２２８〜Ｓ２３１で読み込んだヘッダ情報（ＦＢ元ヘッダ情報）とステップＳ３１１〜Ｓ３１２で読み込んだヘッダ情報（ＦＢ先ヘッダ情報）とを比較するヘッダ比較処理（例えば、コンテンツのサイズの比較処理）を行う。ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報が同じ（例えば、コンテンツのサイズが同じ）でないと判定された場合、ステップＳ５０２へ進む。なお、ＦＢセッションＣＬ２３は、ステップＳ５０１の後に、図８のステップＳ１２７の処理を行ってもよい。このとき、ステータスコードがリダイレクションを示すと判定された場合、ステップＳ１２３へ戻る。この場合、ステップＳ３０７に戻って、リダイレクション先へデータを要求するリクエストを送信するためのプログラム（ｓｅｎｄＲｅｑｕｅｓｔ（））を生成してもよい。
（ステップＳ５０２）ＦＢセッションＣＬ２３は、ステップＳ３０４で生成されたソケットを閉じる。

図１４は、本実施形態に係るプロキシ部Ｐ１の処理フローを示す別の図である。この図は、図１０のステップＳ２２３の続きである。図１１において、図９〜図１２と同じ符号を付した処理は、図９〜図１２のものと同じであるので、説明を省略する。

（ステップＳ６０１、Ｓ６０２、及びＳ６０３）スレッドＣＬ２４は、図１０のステップＳ２２１で送信したリクエストに対して、レスポンスのヘッダ情報を受信できない、又は、全てのヘッダ情報を受信できない状態となる。スレッドＣＬ２４は、３秒間、レスポンスを取得できなかった場合には、ステップＳ６０４へ進む。
（ステップＳ６０４）スレッドＣＬ２４は、ステップＳ２１７で生成されたソケットを閉じる。その後、ステップＳＳ２３９へ進む。
（ステップＳ６０５）ＦＢセッションＣＬ２３は、フォールバックを行うためのプログラム（ｄｏＲｅｔｒｙ）を生成する。その後、ステップＳ３０４へ進む。

このように、本実施形態によれば、ＦＢ元インターフェース１５１−ｉは、第１通信（例えば、Ｗｉ−Ｆｉ）を行う。ＦＢ先インターフェース１５１−ｋは、第２通信（例えば、ＬＴＥ）を行う。記憶部１４は、第１通信を用いて取得した通信データのヘッダ情報であるＦＢ元ヘッダ情報を記憶する。プロキシ部Ｐ１は、第２通信を用いて取得した通信データのヘッダ情報であるＦＢ先ヘッダ情報を取得する。プロキシ部Ｐ１は、ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報とを比較し、比較結果に基づいて、通信の一部又は全部について、第１通信と第２通信との切り換えを制御する。これにより、通信装置１は、適切に無線リンクの切り換えを制御できる。例えば、通信装置１は、フォールバックによって、第１通信を用いて取得したデータと第２通信を用いて取得したデータを結合してしまい、データの不整合が生じることを防止できる。

また、本実施形態によれば、プロキシ部Ｐ１は、ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報の少なくとも一部が一致しない場合には、通信の一部又は全部について、第１通信と第２通信との切り換えを止めると判定する。つまり、通信装置１は、フォールバックを止める。
プロキシ部Ｐ１は、ＦＢ先ヘッダ情報がリダイレクションを示す場合には、当該リダイレクション先からＦＢ先ヘッダ情報を取得し、取得したＦＢ先ヘッダ情報とＦＢ元ヘッダ情報との比較結果に基づいて、通信の一部又は全部について、第１通信と第２通信との切り換えを制御する。これにより、通信装置１は、フォールバック時にリダイレクトされた場合でも、ヘッダ情報が同じものを取得できた場合、つまり、最終的にコンテンツが同じである場合、フォールバックを行うことができる。

また、本実施形態によれば、記憶部１４は、通信装置１に提供されるコンテンツのうち、第１通信を用いて取得したコンテンツ（取得済コンテンツとも称する）を記憶する。プロキシ部Ｐ１は、ＦＢ元ヘッダ情報とＦＢ先ヘッダ情報の少なくとも一部が一致する場合には、通信の一部又は全部について、第１通信と第２通信を切り換えると判定する。プロキシ部Ｐ１は、第２通信を用いてコンテンツのうち、取得済コンテンツ以外のコンテンツ（未取得コンテンツとも称する）を取得し、取得済コンテンツと未取得コンテンツを合成する。

また、本実施形態によれば、プロキシ部Ｐ１は、第１通信から第２通信への単一フォールバックを行う条件（切り替え条件）を満たしたか否かを、予め定めたセッション（一連の通信）毎に判定し、判定結果に基づいて、セッション毎に、第１通信から前記第２通信への切り替えを制御する。このように、通信装置１は、セッション毎に単一フォールバックの制御を行うため、適切に無線リンクの切り換えを制御することができる。

例えば、プロキシ部Ｐ１は、第１通信を用いた接続要求に対する応答を所定の時間以上取得できなかった場合（例えば、セッションがタイムアウトした場合）、単一フォールバックを行う条件を満たしたと判定する。また、プロキシ部Ｐ１は、第１通信を用いて取得する通信データの送信元を識別可能な情報を所定の時間以上取得できなかった場合（例えば、名前解決処理がタイムアウトした場合）、単一フォールバックを行う条件を満たしたと判定してもよい。これにより、通信装置１は、特定のサーバや通信経路がダウンしている場合や、特定のネットワークで単一フォールバックを行うと判定する閾値以上の応答の遅延が発生する環境において、あるセッションが接続できないだけで、他のすべての通信（接続が成功する可能性のある通信）まで切り替えてしまうことを抑制することができる。

また、プロキシ部Ｐ１は、ＦＢセッション数（第１通信から第２通信へ切り替えた数）に応じて、タイムアウト時間（所定の時間）を変更する。例えば、プロキシ部Ｐ１は、単一フォールバック回数に応じて、タイムアウト時間を増加させる。これにより、通信装置１は、ＦＢセッション数に応じて、１本よりも２本、２本よりも３本、と、徐々にフォールバックしにくくなるように制御することができる。よって、通信装置１は、例えば、使用しているＷｉ−Ｆｉ通信の接続環境が恒常的に遅延しているときに、簡単に全ての通信がフォールバックをされてしまうことを防止できる。

また、プロキシ部Ｐ１は、ＦＢセッション数に応じて、タイムアウト時間を線形的に増加させてもよい。また、プロキシ部Ｐ１は、ＦＢセッション数に応じて、タイムアウト時間を非線形的に増加させてもよい。このように、通信装置１は、ＦＢセッション数に応じて徐々にフォールバックしにくくなるように制御する場合、徐々にフォールバックしにくくなる度合いを調整することができる。

なお、プロキシ部Ｐ１は、ＦＢセッション数に応じて、タイムアウト時間を減少させるように制御してもよい。これにより、通信装置１は、ＦＢセッション数に応じて徐々にフォールバックしやすくなるように制御することも可能である。

また、本実施形態によれば、プロキシ部Ｐ１は、予め定めたセッション（一連の通信）毎に、第１通信と第２通信の切り換えを制御し、第１通信から第２通信へ切り換えているセッションの数（ＦＢセッション数）を計数する。プロキシ部Ｐ１は、予め定めたルールに従って第１通信を優先し、計数したＦＢセッション数が許容値を超えた場合に、第２通信を優先する（強制フォールバックモードへ遷移する）。このように、通信装置１は、強制フォールバックモードに遷移させることで、不要リンクへの通信確立を試みるコストが不要となり、すぐに良好な通信を行うことができる。なお、予め定めたルールとは、例えば、予め定めた状態（デフォルト状態、又は、通常状態）において、第１通信を優先するものである。 また、本実施形態によれば、第１通信と第２通信は、通信のインターフェースが異なる。プロキシ部Ｐ１は、第１通信のＦＢ元インターフェース１５１−ｉと第２通信のＦＢ先インターフェース１５１−ｋとの切り換えを制御する。

（第２の実施形態）
通信装置１（プロキシ部Ｐ１）は、セッションの途中、つまり、ＦＢ先での通信完了前にフェールバックを行ってもよい。その場合、通信装置１は、ヘッダ比較処理を行って、フェールバックをするか否かを判定してもよい。

（第３の実施形態）
上記各実施形態において、通信装置１（プロキシ部Ｐ１）は、提供されるデータ部分のヘッダ情報の一部又は全部を比較してもよい。例えば、ＨＴＴＰのパケットには、ＩＰヘッダやＴＣＰヘッダの後に、データ部分であるＨＴＴＰデータが含まれている。例えば、ＨＴＴＰデータは、ＨＴＭＬの情報である。
この場合、例えば、通信装置１は、無線リンクＬ２において、ＨＴＴＰのヘッダフィールドで「Ｒａｎｇｅ：ｂｙｔｅｓ＝−２００」と指定することで、２００バイト以前のデータを取得できる。例えば、データがＨＴＭＬの場合、２００バイト以前のデータには、ＨＴＭＬのヘッダ情報の一部又は全部が含まれる。通信装置１は、取得したＨＴＭＬのヘッダ情報の一部又は全部と、無線リンクＬ１を用いて取得したＨＴＭＬのヘッダ情報の一部又は全部と、を比較することにより、ヘッダ比較処理を行ってもよい。

（第４の実施形態）
通信装置１（プロキシ部Ｐ１）は、フォールバックを行うか否かの判定（ヘッダ比較処理を含む）において、アプリケーションのタイムアウト時間を考慮してもよい。例えば、通信装置１は、ヘッダ比較処理又はＲＤ先情報取得処理の時間が、アプリケーションのタイムアウト時間に近づいたときには、フォールバックを行わないと判定してもよい。

なお、上述した実施形態における通信装置１の一部をコンピュータで実現するようにしてもよい。その場合、この制御機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、通信装置１に内蔵されたコンピュータシステムであって、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
また、上述した実施形態における通信装置１の一部、または全部を、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。通信装置１の各機能ブロックは個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。

以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。

１・・・通信装置、ＡＰ１・・・アクセスポイント、ＢＳ１・・・基地局装置、Ｓｖ１０１、Ｓｖ１０２、Ｓｖ１０３、Ｓｖ１０４・・・サーバ装置、１１・・・入力部、１２・・・出力部、１３・・・制御部、１４・・・記憶部、１５・・・通信部、１３１・・・アプリケーション部、Ｐ１・・・プロキシ部、１５１−１〜１５１−Ｎ・・・インターフェース、１５２・・・信号強度検出部、Ｐ１１１・・・セッション管理部、Ｐ１１２・・・ＤＮＳ管理部、Ｐ１１３・・・スループット取得部、Ｐ１１４・・・容量情報取得部、Ｐ１２１・・・信号強度取得部、Ｐ１２２・・・計時部、Ｐ１２３・・・ＡＰ情報取得部、Ｐ１２４・・・通信方式情報取得部、Ｐ１２５・・・位置情報取得部、Ｐ１３１・・・ヘッダ情報取得部、Ｐ１３２・・・リダイレクト情報取得部、Ｐ１４・・・ＩＦ選択部、Ｐ１５・・・データ合成部

Claims (11)

1. 第１通信を行う第１通信部と、
   第２通信を行う第２通信部と、
   前記第１通信から前記第２通信への切り替え条件を満たしたか否かを、予め定めた一連の通信毎に判定し、判定結果に基づいて、前記一連の通信毎に、前記第１通信から前記第２通信への切り替えを制御する選択部と、
   前記第１通信から前記第２通信へ切り換えている前記一連の通信の数を計数する計数部と、
   を備え、
   前記選択部は、
   前記第１通信を優先し、前記計数部が計数した前記一連の通信の数が閾値を超えた場合には、その後の前記一連の通信に対して前記第２通信を優先する、
   通信装置。
2. 前記選択部は、
   前記第１通信を用いた接続要求に対する応答を所定の時間以上取得できなかった場合、前記切り替え条件を満たしたと判定する、
   請求項１に記載の通信装置。
3. 前記選択部は、
   前記第１通信を用いて取得する通信データの送信元を識別可能な情報を所定の時間以上取得できなかった場合、前記切り替え条件を満たしたと判定する、
   請求項１に記載の通信装置。
4. 前記選択部は、
   前記第１通信から前記第２通信へ切り替えた数に応じて、前記所定の時間を変更する、
   請求項２または３のいずれか一項に記載の通信装置。
5. 前記選択部は、
   前記第１通信から前記第２通信へ切り替えた数に応じて、前記所定の時間を増加させる、
   請求項４に記載の通信装置。
6. 前記選択部は、
   前記第１通信から前記第２通信へ切り替えた数に応じて、前記所定の時間を線形的に増加させる、
   請求項５に記載の通信装置。
7. 前記選択部は、
   前記第１通信から前記第２通信へ切り替えた数に応じて、前記所定の時間を非線形的に増加させる、
   請求項５に記載の通信装置。
8. 前記第１通信と前記第２通信は、論理的又は物理的な通信のインターフェースが異なり、
   前記選択部は、
   前記第１通信のインターフェースから前記第２通信のインターフェースへの切り換えを制御する、
   請求項１から７のいずれか一項に記載の通信装置。
9. 通信装置における通信方法おいて、
   選択部が、
   第１通信から第２通信への切り替え条件を満たしたか否かを、予め定めた一連の通信毎に判定する判定過程と、
   前記判定の判定結果に基づいて、前記一連の通信毎に、前記第１通信から前記第２通信への切り替えを制御する選択過程と、
   計数部が、
   前記第１通信から前記第２通信へ切り換えている前記一連の通信の数を計数する計数過程と、
   を有し、
   前記選択過程において、
   前記第１通信を優先し、前記計数過程において計数された前記一連の通信の数が閾値を超えた場合には、その後の前記一連の通信に対して前記第２通信を優先する、
   通信方法。
10. 通信装置のコンピュータに、
    第１通信から第２通信への切り替え条件を満たしたか否かを、予め定めた一連の通信毎に判定する判定手順と、
    前記判定の判定結果に基づいて、前記一連の通信毎に、前記第１通信から前記第２通信への切り替えを制御する選択手順と、
    前記第１通信から前記第２通信へ切り換えている前記一連の通信の数を計数する計数手順と、
    を実行させ、
    前記選択手順において、
    前記第１通信を優先し、前記計数手順において計数された前記一連の通信の数が閾値を超えた場合には、その後の前記一連の通信に対して前記第２通信を優先する、
    通信プログラム。
11. 第１通信から第２通信への切り替え条件を満たしたか否かを、予め定めた一連の通信毎に判定し、判定結果に基づいて、前記一連の通信毎に、前記第１通信から前記第２通信への切り替えを制御する選択部と、
    前記第１通信から前記第２通信へ切り換えている前記一連の通信の数を計数する計数部と、
    を備え、
    前記選択部は、
    前記第１通信を優先し、前記計数部が計数した前記一連の通信の数が閾値を超えた場合には、その後の前記一連の通信に対して前記第２通信を優先する、
    プロセッサ。

Images