JP3720026B2 - 同一ネットワーク上でｍｃａｐを支援する機器の識別方法及びこれを利用したマルチキャスト通信方法 - Google Patents
同一ネットワーク上でｍｃａｐを支援する機器の識別方法及びこれを利用したマルチキャスト通信方法 Download PDFInfo
- Publication number
- JP3720026B2 JP3720026B2 JP2003056220A JP2003056220A JP3720026B2 JP 3720026 B2 JP3720026 B2 JP 3720026B2 JP 2003056220 A JP2003056220 A JP 2003056220A JP 2003056220 A JP2003056220 A JP 2003056220A JP 3720026 B2 JP3720026 B2 JP 3720026B2
- Authority
- JP
- Japan
- Prior art keywords
- mcap
- channel
- network
- message
- multicast
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は同一ネットワーク上でＭＣＡＰを支援する機器と支援しない機器とが同時に存在する時にこれらの機器がＭＣＡＰを支援するか否かを識別する方法及びこれを利用したマルチキャスト通信方法に関する。
【０００２】
【従来の技術】
従来のマルチキャスト通信方法は同じネットワーク、例えば、ＩＥＥＥ１３９４ネットワークに属する機器がＭＣＡＰを支援するか否かと関係なくブロードキャストチャンネルを利用したマルチキャスト通信を行う。この場合、あらゆる機器がＭＣＡＰを支援しても無駄にブロードキャスト方式を使用してＭＣＡＰ機能自体が無效化され、これによりマルチキャスト通信の核心機能である選択的伝送機能を使用できなくなるという結果を招く。
【０００３】
【発明が解決しようとする課題】
本発明は前記の問題点を解決するために考案されたものであり、同一ネットワーク上でＭＣＡＰを支援する機器の識別方法を提供することをその目的とする。
【０００４】
本発明の他の目的は、前記の識別方法を利用したマルチキャスト通信方法を提供することにある。
【０００５】
【課題を解決するための手段】
前記の目的を達成する本発明によるＭＣＡＰを支援するか否かの識別方法は、（ａ）ＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器に対してＭＣＡＰブロードキャストメッセージをブロードキャストする過程と、（ｂ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器にＩＧＭＰ照会メッセージをブロードキャストする過程と、（ｃ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器からのＩＧＭＰ報告メッセージが伝送されるチャンネル番号により、各機器がＭＣＡＰを支援するか否かを識別する過程とを含むことを特徴とする。
【０００６】
前記他の目的を達成する本発明によるマルチキャスト通信方法は、（ａ）ＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器に対してＭＣＡＰブロードキャストメッセージをブロードキャストする過程と、（ｂ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器にＩＧＭＰ照会メッセージをブロードキャストする過程と、（ｃ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器からのＩＧＭＰ報告メッセージが伝送されるチャンネル番号により各機器がＭＣＡＰを支援するか否かを識別する過程と、（ｅ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたあらゆる機器からのＩＧＭＰ報告メッセージがマルチキャストチャンネルを通じて伝送されれば、該当マルチキャストアドレスに対する送受信をマルチキャストチャンネルを利用して行い、一つでもブロードキャストチャンネルを通じて伝送されれば、該当マルチキャストアドレスに対する送受信をブロードキャストチャンネルを利用して行う過程とを含むことを特徴とする。
【０００７】
【発明の実施の形態】
以下、添付した図面を参照して本発明の構成及び動作を詳細に説明する。
【０００８】
インターネットの伝送方式は伝送に参加する送信者と受信者との観点でユニキャスト、ブロードキャスト、そしてマルチキャストに区分できる。
【０００９】
図１は、ユニキャスト方式、ブロードキャスト方式、そしてマルチキャスト方式を図式的に示した図面である。
【００１０】
ユニキャスト伝送方式は、一人の送信者が他の一人の受信者にデータを伝送する方式であって、一般的なインターネットアプリケーションがいずれもこのユニキャスト方式を使用している。一方、ブロードキャスト伝送方式は、一人の送信者が同じサブネットワーク上のあらゆる受信者にデータを伝送する方式である。
【００１１】
一方、マルチキャスト伝送方式は、一人以上の送信者が特定の一人以上の受信者にデータを伝送する方式であって、インターネット画像会議などの応用として使われる。
【００１２】
グループ通信のために多重受信者に同じデータを伝送しようとする場合、ユニキャスト伝送方式を利用するならば伝送しようとするデータパケットを多数の受信者に各々数回伝送せねばならず、このような同じパケットの重複伝送によりネットワーク効率が低下する。また受信者の数が増加する場合にこのような問題点はより大きくなる。
【００１３】
一方、マルチキャスト伝送が支援されれば送信者は一回にメッセージが伝送できて、データの重複伝送によるネットワーク資源の浪費を最小化できる。
【００１４】
マルチキャスト伝送の一般的なユニキャスト伝送との違いはまずその伝送パケットにある。一般的にＴＣＰ／ＩＰ上のインターネット応用プログラムは、データの送信者がこれを受信する受信者のインターネットアドレスを伝送パケットのヘッダに表示してパケットを伝送する。しかし、マルチキャスト伝送のためにはヘッダに受信者のアドレスの代わりに受信者が所属されているグループアドレスを表示してパケットを伝送する。
【００１５】
マルチキャスト伝送のためのグループアドレスはＤ級ＩＰアドレス（２２４．０．０．０−２３９．２５５．２５５．２５５）であって、全世界個々のインターネットホストを示すＡ、Ｂ、Ｃ級ＩＰアドレスとは異なって実際のホストを表すアドレスではなく、グループアドレスを有するマルチキャストパケットを伝送された受信者は自分がパケットのグループに属しているかどうかを判断してパケットの受容可否を決定する。
【００１６】
ＩＰマルチキャストアドレッシングは、ＲＦＣ１１１２（Ｈｏｓｔ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ ＩＰ Ｍｕｌｔｉｃａｓｔｉｎｇ）に規定されたインターネット標準であって、多数のワークステーション企業（ＳＵＮ、ＳＧＩ、ＤＥＣ、ＨＰ等）で支援しており、公式的にＩＰ級Ｄアドレスと規定化されている。
【００１７】
Ｄ級のアドレス範囲は２２４．０．０．１から２３９．２５５．２５５．２５４までであり、このアドレスは特定のホストに唯一に指定されず、一つのマルチキャスト群に能動的に割当てられるという点が以前までのアドレス割当て方式と異なる。
【００１８】
Ｄ級を認識できる、すなわち、ＩＰマルチキャストを支援するワークステーションは、支援された固有アドレス以外に自ら属しているか／属したいマルチキャスト群のアドレス２つを利用して情報を交換するが、一つのホストがある群を新しく形成するか、これに属しようとする時に交換せねばならない方式を規定したものがＩＧＭＰというプロトコルである。このように構成されたマルチキャスト群を表示する代表的な手段がｓｄ（ｓｅｓｓｉｏｎ ｄｉｓｐｌａｙ）であるが、これを使用すれば現在運営中のマルチキャスト群とこれらの構成要素が何かを確認できる。
【００１９】
一方、次世代ホームネットワーク用インターフェース技術で注目され始めたＩＥＥＥ１３９４は本来ハードディスクインターフェースとしてアップル社で１９８６年に開発され始めた。以後にＩＢＭとソニー社が加勢して標準化作業が進み、１９９４年にはＩＥＥＥ１３９４の普及を目的として１３９４ Ｔｒａｄｅ Ａｓｓｏｃｉａｔｉｏｎが設立された。
【００２０】
１９９５年には正式にＩＥＥＥ Ｓｔｄ １３９４−１９９５という名称で標準規格が承認されたが、この標準案では３つの高速伝送速度で１００Ｍｂｐｓ、２００Ｍｂｐｓ、４００Ｍｂｐｓが規格化されている。また２０００年にこの機能を追加して補完したＩＥＥＥ Ｓｔｄ １３９４ａ−２０００標準が規格化された。
【００２１】
図２は、ＩＥＥＥ１３９４において各階層の関係を図式的に示したものである。
【００２２】
ＩＥＥＥ１３９４−１９９５は物理層、リンク層、そしてトランザクション層の３階層よりなるハードウェア及びソフトウェア標準である。図２は、これら３階層の関係とそれぞれの機能を図式的に表現している。通常的にＩＥＥＥ１３９４ホストアダプタは物理層及びリンク層の役割を行い、ホストではトランザクション層及びバス管理機能を担当する。物理層は主にシリアルバスを使用できる権利を取得する仲裁機能を行い、バスのサイクル制御はデータリンク層で担当する。トランザクション層はネットワーク装置の基本機能−読出し、書込み−を行い、バス制御機能では同時性伝送に必要な資源管理などを担当する。
【００２３】
ＩＥＥＥ１３９４のインターフェースは、６本の銅線で構成されたシリアルインターフェースを基本とするが、これら６本は各々２対の信号線と１対の電源線とよりなる。２対の信号線は半二重で使われるが、１対はデータ信号を、他の１対はデータのサンプリング同期化のためのタイミング信号を伝送するのに使われる。この１対の信号線をタイミング情報として使用する理由は、伝送速度が高速であるためにデータにマンチェスターコーディング（ｍａｎｃｈｅｓｔｅｒ ｃｏｄｉｎｇ）のようなタイミング情報を含む場合に伝送速度が２倍に増加することを防止するためである。
【００２４】
ＩＥＥＥ１３９４を支援する機器をノードと呼ぶが、ノードを連結する最も一般的な物理的連結方式はツリー構造であり、使用方式はバス構造である。すなわち、任意の時間に一つのノードだけがデータを伝送でき、連結されたあらゆるノードが受信できる。
【００２５】
ＩＰマルチキャストをＩＥＥＥ１３９４ネットワーク上で支援するための規格はＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、インターネット標準規格を開発しているＩＡＢ（Ｉｎｔｅｒｎｅｔ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｂｏａｒｄ）傘下の調査委員会）のｄｒａｆｔ−ｉｅｔｆ−ｉｐ１３９４−ｉｐｖ６とｄｒａｆｔ−ｉｅｔｆ−ｉｐ１３９４−ｍｃａｐとで定義しており、ＩＰｖ４での場合はＲＦＣ２７３４（ＩＰｖ４ ｏｖｅｒ ＩＥＥＥ１３９４）に定義されている。これらの規格でＩＰマルチキャストパケットは、非同期ストリーム伝送モードと等時性ストリーム伝送モードとを利用して支援するように規定している。この時、使用するモードはＩＰパケットのサービス要求性格によって選択される。すなわち、非同期ストリーム方式はベストエフォート（Ｂｅｓｔ−Ｅｆｆｏｒｔ）サービス、等時性ストリーム方式はＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を要求するパケットに対して使われる。
【００２６】
このような２つの伝送方法ではノード番号の代りにチャンネル番号を使用して伝送するが、チャンネル番号の割当てと返還及び帯域幅の割当てなどの過程はＣＡＭ（Ｃｈａｎｎｅｌ Ａｌｌｏｃａｔｉｏｎ Ｍａｎａｇｅｒ）でＭＣＡＰプロトコルを使用して実行する。ＣＡＭはマルチキャストソースまたはグループ所属者の要請を受けてマルチキャストチャンネル及び帯域幅を割り当てる。この時に使われる要請及び応答パケットはＭＣＡＰプロトコルを使用する。
【００２７】
前記ＭＣＡＰではチャンネルの割当てについて２つの方法を定義している。
第１に、ＩＰ機能を行うあらゆるノード（ＩＥＥＥ１３９４を支援する機器）が基本的に共有するブロードキャストチャンネルを利用する方法。
第２に、ブロードキャストチャンネル以外のチャンネルを割り当てて利用する方法。
【００２８】
第１の方法は別のプロトコルを使用せずにマルチキャスト通信を行えるが、不要なパケットが機器に受信されるので機器の演算負荷を増大させる結果を招く。
【００２９】
第２の方法の場合、特定マルチキャスト群に属する一つの機器が該当マルチキャスト群アドレスに対するチャンネルを割当てられ、ＭＣＡＰブロードキャストメッセージを通じてネットワーク上のあらゆる機器に該当マルチキャストアドレスと割当てられたチャンネルとの連繋性を知らせる。ＭＣＡＰブロードキャストメッセージを受けたネットワーク上のあらゆるノードは指定されたチャンネルを通じて該当マルチキャストパケットを送／受信せねばならない。
【００３０】
ＩＥＥＥ１３９４ネットワーク上のあらゆる機器が前記第１の場合のようにブロードキャストチャンネルを使用する場合にはマルチキャスト通信に問題が発生しない。ただ、ブロードキャストを行うことによって不要なパケットが該当マルチキャスト群に属していない機器の演算負荷を増大させる現象を甘受せねばならない。
【００３１】
ネットワーク上のあらゆる機器が前記第２の場合のようにＭＣＡＰメッセージを解釈し、これによりチャンネルを調整するＭＣＡＰ支援機器である場合にも問題が発生しない。この場合には不要なパケットの受信を最小化できる。
【００３２】
このように、あらゆる機器がＭＣＡＰ機能を具現しない場合や、あるいはあらゆる機器がＭＣＡＰを支援する場合にはマルチキャスト通信に問題が発生しない。
【００３３】
しかし、現在としてはＩＥＥＥ１３９４ネットワーク上でのあらゆるノードがＭＣＡＰを支援できず、ＭＣＡＰ支援機器と非支援機器とが混在しているために不便なブロードキャスト方式によりマルチキャスト通信を行っているのが実情である。
【００３４】
図３は、ＩＥＥＥ１３９４ネットワーク上での従来のマルチキャスト通信方式を図式的に示したものである。
【００３５】
従来のＩＥＥＥ１３９４ネットワーク上でのマルチキャスト通信方式には、図３（ａ）に図示されたように一つのマルチキャストメッセージをブロードキャストチャンネル（チャンネルｌ３１）を通じてあらゆる機器に伝達する方式を利用する。このような場合、ＭＣＡＰ支援機器３０２、３０６や非支援機器３０４に関係なくあらゆる機器がマルチキャストメッセージをブロードキャストできるように構成することによって利用可能である。
【００３６】
しかし、例えば、ＭＣＡＰ支援機器３０６がブロードキャストチャンネルを利用する代わりに図３（ｂ）のように他のチャンネル、例えば、チャンネル７を割り当ててマルチキャスト通信を行う場合には問題が発生する。
【００３７】
すなわち、ＭＣＡＰ支援機器３０６がマルチキャストアドレス（例えば、２３９．２５５．２５５．２５０）に対してチャンネル７を割り当ててＭＣＡＰメッセージを伝送し、これを認識したＭＣＡＰ支援機器３０２が２３９．２５５．２５５．２５０のアドレスを有するマルチキャストメッセージをチャンネル７を通じて伝送するならば、ＭＣＡＰ非支援機器３０４はこのマルチキャストメッセージを受けられなくなる。
【００３８】
このようにＭＣＡＰを支援しなくてブロードキャストチャンネルだけでマルチキャストを行うように固定されたＭＣＡＰ非支援機器とＭＣＡＰ支援機器とが一つのネットワーク上に共存する場合には両機器間の通信に難しさがある。
【００３９】
すなわち、ＭＣＡＰ支援機器が、特定マルチキャストアドレスに対してブロードキャストチャンネル以外のチャンネルを割り当て、これをＭＣＡＰブロードキャストメッセージを通じてネットワーク内のあらゆる機器に知らせても、ＭＣＡＰ非支援機器はブロードキャストチャンネルでマルチキャストパケットを送受信するように固定されているために、異に割り当てられたチャンネルのパケットを受信できなくなる。
【００４０】
このような問題はホームネットワーク環境で深刻な問題を引き起こすことがある。今後展開されるホームネットワーク環境ではパソコンとノート型パソコン、パームトップ型パソコン、ＴＶセットトップボックス（Ｓｅｔ Ｔｏｐ Ｂｏｘ；ＳＴＢ）、ビデオゲーム機、プリンタ、モデム、スキャナー等想像できるあらゆるコンピュータ機器と共に携帯電話、インターネットフォン、デジタル応答機、ポケベル、冷蔵庫、トースターなどの家庭用生活機器が一斉に接続される。
【００４１】
ホームネットワークにおいてホストに接続される機器はネットワークＰｎＰ（Ｐｌｕｇ ａｎｄ Ｐｌａｙ）機能により接続される。
【００４２】
例えば、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）はマイクロソフト社により開発されたものであって、サンマイクロシステム社により開発されたＪｉｎｉ（ジニー）（登録商標）のようにネットワークＰｎＰの一種である。
【００４３】
ＵＰｎＰの場合、装置を対話式に連結する中継子であって、新しいネットワークプロトコルを使用する。すなわち、ハイパーテキスト伝送プロトコルであるＨＴＴＰのように、ウェブサーバーに接続したコンピュータの種類に関係なくＨＴＴＰプロトコルを要請するデータを適材適所に配る方式である。実際にウィンドウ２０００からはＩＰＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ）というプロトコルを支援、ネットワーク上で接続したプリンタを利用して使用者の文書を遠隔出力できるように具現した。もちろん、ＩＰＰプロトコルは使用者の運営体制及びプリンタ製造、機種などにこだわらない。
【００４４】
一方、Ｊｉｎｉ（登録商標）において、はＭＳのＩＰＰのようなプロトコルの役割をＪａｖａ（登録商標）が担当する。現存する大部分のパソコンは、Ｊａｖａ（登録商標）を支援するウェブブラウザだけあればサーバーからＪａｖａ（登録商標）アプレットをダウンロードして動作する。したがって、この点に着眼して装置を認識させるＪａｖａ（登録商標）アプレットを支援して、随時ダウンロードし、必要としない時には機械上で直ちに消えるように具現した。その核心がＲＭＩ（Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ）である。特に使用者の立場ではＪａｖａ（登録商標）アプレットをダウンロードするか、消えさせる過程が肉眼で識別できない長所がある。
【００４５】
このようなネットワークＰｎＰにより可変性／拡張性を有するホームネットワークにおいて、ＩＥＥＥ１３９４ネットワーク上に存在する機器間のトラフィックを効率的に管理する必要があり、特に、マルチキャスト通信のために不要なパケットが伝送されることを防止する必要がある。
【００４６】
これを解決するために本発明では、同一ネットワーク上にＭＣＡＰを支援しない機器の存否をＩＧＭＰ照会／報告メッセージを利用して把握し、ＭＣＡＰを支援しない機器が存在する場合にのみＭＣＡＰ支援機器がブロードキャストチャンネルを使うようにし、あらゆる機器がＭＣＡＰを支援する場合にはＭＣＡＰプロトコルによってマルチキャスト伝送を行うようにする。
【００４７】
このようにすれば、ＩＥＥＥ１３９４ネットワーク上であるマルチキャストグループに属しているあらゆる機器がＭＣＡＰを支援するのにも無駄にブロードキャストチャンネルを利用して機器の演算負荷を与えることを防止でき、たとえ該当マルチキャストグループにＭＣＡＰ非支援機器があったとしてもマルチキャスト通信を行える効果を得ることができる。
【００４８】
図４は、本発明によるＭＣＡＰを支援するか否かの識別方法を示すフローチャートであり、図５は、図４に示された過程を図式的に示したものである。
【００４９】
図４及び図５を参照して、本発明によるＭＣＡＰを支援するか否かの識別方法を詳細に説明する。
【００５０】
まず、図４に示されたように、ＭＣＡＰ支援機器がブロードキャストチャンネルではない任意のチャンネルをマルチキャストアドレスに割り当てた後、このマルチキャストチャンネルを通じて同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器に対してＭＣＡＰブロードキャストメッセージをブロードキャストする（Ｓ４０２）。
【００５１】
例えば、図５に示されたように、マルチキャスト群２３９．２５５．２５５．２５０に所属されているＭＣＡＰ支援機器４０２がチャンネル７をマルチキャストアドレスに割り当てた後、ブロードキャストチャンネル（チャンネル３１）を通じて同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器にＭＣＡＰブロードキャストメッセージをブロードキャストする。
【００５２】
次に、ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２が、ブロードキャストチャンネル（チャンネル３１）を通じて同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器４０４、４０６にＩＧＭＰ照会メッセージをブロードキャストする（Ｓ４０４）。
【００５３】
ＩＧＭＰプロトコルはマルチキャストグループに対する加入／脱退処理を担当する。ＩＧＭＰは、マルチキャストルータが該当サブネットに存在するホストグループメンバーの存在を認識するのに使われる。
【００５４】
ＩＧＭＰプロトコルは基本的に照会及び報告メッセージを使用する。照会メッセージは、ＩＧＭＰプロトコルが該当グループに加入するホストの有無を尋ねるメッセージである。これは現在グループのメンバーを確認するためにサブネットに周期的に伝送される。報告メッセージは照会メッセージに対する応答であって、グループに加入する意思があるホストだけが送る。
【００５５】
ＩＧＭＰが該当サブネットに照会メッセージを送れば該当マルチキャストグループへの加入を所望するホストだけが報告メッセージを送ることによってグループに加入できる。グループの脱退は一定時間照会メッセージに対する応答がなければなされる。
【００５６】
ＭＣＡＰ支援機器４０２はマルチキャスト群２３９．２５５．２５５．２５０に対するＩＧＭＰ照会メッセージをブロードキャストする（Ｓ４０４）。
【００５７】
ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２は、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からＩＧＭＰメッセージを受信する（Ｓ４０６）。
【００５８】
ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２は、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネルｌ７）を通じて伝送されたかどうかを判断する（Ｓ４０８）。
【００５９】
ＩＥＥＥ１３９４ネットワーク上でマルチキャスト群２３９．２５５．２５５．２５０に所属されている機器４０４、４０６はＩＧＭＰ照会メッセージに対する応答としてＩＧＭＰ報告メッセージを伝送する。ＩＧＭＰ報告の目的アドレスは、ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器、すなわち、ＩＧＭＰ照会メッセージをブロードキャストしたＭＣＡＰ支援機器４０２となる。
【００６０】
ＭＣＡＰ支援機器４０６は、該当マルチキャストアドレス２３９．２５５．２５５．２５０に対するチャンネル番号をＭＣＡＰブロードキャストメッセージによって既に知っているので、チャンネル７を通じてＩＧＭＰ報告を伝送する。
【００６１】
一方、ＭＣＡＰ非支援機器４０４は、ＭＣＡＰブロードキャストメッセージを認識しないためにブロードキャストチャンネル（チャンネル３１）を通じてＩＧＭＰ報告を伝送する。
【００６２】
したがって、ＭＣＡＰ支援機器４０２は、これらのＩＧＭＰメッセージが伝送されるチャンネル番号を確認して各機器４０４、４０６がＭＣＡＰを支援するか否かを確認することができる。
【００６３】
もし、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されたならば、ＭＣＡＰ支援機器４０２は同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器がＭＣＡＰを支援すると判断する（Ｓ４１０）。
【００６４】
一方、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されなかったならば、ＭＣＡＰ支援機器４０２は同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器が全部ＭＣＡＰを支援することではないと判断する（Ｓ４１２）。
【００６５】
ＭＣＡＰブロードキャストメッセージには終了時間（ｅｘｐｉｒｅ ｔｉｍｅ）フィールドが含まれる。終了時間フィールドは、ＭＣＡＰブロードキャストメッセージにより指定されたチャンネルを維持するための時間を設定するためのものである。ＭＣＡＰ支援機器は、終了時間フィールドで指定された時間の間に指定されたチャンネルをマルチキャストのために維持する。
【００６６】
同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されなかったならば、ＭＣＡＰブロードキャストメッセージにより指定されたチャンネルを維持する必要がない。
【００６７】
これにより同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されなかったならば、終了時間＝０（直ちに解除）という内容を有するＭＣＡＰブロードキャストメッセージを同じネットワーク上のあらゆる機器にブロードキャストしてマルチキャストのために指定されたチャンネルを解除するようにする（Ｓ４１４）。
【００６８】
図６は、本発明によるマルチキャスト通信方法を示すフローチャートであり、図７は、図６に示された方法を図式的に示したものである。
【００６９】
図６及び図７を参照して本発明によるマルチキャスト通信方法を詳細に説明する。
【００７０】
まず、図６に示されたように、あるマルチキャスト群に所属されているＭＣＡＰ支援機器４０２がブロードキャストチャンネルではない任意のチャンネル（マルチキャストチャンネル、例えば、チャンネル７）をマルチキャストアドレスに割り当て、このマルチキャストチャンネルを通じて同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器にＭＣＡＰブロードキャストメッセージをブロードキャストする（Ｓ６０２）。
【００７１】
次に、ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２がブロードキャストチャンネルを通じて同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器にＩＧＭＰ照会メッセージをブロードキャストする（Ｓ６０４）。
【００７２】
ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２は、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からＩＧＭＰメッセージを受信する（Ｓ６０６）。
【００７３】
ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２は、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されたかどうかを判断する（Ｓ６０８）。
【００７４】
ＩＥＥＥ１３９４ネットワーク上でマルチキャスト群２３９．２５５．２５５．２５０に所属されている機器４０４、４０６は、ＩＧＭＰ照会メッセージに対する応答としてＩＧＭＰ報告メッセージを伝送する。ＩＧＭＰ報告の目的アドレスは、ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器、すなわち、ＩＧＭＰ照会メッセージをブロードキャストしたＭＣＡＰ支援機器４０２となる。
【００７５】
ＭＣＡＰ支援機器４０６は、該当マルチキャストアドレス２３９．２５５．２５５．２５０に対するチャンネル番号をＭＣＡＰブロードキャストメッセージによって既に知っているので、チャンネル７を通じてＩＧＭＰ報告を伝送する。
【００７６】
一方、ＭＣＡＰ非支援機器４０４は、ＭＣＡＰブロードキャストメッセージを認識しないために、ブロードキャストチャンネル（チャンネル３１）を通じてＩＧＭＰ報告を伝送する。
【００７７】
したがって、ＭＣＡＰ支援機器４０２は、これらのＩＧＭＰメッセージが伝送されるチャンネル番号を確認して各機器４０４、４０６がＭＣＡＰを支援するか否かを確認できる。
【００７８】
もし、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されたならば、ＭＣＡＰ支援機器４０２は同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器がＭＣＡＰを支援すると判断する（Ｓ６１０）。ＭＣＡＰ支援機器４０２は、マルチキャストチャンネルを利用して該当マルチキャストアドレスに対する送受信を行う（Ｓ６１６）。
【００７９】
一方、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されなかったならば、ＭＣＡＰ支援機器４０２は同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器が全部ＭＣＡＰを支援することではないと判断する（Ｓ６１２）。ＭＣＡＰ支援機器４０２は、終了時間＝０（直ちに解除）という内容を有するＭＣＡＰブロードキャストメッセージを同じネットワーク上のあらゆる機器にブロードキャストする（Ｓ６１４）。
【００８０】
ＭＣＡＰ支援機器４０２は、ブロードキャストチャンネルを利用して該当マルチキャストアドレスに対する送受信を行う（Ｓ６１６）。
【００８１】
図７に示されたように、ＭＣＡＰ支援機器４０２は、あらゆるＩＧＭＰ報告が指定されたチャンネルチャンネル７を通じて受信されれば、該当マルチキャストアドレス２３９．２５５．２５５．２５０に対する送受信を割り当てられたチャンネルチャンネル７を利用して行い、一方、一つでもブロードキャストチャンネル（チャンネル３１）を通じてＩＧＭＰ報告が受信されれば、ＭＣＡＰ支援機器４０２もブロードキャストチャンネル（チャンネル３１）を使用してブロードキャストする。
【００８２】
すなわち、あるマルチキャストグループに属しているあらゆる機器がＭＣＡＰを支援する場合にはＭＣＡＰプロトコルによるマルチキャスト通信を行い、ＭＣＡＰを支援しない機器が存在する場合にはブロードキャスト方式を利用したマルチキャスト通信を行う。
【００８３】
【発明の効果】
前述したように、本発明によるＩＥＥＥ１３９４ネットワーク上でマルチキャストグループに属しているあらゆる機器がＭＣＡＰを支援するのにも無駄にブロードキャストチャンネルを利用して機器の演算負荷を与えることを防止でき、たとえ、マルチキャストグループに属している機器のうちにＭＣＡＰ非支援機器があったとしてもマルチキャスト通信ができる。
【図面の簡単な説明】
【図１】 ユニキャスト方式、ブロードキャスト方式、そしてマルチキャスト方式を図式的に示した図面である。
【図２】 ＩＥＥＥ１３９４において各階層の関係を図式的に示した図面である。
【図３】 （ａ），（ｂ）ともに、ＩＥＥＥ１３９４ネットワーク上での従来のマルチキャスト通信方式を図式的に示した図面である。
【図４】 本発明によるＭＣＡＰを支援するか否かの識別方法を示すフローチャートである。
【図５】 図４に示された過程を図式的に示した図面である。
【図６】 本発明によるマルチキャスト通信方法を示すフローチャートである。
【図７】 図６に示された方法を図式的に示した図面である。
【符号の説明】
３０２，３０６，４０２，４０６ ＭＣＡＰ支援機器
３０４，４０４ ＭＣＡＰ非支援機器
【発明の属する技術分野】
本発明は同一ネットワーク上でＭＣＡＰを支援する機器と支援しない機器とが同時に存在する時にこれらの機器がＭＣＡＰを支援するか否かを識別する方法及びこれを利用したマルチキャスト通信方法に関する。
【０００２】
【従来の技術】
従来のマルチキャスト通信方法は同じネットワーク、例えば、ＩＥＥＥ１３９４ネットワークに属する機器がＭＣＡＰを支援するか否かと関係なくブロードキャストチャンネルを利用したマルチキャスト通信を行う。この場合、あらゆる機器がＭＣＡＰを支援しても無駄にブロードキャスト方式を使用してＭＣＡＰ機能自体が無效化され、これによりマルチキャスト通信の核心機能である選択的伝送機能を使用できなくなるという結果を招く。
【０００３】
【発明が解決しようとする課題】
本発明は前記の問題点を解決するために考案されたものであり、同一ネットワーク上でＭＣＡＰを支援する機器の識別方法を提供することをその目的とする。
【０００４】
本発明の他の目的は、前記の識別方法を利用したマルチキャスト通信方法を提供することにある。
【０００５】
【課題を解決するための手段】
前記の目的を達成する本発明によるＭＣＡＰを支援するか否かの識別方法は、（ａ）ＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器に対してＭＣＡＰブロードキャストメッセージをブロードキャストする過程と、（ｂ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器にＩＧＭＰ照会メッセージをブロードキャストする過程と、（ｃ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器からのＩＧＭＰ報告メッセージが伝送されるチャンネル番号により、各機器がＭＣＡＰを支援するか否かを識別する過程とを含むことを特徴とする。
【０００６】
前記他の目的を達成する本発明によるマルチキャスト通信方法は、（ａ）ＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器に対してＭＣＡＰブロードキャストメッセージをブロードキャストする過程と、（ｂ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器にＩＧＭＰ照会メッセージをブロードキャストする過程と、（ｃ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器からのＩＧＭＰ報告メッセージが伝送されるチャンネル番号により各機器がＭＣＡＰを支援するか否かを識別する過程と、（ｅ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたあらゆる機器からのＩＧＭＰ報告メッセージがマルチキャストチャンネルを通じて伝送されれば、該当マルチキャストアドレスに対する送受信をマルチキャストチャンネルを利用して行い、一つでもブロードキャストチャンネルを通じて伝送されれば、該当マルチキャストアドレスに対する送受信をブロードキャストチャンネルを利用して行う過程とを含むことを特徴とする。
【０００７】
【発明の実施の形態】
以下、添付した図面を参照して本発明の構成及び動作を詳細に説明する。
【０００８】
インターネットの伝送方式は伝送に参加する送信者と受信者との観点でユニキャスト、ブロードキャスト、そしてマルチキャストに区分できる。
【０００９】
図１は、ユニキャスト方式、ブロードキャスト方式、そしてマルチキャスト方式を図式的に示した図面である。
【００１０】
ユニキャスト伝送方式は、一人の送信者が他の一人の受信者にデータを伝送する方式であって、一般的なインターネットアプリケーションがいずれもこのユニキャスト方式を使用している。一方、ブロードキャスト伝送方式は、一人の送信者が同じサブネットワーク上のあらゆる受信者にデータを伝送する方式である。
【００１１】
一方、マルチキャスト伝送方式は、一人以上の送信者が特定の一人以上の受信者にデータを伝送する方式であって、インターネット画像会議などの応用として使われる。
【００１２】
グループ通信のために多重受信者に同じデータを伝送しようとする場合、ユニキャスト伝送方式を利用するならば伝送しようとするデータパケットを多数の受信者に各々数回伝送せねばならず、このような同じパケットの重複伝送によりネットワーク効率が低下する。また受信者の数が増加する場合にこのような問題点はより大きくなる。
【００１３】
一方、マルチキャスト伝送が支援されれば送信者は一回にメッセージが伝送できて、データの重複伝送によるネットワーク資源の浪費を最小化できる。
【００１４】
マルチキャスト伝送の一般的なユニキャスト伝送との違いはまずその伝送パケットにある。一般的にＴＣＰ／ＩＰ上のインターネット応用プログラムは、データの送信者がこれを受信する受信者のインターネットアドレスを伝送パケットのヘッダに表示してパケットを伝送する。しかし、マルチキャスト伝送のためにはヘッダに受信者のアドレスの代わりに受信者が所属されているグループアドレスを表示してパケットを伝送する。
【００１５】
マルチキャスト伝送のためのグループアドレスはＤ級ＩＰアドレス（２２４．０．０．０−２３９．２５５．２５５．２５５）であって、全世界個々のインターネットホストを示すＡ、Ｂ、Ｃ級ＩＰアドレスとは異なって実際のホストを表すアドレスではなく、グループアドレスを有するマルチキャストパケットを伝送された受信者は自分がパケットのグループに属しているかどうかを判断してパケットの受容可否を決定する。
【００１６】
ＩＰマルチキャストアドレッシングは、ＲＦＣ１１１２（Ｈｏｓｔ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ ＩＰ Ｍｕｌｔｉｃａｓｔｉｎｇ）に規定されたインターネット標準であって、多数のワークステーション企業（ＳＵＮ、ＳＧＩ、ＤＥＣ、ＨＰ等）で支援しており、公式的にＩＰ級Ｄアドレスと規定化されている。
【００１７】
Ｄ級のアドレス範囲は２２４．０．０．１から２３９．２５５．２５５．２５４までであり、このアドレスは特定のホストに唯一に指定されず、一つのマルチキャスト群に能動的に割当てられるという点が以前までのアドレス割当て方式と異なる。
【００１８】
Ｄ級を認識できる、すなわち、ＩＰマルチキャストを支援するワークステーションは、支援された固有アドレス以外に自ら属しているか／属したいマルチキャスト群のアドレス２つを利用して情報を交換するが、一つのホストがある群を新しく形成するか、これに属しようとする時に交換せねばならない方式を規定したものがＩＧＭＰというプロトコルである。このように構成されたマルチキャスト群を表示する代表的な手段がｓｄ（ｓｅｓｓｉｏｎ ｄｉｓｐｌａｙ）であるが、これを使用すれば現在運営中のマルチキャスト群とこれらの構成要素が何かを確認できる。
【００１９】
一方、次世代ホームネットワーク用インターフェース技術で注目され始めたＩＥＥＥ１３９４は本来ハードディスクインターフェースとしてアップル社で１９８６年に開発され始めた。以後にＩＢＭとソニー社が加勢して標準化作業が進み、１９９４年にはＩＥＥＥ１３９４の普及を目的として１３９４ Ｔｒａｄｅ Ａｓｓｏｃｉａｔｉｏｎが設立された。
【００２０】
１９９５年には正式にＩＥＥＥ Ｓｔｄ １３９４−１９９５という名称で標準規格が承認されたが、この標準案では３つの高速伝送速度で１００Ｍｂｐｓ、２００Ｍｂｐｓ、４００Ｍｂｐｓが規格化されている。また２０００年にこの機能を追加して補完したＩＥＥＥ Ｓｔｄ １３９４ａ−２０００標準が規格化された。
【００２１】
図２は、ＩＥＥＥ１３９４において各階層の関係を図式的に示したものである。
【００２２】
ＩＥＥＥ１３９４−１９９５は物理層、リンク層、そしてトランザクション層の３階層よりなるハードウェア及びソフトウェア標準である。図２は、これら３階層の関係とそれぞれの機能を図式的に表現している。通常的にＩＥＥＥ１３９４ホストアダプタは物理層及びリンク層の役割を行い、ホストではトランザクション層及びバス管理機能を担当する。物理層は主にシリアルバスを使用できる権利を取得する仲裁機能を行い、バスのサイクル制御はデータリンク層で担当する。トランザクション層はネットワーク装置の基本機能−読出し、書込み−を行い、バス制御機能では同時性伝送に必要な資源管理などを担当する。
【００２３】
ＩＥＥＥ１３９４のインターフェースは、６本の銅線で構成されたシリアルインターフェースを基本とするが、これら６本は各々２対の信号線と１対の電源線とよりなる。２対の信号線は半二重で使われるが、１対はデータ信号を、他の１対はデータのサンプリング同期化のためのタイミング信号を伝送するのに使われる。この１対の信号線をタイミング情報として使用する理由は、伝送速度が高速であるためにデータにマンチェスターコーディング（ｍａｎｃｈｅｓｔｅｒ ｃｏｄｉｎｇ）のようなタイミング情報を含む場合に伝送速度が２倍に増加することを防止するためである。
【００２４】
ＩＥＥＥ１３９４を支援する機器をノードと呼ぶが、ノードを連結する最も一般的な物理的連結方式はツリー構造であり、使用方式はバス構造である。すなわち、任意の時間に一つのノードだけがデータを伝送でき、連結されたあらゆるノードが受信できる。
【００２５】
ＩＰマルチキャストをＩＥＥＥ１３９４ネットワーク上で支援するための規格はＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、インターネット標準規格を開発しているＩＡＢ（Ｉｎｔｅｒｎｅｔ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｂｏａｒｄ）傘下の調査委員会）のｄｒａｆｔ−ｉｅｔｆ−ｉｐ１３９４−ｉｐｖ６とｄｒａｆｔ−ｉｅｔｆ−ｉｐ１３９４−ｍｃａｐとで定義しており、ＩＰｖ４での場合はＲＦＣ２７３４（ＩＰｖ４ ｏｖｅｒ ＩＥＥＥ１３９４）に定義されている。これらの規格でＩＰマルチキャストパケットは、非同期ストリーム伝送モードと等時性ストリーム伝送モードとを利用して支援するように規定している。この時、使用するモードはＩＰパケットのサービス要求性格によって選択される。すなわち、非同期ストリーム方式はベストエフォート（Ｂｅｓｔ−Ｅｆｆｏｒｔ）サービス、等時性ストリーム方式はＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を要求するパケットに対して使われる。
【００２６】
このような２つの伝送方法ではノード番号の代りにチャンネル番号を使用して伝送するが、チャンネル番号の割当てと返還及び帯域幅の割当てなどの過程はＣＡＭ（Ｃｈａｎｎｅｌ Ａｌｌｏｃａｔｉｏｎ Ｍａｎａｇｅｒ）でＭＣＡＰプロトコルを使用して実行する。ＣＡＭはマルチキャストソースまたはグループ所属者の要請を受けてマルチキャストチャンネル及び帯域幅を割り当てる。この時に使われる要請及び応答パケットはＭＣＡＰプロトコルを使用する。
【００２７】
前記ＭＣＡＰではチャンネルの割当てについて２つの方法を定義している。
第１に、ＩＰ機能を行うあらゆるノード（ＩＥＥＥ１３９４を支援する機器）が基本的に共有するブロードキャストチャンネルを利用する方法。
第２に、ブロードキャストチャンネル以外のチャンネルを割り当てて利用する方法。
【００２８】
第１の方法は別のプロトコルを使用せずにマルチキャスト通信を行えるが、不要なパケットが機器に受信されるので機器の演算負荷を増大させる結果を招く。
【００２９】
第２の方法の場合、特定マルチキャスト群に属する一つの機器が該当マルチキャスト群アドレスに対するチャンネルを割当てられ、ＭＣＡＰブロードキャストメッセージを通じてネットワーク上のあらゆる機器に該当マルチキャストアドレスと割当てられたチャンネルとの連繋性を知らせる。ＭＣＡＰブロードキャストメッセージを受けたネットワーク上のあらゆるノードは指定されたチャンネルを通じて該当マルチキャストパケットを送／受信せねばならない。
【００３０】
ＩＥＥＥ１３９４ネットワーク上のあらゆる機器が前記第１の場合のようにブロードキャストチャンネルを使用する場合にはマルチキャスト通信に問題が発生しない。ただ、ブロードキャストを行うことによって不要なパケットが該当マルチキャスト群に属していない機器の演算負荷を増大させる現象を甘受せねばならない。
【００３１】
ネットワーク上のあらゆる機器が前記第２の場合のようにＭＣＡＰメッセージを解釈し、これによりチャンネルを調整するＭＣＡＰ支援機器である場合にも問題が発生しない。この場合には不要なパケットの受信を最小化できる。
【００３２】
このように、あらゆる機器がＭＣＡＰ機能を具現しない場合や、あるいはあらゆる機器がＭＣＡＰを支援する場合にはマルチキャスト通信に問題が発生しない。
【００３３】
しかし、現在としてはＩＥＥＥ１３９４ネットワーク上でのあらゆるノードがＭＣＡＰを支援できず、ＭＣＡＰ支援機器と非支援機器とが混在しているために不便なブロードキャスト方式によりマルチキャスト通信を行っているのが実情である。
【００３４】
図３は、ＩＥＥＥ１３９４ネットワーク上での従来のマルチキャスト通信方式を図式的に示したものである。
【００３５】
従来のＩＥＥＥ１３９４ネットワーク上でのマルチキャスト通信方式には、図３（ａ）に図示されたように一つのマルチキャストメッセージをブロードキャストチャンネル（チャンネルｌ３１）を通じてあらゆる機器に伝達する方式を利用する。このような場合、ＭＣＡＰ支援機器３０２、３０６や非支援機器３０４に関係なくあらゆる機器がマルチキャストメッセージをブロードキャストできるように構成することによって利用可能である。
【００３６】
しかし、例えば、ＭＣＡＰ支援機器３０６がブロードキャストチャンネルを利用する代わりに図３（ｂ）のように他のチャンネル、例えば、チャンネル７を割り当ててマルチキャスト通信を行う場合には問題が発生する。
【００３７】
すなわち、ＭＣＡＰ支援機器３０６がマルチキャストアドレス（例えば、２３９．２５５．２５５．２５０）に対してチャンネル７を割り当ててＭＣＡＰメッセージを伝送し、これを認識したＭＣＡＰ支援機器３０２が２３９．２５５．２５５．２５０のアドレスを有するマルチキャストメッセージをチャンネル７を通じて伝送するならば、ＭＣＡＰ非支援機器３０４はこのマルチキャストメッセージを受けられなくなる。
【００３８】
このようにＭＣＡＰを支援しなくてブロードキャストチャンネルだけでマルチキャストを行うように固定されたＭＣＡＰ非支援機器とＭＣＡＰ支援機器とが一つのネットワーク上に共存する場合には両機器間の通信に難しさがある。
【００３９】
すなわち、ＭＣＡＰ支援機器が、特定マルチキャストアドレスに対してブロードキャストチャンネル以外のチャンネルを割り当て、これをＭＣＡＰブロードキャストメッセージを通じてネットワーク内のあらゆる機器に知らせても、ＭＣＡＰ非支援機器はブロードキャストチャンネルでマルチキャストパケットを送受信するように固定されているために、異に割り当てられたチャンネルのパケットを受信できなくなる。
【００４０】
このような問題はホームネットワーク環境で深刻な問題を引き起こすことがある。今後展開されるホームネットワーク環境ではパソコンとノート型パソコン、パームトップ型パソコン、ＴＶセットトップボックス（Ｓｅｔ Ｔｏｐ Ｂｏｘ；ＳＴＢ）、ビデオゲーム機、プリンタ、モデム、スキャナー等想像できるあらゆるコンピュータ機器と共に携帯電話、インターネットフォン、デジタル応答機、ポケベル、冷蔵庫、トースターなどの家庭用生活機器が一斉に接続される。
【００４１】
ホームネットワークにおいてホストに接続される機器はネットワークＰｎＰ（Ｐｌｕｇ ａｎｄ Ｐｌａｙ）機能により接続される。
【００４２】
例えば、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）はマイクロソフト社により開発されたものであって、サンマイクロシステム社により開発されたＪｉｎｉ（ジニー）（登録商標）のようにネットワークＰｎＰの一種である。
【００４３】
ＵＰｎＰの場合、装置を対話式に連結する中継子であって、新しいネットワークプロトコルを使用する。すなわち、ハイパーテキスト伝送プロトコルであるＨＴＴＰのように、ウェブサーバーに接続したコンピュータの種類に関係なくＨＴＴＰプロトコルを要請するデータを適材適所に配る方式である。実際にウィンドウ２０００からはＩＰＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ）というプロトコルを支援、ネットワーク上で接続したプリンタを利用して使用者の文書を遠隔出力できるように具現した。もちろん、ＩＰＰプロトコルは使用者の運営体制及びプリンタ製造、機種などにこだわらない。
【００４４】
一方、Ｊｉｎｉ（登録商標）において、はＭＳのＩＰＰのようなプロトコルの役割をＪａｖａ（登録商標）が担当する。現存する大部分のパソコンは、Ｊａｖａ（登録商標）を支援するウェブブラウザだけあればサーバーからＪａｖａ（登録商標）アプレットをダウンロードして動作する。したがって、この点に着眼して装置を認識させるＪａｖａ（登録商標）アプレットを支援して、随時ダウンロードし、必要としない時には機械上で直ちに消えるように具現した。その核心がＲＭＩ（Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ）である。特に使用者の立場ではＪａｖａ（登録商標）アプレットをダウンロードするか、消えさせる過程が肉眼で識別できない長所がある。
【００４５】
このようなネットワークＰｎＰにより可変性／拡張性を有するホームネットワークにおいて、ＩＥＥＥ１３９４ネットワーク上に存在する機器間のトラフィックを効率的に管理する必要があり、特に、マルチキャスト通信のために不要なパケットが伝送されることを防止する必要がある。
【００４６】
これを解決するために本発明では、同一ネットワーク上にＭＣＡＰを支援しない機器の存否をＩＧＭＰ照会／報告メッセージを利用して把握し、ＭＣＡＰを支援しない機器が存在する場合にのみＭＣＡＰ支援機器がブロードキャストチャンネルを使うようにし、あらゆる機器がＭＣＡＰを支援する場合にはＭＣＡＰプロトコルによってマルチキャスト伝送を行うようにする。
【００４７】
このようにすれば、ＩＥＥＥ１３９４ネットワーク上であるマルチキャストグループに属しているあらゆる機器がＭＣＡＰを支援するのにも無駄にブロードキャストチャンネルを利用して機器の演算負荷を与えることを防止でき、たとえ該当マルチキャストグループにＭＣＡＰ非支援機器があったとしてもマルチキャスト通信を行える効果を得ることができる。
【００４８】
図４は、本発明によるＭＣＡＰを支援するか否かの識別方法を示すフローチャートであり、図５は、図４に示された過程を図式的に示したものである。
【００４９】
図４及び図５を参照して、本発明によるＭＣＡＰを支援するか否かの識別方法を詳細に説明する。
【００５０】
まず、図４に示されたように、ＭＣＡＰ支援機器がブロードキャストチャンネルではない任意のチャンネルをマルチキャストアドレスに割り当てた後、このマルチキャストチャンネルを通じて同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器に対してＭＣＡＰブロードキャストメッセージをブロードキャストする（Ｓ４０２）。
【００５１】
例えば、図５に示されたように、マルチキャスト群２３９．２５５．２５５．２５０に所属されているＭＣＡＰ支援機器４０２がチャンネル７をマルチキャストアドレスに割り当てた後、ブロードキャストチャンネル（チャンネル３１）を通じて同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器にＭＣＡＰブロードキャストメッセージをブロードキャストする。
【００５２】
次に、ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２が、ブロードキャストチャンネル（チャンネル３１）を通じて同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器４０４、４０６にＩＧＭＰ照会メッセージをブロードキャストする（Ｓ４０４）。
【００５３】
ＩＧＭＰプロトコルはマルチキャストグループに対する加入／脱退処理を担当する。ＩＧＭＰは、マルチキャストルータが該当サブネットに存在するホストグループメンバーの存在を認識するのに使われる。
【００５４】
ＩＧＭＰプロトコルは基本的に照会及び報告メッセージを使用する。照会メッセージは、ＩＧＭＰプロトコルが該当グループに加入するホストの有無を尋ねるメッセージである。これは現在グループのメンバーを確認するためにサブネットに周期的に伝送される。報告メッセージは照会メッセージに対する応答であって、グループに加入する意思があるホストだけが送る。
【００５５】
ＩＧＭＰが該当サブネットに照会メッセージを送れば該当マルチキャストグループへの加入を所望するホストだけが報告メッセージを送ることによってグループに加入できる。グループの脱退は一定時間照会メッセージに対する応答がなければなされる。
【００５６】
ＭＣＡＰ支援機器４０２はマルチキャスト群２３９．２５５．２５５．２５０に対するＩＧＭＰ照会メッセージをブロードキャストする（Ｓ４０４）。
【００５７】
ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２は、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からＩＧＭＰメッセージを受信する（Ｓ４０６）。
【００５８】
ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２は、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネルｌ７）を通じて伝送されたかどうかを判断する（Ｓ４０８）。
【００５９】
ＩＥＥＥ１３９４ネットワーク上でマルチキャスト群２３９．２５５．２５５．２５０に所属されている機器４０４、４０６はＩＧＭＰ照会メッセージに対する応答としてＩＧＭＰ報告メッセージを伝送する。ＩＧＭＰ報告の目的アドレスは、ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器、すなわち、ＩＧＭＰ照会メッセージをブロードキャストしたＭＣＡＰ支援機器４０２となる。
【００６０】
ＭＣＡＰ支援機器４０６は、該当マルチキャストアドレス２３９．２５５．２５５．２５０に対するチャンネル番号をＭＣＡＰブロードキャストメッセージによって既に知っているので、チャンネル７を通じてＩＧＭＰ報告を伝送する。
【００６１】
一方、ＭＣＡＰ非支援機器４０４は、ＭＣＡＰブロードキャストメッセージを認識しないためにブロードキャストチャンネル（チャンネル３１）を通じてＩＧＭＰ報告を伝送する。
【００６２】
したがって、ＭＣＡＰ支援機器４０２は、これらのＩＧＭＰメッセージが伝送されるチャンネル番号を確認して各機器４０４、４０６がＭＣＡＰを支援するか否かを確認することができる。
【００６３】
もし、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されたならば、ＭＣＡＰ支援機器４０２は同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器がＭＣＡＰを支援すると判断する（Ｓ４１０）。
【００６４】
一方、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されなかったならば、ＭＣＡＰ支援機器４０２は同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器が全部ＭＣＡＰを支援することではないと判断する（Ｓ４１２）。
【００６５】
ＭＣＡＰブロードキャストメッセージには終了時間（ｅｘｐｉｒｅ ｔｉｍｅ）フィールドが含まれる。終了時間フィールドは、ＭＣＡＰブロードキャストメッセージにより指定されたチャンネルを維持するための時間を設定するためのものである。ＭＣＡＰ支援機器は、終了時間フィールドで指定された時間の間に指定されたチャンネルをマルチキャストのために維持する。
【００６６】
同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されなかったならば、ＭＣＡＰブロードキャストメッセージにより指定されたチャンネルを維持する必要がない。
【００６７】
これにより同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されなかったならば、終了時間＝０（直ちに解除）という内容を有するＭＣＡＰブロードキャストメッセージを同じネットワーク上のあらゆる機器にブロードキャストしてマルチキャストのために指定されたチャンネルを解除するようにする（Ｓ４１４）。
【００６８】
図６は、本発明によるマルチキャスト通信方法を示すフローチャートであり、図７は、図６に示された方法を図式的に示したものである。
【００６９】
図６及び図７を参照して本発明によるマルチキャスト通信方法を詳細に説明する。
【００７０】
まず、図６に示されたように、あるマルチキャスト群に所属されているＭＣＡＰ支援機器４０２がブロードキャストチャンネルではない任意のチャンネル（マルチキャストチャンネル、例えば、チャンネル７）をマルチキャストアドレスに割り当て、このマルチキャストチャンネルを通じて同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器にＭＣＡＰブロードキャストメッセージをブロードキャストする（Ｓ６０２）。
【００７１】
次に、ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２がブロードキャストチャンネルを通じて同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器にＩＧＭＰ照会メッセージをブロードキャストする（Ｓ６０４）。
【００７２】
ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２は、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からＩＧＭＰメッセージを受信する（Ｓ６０６）。
【００７３】
ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器４０２は、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されたかどうかを判断する（Ｓ６０８）。
【００７４】
ＩＥＥＥ１３９４ネットワーク上でマルチキャスト群２３９．２５５．２５５．２５０に所属されている機器４０４、４０６は、ＩＧＭＰ照会メッセージに対する応答としてＩＧＭＰ報告メッセージを伝送する。ＩＧＭＰ報告の目的アドレスは、ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器、すなわち、ＩＧＭＰ照会メッセージをブロードキャストしたＭＣＡＰ支援機器４０２となる。
【００７５】
ＭＣＡＰ支援機器４０６は、該当マルチキャストアドレス２３９．２５５．２５５．２５０に対するチャンネル番号をＭＣＡＰブロードキャストメッセージによって既に知っているので、チャンネル７を通じてＩＧＭＰ報告を伝送する。
【００７６】
一方、ＭＣＡＰ非支援機器４０４は、ＭＣＡＰブロードキャストメッセージを認識しないために、ブロードキャストチャンネル（チャンネル３１）を通じてＩＧＭＰ報告を伝送する。
【００７７】
したがって、ＭＣＡＰ支援機器４０２は、これらのＩＧＭＰメッセージが伝送されるチャンネル番号を確認して各機器４０４、４０６がＭＣＡＰを支援するか否かを確認できる。
【００７８】
もし、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されたならば、ＭＣＡＰ支援機器４０２は同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器がＭＣＡＰを支援すると判断する（Ｓ６１０）。ＭＣＡＰ支援機器４０２は、マルチキャストチャンネルを利用して該当マルチキャストアドレスに対する送受信を行う（Ｓ６１６）。
【００７９】
一方、同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器からのＩＧＭＰメッセージが指定されたチャンネル（チャンネル７）を通じて伝送されなかったならば、ＭＣＡＰ支援機器４０２は同じＩＥＥＥ１３９４ネットワーク上のあらゆる機器が全部ＭＣＡＰを支援することではないと判断する（Ｓ６１２）。ＭＣＡＰ支援機器４０２は、終了時間＝０（直ちに解除）という内容を有するＭＣＡＰブロードキャストメッセージを同じネットワーク上のあらゆる機器にブロードキャストする（Ｓ６１４）。
【００８０】
ＭＣＡＰ支援機器４０２は、ブロードキャストチャンネルを利用して該当マルチキャストアドレスに対する送受信を行う（Ｓ６１６）。
【００８１】
図７に示されたように、ＭＣＡＰ支援機器４０２は、あらゆるＩＧＭＰ報告が指定されたチャンネルチャンネル７を通じて受信されれば、該当マルチキャストアドレス２３９．２５５．２５５．２５０に対する送受信を割り当てられたチャンネルチャンネル７を利用して行い、一方、一つでもブロードキャストチャンネル（チャンネル３１）を通じてＩＧＭＰ報告が受信されれば、ＭＣＡＰ支援機器４０２もブロードキャストチャンネル（チャンネル３１）を使用してブロードキャストする。
【００８２】
すなわち、あるマルチキャストグループに属しているあらゆる機器がＭＣＡＰを支援する場合にはＭＣＡＰプロトコルによるマルチキャスト通信を行い、ＭＣＡＰを支援しない機器が存在する場合にはブロードキャスト方式を利用したマルチキャスト通信を行う。
【００８３】
【発明の効果】
前述したように、本発明によるＩＥＥＥ１３９４ネットワーク上でマルチキャストグループに属しているあらゆる機器がＭＣＡＰを支援するのにも無駄にブロードキャストチャンネルを利用して機器の演算負荷を与えることを防止でき、たとえ、マルチキャストグループに属している機器のうちにＭＣＡＰ非支援機器があったとしてもマルチキャスト通信ができる。
【図面の簡単な説明】
【図１】 ユニキャスト方式、ブロードキャスト方式、そしてマルチキャスト方式を図式的に示した図面である。
【図２】 ＩＥＥＥ１３９４において各階層の関係を図式的に示した図面である。
【図３】 （ａ），（ｂ）ともに、ＩＥＥＥ１３９４ネットワーク上での従来のマルチキャスト通信方式を図式的に示した図面である。
【図４】 本発明によるＭＣＡＰを支援するか否かの識別方法を示すフローチャートである。
【図５】 図４に示された過程を図式的に示した図面である。
【図６】 本発明によるマルチキャスト通信方法を示すフローチャートである。
【図７】 図６に示された方法を図式的に示した図面である。
【符号の説明】
３０２，３０６，４０２，４０６ ＭＣＡＰ支援機器
３０４，４０４ ＭＣＡＰ非支援機器
Claims (10)
- （ａ）ＭＣＡＰ（Ｍｕｌｔｉｃａｓｔ Ｃｈａｎｎｅｌ Ａｌｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）支援機器が、同一ネットワーク上のあらゆる機器に対してＭＣＡＰブロードキャストメッセージをブロードキャストする過程と、
（ｂ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器にＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）照会メッセージをブロードキャストする過程と、
（ｃ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器からのＩＧＭＰ報告メッセージが伝送されるチャンネル番号により、各機器がＭＣＡＰを支援するか否かを識別する過程と
を含む同一ネットワーク上でＭＣＡＰを支援するか否かの確認方法。 - 前記（ｃ）過程は、前記ＩＧＭＰ報告メッセージがＭＣＡＰブロードキャストメッセージにより指定されたチャンネルを通じて伝送されなければ、前記ネットワーク上のあらゆる機器が全部ＭＣＡＰを支援することではないと判断することを特徴とする請求項１に記載の同一ネットワーク上でＭＣＡＰを支援するか否かの確認方法。
- （ｄ）前記ＩＧＭＰ報告メッセージがＭＣＡＰブロードキャストメッセージにより指定されたチャンネルを通じて伝送されなければ、前記ネットワーク上のあらゆる機器に前記指定されたチャンネルを解除することを指示するＭＣＡＰブロードキャストメッセージをブロードキャストする過程をさらに具備することを特徴とする請求項２に記載の同一ネットワーク上でＭＣＡＰを支援するか否かの確認方法。
- 前記（ｄ）過程は‘終了時間’＝０を指定するＭＣＡＰブロードキャストメッセージをブロードキャストすることを特徴とする請求項３に記載の同一ネットワーク上でＭＣＡＰを支援するか否かの確認方法。
- 前記ネットワークはＩＥＥＥ１３９４ネットワークであることを特徴とする請求項１に記載の同一ネットワーク上でＭＣＡＰを支援するか否かの確認方法。
- （ａ）あるマルチキャストグループに属するＭＣＡＰ支援機器が同一ネットワーク上のあらゆる機器に対してＭＣＡＰブロードキャストメッセージをブロードキャストする過程と、
（ｂ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器にＩＧＭＰ照会メッセージをブロードキャストする過程と、
（ｃ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたＭＣＡＰ支援機器が、同一ネットワーク上のあらゆる機器からのＩＧＭＰ報告メッセージが伝送されるチャンネル番号により、各機器がＭＣＡＰを支援するか否かを識別する過程と、
（ｅ）前記ＭＣＡＰブロードキャストメッセージをブロードキャストしたあらゆる機器からのＩＧＭＰ報告メッセージがマルチキャストチャンネルを通じて伝送されれば、該当マルチキャストアドレスに対する送受信をマルチキャストチャンネルを利用して行い、一つでもブロードキャストチャンネルを通じて伝送されれば、該当マルチキャストアドレスに対する送受信をブロードキャストチャンネルを利用して行う過程と
を含む同一ネットワーク上でのマルチキャスト通信方法。 - 前記（ｃ）過程は、前記ＩＧＭＰ報告メッセージがＭＣＡＰブロードキャストメッセージにより指定されたチャンネルを通じて伝送されなければ、前記ネットワーク上のあらゆる機器が全部ＭＣＡＰを支援することではないと判断することを特徴とする請求項６に記載の同一ネットワーク上でのマルチキャスト通信方法。
- （ｄ）前記（ｃ）過程で、前記ＩＧＭＰ報告メッセージがＭＣＡＰブロードキャストメッセージにより指定されたチャンネルを通じて伝送されなければ、前記ネットワーク上のあらゆる機器に前記指定されたチャンネルを解除することを指示するＭＣＡＰブロードキャストメッセージをブロードキャストする過程をさらに具備することを特徴とする請求項７に記載の同一ネットワーク上でのマルチキャスト通信方法。
- 前記（ｄ）過程は‘終了時間’＝０を指定するＭＣＡＰブロードキャストメッセージをブロードキャストすることを特徴とする請求項８に記載の同一ネットワーク上でのマルチキャスト通信方法。
- 前記ネットワークはＩＥＥＥ１３９４ネットワークであることを特徴とする請求項６に記載の同一ネットワーク上でのマルチキャスト通信方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR2002-012153 | 2002-03-07 | ||
| KR10-2002-0012153A KR100433545B1 (ko) | 2002-03-07 | 2002-03-07 | 동일 네트웍 상에 존재하는 기기들의 ＭＣＡＰ（Ｍｕｌｔｉｃａｓｔ ＣｈａｎｎｅｌＡｌｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）지원 여부 식별방법 및 이를 이용한 멀티캐스트 통신 방법 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003273874A JP2003273874A (ja) | 2003-09-26 |
| JP3720026B2 true JP3720026B2 (ja) | 2005-11-24 |
Family
ID=27785998
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003056220A Expired - Fee Related JP3720026B2 (ja) | 2002-03-07 | 2003-03-03 | 同一ネットワーク上でｍｃａｐを支援する機器の識別方法及びこれを利用したマルチキャスト通信方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20050073966A1 (ja) |
| JP (1) | JP3720026B2 (ja) |
| KR (1) | KR100433545B1 (ja) |
| CN (1) | CN1237753C (ja) |
| DE (1) | DE10252448B4 (ja) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040264402A9 (en) * | 1995-06-01 | 2004-12-30 | Padcom. Inc. | Port routing functionality |
| US6418324B1 (en) * | 1995-06-01 | 2002-07-09 | Padcom, Incorporated | Apparatus and method for transparent wireless communication between a remote device and host system |
| US6480510B1 (en) * | 1998-07-28 | 2002-11-12 | Serconet Ltd. | Local area network of serial intelligent cells |
| WO2002019636A1 (en) * | 2000-08-31 | 2002-03-07 | Padcom, Inc. | Method and apparatus for routing data over multiple wireless networks |
| US20040170181A1 (en) * | 2003-02-27 | 2004-09-02 | Padcom, Inc. | Prioritized alternate port routing |
| US20050108331A1 (en) * | 2003-10-31 | 2005-05-19 | Osterman Lawrence W. | Presence tracking for datagram based protocols with search |
| US20060083240A1 (en) * | 2004-10-19 | 2006-04-20 | Padcom, Inc. | Broadcasting data over multiple dissimilar wireless networks |
| FR2925805B1 (fr) * | 2007-12-21 | 2009-12-11 | Alcatel Lucent | Procede pour gerer la transmission de donnees en mode multidiffusion vers une pluralite d'elements de reseau, et element de reseau pour la mise en oeuvre du procede |
| US20100254334A1 (en) * | 2009-04-06 | 2010-10-07 | Qualcomm Incorporated | Setting up a communication session within a wireless communications system |
| US8787234B2 (en) * | 2009-06-23 | 2014-07-22 | Qualcomm Incorporated | Multicasting within a wireless communications system |
| EP2487963B1 (en) | 2009-11-17 | 2019-08-21 | Samsung Electronics Co., Ltd. | Method and device for investigating wifi display service in a wifi direct network |
| US9548869B2 (en) * | 2011-04-08 | 2017-01-17 | Qualcomm Incorporated | Systems and methods for implementing multicasting using personal area network “pan” wireless technology |
| CN112951224B (zh) * | 2021-01-26 | 2022-10-28 | 青岛海尔空调器有限总公司 | 语音设备及其数据处理方法 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| SG47619A1 (en) * | 1993-05-21 | 1998-04-17 | British Telecomm | Cellular radio systems |
| US5854898A (en) * | 1995-02-24 | 1998-12-29 | Apple Computer, Inc. | System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween |
| US5999997A (en) * | 1996-07-26 | 1999-12-07 | Compaq Computer Corporation | Two computers cooperating via interconnected busses |
| KR100356954B1 (ko) * | 2000-12-21 | 2002-10-18 | 엘지전자 주식회사 | 멀티캐스트 데이터 처리 방법 |
| KR100420659B1 (ko) * | 2001-08-18 | 2004-03-02 | 엘지전자 주식회사 | 엠피엘에스 망에서의 멀티캐스트 방법 |
| US7061880B2 (en) * | 2001-10-11 | 2006-06-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Systems and methods for multicast communications |
-
2002
- 2002-03-07 KR KR10-2002-0012153A patent/KR100433545B1/ko not_active IP Right Cessation
- 2002-11-12 CN CNB021504458A patent/CN1237753C/zh not_active Expired - Fee Related
- 2002-11-12 DE DE10252448A patent/DE10252448B4/de not_active Expired - Fee Related
-
2003
- 2003-01-14 US US10/341,496 patent/US20050073966A1/en not_active Abandoned
- 2003-03-03 JP JP2003056220A patent/JP3720026B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20050073966A1 (en) | 2005-04-07 |
| KR100433545B1 (ko) | 2004-05-31 |
| CN1444357A (zh) | 2003-09-24 |
| JP2003273874A (ja) | 2003-09-26 |
| DE10252448A1 (de) | 2003-09-25 |
| CN1237753C (zh) | 2006-01-18 |
| KR20030072878A (ko) | 2003-09-19 |
| DE10252448B4 (de) | 2007-01-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6011782A (en) | Method for managing multicast addresses for transmitting and receiving multimedia conferencing information on an internet protocol (IP) network | |
| US8189584B2 (en) | Multicast traffic management in a network interface | |
| US6138144A (en) | Method for managing multicast addresses for transmitting and receiving multimedia conferencing information on an internet protocol (IP) network implemented over an ATM network | |
| JP4077330B2 (ja) | データ生成装置 | |
| JP4297875B2 (ja) | ネットワーク中継方法及び装置 | |
| JP3720026B2 (ja) | 同一ネットワーク上でｍｃａｐを支援する機器の識別方法及びこれを利用したマルチキャスト通信方法 | |
| CN101299671A (zh) | 用于组播数据包发送与接收的方法和装置 | |
| KR100643285B1 (ko) | 멀티캐스트를 이용한 데이터 송수신 시스템 및 방법 | |
| US6879593B1 (en) | Connections of nodes on different networks | |
| CA2300470C (en) | Data communication method in ieee1394 network | |
| JP2006245713A (ja) | ネットワークシステム及びゲートウェイ装置 | |
| CN102025799A (zh) | 一种发现及自动配置设备的ip地址的方法 | |
| WO2017185212A1 (zh) | 一种组播时延诊断方法及装置 | |
| CN102368707B (zh) | 一种组播控制的方法、设备及系统 | |
| KR20040033866A (ko) | 가상 랜을 이용한 아이피 멀티캐스트 서비스방법 | |
| US7650417B2 (en) | Method for setting up a communication between a device and a host application over an IP network | |
| JP2003069640A (ja) | イーサネット（登録商標）上における明示的マルチキャストサービス方法及び装置 | |
| JP3519628B2 (ja) | 中継装置 | |
| CN101309154B (zh) | 报文的发送方法、发送装置和传输系统 | |
| CN1610349B (zh) | 实时消息传送方法 | |
| WO2009026846A1 (fr) | Procédé, dispositif et système de transmission de messages permettant la mise en oeuvre de services de multidiffusion | |
| KR100285177B1 (ko) | 인터넷 프로토콜 멀티캐스팅 환경에서의 신뢰성있는 다자간 정보 전송 방법 | |
| KR20040039043A (ko) | ＵＰｎＰ 네트워크 시스템의 제어 메시지 전송 방법 | |
| JPH10154980A (ja) | Ｉｐマルチキャスト・サービスシステムおよびそのアドレス割り当て方法 | |
| JP2003283530A (ja) | 通信ネットワークにおけるセッション設定方法及びその通信システム並びにプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050711 |
|
| 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: 20050809 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050906 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080916 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090916 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100916 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100916 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110916 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120916 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130916 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |