(57)【要約】【課題】  エラーフレームが再送されているときに再び瞬断が発生するとモデムが発散し、プライマリチャネルの後端が受信側で認識できなくなる。【解決手段】  プライマリチャネル受信時に正常に受信できたフレーム数と、直前のプライマリチャネル送信で送信機側が送信した全フレーム数と、フレームが再送される次回のプライマリチャネル受信速度とからエラー再送フレームの伝送時間を求めて、プライマリチャネル後端を予測し（Ｓ４）、その予測したタイミングで受信機側のモデムを強制的にコントロールチャネルへ移行させ再同期を行う（Ｓ６，Ｓ１１）ことにより、Ｖ．３４のプライマリチャネル受信中に回線信号の瞬断が発生したような場合にも、プライマリチャネルの後端を予測してコントロールチャネルへの移行を適切に行える。【選択図】  図６
2009253648.tif 000002
【特許請求の範囲】
【請求項１】
ＩＴＵ−Ｔ勧告Ｖ．３４に準拠した通信を行う通信装置であって、
プライマリチャネルにて他の通信装置から画像データを受信する際に、正常に受信されなかったフレームであるエラーフレーム数を計算する計算手段と、
前記計算手段により計算された前記エラーフレーム数に基づいて、前記他の通信装置から送信される前記エラーフレーム数分の画像データの受信を終了するタイミングを予測する予測手段と、
前記プライマリチャネルにて前記エラーフレーム数分の画像データの受信をする際に、前記予測手段により予測した前記タイミングとなったことに応じて、前記プライマリチャネルからコントロールチャネルへ移行するよう制御する制御手段と、
を有することを特徴とする通信装置。
【請求項２】
前記プライマリチャネルにて画像データを受信する際に、正常に受信されたフレームである正常フレーム数を計数する計数手段と、
前記プライマリチャネルにて前記画像データの送信元である他の通信装置により送信された画像データの全フレーム数を前記他の通信装置から取得するフレーム数取得手段とを有し、
前記計算手段は、前記フレーム数取得手段により取得した前記全フレーム数と、前記計数手段により計数された前記正常フレーム数とに基づいて、前記エラーフレーム数を計算することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記他の通信装置が前記エラーフレームを送信する際の前記プライマリチャネルにおける通信速度を取得する通信速度取得手段を有し、
前記予測手段は、前記計算手段により計算された前記エラーフレーム数及び前記通信速度取得手段により取得された前記通信速度に基づいて、前記タイミングを予測することを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記他の通信装置との通信がＩＰネットワークを経由する通信であるか、前記ＩＰネットワークを経由しない通信であるかを検出する検出手段を更に有し、
前記制御手段は、前記検出手段が前記ＩＰネットワークを経由する通信であることを検出した場合は、前記予測手段により予測した前記タイミングとなったことに応じて前記プライマリチャネルを前記コントロールチャネルへ移行させ、前記検出手段が前記ＩＰネットワークを経由しない通信であることを検出した場合は、前記他の通信装置から前記プライマリチャネルから前記コントロールチャネルへ移行するための制御信号を受信したことに応じて前記プライマリチャネルから前記コントロールチャネルへ移行するよう制御することを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
【請求項５】
ＩＴＵ−Ｔ勧告Ｖ．３４に準拠した通信を行う通信装置の制御方法であって、
プライマリチャネルにて他の通信装置から画像データを受信する際に、正常に受信されなかったフレームであるエラーフレーム数を計算する計算工程と、
前記計算工程で計算された前記エラーフレーム数に基づいて、前記他の通信装置から送信される前記エラーフレーム数分の画像データの受信を終了するタイミングを予測する予測工程と、
前記プライマリチャネルにて前記エラーフレーム数分の画像データの受信をする際に、前記予測工程で予測した前記タイミングとなったことに応じて、前記プライマリチャネルからコントロールチャネルへ移行するよう制御する制御工程と、
を有することを特徴とする通信装置の制御方法。
【請求項６】
前記プライマリチャネルにて画像データを受信する際に、正常に受信されたフレームである正常フレーム数を計数する計数工程と、
前記プライマリチャネルにて前記画像データの送信元である他の通信装置により送信された画像データの全フレーム数を前記他の通信装置から取得するフレーム数取得工程とを有し、
前記計算工程は、前記フレーム数取得工程により取得した前記全フレーム数と、前記計数工程により計数された前記正常フレーム数とに基づいて、前記エラーフレーム数を計算することを特徴とする請求項５に記載の通信装置の制御方法。
【請求項７】
前記他の通信装置が前記エラーフレームを送信する際の前記プライマリチャネルにおける通信速度を取得する通信速度取得工程を有し、
前記予測工程は、前記計算工程により計算された前記エラーフレーム数及び前記通信速度取得工程により取得された前記通信速度に基づいて、前記タイミングを予測することを特徴とする請求項５又は６に記載の通信装置の制御方法。
【請求項８】
前記他の通信装置との通信がＩＰネットワークを経由する通信であるか、前記ＩＰネットワークを経由しない通信であるかを検出する検出工程を更に有し、
前記制御工程は、前記検出工程が前記ＩＰネットワークを経由する通信であることを検出した場合は、前記予測工程にて予測された前記タイミングとなったことに応じて前記プライマリチャネルを前記コントロールチャネルへ移行させ、前記検出工程が前記ＩＰネットワークを経由しない通信であることを検出した場合は、前記他の通信装置から前記プライマリチャネルから前記コントロールチャネルへ移行するための制御信号を受信したことに応じて前記プライマリチャネルから前記コントロールチャネルへ移行するよう制御することを特徴とする請求項５乃至７のいずれか１項に記載の通信装置の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＴＵ−Ｔ勧告Ｖ．３４に準拠した通信能力を有する通信装置及びその制御方法に関するものである。
【背景技術】
【０００２】
（１）「ＩＰネットワーク／ＩＰ電話の普及」
近年、家庭や中小規模のオフィスにおいて、ＡＤＳＬ／ＦＴＴＨを利用したインターネット接続サービスが普及している。また企業や大学等では、ＬＡＮによる情報機器の共有化と、従来の専用線からＶＰＮ（Virtual Private Network：インターネットに専用線を作る技術）への移行等が図られている。このような技術背景の下で、ＩＰネットワークが広く普及してきている。また、これらＩＰネットワークを利用したＩＰ電話もまた広く普及してきている。ＩＰ電話は、音声をＩＰパケットとして送る技術（ＶｏＩＰ:Voice over Internet Protocol）を利用している。このＩＰ電話は、高価な交換機等の設備を使用しなくても、安価なＩＰネットワーク／ルータ等で音声通話が行えるため、遠距離通話が多いユーザには大きなコストメリットをもたらしている。
【０００３】
（２）「ＩＰネットワーク経由のファクシミリ通信の増加」
これらＩＰネットワーク／ＩＰ電話の整備や普及を背景として、企業はもとより家庭でも、ＩＰネットワークに接続されたファクシミリ端末が増加し、またＩＰネットワークを経由したファクシミリ通信が増えてきている。
【０００４】
図１は、一般的な公衆電話網とインターネット、ＩＰネットワーク／ＩＰ電話との接続を説明する図である。
【０００５】
通信経路１００は、電話局、公衆電話網のみを経由するファクシミリ通信を示す。通信経路１０２は、ファクシミリ装置１０３がＶｏＩＰルータを介してＩＳＰ（Internet Service Provider）と接続し、インターネットを経由するファクシミリ通信を行う通信経路を示している。またファクシミリ装置１０５は、ＶｏＩＰルータで企業の専用線やＶＰＮなどＩＰネットワークと接続し、ＶｏＩＰゲートウェイを経由して公衆電話網と接続するファクシミリ通信（通信経路１０４）を行うことができる。また通信経路１０６は、ＩＰネットワーク内に接続されたファクシミリ装置間での通信を示している。このように様々な接続形態で、ＩＰネットワーク経由のファクシミリ通信が実現できている。
【０００６】
（３）「ＩＰネットワークを経由するファクシミリ通信の問題点」
従来の公衆電話網でのファクシミリ通信では、伝送路上での通信に必要な帯域が保証されているため通信障害があまり発生しなかった。しかし、ＩＰネットワークの普及に伴ってＩＰネットワーク経由のファクシミリ通信が増えてくると、このようなファクシミリ通信による通信障害が徐々に増加してきている。
【０００７】
ＩＰネットワーク経由のファクシミリ通信では、ファクシミリ信号は音声信号としてパケットに分割して伝送され、受信側では、そのパケットを組み立て音声信号を復号して通信している。ＩＰネットワークでは信号の伝達時間に保証がなく、またＩＰネットワークが混雑している場合に音声信号の帯域とそれ以外のデータ通信の帯域が十分に取れないために、周波数帯の損失やパケットの遅延／喪失による回線障害が発生する場合がある。これらの障害は、通信量の多い企業内ネットワーク等で発生しやすく、特にデータ通信が集中する時間帯などに集中して発生する。
【０００８】
（４）「ＩＰネットワークにおける音声品質劣化の要因」
送信機からの音声信号が受信機に到達するまでに、ＶｏＩＰルータ（又は公衆回線網とＩＰネットワークとの間にあるＶｏＩＰゲートウェイ）で信号のＡ／Ｄ変換、符号化、パケット分割が行われる。そしてＩＰネットワーク内のルータで、ルーティング中継／転送が実施され、受信機側のＶｏＩＰルータ（又はＶｏＩＰゲートウェイ）でパケットの組立、復号、Ｄ／Ａ変換が行われて音声信号が復元される。
【０００９】
このＩＰネットワーク内で転送されるパケットの通信速度は一定ではない。このため、転送される複数のパケットは、パケット毎に、途中のＩＰネットワークでのネットワーク混雑や障害により受信機側のＶｏＩＰルータへの到着タイミングに差が発生する。
【００１０】
図２は、ＩＰネットワークを介した通信におけるパケットの到着タイミングの差やパケットの消失例を説明する図である。
【００１１】
図２は、ファクシミリ装置２０１からＶｏＩＰルータを介して一定間隔で送信されたパケットを、ＩＰネットワークを介してファクシミリ装置２０２が受信する例を示している。このように、各パケットの到着タイミングの差が大きかったり、ＩＰネットワーク内でのパケット消失（パケットロス）が発生すると、ＶｏＩＰルータが送信機側でサンプリングした信号波形を復元できないという現象が発生する。そうすると、受信したパケットに基づいて再生した音声信号には、瞬断（一時的な音声信号の消失）が発生する。
【００１２】
（５）「音声品質劣化がファクシミリ通信に及ぼす影響」
パケットの到着タイミングの差やパケットロスにより発生した音声信号の瞬断は、ファクシミリ通信に影響を及ぼす。ファクシミリ通信は、送信機側のモデムと受信機側のモデムで同期をとりながら手順信号の転送と画像データの転送を繰返し行う通信方式である。このような送信機側と受信機側で同期を必要とする通信方式において、瞬断による通信信号の欠落は、モデムの同期を失わせ、手順信号の送受信状態の維持、画像データの送受信の継続を困難にする。特に、ＩＴＵ−Ｔ勧告Ｖ．３４に準拠したモデムでファクシミリ通信を行う場合に、この瞬断発生が大きく影響する。
【００１３】
図３は、Ｖ．３４モデムで通信中にＩＰネットワークからの影響による音声信号の瞬断が発生した場合に、ファクシミリ通信が受信機側でエラー終了する過程を送信／受信信号の様子から時系列的に説明する図である。
【００１４】
Ｖ．３４通信の画像データは連続するフレームで構成されるため、画像信号の受信中に瞬断が発生した場合、フレームの通信の同期を失ってから再同期を取るまでの時間、フレームの画像データを受信できなくなる。また再同期をとるための処理が複雑であり、ある一定時間以上の回線信号の瞬断が発生した場合には、再同期を取ることができず、瞬断発生以降は、モデムが発散し正常に画像データが受信できなくなってしまう。
【００１５】
このような問題点を解決するために、エラーフレームを検出して次に正しいフレームを受信するまでの一定時間内に有効なフレームを受信できなかった場合に低速手順に移行して相手側の低速コマンドを受信する特許文献１の技術がある。
【特許文献１】特開平０４−２５５１６６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しかし従来の技術では、エラーフレームが再送されているときに再び瞬断が発生するとモデムが発散し、プライマリチャネルの後端が受信側で認識できなくなる。プライマリチャネルの後端とは、画像データの受信を行うためのプライマリチャネルから、手順信号の送受信を行うためのコントロールチャネルに通信チャネルを移行させるための制御信号をいう。そして、このような場合は、受信側は、タイマによる計時でプライマリチャネルの後端が検出されない状態で一定時間が経過したためタイムアウトが発生してエラー終了することになる。
【００１７】
本発明の目的は、上記従来技術の問題点を解決することにある。
【００１８】
本発明の一態様によれば、Ｖ．３４のプライマリチャネルにて他の通信装置からエラーフレームの画像データを受信する際に、ＩＰネットワークに起因する信号の瞬断が発生した場合に、プライマリチャネルからコントロールチャネルへの移行を適切に行える。
【課題を解決するための手段】
【００１９】
上記目的を達成するために本発明の一態様に係る通信装置は以下のような構成を備える。即ち、
ＩＴＵ−Ｔ勧告Ｖ．３４に準拠した通信を行う通信装置であって、
プライマリチャネルにて他の通信装置から画像データを受信する際に、正常に受信されなかったフレームであるエラーフレーム数を計算する計算手段と、
前記計算手段により計算された前記エラーフレーム数に基づいて、前記他の通信装置から送信される前記エラーフレーム数分の画像データの受信を終了するタイミングを予測する予測手段と、
前記プライマリチャネルにて前記エラーフレーム数分の画像データの受信をする際に、前記予測手段により予測した前記タイミングとなったことに応じて、前記プライマリチャネルからコントロールチャネルへ移行するよう制御する制御手段と、
を有することを特徴とする。
【００２０】
上記目的を達成するために本発明の一態様に係る通信装置の制御方法は以下のような工程を備える。即ち、
ＩＴＵ−Ｔ勧告Ｖ．３４に準拠した通信を行う通信装置の制御方法であって、
プライマリチャネルにて他の通信装置から画像データを受信する際に、正常に受信されなかったフレームであるエラーフレーム数を計算する計算工程と、
前記計算工程で計算された前記エラーフレーム数に基づいて、前記他の通信装置から送信される前記エラーフレーム数分の画像データの受信を終了するタイミングを予測する予測工程と、
前記プライマリチャネルにて前記エラーフレーム数分の画像データの受信をする際に、前記予測工程で予測した前記タイミングとなったことに応じて、前記プライマリチャネルからコントロールチャネルへ移行するよう制御する制御工程と、
を有することを特徴とする。
【発明の効果】
【００２１】
本発明によれば、Ｖ．３４のプライマリチャネルで他の通信装置からエラーフレームの画像データを受信する際、ＩＰネットワークに起因する信号の瞬断が発生した場合にプライマリチャネルからコントロールチャネルへの移行を適切に行うことができる。
【発明を実施するための最良の形態】
【００２２】
以下、添付図面を参照して本発明の好適な実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００２３】
本実施形態は、ＩＴＵ−Ｔ（International Telecommunication Union-Telecommunication Standardization Sector）Ｖ．３４勧告に準拠した通信装置に関する。これに準拠する通信装置の一例であるファクシミリ装置が通信を行う際に、回線障害等が発生してモデムが同期を失い通信の継続が難しいような場合でも、継続して通信する通信装置及びその制御方法について説明する。特に、プライマリチャネル及びコントロールチャネル送受信時に瞬断が発生した場合の処理と、回線障害が多発する環境において高解像度の大量のデータを通信する技術に関して説明する。
【００２４】
［実施形態１］
以下、図４〜図６を参照して本発明の実施形態１を詳細に説明する。
【００２５】
図４は、本発明の実施形態１に係る通信装置の構成を示すブロック図である。
【００２６】
ＣＰＵ４０１は、ＲＯＭ４０２に記憶されたプログラムに従って、この通信装置の動作を制御している。ＲＯＭ４０２は、ＣＰＵ４０１により実行される制御プログラムや各種データを格納している。ＲＡＭ４０３はＳＲＡＭ等で構成され、ＣＰＵ４０１による処理の実行時にワークエリアを提供するとともに、画像データ等を一時的に格納するのにも使用される。画像メモリ４０４はＤＲＡＭ等で構成され、スキャンした画像データ或はネットワークを介して受信した画像データ等を蓄積する。解像度変換処理部４０５は、画像データのミリ−インチ等の解像度変換を行う。符号化／復号化部（コーデック）４０６は、この通信装置で扱う画像データを符号化したり、或は符号化された画像データを復号する。時計部（タイマ）４０７は、ＣＰＵ４０１の指示に従って時間間隔等を計測し、損時間が経過したことをＣＰＵ４０１に対して割り込み等で通知する、例えばプログラマブルタイマなどで構成されている。
【００２７】
モデム４０８は、ＮＣＵ４０９を介して入力される回線からの変調された信号を復調したり、逆にこの通信装置からの信号を変調しＮＣＵ４０９を介して回線に送出する。回線ｉ／ｆ部（ＮＣＵ）４０９は電話機４１０を接続し、ＶｏＩＰルータとの間の通信を制御している。電話機４１０は、回線ｉ／ｆ部（ＮＣＵ）４０９を通して電話回線に接続されるハンドセット（ダイヤラを持たない電話機）や外付け電話機（留守番電話機等）である。電話機４１０の接続端子が２個の場合には、夫々の端子でオフフック／オンフック検知をするために接続端子毎にフック検知回路を有する。ＶｏＩＰルータ４１１は、ＶＰＮ等のＩＰネットワーク４１２と、この通信装置とをアナログポートで接続する。
【００２８】
画像処理部４１３は、スキャナ４１４，４１５によって読み込まれた画像データに補正処理を施して出力する。シートスキャナ４１４、ブックスキャナ４１５は、ＣＳイメージセンサ、原稿搬送機構などを有し、原稿を光学的に読み取って電気的な画像データに変換して出力する。またこれらスキャナは両面原稿の読み取りを行うこともできる。操作部４１６は、キーボード、表示部等を有し、オペレータによる操作指示を入力する。尚、この表示部には、電話機４１０のハンドセットがオフフック時に即時ダイヤル操作可能であることを表示し。また、外付け電話機がオフフック時には、通信中であることの表示及び通信予約受け付け可能なことを表示する。
【００２９】
ラインバッファ４１７は、画像データの各走査ラインのデータ（ラスタデータ）を格納し、各ライン単位で転送制御を行う場合に使用される。プリントバッファ４１８は、印刷用のデータを格納する１ページ分のバッファメモリである。プリンタ４１９は、受信した画像データやスキャナにより読み取った画像データを印刷する、例えばＬＢＰ等のプリンタであり、両面印刷も可能である。
【００３０】
図５は、本発明の実施形態における回線障害を回避する具体例を説明するシーケンス図である。
【００３１】
５０１は、プライマリチャネル（ＰＣ）の受信中に回線障害が発生して瞬断が発生した場合の送信側と受信側のシーケンスを示している。プライマリチャネルとは、送信側と受信側とで画像データを送受信するための通信モードをいう。なお、以下では、図４に示す通信装置が画像データを受信する受信側の通信装置として動作し、ＶｏＩＰルータ４１１からＩＰネットワーク４１２を介して接続される他の通信装置（不図示）が送信側（送信元）の通信装置として動作するものとする。
【００３２】
また、以下の説明においては、図４の通信装置と他の通信装置は、ＥＣＭ（Error Correction Mode）にて画像データの伝送を行うものとする。ＥＣＭとは、回線上のノイズなどで欠落した画像データを再送する事により、ライン抜けのない画像を送受信する通信モードをいう。ＥＣＭでは、画像データをブロック単位に区分けし、それをいくつかのフレームに分割して送信側から受信側に送信する。受信側では1フレーム受信するごとにエラー判定を行い、これを1ブロック受信終了するまで繰り返す。1ブロックの受信が終了した時点でエラーフレーム（正常に受信されなかったフレーム）があった場合、送信側に対してエラーフレームの再送要求を行う。再送要求を受けた送信側はエラーが発生したフレームのみを再送し、正常な画像データの送受信が確認できた時点で次のデータ・ブロックの送出を開始する。
【００３３】
５０２は従来技術を示すシーケンスであり、例えば５０１に示すように、通信装置がプライマリチャネルにて他の通信装置から画像データを受信した際にエラーフレームが発生した後の状態を示している。ここではエラーフレームが再送されているが、再び瞬断が発生したためにモデムが発散し、プライマリチャネルの後端を示す制御信号（ＲＣＰ信号）が受信側で認識できない状態を示している。従って、このような場合は、受信側は、タイマによる計時で一定時間が経過したためタイムアウトが発生してエラー終了している。
【００３４】
５０３は、本発明の実施形態を説明している。ここでも例えば５０１に示すような、通信装置がプライマリチャネルにて他の通信装置から画像データを受信した際にエラーフレームが発生した後の状態を示している。ここでも前述の５０２と同様に再び瞬断が発生している。これに対して本実施形態では、プライマリチャネルにおいて、他の通信装置から送信されるエラーフレーム数分の画像データの受信を終了するタイミング（プライマリチャネルの後端）を予測する（予測手段）。そして、モデム４０８は、プライマリチャネルにてエラーフレーム数分の画像データの受信を開始した後に予測されたタイミングとなったことに応じて、プライマリチャネルをコントロールチャネルへ移行するよう制御する。以下、この動作の具体例を詳しく説明する。
【００３５】
図６は、本発明の実施形態１に係る通信装置における受信処理を説明するフローチャートである。ここではプライマリチャネルの後端を予測し、その予測した後端で強制的に再同期を取る処理を行っている。尚、この処理を実行するプログラムはＲＯＭ４０２に記憶されており、ＣＰＵ４０１の制御の下に実行される。
【００３６】
この処理は、プライマリチャネルからの着信後、相手送信機（相手機）とＶ．３４のフェーズ１〜５を経てプライマリチャネル受信処理へ移行することにより開始される。先ずステップＳ１で、プライマリチャネル移行後にプライマリチャネルの通信速度情報を取得する（通信速度取得）。次にステップＳ２に進み、プライマリチャネルの再同期からフラグを受信し、続いて画像フレームの受信が開始されるのを待つ。フレームの受信が開始されるとステップＳ３に進み、前回のプライマリチャネル受信時に正常に受信できなかったフレーム（エラーフレーム）があったかどうかを判定する。エラーフレームがあったと判断した場合はステップＳ４に進み、プライマリチャネルの後端を予測して時計部４０７を起動する。
【００３７】
図７は、図６のステップＳ４のプライマリチャネルの後端予測処理を説明するフローチャートである。この図７を参照してステップＳ４の処理を説明する。
【００３８】
先ずステップＳ２４で、直前のプライマリチャネル受信において、正常に受信されたフレームである正常フレーム数を求める。次にステップＳ２５に進み、直前のプライマリチャネル受信において、送信機が送信した全フレームの数を取得する(全フレーム数取得）。次にステップＳ２６に進み、その全フレームの数から正常に受信したフレームの数を引いて、エラーで再送されるフレームの数を求める。次にステップＳ２７に進み、次回のプライマリチャネルの受信速度を取得する。そしてステップＳ２８で、再送されるエラーフレームの数とプライマリチャネル受信速度とに基づいて、再送されるプライマリチャネル受信の後端までの経過時間を予測する。そしてステップＳ２９に進み、その予測した時間を時計部４０７にセットして計時を開始させる。これにより後のステップＳ６で、この時間が経過しても１フレームの受信が終了しないときはステップＳ１１で強制的に、送信機をプライマリチャネルからコントロールチャネルへ移行させることができる。
【００３９】
次に再び図６に戻り、ステップＳ３でエラーフレームがないと判断した場合はステップＳ５に進み、プライマリチャネルで通信可能な最大データ長であるＥＣＭの１ブロックに相当する時間を時計部４０７にセットして計時を開始させる。より具体的には、例えば図５に示すように、全フレーム数から受信したフレーム数を差し引いて差分値を求め、その差分値に１フレームの伝送時間を掛けることにより、最終的にそのブロックの受信を終了する時間を予測して時計部４０７にセットする。こうしてステップＳ４或はステップＳ５を実行した後ステップＳ６に進む。ステップＳ６〜Ｓ１０の処理は、プライマリチャネルの受信ループ処理である。
【００４０】
ステップＳ６では、時計部４０７からタイムアウトが発生したかどうかをみる。タイムアウトが発生しているとステップＳ１１に進み、強制的にコントロールチャネルへ移行させる。一方、ステップＳ６でタイムアウトが発生していなければステップＳ７に進み、データを１フレーム受信できたかどうかを判断する。ここで１フレームが受信できていなければステップＳ６に戻る。１フレームが受信できていればステップＳ８に進み、受信フレームが正常（エラーが無い）かどうかを判断する。ここでエラーがある場合はエラーフレームを捨ててステップＳ６に戻る。一方、受信フレームが正常だった場合はステップＳ８からステップＳ９に進み、正常受信したフレーム数を計数するカウンタをカウントアップしてステップＳ１０に進む。ステップＳ１０では、プライマリチャネルの後端を示すＲＣＰ信号を受信したかどうかを判定する。ＲＣＰ信号を受信していない場合はステップＳ６に戻って、前述の処理を繰り返す。
【００４１】
ステップＳ１０でＲＣＰ信号を受信するとステップＳ１２に進み、プライマリチャネル受信処理を抜けてコントロールチャネル（ＣＣ）が開始されるタイミングを待つ。コントロールチャネル受信が開始されるとステップＳ１３に進み、手順信号の待ち時間を計時する時間（Ｔ２）を時計部４０７にセットして計時を開始する。次にステップＳ１４，Ｓ１５で、送信機からの信号を待つ。ステップＳ１４では、時間Ｔ２内に手順信号を受信できたかどうかを判断し、時間Ｔ２内に手順信号を受信できない時はステップＳ２１に進み、回線を解放して通信はエラー終了となる。
【００４２】
ステップＳ１４，Ｓ１５で、時間Ｔ２内に手順信号（ＰＰＳ−Ｑ）を受信するとステップＳ１６に進み、ＰＰＳ信号に含まれる全フレーム数を取得する。そしてステップＳ１７に進み、プライマリチャネルで受信した全てのフレームにエラーが無いかどうかを判断する。エラーが無かった場合はステップＳ１８に進み、ＭＣＦを送信して受信データにエラーの無いことを送信機に通知する。一方、ステップＳ１７でエラーがあったと判断した場合はステップＳ１９に進み、送信機に部分ページ要求信号（ＰＰＲ）を送信し、再送して欲しいエラーフレームの番号情報を通知する。こうしてステップＳ１８或はステップＳ１９を実行した後ステップＳ２０に進み、受信したＰＰＳ−Ｑ信号及び受信フレームから次のプライマリチャネル受信（次ページ又はエラーフレーム再送）が有るかを判断する。次のプライマリチャネル受信がある場合はステップＳ１に戻って、プライマリチャネルの受信処理を繰返す。一方、次のプライマリチャネル受信が無い場合はステップＳ２２に進み、回線を解放して通信を正常終了させる。
【００４３】
このように本実施形態１によれば、プライマリチャネルの受信中にエラーが発生すると、直前のプライマリチャネルで送信された全フレーム数と、正常に受信したフレーム数からエラーフレーム数を計算する。そして、そのエラーフレーム数と１フレームの受信速度との乗算結果に応じて、エラー再送フレームの伝送時間を計算して、そのプライマリチャネルの受信の後端を予測する。こうして予測した後端のタイミングで強制的にコントロールチャネル受信へ移行させることにより再同期を行うことができる。
【００４４】
尚、上記の説明では、図４に示す通信装置が通信するのが、ＶｏＩＰルータ４１１からＩＰネットワーク４１２を介して接続される他の通信装置であるものとして説明した。この点、図４の通信装置は、ＮＣＵ４０９を介して他の通信装置と電話回線を介して（ＩＰネットワーク４１２を経由しないで）通信することができるようにしてもよい。この場合、図４の通信装置のＮＣＵ４０９は、他の通信装置との通信がＩＰネットワークを経由する通信であるか、ＩＰネットワークを経由しない通信であるかを検出する機能を有するものとする。ＩＰネットワークを経由しない通信である場合は、プライマリチャネルの後端の予測は不要となる。そこで、モデム４０８は、ＮＣＵ４０９がＩＰネットワークを経由する通信であることを検出した場合には、図６に示すフローを実行するように制御する。一方、モデム４０８は、ＮＣＵがＩＰネットワークを経由しない通信であることを検出した場合には、図６に示すフローのうち、ステップＳ４，Ｓ６，Ｓ１１を除く部分の各ステップを実行するよう制御する。つまり、モデム４０８は、ＮＣＵがＩＰネットワークを経由しない通信であることを検出した場合には、プライマリチャネルの後端を示すＲＣＰ信号を受信したことによりコントロールチャネルへ移行するよう制御する。
【００４５】
［実施形態２］
以下、図８〜図１１を参照して本発明の実施形態２を詳細に説明する。尚、この実施形態２に係る通信装置のハードウェア構成は前述の実施形態１に係る通信装置と同じ構成であるため、その説明を省略する。
【００４６】
図８、図９及び図１０は、本発明の実施形態２に係る通信装置における送信処理を説明するフローチャートである。ここではプライマリチャネル（ＰＣ）での画像データ送信後の次ページ無しの場合の後手順処理において、コマンド再送回数の変更とフォールバック処理を説明している。尚、この処理を実行するプログラムはＲＯＭ４０２に記憶されており、ＣＰＵ４０１の制御の下に実行される。この処理は、送信側である通信装置からの発呼後、受信機（相手機）とＶ．３４のフェーズ１〜５を経てプライマリチャネル送信処理へ移行することにより開始される。
【００４７】
先ずステップＳ３１で、プライマリチャネルで画像データをＥＣＭのフレーム単位で送信する。その後ステップＳ３２に進み、プライマリチャネルでのデータ送信終了を示すＲＣＰ信号を送出する。そしてステップＳ３３に進み、プライマリチャネルからコントロールチャネルへ切換えて後手順の信号であるＰＰＳ−ＥＯＰを送信する。次にステップＳ３４に進み、受信機からの応答を、例えば３秒間待つ。ここで３秒間応答が無い場合はステップＳ３６に進み、コマンドの再送回数（Ｘ）を決定する。
【００４８】
図９は、ステップＳ３６のコマンドの再送回数を決定する処理を説明するフローチャートである。この図９を参照してステップＳ３６の処理を説明する。
【００４９】
先ずステップＳ６１で、ファクシミリ手順での初期識別信号又は命令受信信号を受信した場合に非標準機能信号に含まれるメーカコードを取得し、かつＩＰネットワーク経由の通信であるか否かを確認する。そして、その取得したメーカコードが自機のコードと一致し、且つＩＰネットワーク経由の通信であると判断した場合はステップＳ６２に進み、試行回数を予め登録してある任意の回数（３以上が好ましい）に設定する。それ以外の場合はステップＳ６１からステップＳ６３に進み、ＩＴＵ−Ｔ勧告で指定されている３回に設定する。
【００５０】
そしてステップＳ３７で、ＰＰＳ−ＥＯＰ信号を規定回数送信(ここではＸ回）したかどうかを判定し、再送した回数がＸ回に到達していないときはステップＳ３３に戻ってＰＰＳ−ＥＯＰ信号の再送信を行う。ここでＸ回再送したときはステップＳ３７からステップＳ５０に進んでＤＣＮ信号を送信する。そしてステップＳ５１で回線を切断して処理を終了する。
【００５１】
一方ステップＳ３４で、受信機からの応答があるとステップＳ３８に進み、受信機からＰＰＲ信号を受信したか否かを判断する。ＰＰＲ信号を受信した場合はステップＳ３９に進み、フォールバック（通信速度減速処理）のための、ＰＰＲの受信回数を選択する。
【００５２】
図１０（Ａ）は、ステップＳ３９のＰＰＲの受信回数を決定する処理を説明するフローチャートである。この図１０（Ａ）を参照してステップＳ３９の処理を説明する。
【００５３】
先ずステップＳ７１で、前手順での初期識別信号を受信した非標準機能信号に含まれるメーカコードを取得し、かつＩＰネットワーク経由の通信であるか否かを確認する。ここでメーカコードが自機のコードと一致し、且つＩＰネットワーク経由の通信であると判断するとステップＳ７２に進む。ステップＳ７２では、フォールバックのためのＰＰＲ受信回数を予め登録してある任意の回数Ｙ（２以上が好ましい）に決定する。それ以外の場合はステップＳ７３に進み、２回（Ｙ＝２）に決定する。
【００５４】
次にステップＳ４０に進み、ステップＳ３９で決定したＹ回、ＰＰＲを受信したか否かを判断する。ここでＹ回受信したと判断した場合はステップＳ４１に進み、フォールバックが可能かを判断する。ここでフォールバックが不可能な場合はステップＳ４６に進み、ＥＯＲ送信処理を行って再送を中止する。
【００５５】
一方ステップＳ４１で、フォールバックが可能な場合はステップＳ４２に進み、フォールバックの減速速度を決定する。
【００５６】
図１０（Ｂ）は、ステップＳ４２のフォールバックの減速速度を決定する処理を説明するフローチャートである。この図１０（Ｂ）を参照してステップＳ４２の処理を説明する。
【００５７】
先ずステップＳ８１で、前手順での初期識別信号を受信した非標準機能信号に含まれるメーカコードを取得し、かつＩＰネットワーク経由の通信であるか否かを確認する。ここでメーカコードが一致し、且つＩＰネットワーク経由の通信であると判断した場合はステップＳ８２に進み、フォールバックのための減速速度の割合を、予め登録してある速度減速分（Ｚ）に決定する。それ以外の場合はステップＳ８３に進み、従来の４８００ｂｐｓに決定する。
【００５８】
こうしてフォールバックの減速速度を決定するとステップＳ４３に進み、その決定されたＺbpsの減速速度を、前回のプライマリチャネルの送信速度から引いた送信速度で通信を行うようにモデム４０８に対して設定する。次にステップＳ４４に進み、受信したＰＰＲ信号で指定されたエラーフレームの再送信を行った後、ステップＳ４５で、プライマリチャネルでのデータ送信終了を示すＲＣＰ信号を送信してステップＳ３３に戻る。
【００５９】
一方、ステップＳ３８で、ステップＳ３４で受信した信号がＲＮＲ信号であると判断した場合はステップＳ４７に進む。ステップＳ４７では、その受信したデータをデコードできていないためＲＲ信号を送信して応答を待つ。ここでＲＲ応答受信が無い場合はステップＳ５０に進み、ＤＣＮ信号を送信し、回線切断して通信を終了する。一方ステップＳ４７で、ＲＲ応答を受信した場合はステップＳ４６に進む。
【００６０】
またステップＳ４６でＲＮＲではなく、ステップＳ４８でＭＣＦ信号を受信した場合にはステップＳ５０に進み、ＤＣＮ信号を送信し回線切断して通信を終了する。それ以外の信号の場合はステップＳ４８からステップＳ４９に進み、エラーコードを設定してステップＳ５０に進み、ＤＣＮ信号を送信し回線切断して通信を終了する。
【００６１】
図１１は、前述の図８〜図１０を参照して説明したメーカコードが一致し、かつＩＰネットワーク経由の通信である場合の処理の比較例を示す図である。
【００６２】
１００１は、フォールバックのＰＰＲ受信回数を２回とし、減速速度を４８００ｂｐｓとした従来の場合に、最大何回プライマリチャネルが利用可能であるかを示している。
【００６３】
また１００２は、フォールバックのＰＰＲ受信回数を２回から４回に変更し、フォールバックの減速速度割合を４８００ｂｐｓから２４００ｂｐｓに変更した場合を示している。そして、これにより、これ以上フォールバックできなくなるまで最大何回プライマリチャネルが利用可能であるかが分かる。
【００６４】
このように１００１と１００２とを比較すると、２８８００ｂｐｓからスタートし、毎プライマリチャネルで回線障害が発生したと単純計算した場合、１００２の場合には、４倍の回数プライマリチャネルが利用可能になっていることが分かる。
【００６５】
尚、上記実施形態１，２において、ＩＰネットワーク経由の通信かどうかを判定する検出方法としては、ＩＰネットワークに接続されていることが予め登録されていて、それを参照しても良い。
【００６６】
また或は、発呼番号が「０５０」で始まる電話番号である場合に、ＩＰネットワーク経由の通信であると判断しても良い。
【００６７】
また或は、着信時に通知される発信者電話番号（ナンバーディスプレイ番号）が「０５０」で始まる電話番号であるである場合に、ＩＰネットワーク経由の通信であると判断しても良い。
【００６８】
また或は、ファクシミリ手順で交換される通信端末識別信号（ＴＳＩ）又は被呼端末識別信号（ＣＳＩ）が「０５０」で始まる電話番号である場合に、ＩＰネットワーク経由の通信であると判断しても良い。
【００６９】
以上説明したように本実施形態によれば、Ｖ．３４通信において突発的な回線障害が発生した場合でも、プライマリチャネルやコントロールチャネルにおけるモデムの発散／キャリア断による通信エラーを回避できる。これによりエラー終了に至ることなく通信を継続させることができる。
【００７０】
また本実施形態によれば、瞬断でプライマリチャネル後端（ＲＣＰ信号）を検出できなくても、コントロールチャネルへ確実に移行できる。
【００７１】
また本実施形態によれば、コントロールチャネルで回線障害が発生してもリカバリーの機会を増やし通信を継続させることができるという効果がある。
【００７２】
また本実施形態によれば、回線障害が多発するような回線で高解像度の大量ページの通信も途中エラーで終了する割合を大幅に削減できる。
【図面の簡単な説明】
【００７３】
【図１】一般的な公衆電話網とインターネット、ＩＰネットワーク／ＩＰ電話との接続を説明する図である。
【図２】ＩＰネットワークを介した通信におけるパケットの到着の揺らぎやパケットの消失例を説明する図である。
【図３】Ｖ．３４モデムで通信中にＩＰネットワークからの影響による瞬断が発生した場合に、ファクシミリ通信が受信機側でエラー終了する過程を送信／受信信号の様子から時系列的に説明する図である。
【図４】本発明の実施形態１に係る通信装置の構成を示すブロック図である。
【図５】本発明の実施形態における回線障害を回避する具体例を説明するシーケンス図である。
【図６】本発明の実施形態に係る通信装置における受信処理を説明するフローチャートである。
【図７】図６のステップＳ４の処理を説明するフローチャートである。
【図８】本発明の実施形態２に係る通信装置における送信処理を説明するフローチャートである。
【図９】図８のステップＳ３６のコマンドの再送回数を決定する処理を説明するフローチャートである。
【図１０】図８のステップＳ３９のＰＰＲの受信回数を決定する処理を説明するフローチャート（Ａ）と、図８のステップＳ４２のフォールバックの減速速度を決定する処理を説明するフローチャートである。
【図１１】本発明の実施形態２におけるフォールバック処理を行った場合と従来の処理との比較図である。
【図１】
2009253648.tif 000003
【図２】
2009253648.tif 000004
【図３】
2009253648.tif 000005
【図４】
2009253648.tif 000006
【図５】
2009253648.tif 000007
【図６】
2009253648.tif 000008
【図７】
2009253648.tif 000009
【図８】
2009253648.tif 000010
【図９】
2009253648.tif 000011
【図１０】
2009253648.tif 000012
【図１１】
2009253648.tif 000013