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

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

Info

Publication number
JP5840575B2
JP5840575B2 JP2012160447A JP2012160447A JP5840575B2 JP 5840575 B2 JP5840575 B2 JP 5840575B2 JP 2012160447 A JP2012160447 A JP 2012160447A JP 2012160447 A JP2012160447 A JP 2012160447A JP 5840575 B2 JP5840575 B2 JP 5840575B2
Authority
JP
Japan
Prior art keywords
node
address
request
interface
communication
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
JP2012160447A
Other languages
English (en)
Other versions
JP2014022969A (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 JP2012160447A priority Critical patent/JP5840575B2/ja
Publication of JP2014022969A publication Critical patent/JP2014022969A/ja
Application granted granted Critical
Publication of JP5840575B2 publication Critical patent/JP5840575B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

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

Description

本発明は、マルチホーム通信方式およびシステムに係り、特に、SCTPにより通信パスの迅速な追加を実現するマルチホーム通信方式およびシステムに関する。
現在、3G、Wi-Fi(登録商標)、WiMAX(登録商標)あるいはLTE(登録商標)等の複数の無線ネットワークに対応したAndroid OS搭載のモバイル端末(スマートフォン)が普及している。一般的なAndroid端末は、複数の無線ネットワークに同時接続することは行わず、一つの無線ネットワークのみに接続するため、接続中の無線ネットワークに障害や品質劣化が発生すると通信品質の劣化や通信セッションの切断が発生する。このような技術課題に対して、非特許文献1,2では、無線ネットワークの品質や周囲の電波強度・混雑度を測定し、接続するネットワークを選択する(切替える)技術が研究・議論されているが、通信パスの切り替え基準や切り替え時間が問題となる。
一方、トランスポート層で通信パスを切替える技術として、エンドホスト間で複数の通信パスを用いたコネクション(マルチホーム)を確立し、1つの通信パス上で障害が発生した場合は、残りの通信パスにトラヒックを切り替えることで高信頼な通信を実現するSCTP(Stream Control Transmission Protocol)が注目されている。
しかしながら、非特許文献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では、エンドホスト間に複数の通信パスを用いてアソシエーション(TCPのコネクションに相当する)を確立するマルチホーム接続が可能である。ただし、標準のSCTPは各エンドホストにグローバルなIPアドレス(IPv4アドレスまたはIPv6アドレス)が付与される状況を想定して設計されており、必ずしも、現在のインターネットにおいて広く普及しているNAT(Network address translation)装置を介した通信に適した設計になっていない。このため、エンドホスト間にアソシエーションが確立された後で、NAT装置を介した通信パスを追加しようとすると、以下のような技術課題が生じる。
ここでは、ネットワークにNAT装置を介して接続するモバイル端末MNがサーバSにマルチホーム接続する際の手順を、図5のシーケンスフローを参照して、モバイル端末MNが2つのインタフェースIF(a1,a2)を備え、サーバSが2つのインタフェースIF(b1,b2)を備える場合を例にして説明する。
(1)時刻t1では、モバイル端末MNがサーバSとの間にアソシエーション呼ばれる論理的な接続(SCTPコネクション)を確立するために、一方のインタフェースIF(a1)からサーバSの一方のIF(b1)へINITチャンクを送出し、モバイル端末MNの一方のインタフェースIF(a1)の割り当てられているグローバルIPアドレスGA(1st)がサーバSへ通知される。ここで、IF(a1),IF(b1)間の通信がNAT装置を介して行われると、モバイル端末MNは自身のグローバルIPアドレスを知らないため、送出するINITチャンクに自身のグローバルIPアドレスGA(1st)を付与できない。ただし、サーバSは受信パケットのIPヘッダ等を参照することにより、モバイル端末MNの一方のインタフェースIF(a1)に割り当てられているグローバルIPアドレスGA(1st)を認識できる。
(2)時刻t2では、サーバSの一方のインタフェースIF(b1)からモバイル端末MNの一方のインタフェースIF(a1)へINIT-ACKチャンクが返信され、サーバSの各インタフェースIF(b1),IF(b2)に割り当てられているグローバルIPアドレスGA(b1),GB(b2)がモバイル端末MNへ通知される。さらに、時刻t3,t4ではIF(a1)-IF(b1)間で認証処理のためのCOOKIE-ECHOおよびCOOKIE-ACKの各チャンクが送受される。これにより、IF(a1)-IF(b1)間に第1通信パス(プライマリパス)が接続されてアソシエーションの確立が完了する。
(3)次いで、IF(a2)-IF(b2)間に通信パスを新たに追加する場合を考える。SCTPでは、通信パスの追加手順として、当該通信パス[IF(a2)-IF(b2)]に対してHEARTBEAT/HEARTBEAT-ACKチャンクの送受信による疎通性の確認が行われ、通信パスがACTIVE(かつCONFIRMED)状態にあることが判別された後、ASCONF(Address Configuration Change)チャンクにより通信パスの追加・削除が行われる。このため、モバイル端末MNは時刻t5以降、IF(a2)からサーバSのIF(b2)宛にHEARTBEATを周期的に送出する(ここで、SCTPの実装によっては、モバイル端末MNはサーバSに対してIF(a1)からHEARTBEATを送出してしまい、厳密には通信パス[IF(a2)-IF(b2)]の疎通性を確認しない場合もあるが、ここでは、モバイル端末MNがHEARTBEATの送出元を指定できるものと想定する)。
(4)サーバSは、モバイル端末MNのIF(a2)から送出されたHEARTBEATを受信すると、その送出元IPアドレスGA(2nd)をIPヘッダ等より抽出し、サーバS上で管理しているグローバルIPアドレスとアソシエーションとの対応リストを参照する。しかしながら、当該グローバルIPアドレスGA(2nd)は対応リストに存在しないので当該HEARTBEATは廃棄され、時刻t6において、その送出元のグローバルIPアドレスGA(2nd)に対して、アソシエーションの切断を通知するためのABORTチャンクが送出されてしまう。
(5)前記ABORTチャンクを受信したモバイル端末MNでは、先に接続したコネクション[IF(a1)-IF(b1)]を含めて、サーバSとのアソシエーションを切断する。
このように、標準のSCTPでは、HEARTBEATの送信元IPアドレス(グローバル)がアソシエーションと予め対応付けられていないと、当該HEARTBEATが廃棄されてしまい、通信パスを追加できないのみならず、その送出元に対して、アソシエーションの切断を通知するためのABORTチャンクが送出されてアソシエーションが切断されてしまうという技術課題があった。
本発明の目的は、上記した従来技術の課題を解決し、モバイル端末MNがNAT装置を介してネットワークに接続するために自身のグローバルIPアドレスをサーバSにおいてアソシエーションと対応付けられない場合でも、サーバSとの間に簡単にマルチホーム接続を確立できるマルチホーム通信方式およびシステムを提供することにある。
上記の目的を達成するために、本発明は、ネットワークにNAT装置を介して接続された一方のノードが他方のノードとの間にマルチホーム接続によるSCTPアソシエーションを確立するマルチホーム通信方法において、以下のような手順を含む点に特徴がある。
(1)一方のノードの第1インタフェースから他方のノードの第1インタフェースへ初期化要求を送信し、これに他方のノードが応答することで第1通信パスを接続してアソシエーションを確立する手順と、他方のノードが、前記初期化要求の検証タグ、送信元IPアドレスおよび送信元SCTPポート番号を対応付けて登録する手順と、一方のノードの第2インタフェースから他方のノードの第2インタフェースへ疎通確認要求を周期的に送信する手順と、他方のノードにおいて、前記疎通確認要求の検証タグおよび送信元SCTPポート番号の対応付けが自身に既登録であれば、当該疎通確認要求の送信元IPアドレスとは無関係に疎通成功の応答を返信する手順とを含む。
(2)他方のノードが、前記疎通確認要求の検証タグおよび送信元IPアドレスの組合せが自身に未登録であると、第2インタフェースから一方のノードの第2インタフェースへ当該IPアドレスの登録要請を返信する手順と、一方のノードが、前記登録要請に応答して、第2インタフェースから他方のノードの第2インタフェースへ前記IPアドレスの追加要求を送信する手順と、他方のノードが、前記追加要求に応答して、前記IPアドレスを前記検証タグと対応付けて登録する手順とを含む。
本発明によれば、以下のような効果が達成される。
(1)一方のノードがNAT装置を介してネットワークに接続されているために、そのグローバルIPアドレスが他方のノードにおいてアソシエーションの検証タグと対応付けられない場合でも、他方のノードにおける疎通確認が、一方のノードのIPアドレスとは無関係に、アソシエーションに固有の検証タグおよび送信元ポート番号の対応付けに基づいて行われるので、疎通確認を成功させて通信パスを追加できるようになる。
(2)他方のノードは、検証タグとの対応付けが未登録のIPアドレスから初期化要求を受信すると、一方のノードへ当該未登録IPアドレスの登録を要請し、一方のノードが当該登録要請に応答して未登録IPアドレスを登録要求すると、当該未登録IPアドレスを検証タグと対応付けて追加登録するので、一方のノードのIPアドレスが何らかの原因で変更され、これを当該一方のノードが認識できない場合でも、通信パスを維持できるようになる。
本発明に係るSCTP通信システムの構成を示したブロック図である。 本発明が適用されるネットワーク構成の一例を示した図である。 本発明が適用されるネットワーク構成の他の一例を示した図である。 本発明の一実施形態に係るマルチホーム接続の手順を示したシーケンスフローである。 従来のマルチホーム接続の手順を示したシーケンスフローである。
以下、図面を参照して本発明の実施の形態について詳細に説明する。本発明は、図2に示したように、専用ソフトウェアをインストール可能なサーバ・コンピュータプログラムとモバイル端末MNとの間でSCTPをベースとしたマルチホーム通信を行うシステムにおいて、通信を高信頼化する手順に関するものである(図中のSCTPベース通信ソフトにおける処理手順)。
また、図3に一例を示したように、IPネットワーク内にプロトコル変換サーバを設置し、SCTP通信とTCP通信とを変換することにより、既存のサーバ・コンピュータを変更することなく、SCTPをベースとしたマルチホーム通信システムを実現する手法も考えられる。本発明は、このようなプロトコル変換サーバを介して既存のサーバ・コンピュータと通信を行うシステムにも適用できる。
図1は、本発明に係るSCTP通信システムの構成を示したブロック図であり、本発明の説明に不要な構成は図示が省略されている。ここでは、モバイル端末MNからサーバSへのマルチホーム接続を例にして説明する。
モバイル端末MNおよびサーバSの各ネットワークノードには、インタフェース層、ネットワーク層、トランスポート層およびアプリケーション層から構成されるIPスタックが実装され、トランスポート層のプロトコルとしてSCTPが採用されている。モバイル端末MNおよびサーバSの各SCTPは、マルチホーム接続用の標準機能に加えて、本発明に固有のオプション機能を備え、これにより通信パス15の迅速な追加によるマルチホーム通信が可能になる。
サーバSのトランスポート層において、疎通確認部11は、モバイル端末MNとの間に確立されたアソシエーション(SCTPコネクション)14において、モバイル端末MNから受信したHEARTBEAT(速確認要求)チャンクに応答した疎通確認を、当該HEARTBEATの送信元IPアドレス(グローバル)とは無関係に、当該HEARTBEATチャンクの送信元SCTPポート番号および当該アソシエーション14に固有の検証タグのペアに基づいて行う。追加登録要請部12は、送信元IPアドレスが自身に未登録のHEARTBEATチャンクが受信されると、その送信元に対して、当該未登録の送信元IPアドレスの追加登録要請が記述されたHEARTBEAT-ACKチャンクを返信する。
モバイル端末MNのトランスポート層において、アドレス追加要求部13は、サーバSへ送信したHEARTBEATチャンクに対して、前記送信元IPアドレスの追加登録要請の記述されたHEARTBEAT-ACKチャンクが受信されると、自身のグローバルIPアドレスの追加登録を要求するASCONFチャンクをサーバSへ送信する。
図4は、上記のオプション機能を備えたモバイル端末MN-サーバS間でのマルチホーム接続の手順を示したシーケンスフローであり、モバイル端末MNは2つのインタフェースIF(a1),IF(a2)を備え、サーバSは2つのインタフェースIF(b1),IF(b2)を備えている。サーバSの各インタフェースIF(b1),IF(b2)には、それぞれグローバルIPアドレスGA(b1),GA(b2)が割り当てられているものとする。
時刻t1では、モバイル端末MNがサーバSとの間にアソシエーションを確立するため、一方のインタフェースIF(a1)からサーバSの一方のインタフェースIF(b1)のグローバルIPアドレスGA(b1)宛にINIT(初期化要求)チャンクを送出し、前記一方のインタフェースIF(a1)に動的に割り当てられるグローバルIPアドレスGA(1st)がサーバ側Sへ通知される。ここでは従来技術と同様に、サーバSは受信パケットのIPヘッダ等を参照することにより、モバイル端末MNの一方のインタフェースIF(a1)に割り当てられるグローバルIPアドレスGA(1st)を認識できる。
時刻t2では、サーバSの一方のインタフェースIF(b1)からモバイル端末MNの一方のインタフェースIF(a1)へINIT-ACK(初期化応答)チャンクが返信され、サーバSの全てのグローバルIPアドレスGA(b1),GA(b2)がモバイル端末MNへ通知される。サーバSでは、前記INITチャンクに記述されている検証タグQならびに当該INITチャンクの送信元IPアドレスおよび送信元SCTPポート番号が相互に対応付けられて登録される。
時刻t3,t4では、IFa1-IFb1間で認証処理のためのCOOKIE-ECHOおよびCOOKIE-ACKの各チャンクが送受されて各インタフェースIFa1,IFb2間に第1通信パス#1が接続され、アソシエーション14の確立が完了する。
その後、モバイル端末MNがサーバSとの間でマルチホーム接続を実現しようとする場合、時刻t5以降では、モバイル端末MNの他方のインタフェースIF(a2)からサーバSの他方のインタフェースIF(b2)へHEARTBEATが送信され、これに応答して返信されるHEARTBEAT-ACKチャンクに基づいて疎通性が確認される。
このとき、本実施形態では前記疎通確認部11において、アソシエーション確立時(INIT/INIT-ACKの送受時)に作成される、各アソシエーションに固有の検証タグQ、送信元IPアドレスおよび送信元SCTPポート番号の対応関係のうち、検証タグQおよび送信元SCTPポート番号のペアに基づいて疎通確認が実施され、当該ペアにより特定できるアソシエーションに対してHEARTBEAT-ACKが返信される。すなわち、本実施形態では送信元IPアドレスに基づくアソシエーションの特定は行われない。
ここで、検証タグQおよび送信元SCTPポート番号のペアと一致するアソシエーションがサーバSに未登録であれば、前記HEARTBEATがOOTB(Out Of The Blue)パケットとして扱われてABORTが返信される。これに対して、検証タグおよび送信元SCTPポート番号のペアと一致するアソシエーションがサーバSに既登録であれば、時刻t6において、サーバSのIF(b2)からモバイル端末MNのIF(a2)へHEARTBEAT-ACKのチャンクが返信される。
モバイル端末MNでは、前記HEARTBEAT-ACKの受信により、通信パスがACTIVE(かつCONFIRMED)状態にあることが判別すると、時刻t7において、IF(a2)からサーバSのIF(b2)へASCONF(Address Configuration Change)チャンクを送信して通信パスの追加・削除を要求する。時刻t8では、サーバSからモバイル端末MNへASCONF-ACKチャンクが返信されて第2通信パス#2[IF(a2)-IF(b2)]の接続が完了する。
ところで、HEARTBEATの検証方法が上記のように改修され、モバイル端末MNからサーバSへのHEARTBEATによる疎通確認が、モバイル端末MNのグローバルIPアドレスとは無関係に行われるようになると、以下のような技術課題が新たに生じ得る。
すなわち、モバイル端末MNのグローバルIPアドレスが、アクセスポイントとなるルータ(図示せず)の再起動等により変更された(ここでは、IF(a2)のグローバルIPアドレスがGA(2nd)からGA(3rd)に変更されたものとする)にも関わらず、これをモバイル端末MNが認識できないと、モバイル端末MNとサーバSとの間でASCONFによる新しいグローバルIPアドレスGA(3rd)の登録処理が行われない。したがって、サーバSは変更前のグローバルIPアドレスGA(2nd)に対してデータを送信し続けることになる。
そして、このような状態でもモバイル端末MNからサーバSへのデータ送信は成功し、かつモバイル端末MNのIF(a2)からサーバSのIF(b2)へ定期的に送信され続けるHEARTBEATによる疎通確認も、サーバSでは検証タグおよび送信元SCTPポート番号のペアに基づいて、モバイル端末MNの変更後のIPアドレスGA(3rd)とは無関係に行われるので成功してしまう。その結果、通信パスの片方向(サーバS→モバイル端末MN)においてデータ転送が行えない状態が一定期間持続してしまい、その後、再送が繰り返されて当該第2通信パス#2がサーバSにおいてINACTIVEの状態とされる。
このような技術課題を解決するために、本発明では、HEARTBEATを受信処理するサーバSに、不明なIPアドレス(ここでは、GA(3rd))からHEARTBEATを受信した際には、その旨を当該不明なIPアドレスの送信元に伝え、送信元にASCONFの送付を促すための構成として、前記図1を参照して説明した追加登録要請部12を追加している。
さらに具体的に説明すれば、不明なIPアドレスGA(3rd)からHEARTBEATを受信したサーバSが、前記図4の時刻t4においてHEARTBEAT-ACKを返信する際に、HEARTBEAT-ACKチャンクの空きビット[2]に専用のフラグを付与する一方、当該フラグが付与されたHEARTBEAT-ACKを受信したモバイル端末MNでは、前記図1を参照して説明した追アドレス追加要求部13が、以下の手順に従ってASCONFを送信する。
(1)モバイル端末MNは、新しいIPアドレスGA(3rd)をサーバSに追加登録するためのASCONF_ADDチャンクをIF(a2)からサーバSのIF(b2)へ送信する。サーバSは、当該ASCONF_ADDチャンクのヘッダ情報を参照することでモバイル端末MNの変更後のグローバルIPアドレスGA(3rd)を認識し、当該IPアドレスGA(3rd)を新しいIPアドレスとして前記アソシエーションの検証タグQと対応付けて登録する。
(2)モバイル端末MNは、古いIPアドレスGA(1st),GA(2nd)の登録をサーバSから削除させるためにASCONF_DELETEチャンクを送信する。サーバSは、当該ASCONF_DELETEチャンクのヘッダ情報を参照することでモバイル端末MNのグローバルIPアドレスGA(3rd)を認識し、同一アソシエーションの当該IPアドレスGA(3rd)以外の全てのIPアドレスGA(1st),GA(2nd)を削除する。なお、SCTPでは通信パスを削除する場合に、削除するIPアドレスを指定する方法と、指定するIPアドレス以外のIPアドレスを削除する方法との2通りの方法が規定されている。
(3)モバイル端末MNが複数のインターフェース(IPアドレス)を用いてサーバと接続されている場合、上記(2)の処理によって、同一アソシエーションにおける新しいIPアドレスGA(3rd)以外のIPアドレスが削除されてしまうので、再度、インタフェースIF(a1)よりASCONF_ADDチャンクを送信し、削除されたIPアドレスを登録し直す。
11…疎通確認部,12…追加登録要請部,13…アドレス追加要求部,14…アソシエーション(SCTPコネクション),15…通信パス

Claims (6)

  1. ネットワークにNAT装置を介して接続された一方のノードが他方のノードとの間にマルチホーム接続によるSCTPアソシエーションを確立するマルチホーム通信方法において、
    一方のノードの第1インタフェースから他方のノードの第1インタフェースへ初期化要求を送信し、これに他方のノードが応答することで第1通信パスを接続してアソシエーションを確立する手順と、
    他方のノードが、前記初期化要求の検証タグ、送信元IPアドレスおよび送信元SCTPポート番号を対応付けて自ノードへ登録する手順と、
    前記一方のノードが、第2インタフェースから他方のノードの第2インタフェースへ疎通確認要求を周期的に送信する手順と、
    前記他方のノードが、前記疎通確認要求の検証タグおよび送信元SCTPポート番号の対応付けが自身に既登録であれば、当該疎通確認要求の送信元IPアドレスとは無関係に疎通成功の応答を返信する手順とを含むことを特徴とするマルチホーム通信方法。
  2. 前記他方のノードが、前記疎通確認要求の送信元IPアドレスが自身に未登録であると、第2インタフェースから一方のノードの第2インタフェースへ当該IPアドレスの登録要請を返信する手順と、
    前記一方のノードが、前記登録要請に応答して、第2インタフェースから他方のノードの第2インタフェースへ前記IPアドレスの追加要求を送信する手順と、
    前記他方のノードが、前記追加要求に応答して、前記IPアドレスを前記検証タグと対応付けて登録する手順とを含むことを特徴とする請求項1に記載のマルチホーム通信方法。
  3. 前記一方のノードの第2インタフェースから他方のノードの第2インタフェースへ、前記追加要求したIPアドレス以外の既登録のIPアドレスの削除要求を送信する手順と、
    前記他方のノードが、前記削除要求されたIPアドレスの登録を削除する手順とを含むことを特徴とする請求項2に記載のマルチホーム通信方法。
  4. 前記一方のノードが、前記第2インタフェース以外のインタフェースから他方のノードの第2インタフェース以外のインタフェースへIPアドレスの登録要求を送信する手順を含むことを特徴とする請求項3に記載のマルチホーム通信方法。
  5. ネットワークにNAT装置を介して接続された一方のノードが他方のノードとの間にマルチホーム接続によるSCTPアソシエーションを確立するマルチホーム通信システムにおいて、
    一方のノードが、
    他方のノードへ初期化要求を送信する手段と、
    他方のノードへ疎通確認要求を送信する手段とを具備し、
    他方のノードが、
    一方のノードから受信した初期化要求の検証タグ、送信元IPアドレスおよび送信元SCTPポート番号を対応付けて登録する手段と、
    一方のノードから受信した疎通確認要求の検証タグおよび送信元SCTPポート番号の対応付けが自身に既登録であれば、当該疎通確認要求の送信元IPアドレスとは無関係に疎通成功の応答を返信する手段とを具備したことを特徴とするマルチホーム通信システム。
  6. 前記他方のノードが、前記疎通確認要求の送信元IPアドレスが自身に未登録であると、当該IPアドレスの登録要請を返信する手段と、
    前記一方のノードが、前記登録要請に応答して、前記IPアドレスの追加登録を要求する手段と、
    前記他方のノードが、前記追加登録の要求に応答して、前記IPアドレスを前記検証タグと対応付けて登録する手段とをさらに具備したことを特徴とする請求項5に記載のマルチホーム通信システム。
JP2012160447A 2012-07-19 2012-07-19 マルチホーム通信方法およびシステム Expired - Fee Related JP5840575B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012160447A JP5840575B2 (ja) 2012-07-19 2012-07-19 マルチホーム通信方法およびシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012160447A JP5840575B2 (ja) 2012-07-19 2012-07-19 マルチホーム通信方法およびシステム

Publications (2)

Publication Number Publication Date
JP2014022969A JP2014022969A (ja) 2014-02-03
JP5840575B2 true JP5840575B2 (ja) 2016-01-06

Family

ID=50197403

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012160447A Expired - Fee Related JP5840575B2 (ja) 2012-07-19 2012-07-19 マルチホーム通信方法およびシステム

Country Status (1)

Country Link
JP (1) JP5840575B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105376341B (zh) * 2015-10-10 2018-11-09 北京中创信测科技股份有限公司 自动跟踪设备多ip配置的方法
KR102134895B1 (ko) * 2019-11-28 2020-07-17 주식회사 모비젠 멀티호밍 sctp노드 상에서 동작하는 sctp 유저 어플리케이션의 패킷 분석 시스템 및 그 방법

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4343579B2 (ja) * 2003-05-09 2009-10-14 株式会社エヌ・ティ・ティ・ドコモ 通信システム、通信装置及び通信方法
US7685290B2 (en) * 2004-09-21 2010-03-23 Cisco Technology, Inc. Method and apparatus for handling SCTP multi-homed connections
US8862776B2 (en) * 2008-08-27 2014-10-14 Motorola Mobility Llc Communication network and method of operation therefor

Also Published As

Publication number Publication date
JP2014022969A (ja) 2014-02-03

Similar Documents

Publication Publication Date Title
JP4998316B2 (ja) 通信システム及び通信処理方法並びにノード
US8824480B2 (en) Method and apparatus for end-host based mobility, multi-homing and multipath protocols
US9294548B2 (en) Mobility handling in a communication network
US10110554B2 (en) Method and apparatus for supporting mobility of user equipment
US20230189368A1 (en) Associating transport identifiers with quality of service flows
WO2020083269A1 (zh) 一种建立多路径连接的子流的方法、装置和系统
WO2024000937A1 (zh) 一种支持终端移动接入的多模态网络控制系统和方法
JP2018526923A (ja) 通信ネットワークのための強化近隣発見
JP5502947B2 (ja) 動的ホスト構成プロトコル(dhcp)リリースメッセージの照合のための方法と装置
KR20180051621A (ko) 전기통신 네트워크와 적어도 하나의 사용자 장비 간의 적어도 하나의 통신 교환의 개선된 핸들링을 위한 방법, 전기통신 네트워크, 사용자 장비, 시스템, 프로그램 및 컴퓨터 프로그램 제품
US9917926B2 (en) Communication method and communication system
WO2015070377A1 (zh) 一种多方通话方法及装置
JP5840575B2 (ja) マルチホーム通信方法およびシステム
JP4806364B2 (ja) ルータ切替方法、およびルータ装置
WO2018006359A1 (zh) 一种本地网关之间建立隧道的方法及网关
WO2023071522A1 (zh) 建立连接的方法、装置、存储介质及电子装置
WO2011120276A1 (zh) 一种终端实现连接建立的方法及系统
WO2013083037A1 (zh) 更新报文的处理方法及系统、映射服务器和移动节点
US20200137726A1 (en) Communications device and communication method
JP5918076B2 (ja) マルチホーム通信方法およびシステム
US10681750B2 (en) Method and apparatus for supporting mobility of user device in mobile communication network
WO2015013883A1 (zh) 一种数据传输方法及设备
KR101177354B1 (ko) 이동 단말, 통신 네트워크 및 그것의 이동성 제어 방법
TW201431338A (zh) 多廣域網路介面設備及其更新路由表的方法
KR101035817B1 (ko) 무선 인터넷 서비스를 위한 이동 단말의 인터넷 주소 형성방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150121

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150930

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: 20151021

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20151111

R150 Certificate of patent or registration of utility model

Ref document number: 5840575

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees