"端末と前記端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、前記端末が提供を希望するマルチキャストサービスについてのサービス提供要求を、前記ゲートウェイ装置を介して前記ネットワークに送信することにより前記マルチキャストサービスを提供する通信システムに適用可能なゲートウェイ装置であって、前記端末のマルチキャスト制御の傾向を示す端末挙動情報を管理する端末挙動情報管理手段と、前記端末からマルチキャストサービスについてのサービス提供要求を受信する要求受信手段と、前記要求受信手段により受信したサービス提供要求の種別に基づいて、前記端末が提供を受けるマルチキャストサービスを選択し、前記選択されたマルチキャストサービスについてのサービス提供要求を前記ネットワークへ送信するサービス選択手段と、前記要求受信手段により受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスが前記サービス選択手段により選択された場合、前記端末挙動情報管理手段により管理された端末挙動情報に基づいて、前記要求受信手段により受信されたサービス提供要求を前記ネットワークに送信するタイミングを決定する送信タイミング決定手段と、を備えることを特徴とするゲートウェイ装置。前記送信タイミング決定手段により送信するタイミングが決定されるサービス提供要求は、ネットワークにおける帯域の予約を行うリソース予約要求と特定のマルチキャストグループへの参加を要求する参加要求からなることを特徴とする請求項1に記載のゲートウェイ装置。前記マルチキャストサービスの提供についての前記ネットワークにおける遅延時間を管理する網挙動情報管理手段をさらに備え、前記サービス提供要求送信手段は、前記網挙動情報管理手段により管理された網挙動情報に基づいて、前記参加要求受信手段により受信されたサービス提供要求を前記ネットワークに送信するタイミングを決定すること、を特徴とする請求項1または2のいずれかに記載のゲートウェイ装置。前記サービス選択手段において、前記要求受信手段により受信された参加要求のマルチキャストサービスと異なるマルチキャストサービスが選択された場合、前記ネットワークから受信するマルチキャストパケットを前記端末が送信したサービス提要要求のマルチキャストサービスを示すマルチキャストパケットにアドレス変換して上記端末に送信するアドレス変換手段をさらに備えること、を特徴とする請求項1~3のいずれか1項に記載のゲートウェイ装置。前記端末挙動情報は、前記端末の送信するサービス提供要求の受信履歴であり、前記送信タイミング決定手段は、前記受信履歴が予め定められた頻度以上である場合に、予め定められた一定期間だけリソース予約要求のタイミングを遅らせること、を特徴とする請求項1~4のいずれか1項に記載のゲートウェイ装置。前記マルチキャストサービスを行う制御方式がIGMPv3InternetGroupManagementProtocolversion3であり、前記マルチキャストサービスに用いるパケット方式がIPv6InternetProtocolVersion6であること、を特徴とする請求項1~5のいずれか1項に記載のゲートウェイ装置。前記マルチキャストサービスを行う制御方式がMLDv2MulticastListenerDiscoveryversion2であり、前記マルチキャストサービスに用いるパケット方式がIPv6であること、を特徴とする請求項1~5のいずれか1項に記載のゲートウェイ装置。前記リソース予約の方式がSIPSessionInitiationProtocolであること、を特徴とする請求項1~7のいずれか1項に記載のゲートウェイ装置端末と前記端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、前記端末が提供を希望するマルチキャストサービスについてのサービス提供要求を、前記ゲートウェイ装置を介して前記ネットワークに送信することにより前記マルチキャストサービスを提供する通信システムに適用可能な通信制御方法であって、前記ゲートウェイ装置が、前記端末からマルチキャストサービスについてのサービス提供要求を受信する参加要求受信ステップと、前記参加要求受信ステップにおいて受信したサービス提供要求の種別に基づいて、前記端末が提供を受けるマルチキャストサービスを選択し、前記選択されたマルチキャストサービスについてのサービス提供要求を前記ネットワークへ送信するサービス選択ステップと、前記サービス選択ステップにおいて、前記参加要求ステップにおいて受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスが選択された場合、前記参加要求受信ステップにおいて受信されたサービス提供要求を一定時間経過後に前記ネットワークに送信する参加要求送信ステップと、を備えることを特徴とする通信制御方法。前記参加要求送信ステップでは、前記端末のマルチキャスト制御の傾向を示すマルチキャスト挙動情報に基づいて、前記参加要求ステップにおいて受信された参加要求を前記ネットワークに送信するタイミングを決定すること、を特徴とする請求項9記載の通信制御方法。端末と前記端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、前記端末が提供を希望するマルチキャストサービスについての参加要求を、前記ゲートウェイ装置を介して前記ネットワークに送信することにより前記マルチキャストサービスを提供する通信システムであって、前記端末のマルチキャスト制御の傾向を示す端末挙動情報を管理する端末挙動情報管理手段と、前記端末からマルチキャストサービスについてのサービス提供要求を受信する要求受信手段と、前記要求受信手段により受信したサービス提供要求の種別に基づいて、前記端末が提供を受けるマルチキャストサービスを選択し、前記選択されたマルチキャストサービスについてのサービス提供要求を前記ネットワークへ送信するサービス選択手段と、前記サービス選択手段において、前記要求受信手段により受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスが選択された場合、前記端末挙動情報管理手段により管理された端末挙動情報に基づいて、前記要求受信手段により受信されたサービス提供要求を前記ネットワークに送信するタイミングを決定する送信タイミング決定手段と、を備えることを特徴とする通信システム。IPマルチキャストを実現するにはルーティングを行う必要があるが、一般的にIPマルチキャストのルーティングはユニキャストと比較して複雑であり、ネットワークの計算量が大きくなる。特にマルチキャストにおいてリソース予約やQoSを考慮したルーティングを行う場合にはさらに複雑な計算を要する。一方、ザッピングと呼ばれる、頻繁にチャネル変更を行う視聴行動は、テレビサービスの視聴者に広くみられる傾向がある。IPTVサービスにおいては、ザッピングはマルチキャストルートの頻繁な変動を意味する場合があり、特にNGNのような高度なマルチキャストサービスにおいては、多数の視聴者のザッピングによって、ネットワークのルートリソース予約の再計算負荷が特に大きくなる。このようなネットワーク負荷の増大は、ルートリソース予約処理の遅延による視聴者の体感品質の低下や、ネットワーク装置の処理能力向上のための設備コストの増大という課題が生じる事となる。本発明は上述の課題を解決するためになされたものであり、マルチキャストサービスを下部端末に提供しながら、マルチキャストルートの頻繁な変動等が発生した場合においてもリソース予約解放の回数を抑制することで、頻繁な再計算によるネットワーク負荷の増大を抑制し、上述の課題を解消するゲートウェイ装置を提供することを目的とする。この発明に係るゲートウェイ装置は、端末と端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、端末が提供を希望するマルチキャストサービスについてのサービス提供要求を、ゲートウェイ装置を介してネットワークに送信することによりマルチキャストサービスを提供する通信システムに適用可能なゲートウェイ装置であって、端末のマルチキャスト制御の傾向を示す端末挙動情報を管理する端末挙動情報管理手段と、端末からマルチキャストサービスについてのサービス提供要求を受信する要求受信手段と、要求受信手段により受信したサービス提供要求の種別に基づいて、端末が提供を受けるマルチキャストサービスを選択し、選択されたマルチキャストサービスについてのサービス提供要求をネットワークへ送信するサービス選択手段と、要求受信手段により受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスがサービス選択手段により選択された場合、端末挙動情報管理手段により管理された端末挙動情報に基づいて、要求受信手段により受信されたサービス提供要求をネットワークに送信するタイミングを決定する送信タイミング決定手段と、を備える。また、この発明に係る通信制御方法は、端末と端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、端末が提供を希望するマルチキャストサービスについてのサービス提供要求を、ゲートウェイ装置を介してネットワークに送信することによりマルチキャストサービスを提供する通信システムに適用可能な通信制御方法であって、ゲートウェイ装置が、端末からマルチキャストサービスについてのサービス提供要求を受信する参加要求受信ステップと、参加要求受信ステップにおいて受信したサービス提供要求の種別に基づいて、端末が提供を受けるマルチキャストサービスを選択し、選択されたマルチキャストサービスについての参加要求をネットワークへ送信するサービス選択ステップと、サービス選択ステップにおいて、参加要求ステップにおいて受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスが選択された場合、参加要求ステップにおいて受信されたサービス提供要求を一定時間経過後にネットワークに送信する参加要求送信ステップと、を備える。また、この発明に係る通信システムは、端末と端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、端末が提供を希望するマルチキャストサービスについての参加要求を、ゲートウェイ装置を介してネットワークに送信することによりマルチキャストサービスを提供する通信システムであって、端末のマルチキャスト制御の傾向を示す端末挙動情報を管理する端末挙動情報管理手段と、端末からマルチキャストサービスについてのサービス提供要求を受信する要求受信手段と、要求受信手段により受信したサービス提供要求の種別に基づいて、端末が提供を受けるマルチキャストサービスを選択し、選択されたマルチキャストサービスについてのサービス提供要求をネットワークへ送信するサービス選択手段と、サービス選択手段において、要求受信手段により受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスが選択された場合、端末挙動情報管理手段により管理された端末挙動情報に基づいて、要求受信手段により受信されたサービス提供要求をネットワークに送信するタイミングを決定する送信タイミング決定手段と、を備える。本発明によれば、端末側のザッピング行動のようなマルチキャストルートの変動が頻繁に起こるような場合においても、より適切にマルチキャスト参加要求ならびにリソース予約を行うことができるため、ネットワーク負荷の増大を抑制することができる。実施の形態1.本発明の実施の形態に係るゲートウェイ装置を適用したネットワークシステムについて図面を参照して説明する。図1は、本発明にかかるネットワークシステムの構成図である。図1において、視聴端末1-1~nは、マルチキャストのサービスを受信するための標準的な機能を備えた端末である。視聴端末1-1~nは、少なくともIGMP,MLDのようなマルチキャスト参加離脱要求の機能を備え、マルチキャストサービスに用いるパケット方式はIPv6を用いるものとする。また、ここでは視聴端末1-1~nはSIPに対応し、リソース予約解放の機能を備えているとして説明するが、SIP等のリソース予約解放の機能に対応していない場合であってもよい。ゲートウェイ装置以下、適宜ゲートウェイと略記する2は、視聴端末以下、適宜端末と略記する1-1~nとネットワーク3を中継する位置に配置される。また、ネットワーク3にはサービス提供サーバ4-1~nが接続されている。なお、視聴端末1-1~nを総称する場合、または、区別をしない場合には、視聴端末1または、単に端末1と表記する。サービス提供サーバ4-1~nについても同様である。ネットワーク3は、NGNのようなセッション制御機能を備えたサービスネットワークであり、ここでは、SIPに対応するものとして説明する。また、リソース予約などのサービスを提供するセッション制御部31と、パケットを転送する転送ノード32-0~nとを備える。セッション制御部31は、サービス顧客視聴端末からの要求を受けて、転送ノードのリソースを予約する機能を有する。転送ノード32-0~nは、セッション制御部31からの制御によって予約されたリソースを使用してパケットを転送する機能を有し、パケットをサービス顧客に伝達する役割を担う。このうち、特に転送ノード32-0は、サービス顧客に接続される転送ノードである。サービス提供サーバ4-1~nは、IPTV等のサービスを提供するために、マルチキャストを送信するサーバである。図2は、ゲートウェイ装置2の特徴的な内部機能構成、機能間インタフェース、及びノード間インタフェースを模式的に示した図である。図2において、マルチキャスト管理部20は、端末挙動情報管理部21、サービス情報管理部22、網挙動情報管理部23を参照し、制御ポリシーに従って、SIPB2BUAbacktoBackUserAgent部24、MLDProxy部25、IPv6NATNetworkAddressTranslation部26を制御する機能を有する。例えば、マルチキャスト管理部20は、過去のSIPB2BUA部24、MLDProxy部25の制御履歴から、端末がザッピングを行っているかどうかを検出する。また、SIPB2BUA部24、MLDProxy部25の制御結果を受け取り、端末挙動情報部21、サービス情報管理部22、網挙動情報管理部23に格納された情報を更新する。端末挙動情報管理部21は、ゲートウェイ装置に接続される端末のマルチキャスト制御の傾向などを示す端末挙動情報を格納しており、例えば、各端末が過去に行ったSIPB2BUA部24、MLDProxy部25の制御履歴、すなわち、端末からのリソース予約要求やマルチキャストサービスへの参加要求等の受信履歴を格納する。また、端末1の能力、端末1が利用可能なサービス、および端末1の優先度などを格納することも出来る。SIPB2BUA部24、MLDProxy部25の制御履歴は、マルチキャスト管理部20がSIPB2BUA24、MLDProxy部25の動作を監視することによって取得し、内部インタフェース201を経由して、マルチキャスト管理部20から端末挙動情報部21に通知される。上述した形態に加え、もしくは、代わりに、端末挙動情報部21がノード間インタフェース211、222によって、端末1やネットワーク3から端末挙動情報を取得するようにしてもよい。ノード間インタフェース211は、端末が自身の能力などを通知するために使用するもので、一般的にはHTTPやSIPよって実装する。端末挙動情報部21が備えるノード間インタフェース222は、ネットワークが端末や回線の利用可能なサービス、優先度を通知するために使用するもので、同様に一般的にはHTTPやSIPによって実装する。サービス情報管理部22は、ネットワークがゲートウェイ装置に対して提供することが出来るマルチキャストサービスの内容を示すサービス情報を格納しており、例えば、少なくともサーバの識別子と、マルチキャストグループの識別子を格納する。また、コンテンツの内容を示す情報、リソース予約の要否、サービスが必要とするリソースの情報を含むことが出来る。ここでは、ゲートウェイ装置は、HTTPやSIPによって実装されるノード間インタフェース222により、ネットワークから上記情報を取得する。上述した形態に加え、もしくは、代わりに、サービス情報22がノード間インタフェース212、内部インタフェース202によって、端末1やマルチキャスト管理部20から上記情報を取得することも可能である。ノード間インタフェース212は、端末側から上記情報を通知するために使用するためのもので、一般的にはHTTPやSIPよって実装する。また、内部インタフェース202を用いて上記情報を取得する場合、上記情報はゲートウェイ装置2に固定的に設定されたものを使用する。網挙動情報管理部23は、網挙動情報を管理しており、例えば、ネットワークがサービスに対してマルチキャスト参加離脱、リソース予約解放に要する計算量と時間を示す、もしくは上記計算量と時間を推測するための情報を管理する。ここでは、HTTPやSIPよって実装するノード間インタフェース223によってネットワークから、上記計算量と時間を管理するものとする。上述した形態に加え、もしくは、代わりに、網挙動情報23がノード間インタフェース213、内部インタフェース203によって、端末1やマルチキャスト管理部20から上記情報を取得することも可能である。ノード間インタフェース213は、端末から上記情報を通知するために使用するためのもので、一般的にはHTTPやSIPよって実装する。内部インタフェース203を用いて、上記情報を取得する場合、上記情報は、例えばマルチキャスト管理部20が測定した、過去にサービスに対するリソース予約を行った際に要した時間の統計値のような、ゲートウェイ装置で測定可能な情報である。SIPB2BUA部24は、リソース予約を行うためのSIP通信を制御する。SIPによるリソース予約機能を具備している端末1及びネットワーク3とSIPノード間インタフェース214、224により通信する。一般的なSIPを中継する機能に加え、マルチキャスト管理部20が、端末側と網側の通信を制御する。MLDproxy部25は、マルチキャスト参加離脱を行うためのMLD通信を制御する機能である。MLDによるマルチキャスト参加離脱機能を具備している端末1及びネットワーク3とMLDノード間インタフェース215、225により通信する。単純なMLD中継機能ではなく、マルチキャスト管理部20が、端末側と網側の通信を制御する。一般的なMLDプロキシ機能は、複数の端末から受信したMLDメッセージを集約し、マルチキャストグループアドレス送信元アドレスの参加状態を管理し、その状態を網側に通知する機能であるが、本発明では、これに加え、マルチキャスト管理部20の制御により、端末側のマルチキャストグループアドレス送信元アドレスを別のアドレスに変換して網側に通知する機能を備える。IPv6NAT部26は、ネットワークから受信するマルチキャストストリームのアドレス変換を実施し、端末側へ送信する。マルチキャスト管理部20の制御により、MLDProxy部25でアドレス変換した結果をマルチキャストストリームに反映するための機能である。次に、図3を参照して、本発明の実施の形態1に係るネットワークシステムの動作について説明する。ゲートウェイ装置2は、予めネットワーク3から、サービス情報を取得する。ゲートウェイ装置2は、サービス情報要求信号HTTPGetを送信し手順501、ネットワーク3は応答信号200OKと共に自身が保持するサービス情報を送信する手順502。図4は、本手順で取得したサービス情報の例を示す。図4に示すサービス情報の例では、サービス提供サーバ41が提供する高品質のサービスS1とサービス提供サーバ42が提供する低品質のサービスS2の情報を示している。ここで、サービスS1およびS2のコンテンツ内容はいずれもAで同じであるが、高品質のサービスS1はリソース予約を必要とするのに対し、低品質のサービスS2はリソース予約が不要である。また、ゲートウェイ装置2は、ネットワーク3から網挙動情報を取得する。ゲートウェイ装置2は、網挙動情報要求信号SIPNotifyを送信し手順503、ネットワーク3は応答信号200OKと共に自身が保持する網挙動情報を送信する手順504。図5は本手順で取得した網側挙動情報の例を示す。図5に示す網挙動情報の例は、サービス提供サーバ41が提供する高品質のサービスS1のリソース予約に要する計算量が大きく、3秒の遅延時間が予測されることを示している。ここで、遅延時間とは、ゲートウェイ装置2がサービス提供要求、すなわち、マルチキャストサービスへの参加要求またはリソース予約要求を送信してからサービス提供サーバからマルチキャストが配信されるまでの時間を指すものとするが、これに限定されるものではなく、同様の内容を指す時間であればよい。また、サービス提供サーバ42が提供するサービスS2は、0.5秒の遅延時間が予測されることを示している。これらの手順は、ゲートウェイ装置がネットワークに接続したときや情報に変化があった場合に、必要な情報について実施される。端末からのサービス提供要求が発生した際の情報の流れについて説明する。ここでサービス提供要求とは、端末またはゲートウェイ装置が送信するマルチキャストサービスへの参加要求をいい、端末またはネットワークがリソース予約機能に対応し、リソース予約を行う場合には、端末またはゲートウェイ装置が送信するリソース予約要求も含むものとする。ここでは、端末1-1がサービスS1の提供を要求する場合について説明する。サービスS1はサービスの提供にあたり、リソース予約を必要とするため、まず、端末がリソース予約を実施する必要がある。端末1-1はサービスS1の受信を開始するため、S1に対するリソース予約要求を意味するSIPINVITEを送信する手順601。ゲートウェイ装置2は、SIPB2BUA部24がSIPINVITEを受信し、マルチキャスト管理部20がサービス情報及び網挙動情報を参照して、受信したSIPINVITEの種別を判断する。リソース予約の計算量が予め定められた所定の予測遅延例えば、1秒間より大きいこと、および、同内容かつ予測遅延の小さいサービスS2が存在することから、端末1-1に配信するマルチキャストサービスをサービスS2とすることを決定する。また、端末挙動情報に基づいて、ネットワークに対してリソース予約を実施するタイミングを決定し、スケジューリングを行う。リソース予約を実施するタイミングの決定方法については、詳細を後述する。このリソース予約の実施タイミングの決定に基づいて、SIPB2BUA部24を制御し、200OKを端末に返す手順602。この手順により端末は、リソース予約が完了したものとして動作する。なお、端末がリソース予約の機能を持たない場合、手順601、602は省略してもよい。この場合、端末1-1から受信した参加要求MLDJoinの種別を判断し、端末1-1に配信するマルチキャストサービスを決定する。次に、端末1がゲートウェイ装置2に対して、マルチキャストサービスS1への参加要求MLDjoinを送信する手順603。図3に示す例では、端末1-1がサービスS1についての参加要求をゲートウェイ装置2に送信する。ゲートウェイ装置2は、MLDProxy部25がサービスS1についての参加要求MLDjoinを受信するが、上述のように、予測遅延の小さいサービスS2を配信することを決定しているため、マルチキャスト管理部20は、ネットワークに対して、マルチキャストS2に参加するMLDjoinの送信を行う手順604。また、IPv6NAT部26に対して、サービス提供サーバ42から送信されるサービスS2のマルチキャストパケットを、サービスS1のマルチキャストパケットに変換する設定を行う。サービス提供サーバ4-2及びネットワーク3は、ゲートウェイ装置2から送信されたMLDjoinを受けてIPv6マルチキャストデータの送信及びゲートウェイ装置への伝送を開始する手順605。ゲートウェイ装置2は、サービス提供サーバ4-2からマルチキャストデータを受信すると、IPv6NAT機能が上記設定に基づき、サービスS1に対応するマルチキャストデータへの変換を実施し、端末に送信する手順606。ここまでの一連の動作によって、端末はリソース予約に要する時間を待たずに、とりあえず低品質のサービスの受信を開始することができる。端末が最初に要求した高品質のサービスの受信を開始するにはリソース予約の完了を待つ必要があるためが、とりあえず低品質のサービスを早い時期に受信することでユーザの体感遅延を軽減させる効果を得ることができる。次に、リソース予約を実施するタイミングの決定方法について説明する。ゲートウェイ装置が端末1-1から受信したサービス提供要求についてのサービスS1へのリソース予約を開始するタイミング607を端末挙動情報に基づいて決定する。本タイミングの決定を行う方法について説明する。図6は、端末挙動情報の例を示している。図6では、端末1-1に対応する端末識別子をT1、端末1-2に対応する識別子をT2としている。図6に示す端末挙動情報では、過去に行ったチャンネル切替履歴サービス提供要求受信履歴を管理しており、図6に示す例では、端末識別子T1に対応する端末では、2秒前、5秒前、6秒前にチャンネル切替を行っており、端末識別子T2に対応する端末では、30分前にチャンネル切替を行っていることがわかる。サービス提供要求手順601、手順603を実施した端末T1が、チャネル切替履歴から数秒間隔でチャネル切替を頻繁におこなっていることから、ザッピング中と判定する。一方、端末識別子T2に対応する端末は、過去30分間チャンネル切替が行われていないため、ザッピング中ではないと判定する。この判定基準は実装もしくは設定ポリシーによってさまざまな形式をとることができる。例えば過去10秒以内に3回以上のチャネル切替が行われた場合、直近のチャネル切替が5秒以内に行われた場合などである。また、網挙動情報の予測遅延を加味して上記判断をすることもできる。上述の判定において、端末がザッピング中であると判定した場合、ゲートウェイ装置は判定した時点から一定期間の後にタイミング607をスケジューリングし、サービス参加要求のネットワークへの送信を保留する。この一定期間の間にこの端末から新たにサービス提供要求を受信した場合、保留しておいたサービス提供要求を破棄し、新たに受信したサービス提供要求に対して上述の判定を行い、リソース予約を開始するタイミング607を決定する。また、上述のように新たに受信したサービス提供要求の種別を判断し、ネットワーク3に送信するサービス提供要求を選択する。これらの動作を繰り返し、一定期間中に新たなサービス提供要求を受信しない場合に、ネットワーク3に対して端末1より受信したサービス提供要求を転送することができる。端末がザッピング中でないと判定した場合、ゲートウェイ装置は判定した時点でタイミング607をスケジューリングする。すなわち、タイミング607以降の手順と、それ以前の手順は並行して動作することができる。本制御により、ザッピングによる頻繁なリソース予約を抑制し、ネットワークにおける負荷を低減する効果を得ることが出来る。タイミング607以降の手順について説明する。ゲートウェイ装置は、ネットワークに対してサービスS1についてのリソース予約要求SIPINVITEを送信し手順608、ネットワークからの200OKの受信により、リソース予約の完了を判定する手順609。その後、ゲートウェイ装置は参加要求MLDjoinを送信することにより、マルチキャストサービスS1への参加を実施する手順610。手順608~610は標準的な手順であるため、詳細な説明は省略する。サービス提供サーバ4-1及びネットワーク3は、リース予約要求SIPINVITEの受信によりリソース予約を実施し、参加要求MLDjoinを受けてIPv6マルチキャストデータの送信及びゲートウェイ装置への伝送を開始する手順611。ゲートウェイ装置2は、このマルチキャストデータを受信すると、それまで実施していたIPv6NAT機能のサービスS2からサービスS1へのマルチキャストデータの変換を停止し、サービスS1についてのマルチキャストデータ11を変換せずに端末に送信する。ここまでの手順により、端末への高品質のサービスS1の送信が開始されるが、端末はS2からS1への切替を意識する必要はない。すなわち、本発明を実施するに当たって端末に特別な追加機能を必要としない。本発明の実施の形態に係るゲートウェイ装置は、以上のような構成をしているため、ザッピング行動のような端末側の動作傾向及び、網側のリソース予約に要する時間などに基づいて、適切なサービスに対し適切なタイミングでマルチキャスト参加離脱要求ならびにリソース予約解放を行うことができるため、ネットワーク負荷の増大を抑制することができる。また、遅延を低減させることで、視聴者の体感品質を高めることができる。"