特許 5918076 マルチホーム通信方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5918076

(24)【登録日】2016年4月15日

(45)【発行日】2016年5月18日

(54)【発明の名称】マルチホーム通信方法およびシステム

(51)【国際特許分類】

   H04W 4/00 20090101AFI20160428BHJP

   H04W 80/06 20090101ALI20160428BHJP

   H04L 12/905 20130101ALI20160428BHJP

   H04M 3/00 20060101ALI20160428BHJP

【ＦＩ】

   H04W4/00 111

   H04W80/06

   H04L12/905

   H04M3/00 C

【請求項の数】4

【全頁数】12

(21)【出願番号】特願2012-183230(P2012-183230)

(22)【出願日】2012年8月22日

(65)【公開番号】特開2014-42143(P2014-42143A)

(43)【公開日】2014年3月6日

【審査請求日】2015年1月21日

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100092772

【弁理士】

【氏名又は名称】阪本 清孝

(74)【代理人】

【識別番号】100084870

【弁理士】

【氏名又は名称】田中 香樹

(74)【代理人】

【識別番号】100119688

【弁理士】

【氏名又は名称】田邉 壽二

(72)【発明者】

【氏名】立花 篤男

(72)【発明者】

【氏名】長谷川 輝之

【審査官】 東 昌秋

(56)【参考文献】

【文献】 特開２００６−２７９４６７（ＪＰ，Ａ）

【文献】 特表２００６−５０１７０２（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｗ ４／００−９９／００

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｌ １２／００

Ｈ０４Ｍ ３／００

(57)【特許請求の範囲】

【請求項1】

複数のインタフェースを備えた一方のノードと複数のIPアドレスを割り当てられた他方のノードとの間にSCTPにより無線ネットワーク経由のマルチホーム接続を確立するマルチホーム通信方法において、
一方のノードにおいて、第１インタフェースが他方のノードの第１アドレス宛に初期化要求を送信し、これに他方のノードが応答して第１通信パスを接続することによりアソシエーションを確立する手順と、
一方のノードにおいて、第２インタフェースが接続されたネットワークのエリア内から、当該第２インタフェースが他方のノードの第２アドレス宛に通信パスの追加を要求する手順と、
一方のノードにおいて、前記第２アドレスへの通信パスの追加に成功することなく前記ネットワークとの接続が断たれると、当該第２アドレスのステータスをACTIVE(UNCONFIRMED)とする手順と、
一方のノードにおいて、前記ステータスがACTIVE(UNCONFIRMED)の第２アドレス宛に、疎通確認を経ずに追加要求を送信して通信パスを追加する手順とを含むことを特徴とするSCTPのマルチホーム通信方法。

【請求項2】

前記第２アドレスへの通信パスの追加に成功すると、前記一方および他方のノードにおいて、当該第２アドレスに関する通信パラメータを初期化する手順を更に含むことを特徴とする請求項１に記載のSCTPのマルチホーム通信方法。

【請求項3】

複数のインタフェースを備え、複数のIPアドレスを割り当てられた接続先ノードとの間にSCTPにより無線ネットワーク経由のマルチホーム接続を確立するマルチホーム通信システムにおいて、
第１インタフェースから接続先ノードの第１アドレス宛に初期化要求を送信して第１通信パスを接続し、接続先ノードとの間にアソシエーションを確立する手段と、
第２インタフェースが接続されたネットワークのエリア内から、当該第２インタフェースが接続先ノードの第２アドレス宛に通信パスの追加を要求する手段と、
前記第２アドレスへの通信パスの追加に成功することなく前記ネットワークとの接続が断たれると、当該第２アドレスのステータスをACTIVE(UNCONFIRMED)とする手段と、
前記ステータスがACTIVE(UNCONFIRMED)の第２アドレス宛に、疎通確認を経ずに追加要求を送信して通信パスを追加する手段とを具備したことを特徴とするSCTPのマルチホーム通信システム。

【請求項4】

前記第２アドレスへの通信パスの追加に成功すると、当該第２アドレスに関する通信パラメータを初期化する手段を更に具備したことを特徴とする請求項３に記載のSCTPのマルチホーム通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、モバイル端末のマルチホーム通信方法およびシステムに係り、特に、通信パスを短時間で追加することにより迅速なマルチホーム通信を可能にするSCTPのマルチホーム通信方法およびシステムに関する。

【背景技術】

【0002】

現在、3G、Wi-Fi、WiMAX、LTE等の複数の無線ネットワークに対応したAndroid OS搭載のモバイル端末MN(スマートフォン)が普及している。一般的なAndroid端末は、複数の無線ネットワークに同時接続することは行わず、一つの無線ネットワークのみに接続するため、接続中の無線ネットワークに障害や品質劣化が発生すると通信品質の劣化や通信セッションの切断が発生する。このような技術課題に対して、非特許文献１，２では、無線ネットワークの品質や周囲の電波強度・混雑度を測定し、接続するネットワークを選択する(切り替える)技術が研究・議論されているが、通信パスの切り替え基準や切り替え時間が問題となる。

【0003】

一方、トランスポートレイヤで通信パスを切替える技術として、エンドホスト間で複数の通信パスを用いたコネクションを確立し(マルチホーム)、１つの通信パス上で障害が発生した場合は、残りの通信パスにトラヒックを切り替えることで高信頼な通信を実現するSCTP(Stream Control Transmission Protocol：ストリーム制御伝送プロトコル)が研究開発され、非特許文献３，４に開始されている。

【0004】

非特許文献３，４に開示されている標準のSCTPでは、マルチホーム接続を確立した場合であっても、実際にデータ転送に用いるのは、１本の"プライマリパス"と呼ばれる通信パスのみであるため、障害や品質劣化の発生時においては、従来技術と同様に、他の通信パスの切り替え基準や切り替え時間が問題となる。

【0005】

一方、非特許文献６には、複数の通信パスで同時にデータ転送を行うことにより、通信(スループット)を高速化する手法（Concurrent Multi-path Transfer(CMT) SCTP）が提案されており、この手法は通信を高信頼化させる効果もある。また、非特許文献７には、CMT-SCTPを利用して、NAT環境においても通信パスの追加・削除を実現可能とする手法が提案されている。

【0006】

標準のSCTPは、FreeBSDやWindows(登録商標)等の多くのOS上に試験的に実装され、非特許文献５では、Android(Linux(登録商標))上で動作するライブラリも開発されている。しかしながら、現在のインタネットにおける通信の大半はTCP/UDPをベースとしており、SCTPを用いた一般ユーザ向けのモバイル通信サービスは展開されていない。このため、SCTP通信をエンドツーエンドで実現するためには、既存のサーバやコンピュータプログラムをSCTP通信に対応させる必要がある。

【先行技術文献】

【非特許文献】

【0007】

【非特許文献1】福山他、"IPv4 移動体通信において携帯電話網と無線LAN 間をシームレスに移動する方式の提案," マルチメディア、分散協調とモバイルシンポジウム 2011 論文集，pp.1115-1120, 2011.

【非特許文献2】Access Network Discovery and Selection Function (ANDSF)

【非特許文献3】RFC 3286 - An Introduction to the Stream Control Transmission Protocol

【非特許文献4】RFC 2960 - Stream Control Transmission Protocol

【非特許文献5】SCTP library (sctplib) [URL]: http://www.sctp.de/sctp-download.html

【非特許文献6】J. R. Iyengar, P. D. Amer, and R. Stewart, ``Concurrent Multipath Transfer Using SCTP Multihoming Over Independent End-to-End Paths,'' IEEE/ACM Transactions on Networking, Vol. 14, No. 5, Oct 2006.

【非特許文献7】RFC5061-Streaming Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration

【発明の概要】

【発明が解決しようとする課題】

【0008】

SCTPでは、エンドホスト間に１本の通信パス（プライマリパス）を接続し、これを利用してアソシエーション(ホスト間コネクション)を確立した後、別の通信パスを追加することでマルチホーム接続を実現できる。例えば、3Gネットワークを介してサーバSと通信を行なっているモバイル端末MNが、Wi-Fi等の異種の無線ネットワークのエリア内に移動した際、前記3Gネットワーク経由の通信パスを維持したまま、Wi-Fiネットワーク経由の通信パスを新たに追加することが可能である。しかしながら、従来のSCTPでは以下に詳述するように、所定の条件下で通信パスを迅速に追加できない問題が生じ得る。

【0009】

ここでは、図７のシーケンスフローを参照しながら、３つの通信方式3G、Wi-Fi（登録商標）、WiMAX（登録商標）にそれぞれ対応する３つのインタフェースa1，a2，a3を備えたモバイル端末MNが、SCTPを利用して、２つのグローバルIPアドレス(b1，b2)を割り当てられているサーバSとの間にマルチホーム接続を確立する場合を例にして、従来のSCTPの問題点を説明する。

【0010】

(1)モバイル端末MNは、そのインタフェースa1のみが3Gネットワークに接続している状態において、サーバSとの間にアソシエーションを確立するため、時刻t1において、自身のルーティング設定に従い、インタフェースa1から3Gネットワーク経由でサーバSの1つのIPアドレス(ここでは、b1)宛にINITチャンクを送出する。

【0011】

このINITチャンクを受信したサーバSは、SCTPの標準仕様に従い、時刻t2において、自身に割り当てられている全てのIPアドレス(b1，b2)をINIT-ACKチャンクに記述して返信し、これにより最初の通信パス（プライマリパス）[a1-b1]が接続される。その後、モバイル端末MNおよびサーバSは、時刻t3、t4において、前記通信パス[a1-b1]を利用して認証処理のためにCOOKIE-ECHO/COOKIE-ACKチャンクを送受信することでアソシエーションを確立する。

【0012】

このとき、SCTPでは各エンドホストが通信パスのステータス(ACTIVE/INACTIVE)、チャンク再送間隔およびエラーカウンタ等の通信パラメータを、通信相手への宛先IPアドレスごとに管理する設計となっている。すなわち、SCTPでは各通信パスが、送信元および宛先の各IPアドレスのペアでは管理されず、宛先IPアドレスのみで管理される。このため、モバイル端末MNはサーバSとの間にアソシエーションの確立に成功した後、時刻t5において、インタフェースa1からサーバSのIPアドレスb2宛にHEARTBEATを送信し、時刻t6においてHEARTBEAT-ACKが返信されると、実際には疎通確認されていない他のインタフェースa2、a3を含む全てのインタフェースについても、サーバSのIPアドレスb2に対して疎通可能であると認識する。また、エラーカウンタや輻輳ウィンドウ等のパス単位で設定される通信パラメータに関しても、宛先IPアドレス(b2)が同一である通信パス[a1-b2]による通信時の値が、他の未接続の通信パス[a2-b2]、[a3-b2]に適用される。

【0013】

(2)次いで、モバイル端末MNが、実際にはインタネットへの接続性がないWi-Fiネットワークエリア内に入り、インタフェースa2が有効になった状況、すなわちモバイル端末MNのインタフェースa2の状態がDOWNからUPに変化し、IPアドレスが動的に付与された状況を考える。

【0014】

モバイル端末MNは、IPアドレスb2に関してサーバSへの疎通性があると認識しているため、自身のインタフェースa2とサーバSのIPアドレスb2との間に通信パスを追加するためのASCONF(Address Configuration)チャンクを、時刻t7において、当該インタフェースa2からIPアドレスb2宛に送出する。しかしながら、接続されているWi-Fiネットワークはインタネットへの接続性がないため、前記ASCONFはサーバSに到着しない。

【0015】

モバイル端末MNは、送出したASCONFチャンクに対するサーバSからの返信(ASCONF-ACK)を一定時間内に受信できない場合、独自に計算した時間間隔(再送タイムアウト時間)でASCONFチャンクの再送を繰り返し、その後、再送回数(エラーカウンタ)が上限を超えると、時刻t8において、IPアドレスb2のステータスを「INACTIVE（到達不能）」と判断する。

【0016】

その後、モバイル端末MNは時刻t9において、前記プライマリパス[a1-b1]を介して、アドレス追加のためのASCONFチャンクを送出するが、サーバSでは、既登録のインタフェースa1からのASCONFチャンクと認識されるので当該ASCONFの受信は無視される。これは、プライマリパス経由の送信処理は、サーバSが受信するASCONFチャンクのシーケンス番号の連続性を保つための処理であり、アドレス追加に関する効果がない(SCTPでは、ASCONFのシーケンス番号の連続性が考慮される)ことによる。

【0017】

その後、モバイル端末MNは、「INACTIVE」とされたIPアドレスb2への疎通確認を行うため、独自に計算した時間間隔(通常は数10秒間隔)で、インタフェースa1またはa2からIPアドレスb2宛にHEARTBEATの送信を繰り返す。この際、インタフェースa1，a2のいずれがHEARTBEATの送出元となるかはSCTPの実装に依存する。

【0018】

(3)HEARTBEATがモバイル端末MNのインタフェースa1から送信される場合、HEARTBEATの疎通に成功するので、モバイル端末MNは、再度、IPアドレスb2へのパスを「ACTIVE」と判定し、インタフェースa2からIPアドレスb2に対してASCONFチャンクを送出するが、実際にはa2-b2を介した疎通には成功しない。この結果、インタフェースa1からb2に対するHEARTBEATの疎通成功とインタフェースa2からb2に対するASCONFチャンクの疎通失敗とが繰り返されることになる。

【0019】

一方、HEARTBEATがインタフェースa2から送信される場合、HEARTBEATの疎通に成功しないので、HEARTBEATの再送が繰り返されることになる。ここで、いずれの場合であっても、モバイル端末MNからIPアドレスb2への疎通(状態)確認は、HEARTBEATの送出間隔(通常は最大で数10秒間隔)に基づいて実行されることになる。

【0020】

(4)その後、モバイル端末MNがインタネットに接続可能なWi-Fiネットワークのエリア内に入り、インタフェースa3が有効になってIPアドレスを付与された状況、あるいはインタフェースa2がインタネットに接続可能な別のWi-Fiネットワークに接続された状況を考える。

【0021】

ここで、モバイル端末MNがインタフェースa3を用いて通信パスの追加を行う場合、本来であれば、モバイル端末MNはIPアドレスの変更やインタフェースの状態変化(UP/Down)により新たな接続を認識し、即座に新たな通信パス[a3-b2]あるいは[a2-b2]の追加を試みるべきである。しかしながら、上述の通り、モバイル端末MNからサーバSのIPアドレスb2へ至る通信パス[a2-b2]の疎通確認は、モバイル端末MNが使用するインタフェースa1，a2，a3の区別なく、HEARTBEATの送出間隔で実施されるため、即座にASCONFチャンクを送出することができない。すなわち、ステータスが「INACTIVE」のIPアドレスb2については、HEARTBEATの疎通に成功してステータスが「ACTIVE」とされる時刻t10までASCONF Addを送出できない。このため、モバイル端末MNが新たな無線ネットワークを介してサーバSとの通信が可能になったとしても、即座に通信パスを追加できない。

【0022】

また、HEARTBEATがインタフェースa1から送出されている場合、IPアドレスb2への通信パスが追加された後においても、a1-b2間の通信パラメータ(チャンク再送間隔やエラーカウンタ等)が、宛先IPアドレスが同じb2であるものの通信品質の異なる他の通信パスのパラメータとして利用されてしまうため、SCTPにおける通信パスの状態の管理や制御が非効率なものとなる問題が発生する。

【0023】

本発明の第１の目的は、モバイル端末のネットワーク環境が、サーバ側との疎通が不能な状態から可能な状態に遷移すると、HERTBEATによる疎通確認を待たずに、通信パスの追加要求(ASCCONF Add)を直ちに送出できるようにすることで、素早いマルチホーム接続を可能にすることにある。

【0024】

本発明の第２の目的は、マルチホーム接続のために追加された通信パスの通信パラメータを、先に接続されている通信パスの通信パラメータから独立させることで、追加された通信パスに対して、異なるネットワーク環境下で先に接続済みの通信パラメータが適用されないようにすることにある。

【課題を解決するための手段】

【0025】

上記の目的を達成するために、本発明は、複数のインタフェースを備えた一方のノードと複数のIPアドレスを割り当てられた他方のノードとの間にSCTPにより無線ネットワーク経由のマルチホーム接続を確立するマルチホーム通信方法において、以下のような手段を講じた点に特徴がある。

【0026】

(1)一方のノードにおいて、第１インタフェースが他方のノードの第１アドレス宛に初期化要求を送信し、これに他方のノードが応答して第１通信パスを接続することによりアソシエーションを確立する手順と、一方のノードにおいて、第２インタフェースが接続されたネットワークのエリア内から、他方のノードの第２アドレス宛に通信パスの追加を要求する手順と、一方のノードにおいて、前記第２アドレスへの通信パスの追加に成功することなく前記ネットワークとの接続が断たれると、当該第２アドレスのステータスをACTIVE(UNCONFIRMED)とする手順と、一方のノードにおいて、前記ステータスがACTIVE(UNCONFIRMED)の第２アドレス宛に、疎通確認を経ずに追加要求を送信して通信パスを追加する手順とを設けた。

【0027】

(2)前記第２アドレスへの通信パスの追加に成功すると、前記一方および他方のノードにおいて、当該第２アドレスに関する通信パラメータを初期化する手順を更に設けた。

【発明の効果】

【0028】

本発明によれば、以下のような効果が達成される。
(1)SCTPの標準仕様では、プライマリパスの接続によりアソシエーションの確立されたモバイル端末／サーバ間にモバイル端末側から通信パス（セカンダリパス）を追加する際、疎通が確認されていないためにステータスが「INACTIVE」のIPアドレスに対しては、モバイル端末がIPアドレスへの疎通可能なネットワーク環境へ移動したとしても、通信パスの追加要求(ASCONF)を直ぐには送出できず、周期的なHERTBEATにより前記IPアドレスへの疎通が確認され、当該IPアドレスのステータスが「ACTIVE」に切り替わった後でなければASCONFを送出できない。

【0029】

これに対して、本発明では疎通に失敗したIPアドレスのステータスが、SCTPの標準仕様で定められた「INACTIVE」ではなく「ACTIVE(UNCONFIRMED)」とされ、かつ当該「ACTIVE(UNCONFIRMED)」においてASCONFを送出できるようにようにSCTPが拡張される。したがって、当該IPアドレスに対する通信パスの接続を試行する際には、HERTBEATによる疎通確認を待たずに直ちにASCONFを送出することが可能になり、素早いマルチパス通信が可能になる。

【0030】

(2)SCTPの標準仕様では、ある宛先IPアドレスとの通信パスに設定された通信パラメータが、その後、同じ宛先IPアドレスとの間に異なるネットワーク経由で接続された通信パスに引き継がれてしまうのに対して、本発明では、以前と同じ宛先IPアドレスとの間に通信パスを接続する際には、その通信パラメータが初期化されるようにSCTPが拡張される。したがって、通信環境や条件の異なる通信パラメータが、宛先IPアドレスが同一であるという理由で無条件に他の通信パスにも設定されてしまうことによる通信効率の低下を防止できる。

【図面の簡単な説明】

【0031】

【図1】本発明に係るSCTP通信システムの第１実施形態のブロック図である。

【図2】本発明が適用されるネットワーク構成の一例を示した図である。

【図3】本発明が適用されるネットワーク構成の他の一例を示した図である。

【図4】本発明の第１実施形態に係るマルチホーム接続の手順を示したシーケンスフローである。

【図5】本発明に係るSCTP通信システムの第２実施形態のブロック図である。

【図6】本発明の第２実施形態に係るマルチホーム接続の手順を示したシーケンスフローである。

【図7】従来のマルチホーム接続の手順を示したシーケンスフローである。

【発明を実施するための形態】

【0032】

以下、図面を参照して本発明の実施の形態について詳細に説明する。本発明は、図２に示したように、専用ソフトウェアをインストール可能なサーバ・コンピュータプログラムとモバイル端末MNとの間でSCTPをベースとしたマルチホーム通信を行うシステムにおいて、通信を高信頼化する手順に関するものである(図中のSCTPベース通信ソフトにおける処理手順)。

【0033】

また、図３に一例を示したように、IPネットワーク内にプロトコル変換サーバを設置し、SCTP通信とTCP通信とを変換することにより、既存のサーバ・コンピュータを変更することなく、SCTPをベースとしたマルチホーム通信システムを実現する手法も考えられる。本発明は、このようなプロトコル変換サーバを介して既存のサーバ・コンピュータと通信を行うシステムにも適用できる。

【0034】

図１は、本発明に係るSCTP通信システムの第１実施形態の構成を示したブロック図であり、本発明の説明に不要な構成は図示が省略されている。ここでは、モバイル端末MNからサーバSへのマルチホーム接続を例にして説明する。

【0035】

モバイル端末MNおよびサーバSの各ネットワークノードには、インタフェース層、ネットワーク層、トランスポート層およびアプリケーション層から構成されるIPスタックが実装され、トランスポート層のプロトコルとしてSCTPが採用されている。モバイル端末MNおよびサーバSの各SCTPは、一つのアソシエーション１１で複数の通信パス１０を接続するマルチホーム接続用の標準機能に加えて、本発明に固有の拡張機能を備え、これにより通信パス１０の迅速な追加によるマルチホーム通信を可能にしている。

【0036】

モバイル端末MNのトランスポート層(SCTP)において、第１拡張部１２は、モバイル端末MNのネットワーク環境が、サーバSに割り当てられているIPアドレスとの疎通が不能な状態から可能な状態に遷移した際に、HERTBEATによる疎通確認を待たずに、通信パスの追加要求(ASCCONF Add)を直ちに送出できるようにSCTPを拡張する。

【0037】

図４は、上記の拡張機能を備えたモバイル端末MN/サーバS間でのマルチホーム接続の手順を示したシーケンスフローである。ここでは、３つの通信方式3G、Wi-Fi（登録商標）、WiMAX（登録商標）にそれぞれ対応する３つのインタフェースa1，a2，a3を備えたモバイル端末MNが、２つのグローバルIPアドレス(b1，b2)を割り当てられているサーバSとの間にSCTPによるマルチホーム接続を確立する手順を、モバイル端末MNのインタフェースa1のみが3Gネットワークに接続している状態から説明する。

【0038】

(1)モバイル端末MNは、サーバSとの間にアソシエーション１１を確立するため、時刻t1において、自身のルーティング設定に従ってインタフェースa1から3Gネットワーク経由でサーバSの1つのIPアドレス(ここでは、b1)宛にINITチャンクを送出する。このINITチャンクを受信したサーバSは、時刻t2において、自身に割り当てられている全てのIPアドレス(b1，b2)をINIT-ACKチャンクに記述して返信し、これにより最初の通信パス[a1-b1]が接続される。

【0039】

次いで、モバイル端末MNおよびサーバSは、時刻t3、t4において、前記通信パス[a1-b1]を利用して認証処理のためにCOOKIE-ECHO/COOKIE-ACKチャンクを送受信することでアソシエーション１１を確立する。各エンドホストは、通信パス[a1-b1]の状態(ACTIVE/INACTIVE)、チャンク再送間隔およびエラーカウンタ等の通信パラメータを、通信相手の宛先IPアドレスごとに管理する。

【0040】

その後、インタフェースa1からサーバSのIPアドレスb2に対してHEARTBEATが送信され、HEARTBEAT-ACKが返信されると、実際に疎通確認されていない他のインタフェースa2、a3を含む全てのインタフェースからサーバSのIPアドレスb2に対して疎通可能であると認識される。また、エラーカウンタや輻輳ウィンドウ等のパス単位で設定される通信パラメータに関しても、通信パス[a1-b2]による通信時の値が他の未接続の通信パス[a2-b2]、[a3-b2]に対して適用される。

【0041】

(2)次いで、モバイル端末MNが新たにWi-Fiネットワークのエリア内に入ってインタフェースa2の状態がDOWNからUP（有効）に変化し、IPアドレスが動的に付与されて、サーバSのIPアドレスb2に接続する通信パスを追加する場合を考える。

【0042】

モバイル端末MNでは、サーバSのIPアドレスb2に関して疎通性があると認識されているので、時刻t5において、通信パス[a2-b2]を追加するためのASCONF(Address Configuration)チャンクを、インタフェースa2からIPアドレスb2宛に送出する。しかしながら、接続されているWi-Fiネットワークはインタネットへの接続性がないため、前記ASCONFはサーバSに到着しない。モバイル端末MNは、送出したASCONFチャンクに対するサーバSからの返信(ASCONF-ACK)を一定時間内に受信できない場合、独自に計算した時間間隔(再送タイムアウト時間)でASCONFチャンクの再送を繰り返し、その後、再送回数(エラーカウンタ)が上限を超えると、時刻t6において、IPアドレスb2のステータスをSCTPの標準仕様に基づいて「INACTIVE」とする。

【0043】

その後、モバイル端末MNが前記Wi-Fiネットワークのエリア外へ移動し、時刻t7において、前記付与されていたIPアドレスが無効になると、前記IPアドレスb2のステータスが、従来のSCTP標準仕様であれば「INACTIVE」とされるところ、本実施形態では、前記第１拡張機能部１２により「ACTIVE(UNCONFIRMED)」とされる。

【0044】

SCTPの標準仕様では、「ACTIVE(UNCONFIRMED)」の元ではデータ送信のみならずASCONFチャンクの送信も明示的には許可されていない。これに対して、本実施形態ではIPアドレスが無効になると、そのステータスが「ACTIVE(UNCONFIRMED)」とされ、かつ前記「ACTIVE(UNCONFIRMED)」の元でASCONFチャンクをHERTBEATによる疎通確認を経ずに送出できるようにSCTPが拡張されている。

【0045】

(3)時刻t8では、SCTPの標準仕様に基づいて、インタフェースa2に係る通信パスの削除を要求するASCONF Deleteが、インタフェースa2からIPアドレスb2宛に送信される。時刻t9では、IPアドレスb2からインタフェースa2へ、前記削除要求に対する応答としてASCONF ACKが返信される。

【0046】

(4)その後、時刻t10において、モバイル端末MNがインタフェースa2またはa3のネットワークエリア内へ移動し、例えばインタフェースa2からサーバSのIPアドレスb2への通信パスの追加が要求されると、当該時点ではIPアドレスb2のステータスが「ACTIVE(UNCONFIRMED)」なので、HEARTBEATによる疎通確認を待たずに、時刻t11において直ちに、モバイル端末MNのインタフェースa2からサーバSのIPアドレスb2を宛先としてASCONF Addを送信できる。時刻t12において、サーバSのIPアドレスb2からモバイル端末MNのインタフェースa2へASCONF ACKが返信されると、モバイル端末MNとサーバSとの間に通信パス[a2-b2]が接続される。

【0047】

時刻t13では、モバイル端末MNのインタフェースa2からサーバSのIPアドレスb2を宛先としてHERTBEATが送出される。時刻t14では、サーバSのIPアドレスb2からモバイル端末MNのインタフェースa2へHERTBEAT-ACKが返信され、これ以降、HERTBEAT/HERTBEAT-ACKの送受が所定の周期で繰り返される。

【0048】

本実施形態によれば、通信パスの接続に失敗したIPアドレスのステータスが、SCTPの標準仕様で定められた「INACTIVE」ではなく、「ACTIVE(UNCONFIRMED)」となるようにSCTPが拡張されるので、次に当該IPアドレスに対する通信パスの接続を試行する際に、HERTBEATによる疎通確認を待たずに直ちにASFONFを送出することが可能になり、素早いマルチパス通信が可能になる。

【0049】

図５は、本発明に係るSCTP通信システムの第２実施形態の構成を示したブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。

【0050】

本実施形態では、モバイル端末MNのトランスポート層(SCTP)に第２拡張部１３を設け、マルチホーム接続のために追加された通信パスのパラメータを、先に接続されている通信パスのパラメータから独立させることで、追加された通信パスに対して、異なるネットワーク環境下で先に接続済みの通信パスのパラメータが適用されないようにSCTPを拡張した点に特徴がある。

【0051】

図６は、本発明の第２実施形態の動作を示したシーケンスフローであり、時刻t11までの手順は上記の第１実施形態と同一または同等なので、その説明は省略する。

【0052】

SCTPの標準仕様では、通信パスが新たに追加されると、その通信パラメータとして、先に接続されて宛先IPアドレス（ここでは、b2）が同一の他の通信パス（前記a1-b2）のパラメータが、通信環境や条件の相違にかかわらず引き継がれてしまう。これに対して、本実施形態では、時刻t11，t12においてサーバSとモバイル端末MNとの間でASCONF AddおよびASCONF ACKが送受されて通信パスが追加される際、サーバSではASCONF ACKの返信タイミング(t11)において、またモバイル端末MNでは前記ASCONF ACKの受信タイミング(t12)において、前記宛先IPアドレスb2に関する通信パラメータが初期化される。

【0053】

このように、本実施形態では宛先IPアドレスが同一の通信パスが改めて追加されると、そのパラメータが初期化されるようにSCTPが拡張され、追加された通信パスに既設の通信パスのパラメータが引き継がれない。したがって、通信環境や条件の異なる他の通信パラメータが、追加された新たな通信パスに引き継がれてしまうことによる通信効率の低下を防止できる。

【符号の説明】

【0054】

１０…通信パス，１１…アソシエーション，１２…第１拡張部，１３…第２拡張部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】