(57)【特許請求の範囲】
【請求項１】
無線端末が、メール着信通知に応答してプロキシ回線からプロキシサーバ経由で受信メールサーバに接続して受動フェッチセッションを確立し、受信メールを取得する電子メールシステムの電子メールトラヒック規制装置において、
プロキシ回線の許容帯域を設定する許容帯域設定手段と、
メール受信に係る１フェッチセッション当たりの転送データ量を検知する転送データ量検知手段と、
前記プロキシ回線の許容帯域およびフェッチセッション当たりの転送データ量に基づいて、当該プロキシ回線に許容するメール受信レートを算出する許容レート算出手段と、
メール着信通知とは無関係に確立される能動フェッチの発生レートを算出する手段と、
前記メール受信の許容レートおよび能動フェッチの発生レートに基づいて、受信メールサーバに蓄積された受信メールの宛先を有する端末へ着信通知を配信するレートを決定する着信通知レート決定手段と、
前記決定された着信通知の配信レートに基づいて、前記受信メールの宛先を有する端末へ着信通知を配信する着信通知配信手段とを具備したことを特徴とする電子メールトラヒック規制装置。
【請求項２】
前記着信通知レート決定手段は、前記着信通知の配信レートを、前記メール受信の許容レートから前記能動フェッチの発生レートを減じたレートに決定することを特徴とする請求項１に記載の電子メールトラヒック規制装置。
【請求項３】
無線端末が、メール着信通知に応答してプロキシ回線からプロキシサーバ経由で受信メールサーバに接続して受動フェッチセッションを確立し、受信メールを取得する電子メールシステムの電子メールトラヒック規制装置において、
プロキシ回線の許容帯域を設定する許容帯域設定手段と、
メール受信に係る１フェッチセッション当たりの転送データ量を検知する転送データ量検知手段と、
前記プロキシ回線の許容帯域およびフェッチセッション当たりの転送データ量に基づいて、当該プロキシ回線に許容するメール受信レートを算出する許容レート算出手段と、
前記着信通知に対して受動フェッチセッションを確立しない無応答端末の発生レートを取得する手段と、
前記メール受信の許容レートおよび無応答端末の発生レートに基づいて、受信メールサーバに蓄積された受信メールの宛先を有する端末へ着信通知を配信するレートを決定する着信通知レート決定手段と、
前記決定された着信通知の配信レートに基づいて、前記受信メールの宛先を有する端末へ着信通知を配信する着信通知配信手段とを具備したことを特徴とする電子メールトラヒック規制装置。
【請求項４】
前記着信通知レート決定手段は、前記着信通知の配信レートを、前記メール受信の許容レートに前記無応答端末の発生レートを加えたレートに決定することを特徴とする請求項３に記載の電子メールトラヒック規制装置。
【請求項５】
能動フェッチに対応した受信メールが蓄積されていない空フェッチを検知する手段をさらに具備し、
前記着信通知レート決定手段は、前記着信通知の配信レートを、能動フェッチ数から前記空フェッチ数を減じることを特徴とする請求項１ないし４のいずれかに記載の電子メールトラヒック規制装置。
【請求項６】
前記プロキシ回線をプロキシサーバ経由で受信メールサーバと接続する経路が多段に設けられ、
段違いのプロキシサーバおよび受信メールサーバを相互に接続する手段と、
段毎にプロキシ回線のメール受信に関するフェッチの発生レートを算出する手段とを具備し、
前記着信通知レート決定手段は、前記着信通知の配信レートを、フェッチレートが最大値のプロキシ回線の許容レートに基づいて決定することを特徴とする請求項１に記載の電子メールトラヒック規制装置。
【請求項７】
前記プロキシ回線をプロキシサーバ経由で受信メールサーバと接続する経路が多段に設けられ、
段違いのプロキシサーバおよび受信メールサーバを相互に接続する手段と、
各プロキシ回線の混雑度を監視する手段とを具備し、
前記着信通知レート決定手段は、混雑度のより低いプロキシ回線を経由して接続する端末に対して着信通知を優先的に配信するというポリシーのもとで着信通知の配信レートを決定することを特徴とする請求項１に記載の電子メールトラヒック規制装置。
【請求項８】
前記プロキシ回線をプロキシサーバ経由で受信メールサーバと接続する経路が多段に設けられ、
段違いのプロキシサーバおよび受信メールサーバを相互に接続する手段と、
段毎にプロキシ回線のメール受信に関するフェッチの発生レートを算出する手段と、
前記各受信メールサーバにおける滞留メール数を監視する手段とをさらに具備し、
前記着信通知レート決定手段は、各受信メールサーバに関する着信通知の配信レートを、メール滞留率のより高い受信メールサーバの配信レートλctlをより高くし、かつ各配信レートに応じて転送される全ての受信メールが前記フェッチの発生レートに応じた割合で各プロキシ回線を中継するときに、フェッチレートが最大のプロキシ回線のメール受信レートが許容レート内に収まるように決定することを特徴とする請求項１に記載の電子メールトラヒック規制装置。
【請求項９】
前記プロキシ回線をプロキシサーバ経由で受信メールサーバと接続する経路が多段に設けられ、
段違いのプロキシサーバおよび受信メールサーバを相互に接続する手段と、
段毎にプロキシ回線のメール受信に関するフェッチの発生レートを算出する手段と、
前記各受信メールサーバにおけるメール保留時間を監視する手段とをさらに具備し、
前記着信通知レート決定手段は、各受信メールサーバに関する着信通知の配信レートを、メール保留時間のより長い受信メールサーバの配信レートλctlをより高くし、かつ各配信レートに応じて転送される全ての受信メールが前記フェッチの発生レートに応じた割合で各プロキシ回線を中継するときに、フェッチレートが最大のプロキシ回線のメール受信レートが許容レート内に収まるように決定することを特徴とする請求項１に記載の電子メールトラヒック規制装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メールトラヒック規制装置に係り、特に、ボトルネックの所在に関わらず、ボトルネックの輻輳ならびにプロキシサーバおよびメールサーバの過負荷を防止できる電子メールトラヒック規制装置に関する。
【背景技術】
【０００２】
電子メールのトラヒックによるネットワーク回線の輻輳やサーバの過負荷を防止する技術が種々提案されている。
【０００３】
特許文献１には、電子メールのサイズ合計や総数を監視し、配信を担当するメールサーバを負荷の状況に基づいて変更するシステムが開示されている。
【０００４】
特許文献２には、送信元ユーザのIPアドレスごとに送信メール数をカウントし、送信メール数が閾値を超えたユーザによるメールサーバへのアクセス、即ちメール送信を停止させるシステムが開示されている。
【０００５】
特許文献３には、ネットワークやサーバの輻輳状態により、メールの着信通知を規制あるいは遅延させ、さらには端末側の発信も規制することで、受信メールに対する返信メールの需要、すなわち発信需要を軽減するシステムが開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００９−１７７４３２号公報
【特許文献２】特開２００６−３１０９０２号公報
【特許文献３】特開２０１０−１６１５００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
電子メールトラヒックの集中によるネットワーク回線の輻輳やサーバの過負荷（以下、輻輳で総称する場合もある）は、年末年始や震災発生後など、多数のユーザが一斉に集中して電子メールを送受信する際に発生する可能性が高い。
【０００８】
特許文献１は、負荷の増大に伴ってメールサーバを変更する技術なので、ボトルネック回線において輻輳が発生しても、これを解消することはできない。
【０００９】
特許文献２では、輻輳が発生するとユーザのメール送信を停止することでトラヒックを規制しているが、電子メールトラヒックの集中による輻輳等は、受信トラヒックのみによっても発生し得るので、送信トラヒックの規制だけでは十分に抑制することが難しい。また、メール送信の規制は送信端末のユーザに認知されやすいので、ユーザのサービス利用感が大きく損なわれてしまう。さらに、受信トラヒックによる輻輳を送信トラヒックの規制で解消しようとしても、その送信元が他のネットワーク事業者により管理されている他のドメインであると規制できない。
【００１０】
特許文献３では、メール受信に伴う着信通知を規制または遅延させることで、受信メールの配信や受信メールへの返信に係る発信需要が抑制・軽減されるが、輻輳や過負荷を定量的に捉えることができないので、着信通知を規制または遅延させることはできても、輻輳等を発生させない適切な制御値を算出することはできない。
【００１１】
本発明の目的は、上記した従来技術の課題を全て解決し、ボトルネックの所在に関わらず、ボトルネックの輻輳ならびにプロキシサーバおよびメールサーバの過負荷を防止できる電子メールトラヒック規制装置を提供することにある。
【課題を解決するための手段】
【００１２】
上記の目的を達成するために、本発明は、無線端末が、メール着信通知に応答して受信メールサーバとの間にプロキシ回線およびプロキシサーバ経由で受動フェッチセッションを確立して受信メールを取得する電子メールシステムの受信メールトラヒック規制装置において、以下のような手段を講じた点に特徴がある。
【００１３】
(1)プロキシ回線の許容帯域を設定する許容帯域設定手段と、メール受信に係る１フェッチセッション当たりの転送データ量を検知する転送データ量検知手段と、プロキシ回線の許容帯域およびフェッチセッション当たりの転送データ量に基づいて、当該プロキシ回線に許容するメール受信レートを算出する許容レート算出手段と、メール受信の許容レートに基づいて、受信メールサーバに蓄積された受信メールの宛先を有する端末へ着信通知を配信するレートを決定する着信通知レート決定手段と、決定された着信通知レートに基づいて、受信メールの宛先を有する端末へ着信通知を配信する着信通知制御手段とを具備した。
【００１４】
(2)メール着信通知とは無関係に確立される能動フェッチの発生レートを算出する手段をさらに設け、前記着信通知レート決定手段は、前記着信通知の配信レートを、前記メール受信の許容レートおよび能動フェッチの発生レートに基づいて決定するようにした。
【００１５】
(3)着信通知レート決定手段は、着信通知の配信レートを、前記メール受信の許容レートから前記能動フェッチの発生レートを減じたレートに決定するようにした。
【００１６】
(4)着信通知に対して受動フェッチセッションを確立しない無応答端末の発生レートを取得する手段をさらに設け、着信通知レート決定手段は、着信通知の配信レートを、前記メール受信の許容レートおよび無応答端末の発生レートに基づいて決定するようにした。
【００１７】
(5)着信通知レート決定手段は、着信通知の配信レートを、メール受信の許容レートに前記無応答端末の発生レートを加えたレートに決定するようにした。
【００１８】
(6)プロキシ回線をプロキシサーバ経由で受信メールサーバと接続する経路を多段に設け、各段のプロキシサーバおよび受信メールサーバが相互に接続される多段構成において、プロキシ回線ごとにメール受信に関するフェッチレートを算出し、着信通知の配信レートが、メール受信の許容レートおよびプロキシ回線ごとに求まるフェッチレートの最大値に基づいて決定されるようにした。
【００１９】
(7)プロキシ回線をプロキシサーバ経由で受信メールサーバと接続する経路を多段に設け、各段のプロキシサーバおよび受信メールサーバが相互に接続される構成において、各プロキシ回線の混雑度を監視し、混雑度のより低いプロキシ回線を経由して接続する端末に対して着信通知を優先的に配信するようにした。
【００２０】
(8)多段構成において、各受信メールサーバの滞留メール数を監視する手段をさらに設け、着信通知配信手段は、各受信メールサーバに関する着信通知の配信レートを、メール滞留率のより高い受信メールサーバの配信レートをより高くし、かつ各配信レートに応じて転送される全ての受信メールが前記フェッチの発生レートに応じた割合で各プロキシ回線を中継するときに、フェッチレートが最大のプロキシ回線のメール受信レートが許容レート内に収まるように決定するようにした。
【００２１】
(9)多段構成において、各受信メールサーバのメール保留時間を監視する手段をさらに設け、着信通知配信手段は、各受信メールサーバに関する着信通知の配信レートを、メール保留時間のより長い受信メールサーバの配信レートをより高くし、かつ各配信レートに応じて転送される全ての受信メールが前記フェッチの発生レートに応じた割合で各プロキシ回線を中継するときに、フェッチレートが最大のプロキシ回線のメール受信レートが許容レート内に収まるように決定するようにした。
【発明の効果】
【００２２】
本発明によれば、以下のような効果が達成される。
【００２３】
(1)ボトルネックに輻輳を生じさせることなく、またプロキシサーバやメールサーバに過負荷を生じさせることなくプロキシ回線に許容できるセッションの確立レート（許容レート）は、プロキシ回線の帯域上限や１フェッチセッション当たりの転送データ量のみに依存し、無線区間や集約区間のスループットには依存しない。したがって、ボトルネックの所在に関わらず、プロキシ回線のメール受信レートを許容レート内に規制するのみで、ボトルネックの輻輳、ならびにプロキシサーバおよびメールサーバの過負荷を防止できるようになる。
【００２４】
(2)プロキシ回線のメール受信レートを、メール着信通知の配信レートを制御することで規制する際に、メール着信通知に応答して確立される受動フェッチセッションのみならず、着信通知を待たずに端末ユーザが任意のタイミングで確立する能動フェッチセッションも考慮されるので、プロキシ回線のメール受信レートを、より確実に許容レート内に規制できるようになる。
【００２５】
(3)プロキシ回線のメール受信レートを、メール着信通知の配信レートを制御することで規制する際に、無線端末の電源が切られていたり、所在地が電波の届かない場所であったりするために着信通知を受信できない、あるいは着信通知を受信できても応答しないなどの無応答端末の存在も考慮されるので、プロキシ回線のメール受信レートを、より確実に許容レート内に規制できるようになる。
【００２６】
(4)プロキシ回線をプロキシサーバ経由で受信メールサーバと接続する経路を多段に設け、各段のプロキシサーバおよび受信メールサーバが相互に接続される多段構成において、着信通知の配信レートが、プロキシ回線ごとに求まるフェッチレートの最大値に基づいて決定されるので、各段のプロキシ回線間でフェッチレートが異なる場合でも、プロキシ回線の使用帯域を許容帯域に制限できるようになる。
【００２７】
(5)プロキシ回線をプロキシサーバ経由で受信メールサーバと接続する経路を多段に設け、各段のプロキシサーバおよび受信メールサーバが相互に接続される構成において、混雑度のより低いプロキシ回線を経由して接続する端末に対して着信通知が優先的に配信されるので、各プロキシ回線のメール受信レートを均等化できる。
【００２８】
(6)多段構成において、滞留メール数のより多い受信メールサーバの配信レートを、フェッチレートが最大となるプロキシ回線のメール受信レートが許容レートに収まる範囲内でより高くしたので、各プロキシ回線の有効利用と受信メールサーバ間の滞留メール数の均一化とを実現できる。
【００２９】
(7)多段構成において、メール保留時間のより長い受信メールサーバの配信レートを、フェッチレートが最大となるプロキシ回線のメール受信レートが許容レートに収まる範囲内でより高くしたので、各プロキシ回線の有効利用と受信メールサーバ間のメール保留時間の均一化とを実現できる。
【図面の簡単な説明】
【００３０】
【図１】本発明が適用される電子メールシステムの構成を示したブロック図である。
【図２】電子メールの送受信シーケンスを示した図である。
【図３】本発明の基本的な考え方を説明するための図である。
【図４】無線区間がボトルネックとなるときでも、プロキシ回線の許容レートが無線区間のスループットに依存しないことを示した図である。
【図５】本発明の第１実施形態の機能ブロック図である。
【図６】本発明の第２実施形態の機能ブロック図である。
【図７】本発明の第３実施形態の機能ブロック図である。
【図８】本発明の第４実施形態の機能ブロック図である。
【発明を実施するための形態】
【００３１】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明が適用される電子メールシステムのネットワーク構成を示したブロック図であり、本発明の説明に不要な構成は図示が省略されている。
【００３２】
第１送信メールサーバ（群）１１は、送信端末MNs1からインターネットなどの広域ネットワーク経由で送信された電子メールを一時記憶する。第２送信メールサーバ（群）１２は、送信端末MNs2からRAN(Radio Access Network)経由で送信された電子メールを一時記憶する。各メールサーバ１１，１２は、前記一時記憶した電子メールをインターネットなどの広域ネットワーク１３およびGW/IX１４経由で、その宛先アドレスに対応した受信メールサーバ（群）１５へ送信する。
【００３３】
受信メールサーバ（群）１５において新たな電子メールが受信されると、着信通知配信装置１７は、着信通知をRAN経由で宛先の受信端末MNdへ配信する。前記受信メールサーバ１５に蓄積された電子メールは、前記着信通信を受信した各受信端末MNdからの受信メール要求（受動フェッチ）に応答して、プロキシサーバ１６、プロキシ回線１８およびRAN１９経由で各受信端末MNdへ配信される。
【００３４】
なお、受信メールの配信契機は前記着信通知配信装置１７からの着信通信に応答した端末ユーザによる受動フェッチのみならず、前記着信通信とは無関係に端末ユーザが任意のタイミングでメール受信操作を行って各受信端末MNdから受信メールサーバ１５へ受信メール要求（能動フェッチ）を送信したときも、当該受信端末宛の受信メールがたまたま蓄積されていれば配信契機と成り得る。
【００３５】
図２は、上記の電子メールシステムにおける電子メールの送受信シーケンスを示した図であり、時刻t1で送信端末MNs1（MNs2）から送信された電子メールは、時刻t2において送信メールサーバ１１（１２）で受信、蓄積されたのち、直ちに受信メールサーバ１５へ送信される。時刻t3では、受信メールサーバ１５から着信通知配信装置１７に対して、受信メールに関する着信通知の配信が依頼される。時刻t4では、着信通知配信装置１７が前記依頼に応答して、宛先の無線端末MNdへ着信通信を配信する。
【００３６】
時刻t5では、前記着信通知が宛先の受信端末MNdにおいて受信される。時刻t6では、前記受信端末MNdから受信メールサーバ１５に対して受信メール要求（受動フェッチ）が送信される。時刻t7では、受信メールサーバ１５が前記受信メール要求に応答して、蓄積されている受信メールを前記受信端末MNdへ送信する。時刻t8では、前記電子メールが受信端末MNdにおいて受信される。なお、受信メールの内容によっては、時刻t9において、当該受信メールに対して受信端末MNdから送信端末宛に返信メールが送信されることもある。
【００３７】
このような電子メールシステムでは、受信サーバ１５における着信通知配信装置１７への着信通知配信の依頼、あるいは着信通知配信装置１７における各宛先を有する端末への着信通知の配信を規制することにより、主に受動フェッチ動作を契機とする受信メールトラヒックを抑制できる。
【００３８】
次いで、図１のネットワーク構成を例にして、本発明の基本的な考え方を説明し、その後、本発明の具体的な構成および動作について説明する。
【００３９】
図３に模式的に表現したように、電子メールの受信ノードが無線端末であって、無線回線、RAN、プロキシ回線１８、プロキシサーバ１６を介して受信メールサーバ群１５との間にTCP/IPセッション（フェッチセッション）を確立して受信メールを受信する場合、その実用スループットはボトルネック部分のスループットに支配される。したがって、同図(a)に示したように、例えばプロキシ回線１８のスループットが100Mbpsであっても、無線区間がボトルネックのスループットが例えば50kbpsであれば、実用スループットは無線区間のスループットに支配されて50kbpsに制限されてしまう。なお、図３ではProxy１６を終端とする例を示して説明しているが、後段の受信メールサーバ（群）１５が終端となる構成の場合も同様である。
【００４０】
同様に、同図(b)に示したように、プロキシ回線１８のスループットが例えば5Mbpsであれば、無線区間のスループットが10Mbpsであっても、実用スループットはプロキシ回線１８のスループットに支配されて5Mbpsに制限されてしまう。
【００４１】
ここで、メールトラヒックの増大による輻輳は、ボトルネックを流れるメールトラヒックの総量が当該ボトルネックの回線容量を超えるような場合のみならず、同図(c)に示したように、着信通知を受信した受信端末から受信メールサーバ１５への受信メール要求が増え、その結果、プロキシサーバ１６や受信メールサーバ１５の同時接続セッション数が増えて新たなセッションを確立できなくなることによっても生じ得る。
【００４２】
しかも、サーバへの同時接続セッション数が増えると、セッション当たりの処理速度が低下するために各セッションの完了時間に遅れが生じ、さらに同時接続セッション数が増加してセッション当たりの処理速度が低下するという悪循環に陥り、セッションの確立時にサーバがエラーを返したり無応答となったりすることになる。
【００４３】
特にTCPでは、ひとたび輻輳が生じると、再送処理の頻発やウインドウサイズの縮小によりスループットの更なる低下が生じ得る。したがって、メールトラヒックによる輻輳を防止するためには、ボトルネックのメールトラヒック総量を回線容量以下に抑えるのみならず、プロキシサーバ１６やメールサーバ１５への同時接続セッション数を抑制する必要がある。
【００４４】
ここで、プロキシ回線１８の帯域上限をBW[bps]、無線区間のスループットをTP_air[kbps]とすれば、プロキシサーバ１６に対して許容できる最大同時接続セッション数Nは次式(1)で表される。
【００４５】
【数１】
0005808694.tif 000002
【００４６】
また、受信メールの平均サイズをsize[bit]とし、１フェッチセッション当たりの転送メール数が「１」であれば、１フェッチセッション当たりの保留時間T（データ転送時間）は次式(2)で表される。
【００４７】
【数２】
0005808694.tif 000003
【００４８】
さらに、単位時間（本実施形態では、1sec）毎に新たに確立を許可できるセッション数、すなわち許容メール受信レートλ[session/sec]は、次式(3)で表される。
【００４９】
【数３】
0005808694.tif 000004
【００５０】
したがって、プロキシ回線１８の許容メール受信レートλは、その帯域上限BWおよび１フェッチセッション当たりの転送データ量sizeのみに依存し、無線区間のスループットTP_airには依存しないことが判る。また、ボトルネックが無線区間ではなくプロキシ回線１８の場合や、無線区間からプロキス回線１８に移った場合も上記と同様で、無線区間のスループットに依存しない。
【００５１】
図４は、無線回線がボトルネックとなる場合の、主にプロキシ回線の許容メール受信レートλと無線回線のスループットTH_airとの関係の一例を示した図であり、ここでは、プロキシ回線１８の実効帯域上限BWmaxは90[Mbps]であるものの、スループットのバースト変動や規制の伸びしろなどを見越して許容帯域上限BWrealが80[Mbps]に設定されている。すなわち、前記許容帯域BW=BWrealである。また、平均メールサイズは15[kByte]であり、１回のフェッチ動作により１つの受信メールが取得されるものとする。
【００５２】
この場合、無線区間のスループットTP_airが例えば10[kbps]であると、許容同時接続セッション数Nは、上式(1)から8000セッションとなる。また、１フェッチセッション当たりの保留時間Tは、上式(2)から12[sec]となる。そして、許容メール受信レートλは、上式(3)から666.67[session/sec]となり、これはプロキシ回線の許容帯域上限BWrealが80[Mbps]である限り、無線区間のスループットTP_airに関わらず一定である。
【００５３】
本発明では、以上の考察に基づいて、プロキシ回線の許容帯域上限BWを予め設定すると共に、１フェッチセッション当たりの転送データ量（受信メールの平均サイズ）sizeを履歴情報またはリアルタイムでの監視結果から取得し、これらに基づいて許容メール受信レートλを算出する。そして、前記着信通知配信装置１７による着信通知の配信レートを、前記許容メール受信レートλに基づいて、例えば着信通知の配信レートと前記許容メール受信レートλとが一致するように制御することで、プロキシ回線の使用帯域を許容帯域上限以下に規制する。
【００５４】
図５は、本発明の第１実施形態の主要部の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表しているので、その説明は省略する。
【００５５】
許容レート算出装置２０において、許容帯域設定部２０１は、プロキシ回線１８の許容帯域BWを設定する。転送データ量検知部２０２は、受信メールサーバ１５に蓄積された各メールのデータサイズやプロキシ回線１８に流れるメールセッションのトラヒックをモニタした結果に基づいて、メール受信に係る１フェッチセッション当たりの平均的な転送データ量sizeを検知する。前記許容レート算出装置２０は、前記プロキシ回線１８の許容帯域BWおよび１フェッチセッション当たりの転送データ量sizeを上式(3)に適用することで、当該プロキシ回線１８に許容するメール受信レートλを算出する。
【００５６】
なお、１フェッチセッション当たりの平均的な転送データ量sizeは、ユーザのメール受信数や添付ファイルの有無など、受信メールの状況により時間的に変化するので、BWやsizeを所定の周期毎に見直し、見直し後の値を上式(3)に適用することで、前記メール受信レートλを適宜に更新するようにしても良い。
【００５７】
着信通知配信装置１７において、着信通知レート決定部１７１は、前記メール受信の許容レートλに基づいて、受信メールサーバ１５に蓄積された受信メールの宛先を有する端末への着信通知の配信レートλctlを、例えばメール受信の許容レートλと同一または同等のレートに設定する。着信通知制御部１７２は、前記決定された着信通知レートλctlで前記各受信メールの宛先を有する端末へ着信通知を配信する。
【００５８】
本実施形態によれば、ボトルネックの輻輳ならびにプロキシサーバおよびメールサーバの過負荷を防止できるメール受信レートの許容値を、プロキシ回線の帯域上限BWおよび１フェッチセッション当たりの転送データ量sizeに基づいて求めることができるので、メール受信レートを当該許容値に規制するだけで、ボトルネックの輻輳ならびにプロキシサーバおよびメールサーバの過負荷を防止できるようになる。
【００５９】
図６は、本発明の第２実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表しているので、その説明は省略する。本実施形態では、能動フェッチを考慮して着信通知の配信レートλctlが決定される。
【００６０】
着信通知配信装置１７において、能動フェッチレート検知部１７３は、端末ユーザがメール着信通知とは無関係に任意のタイミングで自らメールの送受信操作を行う能動フェッチの発生レートλactを検知する。
【００６１】
このような能動フェッチレートλactは、例えば着信通知配信装置１７が送信した着信通知数と受信メールサーバ１５において観測されたフェッチ数（受動・能動を問わない）との差分に基づいて求めることができる。また、着信通知配信装置１７が着信通知を送信した端末の識別情報（例えば、ユーザID）を管理しておけば、これを各フェチセッションの端末識別情報と比較することで、能動フェッチレートλactをより正確に検知することができる。
【００６２】
さらに、能動フェッチが必ずメールトラヒックを発生させるとは限らず、受信メールが存在しないときに行われた能動フェッチ（空フェッチ）ではメールトラヒックが発生しない。したがって、能動フェッチの数や割合と共に、各フェッチセッションでダウンロードされるデータの有無に基づいて空フェッチを検知し、これを能動フェッチ数から予め減じるようにすれば、真にメールトラヒックに影響する能動フェッチレートλactを算出できるようになる。
【００６３】
なお、端末ユーザによる能動フェッチ動作は、受信メールトラヒックの規制が厳しくなるほど頻度が高くなると推定できるので、受信メールトラヒックの規制内容と能動フェッチレートλactとの関係を表すモデルや関数を予め用意しておき、受信メールトラヒックの規制状況に基づいて算出されるようにしても良い。
【００６４】
前記着信通知レート決定部１７１は、前記メール受信の許容レートλおよび能動フェッチレートλactに基づいて、受信メールサーバ１５に蓄積された受信メールの宛先を有する端末への着信通知の配信レートλctlを、例えばメール受信の許容レートλと能動フェッチレートλactとの差分レート（λ−λact）に決定する。
【００６５】
本実施形態によれば、着信通知の配信レートλctlが能動フェッチレートλact分だけ予め低く設定されるので、能動フェッチセッションが発生しても、プロキシ回線１８の使用帯域を許容帯域上限内に抑えられるようになる。
【００６６】
図７は、本発明の第３実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表しているので、その説明は省略する。本実施形態では、前記着信通知配信装置１７から配信される着信通知に無応答な端末の存在を考慮して着信通知の配信レートλctlが決定される。
【００６７】
着信通知配信装置１７において、無応答レート検知部１７４は、無線端末の電源が切られていたり、所在地が電波の届かない圏外であったりするために前記着信通知を受信できない、あるいは着信通知を受信できても応答しないなど、着信通知に応答して受動フェッチセッションを確立しない無応答端末の発生レートλoffを検知する。
【００６８】
このような無応答端末レートλoffは、例えば着信通知配信装置１７が着信通知を送信した宛先端末の識別情報を管理し、これを応答端末の識別情報と比較することで応答率を算出し、その履歴情報を統計的に処理することで求められる。あるいは着信通知配信装置１７による着信通知の配信失敗数を監視し、その履歴情報を統計的に処理することで求めるようにしても良い。
【００６９】
前記着信通知レート決定部１７１は、前記メール受信の許容レートλおよび無応答端末レートλoffに基づいて、受信メールサーバ１５に蓄積された受信メールの宛先を有する端末への着信通知の配信レートλctlを、例えばメール受信の許容レートλと無応答端末レートλoffとの総和レート（λ＋λoff）に決定する。
【００７０】
なお、上記の各実施形態では、全てのプロキシ回線１８が一箇所に集約されている場合や、プロキシ１６及びプロキシ回線１８と受信メールサーバ１５とが1対1の関係である構成を例にして説明したが、図８に一例を示したように、プロキシ回線１８をプロキシサーバ１６経由で受信メールサーバ１５と接続する経路を多段に設け、各段のプロキシサーバ１６と受信メールサーバ１５とが相互に接続される多段構成とすることもできる。
【００７１】
しかしながら、このような多段構成の電子メールシステムでは、フェッチセッションが各段のプロキシ回線１８に分配される比率（プロキシ比率）が均等になるとは限らない。これは、各端末宛の受信メールが各段の受信メールサーバ１５のいずれに蓄積されるのかが、当該端末ユーザの契約時期や契約内容に応じて決定されるからであり、また、受信メールサーバ１５やプロキシ１６の変更は、当該変更に要するコストやサービス継続性等の観点から頻繁に実施することが現実的には難しいからである。
【００７２】
そのため、このような多段構成の電子メールシステムでは、例えばプロキシ回線１８ａを経由するフェッチ要求の対象となる受信メールが受信メールサーバ１５ａに蓄積されているとは限らず、事業者が管理する収容内容やネットワークの接続構成によっては受信メールサーバ１５ｂに蓄積されている場合もあるので、当該受信メールは受信メールサーバ１５ｂからプロキシ回線１８ａを経由して返信されることになる。したがって、プロキシ回線１８ａで観測されるフェッチレートでは受信メールサーバ１５aの許容メール受信レートを代表できない。
【００７３】
例えば、受信メールサーバ１５ａ，１５bの規制レートがいずれもλidealであり、この規制レートλidealに対応した各プロキシ回線１８ａ，１８ｂの許容帯域上限がいずれもλmaxであるときに、各プロキシ回線１８ａ、１８ｂで観測されるフェッチレートλの割合が0.8：0:2であるとする。この場合、受信メールサーバ１５ａ，１５bがいずれも規制レートλidealで運用されていても、プロキシ回線１８ａの使用帯域は1.6λmaxとなり、プロキシ回線１８bの使用帯域は0.4λmaxとなり得る。すなわち、フェッチレートλの高いプロキシ回線１８ａの使用帯域は許容帯域上限λmaxを超えてしまう場合がある。
【００７４】
したがって、このような電子メールシステムでは、フェッチレートλの割合が高いプロキシ回線１８ａに合わせて着信通知の配信レートλctlを設定する必要がある。上記の例であれば、着信通知の配信レートλctlは、他の実施形態と比べて1/1.6倍に設定することが望ましい。
【００７５】
また、上記の多段構成に係る電子メールシステムでは、各プロキシ回線１８の混雑度を監視し、前記着信通知配信装置１７は、混雑度のより低いプロキシ回線を経由して接続する端末に対して着信通知を優先的に配信するというポリシーのもとで、当該プロキシ回線の許容帯域およびフェッチセッション当たりの転送データ量に基づいてメール受信レートを算出しても良い。このようにすれば、各プロキシ回線１８のメール受信レートを均等化できる。
【００７６】
さらに、各プロキシ回線１８ａ，１８ｂで観測されるフェッチレートλの割合と、各受信メールサーバ１５ａ，１５ｂに各フェッチセッションが接続される割合とが既知ならば、着信通知の配信レートλctlを各受信メールサーバ１５ａ，１５ｂのメール滞留率に応じて最適化できる。
【００７７】
例えば、各プロキシ回線１８ａ，１８ｂで観測されるフェッチレートλの割合が0.8：0:2であり、そのときに各受信メールサーバ１５ａ，１５ｂにフェッチセッションが接続される割合が0.5：0.5であるならば、受信メールがいずれの受信サーバ１５に滞留しているかにかかわらず、各受信メールサーバ１５ａ，１５ｂから各端末へ返送される受信メールは、その８割がプロキシ回線１８ａを中継し、その２割がプロキシ回線１８ｂを中継することになる。
【００７８】
したがって、各受信メールサーバ１５ａ，１５ｂのメール滞留率が、例えば0.4：0:6であるならば、各受信サーバ１５ａ，１５ｂにおける着信通知の配信レートλctlを0.4：0:6とすることで、メール滞留率のより高い受信メールサーバ１５の配信レートλctlをより高くする。そして、さらに各配信レートλctlに応じて転送される全ての受信メールの８割がプロキシ回線１８ａを通過するとしたときのメール受信レートが、その許容レート内に収まるようにすれば、各プロキシ回線１８ａ，１８ｂの有効利用と受信メールサーバ間の滞留メール数の均一化とを実現できる。
【００７９】
あるいは、各受信メールサーバ１５におけるメールの保留時間を監視できれば、着信通知の配信レートλctlを各受信サーバ１５ａ，１５ｂのメール滞留率に応じて最適化できる。
【００８０】
例えば、各プロキシ回線１８ａ，１８ｂで観測されるフェッチレートλの割合が0.8：0:2であり、各受信メールサーバ１５ａ，１５ｂに各フェッチセッションが接続される割合が0.5：0.5であり、かつ各受信メールサーバ１５ａ，１５ｂにおけるメール保留時間の比率が0.4：0:6であるならば、各受信メールサーバ１５ａ，１５ｂにおける着信通知の配信レートλctlを0.4：0:6とすることで、メール保留時間のより長い受信メールサーバ１５の配信レートλctlをより高くする。
【００８１】
そして、さらに各配信レートλctlに応答して返信される全ての受信メールの８割がプロキシ回線１８ａを通過するとしたときの受信メールレートが、その許容レート内に収まるようにすれば、各プロキシ回線１８ａ，１８ｂの有効利用と受信メールサーバ間のメール保留時間の均一化とを実現できる。
【符号の説明】
【００８２】
１１…第１送信メールサーバ（群），１２…第２送信メールサーバ（群），１３…広域ネットワーク，１４…GW/IX，１５…受信メールサーバ，１６…プロキシサーバ，１７…着信通知配信装置，１８…プロキシ回線，１９…RAN，２０…許容レート算出装置，１７１…着信通知レート決定部，１７２…着信通知制御部，１７３…能動フェッチレート検知部，１７４…無応答レート検知部，２０１…許容帯域設定部，２０２…転送データ量検知部
【図１】
0005808694.tif 000005
【図２】
0005808694.tif 000006
【図３】
0005808694.tif 000007
【図４】
0005808694.tif 000008
【図５】
0005808694.tif 000009
【図６】
0005808694.tif 000010
【図７】
0005808694.tif 000011
【図８】
0005808694.tif 000012