JPH10308758A

JPH10308758A - 通信装置

Info

Publication number: JPH10308758A
Application number: JP2090598A
Authority: JP
Inventors: Takeshi Saito; 健斉藤; Yoshiaki Takahata; 由彰高畠; Mikio Hashimoto; 幹生橋本
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1997-03-06
Filing date: 1998-02-02
Publication date: 1998-11-17

Abstract

(57)【要約】【課題】ネットワーク間でマルチキャストデータ転送を
行う際、ＮＡＴ処理（アドレス変換処理）を行う必要の
ない通信装置を提供する。【解決手段】放送型のネットワークに接続された通信装
置において、ネットワークレイヤのマルチキャストアド
レスのデータを受信したとき、前記ネットワークに接続
された第２の通信装置が前記マルチキャストのデータを
受信するための通信資源を確保する手段と、少なくとも
前記確保された通信資源の識別情報と前記マルチキャス
トのデータの識別情報とを前記第２の通信装置に通知す
る通知手段と、前記マルチキャストのデータを前記確保
された通信資源を用いて前記第２の

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＩＥＥＥ１３９４
バス等の放送型のネットワークを介して、例えばインタ
ーネットとの情報のやり取りを行う通信装置に関する。

【０００２】

【従来の技術】最近インターネットをはじめとする通信
技術の急激な進歩が各方面で話題になっており、企業や
大学などを中心にＬＡＮの導入、あるいはこれのＷＡＮ
やインターネットへの接続といったことが話題になって
いる。

【０００３】これらの技術革新は、家庭を取り巻くネッ
トワーク環境をも変える可能性が高い。即ち、家庭にＰ
ＣやＤＶＤ、デジタルセットトップボックス等のデジタ
ル機器が普及してくるに連れて、これらを相互にデジタ
ルネットワークにて接続しようという気運が高まるのは
必然である。現在、ＡＶベンダを中心に、ＩＥＥＥ１３
９４バスが、その候補の筆頭として、各方面から注目を
集めている。

【０００４】ＩＥＥＥ１３９４バスは、１００Ｍ、２０
０Ｍ、４００Ｍｂｐｓの高速デジタル網として利用する
ことができ、プラグアンドプレイ、同期チャネルを用い
た同期転送機能等、いくつもの注目すべき機能がある。

【０００５】それとともに、いわゆる家庭へのアクセス
網の技術革新も急である。即ち、ＣＡＴＶやＡＤＳＬ
（ＡｓｙｍｍｅｔｒｉｃＤｉｇｉｔａｌＳｕｂｓｃ
ｒａｉｂｅｒＬｉｎｅ）、ＦＴＴＨ（ｆｉｂｅｒ−ｔ
ｏ−ｔｈｅ−ｈｏｍｅ）等の高速ネットワーク技術、イ
ンターネット等のネットワークサービス等、その進歩は
著しい。特に、インターネット技術は、その高速化、Ｒ
ＳＶＰ（ＲｅｓｏｕｒｃｅＲｅｅｒｖａｔｉｏｎＰ
ｒｏｔｏｃｏｌ）等ネットワークレイヤレベルのシグナ
リングプロトコルを用いたＱＯＳ（Ｑｕａｌｉｔｙｏ
ｆＳｅｒｖｉｃｅ）保証、マルチキャスト等、注目す
べき技術が次々と生まれている。

【０００６】インターネット上で、これらの技術が実現
する近未来においては、家庭へのビデオ転送等、高速、
リアルタイムを要求される情報の転送の一部がインター
ネットを通じて行われる可能性がある。これは、インタ
ーネットに蓄積される情報量が実質的に無限であり、イ
ンターネットに対して、情報要求を行うユーザが当然期
待できるからである。

【０００７】

【発明が解決しようとする課題】しかしながら、家庭内
のデジタル機器を、アクセス網を介して接続し、インタ
ーネットを通じた情報のやり取りをしようとした場合、
以下のような問題点が考えられる。

【０００８】（問題点１）家庭内では、多様な機器が
家庭内ネットワークに接続されるために、多数のアドレ
スが必要になる。これらがインターネット端末になると
すると、多数のインターネットアドレスの取得が不可欠
となる。ところが、周知のように、インターネットアド
レスは、近年の急激な加入ホスト数の増加のため、不足
気味となっており、膨大なアドレス数が必要となる家庭
向けに、インターネットアドレスが開放されるとは考え
にくい。これを解決するための技術として、ＩＥＴＦ
（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓ
ｋＦｏｒｃｅ）がＲＦＣ１６３１で公開しているＮＡ
Ｔ（ネットワークアドレス変換）が知られている。この
方法は、家庭網内では、プライベートアドレスと呼ばれ
る、特別なＩＰアドレスを利用し、外部にはプライベー
トアドレスを見せないことで、上記問題を解決する。と
ころが、インターネットと家庭網の間を接続する網間接
続装置において、上記ＮＡＴに対応するための変換処理
が必要になるが、この変換処理は多大な処理負荷がかか
る事が知られており、映像等の高速なデータ転送を上記
ＮＡＴ技術と併用して利用しようとすると、非常に高コ
ストの接続装置を用意する必要が生ずる。

【０００９】（問題点２）一般に家電製品は、コスト
が非常に重要視される分野であり、ネットワーク機能の
コストも当然抑制が望まれる。ところが、一般にＩＰ処
理機能は、複雑なソフトウエアで実現されているのが通
常であり、これを家電製品に全て取り込むのは、高速な
処理装置と大きなソフトウエアが必要になるのが通例で
ある。一方、大きなインターネットトラヒック量が期待
される家電製品のうち、その多くは単にインターネット
パケットに収められた映像等の受信を行うのみであり、
上記のようなＩＰ処理機能をフルで持つことは冗長であ
る。そこで、本発明は、以上の問題点に鑑みてなされた
ものであり、これらの問題点を解決しようとするもので
ある。

【００１０】

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

１）上記（問題点１）を解決するための手段（請求項１）本発明の通信装置は、放送型のネットワー
クに接続された通信装置において、ネットワークレイヤ
のマルチキャストアドレスのデータを受信したとき、前
記ネットワークに接続された第２の通信装置が前記マル
チキャストのデータを受信するための通信資源を確保す
る手段と、少なくとも前記確保された通信資源の識別情
報と前記マルチキャストのデータの識別情報とを前記第
２の通信装置に通知する通知手段と、前記マルチキャス
トのデータを前記確保された通信資源を用いて前記第２
の通信装置へ配信する配信手段と、を具備したことを特
徴とする。

【００１１】本発明によれば、情報の転送要求を行った
端末がプライベートアドレスを有するプライベートネッ
トワーク上にある場合に、ＩＰマルチキャストアドレス
であれば、プライベートネットワーク上にある端末に
も、前記ＩＰマルチキャストアドレスを与えることは可
能であることから、インターネットとプライベートネッ
トワークとの間に入る接続装置が、いわゆるＮＡＴ処理
（ネットワークアドレス変換処理）を行わずとも、デー
タ転送を行うことが可能となり、接続装置の処理負荷の
大幅な低減に寄与することが可能となる。

【００１２】また、先に説明したＩＰマルチキャストに
関する利点を持ち続けた上で、受信端末から要求された
送信情報内容の変更を柔軟に行うことが可能となり、全
体として低コストかつ柔軟なシステムとすることが可能
となる。これは、端末装置一つ一つ、あるいはアプリケ
ーション一つ一つに対して、個別に別々のＩＰマルチキ
ャストアドレスを与えることが可能となり、接続装置で
のＮＡＴ処理が不要となることに起因する高スループッ
ト、即ち各受信端末への高速情報転送が可能となること
を意味する。よって、送信情報内容、例えばＴＶチャン
ネルの動的変更を伴う各受信端末への映像転送を、ＩＰ
マルチキャストのメカニズムを用いて行う手法とするこ
とができる。

【００１３】（請求項２）本発明の通信装置は、放送
型のネットワークに接続された通信装置であって、ネッ
トワークレイヤのマルチキャストアドレスと前記ネット
ワークに接続された第２の通信装置のプライベートアド
レスとを対応付ける対応テーブルを記憶する記憶手段
と、前記マルチキャストアドレスのデータを受信したと
き、前記対応テーブルを参照して該データを受信する第
２の通信装置へ該データを配信する配信手段と、を具備
したことを特徴とする。

【００１４】本発明によれば、通信装置（網間接続装
置）を介して、情報の転送要求を行った端末が、プライ
ベートアドレスを有する、プライベートネットワーク上
にある場合に、ＩＰマルチキャストアドレスであれば、
プライベートネットワーク上にある端末にも、前記ＩＰ
マルチキャストアドレスを与えることは可能であること
から、インターネットとプライベートネットワークとの
間に入る網間接続装置が、いわゆるＮＡＴ処理（ネット
ワークアドレス変換処理）を行わずとも、データ転送を
行うことが可能となり、網間接続装置の処理負荷の大幅
な低減に寄与することが可能となる。

【００１５】また、先に確立されたＩＰマルチキャスト
のデータフォワーディングを、転送されるＩＰパケット
のヘッダ処理を伴わずに行うことが可能となり、一般に
大きな負荷がかかるといわれるＩＰパケットのヘッダ処
理を行わずにデータ転送が可能となることから、データ
転送のスループットを大幅に向上することが可能とな
る。これは、端末装置一つ一つ、あるいはアプリケーシ
ョン一つ一つに対して、個別に別々のＩＰマルチキャス
トアドレスを与えた場合、接続装置でのＮＡＴ処理が不
要となることに起因する、高スループットを保証した上
で、各受信端末への高速情報転送が低コストで可能とな
ることを意味し、各受信端末への映像転送等の高速情報
転送を、ＩＰマルチキャストのメカニズムを用いて行う
手法とすることができる。２）上記（問題点２）を解決するための手段（請求項３）本発明の通信装置は、放送型のネットワー
クに接続された通信装置において、前記ネットワークに
接続された第２の通信装置がネットワークレイヤのデー
タフローを受信するための通信資源を確保する手段と、
少なくとも前記確保された通信資源の識別情報と前記デ
ータフローの識別情報とを前記第２の通信装置に通知す
る通知手段と、前記データフローを前記確保された通信
資源を用いて前記第２の通信装置へ配信する配信手段
と、を具備したことを特徴とする。

【００１６】本発明により、放送型のネットワークに接
続された本通信装置（制御ノード）が、任意の情報の入
手や維持のための手続きをインターネットに対して行い
つつ、前記放送型ネットワーク上の他の端末は、単純な
ＩＰフローの受信機能のみを持つだけで、所望のデータ
の受信を行うことが可能となる。即ち、一般にＩＰパケ
ットの送信・受信機能を実現するソフトウエアは、大き
な処理ルーチンを必要とし、複雑なソフトウエアを装備
する必要があった。ところが、映像受信のようなアプリ
ケーションのみを稼動する受信端末にとっては、関心が
あるのは映像をペイロードに載せたパケット等の受信の
みであり、上記のような複雑なソフトウエアは冗長な機
能であった。そこで、機能をＩＰパケットの受信のみに
絞り込み、かつ、受信するＩＰパケットの種別、即ち受
信するＩＰフローの識別情報（例えば、送信ＩＰアドレ
ス、受信ＩＰアドレス、送信ポート番号、受信ポート番
号の組み等）をその都度通知してもらい、そのＩＰフロ
ーのみを受信する様な端末とすることで、極めて安価に
ＩＰを通した映像などのデータ受信端末の構成が可能と
なる。

【００１７】また、前記制御ノードは、データ前記受信
端末に成り代わり、トランスポート層より上位のレイヤ
の処理を、前記情報の送信ノードと交す処理手段を持っ
てもよい。この様にすることにより、ＲＴＣＰ（Ｒｅａ
ｌｔｉｍｅＴｒａｎｓｐｏｒｔＣｏｎｔｒｏｌＰ
ｒｏｔｏｃｏｌ）処理のような、送信端末と受信端末と
の間のやり取りが必要なプロトコルを元に運用されてい
るような系においても、制御ノードがこのやり取りを代
行してやることが可能となり、もって前記端末がデータ
を受信し続けている状態で、前記のようなプロトコルの
運用も可能となる。

【００１８】また、前記制御ノードは、データ受信端末
からの任意の情報の受信要請を受け付ける手段を持って
いてもよい。この様にすることにより、前記受信端末
は、欲しい任意の情報の種別、属性を本制御ノードに通
知し、本制御ノードは、前記端末に代わり、前記任意の
情報を入手するための手続きをインターネットに対して
行い、インターネット側から受信した前記任意の情報
を、ＩＰパケットのまま前記端末に送信することが可能
となる。もって、前記端末は、欲しい任意の情報の入手
が可能となる。

【００１９】（請求項４）本発明の通信装置は、第１の
ネットワークと放送型の第２のネットワークを接続する
通信装置において、前記第１のネットワークに接続され
た第２の通信装置に対しネットワークレイヤのデータフ
ローの配送を要求する要求手段と、前記第２のネットワ
ークに接続された第３の通信装置が前記データフローを
受信するための通信資源を確保する手段と、少なくとも
前記確保された通信資源の識別情報と前記データフロー
の識別情報とを前記第３の通信装置に通知する通知手段
と、前記データフローを前記確保された通信資源を用い
て前記第３の通信装置へ配信する配信手段と、を具備し
たことを特徴とする。

【００２０】本発明によれば、任意の情報の入手や維持
のための手続きをインターネットに対して行いつつ、前
記放送型ネットワーク上の他の受信端末は、単純なＩＰ
フローの受信機能のみを持つだけで、所望のデータの受
信を行うことが可能となる。即ち、一般にＩＰパケット
の送信・受信機能を実現するソフトウエアは、大きな処
理ルーチンを必要とし、複雑なソフトウエアを装備する
必要があった。ところが、映像受信のようなアプリケー
ションのみを稼動する受信端末にとっては、関心がある
のは映像をペイロードに載せたパケット等の受信のみで
あり、上記のような複雑なソフトウエアは冗長な機能で
あった。そこで、このような複雑さＩＰ処理機能を本通
信装置に持たせ、受信端末に具備される機能をＩＰパケ
ットの受信のみに絞り込み、かつ、通信制御装置から受
信するＩＰパケットの種別、即ち受信するＩＰフローの
属性をその都度通知してもらい、そのＩＰフローのみを
受信する様な端末とすることで、極めて安価にＩＰを通
した映像などのデータ受信端末の構成が可能となる。

【００２１】また、前記通信装置（制御ノード）は、前
記受信端末に成り代わり、トランスポート層より上位の
レイヤの処理を情報の送信端末と交す処理手段を持って
もよい。この様にすることにより、ＲＴＣＰ（Ｒｅａｌ
ｔｉｍｅＴｒａｎｓｐｏｒｔＣｏｎｔｒｏｌＰｒ
ｏｔｏｃｏｌ）処理のような、送信端末と受信端末との
間のやり取りが必要なプロトコルを基に運用されている
ような系においても、制御ノードがこのやり取りを代行
してやることが可能となり、もって前記端末がデータを
受信し続けている状態で、前記のようなプロトコルの運
用も可能となる。

【００２２】また、前記通信装置（制御ノード）は、受
信端末からの任意の情報の受信要求を受け付ける手段を
具備していてもよい。この様にすることにより、受信端
末は、欲しい任意の情報の種別、属性を本制御ノードに
通知し、本制御ノードは、前記端末に代わり、前記任意
の情報を入手するための手続きをインターネットに対し
て行い、インターネット側から受信した前記任意の情報
を、ＩＰパケットのまま前記受信端末に送信することが
可能となる。もって、前記受信端末は、欲しい任意の情
報の入手が可能となる。

【００２３】本発明の通信装置は、放送型のネットワー
クに接続される通信装置であって、前記放送型のネット
ワークに接続される他の通信装置から通知される所定の
データフローの識別子と通信資源の識別子を基に、前記
所定のデータフローのみを受信する受信手段を具備した
ことにより、放送型のネットワークに接続された通信装
置（制御ノード）が、任意の情報の入手や維持のための
手続きをインターネットに対して行いつつ、前記放送型
ネットワーク上の本通信装置（受信端末）は、単純なＩ
Ｐフローの受信機能のみを持つだけで、所望のデータの
受信を行うことが可能となる。即ち、一般にＩＰパケッ
トの送信・受信機能を実現するソフトウエアは、大きな
処理ルーチンを必要とし、複雑なソフトウエアを装備す
る必要があった。ところが、映像受信のようなアプリケ
ーションのみを稼動する受信端末にとっては、関心があ
るのは映像をペイロードに載せたパケット等の受信のみ
であり、上記のような複雑なソフトウエアは冗長な機能
であった。そこで、機能をＩＰパケットの受信のみに絞
り込み、かつ、受信するＩＰパケットの種別、即ち受信
するＩＰフローの属性をその都度通知してもらい、その
ＩＰフローのみを受信する様な端末とすることで、極め
て安価にＩＰを通した映像などのデータ受信端末の構成
が可能となる。

【００２４】また、前記通信装置（受信端末）は、前記
放送型のネットワークに接続される別のノードに対し
て、特定の情報を要求する要求手段を具備していてもよ
い。この様にすることにより、前記通信装置（制御ノー
ド）にその情報の入手を代行してもらうことが可能とな
る。

【００２５】３）（請求項５）本発明の通信装置は、放送型のネットワー
クに接続された信装置であって、前記ネットワークに接
続された第２の通信装置へのネットワークの通信資源の
識別情報と、任意のネットワークレイヤのデータフロー
の識別情報とを前記第２の通信装置に通知する通知手段
と、前記データフローを前記通信資源を用いて前記第２
の通信装置へ配信する配信手段とを具備し、前記データ
フローの宛先ネットワークレイヤアドレスは、前記第２
の通信装置のもともとのネットワークレイヤアドレスと
は異なることを特徴とする。

【００２６】本発明によれば、放送型のネットワークに
接続された本通信装置が、任意の情報の入手や維持のた
めの手続きを例えばインターネットに対して行いつつ、
前記放送型ネットワーク上の他の端末は、単純なＩＰフ
ローをの受信機能のみをもつだけで、所望のデータの受
信を行うことが可能となる。すなわち、一般にＩＰパケ
ットの送信・受信機能を実現するソフトウエアは、大き
な処理ルーチンを必要とし、複雑なソフトウエアを装備
する必要があった。ところが映像受信のようなアプリケ
ーションのみを稼働する受信装置にとっては、関心があ
るのは映像をペイロードに載せたパケット等の受信のみ
であり、上記のような複雑なソフトウエアは冗長な機能
でった。

【００２７】そこで、機能をＩＰパケットの受信のみに
絞り込み、かつ、受信するＩＰパケットの種別、すなわ
ち、受信するＩＰフローの属性（例えば、送信ＩＰアド
レス、受信ＩＰアドレス、送信ポート番号、受信ポート
番号の組み等）をその都度通知してもらい、そのＩＰフ
ローのみを受信する様な端末とすることで、極めて安価
にＩＰを通した映像などのデータ受信端末の構成が可能
となる。

【００２８】（請求項６）請求項５記載の本発明の通信
装置は、前記ネットワーク上に、前記第２の通信装置が
前記ネットワークレイヤのデータフローを受信するため
の通信資源を確保する手段をさらに具備したことを特徴
とする。

【００２９】本発明によれば、例えば、ＩＥＥＥ１３９
４におけるチャネル等、その利用に先だって、使用する
通信資源の確保が必要な場合（例えば、転送トラヒック
がＱｏｓを要求するようなものである場合）、あるいは
そのデータフロー向けの通信資源を確保することによ
り、他のトラヒックとアイソレーションを確保できる場
合において、前記第２の通信装置との間に通信資源を確
保する場合に、これを行うことができる。

【００３０】また、前記第２の通信装置は、該確保され
た通信資源を通して、通知されたデータフローが転送さ
れてくることを予め認識することができるようになるた
め、データフロー識別のためのフィルタと通信資源識別
のためのフィルタとを合わせて構成することも可能とな
る。

【００３１】（請求項７）請求項５または請求項６記載
の通信装置は、第３の通信装置に対し、前記ネットワー
クレイヤのデータフローの配信を要求する手段をさらに
具備したことを特徴とする。

【００３２】本発明の通信装置は、受信装置である第２
の通信装置に代わって、データフローの送信要求を送出
することが可能となり、もって、第２の通信装置に本来
必要とされたデータの送信機能を省いた上でも、第２の
通信装置への任意のデータフローの配信の指定を該通信
装置を通して行うことができるようになる。

【００３３】（請求項８）請求項７記載の通信装置は、
トランスポート層よりも上位レイヤの処理を、前記第３
の通信装置と交す処理手段をさらに具備したことを特徴
とする。

【００３４】本発明によれば、例えば、ＲＴＣＰ（Ｒｅ
ａｌｔｉｍｅＴｒａｎｓｐｏｒｔＣｏｎｔｏｒｏｌ
Ｐｒｏｔｏｃｏｌ）処理のような、送信端末と受信端末
との間のやりとりが必要なトランスポートプロトコル等
のプロトコルを基に運用されているような系において
も、本通信装置がこのやりとりを代行することが可能と
なり、もって、前記受信端末がデータを受信し続けてい
る状態でＲＴＣＰ等のプロトコルの運用も可能となる。

【００３５】（請求項９）本発明の通信装置は、放送型
のネットワークに接続された通信装置であって、前記ネ
ットワークに接続される他の通信装置から通知される所
定のネットワークレイヤのデータフローの識別情報と、
該データフローの配送に利用される前記ネットワークの
通信資源の識別情報との対応関係の通知を受信する第１
の受信手段と、一時的に前記所定のネットワークレイヤ
のデータフローを受信する第２の受信手段と、を具備
し、前記データフローの宛先ネットワークレイヤアドレ
スは、本通信装置のもともとのネットワークレイヤアド
レスとは異なることを特徴とする。

【００３６】本発明によれば、放送型のネットワークに
接続された制御ノードが、任意の情報の入手や維持のた
めの手続きを例えばインターネットに対して行いつつ、
前記放送型ネットワーク上の本通信装置は、単純なＩＰ
フローの受信機能のみを持つだけで、所望のデータの受
信を行うことが可能となる。すなわち、一般にＩＰパケ
ットの送信・受信機能を実現するソフトウエアは、大き
な処理ルーチンを必要とし、複雑なソフトウエアを装備
する必要があった。ところが、映像受信のようなアプリ
ケーションのみを稼働する受信端末にとっては、関心が
あるのは映像をペイロードに載せたパケット等の受信の
みであり、上記のような複雑なソフトウエアは冗長な機
能であった。

【００３７】そこで、機能をＩＰパケットの受信のみに
絞り込み、かつ、受信するＩＰパケットの種別、すなわ
ち受信するＩＰフローの属性をその都度通知してもら
い、そのＩＰフローのみを受信するような通信装置とす
ることで、極めて安価にＩＰを通した映像などのデータ
受信端末の構成が可能となる。

【００３８】

【発明の実施の形態】以下、図面を参照して本発明の実
施形態について説明する。なお、以下の説明では、一例
として家庭内に構築されたネットワーク（家庭内ネット
ワーク）を対象として説明するが、これに限るものでは
なく、例えば、ホテル等の建物、敷地内といった限られ
た範囲に構築されるネットワークにおいても適用でき
る。

【００３９】（第１の実施形態）図１は、本発明の第１
の実施形態に係るネットワーク全体の構成例を示したも
ので、映像サービスを提供しているビデオサーバからの
データを、公衆網を介して家庭内ネットワークにとりこ
み、家庭内ネットワークに接続された端末で、該サービ
スを受ける状況を説明する図となっている。

【００４０】図１に示すように、全体の構成は、ビデオ
サーバ１０１、公衆網１０４、接続装置１０２、例えば
家庭内に構築された第１のネットワーク１０５、第２の
ネットワーク１０６、第１のネットワークに接続された
端末１０３からなる。

【００４１】なお、図１では第１のネットワーク１０５
に端末１０３が１つ接続されているのみであるが、実際
には両ネットワーク１０５、１０６に、他の種々の端
末、あるいは網間接続装置等が接続されていても良い。

【００４２】公衆網は、例えばＣＡＴＶ網、あるいはＩ
ＳＤＮ／Ｂ−ＩＳＤＮ網、ＡＴＭ−ＰＯＮ網、高速無線
アクセス網、ＡＤＳＬ／ＨＤＳＬ網等、色々な場合が考
えられる。ただし、本実施形態のビデオサービスはＭＰ
ＥＧ映像をインターネットを介して提供されるものとす
る（ＭＰＥＧｏｖｅｒＩＰ）。よって、本サービスが提
供されるインタフェースはデジタルインタフェースであ
るものとする。

【００４３】本実施形態においては、該デジタルネット
ワークはデータリンク方式として、ＡＴＭ方式を採用し
ているものとして、以後の説明を進めていくが、本発明
の方式はＡＴＭ方式に限定されるものではない。例え
ば、以後の説明のＡＴＭのＶＰＩ／ＶＣＩ等のデータリ
ンクレイヤ識別子は、ＩＳＤＮであればＢチャネル識別
子、ＣＡＴＶであれば周波数に対応するものである。こ
のように、本実施形態のＡＴＭにおけるＶＰＩ／ＶＣＩ
をこれら他のデータリンクレイヤ識別子に置き換えたも
のも、本発明に含まれるものである。

【００４４】ビデオサーバ１０１は、専用のビデオサー
バでも良いし、例えば映像対応ＷＷＷサーバ等、映像信
号を送出できるサーバであれば良い。ここで、「映像信
号を送出できる」とは、リアルタイム伝送を行う事は必
ずしも意味しない。例えば、映像データを、リアルタイ
ム配信ではなく、ベストエフォートにて配信する場合が
これにあたる。

【００４５】公衆網１０４と家庭内に構築されたネット
ワークの間は、専用の接続装置１０２にて接続されてい
る。接続装置１０２には、この場合、公衆網１０４の終
端機能、家庭内のネットワーク１０５、１０６の終端機
能、ＩＰ処理機能、ＲＦＣ１６３１にて標準化されてい
るＮＡＴ（ＮｅｔｗｏｒｋＡｄｄｒｅｓｓＴｒａｎ
ｓｌａｔｉｏｎ）機能の他に、ＩＰマルチキャスト対応
機能、ＩＰシグナリング機能、公衆網と家庭内のネット
ワーク間でリアルタイムデータ転送可能なデータリンク
レイヤレベルのスイッチ、アドレス通知機能等が実装さ
れている。詳細は後述する。

【００４６】次に、図１に示したネットワーク上のＩＰ
のサブネット構成とアドレス割当について説明する。図
１に示すように、第１の実施形態において、家庭内のネ
ットワーク全体（第１および第２のネットワーク１０
５、１０６）にて１つのＩＰサブネット( ネットワーク
アドレスＰ）が構成されており、更に家庭内ネットワー
クは、ＲＦＣ１５９７にて標準化されているプライベー
トアドレスを利用している。

【００４７】また、接続装置１０２の公衆網側には、グ
ローバルなＩＰアドレス（Ｇ．２）が割り当てられてい
る。このようなアドレス構成となっている理由は、例え
ば複数のグローバルなＩＰアドレスの取得には、１つの
グローバルＩＰアドレス取得と比べてコストがかかる、
あるいは世界的なＩＰアドレスの枯渇のためである。即
ち、端末数、アドレス数の急成長が見込まれる家庭内ネ
ットワークへの接続端末にはグローバルなＩＰアドレス
の新規の割当は実質的にはほとんど不可能、等の理由に
よるものである。

【００４８】なお、第１のネットワーク１０５、第２の
ネットワーク１０６は、それぞれ別のプライベートアド
レス内という限定の上で、別々のサブネットとなってい
てもよい。この場合は、両者の間にはいる接続装置１０
２はルータとなる。

【００４９】本実施形態においては、第１および第２の
ネットワーク１０５、１０６は同一のサブネットに属す
るものとして、以降の説明を行う。次に、図１の端末１
０３が接続装置１０２、公衆網１０４を通してビデオサ
ーバからビデオを転送してもらうまでの処理手順につい
て、図２を参照して説明する。また、その際の端末１０
３の処理手順および接続装置１０２の処理手順を、それ
ぞれ図３、図４に示す。

【００５０】図２、図３、図４は、後に示すように、接
続装置１０２がＳＢＭ（ＳｕｂｎｅｔＢａｎｄｗｉｄ
ｔｈＭａｎａｇｅｒ）であるような場合に、この機構
を用いて通信資源の確保を使った場合のシーケンスを記
述したものである。

【００５１】ＳＢＭとは、ＩＥＴＦのＩｎｔＳｅｒｖワ
ーキンググループで議論されているもので、サブネット
内の通信資源確保をＲＳＶＰを用いて行うものである。
まず、端末１０３は、ＯＳＩの標準化された７レイヤの
うちのレイヤ５以上のプロトコルを用いて、見たいビデ
オについての情報の入手を行う（ステップＳ２０１、Ｓ
２０３）。これは、ＭＰＥＧ／ＤＡＶＩＣのＤＳＭ−Ｃ
Ｃや、それに準じたプロトコルを用いたネゴシエーショ
ンや、ＲＴＳＰ等を用いてＷＷＷサーバからの情報の選
択をＷｅｂ上で行う事による情報の選択など、色々な場
合が考えられる。以降では、これを「上位レイヤプロト
コル」として、まとめて表現する。

【００５２】本実施形態では、これらの情報の交換は、
ＩＰパケットを使って行われるものとする。ちなみに、
この上位レイヤプロトコルは、接続装置１０２にてＮＡ
Ｔの処理を受けながら通信されていても良い（ステップ
Ｓ２０２）。

【００５３】ＮＡＴ処理とは、プライベートＩＰ網から
インターネットにＩＰパケットをフォワーディングする
に際し、プライベートＩＰアドレスをインターネット側
に送出するのは許されないため、接続装置１０２にて、
プライベートＩＰアドレスを自身のグローバルＩＰアド
レス( ここでは「Ｇ．２」）に変換して送出する方式を
言う。

【００５４】ＮＡＴ処理の詳細については、例えば本発
明者らによる特願平第８−３１６５５２号を参照された
い。本実施形態においては、ビデオサーバからの映像サ
ービスは、ＩＰマルチキャストを通じて提供されるもの
とする。そこで、前記上位レイヤプロトコルを用いて選
択するビデオが決定した場合、そのビデオを転送するた
めのＩＰマルチキャストアドレスを取得する必要があ
る。

【００５５】その放送形態( 配信形態) にはいくつかの
形態が考えられる。（Ａ）まず、ビデオ毎( コンテンツ毎) に、別々のＩＰ
マルチキャストアドレスが割り当てられている場合から
説明する。

【００５６】これは、例えばＡ放送局からの放送はＩＰ
マルチキャストアドレス＝「＃１」、Ｂ放送局からの放
送は「＃６」等と、ＩＰマルチキャストアドレスが割当
てられている場合である。

【００５７】上位レイヤプロトコルを通して、ビデオサ
ーバ１０１は、端末１０３にそのビデオを転送するため
のマルチキャストアドレス「Ｍ」を通知する。すると、
端末１０３は、ＩＰマルチキャストのプロトコル（例え
ばＩＧＭＰ（ＲＦＣ１１１２））に従い、インターネッ
ト側から受け取るＱＵＥＲＹメッセージに対し、加入し
たいマルチキャストアドレス「Ｍ」についてのＲＥＰＯ
ＲＴメッセージを送出する（ステップＳ２０４）。

【００５８】これを受信した接続装置１０２は、端末１
０３のプライベートアドレス「Ｐ．２」と、要求された
マルチキャストアドレス「Ｍ」との対応関係を記憶した
後（ステップＳ２０５）、ＲＥＰＯＲＴメッセージを上
流のルータに通知する（ステップＳ２０６）。その際、
送信者アドレスを自身（接続装置１０２）のグローバル
ＩＰアドレス「Ｇ．２」としておく。

【００５９】接続装置１０２に記憶される対応テーブル
の一例を図５に示す。マルチキャストアドレス「Ｍ」へ
の加入が成功すると、接続装置１０２は、端末１０３が
マルチキャストアドレス「Ｍ」に加入した旨を記憶し
（ステップＳ２０５）、これを端末１０３に通知する。

【００６０】次に、端末１０３は、このビデオ映像を良
い品質で受信するための通信資源の予約を行う。このた
めの方法として、いくつかの方法が考えられる。（ａ）ＳＢＭを用いる方法ＳＢＭ（ＳｕｂｎｅｔＢａｎｄｗｉｄｔｈＭａｎａ
ｇｅｒ）とは、インターネットの標準化機関であるＩＥ
ＴＦで提案されているサブネット内の帯域予約のための
方式であり、サブネット内の帯域予約をＲＳＶＰを使っ
て行うものである。

【００６１】（ｂ）ＲＳＶＰ（ＲｅｓｏｕｒｃｅＲ
ｅｓｅｒｖａｔｉｏｎＰｒｏｔｏｃｏｌ）を用いる方
法（ｃ）ＩＥＣ１８８３を用いる方法以下、順に説明する。

【００６２】（ａ）ＳＢＭを用いる方法まず、ＳＢＭを用いる場合について、図２に示すシーケ
ンスを参照して説明する。

【００６３】接続装置１０２は、ＳＢＭノードであるこ
とから、ルーチングプロトコルは稼動していない。本実
施形態の接続装置は、ＮＡＴ機能を持っているため、グ
ローバルＩＰアドレス（Ｇ．２）を有しているが、家庭
内ネットワーク側に複数の物理インタフェースがあると
しても、物理インタフェース毎にＩＰアドレス( プライ
ベートアドレス) を持つ必要はない。例えば、接続装置
１０２は、グローバルＩＰアドレスの他、プライベート
アドレスを１つ持てば充分である。ここでは、接続装置
１０２はプライベートＩＰアドレス「Ｐ．１」を持って
いる。

【００６４】端末１０３は、上位レイヤプロトコル等で
ＲＳＶＰのＰＡＴＨメッセージの送出をビデオサーバ１
０１に促しても良い。ＰＡＴＨメッセージはマルチキャ
ストアドレス「Ｍ」宛てに送出され、接続装置１０２に
届く（ステップＳ２０７）。

【００６５】接続装置１０２では、ＲＳＶＰのＰＡＴＨ
ステートを作成し（ステップＳ２０８）、その後、ＰＡ
ＴＨメッセージをマルチキャストアドレス「Ｍ」宛に送
出し、結局、端末１０３に到着する（ステップＳ２０
９）。その際、接続装置１０２は端末１０３がマルチキ
ャストアドレス「Ｍ」に属している事を、図５の対応テ
ーブルにより認識しているので、該ＰＡＴＨメッセージ
を端末１０３にフォワードする事が出来る。

【００６６】接続装置１０２内には、ＰＡＴＨステート
が出来る。ここで、接続装置１０２はＳＢＭノードであ
る。端末１０３は、帯域等の通信資源を予約すべく、Ｒ
ＳＶＰのＲＥＳＶメッセージを上流の接続装置１０２に
送出する（ステップＳ２１０）。

【００６７】ＲＥＳＶメッセージを受信した接続装置１
０２は、接続装置１０２と端末１０３間の通信資源を確
保すべく、第１のネットワーク（ＩＥＥＥ１３９４）１
０５のＩＥＥＥ１３９４同期リソースマネージャにアク
セスして、必要な帯域と同期チャネル番号を確保する
（ステップＳ２１１）。ここで、確保された同期チャネ
ルの番号を「＃ｘ」とする。

【００６８】この時点で、接続装置１０２は、端末１０
３に「どの同期チャネルを用いて、リクエストされた番
組を送出するのか」を端末１０３に通知しても良い（ス
テップＳ２１２）。

【００６９】この通知方法としては、例えば、図６に示
したようなフォーマットのＲＳＶＰのＰＡＴＨメッセー
ジを用いる方法がある。すなわち、図６に示すよに、Ｒ
ＳＶＰのＰＡＴＨメッセージ内に、「今後（あるいは
今）、このＰＡＴＨメッセージに含まれるデータ（ＩＰ
フロー）は、同期チャネル番号＝「＃ｘ」にて伝送す
る」といった旨の情報が記述される。

【００７０】第２の通知方法は、発明者らが特願平第８
−２６４４９６号に記載したＦＡＮＰ（ＦｌｏｗＡｔ
ｔｒｉｂｕｔｅＮｏｔｉｆｉｃａｔｉｏｎＰｒｏｔ
ｏｃｏｌ）を用いる方法である。

【００７１】ＦＡＮＰは、隣接ノード間（本実施形態の
場合、接続装置１０２と端末１０３間）にて、送信する
ＩＰフロー等（本実施形態の場合、例えばＩＰマルチキ
ャストアドレス「Ｍ」）と、リンクレイヤのＩＤ情報
（本実施形態の場合、先に確保したＩＥＥＥ１３９４の
チャネル番号）との対応関係を通知しあうものである。

【００７２】第３の通知方法は、ＩＥＣ１８８３のＣＩ
Ｐヘッダを用いる方法である。ＩＥＣ１８８３を用い
て、接続装置１０２が直接端末１０３のＰＣＲ（Ｐｌｕ
ｇＣｏｎｔｒｏｌＲｅｇｉｓｔｅｒ）に使用するチ
ャネル番号を書き込み、１３９４のヘッダなり、ＩＥＣ
１８８３にて定められたＣＩＰ（ＣｏｍｍｏｎＩｓｏ
ｃｈｒｏｎｏｕｓＰａｃｋｅｔ）ヘッダなりで端末１
０３に、送信している情報がＭＰＥＧｏｖｅｒＩＰであ
ることを認識させる。例えば、ＣＩＰヘッダを拡張する
場合は、そのパケットがＩＰパケットである旨、あるい
はＭＰＥＧｏｖｅｒＩＰである旨を示す値をＦＭＰ（フ
ォーマットＩＤ）領域に書き込むことにより、端末１０
３はＣＩＰヘッダを見ることにより、そのパケットの属
性がＩＰパケット、あるいはＭＰＥＧが載ったＩＰパケ
ットであることが認識できるようになる。

【００７３】第４の通知方法は、図７に示すように、Ｐ
ＣＲを拡張して、ＰＣＲレジスタの意味の一部を、その
チャネル番号に伝送する内容を意味するものとする。例
えば、ＩＰパケットあるいはＭＰＥＧｏｖｅｒＩＰのパ
ケットである。また、そのチャネル番号を伝送されるフ
ローの属性を記述しても良い。例えば、送信ＩＰアドレ
ス／受信ＩＰアドレス／送信ポート番号／受信ポート番
号の組み合わせなどである。このようなレジスタを端末
１０３に用意し、接続装置１０２( あるいはコントロー
ラ) がこのレジスタに適切に記述することにより、端末
１０３が、そのチャネル番号を通して受信するデータが
ＩＰパケット、あるいはＭＰＥＧｏｖｅｒＩＰのパケッ
トであること、あるいは、その属性を認識できるように
なる。

【００７４】無論、上記第１〜第４の通知方法の適宜組
み合わせて用いることもできる。なお、タイミング的に
は、ここで説明したタイミング以外にも、ビデオサーバ
１０１まで通信資源の予約が完了し、エンド- エンドの
通信が可能になった段階で上記の手続きを行う形も考え
られる。

【００７５】さて、下流側の通信資源の確保に成功した
接続装置１０２は、ＲＳＶＰのＲＥＳＶメッセージを更
に上流へと流す（ステップＳ２１３）。これを受けとっ
たインターネット内のルータは例えば、Ｑ．２９３１等
を使って下流側のＡＴＭ網の通信資源を確保し（ステッ
プＳ２１４）、それを確認した後、更に上流へとＲＥＳ
Ｖメッセージの送出、といったことを繰り返す。

【００７６】更に、ＰＡＴＨあるいはＦＡＮＰを用いて
下流方向のＲＳＶＰ／ＳＢＭノードに対して、使用する
データリンク識別子（この場合、データリンク技術がＡ
ＴＭであるため、ＶＰＩ／ＶＣＩ）についての情報を送
出し、該ＲＳＶＰ／ＳＢＭノードに、送出ＩＰフローと
データリンク識別子との対応関係の通知を行う（ステッ
プＳ２１５）。ここで、接続装置１０２に対して確保さ
れたＡＴＭのＶＣＩの値「＃ｙ」とする。

【００７７】こうして、エンドエンドの通信資源が確保
されたなら、ビデオ転送を開始する（ステップＳ２１
６、Ｓ２１７）。ここで、接続装置１０２では、ビデオ
サーバ１０１からＡＴＭコネクション「＃ｙ（ＶＣＩ値
＝「＃ｙ」）」にてＭＰＥＧｏｖｅｒＩＰのデータが伝
送されてくることを認識しており、また端末１０３に対
してＩＥＥＥ１３９４の同期チャネル「＃ｘ」にて受信
したＩＰパケットを送出すればよいことを認識してい
る。

【００７８】そこで、接続装置１０２では、ＶＣＩ「＃
ｙ」を通して受信したデータを、ＩＰパケットのヘッダ
の中身まで検証することなく、直接ＩＥＥＥ１３９４の
同期チャネル「＃ｘ」に対して、ＩＰパケットの同期を
とった上で伝送する。即ち、ＶＣＩ値のみの検証によ
り、ＩＰレイヤの処理をすることなく、直接１３９４へ
のデータ転送を行うことができる。これは、データリン
クレイヤの情報のみで、データのスイッチングを行って
いることから、データリンクスイッチと見ることができ
る。

【００７９】このことにより、本来ＩＰレイヤで行うべ
き、ＩＰレイヤ処理、即ちＩＰヘッダの検証やルーチン
グ処理等の一連のソフトウエア処理を、データリンクレ
イヤスイッチング処理にて置き換えることが可能にな
り、処理時間、及び処理負荷の大幅な低減を図ることが
可能になる。これは、ＳＢＭを行った上で、データリン
クスイッチを行っていることに相当する。

【００８０】なお、以上の説明では、接続装置１０２は
ＳＢＭノードとして説明を行ってきたが、接続装置１０
２がルータであり、ＲＳＶＰを利用した通信資源の確保
を行ってももちろんよい。

【００８１】また、通信資源の予約を行う際に、本発明
の発明者らによる特願平第８−２６４４９６号に記載さ
れている方法、すなわち、ＦＡＮＰにより通信資源の予
約を行うようにしてもよい。

【００８２】以上は、ＩＥＥＥ１３９４上の通信資源予
約をＲＳＶＰの上流のノードが行う場合についての説明
であった。これに対し、図８に示すように、ＩＥＥＥ１
３９４バス上の同期チャネルの確保を、下流側のノード
（本実施形態の場合、端末１０３）が行ってもよい。

【００８３】下流側のノードが必要な通信資源を持った
同期チャネルの確保を行った後（ステップＳ２１１
０）、上流側にＲＥＳＶメッセージの送出を行う（ステ
ップＳ２１１１）。この場合、確保した同期チャネルの
番号等は、続けて送出するＲＳＶＰのＲＥＳＶメッセー
ジに含めて送出しても良い。

【００８４】さて、端末１０３のユーザが、異なるビデ
オ映像( 例えば、違うチャンネルのテレビ番組) を見た
いと考えた場合、以上の同様の手続きをもう一度踏む事
になる。即ち、その新しいビデオ映像に対応するＩＰマ
ルチキャストアドレスを上位プロトコルなどを通じて入
手し、該ＩＰマルチキャストアドレスへの加入という手
続きを再度踏むことで、これを実現する。その際は、先
に加入していたＩＰマルチキャストアドレスは離脱する
ことが、通信資源の有効活用の観点から望ましい。この
様子を図９に示している。

【００８５】また、家庭内に構築されたネットワークに
は端末が複数接続され、その各々が別々の放送を見てい
る場合は、その各々のデータが公衆網１０４および接続
装置１０２を通ることになる。接続装置１０２におい
て、データリンクスイッチを行うため、別々のＡＴＭ−
ＶＣにて別々の端末宛てのこれらのデータが伝送されて
くることが望ましい。通信資源の確保については、再度
上記のようなＳＢＭ／ＲＳＶＰ／ＦＡＮＰ等を使った手
続きが必要あるかどうかは、ＲＳＶＰ／ＳＢＭの予約の
仕方による。即ち、ＳｈａｒｅｄＥｘｐｌｉｃｉｔの
予約であれば、送信者のビデオサーバが同一である限
り、あるいはＳｈａｒｅｄＥｘｐｌｉｃｉｔのサーバ
のアドレスとして、次にビデオを送出する新しいビデオ
サーバが登録されていれば、先に予約したのと同一の通
信資源（ＡＴＭのＶＣ、１３９４の同期チャネル）をそ
のまま利用し続ければよく、ＩＰマルチキャストの再加
入を行うのみで良い。

【００８６】（Ｂ）次に、ＩＰマルチキャストアドレ
スは同じで、コンテンツが変わる場合を説明する。この
場合は、同一のマルチキャストアドレスを用いて、同一
のユーザに対して複数の映像サービスを行う形式とな
り、上位プロトコルを用いて映像コンテンツの変更（テ
レビのチャンネルの変更に相当）を行う形となる。

【００８７】このときも、最初の通信資源の確保までは
同じ手順を踏む。ただし、上位レイヤプロトコルを通し
て与えられるＩＰマルチキャストアドレスは、あらかじ
めその端末に固有に与えられた（あらかじめ、ネットワ
ークサービスプロバイダが、ユーザ毎、あるいは端末毎
に割当てておいた）ＩＰマルチキャストアドレスであっ
てもよい。端末の識別は、例えばネットワークサービス
プロバイダがあらかじめ端末毎に与えておいた識別子を
用いて、上位レイヤプロトコルを使って行う等の方法が
考えられる。

【００８８】次のコンテンツの変更（テレビのチャンネ
ルの変更に相当）の際に、端末は上位レイヤプロトコル
を用いて、このコンテンツ変更を要求する。ビデオサー
バ１０１は、使用しているＩＰマルチキャストアドレス
を変更することなく、そのまま用い、変更したコンテン
ツを、該ＩＰマルチキャストアドレス宛に送出する。

【００８９】前述の様に、このＩＰマルチキャストアド
レスは、図１０に示すように、必ずしもマルチキャスト
に用いる必要は無く、単一の端末に対するコンテンツ転
送に用いても良い。即ち、一つ一つのマルチキャストア
ドレスを、ビデオ配信の要求のあったユーザ( 端末) に
割当て、送出コンテンツの変更は、例えば上位レイヤプ
ロトコルにて対応する。

【００９０】また、接続装置１０２から送信されるＩＰ
パケットのポート番号の違いを見て、別々のマルチキャ
ストアドレスを割当てる判断のトリガとしてもよい。こ
のように、ユーザ毎、あるいはアプリケーション毎に別
々のＩＰマルチキャストアドレスを与えるようにするこ
とにより、ＩＰマルチキャストアドレスは端末に対して
動的な割当てが可能であることから、プライベートアド
レス環境においても、グローバルユニークなＩＰアドレ
スとの重複を心配すること無く、種々のコンテンツをプ
ライベートアドレスを持った端末に送信することが可能
となる。

【００９１】（第２の実施形態）次に、第２の実施形態
として、内部のネットワーク処理能力が低く、自律的に
一連のＴＣＰ／ＩＰプロトコルの処理を行う機能を完全
には持っていない端末が受信端末になる場合について説
明する。

【００９２】この時、同じ家庭内のネットワークに接続
された別の制御ノードが、この端末に成り変わり、通信
資源の予約、マルチキャストプロトコルへの対応、上位
レイヤプロトコルへの対応等を行うことにより、外部網
（公衆網）とのやり取りを行うとともに、端末との本発
明の特徴であるプロトコルのやり取りにより、端末に対
して動的なＩＰアドレス、あるいはアプリケーションの
受信処理を可能とさせる。

【００９３】図１１は、本発明の第２の実施形態に係る
ネットワーク全体の構成例を示したもので、図１とほと
んど同様であるが、差分は、家庭内に構築されたネット
ワーク１１０６に端末１１０３とその制御ノード１１０
４が接続されている点である。

【００９４】制御ノード１１０４は、端末１１０３に成
り代わり、公衆網／インターネットとの制御のやり取り
を行うとともに、端末１１０３に対して、受信すべきＩ
Ｐアドレス、ポート番号、アプリケーション種別などを
通知する。

【００９５】端末１１０３は、基本的にはＩＰパケット
の受信機能と、あらかじめ定められたフォーマットのパ
ケットの処理機能を有する。例えば、端末１１０３がＭ
ＰＥＧ映像受信端末であれば、ＭＰＥＧｏｖｅｒＩＰの
パケットを受信できる機能、等である。

【００９６】このような限定された機能であれば、一連
の１３９４プロトコル（ＩＥＥＥ１３９４−１９９５ス
ペック、ＩＥＣ１８８３、ＡＶ／Ｃプロトコル等）に準
拠した既存のデジタルＡＶ機器へのハードウエア的、あ
るいはファームウエア的な小変更のみで構成することが
可能である。ただし、この端末１１０３には、従来には
ない新しい機能、即ち制御ノード１１０４からの受信す
べきＩＰフローについての情報、即ちＩＰアドレス、ポ
ート番号、アプリケーション種別等の通知を受け、これ
を自ら設定する機能が求められる。これについては後述
する。

【００９７】図１２にビデオサーバ１１０１から端末１
１０３へのビデオ転送を行う場合の処理シーケンスを示
す。ここでも、基本的には第１の実施形態と同様に、Ｉ
Ｐマルチキャストを通じて、ＭＰＥＧ等の映像サービス
が提供されているものとする。

【００９８】図１３には制御ノード１１０４、図１４に
は端末１１０３のそれぞれの処理シーケンスを示す。ま
ず、第１の実施形態と同様に、上位レイヤプロトコルを
通じて、番組内容やＩＰマルチキャストアドレスについ
ての情報を制御ノード１１０４が入手する（図１２のス
テップＳ１２０１〜Ｓ１２０３、図１３のステップＳ１
３０１）。

【００９９】次に、第１の実施形態と同様に、ＩＧＭＰ
（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔ
Ｐｒｏｔｏｃｏｌ）等を通じて、通知されたＩＰマル
チキャストアドレスへの加入を行う（図１２のＳ１２０
４〜Ｓ１２０６、図１３のステップＳ１３０２）。そし
て、これも第１の実施形態と同様に、ＲＳＶＰやＳＢ
Ｍ、ＦＡＮＰ、Ｑ．２９３１、ＩＥＥＥ１３９４、ＩＥ
Ｃ１８８３等の種々のプロトコルを用いて、ビデオーサ
ーバ１１０１から家庭内ネットワーク１１０６までの通
信資源の確保を行う（図１２のステップＳ１２０７〜Ｓ
１２０９、図１３のステップＳ１３０２）。

【０１００】この通信資源の確保と前後して、制御ノー
ド１１０４は、端末１１０３に対して、端末１１０３が
受信すべきＩＰパケットの種別を通知する（図１２のス
テップＳ１２１０、図１３のステップＳ１３０４）。

【０１０１】ここでは、宛先ＩＰアドレスであるＩＰマ
ルチキャストアドレス「Ｍ」、送信ＩＰアドレス「Ｇ．
１」、送信ポート番号「Ｓ０」、受信ポート番号「Ｓ
１」、アプリケーション種別（ＭＰＥＧｏｖｅｒＩＰ）
等を通知するものとる。ここでは、家庭内ネットワーク
１１０６はＩＥＥＥ１３９４であるものと仮定している
ので、この通知は端末１１０３内のレジスタへの書き込
みの形でこれを行うものとしてもよい。その場合は、そ
のレジスタに書き込まれたＩＰフローの属性を持つＩＰ
パケットを、端末装置は一時的に受信するように定義づ
けられているものとする。

【０１０２】家庭内ネットワーク１１０６が、例えばイ
ーサネットなどで構成されていたなら、レジスタへの書
き込みという形ではなく、ＢＯＯＴＰ（Ｂｏｏｔｓｔｒ
ｐＰｒｏｔｏｃｏｌ）の様なパケットのやり取りにてこ
れを行うことも可能である。

【０１０３】端末１１０３は、このレジスタに書き込ま
れた属性を持つＩＰパケットは、これを取り込む機能を
持つ。これは、例えば、このレジスタに書き込まれた属
性以外の属性を持ったＩＰパケットは常にすべて廃棄
し、書き込まれた属性のもののみ、特に制御用パケット
（例えば、ＩＣＭＰ（ＩｎｔｅｒｎｅｔＣｏｎｔｏｒ
ｏｌＭｅｓｓａｇｅＰｒｏｔｏｃｏｌ）等のＩＰプ
ロトコル内のエラー制御のためのプロトコルのメッセー
ジを載せたパケットでもよい）を送り返すことなく、受
信するようにしておけばよい。

【０１０４】また、アプリケーション種別として、例え
ばＭＰＥＧｏｖｅｒＩＰ等と通知された場合は、どのよ
うなフォーマットで、ＭＰＥＧデータがＩＰパケットを
使って送られてくるかを端末１１０３があらかじめ認識
できる場合がある。例えば、ＭＰＥＧデータをＲＴＰを
用いて伝送するような場合であり、この場合は、ＩＥＴ
ＦにてＭＰＥＧデータの伝送フォーマットが定められて
いるため、フォーマットの予測が可能である。このよう
な場合、受信したデータをいちいち解析する必要も必ず
しもなく、単純に、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰ
ヘッダの削除を行い、ＭＰＥＧフレームを抽出して、そ
れをそのままＭＰＥＧデコーダに渡す、といった方式の
適用が可能となる。この時、ＲＴＣＰ（リアルタイム制
御プロトコル）の受信情報の送出は、制御ノードが行う
ため、端末が行う必要はない。

【０１０５】端末１１０３は、単に上記ＩＰパケットの
受信を行うのみである。このようにすることにより、ネ
ットワークが家庭内ネットワーク、公衆網等と相互接続
され、ＩＰパケット以外でのデータ転送が難しい状況の
もとで、従来ソフトウエアにてＩＰパケットを受信、処
理する複雑な機構を準備する必要のあった端末の構成
を、以上紹介したような極めて単純なＩＰ受信機能を持
つのみとすることができ、ネットワークの相互接続環境
における端末の構成コストを大幅に削減することが可能
となる。これは、制御ノードと端末間で、必要なＩＰア
ドレス、ポート番号、アプリケーション種別などの情報
をやり取りすることにより、可能となるものである。

【０１０６】さて、制御ノード１１０４は、このＩＰア
ドレスなどの通知と前後して、第１の実施形態で説明し
たＩＥＣ１８８３プロトコルを用いて、予約したＭＰＥ
ＧフレームがＩＰパケットにカプセル化されて転送され
てくる同期チャネルや、その帯域情報等を端末１１０３
のＰＣＲ（ＩＥＥＥ１３９４のＰｌｕｇｓＣｏｎｔｏ
ｒｏｌＲｅｇｉｓｔｅｒ）に登録してもよい（図１２
のステップＳ１２１２、図１３のステップＳ１３０５、
図１４のステップＳ１４０１）。しかる後、接続装置１
１０２を介して、ＩＰマルチキャストアドレス「Ｍ」宛
にビデオデータがＭＰＥＧｏｖｅｒＩＰの形で転送され
てくる（図１２のステップＳ１２１３〜Ｓ１２１４、図
１３のステップＳ１３０６、図１４のステップＳ１４０
２）。

【０１０７】これに対して、ＲＴＣＰ等のプロトコルを
用いて、もっぱら送信側にレスポンスを返すのは制御ノ
ード１１０４の役割である（図１２のステップＳ１２１
５、図１３のステップＳ１３０７）。端末１１０３は、
もっぱらＭＰＥＧｏｖｅｒＩＰのデータを受信するのみ
でよい。

【０１０８】図１４のフローチャートに示すように、端
末１１０３は、受信したＩＰパケットがマルチキャスト
アドレス「Ｍ」宛ならば、これを廃棄せずに受信し（図
１４のステップＳ１４０３、ステップＳ１４０５）、更
に受信するパケットはＭＰＥＧｏｖｅｒＩＰであること
をＩＥＣ１８８３によりあらかじめ認識しているため、
該フレームをあらかじめ定められたフォーマットに従っ
てはずし、ＭＰＥＧフレームをリアセンブリし、ＭＰＥ
Ｇデータの再生をもっぱら行う（図１４のステップＳ１
４０４）。

【０１０９】この端末１１０３が該ＩＰアドレス( 本実
施形態ではＩＰマルチキャストアドレス「Ｍ」) を使い
続けるのは、前記レジスタにこのＩＰアドレス等が登録
してある間としてもよいし、ＢＯＯＴＰと同様なプロト
コルパケットを、制御ノード１１０４が端末１１０３に
定期的に送信し続けている間としてもよい。即ち、受信
ＩＰアドレス等の状態はＲＳＶＰプロトコル等と同様に
ソフトステートとし、一定時間通知がないと、その端末
はその属性（ＩＰアドレス等）宛てのＩＰパケットの受
信をやめてしまう仕掛けとしておくことにより、制御ノ
ード１１０４の故障などが原因で、その端末１１０３が
永久にそのアドレスが登録されてしまうことを避ける。

【０１１０】ここで紹介した機構は、ＩＰマルチキャス
トアドレス以外のＩＰアドレスを一時的に端末１１０３
に与えることも可能とする。例えば、図１５のように、
唯一グローバルＩＰアドレスを持った接続装置１１０２
が制御ノードである場合に、該制御ノード自身のＩＰア
ドレス（グローバルＩＰアドレス）を端末１１０３に一
時的に使用( 受信) させることが可能である。

【０１１１】また、接続装置１１０２にて受信パケット
をデータリンクレイヤでのスイッチングを行ってしまう
ため、グローバルなＩＰアドレスがプライベートネット
内（家庭内ネットワーク内）に侵入してくる際にも、グ
ローバルＩＰアドレスを一時的にこのような端末に受信
させることにより、接続装置１１０２内でのアドレス変
換( ＮＡＴ処理）が必須のものではもはやなくなる。こ
れは、端末１１０３がグローバルＩＰアドレスを用いた
処理は、該グローバルＩＰアドレス宛てのＩＰパケット
の受信のみであり、また該ＩＰパケットは該端末以外に
は伝送されない。また、該端末１１０３は、該グローバ
ルＩＰアドレスを用いたＩＰパケット送信処理を行うこ
とがない。このため、全体的な矛盾（同じグローバルＩ
Ｐアドレスを２つ以上の端末が同時に送信アドレスとす
る等) を生ずることがない。

【０１１２】また、ＩＰルーチングではなく、接続装置
１１０２内でのデータリンクレイヤ情報のみを使った、
高速スイッチングが可能となり、映像など高速なスイッ
チングが求められる状況において、接続装置１１０２内
のスイッチング機構を、ＩＰレイヤ処理にてこれを行う
場合と比較して、効率の大幅な向上が見込め、もって大
幅に低コストで実現することが可能となる。

【０１１３】次に、図１６を参照して、ＩＰアドレス・
ポート番号通知プロトコルの他の使い方に付いて説明す
る。図１６は、図１５の制御ノード１１０２と端末１１
０３の通信資源確保後のシーケンスに対応するものであ
り、図１５のステップＳ１５０４、Ｓ１５０５、Ｓ１５
０６、Ｓ１５０９が、図１６のステップＳ１６０１、Ｓ
１６０２、Ｓ１６０３、Ｓ１６０４にそれぞれ対応す
る。

【０１１４】さて、ここで例えば転送されてくるＩＰア
ドレスの宛先ＩＰアドレスが変更になる場合（例えば、
番組変更にともなう、ＩＰマルチキャストアドレスの変
更）や、ポート番号の変更があった場合に端末１１０３
に対して、これまで使用していたＩＰアドレス、ポート
番号をもったＩＰパケットの受信を中断し、そのかわ
り、新しく受信されるべきＩＰパケットの属性（ＩＰア
ドレス、ポート番号）等を通知することで対応する（図
１６のステップＳ１６０５、Ｓ１６０６）。このように
することで、端末１１０３は、新たなＩＰパケット群の
受信を行うことができるようになる（図１６のステップ
Ｓ１６０７）。

【０１１５】また、上記ＩＰパケット群の受信を終了さ
せる場合は、ステップＳ１６０８において、該ＩＰアド
レス、ポート番号でのＩＰパケット受信を終了させる通
知を制御ノード１１０２が端末１１０３に送出すること
によって、これをおこなうことが可能である。

【０１１６】このように、一連のＩＰアドレス、ポート
番号通知のプロトコルは、「一時的に、これらのＩＰア
ドレスを使いなさい」という意味で使われるインターネ
ットのＤＨＣＰプロトコル（動的ホスト構成プロトコ
ル）と共通点が見いだせる。そのことから、ＤＨＣＰの
オプションとして、このＩＰアドレス・ポート番号通知
プロトコルを実装する事も可能である。

【０１１７】すなわち、図１７に示すように、ＤＨＣＰ
パケットに、それがＩＰアドレス・ポート番号通知プロ
トコルとして使用するものであるかどうかを示すオプシ
ョンフィールドを設け、更に使用するべきＩＰアドレ
ス、ポート番号等を記述する。必要であれば、使用を中
止するＩＰアドレス、ポート番号などを記述する領域が
あっても良い。また、該ＩＰアドレス、ポート番号につ
いて、その属性の使用開始を促すものなのか、使用終了
を促すものなのかをそれぞれ示すフィールドがあっても
良い。

【０１１８】また、ＩＥＥＥ１３９４の場合には、これ
らの情報をやりとりするための専用のレジスタを端末が
持つようにするようにしてもよい。この場合、図１７の
ペイロード領域のデータを、その特定のレジスタに書き
込んだり、読み込んだりしていくことになる。

【０１１９】なお、以上の説明は、現行のＩＰであるＩ
Ｐｖ４のみならず、ＩＰｖ６の場合もそのまま適用が可
能である。また、上記実施形態に示した手法は、特定の
ＩＰマルチキャストアドレスをＩＥＥＥ１３９４の任意
の非同期ストリームにおいて転送する場合の、そのＩＰ
マルチキャストアドレスと非同期ストリームのチャネル
番号との対応関係の通知に用いることができることも明
らかである。すなわち、図２のステップＳ２１１におい
て、チャネルを確保し、そのチャネル番号と、そのチャ
ネルを通じて転送するＩＰマルチキャストアドレスとの
対応関係を通知すればよい。それ以外は、前述同様であ
る。

【０１２０】さらに、上記実施形態に示した手法は、イ
ーサネットにおける一時的な受信端末への受信データフ
ローの通知等、データリンクレイヤにおける通信資源の
確保は伴わない場合においても適用が可能である。この
場合、ＩＥＥＥ１３９４における通信資源の確保のシー
ケンスが省略され、その代わり通信資源としては、通常
のＭＡＣアドレスが使われることとなり、以降はこのＭ
ＡＣアドレス宛てのフレームを通じて、該通知したデー
タフローが転送されることになる。

【０１２１】

【発明の効果】以上説明したように、本発明によれば、
プライベートＩＰ網とグローバルＩＰ網の間に入る接続
装置内で稼動されるＮＡＴの変換処理は多大な処理負荷
がかかる事が知られており、映像等の高速なデータ転送
を、ＮＡＴ技術と併用して利用しようとすると、非常に
高コストの接続装置を用意する必要が生ずるという問題
点に対し、受信端末あるいは受信アプリケーションにＩ
Ｐマルチキャストアドレスを与え、データ転送をＩＰマ
ルチキャストアドレスを用いて行い、ＮＡＴ処理を不要
とすることにより、低コストで高速データ転送を行うこ
とが可能となる。

【０１２２】また、多くの家電製品にとって、ＩＰ処理
機能をフルで持つことは、冗長であるという問題点に対
し、受信すべきＩＰフローについての情報を装置に与
え、その装置は一時的にそのＩＰフローの受信のみを行
っていればよいという方法を用いる事により、複雑とい
われているＩＰ処理機能を、その受信機能のみの実装を
用意すればよいことになり、装置構成の大幅な簡略化と
低コスト化が可能となる。

【図面の簡単な説明】

【図１】本発明の第１の実施形態に係るネットワーク全
体の構成例を示したもので、映像サービスを提供してい
るビデオサーバからのデータを、公衆網を介して家庭内
ネットワークにとりこみ、家庭内ネットワークに接続さ
れた端末で、該サービスを受ける状況を説明するための
図。

【図２】図１の端末が接続装置、公衆網を通してビデオ
サーバからビデオを転送してもらうまでの全体の処理手
順を示した図で、ＩＥＥＥ１３９４上の通信資源予約を
ＲＳＶＰの上流のノードが行う場合を示している。

【図３】図１の端末が接続装置、公衆網を通してビデオ
サーバからビデオを転送してもらうまでの端末の処理手
順を示した図。

【図４】図１の端末が接続装置、公衆網を通してビデオ
サーバからビデオを転送してもらうまでの接続装置の処
理手順を示した図。

【図５】接続装置に記憶される対応テーブルの一例を示
した図。

【図６】ＲＳＶＰのＰＡＴＨメッセージのフォーマット
の一例を示した図。

【図７】ＩＥＥＥ１３９４のＰＣＲレジスタの記述例を
示した図。

【図８】図１の端末が接続装置、公衆網を通してビデオ
サーバからビデオを転送してもらうまでの通信システム
全体の処理手順を示した図で、ＩＥＥＥ１３９４上の通
信資源予約をＲＳＶＰの下流のノードが行う場合を示し
ている。

【図９】すでに加入したＩＰマルチキャストアドレスを
離脱して異なるＩＰマルチキャストアドレスに加入し、
異なるコンテンツの配送を行う場合について説明するた
めの図。

【図１０】ＩＰマルチキャストアドレスは同じで、コン
テンツが変わる場合について説明するための図。

【図１１】本発明の第２の実施形態に係るネットワーク
全体の構成例を示した図。

【図１２】図１１のビデオサーバから端末へのビデオ転
送を行う場合の全体の処理手順を示した図で制御ノード
が受信端末を代行してＩＰ処理、通信資源の予約等を行
う場合を示している。

【図１３】図１１のビデオサーバから端末へのビデオ転
送を行う場合の制御ノードの処理手順を示した図。

【図１４】図１１のビデオサーバから端末へのビデオ転
送を行う場合の端末の処理手順を示した図。

【図１５】図１１のビデオサーバから端末へのビデオ転
送を行う場合の端末の処理手順を示した図で、制御ノー
ド（接続装置）のグローバルＩＰアドレスを使用してビ
デオ転送を行う場合の制御ノードから端末へのＩＰアド
レス、ポート番号の通知方法を示している。

【図１６】制御ノードから端末へのＩＰアドレス、ポー
ト番号の他の通知手順を示した図。

【図１７】制御ノードから端末へのＩＰアドレス、ポー
ト番号を通知するためのＤＨＣＰパケットの一例を示し
た図。

【符号の説明】

１０１…ビデオサーバ（通信装置、送信端末）１０２…接続装置（通信制御装置）１０３…端末（通信装置）１０４…公衆網１０５…第１の家庭内ネットワーク（ＩＥＥＥ１３９
４）１０６…第２の家庭内ネットワーク１１０１…ビデオサーバ（通信装置、送信端末）１１０２…接続装置（通信制御装置）１１０３…端末（通信装置、受信端末）１１０４…制御ノード（通信制御装置）１１０５…公衆網１１０６…家庭内ネットワーク（ＩＥＥＥ１３９４）

Claims

【特許請求の範囲】

【請求項１】放送型のネットワークに接続された通信
装置において、ネットワークレイヤのマルチキャストアドレスのデータ
を受信したとき、前記ネットワークに接続された第２の
通信装置が前記マルチキャストのデータを受信するため
の通信資源を確保する手段と、少なくとも前記確保された通信資源の識別情報と前記マ
ルチキャストのデータの識別情報とを前記第２の通信装
置に通知する通知手段と、前記マルチキャストのデータを前記確保された通信資源
を用いて前記第２の通信装置へ配信する配信手段と、を具備したことを特徴とする通信装置。
【請求項２】放送型のネットワークに接続された通信
装置であって、ネットワークレイヤのマルチキャストアドレスと前記ネ
ットワークに接続された第２の通信装置のプライベート
アドレスとを対応付ける対応テーブルを記憶する記憶手
段と、前記マルチキャストアドレスのデータを受信したとき、
前記対応テーブルを参照して該データを受信する第２の
通信装置へ該データを配信する配信手段と、を具備したことを特徴とする通信装置。
【請求項３】放送型のネットワークに接続された通信
装置において、前記ネットワークに接続された第２の通信装置がネット
ワークレイヤのデータフローを受信するための通信資源
を確保する手段と、少なくとも前記確保された通信資源の識別情報と前記デ
ータフローの識別情報とを前記第２の通信装置に通知す
る通知手段と、前記データフローを前記確保された通信資源を用いて前
記第２の通信装置へ配信する配信手段と、を具備したことを特徴とする通信装置。
【請求項４】第１のネットワークと放送型の第２のネ
ットワークを接続する通信装置において、前記第１のネットワークに接続された第２の通信装置に
対しネットワークレイヤのデータフローの配送を要求す
る要求手段と、前記第２のネットワークに接続された第３の通信装置が
前記データフローを受信するための通信資源を確保する
手段と、少なくとも前記確保された通信資源の識別情報と前記デ
ータフローの識別情報とを前記第３の通信装置に通知す
る通知手段と、前記データフローを前記確保された通信資源を用いて前
記第３の通信装置へ配信する配信手段と、を具備したことを特徴とする通信制御装置。
【請求項５】放送型のネットワークに接続された信装
置であって、前記ネットワークに接続された第２の通信装置へのネッ
トワークの通信資源の識別情報と、任意のネットワーク
レイヤのデータフローの識別情報とを前記第２の通信装
置に通知する通知手段と、前記データフローを前記通信資源を用いて前記第２の通
信装置へ配信する配信手段とを具備し、前記データフローの宛先ネットワークレイヤアドレス
は、前記第２の通信装置のもともとのネットワークレイ
ヤアドレスとは異なることを特徴とする通信装置。
【請求項６】前記通信装置は、前記ネットワーク上
に、前記第２の通信装置が前記ネットワークレイヤのデ
ータフローを受信するための通信資源を確保する手段を
さらに具備したことを特徴とする請求項５記載の通信装
置。
【請求項７】前記通信装置は、第３の通信装置に対
し、前記ネットワークレイヤのデータフローの配信を要
求する手段をさらに具備したことを特徴とする請求項５
または請求項６記載の通信装置。
【請求項８】前記通信装置は、トランスポート層より
も上位レイヤの処理を、前記第３の通信装置と交す処理
手段をさらに具備したことを特徴とする請求項７記載の
通信装置。
【請求項９】放送型のネットワークに接続された通信
装置であって、前記ネットワークに接続される他の通信装置から通知さ
れる所定のネットワークレイヤのデータフローの識別情
報と、該データフローの配送に利用される前記ネットワ
ークの通信資源の識別情報との対応関係の通知を受信す
る第１の受信手段と、一時的に前記所定のネットワークレイヤのデータフロー
を受信する第２の受信手段と、を具備し、前記データフローの宛先ネットワークレイヤ
アドレスは、本通信装置のもともとのネットワークレイ
ヤアドレスとは異なることを特徴とする通信装置。