JP5918076B2 - マルチホーム通信方法およびシステム - Google Patents

マルチホーム通信方法およびシステム Download PDF

Info

Publication number
JP5918076B2
JP5918076B2 JP2012183230A JP2012183230A JP5918076B2 JP 5918076 B2 JP5918076 B2 JP 5918076B2 JP 2012183230 A JP2012183230 A JP 2012183230A JP 2012183230 A JP2012183230 A JP 2012183230A JP 5918076 B2 JP5918076 B2 JP 5918076B2
Authority
JP
Japan
Prior art keywords
communication
address
sctp
communication path
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2012183230A
Other languages
English (en)
Other versions
JP2014042143A (ja
Inventor
篤男 立花
篤男 立花
長谷川 輝之
輝之 長谷川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KDDI Corp
Original Assignee
KDDI Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by KDDI Corp filed Critical KDDI Corp
Priority to JP2012183230A priority Critical patent/JP5918076B2/ja
Publication of JP2014042143A publication Critical patent/JP2014042143A/ja
Application granted granted Critical
Publication of JP5918076B2 publication Critical patent/JP5918076B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Description

本発明は、モバイル端末のマルチホーム通信方法およびシステムに係り、特に、通信パスを短時間で追加することにより迅速なマルチホーム通信を可能にするSCTPのマルチホーム通信方法およびシステムに関する。
現在、3G、Wi-Fi、WiMAX、LTE等の複数の無線ネットワークに対応したAndroid OS搭載のモバイル端末MN(スマートフォン)が普及している。一般的なAndroid端末は、複数の無線ネットワークに同時接続することは行わず、一つの無線ネットワークのみに接続するため、接続中の無線ネットワークに障害や品質劣化が発生すると通信品質の劣化や通信セッションの切断が発生する。このような技術課題に対して、非特許文献1,2では、無線ネットワークの品質や周囲の電波強度・混雑度を測定し、接続するネットワークを選択する(切り替える)技術が研究・議論されているが、通信パスの切り替え基準や切り替え時間が問題となる。
一方、トランスポートレイヤで通信パスを切替える技術として、エンドホスト間で複数の通信パスを用いたコネクションを確立し(マルチホーム)、1つの通信パス上で障害が発生した場合は、残りの通信パスにトラヒックを切り替えることで高信頼な通信を実現するSCTP(Stream Control Transmission Protocol:ストリーム制御伝送プロトコル)が研究開発され、非特許文献3,4に開始されている。
非特許文献3,4に開示されている標準のSCTPでは、マルチホーム接続を確立した場合であっても、実際にデータ転送に用いるのは、1本の"プライマリパス"と呼ばれる通信パスのみであるため、障害や品質劣化の発生時においては、従来技術と同様に、他の通信パスの切り替え基準や切り替え時間が問題となる。
一方、非特許文献6には、複数の通信パスで同時にデータ転送を行うことにより、通信(スループット)を高速化する手法(Concurrent Multi-path Transfer(CMT) SCTP)が提案されており、この手法は通信を高信頼化させる効果もある。また、非特許文献7には、CMT-SCTPを利用して、NAT環境においても通信パスの追加・削除を実現可能とする手法が提案されている。
標準のSCTPは、FreeBSDやWindows(登録商標)等の多くのOS上に試験的に実装され、非特許文献5では、Android(Linux(登録商標))上で動作するライブラリも開発されている。しかしながら、現在のインタネットにおける通信の大半はTCP/UDPをベースとしており、SCTPを用いた一般ユーザ向けのモバイル通信サービスは展開されていない。このため、SCTP通信をエンドツーエンドで実現するためには、既存のサーバやコンピュータプログラムをSCTP通信に対応させる必要がある。
福山他、"IPv4 移動体通信において携帯電話網と無線LAN 間をシームレスに移動する方式の提案," マルチメディア、分散協調とモバイルシンポジウム 2011 論文集,pp.1115-1120, 2011. Access Network Discovery and Selection Function (ANDSF) RFC 3286 - An Introduction to the Stream Control Transmission Protocol RFC 2960 - Stream Control Transmission Protocol SCTP library (sctplib) [URL]: http://www.sctp.de/sctp-download.html 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. RFC5061-Streaming Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
SCTPでは、エンドホスト間に1本の通信パス(プライマリパス)を接続し、これを利用してアソシエーション(ホスト間コネクション)を確立した後、別の通信パスを追加することでマルチホーム接続を実現できる。例えば、3Gネットワークを介してサーバSと通信を行なっているモバイル端末MNが、Wi-Fi等の異種の無線ネットワークのエリア内に移動した際、前記3Gネットワーク経由の通信パスを維持したまま、Wi-Fiネットワーク経由の通信パスを新たに追加することが可能である。しかしながら、従来のSCTPでは以下に詳述するように、所定の条件下で通信パスを迅速に追加できない問題が生じ得る。
ここでは、図7のシーケンスフローを参照しながら、3つの通信方式3G、Wi-Fi(登録商標)、WiMAX(登録商標)にそれぞれ対応する3つのインタフェースa1,a2,a3を備えたモバイル端末MNが、SCTPを利用して、2つのグローバルIPアドレス(b1,b2)を割り当てられているサーバSとの間にマルチホーム接続を確立する場合を例にして、従来のSCTPの問題点を説明する。
(1)モバイル端末MNは、そのインタフェースa1のみが3Gネットワークに接続している状態において、サーバSとの間にアソシエーションを確立するため、時刻t1において、自身のルーティング設定に従い、インタフェースa1から3Gネットワーク経由でサーバSの1つのIPアドレス(ここでは、b1)宛にINITチャンクを送出する。
このINITチャンクを受信したサーバSは、SCTPの標準仕様に従い、時刻t2において、自身に割り当てられている全てのIPアドレス(b1,b2)をINIT-ACKチャンクに記述して返信し、これにより最初の通信パス(プライマリパス)[a1-b1]が接続される。その後、モバイル端末MNおよびサーバSは、時刻t3、t4において、前記通信パス[a1-b1]を利用して認証処理のためにCOOKIE-ECHO/COOKIE-ACKチャンクを送受信することでアソシエーションを確立する。
このとき、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]に適用される。
(2)次いで、モバイル端末MNが、実際にはインタネットへの接続性がないWi-Fiネットワークエリア内に入り、インタフェースa2が有効になった状況、すなわちモバイル端末MNのインタフェースa2の状態がDOWNからUPに変化し、IPアドレスが動的に付与された状況を考える。
モバイル端末MNは、IPアドレスb2に関してサーバSへの疎通性があると認識しているため、自身のインタフェースa2とサーバSのIPアドレスb2との間に通信パスを追加するためのASCONF(Address Configuration)チャンクを、時刻t7において、当該インタフェースa2からIPアドレスb2宛に送出する。しかしながら、接続されているWi-Fiネットワークはインタネットへの接続性がないため、前記ASCONFはサーバSに到着しない。
モバイル端末MNは、送出したASCONFチャンクに対するサーバSからの返信(ASCONF-ACK)を一定時間内に受信できない場合、独自に計算した時間間隔(再送タイムアウト時間)でASCONFチャンクの再送を繰り返し、その後、再送回数(エラーカウンタ)が上限を超えると、時刻t8において、IPアドレスb2のステータスを「INACTIVE(到達不能)」と判断する。
その後、モバイル端末MNは時刻t9において、前記プライマリパス[a1-b1]を介して、アドレス追加のためのASCONFチャンクを送出するが、サーバSでは、既登録のインタフェースa1からのASCONFチャンクと認識されるので当該ASCONFの受信は無視される。これは、プライマリパス経由の送信処理は、サーバSが受信するASCONFチャンクのシーケンス番号の連続性を保つための処理であり、アドレス追加に関する効果がない(SCTPでは、ASCONFのシーケンス番号の連続性が考慮される)ことによる。
その後、モバイル端末MNは、「INACTIVE」とされたIPアドレスb2への疎通確認を行うため、独自に計算した時間間隔(通常は数10秒間隔)で、インタフェースa1またはa2からIPアドレスb2宛にHEARTBEATの送信を繰り返す。この際、インタフェースa1,a2のいずれがHEARTBEATの送出元となるかはSCTPの実装に依存する。
(3)HEARTBEATがモバイル端末MNのインタフェースa1から送信される場合、HEARTBEATの疎通に成功するので、モバイル端末MNは、再度、IPアドレスb2へのパスを「ACTIVE」と判定し、インタフェースa2からIPアドレスb2に対してASCONFチャンクを送出するが、実際にはa2-b2を介した疎通には成功しない。この結果、インタフェースa1からb2に対するHEARTBEATの疎通成功とインタフェースa2からb2に対するASCONFチャンクの疎通失敗とが繰り返されることになる。
一方、HEARTBEATがインタフェースa2から送信される場合、HEARTBEATの疎通に成功しないので、HEARTBEATの再送が繰り返されることになる。ここで、いずれの場合であっても、モバイル端末MNからIPアドレスb2への疎通(状態)確認は、HEARTBEATの送出間隔(通常は最大で数10秒間隔)に基づいて実行されることになる。
(4)その後、モバイル端末MNがインタネットに接続可能なWi-Fiネットワークのエリア内に入り、インタフェースa3が有効になってIPアドレスを付与された状況、あるいはインタフェースa2がインタネットに接続可能な別のWi-Fiネットワークに接続された状況を考える。
ここで、モバイル端末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との通信が可能になったとしても、即座に通信パスを追加できない。
また、HEARTBEATがインタフェースa1から送出されている場合、IPアドレスb2への通信パスが追加された後においても、a1-b2間の通信パラメータ(チャンク再送間隔やエラーカウンタ等)が、宛先IPアドレスが同じb2であるものの通信品質の異なる他の通信パスのパラメータとして利用されてしまうため、SCTPにおける通信パスの状態の管理や制御が非効率なものとなる問題が発生する。
本発明の第1の目的は、モバイル端末のネットワーク環境が、サーバ側との疎通が不能な状態から可能な状態に遷移すると、HERTBEATによる疎通確認を待たずに、通信パスの追加要求(ASCCONF Add)を直ちに送出できるようにすることで、素早いマルチホーム接続を可能にすることにある。
本発明の第2の目的は、マルチホーム接続のために追加された通信パスの通信パラメータを、先に接続されている通信パスの通信パラメータから独立させることで、追加された通信パスに対して、異なるネットワーク環境下で先に接続済みの通信パラメータが適用されないようにすることにある。
上記の目的を達成するために、本発明は、複数のインタフェースを備えた一方のノードと複数のIPアドレスを割り当てられた他方のノードとの間にSCTPにより無線ネットワーク経由のマルチホーム接続を確立するマルチホーム通信方法において、以下のような手段を講じた点に特徴がある。
(1)一方のノードにおいて、第1インタフェースが他方のノードの第1アドレス宛に初期化要求を送信し、これに他方のノードが応答して第1通信パスを接続することによりアソシエーションを確立する手順と、一方のノードにおいて、第2インタフェースが接続されたネットワークのエリア内から、他方のノードの第2アドレス宛に通信パスの追加を要求する手順と、一方のノードにおいて、前記第2アドレスへの通信パスの追加に成功することなく前記ネットワークとの接続が断たれると、当該第2アドレスのステータスをACTIVE(UNCONFIRMED)とする手順と、一方のノードにおいて、前記ステータスがACTIVE(UNCONFIRMED)の第2アドレス宛に、疎通確認を経ずに追加要求を送信して通信パスを追加する手順とを設けた。
(2)前記第2アドレスへの通信パスの追加に成功すると、前記一方および他方のノードにおいて、当該第2アドレスに関する通信パラメータを初期化する手順を更に設けた。
本発明によれば、以下のような効果が達成される。
(1)SCTPの標準仕様では、プライマリパスの接続によりアソシエーションの確立されたモバイル端末/サーバ間にモバイル端末側から通信パス(セカンダリパス)を追加する際、疎通が確認されていないためにステータスが「INACTIVE」のIPアドレスに対しては、モバイル端末がIPアドレスへの疎通可能なネットワーク環境へ移動したとしても、通信パスの追加要求(ASCONF)を直ぐには送出できず、周期的なHERTBEATにより前記IPアドレスへの疎通が確認され、当該IPアドレスのステータスが「ACTIVE」に切り替わった後でなければASCONFを送出できない。
これに対して、本発明では疎通に失敗したIPアドレスのステータスが、SCTPの標準仕様で定められた「INACTIVE」ではなく「ACTIVE(UNCONFIRMED)」とされ、かつ当該「ACTIVE(UNCONFIRMED)」においてASCONFを送出できるようにようにSCTPが拡張される。したがって、当該IPアドレスに対する通信パスの接続を試行する際には、HERTBEATによる疎通確認を待たずに直ちにASCONFを送出することが可能になり、素早いマルチパス通信が可能になる。
(2)SCTPの標準仕様では、ある宛先IPアドレスとの通信パスに設定された通信パラメータが、その後、同じ宛先IPアドレスとの間に異なるネットワーク経由で接続された通信パスに引き継がれてしまうのに対して、本発明では、以前と同じ宛先IPアドレスとの間に通信パスを接続する際には、その通信パラメータが初期化されるようにSCTPが拡張される。したがって、通信環境や条件の異なる通信パラメータが、宛先IPアドレスが同一であるという理由で無条件に他の通信パスにも設定されてしまうことによる通信効率の低下を防止できる。
本発明に係るSCTP通信システムの第1実施形態のブロック図である。 本発明が適用されるネットワーク構成の一例を示した図である。 本発明が適用されるネットワーク構成の他の一例を示した図である。 本発明の第1実施形態に係るマルチホーム接続の手順を示したシーケンスフローである。 本発明に係るSCTP通信システムの第2実施形態のブロック図である。 本発明の第2実施形態に係るマルチホーム接続の手順を示したシーケンスフローである。 従来のマルチホーム接続の手順を示したシーケンスフローである。
以下、図面を参照して本発明の実施の形態について詳細に説明する。本発明は、図2に示したように、専用ソフトウェアをインストール可能なサーバ・コンピュータプログラムとモバイル端末MNとの間でSCTPをベースとしたマルチホーム通信を行うシステムにおいて、通信を高信頼化する手順に関するものである(図中のSCTPベース通信ソフトにおける処理手順)。
また、図3に一例を示したように、IPネットワーク内にプロトコル変換サーバを設置し、SCTP通信とTCP通信とを変換することにより、既存のサーバ・コンピュータを変更することなく、SCTPをベースとしたマルチホーム通信システムを実現する手法も考えられる。本発明は、このようなプロトコル変換サーバを介して既存のサーバ・コンピュータと通信を行うシステムにも適用できる。
図1は、本発明に係るSCTP通信システムの第1実施形態の構成を示したブロック図であり、本発明の説明に不要な構成は図示が省略されている。ここでは、モバイル端末MNからサーバSへのマルチホーム接続を例にして説明する。
モバイル端末MNおよびサーバSの各ネットワークノードには、インタフェース層、ネットワーク層、トランスポート層およびアプリケーション層から構成されるIPスタックが実装され、トランスポート層のプロトコルとしてSCTPが採用されている。モバイル端末MNおよびサーバSの各SCTPは、一つのアソシエーション11で複数の通信パス10を接続するマルチホーム接続用の標準機能に加えて、本発明に固有の拡張機能を備え、これにより通信パス10の迅速な追加によるマルチホーム通信を可能にしている。
モバイル端末MNのトランスポート層(SCTP)において、第1拡張部12は、モバイル端末MNのネットワーク環境が、サーバSに割り当てられているIPアドレスとの疎通が不能な状態から可能な状態に遷移した際に、HERTBEATによる疎通確認を待たずに、通信パスの追加要求(ASCCONF Add)を直ちに送出できるようにSCTPを拡張する。
図4は、上記の拡張機能を備えたモバイル端末MN/サーバS間でのマルチホーム接続の手順を示したシーケンスフローである。ここでは、3つの通信方式3G、Wi-Fi(登録商標)、WiMAX(登録商標)にそれぞれ対応する3つのインタフェースa1,a2,a3を備えたモバイル端末MNが、2つのグローバルIPアドレス(b1,b2)を割り当てられているサーバSとの間にSCTPによるマルチホーム接続を確立する手順を、モバイル端末MNのインタフェースa1のみが3Gネットワークに接続している状態から説明する。
(1)モバイル端末MNは、サーバSとの間にアソシエーション11を確立するため、時刻t1において、自身のルーティング設定に従ってインタフェースa1から3Gネットワーク経由でサーバSの1つのIPアドレス(ここでは、b1)宛にINITチャンクを送出する。このINITチャンクを受信したサーバSは、時刻t2において、自身に割り当てられている全てのIPアドレス(b1,b2)をINIT-ACKチャンクに記述して返信し、これにより最初の通信パス[a1-b1]が接続される。
次いで、モバイル端末MNおよびサーバSは、時刻t3、t4において、前記通信パス[a1-b1]を利用して認証処理のためにCOOKIE-ECHO/COOKIE-ACKチャンクを送受信することでアソシエーション11を確立する。各エンドホストは、通信パス[a1-b1]の状態(ACTIVE/INACTIVE)、チャンク再送間隔およびエラーカウンタ等の通信パラメータを、通信相手の宛先IPアドレスごとに管理する。
その後、インタフェースa1からサーバSのIPアドレスb2に対してHEARTBEATが送信され、HEARTBEAT-ACKが返信されると、実際に疎通確認されていない他のインタフェースa2、a3を含む全てのインタフェースからサーバSのIPアドレスb2に対して疎通可能であると認識される。また、エラーカウンタや輻輳ウィンドウ等のパス単位で設定される通信パラメータに関しても、通信パス[a1-b2]による通信時の値が他の未接続の通信パス[a2-b2]、[a3-b2]に対して適用される。
(2)次いで、モバイル端末MNが新たにWi-Fiネットワークのエリア内に入ってインタフェースa2の状態がDOWNからUP(有効)に変化し、IPアドレスが動的に付与されて、サーバSのIPアドレスb2に接続する通信パスを追加する場合を考える。
モバイル端末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」とする。
その後、モバイル端末MNが前記Wi-Fiネットワークのエリア外へ移動し、時刻t7において、前記付与されていたIPアドレスが無効になると、前記IPアドレスb2のステータスが、従来のSCTP標準仕様であれば「INACTIVE」とされるところ、本実施形態では、前記第1拡張機能部12により「ACTIVE(UNCONFIRMED)」とされる。
SCTPの標準仕様では、「ACTIVE(UNCONFIRMED)」の元ではデータ送信のみならずASCONFチャンクの送信も明示的には許可されていない。これに対して、本実施形態ではIPアドレスが無効になると、そのステータスが「ACTIVE(UNCONFIRMED)」とされ、かつ前記「ACTIVE(UNCONFIRMED)」の元でASCONFチャンクをHERTBEATによる疎通確認を経ずに送出できるようにSCTPが拡張されている。
(3)時刻t8では、SCTPの標準仕様に基づいて、インタフェースa2に係る通信パスの削除を要求するASCONF Deleteが、インタフェースa2からIPアドレスb2宛に送信される。時刻t9では、IPアドレスb2からインタフェースa2へ、前記削除要求に対する応答としてASCONF ACKが返信される。
(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]が接続される。
時刻t13では、モバイル端末MNのインタフェースa2からサーバSのIPアドレスb2を宛先としてHERTBEATが送出される。時刻t14では、サーバSのIPアドレスb2からモバイル端末MNのインタフェースa2へHERTBEAT-ACKが返信され、これ以降、HERTBEAT/HERTBEAT-ACKの送受が所定の周期で繰り返される。
本実施形態によれば、通信パスの接続に失敗したIPアドレスのステータスが、SCTPの標準仕様で定められた「INACTIVE」ではなく、「ACTIVE(UNCONFIRMED)」となるようにSCTPが拡張されるので、次に当該IPアドレスに対する通信パスの接続を試行する際に、HERTBEATによる疎通確認を待たずに直ちにASFONFを送出することが可能になり、素早いマルチパス通信が可能になる。
図5は、本発明に係るSCTP通信システムの第2実施形態の構成を示したブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
本実施形態では、モバイル端末MNのトランスポート層(SCTP)に第2拡張部13を設け、マルチホーム接続のために追加された通信パスのパラメータを、先に接続されている通信パスのパラメータから独立させることで、追加された通信パスに対して、異なるネットワーク環境下で先に接続済みの通信パスのパラメータが適用されないようにSCTPを拡張した点に特徴がある。
図6は、本発明の第2実施形態の動作を示したシーケンスフローであり、時刻t11までの手順は上記の第1実施形態と同一または同等なので、その説明は省略する。
SCTPの標準仕様では、通信パスが新たに追加されると、その通信パラメータとして、先に接続されて宛先IPアドレス(ここでは、b2)が同一の他の通信パス(前記a1-b2)のパラメータが、通信環境や条件の相違にかかわらず引き継がれてしまう。これに対して、本実施形態では、時刻t11,t12においてサーバSとモバイル端末MNとの間でASCONF AddおよびASCONF ACKが送受されて通信パスが追加される際、サーバSではASCONF ACKの返信タイミング(t11)において、またモバイル端末MNでは前記ASCONF ACKの受信タイミング(t12)において、前記宛先IPアドレスb2に関する通信パラメータが初期化される。
このように、本実施形態では宛先IPアドレスが同一の通信パスが改めて追加されると、そのパラメータが初期化されるようにSCTPが拡張され、追加された通信パスに既設の通信パスのパラメータが引き継がれない。したがって、通信環境や条件の異なる他の通信パラメータが、追加された新たな通信パスに引き継がれてしまうことによる通信効率の低下を防止できる。
10…通信パス,11…アソシエーション,12…第1拡張部,13…第2拡張部

Claims (4)

  1. 複数のインタフェースを備えた一方のノードと複数のIPアドレスを割り当てられた他方のノードとの間にSCTPにより無線ネットワーク経由のマルチホーム接続を確立するマルチホーム通信方法において、
    一方のノードにおいて、第1インタフェースが他方のノードの第1アドレス宛に初期化要求を送信し、これに他方のノードが応答して第1通信パスを接続することによりアソシエーションを確立する手順と、
    一方のノードにおいて、第2インタフェースが接続されたネットワークのエリア内から、当該第2インタフェースが他方のノードの第2アドレス宛に通信パスの追加を要求する手順と、
    一方のノードにおいて、前記第2アドレスへの通信パスの追加に成功することなく前記ネットワークとの接続が断たれると、当該第2アドレスのステータスをACTIVE(UNCONFIRMED)とする手順と、
    一方のノードにおいて、前記ステータスがACTIVE(UNCONFIRMED)の第2アドレス宛に、疎通確認を経ずに追加要求を送信して通信パスを追加する手順とを含むことを特徴とするSCTPのマルチホーム通信方法。
  2. 前記第2アドレスへの通信パスの追加に成功すると、前記一方および他方のノードにおいて、当該第2アドレスに関する通信パラメータを初期化する手順を更に含むことを特徴とする請求項1に記載のSCTPのマルチホーム通信方法。
  3. 複数のインタフェースを備え、複数のIPアドレスを割り当てられた接続先ノードとの間にSCTPにより無線ネットワーク経由のマルチホーム接続を確立するマルチホーム通信システムにおいて、
    第1インタフェースから接続先ノードの第1アドレス宛に初期化要求を送信して第1通信パスを接続し、接続先ノードとの間にアソシエーションを確立する手段と、
    第2インタフェースが接続されたネットワークのエリア内から、当該第2インタフェースが接続先ノードの第2アドレス宛に通信パスの追加を要求する手段と、
    前記第2アドレスへの通信パスの追加に成功することなく前記ネットワークとの接続が断たれると、当該第2アドレスのステータスをACTIVE(UNCONFIRMED)とする手段と、
    前記ステータスがACTIVE(UNCONFIRMED)の第2アドレス宛に、疎通確認を経ずに追加要求を送信して通信パスを追加する手段とを具備したことを特徴とするSCTPのマルチホーム通信システム。
  4. 前記第2アドレスへの通信パスの追加に成功すると、当該第2アドレスに関する通信パラメータを初期化する手段を更に具備したことを特徴とする請求項3に記載のSCTPのマルチホーム通信システム。
JP2012183230A 2012-08-22 2012-08-22 マルチホーム通信方法およびシステム Expired - Fee Related JP5918076B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012183230A JP5918076B2 (ja) 2012-08-22 2012-08-22 マルチホーム通信方法およびシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012183230A JP5918076B2 (ja) 2012-08-22 2012-08-22 マルチホーム通信方法およびシステム

Publications (2)

Publication Number Publication Date
JP2014042143A JP2014042143A (ja) 2014-03-06
JP5918076B2 true JP5918076B2 (ja) 2016-05-18

Family

ID=50394074

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012183230A Expired - Fee Related JP5918076B2 (ja) 2012-08-22 2012-08-22 マルチホーム通信方法およびシステム

Country Status (1)

Country Link
JP (1) JP5918076B2 (ja)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6850503B2 (en) * 2002-08-06 2005-02-01 Motorola, Inc. Method and apparatus for effecting a handoff between two IP connections for time critical communications
JP4153502B2 (ja) * 2005-03-29 2008-09-24 富士通株式会社 通信装置及び論理リンク異常検出方法

Also Published As

Publication number Publication date
JP2014042143A (ja) 2014-03-06

Similar Documents

Publication Publication Date Title
CN109981316B (zh) 应用服务器的切换方法及会话管理网元、终端设备
KR102156687B1 (ko) 다중 경로 연결을 확립하기 위한 방법 및 멀티 홈 장비
JP4998316B2 (ja) 通信システム及び通信処理方法並びにノード
US20160380966A1 (en) Media Relay Server
US20150237525A1 (en) Traffic Shaping and Steering for a Multipath Transmission Control Protocol Connection
WO2020068605A1 (en) Systems and methods for selection of collocated nodes in 5g network
WO2016210202A1 (en) Media relay server
WO2012000271A1 (zh) 终端接入方法和无线通信网络
WO2021008591A1 (zh) 数据传输方法、装置及***
US8180361B2 (en) Methods and systems for base station installation in distributed call processing networks
JP2018526923A (ja) 通信ネットワークのための強化近隣発見
WO2022067818A1 (zh) 一种数据传输方法及装置
CN111107672A (zh) 一种建立多路径连接的子流的方法、装置和***
JP5502947B2 (ja) 動的ホスト構成プロトコル(dhcp)リリースメッセージの照合のための方法と装置
EP3632081B1 (en) Session layer communications using an id-oriented network
WO2023071522A1 (zh) 建立连接的方法、装置、存储介质及电子装置
JP5840575B2 (ja) マルチホーム通信方法およびシステム
WO2013178164A1 (zh) IPv6域名服务器DNS地址分配、获取方法及装置
US20110138073A1 (en) Connection destination selection apparatus and method thereof
JP5918076B2 (ja) マルチホーム通信方法およびシステム
US20200137726A1 (en) Communications device and communication method
TWI495314B (zh) 多廣域網路介面設備及其更新路由表的方法
WO2015013883A1 (zh) 一种数据传输方法及设备
CN106375224B (zh) 路由器及利用该路由器进行网络连接的方法
US20170311135A1 (en) Control Signaling Transmission Method in MCPTT Architecture and Related Device

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150121

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20151216

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20151216

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160210

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160316

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160407

R150 Certificate of patent or registration of utility model

Ref document number: 5918076

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees