JP5708368B2 - ゲートウェイ装置、通信システムおよび通信制御方法 - Google Patents

Description

この発明は、例えば、ＩＰＴＶ(Internet Protocol Television)のように、ＩＰ(Internet Protocol)マルチキャストを使用したサービスを行う通信システムと、その通信システムに適用可能なゲートウェイ装置、および、その通信システムの通信制御方法に係る。

ＩＰネットワークにおいて利用されるマルチキャストの制御プロトコルとしてＩＧＭＰ(Internet Group Management Protocol)、ＭＬＤ(Multicast Listener Discovery)が標準化団体ＩＥＴＦ(Internet Engineering Task Force)によって標準化されている。また、これらのマルチキャスト制御プロトコルとＮＧＮ(Next Generation Network)との連携についても標準化が行われており、ＮＧＮの重要な基盤技術であるＳＩＰ(Session Initiation Protocol)との連携によって、リソース予約、ＱｏＳ（Quality of Service）などの機能を備えた高度なマルチキャストサービスの方式が標準化されている（例えば、非特許文献１参照）。

一方、マルチキャストを使用したサービスを受信する既存のマルチキャスト受信装置は、ＩＧＭＰ、ＭＬＤに対応する機能を備えているものの、標準化されてから日の浅いＳＩＰとの連携機能については備えていないものが多い。そこで、マルチキャストに対応する上位ネットワークからのマルチキャストデータを中継するゲートウェイ装置で対応することが検討されており、例えば、特許文献１は、既存のマルチキャスト受信装置からのＩＧＭＰ、ＭＬＤメッセージの受信を契機として、ＳＩＰとの連携を実施する機能を有するゲートウェイ装置について開示されている。この装置によれば、ＮＧＮの機能に対応していいないマルチキャスト受信装置であっても、ＮＧＮ対応の高度なマルチキャストサービスを享受することができる。

特開２０１０−２５２１１０号公報

ETSI TS 183 063 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification

ＩＰマルチキャストを実現するにはルーティングを行う必要があるが、一般的にＩＰマルチキャストのルーティングはユニキャストと比較して複雑であり、ネットワークの計算量が大きくなる。特にマルチキャストにおいてリソース予約やＱｏＳを考慮したルーティングを行う場合にはさらに複雑な計算を要する。一方、ザッピングと呼ばれる、頻繁にチャネル変更を行う視聴行動は、テレビサービスの視聴者に広くみられる傾向がある。ＩＰ ＴＶサービスにおいては、ザッピングはマルチキャストルートの頻繁な変動を意味する場合があり、特にＮＧＮのような高度なマルチキャストサービスにおいては、多数の視聴者のザッピングによって、ネットワークのルート・リソース予約の再計算負荷が特に大きくなる。このようなネットワーク負荷の増大は、ルート・リソース予約処理の遅延による視聴者の体感品質の低下や、ネットワーク装置の処理能力向上のための設備コストの増大という課題が生じる事となる。

本発明は上述の課題を解決するためになされたものであり、マルチキャストサービスを下部端末に提供しながら、マルチキャストルートの頻繁な変動等が発生した場合においてもリソース予約・解放の回数を抑制することで、頻繁な再計算によるネットワーク負荷の増大を抑制し、上述の課題を解消するゲートウェイ装置を提供することを目的とする。

この発明に係るゲートウェイ装置は、
端末と端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、端末が提供を希望するマルチキャストサービスについてのサービス提供要求を、ゲートウェイ装置を介してネットワークに送信することによりマルチキャストサービスを提供する通信システムに適用可能なゲートウェイ装置であって、端末からマルチキャストサービスについてのサービス提供要求を受信する要求受信手段と、要求受信手段により受信されたマルチキャストサービスについてのサービス提供要求の受信履歴を管理する端末挙動情報管理手段と、要求受信手段により受信されたサービス提供要求の種別に基づいて、端末が提供を受けるマルチキャストサービスを選択し、選択されたマルチキャストサービスについてのサービス提供要求をネットワークへ送信するサービス選択手段と、要求受信手段により受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスがサービス選択手段により選択された場合、端末挙動情報管理手段により管理された受信履歴に基づいて、要求受信手段により受信されたサービス提供要求をネットワークに送信するタイミングを決定し、受信履歴が予め定められた頻度以上である場合にはネットワークへのサービス提供要求の送信を保留し、予め定められた期間に要求受信手段により新たなサービス提供要求が受信されると保留しておいたサービス提供要求を破棄する送信タイミング決定手段と、を備える。

また、この発明に係る通信制御方法は、端末と端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、端末が提供を希望するマルチキャストサービスについてのサービス提供要求を、ゲートウェイ装置を介してネットワークに送信することによりマルチキャストサービスを提供する通信システムに適用可能な通信制御方法であって、ゲートウェイ装置が、端末からマルチキャストサービスについてのサービス提供要求を受信する参加要求受信ステップと、参加要求受信ステップにおいて受信したサービス提供要求の種別に基づいて、端末が提供を受けるマルチキャストサービスを選択し、選択されたマルチキャストサービスについてのサービス提供要求をネットワークへ送信するサービス選択ステップと、サービス選択ステップにおいて、参加要求受信ステップにおいて受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスが選択された場合、参加要求受信ステップにおいて受信されたサービス提供要求の受信履歴に基づいて、参加要求受信ステップにおいて受信されたサービス提供要求をネットワークに送信するタイミングを決定し、受信履歴が予め定められた頻度以上である場合にはネットワークへのサービス提供要求の送信を保留し、予め定められた期間に参加要求受信ステップにより新たなサービス提供要求が受信されると保留しておいたサービス提供要求を破棄する参加要求送信ステップと、を備える。

また、この発明に係る通信システムは、端末と端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、端末が提供を希望するマルチキャストサービスについての参加要求を、ゲートウェイ装置を介してネットワークに送信することによりマルチキャストサービスを提供する通信システムであって、端末からマルチキャストサービスについてのサービス提供要求を受信する要求受信手段と、要求受信手段により受信されたマルチキャストサービスについてのサービス提供要求の受信履歴を管理する端末挙動情報管理手段と、要求受信手段により受信されたサービス提供要求の種別に基づいて、端末が提供を受けるマルチキャストサービスを選択し、選択されたマルチキャストサービスについてのサービス提供要求をネットワークへ送信するサービス選択手段と、サービス選択手段において、要求受信手段により受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスが選択された場合、端末挙動情報管理手段により管理された受信履歴に基づいて、要求受信手段により受信されたサービス提供要求をネットワークに送信するタイミングを決定し、受信履歴が予め定められた頻度以上である場合にはネットワークへのサービス提供要求の送信を保留し、予め定められた期間に要求受信手段により新たなサービス提供要求が受信されると保留しておいたサービス提供要求を破棄する送信タイミング決定手段と、を備える。

本発明によれば、端末側のザッピング行動のようなマルチキャストルートの変動が頻繁に起こるような場合においても、より適切にマルチキャスト参加要求ならびにリソース予約を行うことができるため、ネットワーク負荷の増大を抑制することができる。

本発明の実施の形態１に示すネットワークの構成図である。 本発明の実施の形態１に示すゲートウェイ装置の内部機能を表す構成図を示す。 本発明の実施の形態１に示すネットワークの情報の流れを示すシーケンス図である。 本発明の実施の形態１に示すサービス情報の例を示す図である。 本発明の実施の形態１に示す網挙動情報の例を示す図である。 本発明の実施の形態１に示す端末挙動情報の例を示す図である。

実施の形態１．
本発明の実施の形態に係るゲートウェイ装置を適用したネットワークシステムについて図面を参照して説明する。図１は、本発明にかかるネットワークシステムの構成図である。図１において、視聴端末１−１〜ｎは、マルチキャストのサービスを受信するための標準的な機能を備えた端末である。視聴端末１−１〜ｎは、少なくともＩＧＭＰ，ＭＬＤのようなマルチキャスト参加・離脱要求の機能を備え、マルチキャストサービスに用いるパケット方式はＩＰｖ６を用いるものとする。また、ここでは視聴端末１−１〜ｎはＳＩＰに対応し、リソース予約・解放の機能を備えているとして説明するが、ＳＩＰ等のリソース予約・解放の機能に対応していない場合であってもよい。

ゲートウェイ装置（以下、適宜ゲートウェイと略記する）２は、視聴端末（以下、適宜端末と略記する）１−１〜ｎとネットワーク３を中継する位置に配置される。また、ネットワーク３にはサービス提供サーバ４−１〜ｎが接続されている。なお、視聴端末１−１〜ｎを総称する場合、または、区別をしない場合には、視聴端末１（または、単に端末１）と表記する。サービス提供サーバ４−１〜ｎについても同様である。

ネットワーク３は、ＮＧＮのようなセッション制御機能を備えたサービスネットワークであり、ここでは、ＳＩＰに対応するものとして説明する。また、リソース予約などのサービスを提供するセッション制御部３１と、パケットを転送する転送ノード３２−０〜ｎとを備える。セッション制御部３１は、サービス顧客（視聴端末）からの要求を受けて、転送ノードのリソースを予約する機能を有する。転送ノード３２−０〜ｎは、セッション制御部３１からの制御によって予約されたリソースを使用してパケットを転送する機能を有し、パケットをサービス顧客に伝達する役割を担う。このうち、特に転送ノード３２−０は、サービス顧客に接続される転送ノードである。サービス提供サーバ４−１〜ｎは、ＩＰＴＶ等のサービスを提供するために、マルチキャストを送信するサーバである。

図２は、ゲートウェイ装置２の特徴的な内部機能構成、機能間インタフェース、及びノード間インタフェースを模式的に示した図である。図２において、マルチキャスト管理部２０は、端末挙動情報管理部２１、サービス情報管理部２２、網挙動情報管理部２３を参照し、制御ポリシーに従って、ＳＩＰ Ｂ２Ｂ ＵＡ（back-to-Back User Agent）部２４、ＭＬＤ Ｐｒｏｘｙ部２５、ＩＰｖ６ ＮＡＴ（Network Address Translation）部２６を制御する機能を有する。例えば、マルチキャスト管理部２０は、過去のＳＩＰ Ｂ２Ｂ ＵＡ部２４、ＭＬＤ Ｐｒｏｘｙ部２５の制御履歴から、端末がザッピングを行っているかどうかを検出する。また、ＳＩＰ Ｂ２Ｂ ＵＡ部２４、ＭＬＤ Ｐｒｏｘｙ部２５の制御結果を受け取り、端末挙動情報部２１、サービス情報管理部２２、網挙動情報管理部２３に格納された情報を更新する。

端末挙動情報管理部２１は、ゲートウェイ装置に接続される端末のマルチキャスト制御の傾向などを示す端末挙動情報を格納しており、例えば、各端末が過去に行ったＳＩＰ Ｂ２Ｂ ＵＡ部２４、ＭＬＤ Ｐｒｏｘｙ部２５の制御履歴、すなわち、端末からのリソース予約要求やマルチキャストサービスへの参加要求等の受信履歴を格納する。また、端末１の能力、端末１が利用可能なサービス、および端末１の優先度などを格納することも出来る。ＳＩＰ Ｂ２Ｂ ＵＡ部２４、ＭＬＤ Ｐｒｏｘｙ部２５の制御履歴は、マルチキャスト管理部２０がＳＩＰ Ｂ２Ｂ ＵＡ２４、ＭＬＤ Ｐｒｏｘｙ部２５の動作を監視することによって取得し、内部インタフェース２０１を経由して、マルチキャスト管理部２０から端末挙動情報部２１に通知される。

上述した形態に加え、もしくは、代わりに、端末挙動情報部２１がノード間インタフェース２１１、２２２によって、端末１やネットワーク３から端末挙動情報を取得するようにしてもよい。ノード間インタフェース２１１は、端末が自身の能力などを通知するために使用するもので、一般的にはＨＴＴＰやＳＩＰよって実装する。端末挙動情報部２１が備えるノード間インタフェース２２２は、ネットワークが端末や回線の利用可能なサービス、優先度を通知するために使用するもので、同様に一般的にはＨＴＴＰやＳＩＰによって実装する。

サービス情報管理部２２は、ネットワークがゲートウェイ装置に対して提供することが出来るマルチキャストサービスの内容を示すサービス情報を格納しており、例えば、少なくともサーバの識別子と、マルチキャストグループの識別子を格納する。また、コンテンツの内容を示す情報、リソース予約の要否、サービスが必要とするリソースの情報を含むことが出来る。ここでは、ゲートウェイ装置は、ＨＴＴＰやＳＩＰによって実装されるノード間インタフェース２２２により、ネットワークから上記情報を取得する。

上述した形態に加え、もしくは、代わりに、サービス情報２２がノード間インタフェース２１２、内部インタフェース２０２によって、端末１やマルチキャスト管理部２０から上記情報を取得することも可能である。ノード間インタフェース２１２は、端末側から上記情報を通知するために使用するためのもので、一般的にはＨＴＴＰやＳＩＰよって実装する。また、内部インタフェース２０２を用いて上記情報を取得する場合、上記情報はゲートウェイ装置２に固定的に設定されたものを使用する。

網挙動情報管理部２３は、網挙動情報を管理しており、例えば、ネットワークがサービスに対してマルチキャスト参加・離脱、リソース予約・解放に要する計算量と時間を示す、もしくは上記計算量と時間を推測するための情報を管理する。ここでは、ＨＴＴＰやＳＩＰよって実装するノード間インタフェース２２３によってネットワークから、上記計算量と時間を管理するものとする。

上述した形態に加え、もしくは、代わりに、網挙動情報２３がノード間インタフェース２１３、内部インタフェース２０３によって、端末１やマルチキャスト管理部２０から上記情報を取得することも可能である。ノード間インタフェース２１３は、端末から上記情報を通知するために使用するためのもので、一般的にはＨＴＴＰやＳＩＰよって実装する。内部インタフェース２０３を用いて、上記情報を取得する場合、上記情報は、例えばマルチキャスト管理部２０が測定した、過去にサービスに対するリソース予約を行った際に要した時間の統計値のような、ゲートウェイ装置で測定可能な情報である。

ＳＩＰ Ｂ２Ｂ ＵＡ部２４は、リソース予約を行うためのＳＩＰ通信を制御する。ＳＩＰによるリソース予約機能を具備している端末１及びネットワーク３とＳＩＰ（ノード間インタフェース２１４、２２４）により通信する。一般的なＳＩＰを中継する機能に加え、マルチキャスト管理部２０が、端末側と網側の通信を制御する。

ＭＬＤ ｐｒｏｘｙ部２５は、マルチキャスト参加・離脱を行うためのＭＬＤ通信を制御する機能である。ＭＬＤによるマルチキャスト参加・離脱機能を具備している端末１及びネットワーク３とＭＬＤ（ノード間インタフェース２１５、２２５）により通信する。単純なＭＬＤ中継機能ではなく、マルチキャスト管理部２０が、端末側と網側の通信を制御する。一般的なＭＬＤプロキシ機能は、複数の端末から受信したＭＬＤメッセージを集約し、マルチキャストグループアドレス・送信元アドレスの参加状態を管理し、その状態を網側に通知する機能であるが、本発明では、これに加え、マルチキャスト管理部２０の制御により、端末側のマルチキャストグループアドレス・送信元アドレスを別のアドレスに変換して網側に通知する機能を備える。

ＩＰｖ６ ＮＡＴ部２６は、ネットワークから受信するマルチキャストストリームのアドレス変換を実施し、端末側へ送信する。マルチキャスト管理部２０の制御により、ＭＬＤ Ｐｒｏｘｙ部２５でアドレス変換した結果をマルチキャストストリームに反映するための機能である。

次に、図３を参照して、本発明の実施の形態１に係るネットワークシステムの動作について説明する。ゲートウェイ装置２は、予めネットワーク３から、サービス情報を取得する。ゲートウェイ装置２は、サービス情報要求信号（ＨＴＴＰ Ｇｅｔ）を送信し（手順５０１）、ネットワーク３は応答信号（２００ ＯＫ）と共に自身が保持するサービス情報を送信する（手順５０２）。図４は、本手順で取得したサービス情報の例を示す。図４に示すサービス情報の例では、サービス提供サーバ４１が提供する高品質のサービスＳ１とサービス提供サーバ４２が提供する低品質のサービスＳ２の情報を示している。ここで、サービスＳ１およびＳ２のコンテンツ内容はいずれもＡで同じであるが、高品質のサービスＳ１はリソース予約を必要とするのに対し、低品質のサービスＳ２はリソース予約が不要である。

また、ゲートウェイ装置２は、ネットワーク３から網挙動情報を取得する。ゲートウェイ装置２は、網挙動情報要求信号（ＳＩＰ Ｎｏｔｉｆｙ）を送信し（手順５０３）、ネットワーク３は応答信号（２００ ＯＫ）と共に自身が保持する網挙動情報を送信する（手順５０４）。図５は本手順で取得した網側挙動情報の例を示す。図５に示す網挙動情報の例は、サービス提供サーバ４１が提供する高品質のサービスＳ１のリソース予約に要する計算量が大きく、３秒の遅延時間が予測されることを示している。ここで、遅延時間とは、ゲートウェイ装置２がサービス提供要求、すなわち、マルチキャストサービスへの参加要求またはリソース予約要求を送信してからサービス提供サーバからマルチキャストが配信されるまでの時間を指すものとするが、これに限定されるものではなく、同様の内容を指す時間であればよい。また、サービス提供サーバ４２が提供するサービスＳ２は、０．５秒の遅延時間が予測されることを示している。これらの手順は、ゲートウェイ装置がネットワークに接続したときや情報に変化があった場合に、必要な情報について実施される。

端末からのサービス提供要求が発生した際の情報の流れについて説明する。ここでサービス提供要求とは、端末またはゲートウェイ装置が送信するマルチキャストサービスへの参加要求をいい、端末またはネットワークがリソース予約機能に対応し、リソース予約を行う場合には、端末またはゲートウェイ装置が送信するリソース予約要求も含むものとする。ここでは、端末１−１がサービスＳ１の提供を要求する場合について説明する。

サービスＳ１はサービスの提供にあたり、リソース予約を必要とするため、まず、端末がリソース予約を実施する必要がある。端末１−１はサービスＳ１の受信を開始するため、Ｓ１に対するリソース予約要求を意味するＳＩＰ ＩＮＶＩＴＥを送信する（手順６０１）。ゲートウェイ装置２は、ＳＩＰ Ｂ２Ｂ ＵＡ部２４がＳＩＰ ＩＮＶＩＴＥを受信し、マルチキャスト管理部２０がサービス情報及び網挙動情報を参照して、受信したＳＩＰ ＩＮＶＩＴＥの種別を判断する。リソース予約の計算量が予め定められた所定の予測遅延（例えば、１秒間）より大きいこと、および、同内容かつ予測遅延の小さいサービスＳ２が存在することから、端末１−１に配信するマルチキャストサービスをサービスＳ２とすることを決定する。

また、端末挙動情報に基づいて、ネットワークに対してリソース予約を実施するタイミングを決定し、スケジューリングを行う。リソース予約を実施するタイミングの決定方法については、詳細を後述する。このリソース予約の実施タイミングの決定に基づいて、ＳＩＰ Ｂ２Ｂ ＵＡ部２４を制御し、２００ ＯＫを端末に返す（手順６０２）。この手順により端末は、リソース予約が完了したものとして動作する。なお、端末がリソース予約の機能を持たない場合、手順６０１、６０２は省略してもよい。この場合、端末１−１から受信した参加要求（ＭＬＤ Ｊｏｉｎ）の種別を判断し、端末１−１に配信するマルチキャストサービスを決定する。

次に、端末１がゲートウェイ装置２に対して、マルチキャストサービスＳ１への参加要求（ＭＬＤ ｊｏｉｎ）を送信する（手順６０３）。図３に示す例では、端末１−１がサービスＳ１についての参加要求をゲートウェイ装置２に送信する。ゲートウェイ装置２は、ＭＬＤ Ｐｒｏｘｙ部２５がサービスＳ１についての参加要求（ＭＬＤ ｊｏｉｎ）を受信するが、上述のように、予測遅延の小さいサービスＳ２を配信することを決定しているため、マルチキャスト管理部２０は、ネットワークに対して、マルチキャストＳ２に参加するＭＬＤ ｊｏｉｎの送信を行う（手順６０４）。また、ＩＰｖ６ ＮＡＴ部２６に対して、サービス提供サーバ４２から送信されるサービスＳ２のマルチキャストパケットを、サービスＳ１のマルチキャストパケットに変換する設定を行う。

サービス提供サーバ４−２及びネットワーク３は、ゲートウェイ装置２から送信されたＭＬＤ ｊｏｉｎを受けてＩＰｖ６マルチキャストデータの送信及びゲートウェイ装置への伝送を開始する（手順６０５）。ゲートウェイ装置２は、サービス提供サーバ４−２からマルチキャストデータを受信すると、ＩＰｖ６ ＮＡＴ機能が上記設定に基づき、サービスＳ１に対応するマルチキャストデータへの変換を実施し、端末に送信する（手順６０６）。ここまでの一連の動作によって、端末はリソース予約に要する時間を待たずに、とりあえず低品質のサービスの受信を開始することができる。端末が最初に要求した高品質のサービスの受信を開始するにはリソース予約の完了を待つ必要があるためが、とりあえず低品質のサービスを早い時期に受信することでユーザの体感遅延を軽減させる効果を得ることができる。

次に、リソース予約を実施するタイミングの決定方法について説明する。ゲートウェイ装置が端末１−１から受信したサービス提供要求についてのサービスＳ１へのリソース予約を開始するタイミング（６０７）を端末挙動情報に基づいて決定する。本タイミングの決定を行う方法について説明する。図６は、端末挙動情報の例を示している。図６では、端末１−１に対応する端末識別子をＴ１、端末１−２に対応する識別子をＴ２としている。図６に示す端末挙動情報では、過去に行ったチャンネル切替履歴（サービス提供要求受信履歴）を管理しており、図６に示す例では、端末識別子Ｔ１に対応する端末では、２秒前、５秒前、６秒前にチャンネル切替を行っており、端末識別子Ｔ２に対応する端末では、３０分前にチャンネル切替を行っていることがわかる。

サービス提供要求（手順６０１、手順６０３）を実施した端末Ｔ１が、チャネル切替履歴から数秒間隔でチャネル切替を頻繁におこなっていることから、ザッピング中と判定する。一方、端末識別子Ｔ２に対応する端末は、過去３０分間チャンネル切替が行われていないため、ザッピング中ではないと判定する。この判定基準は実装もしくは設定ポリシーによってさまざまな形式をとることができる。例えば過去１０秒以内に３回以上のチャネル切替が行われた場合、直近のチャネル切替が５秒以内に行われた場合などである。また、網挙動情報の予測遅延を加味して上記判断をすることもできる。

上述の判定において、端末がザッピング中であると判定した場合、ゲートウェイ装置は判定した時点から一定期間の後にタイミング６０７をスケジューリングし、サービス参加要求のネットワークへの送信を保留する。この一定期間の間にこの端末から新たにサービス提供要求を受信した場合、保留しておいたサービス提供要求を破棄し、新たに受信したサービス提供要求に対して上述の判定を行い、リソース予約を開始するタイミング６０７を決定する。また、上述のように新たに受信したサービス提供要求の種別を判断し、ネットワーク３に送信するサービス提供要求を選択する。これらの動作を繰り返し、一定期間中に新たなサービス提供要求を受信しない場合に、ネットワーク３に対して端末１より受信したサービス提供要求を転送することができる。

端末がザッピング中でないと判定した場合、ゲートウェイ装置は判定した時点でタイミング６０７をスケジューリングする。すなわち、タイミング６０７以降の手順と、それ以前の手順は並行して動作することができる。本制御により、ザッピングによる頻繁なリソース予約を抑制し、ネットワークにおける負荷を低減する効果を得ることが出来る。

タイミング６０７以降の手順について説明する。ゲートウェイ装置は、ネットワークに対してサービスＳ１についてのリソース予約要求（ＳＩＰ ＩＮＶＩＴＥ）を送信し（手順６０８）、ネットワークからの２００ ＯＫの受信により、リソース予約の完了を判定する（手順６０９）。その後、ゲートウェイ装置は参加要求（ＭＬＤ ｊｏｉｎ）を送信することにより、マルチキャストサービスＳ１への参加を実施する（手順６１０）。手順６０８〜６１０は標準的な手順であるため、詳細な説明は省略する。サービス提供サーバ４−１及びネットワーク３は、リース予約要求（ＳＩＰ ＩＮＶＩＴＥ）の受信によりリソース予約を実施し、参加要求（ＭＬＤ ｊｏｉｎ）を受けてＩＰｖ６マルチキャストデータの送信及びゲートウェイ装置への伝送を開始する（手順６１１）。ゲートウェイ装置２は、このマルチキャストデータを受信すると、それまで実施していたＩＰｖ６ ＮＡＴ機能のサービスＳ２からサービスＳ１へのマルチキャストデータの変換を停止し、サービスＳ１についてのマルチキャストデータ１１を変換せずに端末に送信する。

ここまでの手順により、端末への高品質のサービスＳ１の送信が開始されるが、端末はＳ２からＳ１への切替を意識する必要はない。すなわち、本発明を実施するに当たって端末に特別な追加機能を必要としない。

本発明の実施の形態に係るゲートウェイ装置は、以上のような構成をしているため、ザッピング行動のような端末側の動作傾向及び、網側のリソース予約に要する時間などに基づいて、適切なサービスに対し適切なタイミングでマルチキャスト参加・離脱要求ならびにリソース予約・解放を行うことができるため、ネットワーク負荷の増大を抑制することができる。また、遅延を低減させることで、視聴者の体感品質を高めることができる。

１−１〜ｎ 視聴端末、２ ゲートウェイ装置、３ ネットワーク、４−１〜ｎ サービス提供端末、２０ マルチキャスト管理部、２１ 端末挙動情報管理部、２２ サービス情報管理部、２３ 網挙動情報管理部、２４ ＳＩＰ Ｂ２Ｂ ＵＡ部、２５ ＭＬＤ Ｐｒｏｘｙ部、２６ ＩＰｖ６ ＮＡＴ部、３１ セッション制御部、３２−０〜ｎ 転送ノード

Claims (9)

1. 端末と前記端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、前記端末が提供を希望するマルチキャストサービスについてのサービス提供要求を、前記ゲートウェイ装置を介して前記ネットワークに送信することにより前記マルチキャストサービスを提供する通信システムに適用可能なゲートウェイ装置であって、
   前記端末からマルチキャストサービスについてのサービス提供要求を受信する要求受信手段と、
   前記要求受信手段により受信されたマルチキャストサービスについてのサービス提供要求の受信履歴を管理する端末挙動情報管理手段と、
   前記要求受信手段により受信されたサービス提供要求の種別に基づいて、前記端末が提供を受けるマルチキャストサービスを選択し、前記選択されたマルチキャストサービスについてのサービス提供要求を前記ネットワークへ送信するサービス選択手段と、
   前記要求受信手段により受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスが前記サービス選択手段により選択された場合、前記端末挙動情報管理手段により管理された前記受信履歴に基づいて、前記要求受信手段により受信されたサービス提供要求を前記ネットワークに送信するタイミングを決定し、前記受信履歴が予め定められた頻度以上である場合には前記ネットワークへのサービス提供要求の送信を保留し、予め定められた期間に前記要求受信手段により新たなサービス提供要求が受信されると保留しておいたサービス提供要求を破棄する送信タイミング決定手段と、
   を備えることを特徴とするゲートウェイ装置。
2. 前記送信タイミング決定手段により送信するタイミングが決定されるサービス提供要求は、ネットワークにおけるリソース予約を行うリソース予約要求と特定のマルチキャストグループへの参加を要求する参加要求からなることを特徴とする請求項１に記載のゲートウェイ装置。
3. 前記マルチキャストサービスの提供についての前記ネットワークにおける遅延時間を管理する網挙動情報管理手段をさらに備え、
   前記送信タイミング決定手段は、前記網挙動情報管理手段により管理された網挙動情報に基づいて、前記要求受信手段により受信されたサービス提供要求を前記ネットワークに送信するタイミングを決定すること、
   を特徴とする請求項１または２のいずれかに記載のゲートウェイ装置。
4. 前記サービス選択手段において、前記要求受信手段により受信された参加要求のマルチキャストサービスと異なるマルチキャストサービスが選択された場合、前記ネットワークから受信するマルチキャストパケットを前記端末が送信したサービス提供要求のマルチキャストサービスを示すマルチキャストパケットにアドレス変換して上記端末に送信するアドレス変換手段をさらに備えること、
   を特徴とする請求項１〜３のいずれか１項に記載のゲートウェイ装置。
5. 前記マルチキャストサービスを行う制御方式がＩＧＭＰｖ３（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ３）であり、
   前記マルチキャストサービスに用いるパケット方式がＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ６）であること、
   を特徴とする請求項１〜４のいずれか１項に記載のゲートウェイ装置。
6. 前記マルチキャストサービスを行う制御方式がＭＬＤｖ２（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ ｖｅｒｓｉｏｎ２）であり、
   前記マルチキャストサービスに用いるパケット方式がＩＰｖ６であること、
   を特徴とする請求項１〜４のいずれか１項に記載のゲートウェイ装置。
7. 前記リソース予約の方式がＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ)であること、
   を特徴とする請求項２に記載のゲートウェイ装置。
8. 端末と前記端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、前記端末が提供を希望するマルチキャストサービスについてのサービス提供要求を、前記ゲートウェイ装置を介して前記ネットワークに送信することにより前記マルチキャストサービスを提供する通信システムに適用可能な通信制御方法であって、
   前記ゲートウェイ装置が、前記端末からマルチキャストサービスについてのサービス提供要求を受信する参加要求受信ステップと、
   前記参加要求受信ステップにおいて受信したサービス提供要求の種別に基づいて、前記端末が提供を受けるマルチキャストサービスを選択し、前記選択されたマルチキャストサービスについてのサービス提供要求を前記ネットワークへ送信するサービス選択ステップと、
   前記サービス選択ステップにおいて、前記参加要求受信ステップにおいて受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスが選択された場合、前記参加要求受信ステップにおいて受信されたサービス提供要求の受信履歴に基づいて、前記参加要求受信ステップにおいて受信されたサービス提供要求を前記ネットワークに送信するタイミングを決定し、前記受信履歴が予め定められた頻度以上である場合には前記ネットワークへのサービス提供要求の送信を保留し、予め定められた期間に前記参加要求受信ステップにより新たなサービス提供要求が受信されると保留しておいたサービス提供要求を破棄する参加要求送信ステップと、
   を備えることを特徴とする通信制御方法。
9. 端末と前記端末に複数のマルチキャストサービスを提供可能なネットワークとに接続されたゲートウェイ装置を備え、前記端末が提供を希望するマルチキャストサービスについての参加要求を、前記ゲートウェイ装置を介して前記ネットワークに送信することにより前記マルチキャストサービスを提供する通信システムであって、
   前記端末からマルチキャストサービスについてのサービス提供要求を受信する要求受信手段と、
   前記要求受信手段により受信されたマルチキャストサービスについてのサービス提供要求の受信履歴を管理する端末挙動情報管理手段と、
   前記要求受信手段により受信されたサービス提供要求の種別に基づいて、前記端末が提供を受けるマルチキャストサービスを選択し、前記選択されたマルチキャストサービスについてのサービス提供要求を前記ネットワークへ送信するサービス選択手段と、
   前記サービス選択手段において、前記要求受信手段により受信されたサービス提供要求のマルチキャストサービスと異なるマルチキャストサービスが選択された場合、前記端末挙動情報管理手段により管理された前記受信履歴に基づいて、前記要求受信手段により受信されたサービス提供要求を前記ネットワークに送信するタイミングを決定し、前記受信履歴が予め定められた頻度以上である場合には前記ネットワークへのサービス提供要求の送信を保留し、予め定められた期間に前記要求受信手段により新たなサービス提供要求が受信されると保留しておいたサービス提供要求を破棄する送信タイミング決定手段と、
   を備えることを特徴とする通信システム。

Images