特許 6381565 マルチキャストツリーの更新方法及びシステム

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

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

(11)【特許番号】6381565

(24)【登録日】2018年8月10日

(45)【発行日】2018年8月29日

(54)【発明の名称】マルチキャストツリーの更新方法及びシステム

(51)【国際特許分類】

   H04W 4/06 20090101AFI20180820BHJP

   H04W 36/18 20090101ALI20180820BHJP

   H04W 80/04 20090101ALI20180820BHJP

【ＦＩ】

   H04W4/06 150

   H04W36/18

   H04W80/04

【請求項の数】11

【全頁数】34

(21)【出願番号】特願2016-47440(P2016-47440)

(22)【出願日】2016年3月10日

(62)【分割の表示】特願2013-545027(P2013-545027)の分割

【原出願日】2011年12月20日

(65)【公開番号】特開2016-106501(P2016-106501A)

(43)【公開日】2016年6月16日

【審査請求日】2016年3月10日

(31)【優先権主張番号】201010597699.6

(32)【優先日】2010年12月20日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】507142144

【氏名又は名称】中国移▲動▼通信集▲団▼公司

【氏名又は名称原語表記】ＣＨＩＮＡ ＭＯＢＩＬＥ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＣＯＲＰＯＲＡＴＩＯＮ

(74)【代理人】

【識別番号】100101454

【弁理士】

【氏名又は名称】山田 卓二

(74)【代理人】

【識別番号】100081422

【弁理士】

【氏名又は名称】田中 光雄

(74)【代理人】

【識別番号】100125874

【弁理士】

【氏名又は名称】川端 純市

(72)【発明者】

【氏名】惠 敏

(72)【発明者】

【氏名】▲でん▼ 輝

(72)【発明者】

【氏名】曹 振

【審査官】 青木 健

(56)【参考文献】

【文献】 米国特許出願公開第２００８／００８４８４７（ＵＳ，Ａ１）

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

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

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

【文献】 欧州特許出願公開第０２０１２４７８（ＥＰ，Ａ１）

【文献】 国際公開第２００８／０６９６３０（ＷＯ，Ａ１）

【文献】 H YOKOTA，FAST HANDOVERS FOR PROXY MOBILE IPV6; DRAFT-IETF-MIPSHOP-PFMIPV6-01.TXT，IETF STANDARD-WORKING-DRAFT，スイス，IETF，２００８年１２月１９日

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

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

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

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１，４

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

【請求項1】

マルチキャストツリーの更新方法であって、
第1のマルチキャストノードは、第1の移動アクセスゲートウェイMAGによって送信されたデータパケットを受信し、
上記データパケットにマルチキャストソースが第１の移動アクセスゲートウェイMAGから第２のMAGへアクセスを切り替えるように指示するためのマルチキャストソース切り替え指示を有すると特定した後に、マルチキャストツリーを生成するためのアクセスメッセージを構築し、上記データパケットに有する第2のMAGのアドレス情報を、上記アクセスメッセージに付加して転送し、
上記アクセスメッセージを受信した第2のマルチキャストノードは、上記アクセスメッセージが有する第2のMAGのアドレス情報に基づいて、マルチキャストルートを更新し、
上記第２のMAGのアドレス情報に基づいてマルチキャストルートを更新した後の第２のマルチキャストノードが上記アクセスメッセージを受信するまで、上記アクセスメッセージを続けて転送することを含むことを特徴とする方法。

【請求項2】

上記マルチキャストソース切り替え指示及び上記第2のMAGのアドレス情報が、上記データパケットのＩpv6ホップバイホップのオプションヘッダーに付加されることを特徴とする請求項１に記載の方法。

【請求項3】

第1のマルチキャストノードが上記データパケットに有する第2のMAGのアドレス情報を、上記アクセスメッセージに付加して転送することは、
第1のマルチキャストノードが上記アクセスメッセージを、上記第2のMAGのアドレスを目的アドレスとするデータパケットにパッケージングし、上記データパケットに上記マルチキャストソース切り替え指示を付加し、
設定された上流の近隣ルータアドレスに基づいて、上記マルチキャストソース切り替え指示を有するデータパケットを転送することを含むことを特徴とする請求項１に記載の方法。

【請求項4】

上記アクセスメッセージを受信した第2のマルチキャストノードが、上記アクセスメッセージが有する第2のMAGのアドレス情報に基づいてマルチキャストルートを更新することは、
第2のマルチキャストノードは、上記アクセスメッセージが有する第2のMAGのアドレス情報に基づいて、このマルチキャストサービスに対応するマルチキャストルート状態での予備切り替えインターフェースPre-handoverInterfaceを、上記第2のMAGへのRPFインターフェースに設置することを含むことを特徴とする請求項１に記載の方法。

【請求項5】

第2のマルチキャストノードは、上記アクセスメッセージが有する第2のMAGのアドレス情報に基づいて、このマルチキャストサービスに対応するマルチキャストルート状態でのPre-handoverInterfaceを、上記第2のMAGへのRPFインターフェースに設置することは、
第2のマルチキャストノードは、その自身にこのマルチキャストサービスに対応するマルチキャストルート状態があるかどうかを特定し、
このマルチキャストサービスに対応するマルチキャストルート状態があると特定した場合に、上記マルチキャストルート状態でのPre-handoverInterfaceを、上記第2のMAGへのRPFインターフェースに設置し、
このマルチキャストサービスに対応するマルチキャストルート状態がないと特定した場合に、マルチキャストルート状態を作成し、上記マルチキャストルート状態でのPre-handoverInterfaceの状態を、上記第2のMAGへのRPFインターフェースに設置し、上記マルチキャストルート状態でのデータ受信インターフェースActiveInterfaceの状態を空きに設置することを含むことを特徴とする請求項４に記載の方法。

【請求項6】

第2のマルチキャストノードが上記アクセスメッセージが有する第2のMAGのアドレス情報に基づいてマルチキャストルートを更新した後に、
第2のマルチキャストノードが、初めて上記Pre-handoverInterfaceを介してデータを受信し、
マルチキャストルート状態でのActiveInterface状態が空き、又は上記ActiveInterfaceとPre-handoverInterfaceとが同じである場合に、上記Pre-handoverInterface の状態に基づいて、上記ActiveInterfaceの状態を設置し、上記Pre-handoverInterfaceの状態を空きに設置することをさらに含むことを特徴とする請求項５に記載の方法。

【請求項7】

マルチキャストツリーの更新システムであって、
第1の移動アクセスゲートウェイMAGが送信するデータパケットを受信し、上記データパケットにマルチキャストソースが第１の移動アクセスゲートウェイMAGから第２のMAGへアクセスを切り替えるように指示するためのマルチキャストソース切り替え指示を有すると特定した後に、マルチキャストツリーを生成するためのアクセスメッセージを構築し、上記データパケットに有する第2のMAGのアドレス情報を、上記アクセスメッセージに付加して転送するための第1のマルチキャストノードと、
上記第1のマルチキャストノードが転送する上記アクセスメッセージを受信し、上記アクセスメッセージが有する第2のMAGのアドレス情報に基づいてマルチキャストルートを更新し、既に上記第2のMAGのアドレス情報に基づいてマルチキャストルートを更新した後の第２のマルチキャストノードが、上記アクセスメッセージを受信するまで、上記アクセスメッセージを続けて転送する第2のマルチキャストノードとを含むことを特徴とするシステム。

【請求項8】

上記第1のマルチキャストノードは、具体的に、
上記アクセスメッセージを、上記第2のMAGのアドレスを目的アドレスとするデータパケットにパッケージングし、上記データパケットに上記マルチキャストソース切り替え指示を付加し、設定された上流の近隣ルータアドレスに基づいて、上記マルチキャストソース切り替え指示を有するデータパケットを転送することを特徴とする請求項７に記載のシステム。

【請求項9】

上記第2のマルチキャストノードは、具体的に、
上記アクセスメッセージが有する第2のMAGのアドレス情報に基づいて、このマルチキャストサービスに対応するマルチキャストルート状態での予備切り替えインターフェースPre-handoverInterfaceを、上記第2のMAGへの逆方向パス転送 RPFインターフェースに設置することを特徴とする請求項７に記載のシステム。

【請求項10】

上記第2のマルチキャストノードは、具体的に、
その自身にこのマルチキャストサービスに対応するマルチキャストルート状態があるかどうかを特定し、
このマルチキャストサービスに対応するマルチキャストルート状態があると特定した場合に，上記マルチキャストルート状態でのPre-handoverInterfaceを、上記第2のMAGへのRPFインターフェースに設置し、
このマルチキャストサービスに対応するマルチキャストルート状態がないと特定した場合に、マルチキャストルート状態を作成し、上記マルチキャストルート状態でのPre-handoverInterfaceの状態を、上記第2のMAGへのRPFインターフェースに設置し、上記マルチキャストルート状態でのデータ受信インターフェースActiveInterfaceの状態を空きに設置することを特徴とする請求項９に記載のシステム。

【請求項11】

上記第2のマルチキャストノードは、さらに、
上記アクセスメッセージが有する第2のMAGのアドレス情報に基づいてマルチキャストルートを更新した後に、初めて上記Pre-handoverInterfaceによりデータを受信し、マルチキャストルート状態でのActiveInterface状態が空き、又は上記ActiveInterfaceとPre-handoverInterfaceとが同じである場合に、上記Pre-handoverInterfaceの状態に基づいて、上記ActiveInterfaceの状態を設置し、上記Pre-handoverInterfaceの状態を空きに設置することを特徴とする請求項１０に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、移動通信技術分野に関し、特にマルチキャストデータを伝送する方法、マルチキャストツリーの更新方法並びにシステム及び装置に関する。

【0002】

本願は、2010年12月21日に中国専利局に提出した、出願番号が201010597699.6であって、発明の名称が「マルチキャストデータを伝送する方法、マルチキャストツリーの更新方法及びシステム並びに装置」である中国特許出願の優先権を主張し、本願で、その全ての内容を援用するものとする。

【背景技術】

【0003】

近年、無線技術の成熟につれて、多くの人が、無線デバイスを介してネットワークに接続しつつあり、且ついつでも、どこでもネットワークにアクセスすることを希望している。移動通信のサポートは、ネットワークの発展に必然的な要求であり、多くの研究が、既にネットワークがどのように移動をサポートするかに関心を寄せている。なお、IETF(Internet Engineering Task Force：インターネット技術タスクフォース）のPMIPv6(ProxyMobileIPv6：プロキシ移動IPv6)は、局所モバイル管理技術として、モバイル管理機能を端末側からネットワーク側にシフトさせ、ネットワークは、ホストを代表してIPモビリティの管理を担当し、ネットワークにおける移動エンティティは、ホストの移動を追跡し、且つ要請される移動信号伝送の初期化を担当する。PMIPv6は、ホストがいかなるモバイル関連信号伝送にも参与する必要がない前提でホストのIP(Internet Protocol：インターネット・プロトコル）モビリティを実現することにより、端末の負荷を大幅に軽減するとともに、集中制御の便を図る。

【0004】

一方、マルチキャスト技術は、広く様々な分野に適用されつつある。マルチキャストは、ポイントツーマルチポイントの情報伝送方式であって、データが一つのソースノードから複数のターゲットノードに伝送できるよう要請し、ターゲットノードは一つの特定のノード集合を構成し、グループ又は群と称する。マルチキャスト技術は、ネットワーク利用率が高く、バックボーンネットワークの輻輳を低減し、省資源、拡張性が強い等のメリットを有するので、ビデオ会議、ファイル配布、リアルタイム情報発信、IPテレビ等新型ネットワークの適用に重要な役割を果たしている。典型的モバイルIPTV(Interactive Personality TV、インタラクティブパーソナリティーテレビ）の応用において、大量のユーザーは、マルチキャスト技術によりネットワークが配布したオーディオ/ビデオストリームデータを得ることができる。

【0005】

移動通信技術の発展につれて、移動とマルチキャストとの結合が、差し迫って必要とされている。移動環境において、無線リンクのリンク帯域幅が有限で、且つ、高いエラーレートを有するとともに、移動ノードのエネルギ供給、プロセッサー能力等も非常に限られているため、これは伝統的マルチキャスト技術に対して新たな挑戦である。伝統的マルチキャストプロトコルは、固定ネットワーク、有線による通信方式に基づいたものであるため、モビリティの要求を満足することができない。移動マルチキャストアーキテクチャは、移動ホスト位置の動態変化を処理するだけでなく、マルチキャストグループ中で動的変化しているグループメンバーの関係を処理する。つまり、移動環境におけるマルチキャストアーキテクチャは以下の要求を満足する必要がある。即ち、ノード切り替えの際にマルチキャストダイアログのシームレスな連続性を保証することと、データパケットの最適ルートを保証することと、マルチキャスト通信でのストリーム切り替え（異なるストリームは異なる特性と標識を有する）をサポートすることと、マルチキャストの解決方案の特殊化(マルチキャストのみをサポートするが、ユニキャストをサポートしない）を回避することと、パケットロス、重複コピーを処理可能であることと、マルチキャストデータストリームが現在のネットワークの状況に動的に適応する（送信レート等を調整する）ことと、配置が簡単であることと、ルーティングプロトコルの収束速度を加速する等がある。

【0006】

現在、IETFワークグループによるマルチキャストソース移動支援の研究作業は、依然として初期段階にあり、PMIPv6においてマルチキャストソースモビリティをサポートする方案が提出されている。この方案は、PMIPv6においてRPT（Rendezvous Point Tree、ランデブーポイントツリー）とSPT(Shortest Path Tree、最短パスツリー）の方法を提出している。

【0007】

方案は、RPTモードを使用してマルチキャストデータを伝送する際に、LMA(Local Mobility Anchor：ローカルモビリティアンカー）を使用してRP(Rendezvous Point：ランデブーポイント）とし、それによりマルチキャスト受信ノードの送信したアクセスメッセージを返信し、LMAからマルチキャスト受信ノードまでの最短パスマルチキャストツリーを構築することを提案した。マルチキャストデータは、マルチキャストソースからLMAに送信され、さらにLMAによってマルチキャストツリーを通じてマルチキャスト受信ノードに転送される。このモードでは、マルチキャストソースの位置が移動する際に、LMAからマルチキャスト受信ノードまでの最短パスツリーを新たに構築する必要がなく、マルチキャストツリーが安定的である。しかし、LMAにより転送されるパスはマルチキャストソースからマルチキャスト受信ノードまでの最適ルートではないため、このモードは大きなタイムラグとネットワーク負荷を招致する恐れがある。

【0008】

RPTモードで、マルチキャストソースMNがPMIPv6ドメインに入った後、実行されるフローは、図1に示すように、主に以下のステップを含む。
ステップ101：移動アクセスゲートウェイMAG1とマルチキャストソースMNとの間のリンクを構築し、マルチキャストソースMNは、RS（Router Solicitation：ルータ要請）メッセージには「S」=1、「J」=1が含まれ、自身がマルチキャストソースであることを標識するとともに、RPTモードを選択する。

【0009】

ステップ102：MAG1は、マルチキャストソースMNがアクセスしたと特定した後に、拡張したPBUメッセージをLMAに送信して、MAG1とLMAとの間の双方向トンネルを構築する。
当該ステップ102において、LMAがPBUメッセージを受信した後に、当該 PUBメッセージに含まれる拡張情報を解析し、マルチキャストアクセスメッセージを返信する。

【0010】

ステップ103：マルチキャストデータは、PMIPv6で定義した基本方式に従って、マルチキャストソースMNからLMAに送信される。
当該ステップにおいて、LMAとマルチキャスト受信ノードとの間にSPTが構築され、マルチキャストデータは、マルチキャストルートプロトコルに従って LMAとマルチキャスト受信ノードとの間で伝送される。

【0011】

ステップ104：マルチキャストソースMNがMAG2に移動し、マルチキャストソースMNがRSメッセージによりマルチキャスト関連情報をMAG2に送信する。

【0012】

ステップ105：LMAとMAG2との間の双方向トンネルを更新する。
当該ステップ105において、LMAとMAG2との間の双方向トンネルを更新する過程は、LMAとマルチキャスト受信者とのSPTに影響を及ぼさない。

【0013】

マルチキャストソースMNを切り替えた後に、マルチキャストデータが継続して伝送される。マルチキャストソースの移動は、マルチキャスト受信者に影響を及ぼさない。

【0014】

方案は、SPTモードを使用してマルチキャストデータを伝送する際に、マルチキャストソースによりマルチキャスト受信ノードの送信したアクセスメッセージを返信し、マルチキャストソースからマルチキャスト受信ノードまでの最短パスマルチキャストツリーを直接に構築し、マルチキャストデータは、マルチキャストソースから直接に構築されたマルチキャストツリーを介してマルチキャスト受信ノードに送信されることを提案する。このモードでは、ルートの最適化のために、ネットワーク遅延は小さいが、ルータの記憶負荷が重すぎ、マルチキャストツリーが不安定であるという問題を引き起こすおそれがある。マルチキャストソースがネットワークにおいて移動する時に、マルチキャストツリーは頻繁に更新する必要がある。

【0015】

SPTモードで、マルチキャストソースMNがPMIPv6ドメインに入った後に実行されるフローは、図2に示すように、主に以下のステップを含む。
ステップ201：MAG1とマルチキャストソースMNとの間のリンクを構築し、マルチキャストソースMNは、RSメッセージで「S」=1、「J」=0を含み、自身がマルチキャストソースであることを標記するとともに、SPTモードを選択する。

【0016】

ステップ202：MAG1は、マルチキャストソースMNがアクセスしたと特定した後に、拡張したPBUメッセージをLMAに送信して、MAG1とLMAとの双方向トンネルを構築する。
当該ステップ202において、LMAは、PBUメッセージを受信した後に、当該PUBメッセージに含まれる拡張情報を解析するが、マルチキャストアクセスメッセージを返信しない。

【0017】

ステップ203：マルチキャストデータは、PMIPv6で定義した基本方式に従ってマルチキャストソースMNからLMAに送信される。
当該ステップ203において、LMAが、マルチキャストアクセスメッセージをマルチキャストソースMNにリダイレクトする際に、マルチキャストソースとマルチキャスト受信ノードとのSPTを構築し始め、次のマルチキャストデータは、最適化された後のパスに従ってマルチキャストソースとマルチキャスト受信ノードとの間で伝送される。

【0018】

ステップ204：マルチキャストソースMNがMAG2に移動した後に、マルチキャストソースMNは、RSメッセージによりマルチキャスト関連情報をMAG2に送信する。

【0019】

ステップ205：LMAとMAG2との双方向トンネルを更新する。
当該ステップ205において、LMAとMAG2との双方向トンネルを更新する時に、マルチキャストソースとマルチキャスト受信ノードとのSPTを更新する必要もある。それは、マルチキャストツリーのルートノードは異なる位置に移動したためである。

【0020】

方案には、マルチキャストソースが移動速度に基づいてモードの選択を行うことが規定されている。ネットワークにおいてマルチキャストソースが小さい速率で移動する場合に、SPTの方式を採用して、マルチキャストソースとマルチキャスト受信ノードとの間で最短パスマルチキャストツリーを構築し、ネットワークにおいてマルチキャストソースの移動速度が速い場合に、RPTの方式を採用して、LMAをシンクノードとして、LMAとマルチキャスト受信ノードとの間で最短パスマルチキャストツリーを構築する。

【発明の概要】

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

【0021】

従来技術の欠点として、マルチキャストソースの急速な切り替えをサポートできず、マルチキャストソースがPMIPv6ドメインにおいて二つのMAGの間で切り替えを行う際に大きい遅延がある。従来の方案では、マルチキャストソースが古いMAG(即ち、MAGI)から新しいMAG(即ち、MAG2)に移動すると、マルチキャストソースとMAG2との間のバインディング更新、認証等の一連の過程を行う必要があり、特に、SPTモードでは、さらにマルチキャストツリーの再構築過程を行う必要があることが規定されている。これらの過程が終了した後に、マルチキャストデータの配布を続けて行うことができる。よって、マルチキャストサービスには長い時間の中断が生じる。マルチキャストサービスの1対多特性のため、マルチキャストソースの切り替え遅延はグループ内の全てのユーザーに影響を及ぼす。よって、マルチキャストセッションのシームレスな連続性を満足できず、特に適時性が要求される応用に大きく影響を及ぼすことは明らかである。

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

【0022】

これに鑑み、本発明の実施例は、マルチキャストデータを伝送する方法、マルチキャストツリーの更新方法及びシステム並びに装置を提供し、当該技術方案を採用して、マルチキャストソースが移動ゲートウェイの間で切り替えることによるマルチキャストサービス中断時間遅延を低減し、PMIPv6システムにおいてマルチキャストサービスの適時性を保証する。

【0023】

本発明実施例は、以下の通りの技術方案により実現される。
本発明の実施例の一方面に基づいて、マルチキャストデータを伝送する方法を提供し、
第1の移動アクセスゲートウェイMAGは、マルチキャストソースが現在アクセスする第1のMAGから第2のMAGに切り替える前に送信する切り替え予告メッセージを受信し、上記切り替え予告メッセージは、上記第2のMAGの標識情報を有し、
第1のMAGは、上記切り替え予告メッセージに有する上記第2のMAGの標識に基づいて、上記第2のMAGとの間の双方向トンネルを構築し、
特定された切り替え後のマルチキャストモード、及び構築された上記双方向トンネルに基づいて、上記マルチキャストソースからのマルチキャストデータに対してマルチキャストを行い、
上記切り替え後のマルチキャストモードは、上記マルチキャストソースが上記第2のMAGに切り替えた後に用いられるマルチキャストモードである。

【0024】

本発明の実施例の一方面によれば、マルチキャストツリーの更新方法が提供され、
第1のマルチキャストノードは、第1の移動アクセスゲートウェイMAGが送信するデータパケットを受信し、
上記データパケットにマルチキャストソース切り替え指示を有することを特定した後に、マルチキャストツリーを生成するためのアクセスメッセージを構築し、上記データパケットに有する第2のMAGのアドレス情報を、上記アクセスメッセージに付加して転送し、
上記アクセスメッセージを受信した第2のマルチキャストノードは、上記アクセスメッセージが有する第2のMAGのアドレス情報に基づいて、マルチキャストルートを更新し、既に上記第2のMAGのアドレス情報に基づいてマルチキャストルートを更新した後のマルチキャストノードが、上記アクセスメッセージを受信するまで、続いて上記アクセスメッセージを転送することを含む。

【0025】

本発明の実施例の一方面によれば、マルチキャストデータを伝送するシステムが提供され、
マルチキャストソース、第1の移動アクセスゲートウェイMAG、及び第2のMAGを含み、
上記マルチキャストソースは、現在アクセスしている第1のMAGから第2のMAGに切り替える前に、上記第1のMAGへ切り替え予告メッセージを送信するためのものであり、上記切り替え予告メッセージは、上記第2のMAGの標識情報を有し、
上記第1のMAGは、上記マルチキャストソースが送信する切り替え予告メッセージに有する上記第2のMAGの標識に基づいて、上記第2のMAGとの間の双方向トンネルを構築し、特定された切り替え後のマルチキャストモード、及び構築された上記双方向トンネルに基づいて、上記マルチキャストソースからのマルチキャストデータに対してマルチキャストを行うためのものであり、上記切り替え後のマルチキャストモードは、上記マルチキャストソースが上記第2のMAGに切り替えられた後に用いられるマルチキャストモードである。

【0026】

本発明の実施例の一方面に基づいて、マルチキャストデータを伝送する装置を提供し、
マルチキャストソースが現在アクセスしている第1の移動アクセスゲートウェイMAGから第2のMAGに切り替える前に送信する、上記第2のMAGの標識情報を有する切り替え予告メッセージを受信するための切り替え予告メッセージ受信ユニットと、
上記切り替え予告メッセージ受信ユニットが受信する切り替え予告メッセージに有する上記第2のMAGの標識に基づいて、上記第2のMAGとの間の双方向トンネルを構築するためのトンネル構築ユニットと、
特定された切り替え後のマルチキャストモード、及び上記トンネル構築ユニットが構築した上記双方向トンネルに基づいて、上記マルチキャストソースからのマルチキャストデータに対してマルチキャストを行うためのマルチキャストデータ伝送ユニットとを含み、
上記切り替え後のマルチキャストモードは、上記マルチキャストソースが上記第2のMAGに切り替えた後に用いるマルチキャストモードである。

【0027】

本発明の実施例の一方面に基づいて、マルチキャストツリーの更新システムを提供し、
第1の移動アクセスゲートウェイMAGによって送信されるデータパケットを受信し、上記データパケットにマルチキャストソース切り替え指示を有すると特定した後に、マルチキャストツリーを生成するためのアクセスメッセージを構築し、上記データパケットに有する第2のMAGのアドレス情報を、上記アクセスメッセージに付加して転送するための第1のマルチキャストノードと、
上記第1のマルチキャストノードによって転送される上記アクセスメッセージを受信し、上記アクセスメッセージが有する第2のMAGのアドレス情報に基づいてマルチキャストルートを更新し、上記第2のMAGのアドレス情報に基づいて既にマルチキャストルートが更新された後のマルチキャストノードが、上記アクセスメッセージを受信するまで、上記アクセスメッセージを続けて転送する第2のマルチキャストノードとを含む。

【0028】

本発明の実施例が提供した上記少なくとも一つの技術方案により、第1のMAGは、マルチキャストソースが送信する、第2のMAG標識を含む切り替え予告メッセージを受信し、当該切り替え予告メッセージに含まれる第2のMAG標識に基づいて、当該第2のMAG標識に対応する第2のMAGとの間の双方向トンネルを構築し、特定された切り替え後のマルチキャストモード、及び構築された双方向トンネルに基づいて、マルチキャストソースからのマルチキャストデータに対してマルチキャストを行う。なお、切り替え後のマルチキャストモードは、マルチキャストソースが第2のMAGに切り替えられた後に用いられるマルチキャストモードである。当該技術方案を採用すると、切り替え予告メッセージが、マルチキャストソースが現在アクセスしている第1のMAGから第2のMAGに切り替えられる前に送信され、予め双方向トンネルを構築することにより、マルチキャストソースと第2のMAGとの間でバインディング更新、認証等の過程を行う際に、第1のMAGは、構築した当該双方向トンネルを介してマルチキャストデータを伝送し、これにより、マルチキャストソースがMAGの間で切り替えられることによるマルチキャストサービス中断時間遅延を低減し、PMIPv6システムにおけるマルチキャストサービスの適時性及び連続性を保証する。

【0029】

本発明の他の特徴及び利点は、以下の明細書において記載され、且つ部分的に明細書から明らかになり、又は本発明を実施することにより明確になる。本発明の目的及び他の利点は、作成した明細書、請求の範囲、及び図面に特に指摘された構成により実現され得る。

【0030】

図面は、本発明をさらに理解するためのものであって、明細書の一部を構成し、本発明の実施例とともに、本発明を解釈するためのものであるが、本発明を限定するものではない。

【図面の簡単な説明】

【0031】

【図1】従来技術が提供する、RPTモードでマルチキャストソースがPMIPv6ドメインに入る切り替えフローチャートである。

【図2】従来技術が提供する、SPTモードでマルチキャストソースがPMIPv6ドメインに入る切り替えフローチャートである。

【図3】本発明の実施例一が提供する、マルチキャストデータを伝送する方法のフローチャートである。

【図4】本発明の実施例一が提供する、MAG1とMAG2との間に双方向トンネルを構築するフローチャートである。

【図5】従来技術に定義される、HIメッセージの基本的なメッセージフォーマットの模式図である。

【図6】本発明の実施例一が提供する、拡張後のHIメッセージの基本的なメッセージフォーマットの模式図である。

【図7】本発明の実施例一が提供する、マルチキャストソース切り替えオプションのフォーマットの模式図である。

【図8】従来技術に定義される、HAckメッセージの基本的なメッセージフォーマットの模式図である。

【図9】本発明の実施例一が提供する、拡張後のHAckメッセージのメッセージフォーマットの模式図である。

【図10】本発明の実施例一が提供する、RPTモードでマルチキャストデータを伝送するフローチャートである。

【図11】本発明の実施例一が提供する、SPT、且つ不更新マルチキャストツリーモードでマルチキャストデータを伝送するフローチャートである。

【図12】本発明の実施例一が提供する、SPT、且つマルチキャストツリー予備更新モードでマルチキャストデータを伝送するフローチャートである。

【図13】本発明の実施例一が提供する、マルチキャストソースがアクセスポイント1からアクセスポイント2に移動した際のマルチキャストツリーの模式図である。

【図14】本発明の実施例一が提供する、マルチキャストツリー更新のフローチャートである。

【図15】本発明の実施例一が提供する、マルチキャストルートを更新するフローチャートである。

【図16】本発明の実施例一が提供する、IPv6ホップバイホップオプションヘッダーのフォーマットの模式図である。

【図17】本発明の実施例一が提供する、マルチキャストソース切り替えオプションのフォーマットの模式図である。

【図18】本発明の実施例一が提供する、マルチキャストルートをさらに更新するフローチャートである。

【図19】本発明の実施例二が提供する、マルチキャストデータを伝送する装置模式図1である。

【図20】本発明の実施例二が提供する、マルチキャストデータを伝送する装置模式図2である。

【図21】本発明の実施例二が提供する、マルチキャストデータを伝送する装置模式図3である。

【図22】本発明の実施例三が提供する、マルチキャストデータを伝送するシステム模式図である。

【図23】本発明の実施例四が提供する、マルチキャストツリー更新システムの模式図である。

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

【0032】

PMIPv6システムにおいてマルチキャストサービスの適時性及び連続性を保証する実現方案を与えるために、本発明の実施例は、マルチキャストデータを伝送する方法、マルチキャストツリーの更新方法及びシステム並びに装置を提供し、以下、図面に基づいて本発明の最適な実施例を説明する。ここで記述する最適実施例は、本発明を説明や解釈するためのものであり、本発明を限定するものではないことを理解すべきである。そして、衝突しない場合に、本願の実施例、及び実施例における特徴は、互いに組合せることができる。

【0033】

実施例一
本発明の実施例一は、まず、マルチキャストデータ伝送方法を提供する。当該方法により、移動マルチキャストソースがPMIPv6システムにおいて二つのMAGの間で切り替わる際にマルチキャストの中断が長すぎるという問題を解決し、できるだけ短い時間遅延内でマルチキャストサービスを回復する目的を果たす。本発明の実施例一は、マルチキャストツリーの更新方法をさらに提供する。当該方法により、PMIPv6においてマルチキャストソースが移動する際のSPTの予備更新問題を解決し、マルチキャスト受信者に対して透明であることを前提として、マルチキャストソース切り替え終了前に予めSPTを更新する目的を実現した。

【0034】

本発明は、例えば、マルチキャストソースMNが、現在アクセスしているMAG1から同一PMIPv6ドメインにおけるMAG2に移動するなどの、同一PMIPv6システム内でマルチキャストソースMNを切り替えるシーンに応用することができる。本発明の実施例一が提供する、マルチキャストデータ伝送方法を詳細に記述する前に、まず、本発明の実施例に提案されている切り替え後のマルチキャストモードを詳細に説明する。ここで、切り替え後のマルチキャストモードは、マルチキャストソースMNがMAG2にアクセスした後に採用されるマルチキャストモードである。

【0035】

本発明の実施例は、三つの切り替え後のマルチキャストモードを提供する。当該三つの切り替え後のマルチキャストモードは
RPTモード、
SPT且つ不更新マルチキャストツリーモード、
SPT且つマルチキャストツリー予備更新モードに分類される。

【0036】

以下、当該三つの切り替え後のマルチキャストモードを詳細に説明する。
(1)RPTモード
マルチキャストソースMNがMAG1にアクセスする際にRPTモードを採用してマルチキャストデータを伝送し、即ち、LMAを使用してRPとする。マルチキャストデータは、まず、LMAに送信されてから、LMAにより各マルチキャスト受信者に伝送される。この場合に、当該マルチキャストソースMNがMAG2に切り替えられた後に、依然としてRPTモードを使用する必要がある。即ち、マルチキャストソースMNがMAG2にアクセスした後に用いられるマルチキャストモードがRPTモードである。このモードでは、MAG1は、RPアドレスをMAG2に伝達する必要があり、MAG2は、RPまでのパスを構築する必要がある。

【0037】

当該RPTモードによると、マルチキャストソースとMAG2の接続が構築されて、且つバインディング更新等の過程が終了される前に、マルチキャストデータ を、MAG1及びMAG2との間に構築された双方向トンネルを介して転送することができる。即ち、マルチキャストデータがマルチキャスト受信者に対応するマルチキャスト受信ノードに送信される際に通るパスは以下の通りである。
Source(即ち、マルチキャストソース）→MAG2→MAG1→LMA(RP)→マルチキャストツリーがマルチキャスト受信ノードに伝送する。

【0038】

マルチキャストソースとMAG2との接続が構築されており、且つバインディング更新等の過程が終了した後に、マルチキャストデータがマルチキャスト受信者に対応するマルチキャスト受信ノードに送信される際に通るパスは、以下の通りである。
Source→MAG2→LMA(RP)→マルチキャストツリーがマルチキャスト受信ノードに伝送する。

【0039】

（2）SPT且つ不更新マルチキャストツリーモード
マルチキャストソースMNがMAG1にアクセスする際にSPTモードを用いてマルチキャストデータを伝送する。この際にマルチキャストソースMNの移動速度が速い（例えば、設定閾値よりも大きい）と、当該マルチキャストソースMNがMAG2に切り替えられた後に、SPTモードを続けて使用してマルチキャストデータを伝送する必要があるが、マルチキャストツリーは更新する必要がない。当該切り替え後のマルチキャストモードを、SPT且つ不更新マルチキャストツリーモードと称する。

【0040】

当該SPT且つ不更新マルチキャストツリーモードによれば、MAG1及びMAG2の間に構築された双方向トンネルを介して転送することができる。即ち、マルチキャストソースとMAG2との接続が構築されており、且つバインディング更新等の過程が終了する前及び後に、マルチキャストデータがマルチキャスト受信者に対応するマルチキャスト受信ノードに送信される際に通るパスは以下の通りである。
Source→MAG2→MAG1→マルチキャストツリー。

【0041】

当該SPT且つ不更新マルチキャストツリーモードを採用すると、MAG1とMAG2との間のトンネルは、マルチキャストソースとMAG2との接続が構築され、且つバインディング更新を終了する等の過程の終了に伴って取り消されず、マルチキャストソースが外界へ送信するデータはずっと当該双方向トンネルを介してマルチキャスト受信ノードに伝送される。当該モードを用いることにより、マルチキャストソースMNの移動速度が早すぎることによってMAGの間の切り替えによるマルチキャストツリーの頻繁なばらし、構築を減少することができ、ネットワークの資源ロスが回避され、マルチキャストの転送効率が向上される。

【0042】

（3）SPT且つマルチキャストツリー予備更新モード
マルチキャストソースMNがMAG1にアクセスする際にSPTモードを用いてマルチキャストデータを伝送する。この際に、マルチキャストソースの移動速度が遅い（例えば、設定閾値以下である）と、当該マルチキャストソースMNがMAG2に切り替えられた後に、SPTモードを使用し続けてマルチキャストデータを伝送する必要がある。この際に、マルチキャストツリーを予備更新する必要があり、当該切り替え後のマルチキャストモードを、SPT且つマルチキャストツリー予備更新モードと称する。

【0043】

このモードでは、MAGIは、MAG2がフィードバックした双方向トンネルを構築する返信メッセージを受信した後に、マルチキャストツリーの予備更新過程を発動する必要がある。当該マルチキャストツリーの予備更新過程は、主に、MAG1がマルチキャストデータパケットにマルチキャストソース切り替えオプションを有することを含み、当該オプションには、マルチキャストソース切り替え指示やMAG2のアドレス等の情報が含まれる。マルチキャストデータパケットが古いマルチキャストツリー上で伝達されることに伴って、マルチキャストソースオプションがマルチキャストツリーにおけるルータへ、間もなく発生するマルチキャストソース切り替え、及び切り替え後のMAG2のアドレスを通知することにより、マルチキャストツリーの予備更新を触発する。ここで、古いマルチキャストツリーとは、マルチキャストソースMNがMAG1にアクセスする際に構築した、マルチキャストデータを伝送するためのマルチキャストパスを指す。新しいマルチキャストツリーが更新済みで、且つマルチキャストソースMNがMAG2においてバインディング更新等の過程を終了した後に、マルチキャストデータは、新しいマルチキャストツリーを介してマルチキャスト受信ノードに送信される。ここで、新しいマルチキャストツリーとは、マルチキャストソースMNがMAG2にアクセスする際に構築した、マルチキャストデータを伝送するためのマルチキャストパスを指す。

【0044】

当該SPT且つマルチキャストツリー予備更新モードに基づいて、マルチキャストソースとMAG2との接続が構築されており、且つバインディング更新等の過程を終了する前に、マルチキャストデータを、MAG1及びMAG2との間に構築された双方向トンネルを介して転送することができる。即ち、マルチキャストデータが、マルチキャスト受信者に対応するマルチキャスト受信ノードに送信される際に通るパスは、
Source→MAG2→MAGl→マルチキャストツリー（古いマルチキャストツリー）である。

【0045】

マルチキャストソースとMAG2との接続が構築されており、バインディング更新等の過程を終了した後に、マルチキャストデータがマルチキャスト受信者に対応するマルチキャスト受信ノードに送信される際に通るパスは、
Source→MAG2→マルチキャストツリー（新しいマルチキャストツリー）である。

【0046】

以上定義された切り替え後のマルチキャストモード、及び相応するデータ伝送パスによれば、本発明の実施例一が提供したマルチキャストデータを伝送する方法は、図3に示すように、主に、以下のステップを含む。
ステップ301：MAG1は、マルチキャストソースMNが現在アクセスしているMAG1からMAG2に切り替わる前に送信した切り替え予告メッセージを受信し、当該切り替え予告メッセージはMAG2の標識情報を有する。

【0047】

ステップ302：MAG1は、当該切り替え予告メッセージが有するMAG2の標識に基づいて、MAG2との間の双方向トンネルを構築する。

【0048】

ステップ303：特定した切り替え後のマルチキャストモード及び、構築した双方向トンネルに基づいて、マルチキャストソースからのマルチキャストデータに対してマルチキャストを行う。
当該ステップ303において、特定した切り替え後のマルチキャストモードが異なることによって、当該ステップ303に用いるマルチキャストデータを伝送する具体的方式が異なる。当該過程は、後続の実施例で詳細に記載し、ここで記述しない。

【0049】

ここまでで、マルチキャストソースの移動でアクセス変更の必要があるMAGが変更する際に対応する、マルチキャストデータを伝送するフローが終了する。

【0050】

上記のフローが具体的に実現される際には、主に、マルチキャストソースMNは、移動ニーズでMAGを切り替える必要がある際にマルチキャストデータを伝送するシーンに応用される。具体的には、マルチキャストソースMNがMAG1からMAG2に切り替えられる必要がある際に、MAG1とMAG2との間で双方向トンネルを構築する必要があり、当該双方向トンネルを構築するフローは、図4に示すように、主に、以下の通りのステップを含む。
ステップ401：切り替えが発生する前に、マルチキャストソースMNがMAG1に接続され、採用されたマルチキャストモードに従ってマルチキャストデータを伝送する。
当該ステップ401において、RPTモードを用いてマルチキャストデータを伝送すると、マルチキャストデータは、マルチキャストソースMNからMAG1に送信され、その後、LMA に( LMAが RPランデブーポイントとする）伝送されて、LMAからマルチキャスト受信者に転送される。SPTモードを用いてマルチキャストデータを伝送すると、マルチキャストデータは、直接に、構築したSPTに基づいてマルチキャストソースからマルチキャスト受信者に転送される。

【0051】

ステップ402：マルチキャストソースMNは、間もなく切り替えが発生することを特定し、MAG1へマルチキャストソースMNのID及びMAG2のIDを報告する。
当該ステップ402において、マルチキャストソースMNが、間もなく切り替えが発生することを特定する。即ち、間もなく現在アクセスしているMAG1からMAG2に切り替えられ、つまり、マルチキャストソースMNが、MAG1の位置するネットワークのカバー領域からMAG2の位置するネットワークのカバー領域に移動することを特定する。

【0052】

ステップ403：MAG1は、拡張後のHIメッセージ（Handover Initiate Message：切り替え初期化メッセージ)をMAG2に送信する。
当該ステップ403において、MAG1が送信したHIメッセージに、マルチキャストソース切り替えの指示情報と、マルチキャストソース標識と、切り替え後のマルチキャストモードの指示情報と、マルチキャストグループアドレスと、マルチキャストソースホームアドレスとを含む。さらに、当該HI メッセージが指示するマルチキャストモードがRPTモードである場合に、当該HIメッセージは、RPアドレスをさらに含む。

【0053】

ステップ404：MAG2がHIメッセージを受信した後に、HAckメッセージ（Handover Acknowledge message：切り替え返信メッセージ）をMAG1に送信する。
当該ステップ404において、HAckメッセージには、MAG2がマルチキャストソース切り替えを受けるかどうかの指示が含まれる。実際の応用において、MAG2は、ローカル・ポリシー、マルチキャストソース切り替えをサポートせず、負荷が重すぎる等の原因によってマルチキャストソース切り替えを拒否する可能性がある。MAG2がマルチキャストソース切り替えに同意すると、MAG1とMAG2との双方向トンネルが構築される。

【0054】

ここまでで、MAG1とMAG2との間に双方向トンネルを構築するフローが終了する。

【0055】

さらに、本発明の好適な実施例において、切り替え後のマルチキャストモードがRPTモードであると特定すると、MAG2は、MAG1の送信するHIメッセージを受信した後に、予め当該HIメッセージに含まれるRPアドレスに基づいて、それと当該RPに対応するLMAとのマルチキャストパスを更新することができる。MAG2とLMAとの間のマルチキャストパスの予備更新により、マルチキャストソースがMAGを切り替えた後に引き起こされるマルチキャスト時間遅延がさらに短縮される。

【0056】

本発明の実施例において、上記フローに係るHIメッセージ及びHAckメッセージは、拡張後のメッセージであり、以下、HIメッセージ及びHAckメッセージの拡張方式について、詳細に説明する。

【0057】

本発明の拡張後のHIメッセージには、今回の切り替えがマルチキャスト切り替えであり、且つマルチキャストソース切り替えであることを示すための指示ビットが追加される。なお、拡張後のHIメッセージは、マルチキャストソースMNの標識と一つの拡張の移動オプション（Mobility options)をさらに含む。当該移動オプションは、切り替え後のマルチキャストモード選択ビット（RPTモード、SPT且つ不更新マルチキャストツリーモード、SPT且つマルチキャストツリー予備更新モードの何れかに対応する）、マルチキャストグルールアドレス（選択できる）、RPアドレス（選択できる）、マルチキャストソースホームアドレス（選択できる）を含む。

【0058】

RFC5568は、FMIPv6プロトコルがユニキャストノードに用いる快速切り替えの方案を定義し、プロトコルにおいて、HI/HAckメッセージを定義し、古いアクセスルータと新しいアクセスルータとの間にトンネルを構築し、コンテクスト、例えば、マルチキャストソースMN の標識、Ipv4ホームアドレス等を伝送するためのものである。IETFMipshopワークグループは、PMIPv6における快速切り替え方案を研究し、FMIPv6プロトコルを拡張し、HI/HAckメッセージを新たに定義し、本発明の実施例は、この上にさらにHI/HAckメッセージを拡張して、本発明の実施例に係るMAG1及びMAG2との間の双方向トンネルを構築する目的を実現するようにする。

【0059】

具体的には，HIメッセージ及びHAckメッセージについての拡張説明は、以下の通りである。
（1）HIメッセージの拡張説明
HIメッセージは、MAG1からMAG2に送信され、マルチキャストソースMNの切り替え過程を発動するためのものである。

【0060】

従来技術の定義したHIメッセージの基本的メッセージフォーマットは、図5に示すように、対応するその中のフィールドの説明は以下の通りである。

【0061】

【表1】

【0062】

本発明の実施例が提供する技術方案に基づいて拡張後のHIメッセージの基本的メッセージフォーマットは、図6に示すように、当該拡張後のHIメッセージには、元のHIメッセージに新しいマークビットM、Rが追加され、且つMobility Options(移動オプション）に新しく定義したマルチキャストソース切り替えオプションが追加されることにより実現される。
Mビット：移動マルチキャスト切り替え要請を示す。
Rビット：マルチキャスト受信者の切り替えであるかマルチキャストソースの切り替えであるかを示す。
M=0、R=0:ユニキャストノードの快速切り替え。
M=l、R=l:マルチキャスト受信者ノードの快速切り替え。
M=l、R=0:マルチキャストソースの快速切り替え。
M=0、R=l:不適当。

【0063】

上記定義に基づいて、HIメッセージにおけるM=l、R=0である場合は、マルチキャストソース切り替えを示す。この際に、Mobility optionsにおいて新しく定義したマルチキャストソース切り替えオプションを含む必要がある。具体的には、図7に示すように、主に、以下の通りのフィールドを含む。
Option-Code(マルチキャストオプション）であって、切り替え後のマルチキャストモードを示すためのものであり、例えば、「0」は、切り替え後のマルチキャストモードがRPTモードであることを示し、「1」は、切り替え後のマルチキャストモードがSPT且つ不更新マルチキャストツリーモードであることを示し、「2」は、切り替え後のマルチキャストモードがSPT且つマルチキャストツリー予備更新モードであることを示すように定義される。
Multicast Address(マルチキャストグループアドレス)、
Multicast Source Home Address(マルチキャストソースホームアドレス）、即ち、マルチキャストソースがマルチキャストデータパケットを送信する際に使用するアドレスである。
RP Address(RPのアドレス）、当該フィールドは、Option-Code=0である場合に、即ち、RPTモードを選択する場合に存在する。

【0064】

（2）HAckメッセージの拡張説明
HAckメッセージは、MAG2からMAG1に送信され、MAG1の送信するHIメッセージに対して返信するためのものである。

【0065】

従来技術に定義されたHAckメッセージの基本的メッセージフォーマットは、図8に示すようで、対応するその中のフィールドの説明が以下の通りである。

【0066】

【表2】

【0067】

本発明の実施例が提供する技術方案によれば、拡張後のHAckメッセージの基本的メッセージフォーマットは、図9に示すように、拡張後のHAckメッセージは、元のHAckメッセージに新しいマークビットM、Rが追加されている。HIメッセージに対する返信を示すためのものである。なお、M、Rビットの定義は、拡張のHIメッセージにおけるM、Rの定義と同じであるので、ここでは繰り返さない。

【0068】

図3に記載のフローのステップ303において、特定した切り替え後のマルチキャストモード及び構築された双方向トンネルに基づいて、マルチキャストソースからのマルチキャストデータに対してマルチキャストを行う際に、特定した切り替え後のマルチキャストモードが異なることによって、具体的な処理過程は異なる。以下、上記三つの異なるマルチキャストモードについて、当該過程を詳細に説明する。

【0069】

一、切り替え後のマルチキャストモードがRPTモードである場合にマルチキャストデータを伝送するフロー
RPTモードでは、MAG1は、RPアドレスをMAG2に伝達する必要があり、MAG2は、RPまでのパスを構築する。マルチキャストソースMNとMAG2との接続が構築され、且つバインディング更新等の過程が終了した後に、マルチキャストデータの通るパスは、Source(即ち、マルチキャストソース）→MAG2→LMA(RP)→マルチキャストツリーからマルチキャスト受信ノードへの伝送、である。

【0070】

図10に示すように、RPTモードでのマルチキャストデータの伝送は、主に、以下の通りのステップ（当該フローは上記図4に記載の双方向トンネル構築のフローに続く）を含む。
ステップ1001：マルチキャストソースMNは、MAG1との接続を切断し、切り替え過程（即ち、MAG2にアクセスする)を開始する。

【0071】

ステップ1002：マルチキャストソースMNがMAG2に接続して、マルチキャストデータが、マルチキャストソースMNからMAG2に送信され、MAG2とMAG1との双方向トンネルを介して古いマルチキャストツリーに伝送され、当該古いマルチキャストツリーによりマルチキャスト受信者に送信される。
ここで、古いマルチキャストツリーとは、当該マルチキャストソースMNがMAG1にアクセスする際にマルチキャストデータを伝送するためのマルチキャストパスを指す。

【0072】

ステップ1003：MAG2は、現在のフローに基づいてLMAへ拡張のバインディング更新メッセージ（PUBメッセージ）を送信し、MAG2とLMAとのトンネルを更新し、LMAをマルチキャストソースのRPとすることを要請する。

【0073】

ステップ1004：マルチキャストソースMNとRP(LMA)とのパス更新を終了し、マルチキャストデータは、source(即ち、マルチキャストソースMN)→MAG2→LMA(RP)→マルチキャストツリーのようなパスに沿って転送され始める。

【0074】

ステップ1005：MAG2とMAGIとのトンネルが取り消され、MAG1がLMAへマルチキャストソースMNとのバインディングを解除するPBUメッセージが送信される。

【0075】

ここまでで、RPTモードでマルチキャストデータを伝送するフローは、終了する。

【0076】

上記フローによれば、マルチキャストソースMNがMAG2にアクセスした後にマルチキャストデータに用いるマルチキャストパスの構築が終了する前に、即ち、マルチキャストソースMNとRP(LMA)とのパス更新が終了する前に、MAG1は、構築した双方向トンネルを介してMAG2の転送するマルチキャストソースMNのマルチキャストデータを受信し、マルチキャストソースがアクセスする際に構築したマルチキャストパスに基づいて当該マルチキャストデータを伝送する。マルチキャストソースがMAG2にアクセスした後にマルチキャストデータに用いるマルチキャストパスの構築が終了した後に、MAG2とRP(LMA)との間のパスを用いてマルチキャストデータを伝送し、MAG1とMAG2との間に構築された双方向トンネルを取り消す。

【0077】

二、切り替え後のマルチキャストモードがSPT且つ不更新マルチキャストツリーモードである場合にマルチキャストデータを伝送するフロー
図11に示すように、SPT且つ不更新マルチキャストツリーモードでのマルチキャストデータの伝送は、主に、以下の通りのステップ（当該フローが上記図4に記載の双方向トンネル構築のフローに続く）を含む。
ステップ1101：マルチキャストソースMNは、MAG1との接続を切断し、切り替え過程を開始する。

【0078】

ステップ1102：マルチキャストソースMNがMAG2に接続され、マルチキャストデータは、マルチキャストソースMNからMAG2送信されてから、MAG2とMAG1との双方向トンネルを介して古いマルチキャストツリーに伝送され、当該古いマルチキャストツリーによりマルチキャスト受信者に送信される。

【0079】

ステップ1103：MAG2は、LMAへPMIPv6が正常であるバインディング更新メッセージを送信し、MAG2とLMAとのトンネルを更新する。

【0080】

この際、MAG1とMAG2とのトンネルは取り消されず、マルチキャストソースが外界へ発信するデータは、相変わらずSource(マルチキャストソースMN)→MAG2→MAG1→マルチキャストツリーのようなパスでマルチキャスト受信ノードに伝送される。

【0081】

当該SPT且つ不更新マルチキャストツリーモードでは、マルチキャストソースMNの移動速度が速いので、MAG1が選択され終始マルチキャストツリーのルートノードとされ、マルチキャストソースMNの新しくアクセスしたMAGとのトンネルの構築を保持する。マルチキャストソースMNから再び切り替えが送信された場合には、MAG2からMAG3に切り替え、マルチキャストソースMNがMAG3のアドレスをMAG1に通知し、MAG1がMAG3との双方向トンネルを新たに構築し、上記フローを繰り返してMAG3の転送するマルチキャストソースMNのマルチキャストデータを伝送する。MAG1がMAG3との双方向トンネルを構築した後にMAG2との双方向トンネルを取り消す必要がある。

【0082】

当該SPT且つ不更新マルチキャストツリーモードでは、マルチキャストソースとMAG2との接続を構築し、且つバインディング更新等の過程を終了する前及び後に、マルチキャストデータがマルチキャスト受信者に対応するマルチキャスト受信ノードに送信される際に通るパスは、
Source (マルチキャストソース）→MAG2→MAG1→古いマルチキャストツリーである。

【0083】

当該方式によれば、マルチキャストツリーを再構築する必要がなく、マルチキャストツリー構築の操作が減少される。

【0084】

三、切り替え後のマルチキャストモードがSPT且つマルチキャストツリー予備更新モードである場合にマルチキャストデータを伝送するフロー
図12に示すように、SPT且つマルチキャストツリー予備更新モードでのマルチキャストデータの伝送は、主に、以下の通りのステップ（当該フローは上記図4に記載の双方向トンネル構築のフローに続く）を含む。
ステップ1201：MAG1がマルチキャストツリー予備更新の過程を発動し、当該マルチキャストツリー予備更新過程は、以下の実施例で詳細に記述される。ここで記述しない。

【0085】

ステップ1202：マルチキャストソースMNは、MAG1との接続を切断し、切り替え過程を開始する。

【0086】

ステップ1203：マルチキャストソースMNがMAG2に接続され、マルチキャストデータは、マルチキャストソースMNからMAG2に送信され、そしてMAG2とMAG1との間の双方向トンネルを介して古いマルチキャストツリーに伝送されて、当該古いマルチキャストツリーによりマルチキャスト受信者に送信される。

【0087】

ステップ1204：MAG2は、LMAへPMIPv6が正常であるバインディング更新メッセージを送信する。

【0088】

ステップ1205：マルチキャストソースMNのバインディング更新及びマルチキャストツリーの更新とも既に終了し、マルチキャストデータが新しいマルチキャストツリーに沿って転送され始める。

【0089】

ステップ1206：MAG2とMAG1との間のトンネルが取り消され、MAG1は、LMAへ、マルチキャストソースMNとのバインディングを解除するPBUメッセージを送信する。

【0090】

ここまでで、SPT且つマルチキャストツリー予備更新モードでマルチキャストデータを伝送するフローは、終了する。

【0091】

上記フローによれば、マルチキャストソースがMAG2にアクセスした後にマルチキャストデータに用いるマルチキャストパスの構築が終了する前に、MAG1は、構築した双方向トンネルを介して、MAG2の転送するマルチキャストソースのデータを受信し、且つマルチキャストソースがアクセスする際に構築したマルチキャストパスに基づいて、当該データに対してマルチキャストを行う。同時に、マルチキャストツリーの予備更新フローを行い、マルチキャストソースがMAG2にアクセスした後にマルチキャストデータに用いるマルチキャストパスの構築が終了した後に、新しいマルチキャストパス（即ち、更新後のマルチキャストツリー）を用いてマルチキャストデータが伝送される。

【0092】

以下、本発明の実施例に係るマルチキャストツリー予備更新フローを詳細に説明する。
マルチキャストツリー予備更新過程は、MAG1がMAG2の送信するHAckメッセージを受信した後に発動される。即ち、MAG1は、マルチキャストソースがアクセスする際に構築したマルチキャストパス及びMAG2のアドレスに基づいて、当該マルチキャストソースがMAG2にアクセスした後にマルチキャストデータに用いるマルチキャストパスを構築することを触発し、即ち、マルチキャストツリー更新過程を触発する。具体的には、MAG1が双方向トンネルを介して受信したデータパケット、又はマルチキャストソースが直接に送信したデータパケットにおいて、マルチキャストソース切り替え指示及びMAG2のアドレス情報を付加し、且つマルチキャストソースがアクセスする際に構築したマルチキャストパス（即ち、古いマルチキャストツリー）に基づいて、マルチキャストソース切り替え指示及びMAG2のアドレス情報を有するデータパケットを送信する。具体的には、データパケットのIpv6ホップバイホップのオプションヘッダーにマルチキャストソース切り替え指示及びMAG2のアドレス情報を有することができる。

【0093】

従来のPMIPv6では、ノードが PMIPv6ドメイン内を移動する際にIPアドレスが変わらない。そうすると、マルチキャストソースが新しいMAGに移動した後に、相変わらず同じIPアドレスを使用し続けてマルチキャストデータが送信される。システムにおいて需要駆動、明示的アクセスの方法を採用してマルチキャストツリーを再構築すると、マルチキャスト受信ノードが、移動ノードが切り替えられたことを知らないので、アクセスメッセージを新たに送信しない。よって、マルチキャストツリーを再構築することができない。データ駆動、拡散剪定の方式を採用してマルチキャストツリーを再構築すると、新しいMAGにより送信されたマルチキャストデータパケットがRPF検査を通らず、よって、マルチキャストツリーを再構築することができない。このような問題について、本発明の実施例は、PMIPv6環境においてSPTツリーを更新する方法を提出する。

【0094】

図13に示すように、マルチキャストソース（source)がアクセスポイント1からアクセスポイント2に移動した際にそれぞれ対応するマルチキャストツリー（即ち、マルチキャストパス）であって、なお、パス：アクセスポイント1に対応するDR→Routerl(ルート1)→Router2→Router3→DRであり、マルチキャストソースが切り替える前のマルチキャストツリー、即ち、マルチキャストソースがアクセスポイント1にアクセスする際のマルチキャストパスを代表する。パス：アクセスポイント2に対応するDR→Router4→Router2→Router3→DRであり、予備更新後のマルチキャストツリー、即ち、マルチキャストソースがアクセスポイント2にアクセスした後のマルチキャストパスを代表する。図13から分かるように、マルチキャストツリーに関連するルータは、以下の四種に分けることができ、
1、古いマルチキャストツリーにあるが、新しいマルチキャストツリーにはないもの。例えば、Router1である。
2、古いマルチキャストツリーにもあり、新しいマルチキャストツリーにもあるが、マルチキャストデータを受信するインターフェースが変わっているもの。例えば、Router2である
3、古いマルチキャストツリーにもあり、新しいマルチキャストツリーにもあり、且つマルチキャストデータを受信するインターフェースが変わらないもの。例えば Router3である。
4、古いマルチキャストツリーにはないが、新しいマルチキャストツリーにあるもの。例えば、Router4である。

【0095】

本発明の実施例に基づいて、MAG1は、MAG2がマルチキャストソース切り替えをサポートすることに関する同意メッセージ（HAckメッセージ）を取得した後に、MAG1は、すぐ、マルチキャストツリーの予備更新過程を起動し、マルチキャストソースとMAG2との接続の構築を待つ必要がない。こうする目的は、時間を取得してできるだけ早くマルチキャストツリーを更新するためであり、マルチキャストソースがマルチキャストツリー更新を待つ時間を減らすためである。従来の方法においては、マルチキャストツリーの更新によって、必ず、古いマルチキャストツリーの使用に影響を及ぼし、新しいマルチキャストツリーが古いマルチキャストツリーの廃棄につながる。これは、マルチキャスト快速切り替えにとって望ましくなく、予備更新マルチキャストツリーの過程で、古いマルチキャストツリーを使用してマルチキャストデータを送信して、マルチキャストサービスの停止時間遅延を低減する目的を達することが望ましい。

【0096】

以上の困難を克服するために、本発明の実施例が提供する技術方案においては、マルチキャストツリー予備更新が行なわれる際に、依然として古いマルチキャストツリーからデータを受信することができる。この目的を実現するために、本発明は、マルチキャストルータに保存した（S、G）ルート状態を拡張して、各マルチキャストソースに対応するマルチキャストルートが、二つのマルチキャストデータを受信するインターフェースを有するようにした。すなわち、
データ受信インターフェースActiveInterface、及び
予備切り替えインターフェースpre-handoverInterfaceである。

【0097】

なお、
ActiveInterfaceは、切り替える前に使用するマルチキャストデータを受信するインターフェースであり、即ち、ルータからマルチキャストソースの古いアクセスポイントMAG1へのRPFインターフェースである。ここで、古いアクセスポイントとは、マルチキャストソースMNが切り替える前にアクセスされるMAG1を指す。マルチキャストツリー予備更新過程において、ルータは、ずっと、このインターフェースにより古いマルチキャストツリーからマルチキャストデータを受信する。
Pre-handoverInterfaceは、ルータからマルチキャストソースの新しいアクセスポイントMAG2へのRPFインターフェースである。ここで，新しいアクセスポイントとは、マルチキャストソースMNが切り替えられた後にアクセスされるMAG2を指す。切り替えられる前に、pre-handoverInterfaceは、空きに設置される。予備更新過程で、ルータからMAG2へのRPFインターフェースに設置される。マルチキャストデータがこのインターフェースを介して到達する場合に、新しいマルチキャストツリーが既に動作し始めたことを説明し、このインターフェースがActiveInterfaceにアップグレードする。

【0098】

また、本発明の実施例においては、リーフルータ（即ち、マルチキャストツリーにおけるマルチキャストノード）がMAG2へのマルチキャストアクセス要請を発動する場合に、マルチキャストソースのIPアドレスは変わらないので、一般的方式でアクセスメッセージを送信すると、問題がある。途中のルータがMAG2に向く方向へこのアクセスメッセージを転送するように通知するために、ルータは、Join（S、G）メッセージをMAG2を目的アドレスとするIPデータパケットにパッケージングする必要があり、このIPデータパケットのオプションヘッダーにおいて、マルチキャストソース切り替えオプションを含んでいるホッ プバイホップのオプションヘッダーを有する必要がある。

【0099】

図14に示すように、マルチキャストツリー更新の具体的過程は、主に、以下の通りのステップを含む。
ステップ1401：切り替えが開始する前に、マルチキャストツリールータのうち、（S、G）状態のActiveInterfaceが、ルータからマルチキャストソースの古いアクセスポイントMAG1へのRPFインターフェースに設置され、pre-handoverInterfaceが、空きに設置される。

【0100】

ステップ1402：MAG1は、マルチキャストツリー予備更新過程を発動し、マルチキャストデータのIpv6ホップバイホップのオプションヘッダーに、本発明の拡張のマルチキャストソース切り替えオプションを添加し、オプションにおいて、マルチキャストソース切り替え指示及び、マルチキャストソースがアクセスしようとするMAG2のアドレスを含む。
当該ステップ1402において、拡張のマルチキャストソース切り替えオプションは、以下で詳細に説明するので、ここでは記述しない。

【0101】

ステップ1403：マルチキャストソース切り替えオプションを有しているデータパケットが第1のマルチキャストノードに到達した時に、第1のマルチキャストノードは、マルチキャストツリーを生成するためのアクセスメッセージを構築し、当該データパケットに付加されているMAG2のアドレス情報を、アクセスメッセージに付加して、転送する。

【0102】

ステップ1404：当該アクセスメッセージを受信した第2のマルチキャストノードは、当該アクセスメッセージが有するMAG2のアドレス情報に基づいてマルチキャストルートを更新し、新しいマルチキャストツリーにアクセスが成功するまで、即ち、MAG2のアドレス情報に基づいてマルチキャストルートを更新した後のマルチキャストノードが当該アクセスメッセージを受信するまで、続けて当該アクセスメッセージを転送する。
当該ステップ1404において、アクセスメッセージがMAG2に到達した後に、この時のマルチキャストソースMNが未だMAG2に接続されていない場合には、MAG2がマルチキャストソースMNに代わって当該アクセスメッセージを処理する。具体的処理過程は、PIM-SMプロトコル(即ち、RFC4601の内容）に従い、ここでは詳細に記述しない。

【0103】

上記ステップの処理が終了した後に、ネットワークにおいて、予め、一つの、マルチキャストソースの新アクセスポイントMAG2を根とするマルチキャストツリーを構築し、この予備更新のマルチキャストツリーにおいて、全てのルータ（S、G）状態のpre-handoverInterfaceとも、ルータからマルチキャストソースの新アクセスポイントMAG2へのRPFインターフェースに設置される。

【0104】

ここまでで、マルチキャストツリー更新フローは、終了する。

【0105】

図14に記載のフローに含まれるステップ1403において、第1のマルチキャストノードがMAG2のアドレス情報をアクセスメッセージに付加して、転送することは、具体的に、以下の通りの過程による。
第1のマルチキャストノードは、当該アクセスメッセージをMAG2のアドレスを目的アドレスとするデータパケットにパッケージングする。当該データパケットはマルチキャストソース切り替え指示を有する。
設定した上流近隣ルータアドレスに基づいて、マルチキャストソース切り替え指示を有するデータパケットを転送する。

【0106】

図14に記載のフローに含まれるステップ1404において、当該アクセスメッセージを受信した第2のマルチキャストノードは、当該アクセスメッセージが有するMAG2のアドレス情報に基づいてマルチキャストルートを更新する。即ち、アクセスメッセージが有するMAG2のアドレス情報に基づいて、マルチキャストルート状態での Pre-handoverinterfaceを、MAG2へのRPFインターフェースに設置する。具体的には、マルチキャストルートを更新する過程は、図15に示すように、以下の通りのステップを含む。
ステップ1501：第2のマルチキャストノードは、Ipv6メッセージオプションヘッダーにおけるマルチキャストソース切り替えオプションを解析して、その中に有するMAG2のアドレスを取得する。

【0107】

ステップ1502：第2のマルチキャストノードは、自身にこのマルチキャストサービスに対応するマルチキャストルート状態があるかどうかを判断し、「YES」であると、ステップ1503を実行し、「NO」であると、ステップ1504を実行する。
当該ステップ1502において、判断結果が「YES」であると、以上に記載のRouter2、3タイプ、即ち、古いマルチキャストツリーにもあり、新しいマルチキャストツリーにもあるルータに対応し、判断結果が「NO」であると、以上に記載のRounter4タイプ、即ち古いマルチキャストツリーにはないが、新しいマルチキャストツリーにあるものに対応する。なお、Rounter1は当該アクセスメッセージを受信できない。

【0108】

ステップ1503：このマルチキャストサービスに対応するマルチキャストルート状態でのPre-handoverinterfaceを、MAG2へのRPFインターフェースに設置し、Activeinterfaceの状態を保持する。

【0109】

ステップ1504：このマルチキャストサービスに対応するマルチキャストルート状態を作成し、且つPre-handoverinterfaceの状態を、MAG2へのRPFインターフェースに設置し、Activeinterfaceの状態を空きに設置する。

【0110】

ここまでで、マルチキャストルートを更新するフローは、終了する。

【0111】

上記フローが終了した後に、第2のマルチキャストノードは、続いてMAG2の上流方向に向かって当該Joinデータパケットを転送する。具体的には、当該joinデータパケットを転送する際に、設定した上流近隣ルータアドレスに基づいて転送する。

【0112】

図14に記載のフローに係る拡張のマルチキャストソース切り替えオプションがIPデータパケットのオプションヘッダーに付加される。具体的には、IPv6ホップバイホップのオプションヘッダーがRFC2460により定義されて、そのフォーマットは図16に示すように、options(オプション）フィールドにおいて、本発明は、以下の通りの新しいオプションを定義する。すなわち、
マルチキャストソース切り替えオプションである。
マルチキャストソース切り替えオプションは、マルチキャストソースに間もなく切り替えが発生することを示し、その中には、マルチキャストソースの新アクセスポイントMAG2のアドレスが含まれる。具体的には、本発明の実施例に定義されたマルチキャストソース切り替えオプションは、図17に示すように、
Hは、マルチキャストソース切り替え指示を示し、
New access point's Addressは、マルチキャストソースの新アクセスポイントMAG2のアドレスを示す。
他のフィールドは、従来フィールドの意味と同じなので、ここで重複しない。

【0113】

図14に記載のフローの実行過程において、マルチキャストデータは、ずっと、古いマルチキャストツリーを介した、マルチキャスト受信ノードへの到達を保持する。マルチキャストソースがMAG2でバインディング更新等の操作を終了した後に、マルチキャストデータは、新しいマルチキャストツリーに沿って転送され始め、（S,G）状態のpre-handoverInterfaceインターフェースから各ルータへの到達を開始する。

【0114】

新しいマルチキャストツリー上のルータが、初めてpre-handoverInterfaceインターフェースからマルチキャストデータを受信した時に、新しいマルチキャストツリーが使用され始めたことが証明され、マルチキャストルータをさらに更新する必要がある。具体的に、図18に示すように、以下の通りのステップを含む。
ステップ1801：マルチキャストルート状態でのActiveInterface状態が空きかどうかを判断し、「YES」であると、ステップ1804を実行し、「NO」であると、ステップ1802を実行する。
当該ステップ1801において、判断結果が「YES」であると、上記の Router4タイプ、即ち、古いマルチキャストツリーにはないが、新しいマルチキャストツリーにあるルータに対応する。

【0115】

ステップ1802：マルチキャストルート状態での ActiveInterfaceとPre-handoverInterfaceが同じかどうかを判断し、「YES」であると、ステップ1804を実行し、「NO」であると、ステップ1803を実行する。
当該ステップ1802において、判断結果が「YES」であると、上記のRouter3タイプに対応し、即ち古いマルチキャストツリーにもあり、新しいマルチキャストツリーにもあるルータに対応し、判断結果が「NO」であると、上記のRouter2タイプ、即ち古いマルチキャストツリーにもあり、新しいマルチキャストツリーにもあるルータに対応する。

【0116】

ステップ1803：ActiveInterfaceの方向へ剪定メッセージを送信し、当該ルータをマルチキャストツリーから剪定する。

【0117】

ステップ1804：Pre-handoverInterfaceの状態に基づいてActiveInterfaceの状態を設置し、且つPre-handoverInterfaceの状態を空きに設置する。

【0118】

ここまで、新旧マルチキャストツリーの交替仕事が終了し、マルチキャストデータは、新しいマルチキャストツリーに沿って転送される。

【0119】

図18に記載のフローにより、第2のマルチキャストノードがアクセスメッセージの有するMAG2のアドレス情報に基づいてマルチキャストルートを更新した後に、初めて、Pre-handoverInterfaceによりデータを受信すると、ActiveInterface状態が空き、又は、ActiveInterfaceとPre-handoverInterfaceとが同じである場合に、Pre-handoverInterfaceをActiveInterface(即ち、Pre-handoverInterfaceの状態に基づいてActiveInterfaceの状態を設置する）にアップグレードし、Pre-handoverInterfaceの状態を空きに設置する。

【0120】

本発明の実施例が提供する上記技術方案によれば、MAG1(マルチキャストソース切り替えの前にアクセスするMAG)、MAG2(マルチキャストソース切り替えの後にアクセスするMAG)及びマルチキャストツリー予備更新過程でのマルチキャストルータは、相応して改善する必要がある。具体的には、MAG1、MAG2及びマルチキャストルータ上の操作は、それぞれ、以下の通りである。

【0121】

一、MAG1上の操作は、主に、以下の通りの方面を含む。
（1）MAG1は、マルチキャストソースMNの送信した切り替え予告メッセージを受信した後に、当該マルチキャストソースMNのID及びMAG2のIDを抽出する。マルチキャストソース切り替え後のマルチキャストモードを特定し、マルチキャストグループのアドレス、RPアドレス（RPTモードを選択する時に）、マルチキャストソースホームアドレス等の情報を用意して伝送を待つ。
（2）MAG1が拡張のHIメッセージをMAG2に送信し、当該拡張のHIメッセージにおいて、指示ビットはM=l、R=0であって、当該切り替えがマルチキャスト切り替えであり、且つマルチキャストソース切り替えであることを示す。また、拡張後のHIメッセージにおいて、マルチキャストソースMNのIDと一つの拡張の移動オプションを含む。当該拡張の移動オプションにおいて、切り替え後のマルチキャストモード選択ビット、マルチキャストグループアドレス、RPアドレス（RPTモードを選択する時に）、マルチキャストソースホームアドレス等の情報を含む。
（3）MAG2から戻ったHAckメッセージを受信し、MAG2との間にマルチキャストデータを伝送するための双方向トンネルを構築する。
（4）MAG2が双方向トンネルを介して転送してきたマルチキャストデータを受信し、切り替え前のマルチキャストモードに従ってマルチキャストデータを転送する。
（5）切り替え後のマルチキャストモードによって、異なる操作を行う。
RPTモードでは、マルチキャストソースが新しい位置でのマルチキャストツリーの更新を終了した後に、MAG1がMAG2の通知を受け、MAG1からMAG2までの双方向トンネルを取り消し、LMAへマルチキャストソースMNとのバインディングを解除するPBUメッセージを送信する。
SPT且つ不更新マルチキャストツリーモードでは、MAG1とMAG2との間のトンネルが取り消されず、マルチキャストソースが外界へ発信するデータは、相変わらずSource→MAG2→MAG1→マルチキャストツリーのようなパスで、マルチキャスト受信ノードに伝送される。マルチキャストソースの移動速度が速いので、MAG1がずっとマルチキャストツリーのルートノードとして、マルチキャストソースMNの最も新しいアクセスポイントMAG2との間のトンネルの構築を保持する。マルチキャストソースMNが、第二回、第三回... ...と移動する際に、現在のトンネルを介して次のアクセスポイントのアドレスをMAGIに通知し、MAG1がそれとマルチキャストソースMNの新アクセスポイントMAGとの間のトンネルを循環的に構築し、マルチキャストデータが新しいトンネルを介してMAG1に伝送され、さらに、マルチキャストツリー上に伝送される。MAG1とマルチキャストソースMNの前のアクセスポイントとのトンネルは、取り消される。
SPT且つマルチキャストツリー予備更新モードでは、MAG1がマルチキャストツリー予備更新過程を発動する。MAG1は、マルチキャストデータのIpv6ホップバイホップのオプションヘッダーに本発明の拡張のマルチキャストソース切り替えオプションを添加し、オプションには、マルチキャストソース切り替え指示、及びマルチキャストソースがアクセスするMAG2のアドレスが含まれる。マルチキャストソースが新しい位置でのマルチキャストツリー更新が終了した後に、MAG1がMAG2の通知を受けて、MAG1からMAG2までの双方向トンネルを取り消し、LMAへマルチキャストソースMNとのバインディングを解除するPBUメッセージ送信する。

【0122】

二、MAG2上の操作は、主に、以下の通りの方面を含む。
（１）MAG2はMAG1が送信したHIメッセージを受信し、当該HIメッセージを解析することにより、今回の切り替えがマルチキャストソース切り替えであると特定し、その中に有る切り替え後のマルチキャストモード情報、マルチキャストグループアドレス、RPアドレス（RPTモードを選択する時に）、マルチキャストソースホームアドレス等の情報を抽出する。ローカル・ポリシーに基づいてマルチキャストソース切り替えをサポートするかどうか、負荷が重いかどうか等の場合を特定して切り替えを受けるかどうかを決定する。
（2）HAckメッセージをMAG1に送信し、MAG2がマルチキャストソース切り替えを受けるかどうかの情報を含み、MAG2が 切り替えに同意すると、MAG1との間に双方向トンネルが構築される。
（3）マルチキャストソースMNがMAG2に接続された後に、MAG2がマルチキャストソースの送信したマルチキャストデータを受信してから、MAG2とMAG1との双方向トンネルを介してMAG1に伝送する。
（4）MAG2は、切り替え後のマルチキャストモードが異なることに応じて、異なる操作を実行する。
RPTモードでは、MAG2は、LMAへ拡張のバインディング更新メッセージを送信し、LMAをマルチキャストソースのRPとすることを要請する。バインディング更新等の過程が終了した後に、MAG2がMAG1へマルチキャストデータの転送を停止することを通知し、MAG1からMAG2までの双方向トンネルを取り消す。
SPT且つ不更新マルチキャストツリーモードでは、MAG2がLMAへPMIPv6が正常であるバインディング更新メッセージを送信する。マルチキャストソースの移動速度が速いので、MAG1とMAG2とのトンネルが取り消されず、マルチキャストソースが外界へ発信したデータは、相変わらずSource->MAG2->MAGl->マルチキャストツリーのようなパスで、マルチキャスト受信ノードに伝送される。マルチキャストソースMNが再び移動する際に、MAG2は、MAG1とMAG2との間のトンネルを介して、マルチキャストソースMNが再び移動した新しいアクセスポイントMAGのアドレスをMAG1に通知し、MAG1と新しいアクセスポイントMAGとのトンネルが構築された後に、現在のMAG1とMAG2とのトンネルが取り消される。
SPT且つマルチキャストツリー予備更新モードでは、MAG2は、LMAへPMIPv6が正常であるバインディング更新メッセージを送信する。マルチキャストツリー更新過程において、特殊のアクセスメッセージを受信する。この時にマルチキャストソースMNがMAG2に接続されていない場合、MAG2がマルチキャストソースMNに代わって、アクセスメッセージを処理する。マルチキャストツリー更新が終了した後は、マルチキャストデータが新しいマルチキャストツリーに沿って転送され始め、MAG2がMAG1へのマルチキャストデータの転送の停止を通知し、MAG1からMAG2までの双方向トンネルを取り消す。

【0123】

三、マルチキャストツリー予備更新過程でのマルチキャストルータ上の操作は、主に、以下の通りの方面を含む。
（1）切り替えが開始する前に、マルチキャストツリールータのうち、（S,G）状態のActiveInterfaceを、ルータからマルチキャストソースの古いアクセスポイントMAG1へのRPFインターフェースに設置し、pre-handoverInterfaceを空きに設置する。
（2）リーフノードルータ（マルチキャストノードに対応する）がMAG1が送信した、マルチキャストソース切り替えオプション付きのマルチキャストデータを受信した後に、マルチキャストソース切り替えオプションを解析する必要があり、その中からMAG2のアドレスを抽出して、Join（S,G）メッセージを構成し、Join（S,G）メッセージを、MAG2を目的アドレスとするIPデータパケット中にパッケージングする。IPデータパケットのIPv6ホップバイホップのオプションヘッダーは、マルチキャストソース切り替えオプションを有する。最後に、それは、IPメッセージにパッケージングされたアクセスメッセージを、MAG2の方向に向かって送信する。
（3）途中で、ルータがIPメッセージでパッケージングしたアクセスメッセージを受信した後に、マルチキャストルートを更新する。且つMAG2から戻った、アクセスメッセージに対する返信を受信し、ネットワークにおいて予め一つのマルチキャストソースの新アクセスポイントMAG2を根とするマルチキャストツリーを構築し、この予備更新のマルチキャストツリーにおいて、全てのルータ（S,G）状態のpre-handoverInterfaceが、何れもルータからマルチキャストソースの新アクセスポイントMAG2へのRPFインターフェースに設置される。
（4）マルチキャストツリー予備更新過程において、ActiveInterfaceからマルチキャストデータを受信して転送する。マルチキャストソースがMAG2でバインディング更新等の操作を終了した後は、マルチキャストデータが、新しいマルチキャストツリーに沿って転送され始め、即ち、（S,G）状態のpre-handoverInterfaceインターフェースから各ルータに到達する。
（5）新マルチキャストツリー上のルータが初めてpre-handoverInterfaceインターフェースからマルチキャストデータを受信した時に、新しいマルチキャストツリーが使用されることが証明され、さらに、マルチキャストルートが更新される。
（6）新旧マルチキャストツリーの交替作業が終了した後は、ルータは、新しいパスに従ってマルチキャストデータを転送する。

【0124】

実施例二
本発明の実施例二は、マルチキャストデータを伝送する装置を提供する。図19に示すように、当該装置は、切り替え予告メッセージ受信ユニット1901、トンネル構築ユニット1902、及びマルチキャストデータ伝送ユニット1903を含む。
切り替え予告メッセージ受信ユニット1901は、マルチキャストソースが現在アクセスする第1の移動アクセスゲートウェイMAGから第2のMAGに切り替える前に送信した切り替え予告メッセージを受信するためのものであり、当該切り替え予告メッセージは当該第2のMAGの標識情報を有する。
トンネル構築ユニット1902は、切り替え予告メッセージ受信ユニット1901の受信した切り替え予告メッセージに付加されている第2のMAGの標識に基づいて、当該第2のMAGとの間の双方向トンネルを構築するためのものである。
マルチキャストデータ伝送ユニット1903は、特定した切り替え後のマルチキャストモード及びトンネル構築ユニット1902の構築した双方向トンネルに基づいて、当該マルチキャストソースからのマルチキャストデータに対してマルチキャストを行うためのものであり、当該切り替え後のマルチキャストモードは、当該マルチキャストソースから第2のMAGに切り替えられた後に用いられるマルチキャストモードである。

【0125】

本発明の実施例二が提供する一つの最適な実施方式において、図19に示す装置に含まれるトンネル構築ユニット1902は、具体的に、
第2のMAGへ切り替え初期化HIメッセージを送信し、当該第2のMAGの送信した切り替え返信HAckメッセージを受信した後に、当該第2のMAGとの双方向トンネルを構築するためのものである。

【0126】

本発明の実施例二が提供する一つの最適な実施方式において、図19に示す装置に含まれるトンネル構築ユニット1902は、具体的に、
当該第2のMAGへマルチキャストソース切り替えの指示情報、マルチキャストソース標識及び切り替え後のマルチキャストモードの指示情報を含むHIメッセージを送信するためのものである。

【0127】

本発明の実施例二が提供する一つの最適な実施方式において、図19に示す装置に含まれるトンネル構築ユニット1902は、具体的に、
当該第2のMAGへマルチキャストグループアドレス及びマルチキャストソースホームアドレスをさらに含むHIメッセージを送信するためのものであり、そして、当該HIメッセージの指示したマルチキャストモードが共有ツリーRPTモードである場合に、当該HIメッセージは、マルチキャストランデブーポイントRPアドレスをさらに含む。

【0128】

本発明の実施例二が提供する一つの最適な実施方式において、図19に示す装置に含まれるマルチキャストデータ伝送ユニット1903は、具体的に、
当該マルチキャストソースが第1のMAGにアクセスする際に用いるマルチキャストモードを特定し、
当該マルチキャストソースが第1のMAGにアクセスする際に用いるマルチキャストモードがRPTモードであると特定した場合に、切り替え後のマルチキャストモードがRPTモードであると特定し、
当該マルチキャストソースが第1のMAGにアクセスする際に用いるマルチキャストモードがSPTモードであると特定し、且つ当該マルチキャストソースの移動速度が設定閾値より大きいと特定した場合に、切り替え後のマルチキャストモードがSPT且つ不更新マルチキャストツリーモードであると特定し、
マルチキャストソースが第1のMAGにアクセスする際に用いるマルチキャストモードがSPTモードであると特定し、且つ当該マルチキャストソースの移動速度が設定閾値以下であると特定した場合に、切り替え後のマルチキャストモードがSPT且つマルチキャストツリー予備更新モードであると特定するためのものである。

【0129】

本発明の実施例二が提供する一つの最適な実施方式において、図19に示す装置に含まれるマルチキャストデータ伝送ユニット1903は、具体的に、
特定した切り替え後のマルチキャストモードがRPTモード又はSPT且つマルチキャストツリー予備更新モードである場合に、当該マルチキャストソースが第2のMAGにアクセスした後にマルチキャストデータに用いるマルチキャストパスの構築が終了する前に、第1のMAGは、構築した双方向トンネルを介して、当該第2のMAGの転送した当該マルチキャストソースのデータを受信し、当該マルチキャストソースがアクセスする際に構築したマルチキャストパスに基づいてデータに対してマルチキャストを行い、
特定した切り替え後のマルチキャストモードがSPT且つ不更新マルチキャストツリーモードである場合に、第1のMAGは、構築した当該双方向トンネルを介して、当該第2のMAGの転送した当該マルチキャストソースのデータを受信し、当該マルチキャストソースがアクセスする際に構築したマルチキャストパスに基づいて当該データに対してマルチキャストを行うためのものである。

【0130】

図20に示すように、本発明の実施例二が提供した一つの最適な実施方式において、図19に示す装置は、マルチキャストツリー更新制御ユニット1904さらに含んでもよく、
マルチキャストツリー更新制御ユニット1904は、特定した切り替え後のマルチキャストモードがSPT且つマルチキャストツリー予備更新モードである場合に、第2のMAGの送信したHAckメッセージを受信した後に、当該マルチキャストソースがアクセスする際に構築されたマルチキャストパス及び第2のMAGのアドレスに基づいて、当該マルチキャストソースが第2のMAGにアクセスした後にマルチキャストデータに用いるマルチキャストパスの構築を触発する。

【0131】

本発明の実施例二が提供する一つの最適な実施方式において、図20に示す装置に含まれるマルチキャストツリー更新制御ユニット1904は、具体的に、
マルチキャストソースの送信したデータパケットにおいてマルチキャストソース切り替え指示及び第2のMAGのアドレス情報を有し、且つ当該マルチキャストソースがアクセスする際に構築したマルチキャストパスに基づいて、当該マルチキャストパス上のマルチキャストノードへマルチキャストソース切り替え指示及び当該第2のMAGのアドレス情報を有したデータパケットを送信するためのものである。

【0132】

本発明の実施例二が提供する一つの最適な実施方式において、図20に示す装置に含まれるマルチキャストツリー更新制御ユニット1904は、具体的に、
マルチキャストソースの送信したデータパケットのIpv6ホップバイホップのオプションヘッダーにおいてマルチキャストソース切り替え指示及び当該第2のMAGのアドレス情報を有するためのものである。

【0133】

図21に示すように、本発明の実施例二が提供する最適な実施方式において、図19に示す装置は、トンネル取り消しユニット1905をさらに含んでもよく、
トンネル取り消しユニット1905は、特定した切り替え後のマルチキャストモードがRPTモード又はSPT且つマルチキャストツリー予備更新モードである場合に、マルチキャストソースが第2のMAGにアクセスした後にマルチキャストデータに用いられるマルチキャストパスの構築が終了した後に、当該第2のMAGの送信した双方向トンネル取り消し指示を受信し、且つ当該取り消し指示に基づいて第2のMAGとの間の双方向トンネルを取り消す。

【0134】

以上、マルチキャストデータを伝送する装置に含まれるユニットは、当該装置が実現する機能に基づいて行うロジック区分に過ぎず、実用において、上記ユニットの重畳又は分割を行うことができると理解すべきである。また、当該実施例が提供した装置が実現する機能は、上記実施例一が提供したマルチキャストデータを伝送する方法フローに対応し、当該装置が実現する一層詳細な処理フローは、上記方法実施例一で既に詳細に記述されているので、ここでは詳細に記述しない。

【0135】

実施例三
本発明の実施例三は、マルチキャストデータを伝送するシステムを提供し、図22に示すように、当該システムは、主に、マルチキャストソース2201、第1の移動アクセスゲートウェイMAG2202及び第2のMAG2203を含み、
マルチキャストソース2201は、現在アクセスする第1のMAGが第2のMAGに切り替える前に、第1のMAG2202へ切り替え予告メッセージを送信するためのものであり、当該切り替え予告メッセージは、第2のMAG2203の標識情報を有する。
第1のMAG2202は、マルチキャストソース2201が送信した切り替え予告メッセージに有する第2のMAG2203の標識に基づいて、第2のMAG2203との間の双方向トンネルを構築し、且つ特定した切り替え後のマルチキャストモード及び構築した双方向トンネルに基づいて、マルチキャストソースからのマルチキャストデータに対してマルチキャストを行うためのものであり、なお、切り替え後のマルチキャストモードは、マルチキャストソースが第2のMAG2203に切り替えられた後に用いられるマルチキャストモードである。

【0136】

以上、マルチキャストデータを伝送するシステムに含まれる第1のMAGが実現する機能は、上記実施例二が提供したマルチキャストデータを伝送する装置に対応すると理解すべきであり、第1のMAGが実現する一層詳細な処理フローは、上記実施例二に既に詳細に記述されているので、ここでは詳細に記述しない。

【0137】

実施例四
本発明の実施例四は、マルチキャストツリーの更新システムを提供し、図23に示すように、当該システムは、主に、第1のマルチキャストノード2301、及び第2のマルチキャストノード2302を含み、
第1のマルチキャストノード2301は、第1の移動アクセスゲートウェイMAGの送信したデータパケットを受信し、当該データパケットにマルチキャストソース切り替え指示を有すると特定した後に、マルチキャストツリーを生成するためのアクセスメッセージを構築し、データパケットに有する第2のMAGのアドレス情報を、アクセスメッセージに有し、転送するためのものであり、
第2のマルチキャストノード2302は、第1のマルチキャストノード2301の転送したアクセスメッセージを受信し、当該アクセスメッセージが有する第2のMAGのアドレス情報に基づいてマルチキャストルートを更新し、続いて、当該アクセスメッセージを転送して、既に第2のMAGのアドレス情報に基づいてマルチキャストルートを更新した後のマルチキャストノードがアクセスメッセージを受信するためのものである。

【0138】

本発明の実施例四が提供する一つの最適な実施方式において、図23に示すシステムに含まれる第1のマルチキャストノード2301は、具体的に、
アクセスメッセージを、第2のMAGのアドレスを目的アドレスとするデータパケットにパッケージングし、データパケットにおいてマルチキャストソース切り替え指示を有し、設定した上流近隣ルータアドレスに基づいて、マルチキャストソース切り替え指示を有するデータパケットを転送するためのものである。

【0139】

本発明の実施例四が提供する一つの最適な実施方式において、図23に示すシステムに含まれる第2のマルチキャストノード2302は、具体的に、
アクセスメッセージが有する第2のMAGのアドレス情報に基づいて、このマルチキャストサービスに対応するマルチキャストルート状態での予備切り替えインターフェースPre-handoverInterfaceを、第2のMAGへの反対方向パス転送 RPFインターフェースに設置するためのものである。

【0140】

本発明の実施例四が提供する一つの最適な実施方式において、図23に示す第2のマルチキャストノード2302は、具体的に、
自身にこのマルチキャストサービスに対応するマルチキャストルート状態があるかどうかを特定し、
このマルチキャストサービスに対応するマルチキャストルート状態があると特定した場合に、マルチキャストルート状態でのPre-handoverInterfaceを、第2のMAGへのRPFインターフェースに設置し、
このマルチキャストサービスに対応するマルチキャストルート状態がないと特定した場合に、マルチキャストルート状態を作成し、マルチキャストルート状態でのPre-handoverInterfaceの状態を、第2のMAGへのRPFインターフェースに設置し、マルチキャストルート状態でのデータ受信インターフェースActiveInterfaceの状態を、空きに設置するためのものである。

【0141】

本発明の実施例四が提供する一つの最適な実施方式において、図23に示すシステムが含む第2のマルチキャストノード2302は、さらに、
アクセスメッセージが有する第2のMAGのアドレス情報に基づいてマルチキャストルートを更新した後に、初めて、Pre-handoverInterfaceによりデータを受信すると、マルチキャストルート状態でのActiveInterface状態が空き、又はActiveInterfaceとPre-handoverInterfaceとが同じであると特定すると、Pre-handoverInterfaceの状態に基づいてActiveInterfaceの状態を設置し、Pre-handoverInterfaceの状態を空きに設置するためのものである。

【0142】

本発明の実施例が提供する上記技術方案は、マルチキャストソース切り替えの前に、MAG1が拡張の切り替えにより、（HI）と切り替え応答（HAck）シグナリングメッセージを発動し、事前に、マルチキャストソースのマルチキャストグループアドレス、RPアドレス、マルチキャストモード選択方式等の情報をMAG2に送信し、且つ予めMAG1とMAG2との間に一つの双方向トンネルを構築する。マルチキャストソースがバインディング更新、認証、マルチキャストツリー再構築等の過程を終了する前に、マルチキャストデータは、マルチキャストソース→MAG2→MAG1のようなパスにより元のマルチキャストツリー上に伝送されることにより、マルチキャスト受信ノードに転送される。このように、マルチキャストサービスの停止時間を最小化し、一旦、マルチキャストソースとMAG2との接続が構築されると、マルチキャストサービスが、すぐ回復できる。SPT且つマルチキャストツリー更新モードを使用する場合に、本発明の実施例が提供した技術方案によれば、以下の通りの分析を行うことができ、
従来技術の場合、マルチキャストソース切り替えの遅延は、マルチキャストソースMNが移動し且つMAG2に接続する時間+MAG2がLMAへのバインディング更新時間（PBU、PBAメッセージの送信、伝送、LMA認証の時間を含む）+マルチキャストツリー再構築の時間（SPTモード）である。本方案を使用する場合、マルチキャストソースの切り替え遅延は、マルチキャストソースMNが移動し且つMAG2に接続する時間である。これから見ると、本方案は、マルチキャストソースの切り替え遅延を有効に低減し、できるだけ短い時間遅延内でマルチキャストサービスを回復する目的を達する。また、SPT且つマルチキャストツリー更新モードを使用する場合、切り替えの初めにマルチキャストツリーの予備更新作業が開始されるので、マルチキャストソースがマルチキャストツリーの再構築を待つ時間が有効に低減される。

【0143】

さらに、本発明は、従来技術の切り替え後のマルチキャストモードを補充、改善した。現実の切り替えの異なる状況について、本発明は、三つの切り替え後のマルチキャストモードを定義し、RPTモード、SPT且つ不更新マルチキャストツリーモード、及びSPT且つマルチキャストツリー予備更新モードである。各モードは、異なる実際の状況に対して、異なる切り替え方式を用いるので、実情により適合され、利用性がより高く、ネットワークの資源ロス、マルチキャストサービス遅延が長すぎる等の状況が回避される。

【0144】

さらに、本発明は、SPTを予備更新する方法を定義し、移動ノードが切り替わる前にマルチキャストツリーの予備更新作業が起動され、予めマルチキャストツリーの再構築が行われることにより、マルチキャストツリー更新に必要な時間遅延が減少される。そして、マルチキャストツリー予備更新過程で古いマルチキャストツリーには影響が及ばず、古いマルチキャストツリーによるデータ転送が実現される。本発明は、マルチキャストソース移動過程でマルチキャストソースアドレスが変わらない場合に RPFの検出が無効になる問題を克服し、マルチキャストソース移動がマルチキャスト受信者にとって透明であることを保証する。マルチキャストソースMNがMAG2に切り替えられた後マルチキャストツリーの更新を待つ時間が減少され、マルチキャストツリー更新過程でのマルチキャストデータのロスが回避される。

【0145】

当業者は、本発明の実施例が方法、システム、又はコンピュータプログラム製品として提供されることを理解すべきである。従って、本発明は、完全ハードウェアの実施例、完全ソフトウェア実施例、又はソフトウェアとハードウェアを組み合わせた実施例の形式を採用することができる。そして、本発明は、一つ又は複数の、その中にコンピュータ利用可能なプログラムコードが含まれる、コンピュータが利用可能な記憶媒体（ディスクメモリ、CD-ROM、光学メモリ等を含むが、これに限定されない）により実施されるコンピュータプログラム製品の形式を採用してもよい。

【0146】

本発明は、本発明の実施例の方法、デバイス（システム）、コンピュータプログラム製品に基づくフローチャート及び/又はブロック図を参照して記述した。コンピュータプログラム指令により、フローチャート及び/又はブロック図における各フロー及び/又はブロック、フローチャート及び/又はブロック図におけるフロー及び/又はブロックの組み合わせが実現できることを理解すべきである。これらのコンピュータプログラム指令を汎用のコンピュータ、専用のコンピュータ、組み込み式プロセッサー又は他のプログラマブルデータ処理デバイスのプロセッサーに提供して一つの機器を生じ、コンピュータ又はプログラマブルデータ処理デバイスのプロセッサーが実行する指令により、フローチャートの一つ又は複数のフロー及び/又はブロック図の一つ又は複数のブロックで指定する機能を実現するための装置が生じるようにする。

【0147】

これらのコンピュータプログラム指令は、コンピュータ又は他のプログラマブルデータ処理デバイスを案内して特定の方式で作業するようにするコンピュータ読み取り可能なメモリに記憶され、当該コンピュータ読み取り可能なメモリに記憶された指令が、指令装置を含む製造品を生じるようにしてもよく、当該指令装置は、フローチャートの一つのフロー又は複数のフロー及び/又はブロック図の一つのブロック又は複数のブロックで指定された機能を実現する。

【0148】

これらのコンピュータプログラム指令は、コンピュータ又は他のプログラマブル処理デバイスに搭載され、コンピュータ又は他のプログラマブル処理デバイス上で一連の操作ステップが実行され、コンピュータが実現する処理を生じることにより、コンピュータ又は他のプログラマブル処理デバイスで実行する指令が、フローチャートの一つのフロー又は複数のフロー及び/又はブロック図の一つのブロック又は複数のブロックで指定される機能を実現するためのステップを提供する。

【0149】

本発明の最適な実施例を記述したが、当業者は、一旦、基本的進歩性概念を知ると、これらの実施例に対して、別の変更と修正を行うことができる。従って、付属の請求項は、好ましい実施例、及び本発明の範囲に入る全ての変更と修正を含むと解釈される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】