JPH10112730A - 通信端末装置および中継装置およびネットワーク間接続ケーブル - Google Patents

通信端末装置および中継装置およびネットワーク間接続ケーブル

Info

Publication number
JPH10112730A
JPH10112730A JP26449696A JP26449696A JPH10112730A JP H10112730 A JPH10112730 A JP H10112730A JP 26449696 A JP26449696 A JP 26449696A JP 26449696 A JP26449696 A JP 26449696A JP H10112730 A JPH10112730 A JP H10112730A
Authority
JP
Japan
Prior art keywords
data
physical network
header
address
network
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.)
Granted
Application number
JP26449696A
Other languages
English (en)
Other versions
JP3719789B2 (ja
Inventor
Takeshi Saito
健 斉藤
Yoshiaki Takahata
由彰 高畠
Mikio Hashimoto
幹生 橋本
Yukio Kamaya
幸男 釜谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP26449696A priority Critical patent/JP3719789B2/ja
Priority to EP19970117278 priority patent/EP0835037A3/en
Priority to US09/036,197 priority patent/US6751221B1/en
Publication of JPH10112730A publication Critical patent/JPH10112730A/ja
Priority to US10/830,020 priority patent/US7466705B2/en
Application granted granted Critical
Publication of JP3719789B2 publication Critical patent/JP3719789B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40058—Isochronous transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2832—Interconnection of the control functionalities between home networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2838—Distribution of signals within a home automation network, e.g. involving splitting/multiplexing signals to/from different paths
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40065—Bandwidth and channel allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40117—Interconnection of audio or video/imaging devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/169—Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0478—Provisions for broadband connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/282—Controlling appliance services of a home automation network by calling their functionalities based on user interaction within the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/2821—Avoiding conflicts related to the use of home appliances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/2849—Audio/video appliances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5619—Network Node Interface, e.g. tandem connections, transit switching
    • H04L2012/5623—Network design, dimensioning, topology or optimisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5665—Interaction of ATM with other protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5665—Interaction of ATM with other protocols
    • H04L2012/5667—IP over ATM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5685—Addressing issues

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Automation & Control Theory (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Abstract

(57)【要約】 【課題】家庭内ネットワークの大規模化および多様化
（種々のネットワークを使用）が図れる通信端末装置お
よび中継装置およびネットワーク間接続ケーブルを提供
する。 【解決手段】１または複数の物理ネットワークを介して
相手端末装置へ情報データを送信する際、少なくとも、
その相手端末装置のＩＰアドレス情報と物理ネットワー
クに依存するヘッダ若しくはチャネル情報を含む制御メ
ッセージを送信する第１の送信手段と、この第１の送信
手段で送信された制御メッセージに呼応した、相手端末
装置までの情報データを送信するための経路が設定され
た旨を通知する応答メッセージを受信する第１の受信手
段と、この第１の受信手段で応答メッセージが受信され
たとき、少なくともヘッダ若しくはチャネル情報を含む
情報データパケットを相手端末装置に送信する第２の送
信手段とを具備する。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、ホームネットワー
ク環境を構築するネットワークシステムに関する
【０００２】
【従来の技術】近年、マルチメディアという言葉に代表
されるように、電子機器のデジタル化が急速に進行して
いる。この傾向は、まずオフィス環境で始まっている。
【０００３】具体的には、まずハードウエアとしては、
パソコンの導入、ＯＡ機器のデジタル化、及びそれらの
ネットワーク化という形で進行している。また、ソフト
ウエアとして、ホストによる（あるいはライトサイジン
グされてパソコン等に移行されつつある）基幹業務や、
ワープロ、表計算などのソフトウエア、あるいはＷＷＷ
等のインターネットアプリケーション等、その発展はと
どまるところを知らない。
【０００４】この動きは、家庭においても見られる。即
ち、家庭においても、ＡＶ機器のデジタル化（ＤＶＤ、
デジタルＶＴＲ、デジタルビデオカメラ等）や、放送の
デジタル化、あるいはＯＣＮ等のインターネットアクセ
ス等の形で、デジタル化の進行は着実に進んでいる。
【０００５】オフィス環境と同様に、これらの波はネッ
トワーク化へと今後向かっていくことが考えられる。即
ち、情報・通信・放送といった種々の分野の技術がデジ
タル化によって束ねられ、ネットワーク化によって、相
互乗り入れを始めていくと言われている。
【０００６】このためのネットワーク技術としては種々
の候補が有る。例えば、イーサネットは、オフィス環境
にて圧倒的な実績を持っており、家庭でのパソコンネッ
トワークにおいても、その最有力候補であろう。また、
ＡＴＭも有力な候補である。これは、インフラの構築側
（電話会社やＣＡＴＶ等）が、高速、リアルタイム、広
帯域といったＡＴＭの特徴に注目し、この技術を使って
インフラを構築していこうというのが一般的な動きであ
るからである。
【０００７】これらの候補に加えて、最近ＩＥＥＥ１３
９４なるネットワーク技術（バス技術）が注目を集めて
いる。これは、高速、リアルタイム（ＱＯＳ保証）、プ
ラグアンドプレイ等の数々の注目すべき特徴を持ってお
り、特にＡＶ業界から、デジタルＡＶ機器同士の接続法
式の最有力候補として、業界から大変な注目を集めてい
る。これにひきづられる様に、パソコンなどのコンピュ
ータ業界も、この技術への注目が集まりはじめた。
【０００８】当初は、家庭向けのデジタル機器の普及に
伴い、それらの機器の相互接続が、ユーザの好み・要望
により、これらの数々のネットワーク技術により実現さ
れていくだろう。このようにして、徐々に家庭内にデジ
タルネットワークの雛形が誕生していく。
【０００９】その次の段階として、これらのデジタルネ
ットワークを相互に接続したいという要求が出て来る。
例えば、１階の応接間の１３９４ネットワークに接続さ
れたＡＶ機器と、２階の部屋の１３９４ネットワークに
接続されたＡＶ機器とを、相互接続して、例えばダビン
グ等、協調動作をさせようというような場合である。
【００１０】
【発明が解決しようとする課題】しかしながら、これを
実現するには、以下のような大きな問題がある。
【００１１】（１）１３９４ネットワークは大規模化に
適していない。たとえば、ケーブル長が４．５ｍに制限
されており、部屋をまたがった配線を行うのは困難であ
る。また、１３９４のプラグアンドプレイ機能には、こ
れにともなう副作用として、誰かが１３９４に接続、あ
るいは離脱すると、一瞬通信が途絶えるという特性を持
つ。部屋をまたがって１３９４を配線しようとすると、
別の部屋での挙動が、そのまた別の部屋に「通信断」と
なって現れるため不便である。
【００１２】（２）１３９４間の相互接続プロトコル／
方式である「１３９４ブリッジ」の仕様の検討／標準化
が１３９４の標準化委員会である１３９４ＴＡにて開始
されている。しかし、その仕様は、スケーラビリティを
要求し、呼設定の概念なども取り込むなど、非常に複雑
なものになる事が予想され、時間もまたかかるものと予
想される。
【００１３】（３）家庭内のネットワークは１３９４ば
かりであるとは考えられないので、種々のネットワーク
を相互に接続するような方式で家庭内ネットワークを構
築する事が望ましい。ところが、そのようなアーキテク
チャの提案はまだない。
【００１４】（４）種々のネットワークの相互接続技術
としては、インターネットプロトコルがある。しかし、
この方式は、その設定、管理、維持が素人には難しく、
サーバの管理なども伴うので、端末数も多いとは言えな
い家庭向けの方式としては、現在のままでは適用しにく
い。
【００１５】本発明は、以上の問題点を解決することを
目的とする。
【００１６】
【課題を解決するための手段】
（請求項１） 本発明の通信端末装置は、１または複数
の物理ネットワークを介して相手端末装置へ情報データ
を送信する際、少なくとも、その相手端末装置のＩＰア
ドレス情報と物理ネットワークに依存するヘッダ若しく
はチャネル情報を含む制御メッセージを送信する第１の
送信手段と、この第１の送信手段で送信された制御メッ
セージに呼応した、前記相手端末装置までの情報データ
を送信するための経路が設定された旨を通知する応答メ
ッセージを受信する第１の受信手段と、この第１の受信
手段で前記応答メッセージが受信されたとき、少なくと
も前記ヘッダ若しくはチャネル情報を含む情報データを
前記ＩＰアドレス情報に対応するプロトコルレイヤより
上位のレイヤパケットにて前記相手端末装置に送信する
第２の送信手段と、を具備することにより、複数の物理
ネットワークが相互接続された環境において、任意の遠
方のネットワーク（送信ノードが属さない物理ネットワ
ーク）に属する受信ノード（相手端末装置）に対して、
任意のデータの送信を行うことが可能となる。すなわ
ち、隣接するノード（具体的には、送信ノードが属する
物理ネットワークにおける仮想コネクション、あるいは
同期チャネル等の終端ノード）に対し、後にデータを送
付するヘッダ情報（ＡＴＭ、ＩＥＥＥ１３９４等のパケ
ットを主体とする伝送方式を用いた物理ネットワークの
とき）、あるいは、チャネル情報（ＳＴＭ、ＨＦＣ等チ
ャネルの概念を持つ伝送方式を用いた物理ネットワーク
のとき）と、データを受け取るべきノードのＩＰアドレ
スを通知することにより、該隣接するノードに、今後こ
のヘッダ情報若しくはチャネル情報を有した情報の転送
先は、該データを受け取るべきノードのＩＰアドレスで
あることを通知することが可能である。また、このアド
レスをＩＰアドレスとすることにより、複数種類の物理
ネットワークが相互接続されている環境においても、共
通して利用できるアドレス体系とすることが出来、伝送
方式の異なる物理ネットワークに属したノードに対して
も、データの送信や制御メッセージの送信を行うことが
可能となる。また、データを受け取るべきノードからの
確認信号（ＡＣＫ）を受け付けた後に、データの送信を
行うことで、途中ノードにおけるコネクション設定が完
了した旨を認識することが可能となり、データの送信の
開始が可能となる。また、途中ノードのコネクション設
定が完了していれば、送信するデータはＩＰパケットに
限定する必然性はなく、ＭＰＥＧ映像や音声など、生の
データの送信が可能となる。
【００１７】（請求項２）また、本発明の通信端末装置
は、１または複数の物理ネットワークを介して相手端末
装置へ情報データを送信する際、少なくとも、その相手
端末装置のＩＰアドレス情報と物理ネットワークに依存
するヘッダ若しくはチャネル情報と通信リソース量を含
む制御メッセージを送信する第１の送信手段と、この第
１の送信手段で送信された制御メッセージに呼応した、
前記相手端末装置までの情報データを送信するための経
路が設定された旨を通知する応答メッセージを受信する
第１の受信手段と、この第１の受信手段で前記応答メッ
セージが受信されたとき、少なくとも前記ヘッダ若しく
はチャネル情報を含む情報データを前記相手端末装置に
送信する第２の送信手段と、を具備することにより、複
数の物理ネットワークが相互接続された環境において、
任意の遠方のネットワーク（送信ノード（送信元の通信
端末装置）が属さない物理ネットワーク）に属する受信
ノードに対して、特定の通信品質のコネクションを両ノ
ード間に設定した上で、データの送信を行うことが可能
となる。すなわち、隣接するノード（具体的には、送信
ノードが属する物理ネットワークにおける仮想コネクシ
ョン、あるいは同期チャネル等の終端ノード）に対し、
後にデータを送付するヘッダ若しくはチャネル情報と、
データを受け取るべきノードのＩＰアドレスと、確保す
べき通信リソース量を通知することにより、該隣接する
ノードに、今後このヘッダ情報を有した情報の転送先
は、該データを受け取るべきノードのＩＰアドレスであ
ることを通知することが可能である。また、このアドレ
スをＩＰアドレスとすることにより、複数種類の物理ネ
ットワークが相互接続されている環境においても、共通
して利用できるアドレス体系とすることが出来、伝送方
式の異なる物理ネットワークに属したノードに対して
も、データの送信や制御メッセージの送信を行うことが
可能となる。また、確保すべき通信リソース量を申告す
ることで、伝送方式の異なる、複数種類の物理ネットワ
ークが相互接続されている環境においても、隣接ノード
に対して該確保すべき通信リソース量を通知することが
可能となり、もって、該隣接ノードも、そこから先のコ
ネクション設定に必要な該確保すべき通信リソース量を
知り、これをフォワードし、最終受信ノードまでのコネ
クション設定を行うことが可能となる。また、データを
受け取るべきノードからの確認信号を受け付けた後に、
データの送信を行うことで、途中ノードにおけるコネク
ション設定が、該確保すべき通信リソースを確保した上
で完了した旨を認識することが可能となり、データの送
信の開始が可能となる。
【００１８】（請求項３） また、デジタル映像および
またはデジタル音声を受信する第２の受信手段をさらに
具備し、前記第２の送信手段は、前記第２の受信手段で
受信されたデジタル映像およびまたはデジタル音声を所
定の物理ネットワークの伝送フォーマットに整合して、
前記相手端末装置に送信することにより、デジタル衛星
放送やＣＡＴＶのセットトップボックスのように生の、
あるいはＭＰＥＧ符号化等をされた映像／音声データを
受信し、これを特定の受信ノードまで該データをフォワ
ードする必要があるノードにおいて、これを、物理ネッ
トワークのフォーマットに合わせた上でこれを行うこと
が可能となる。
【００１９】（請求項４） また、圧縮されたデジタル
映像およびまたはデジタル音声を受信する第２の受信手
段をさらに具備し、前記第２の送信手段は、前記第２の
受信手段で受信された圧縮されたデジタル映像およびま
たはデジタル音声を伸長し、前記相手端末装置に送信す
ることにより、デジタル衛星放送やＣＡＴＶのセットト
ップボックスのようにＭＰＥＧ等の符号化方式で符号化
された映像／音声データを受信し、これを特定の受信ノ
ードまで、デコードされた映像／音声データをフォワー
ドする必要があるノードにおいて、これを行うことが可
能となる。このようにすることにより、通常大きな負荷
が予想されるＭＰＥＧ等のデコード機能、伸長機能を該
送信ノードに集中させることが可能となり、受信ノード
側にこのような機能を配備する必要がなくなるというメ
リットもある。
【００２０】（請求項５） 本発明の中継装置は、互い
にデータリンクレイヤ方式の相異なる少なくとも２つの
物理ネットワークを接続し、一方の物理ネットワークか
らの受信データを他方の物理ネットワークへ送信する中
継装置において、前記一方の物理ネットワークから、少
なくとも、データ送信先の端末装置の第１のアドレス情
報と前記一方の物理ネットワークに依存する第１のヘッ
ダあるいはチャンネル情報を含む第１の制御メッセージ
を受信する受信手段と、この受信手段で前記第１の制御
メッセージを受信したとき、少なくとも、前記第１のア
ドレス情報から求められる前記他方の物理ネットワーク
に依存する第２のヘッダ若しくはチャネル情報と前記第
１のアドレス情報を含む第２の制御メッセージを前記他
方の物理ネットワークに送信する第１の送信手段と、前
記受信手段で前記第１の制御メッセージを受信したと
き、前記第１のヘッダ若しくはチャネル情報と前記第２
のヘッダ若しくはチャネル情報の対応関係を記憶する記
憶手段と、前記一方の物理ネットワークから、前記第１
のヘッダ若しくはチャネル情報を含むデータを受信した
とき、その第１のヘッダ若しくはチャネル情報に対応す
る第２のヘッダ若しくはチャネル情報を前記記憶手段に
記憶された対応関係から求め、それを前記受信データに
付加して前記他方の物理ネットワークに送信する第２の
送信手段と、を具備することにより、ＡＴＭとＩＥＥＥ
１３９４バスのように互いにデータリンクレイヤ方式の
相異なる２つ以上のネットワークを相互接続するに際し
て、前段の隣接ノードから、後にデータの配送されてく
る第１の物理ネットワーク（一方の物理ネットワーク）
のヘッダ若しくはチャネル情報と、その宛先ノードの宛
先（第１のアドレス情報）を知ることができ、これらの
情報から、第２の物理ネットワーク（他方の物理ネット
ワーク）において使用されるヘッダ若しくはチャネル情
報と、宛先アドレス（第１のアドレス情報）との対応関
係を隣接ノードに知らせることができるとともに、第１
の物理ネットワーク上のヘッダ若しくはチャネル情報の
みを参照することにより、第２の物理ネットワークのヘ
ッダ若しくはチャネル情報をつけた上で、該データの配
送を行うことが可能となり、パケット毎にネットワーク
レイヤ処理部での処理が必要ないこともあいまって、大
幅な処理の高速化が、異種ネットワーク間においても可
能となる。
【００２１】（請求項６） また、本発明の中継装置
は、少なくとも２つの物理ネットワークを接続し、一方
の物理ネットワークからの受信データを他方の物理ネッ
トワークへ送信する中継装置において、前記一方の物理
ネットワークから、少なくとも、データ送信先の端末装
置の第１のアドレス情報と、前記一方の物理ネットワー
クに依存する第１のヘッダ若しくはチャネル情報を含む
第１の制御メッセージを受信する受信手段と、この受信
手段で前記第１の制御メッセージを受信したとき、少な
くとも、前記第１のアドレス情報から求められる前記他
方の物理ネットワークに依存する第２のヘッダ若しくは
チャネル情報と前記第１のアドレス情報を含む第２の制
御メッセージを前記他方の物理ネットワークに送信する
第１の送信手段と、前記受信手段で前記第１の制御メッ
セージを受信したとき、前記第１のヘッダ若しくはチャ
ネル情報と前記第２のヘッダ若しくはチャネル情報の対
応関係を記憶する記憶手段と、前記一方の物理ネットワ
ークから、前記第１のヘッダ若しくはチャネル情報を含
むデータを受信したとき、その第１のヘッダ若しくはチ
ャネル情報に対応する第２のヘッダ若しくはチャネル情
報を前記記憶手段に記憶された対応関係をから求め、そ
れを前記受信データに付加して前記他方の物理ネットワ
ークに送信する第２の送信手段と、前記第２の送信手段
で送信されるデータの伝送フォーマットを前記一方の物
理ネットワークの伝送フォーマットから前記他方の物理
ネットワークの伝送フォーマットに変換する変換手段
と、を具備することにより、２つ以上の物理ネットワー
クを相互接続するに際して、前段の隣接ノードから、後
にデータの配送されてくる第１の物理ネットワーク（他
方の物理ネットワーク）へのヘッダ若しくはチャネル情
報と、その宛先ノードの宛先（第１のアドレス情報）を
知ることができ、これらの情報から、第２の物理ネット
ワーク（他方の物理ネットワーク）において使用される
ヘッダ若しくはチャネル情報と、宛先アドレス（第１の
アドレス情報）との対応関係を隣接ノードに知らせるこ
とができるとともに、物理ネットワークのヘッダ若しく
はチャネル情報のみを参照することにより、該第２の物
理ネットワークのヘッダ情報をつけた上で、該データの
配送を行うことが可能となり、パケット毎にネットワー
クレイヤ処理部での処理が必要ないこともあいまって、
大幅な処理の高速化が、異種ネットワーク間においても
可能となる。また、隣接ノードとの間で、後に転送され
るデータの属性によって、その転送フォーマットが第１
の物理ネットワークと、第２の物理ネットワークとの間
で異なる場合に、適切な処置（フォーマット変換）を施
すことが可能となる。
【００２２】（請求項７） また、前記変換手段は、前
記第２の送信手段にて送信されるＭＰＥＧデータの伝送
フォーマットを、前記一方の物理ネットワークのＭＰＥ
Ｇデータの伝送フォーマットから前記他方の物理ネット
ワークのＭＰＥＧデータの伝送フォーマットに変換する
ことにより、隣接ノードとの間で、後に転送されるＭＰ
ＥＧデータの転送フォーマットが、物理ネットワークの
種別によって、異なる場合（例えば、ＡＴＭ網とＩＥＥ
Ｅ１３９４バスとを相互接続する場合の、ＭＰＥＧｏｖ
ｅｒＡＴＭとＭＰＥＧｏｖｅｒ１３９４のような場合）
において、適切な処置（フォーマット変換など）を施す
ことが可能となる。
【００２３】（請求項８） また、本発明の中継装置
は、少なくとも２つの物理ネットワークを接続し、一方
の物理ネットワークからの受信データを他方の物理ネッ
トワークへ送信する中継装置において、前記一方の物理
ネットワークから、少なくとも、データ送信先の端末装
置のＩＰアドレス情報と、前記一方の物理ネットワーク
に依存する第１のヘッダ若しくはチャネル情報を含む第
１の制御メッセージを受信する受信手段と、この受信手
段で前記第１の制御メッセージを受信したとき、少なく
とも、前記ＩＰアドレス情報から求められる前記他方の
物理ネットワークに依存する第２のヘッダ若しくはチャ
ネル情報と前記ＩＰアドレス情報を含む第２の制御メッ
セージを前記他方の物理ネットワークに送信する第１の
送信手段と、前記受信手段で前記第１の制御メッセージ
を受信したとき、前記第１のヘッダ若しくはチャネル情
報と前記第２のヘッダ若しくはチャネル情報の対応関係
を記憶する記憶手段と、前記一方の物理ネットワークか
ら、前記第１のヘッダ若しくはチャネル情報を含むデー
タを受信したとき、その第１のヘッダ若しくはチャネル
情報に対応する第２のヘッダ若しくはチャネル情報を前
記記憶手段に記憶された対応関係をから求め、それを前
記受信データに付加して前記他方の物理ネットワークに
送信する第２の送信手段と、を具備し、前記第１のヘッ
ダ若しくはチャネル情報を含むデータは、前記ＩＰレイ
ヤより上位のレイヤパケットであることにより、２つ以
上の物理ネットワークを相互接続するに際して、前段の
隣接ノードから、後にデータの配送されてくる第１の物
理ネットワークのヘッダ若しくはチャネル情報と、その
宛先ノードの宛先ＩＰアドレスを知ることができ、これ
らの情報から、第２の物理ネットワークにおいて使用さ
れるヘッダ若しくはチャネル情報と、宛先ＩＰアドレス
との対応関係を隣接ノードに知らせることができるとと
もに、該物理ネットワークのヘッダ若しくはチャネル情
報のみを参照することにより、該第２の物理ネットワー
クのヘッダ若しくはチャネル情報をつけた上で、該デー
タの配送を行うことが可能となり、パケット毎にネット
ワークレイヤ処理部での処理が必要ないこともあいまっ
て、大幅な処理の高速化が、異種ネットワーク間におい
ても可能となる。また、前記データの最終宛先は、ＩＰ
アドレスを用いる事により、複数種類の物理ネットワー
クが相互接続されている環境においても、共通して利用
できるアドレス体系とすることが出来、伝送方式の異な
る物理ネットワークを相互接続するような場合において
も、データや制御メッセージのフォワーディングを行う
ことが可能となる。また、該中継装置のデータリンクレ
イヤにおけるコネクション設定が完了していれば、該中
継装置におけるＩＰ処理の必然性がなくなるため、送信
するデータはＩＰパケットに限定する必然性はなく、Ｍ
ＰＥＧ映像や音声など、生のデータの送信が可能とな
る。
【００２４】（請求項９） また、本発明の中継装置
は、第１の物理ネットワークであるＩＥＥＥ１３９４バ
スと、第２の物理ネットワークを接続し、一方の物理ネ
ットワークからの受信データを他方の物理ネットワーク
へ送信する中継装置において、前記一方の物理ネットワ
ークから、少なくとも、データ送信先の端末装置の第１
のアドレス情報と、前記一方の物理ネットワークに依存
する第１のヘッダ若しくはチャネル情報を含む第１の制
御メッセージを受信する受信手段と、この受信手段で前
記第１の制御メッセージを受信したとき、少なくとも、
前記第１のアドレス情報から求められる前記他方の物理
ネットワークに依存する第２のヘッダ若しくはチャネル
情報と前記第１のアドレス情報を含む第２の制御メッセ
ージを前記他方の物理ネットワークに送信する第１の送
信手段と、前記受信手段で前記第１の制御メッセージを
受信したとき、前記第１のヘッダ若しくはチャネル情報
と前記第２のヘッダ若しくはチャネル情報の対応関係を
記憶する記憶手段と、前記一方の物理ネットワークか
ら、前記第１のヘッダ若しくはチャネル情報を含むデー
タを受信したとき、その第１のヘッダ若しくはチャネル
情報に対応する第２のヘッダ若しくはチャネル情報を前
記記憶手段に記憶された対応関係をから求め、それを前
記受信データに付加して前記他方の物理ネットワークに
送信する第２の送信手段と、を具備することにより、１
３９４バス同士、もしくは１３９４バスと任意の物理ネ
ットワークが相互接続された環境において、任意の遠方
のネットワーク（送信ノードが属さない物理ネットワー
ク）に属する受信ノードに対して、任意のデータの送信
を行うことが可能となる。即ち、ＩＥＥＥ１３９４バス
同士、もしくはＩＥＥＥ１３９４バスと他の任意の物理
ネットワークとを相互接続させた相互接続ネットワーク
において、第１の物理ネットワークであるＩＥＥＥ１３
９４バス側の隣接ノードから、後にデータの配送されて
くる第１の物理ネットワークのヘッダ情報である宛先ノ
ードＩＤやチャネル番号と、その宛先ノードの宛先アド
レス（ＩＰアドレスなどのネットワークレイヤアドレス
でも良いし、１３９４アドレスやＭＡＣアドレスなどの
データリンクレイヤアドレスでも良い）を知ることがで
き、これらの情報から、第２の物理ネットワークにおい
て使用されるヘッダ若しくはチャネル情報（第２の物理
ネットワークにおける仮想コネクション識別子、あるい
は宛先ノードＩＤ、チャネル番号、もしくはＭＡＣアド
レス等）と、宛先アドレス（第１のアドレス情報）との
対応関係を第２の物理ネットワーク側の隣接ノードに知
らせることができるとともに（あるいは、逆に第２の物
理ネットワーク側からの情報を第１の物理ネットワーク
側に通知）、一方の物理ネットワークのヘッダ若しくは
チャネル情報（チャネル番号、宛先ノードＩＤ、仮想コ
ネクション識別子、ＭＡＣアドレス等）のみを参照する
ことにより、もう一方の物理ネットワークのヘッダ若し
くはチャネル情報（チャネル番号、宛先ノードＩＤ、仮
想コネクション識別子、ＭＡＣアドレス等）をつけた上
（変換した上）で、該データの配送を行うことが可能と
なり、大幅な処理の高速化が、１３９４バスと、他の任
意の物理ネットワーク間においても可能となる。
【００２５】（請求項１０） また、前記第２の物理ネ
ットワークは、ＩＥＥＥ１３９４バスとは異なる物理ネ
ットワークであることにより、ＩＥＥＥ１３９４バス同
士を相互接続しようとした場合に、その中間に位置され
る伝送方式として、例えば長距離やＱＯＳ（通信品質）
の確保に優れたＡＴＭや、コストに優れたイーサネット
等、その用途にあわせた任意の伝送方式を採用する事が
可能となり、相互接続環境の柔軟性の向上を図る事が出
来るようになる。
【００２６】（請求項１１） また、前記ＩＥＥＥ１３
９４バスにおいて転送される前記ヘッダ若しくはチャネ
ル情報は、ＩＥＥＥ１３９４バスの同期チャネル番号で
あることにより、中継装置においては、ＩＥＥＥ１３９
４バスの同期チャネル番号から、第２の物理ネットワー
ク（他方）のヘッダ若しくはチャネル情報（仮想コネク
ション識別子、同期チャネル番号、あるいはＭＡＣアド
レスなど）に直接変換する事（あるいはその逆）が可能
となり、特に通信品質を要求するデータの配送等の場合
のようにデータリンクレイヤスイッチングでエンド＝エ
ンドのデータ配送が望まれるような場合に、ＩＥＥＥ１
３９４バスの同期チャネルを用い、チャネル番号を仮想
コネクション識別子（例えばＡＴＭのＶＰＩ／ＶＣＩの
様に）用いる事ができることにより、これを実現する事
が可能となる。
【００２７】（請求項１２） また、前記一方の物理ネ
ットワークはＩＥＥＥ１３９４バスであり、前記第２の
物理ネットワークはイーサネットまたはトークンリング
またはＦＤＤＩであり、前記第２の物理ネットワークに
依存するヘッダ若しくはチャネル情報はＭＡＣアドレス
であることにより、ＭＡＣアドレスの値を元にした対応
テーブル、変換テーブルを用意して、１３９４バス側の
ヘッダ値とその属性、通信品質などを認識すること、あ
るいは逆に１３９４バスのヘッダ情報の値を基にしたテ
ーブルを用意して、第２の物理ネットワーク（他方の物
理ネットワーク）側のヘッダ情報（第２の物理ネットワ
ークに依存するヘッダ若しくはチャネル情報）の値とそ
の属性、通信品質などを認識する事が可能となり、もっ
て、対向したネットワーク側に該データのフォワーディ
ングをデータリンクレイヤ処理のみで行う事が可能とな
り、高速なフォワーディング処理が可能となる。もっ
て、第２の物理ネットワークの伝送方式として、ＭＡＣ
アドレスを用いる種々のフレーム方式を用いる事が可能
となる。
【００２８】（請求項１３） また、前記第２の物理ネ
ットワークはＡＴＭネットワークであり、前記第２の物
理ネットワークに依存するヘッダ若しくはチャネル情報
はＶＰＩ／ＶＣＩであることにより、ＶＰＩ／ＶＣＩの
値を基にした対応テーブル、変換テーブルを用意して、
１３９４バス側のヘッダ値とその属性、通信品質などを
認識すること、あるいは逆に１３９４バスのヘッダ情報
の値を元にしたテーブルを用意して、ＶＰＩ／ＶＣＩの
値（第２の物理ネットワークに依存するヘッダ若しくは
チャネル情報）とその属性、通信品質などを認識する事
が可能となり、もって、対向したネットワーク側に該デ
ータのフォワーディングをデータリンクレイヤ処理のみ
で行う事が可能となり、高速なデータフォワーディング
が可能となる。もって、第２の物理ネットワーク（他方
の物理ネットワーク）の伝送方式として、ＡＴＭを用い
る事が可能となる。
【００２９】（請求項１４） また、前記一方の物理ネ
ットワークはＩＥＥＥ１３９４バスであり、前記第２の
物理ネットワークは無線ネットワークであり、前記第２
の物理ネットワークに依存するヘッダ若しくはチャネル
情報は無線パケットの宛先データリンクレイヤアドレス
あるいは仮想識別子であることにより、宛先データリン
クレイヤアドレス、もしくは仮想識別子の値を元にした
対応テーブル、変換テーブルを用意して、１３９４バス
側のヘッダ値とその属性、通信品質などを認識するこ
と、あるいは逆に１３９４バスのヘッダ情報の値を元に
したテーブルを用意して、第２の物理ネットワーク側の
ヘッダ情報の値とその属性、通信品質などを認識する事
が可能となり、もって、対向したネットワーク側に該デ
ータのフォワーディングをデータリンクレイヤ処理のみ
で行う事が可能となり、高速なデータフォワーディング
が可能となる。また、伝送媒体として無線を用いる事に
より、１３９４バス同士の相互接続の様に、相異なるネ
ットワーク同士の接続を、中間媒体を無線とする事が可
能となり、長距離の配線や、両ネットワーク間に壁など
の障害がある場合に物理的に配線レスの相互接続を行う
事が可能となる。
【００３０】（請求項１５） また、請求項５、６、
９、１６に記載の中継装置において、前記第１のアドレ
ス情報は、ＩＰアドレスであることにより、複数種類の
物理ネットワークが相互接続されている環境において
も、共通して利用できるアドレス体系とすることがで
き、伝送方式の異なる物理ネットワークを相互接続する
ような場合においても、データや制御メッセージのフォ
ワーディングを行うことが可能となる。
【００３１】（請求項１６） また、本発明の中継装置
は、少なくとも２つの物理ネットワークを接続し、一方
の物理ネットワークからの受信データを他方の物理ネッ
トワークへ送信する中継装置において、前記一方の物理
ネットワークから、少なくとも、データ送信先の端末装
置の第１のＭＡＣアドレス情報と、前記一方の物理ネッ
トワークに依存する第１のヘッダ情報を含む第１の制御
メッセージを受信する受信手段と、この受信手段で前記
第１の制御メッセージを受信したとき、少なくとも、前
記第１のＭＡＣアドレス情報から求められる前記他方の
物理ネットワークに依存する第２のヘッダ情報と前記第
１のＭＡＣアドレス情報を含む第２の制御メッセージを
前記他方の物理ネットワークに送信する第１の送信手段
と、前記受信手段で前記第１の制御メッセージを受信し
たとき、前記第１のヘッダ情報と前記第２のヘッダ情報
の対応関係を記憶する記憶手段と、前記一方の物理ネッ
トワークから、前記第１のヘッダ情報を含むデータを受
信したとき、その第１のヘッダ情報に対応する第２のヘ
ッダ情報を前記記憶手段に記憶された対応関係をから求
め、それを前記受信データに付加して前記他方の物理ネ
ットワークに送信する第２の送信手段と、を具備するこ
とにより、２つ以上の物理ネットワークを相互接続され
たブリッジ網において、前段の隣接ノードから、後にデ
ータの配送されてくる第１の物理ネットワーク（一方の
物理ネットワーク）のヘッダ情報（第１の物理ネットワ
ークにおける宛先ＭＡＣアドレス）と、その宛先ノード
の宛先（第１のアドレス情報：最終宛先ＭＡＣアドレ
ス）を知ることができ、これらの情報から、第２の物理
ネットワーク（他方の物理ネットワーク）において使用
されるヘッダ情報（第２の物理ネットワークにおける宛
先ＭＡＣアドレス）と、宛先アドレス（第１のアドレス
情報：最終宛先ＭＡＣアドレス）との対応関係を隣接ノ
ードに知らせることができるとともに、該物理ネットワ
ークのヘッダ情報（第１の物理ネットワークにおける宛
先ＭＡＣアドレス）のみを参照することにより、該第２
の物理ネットワークのヘッダ情報（ＭＡＣアドレス）を
つけた上（変換した上）で、該データの配送を行うこと
が可能となり、大幅な処理の高速化が、異種ネットワー
ク間においても可能となる。ここで、ＭＡＣアドレスは
論理的な値、すなわち、仮想コネクション識別子として
用いてもよい。
【００３２】（請求項１７） また、前記第１および第
２の制御メッセージは、データパケット転送のために確
保すべき通信リソース量を含み、前記受信手段で前記第
１の制御メッセージを受信したとき、前記通信リソース
量に基づき前記他方の物理ネットワーク上に通信リソー
スを確保することにより、中継装置内においても、該通
信リソースを確保することが可能になるとともに、伝送
方式の異なる、複数種類の物理ネットワークが相互接続
されている環境においても、隣接ノード間で、確保すべ
き通信リソース量を通知することが可能となり、もっ
て、該隣接ノードも、そこから先のコネクション設定に
必要な該確保すべき通信リソース量を知り、これをフォ
ワードし、最終受信ノードまでのコネクション設定を行
うことが可能となる。（ＭＡＣによる接続の場合、）ブ
リッジ網の環境においても、送信ノード（通信端末装
置）と受信ノード（送信端末装置）の間で帯域等の通信
リソースの確保が行えるようになる。即ち、該中継装置
内においても、該通信リソースを確保することが可能に
なるとともに、ブリッジ網の環境においても、隣接ノー
ド間で、確保すべき通信リソース量を通知することが可
能となり、もって、該隣接ノードも、そこから先のコネ
クション設定に必要な該確保すべき通信リソース量を知
り、これをフォワードし、最終受信ノードまでのコネク
ション設定を行うことが可能となる。（１３９４による
接続の場合、）前記第１および第２の制御メッセージ
は、データパケット転送のために確保すべき通信リソー
ス量を含み、前記受信手段で前記第１の制御メッセージ
を受信したとき、前記通信リソース量に基づき前記他方
の物理ネットワーク上に通信リソースを確保することに
より、１３９４バスと、他の任意の物理ネットワークが
相互接続された環境においても、送信ノードと受信ノー
ドの間で帯域等の通信リソースの確保が行えるようにな
る。即ち、該中継ノード装置内においても、該通信リソ
ースを確保することが可能になるとともに、相互接続網
の環境においても、隣接ノード間で、確保すべき通信リ
ソース量を通知することが可能となり、もって、該隣接
ノードも、そこから先のコネクション設定に必要な該確
保すべき通信リソース量を知り、これをフォワードし、
最終受信ノードまでのコネクション設定を行うことが可
能となる。
【００３３】（請求項１８） また、前記第１および第
２の制御メッセージは、前記データパケットにて転送さ
れるデータの属性情報を含むことにより、隣接ノードと
の間で、後に転送されるデータの属性、例えばＭＰＥＧ
映像であるとか、音声の符号化方式といったものの伝送
が可能となり、もって、該ノードにおいて、おのおのの
物理ネットワークにおける該データの伝送フォーマット
が異なるような場合（例えば、ＡＴＭ網とＩＥＥＥ１３
９４バスとを相互接続する場合の、ＭＰＥＧｏｖｅｒＡ
ＴＭとＭＰＥＧｏｖｅｒ１３９４のような場合）におい
て、適切な処置（フォーマット変換など）を施すことが
可能となる。
【００３４】（請求項１９および請求項２０） また、
本発明のネットワーク間接続ケーブルは、第１のネット
ワークケーブルと、第１の中継装置と、第３のケーブル
と、第２の中継装置と、第２のネットワークケーブルと
がこの順に接続されて構成されるネットワーク間接続ケ
ーブルであって、前記第３のケーブルは、第１およびま
たは第２のネットワークケーブルよりも長く、前記第１
および第２の中継装置は、請求項５記載の中継装置であ
り、例えば、前記第１および第２のネットワークケーブ
ルは、ＩＥＥＥ１３９４バスケーブルであることによ
り、１３９４バス間のケーブル（第３のケーブル）の長
さを、任意の長さにする事が可能となり、ケーブル長が
４．５ｍと標準により規定されている１３９４バスの相
互接続を、この制約に縛られずに行う事が出来、互いに
遠方に離れた１３９４バス同士の接続が極めて容易にな
る。また、第１の１３９４バスから第２の１３９４バス
までの接続を行うケーブルが一体型となっているため、
ユーザにとって「単なる長大ケーブルの両端を、相互接
続したい１３９４バスにそれぞれつなげば、相互接続が
簡単にできる」、「コネクタのはめ間違いがない」、
「収容が簡単」等のメリットをも生む事が可能である。
また、第３のケーブルの両端に接続された第１および第
２の中継装置により、１３９４バス同士の相互接続環境
において、任意の他方のネットワーク（送信ノードが属
さない物理ネットワーク）に属する受信ノード、あるい
は他方のネットワークに相互接続された任意の物理ネッ
トワークに対して、任意のデータの送信を行うことが可
能となる。
【００３５】（請求項２１） また、前記第１のネット
ワークケーブルと前記第１の中継装置、前記第１の中継
装置と前記第３のケーブル、前記第３のケーブルと前記
第２の中継装置、前記第２の中継装置と前記第２のネッ
トワークケーブルのうちの少なくとも１組は着脱自在で
あることにより、ケーブル長の変更、あるいは両中継ノ
ード装置間に、更に新たな中継ノードを加えて、１３９
４バスの相互接続環境の大規模化を図る事が可能とな
る。
【００３６】（請求項２２） また、前記第１および第
２の中継装置は、第１のネットワークケーブル、第２の
ネットワークケーブルからそれぞれ電力供給を受けるこ
とにより、ＩＥＥＥ１３９４ケーブルに含まれる電力供
給線を通した電源供給を、前記中継ノードは受ける事が
でき、もって該中継ノード装置自体に電源供給を行う必
要がなくなり、単なるケーブル接続に慣れたユーザが、
現在のケーブル接続と同じ感覚で、これを用いる事がで
きるようになる。
【００３７】
【発明の実施の形態】以下、本発明の実施形態について
図面を参照して説明する。
【００３８】（第１の実施形態）図１は、本発明の第１
の実施形態に係る通信ネットワークの構成例を示したも
ので、例えば、ＣＡＴＶ網とそれに接続された家庭宅内
のネットワークから構成されるものである。
【００３９】図１に示すように、本実施形態の通信ネッ
トワークシステムは、ビデオサーバ１０１、番組案内配
信サーバ（以降、案内サーバとも呼ぶ）１０２、局内Ａ
ＴＭバックボーン網１１０、セルスイッチルータ（ＣＳ
Ｒ）１０３、アクセスＡＴＭ網１１１、ＮＩＵ（Ｎｅｔ
ｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｕｎｉｔ）１０４、第
１のＩＥＥＥ１３９４バス１１２、１３９４コネクタ１
０５、第２のＩＥＥＥ１３９４バス１１３、映像端末１
０６からなる。これらの全体の系（あるいは、この系を
構成する装置の内、少なくとも一部の装置群）はインタ
ーネットに加入しているものとする。
【００４０】ビデオサーバ１０１、案内サーバ１０２、
局内ＡＴＭバックボーン網１１０、セルスイッチルータ
１０３までがＣＡＴＶヘッドエンドの設備であり、ＣＡ
ＴＶ局内に位置している。また、ここまではＩＰ（イン
ターネットプロトコル）サブネットＮａに属しているも
のとする。
【００４１】ビデオサーバ１０１は、案内サーバ１０２
からの制御を受け、指定されたアドレスに対して、指定
されたビデオの配信を行う。この指定されるアドレスと
は、ＩＰアドレスであってもよい。
【００４２】案内サーバ１０２は、Ｗｅｂベース、即ち
ＨＴＴＰによる番組案内をインターネットを通して配信
している。リクエストされた番組について、その内容、
属性、配信先などをビデオサーバ１０１に通知し、これ
を制御する機能も有する。また、ユーザの認証や課金な
どを行う機能も備わっているものとする。
【００４３】局内ＡＴＭバックボーン網１１０は、ＣＡ
ＴＶ局内のバックボーンを構成しているＡＴＭ網であ
る。
【００４４】セルスイッチルータ１０３は、例えば特願
平第０７−０５８１９６号で紹介されている装置であ
り、ＩＰ処理部とＡＴＭスイッチを内部に有する。後述
するＦＡＮＰ（Ｆｌｏｗ Ａｔｔｒｉｂｕｔｅ Ｎｏｔ
ｉｆｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いる事に
より、隣接するＦＡＮＰノード（ＦＡＮＰを処理する事
のできるノード）間でプロトコル交換を行い、処理を進
める。具体的には、隣接ＦＡＮＰノード同士で、同セル
スイッチルータを起点（終点）とするデータリンクレイ
ヤコネクション情報（ＡＴＭのＶＰＩ／ＶＣＩ等）を交
換し、内部で両コネクションをＡＴＭスイッチで結合
し、ＡＴＭスイッチングを行う事になる。
【００４５】なお、本発明はこのＦＡＮＰについて、特
願平第０７−０５８１９６号に紹介されているＦＡＮＰ
の機能を強化、修正した物となっている。よって、前記
の文献では、ＦＡＮＰのバージョン番号は「１」となっ
ているが、本実施形態におけるＦＡＮＰのバージョン番
号は、改良版の意味を含めて「２」であるものとして、
以下の記述を行う。
【００４６】アクセスＡＴＭ網１１１は、ＣＡＴＶ局と
家庭とを結ぶものとする。具体的には、この部分はデー
タリンク方式がＡＴＭであればよく、ＦＴＴＨ（Ｆｉｂ
ｅｒＴｏ Ｔｈｅ Ｈｏｍｅ）、ＨＦＣ（Ｈｙｂｒｉｄ
Ｆｉｂｅｒ Ｃｏａｘ）、同軸ケーブル、ＡＤＳＬ
（Ａｓｙｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒ
ｉｂｅｒ Ｌｉｎｅ）等、加入者線の形態は特に問わな
い。
【００４７】ＮＩＵ１０４、２つの１３９４バス１１
２、１１３、１３９４コネクタ１０５、映像端末１０６
は、家庭内に設置される装置あるいはネットワークであ
る。
【００４８】ＮＩＵ１０４は、アクセスＡＴＭ網１１１
の終端機能と、家庭内のネットワークとの相互接続を行
う。後述するように、このノードもＦＡＮＰノードであ
る。
【００４９】２つの１３９４バス１１２、１１３は、Ｉ
ＥＥＥ１３９４なる高速バスで構成された家庭内ネット
ワークである。図１では、第１の１３９４バス１１２に
はＮＩＵ１０４、１３９４コネクタ１０５のみが、第２
の１３９４バス１１３には１３９４コネクタ１０５と映
像端末１０６のみが接続された図となっているが、実際
には他にＰＣ、プリンタ、ＤＶＤ、その他いろいろなデ
ジタルデバイスが接続されていてもかまわない。
【００５０】１３９４コネクタ１０５は、２つ（あるい
はそれ以上）の１３９４バス同士を接続する機能をもつ
装置である。また、本実施形態における１３９４コネク
タ１０５はＦＡＮＰノードでもある。詳細は後述する。
【００５１】映像端末１０６は、ビデオ受信機能、及び
ＩＰ処理機能を有した端末である。
【００５２】ここで、セルスイッチルータ１０３、それ
に家庭内の端末群は１つのＩＰサブネットに属するもの
とする。即ち、各家庭に１つ（あるいはそれ以上）のＩ
Ｐサブネットが与えられているものとする。本実施形態
では、このＩＰサブネットに与えられているサブネット
アドレスをＮｂとする。
【００５３】また、図１のように、ビデオサーバ１０１
のＩＰアドレスはＮａ．１、案内サーバ１０２はＮａ．
２、セルスイッチルータ１０３の局内ＡＴＭバックボー
ン網１１０側のインタフェースのＩＰアドレスはＮａ．
３、アクセスＡＴＭ網１１１側のインタフェースのＩＰ
アドレスはＮｂ．４であるとする。また、ＮＩＵ１０４
のＩＰアドレスはＮｂ．３、１３９４コネクタ１０５は
Ｎｂ．２、映像端末１０６はＮｂ．１であるとする。こ
こで、ＮＩＵ１０４、１３９４コネクタ１０５は、ネッ
トワークインタフェースを複数有しているにもかかわら
ず、ＩＰアドレスを１つのみ有していてもよい。
【００５４】図２に、ＩＰサブネットＮａ側のアドレ
ス、即ち、局内ＡＴＭバックボーン網１１０内のＩＰア
ドレスとデータリンクレイヤアドレス（ＡＴＭアドレ
ス）の対応を記す。ここで、局内ＡＴＭバックボーン網
１１０のＡＴＭアドレスプレフィックスはＡａであると
する。
【００５５】同様にして、図３に、ＩＰサブネットＮｂ
側のアドレスの対応を記す。
【００５６】ここで、アクセスＡＴＭ網１１１のＡＴＭ
アドレスプレフィックスはＡｂ、第１の１３９４バス１
１２のバスＩＤはＢｂ、第２の１３９４バス１１３のバ
スＩＤはＢａである。
【００５７】各１３９４バスにつながる端末には、２つ
の１３９４アドレスが存在する。１つは、バスリセット
の前後で値が変わらないＥＵＩ６４と呼ばれるアドレ
ス、もうひとつは、バスリセットの前後で値が変わる可
能性の有るノードＩＤである。ここで、ノードＩＤと
は、（バスＩＤ、物理ＩＤ）の表現形式にて表現され
る。
【００５８】次に、図１の全体の系のビデオ伝送におけ
る動作を、図４に示すフローチャートを参照して説明す
る。
【００５９】まず、映像端末１０６は、案内サーバ１０
２から送られて来る番組案内を受信する（ステップＳ４
０１）。
【００６０】この番組案内は、例えば、ＨＴＭＬ（Ｈｙ
ｐｅｒ Ｔｅｘｔ ＭａｒｋｕｐＬａｎｇｕａｇｅ）で
作成されており、伝送プロトコルはＨＴＴＰ（Ｈｙｐｅ
ｒＴｅｘｔ ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を
用いる。すなわち、映像端末１０６はＷｅｂ端末（ブラ
ウザ）となっており、番組案内自身はＩＰ（インターネ
ットプロトコル）を通して送られて来る。
【００６１】まず、一般のＩＰパケットが伝送されてく
る仕組みについて、全体の系のそれぞれについて説明す
る。ここで、一般のＩＰパケットとは、ユーザや装置が
特に指定したフロー（一連の互いに意味のあるＩＰパケ
ットの集合。例えば特定のビデオストリーム等）ではな
い、ベストエフォート伝送を行うＩＰパケットのことで
ある。
【００６２】図５に示すように、案内サーバ１０２とセ
ルスイッチルータ１０３との間は、ＩＰパケット伝送の
ためのＶＣ（仮想コネクション）５０１があらかじめ張
られている。また、同様のＶＣ５０３、５０２がそれぞ
れ案内サーバ１０２とビデオサーバ１０１間、ビデオサ
ーバ１０１とセルスイッチルータ１０３間にも張られて
いる。これらのＶＣは、特に（ＦＡＮＰにより）指定の
ない場合は、このＶＣを通してＩＰパケットを転送する
ためのデフォルトで張られているＶＣのことである。こ
のＶＣを以降は「デフォルトＶＣ」と呼ぶ。
【００６３】デフォルトＶＣは、局内ＡＴＭバックボー
ン網１１０内のＡＴＭ−ＡＲＰ（ＡＴＭ−Ａｄｄｒｅｓ
ｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）等によ
り確立されたものであってもよい。これについて以下に
説明する。
【００６４】案内サーバ１０２は、映像端末１０６に向
けてのＩＰパケット（番組案内パケット）を送出するの
に際し、局内ＡＴＭバックボーン網１１０内でＡＴＭ−
ＡＲＰをかける。ＡＴＭ−ＡＲＰサーバは図中には図示
していない。
【００６５】映像端末１０６のＩＰアドレスをＮｂ．１
とする。映像端末１０６は、ＣＡＴＶ局内のＩＰサブネ
ットＮａではなく、サブネットＮｂに属しているため
（図１参照）、この解決アドレス（ＡＴＭアドレス）は
サブネットＮｂに向かうルータのアドレス、すなわち、
セルスイッチルータ１０３のアドレス（ＡＴＭアドレ
ス）となる。
【００６６】案内サーバ１０２は、解決ＡＴＭアドレス
に向けてのＡＴＭコネクションが既に張られている（Ｖ
Ｃ５０１）ことを検出すると、該ＩＰパケットを該ＶＣ
５０１を介して送出する。
【００６７】セルスイッチルータ１０３は、このＩＰパ
ケットをデフォルトＶＣ５０１を介して受信する。
【００６８】図６は、セルスイッチルータ１０３の内部
構成例を示したものである。図６に示すように、セルス
イッチルータ１０３は、ＩＰ／ＦＡＮＰ処理部およびス
イッチ制御部６０１、ＡＴＭスイッチ部６０２からな
る。
【００６９】ＩＰ／ＦＡＮＰ処理部およびスイッチ制御
部６０１は、受信したＩＰパケットやＦＡＮＰパケット
を処理する機能と、ＦＡＮＰ処理結果にしたがって、Ａ
ＴＭスイッチ部６０２の設定を制御する機能を有する。
ちなみに、接続されるＡＴＭネットワークからのＶＣの
うち後述するようにデフォルトＶＣとよばれる、ＩＰパ
ケット転送のための初期から張られているＶＣ５０１、
５０２については、そのＶＣの終端点は、常に内部のＩ
Ｐ／ＦＡＮＰ処理部およびスイッチ制御部６０１とな
る。
【００７０】ＡＴＭスイッチ部６０２は、ＡＴＭスイッ
チから構成される。ＡＴＭスイッチの出力ポートのう
ち、少なくとも１つはＩＰ／ＦＡＮＰ処理部およびスイ
ッチ制御部６０１になっている。
【００７１】さて、デフォルトＶＣを通ってきたＩＰパ
ケットについては、必ずその両端のノードのＩＰ処理部
（ＩＰ／ＦＡＮＰ処理部およびスイッチ制御部６０１）
にパケットがフォワードされる様に設定されている。
【００７２】セルスイッチルータ１０３のＩＰ処理部
（ＩＰ／ＦＡＮＰ処理部およびスイッチ制御部６０１）
は、受信したＩＰパケットが映像端末１０６行きである
ことを確認（該ＩＰパケットの宛先ＩＰアドレスが映像
端末１０６のＩＰアドレスＮｂ．１である事を確認）す
ると、内部のＩＰルーチングテーブルに従ってルーチン
グを行い、出力物理ポートを決定する。
【００７３】セルスイッチルータ１０３は、出力物理ポ
ートにおいて、どのＶＣに入れて該ＩＰパケットを送出
するかを決定すべく、ＡＴＭ−ＡＲＰをアクセスＡＴＭ
網１１１に対して行う。なお、図１には、ここでのＡＴ
Ｍ−ＡＲＰサーバの図示も省略されている。
【００７４】ＡＴＭ−ＡＲＰは、アクセスＡＴＭ網１１
１全体に対して行われ、最終的にはＮＩＵ１０４のＡＴ
Ｍアドレスが解決される。
【００７５】ここで、解決されるＡＴＭアドレスはＮＩ
Ｕ１０４のものであり、映像端末１０６のものではな
い。即ち、このアドレス解決はプロキシ解決、即ち代理
解決となっている。これは、ＡＴＭ網と（例えばイーサ
ネットや、本実施形態の１３９４網１１２、１１３の様
な）他の網とが相互接続されているような場合、ＡＴＭ
網内部からのアドレス解決要求に対して解決されるアド
レスはＡＴＭアドレスであるべきであるが、解決対象の
端末がＡＴＭ網上に存在するとは限らないので、この場
合はＮＩＵ１０４のＡＴＭアドレスが解決される。
【００７６】以下に示すように、本実施形態におけるシ
ステムにおいては、後述の様に、セルスイッチルータ１
０３、ＮＩＵ１０４、１３９４コネクタ１０５がＦＡＮ
Ｐノードであり、ＡＲＰはそれぞれこのノードで一時終
端され、代理応答される。即ち時系列的には、図７に示
すように、順次アドレス解決が行われていく。
【００７７】（ステップＳ７０１） セルスイッチルー
タ１０３からアクセスＡＴＭ網１１１へ、映像端末１０
６のアドレスのアドレス解決要求。
【００７８】（ステップＳ７０２） これを受信したＮ
ＩＵ１０４から、第１の１３９４バス１１２へ、映像端
末１０６のアドレスのアドレス解決要求。
【００７９】（ステップＳ７０３） これを受信した１
３９４コネクタ１０５から第２の１３９４バス１１３
へ、映像端末１０６のアドレスのアドレス解決要求。
【００８０】（ステップＳ７０４） 映像端末１０６か
ら１３９４コネクタ１０５へのアドレス解決（解決アド
レスは映像端末１０６の１３９４アドレス）。
【００８１】（ステップＳ７０５） １３９４コネクタ
１０５からＮＩＵ１０４へのアドレス解決（解決アドレ
スは１３９４コネクタ１０５の１３９４アドレス）。
【００８２】（ステップＳ７０６） ＮＩＵ１０４か
ら、セルスイッチルータ１０３へのアドレス解決（解決
アドレスはＮＩＵ１０４のＡＴＭアドレス）。
【００８３】以上の手続きが終了すると、ＩＰパケット
を送出するシーケンスにはいる（ステップＳ７０７、ス
テップＳ７０８、ステップＳ７０９）。
【００８４】図７に示した手順では、端から順にアドレ
ス解決を行っていき、すべてのデータリンクレイヤアド
レスが解決した時点でＩＰパケットの送信を開始する方
式であるが、図８に示すように、各ホップ毎にアドレス
解決を行っていき、解決すると、順次該ＩＰパケットを
フォワーディングしていく方式も考えられる。
【００８５】さて、セルスイッチルータ１０３は、解決
されたＡＴＭアドレス（ＮＩＵ１０４のＡＴＭアドレ
ス）から、このＡＴＭアドレスとの間に確立されたＡＴ
Ｍ−ＶＣ（デフォルトＶＣ９０１）が存在するかどうか
を確認する。もし、確立されていない場合は確立する
（図９参照）。
【００８６】その後、セルスイッチルータ１０３は、Ｖ
Ｃ９０１を通してＩＰパケットを送信する。このＩＰパ
ケットはＮＩＵ１０４に到達する。
【００８７】図１０にＮＩＵ１０４の内部構成例を示
す。図１０に示すように、ＮＩＵ１０４は、ＡＴＭ物理
レイヤ処理部１００１、ＡＴＭ／ＡＡＬ処理部１００
２、第１のＭＵＸ／ＤＥＭＵＸ１００３、ＩＰ／ＦＡＮ
Ｐ処理部１００４、第２のＭＵＸ／ＤＥＭＵＸ１００
５、１３９４リンク処理部１００６、１３９４物理処理
部１００７、ＡＴＭ／１３９４乗せ換え部１００８、Ａ
ＴＭ制御部１００９、１３９４制御部１０１０から構成
される。
【００８８】ＡＴＭ物理レイヤ処理部１００１は、外部
からのＡＴＭ伝送路を終端し、ＡＴＭの物理レイヤ処理
を行って、ＡＴＭセルを隣のＡＴＭ／ＡＡＬ処理部１０
０２にフォワードする機能と、ＡＴＭ／ＡＡＬ処理部１
００２からのＡＴＭセル流に対してＡＴＭ物理レイヤ処
理を施し、外部に送出する機能を有する。
【００８９】ＡＴＭ／ＡＡＬ処理部１００２は、ＡＴＭ
物理レイヤ処理部１００１から受信したＡＴＭセル流に
ついてＡＴＭレイヤ処理、およびＡＡＬ処理を施して、
必要に応じて、ＡＡＬ−ＳＤＵ（ＡＡＬ−Ｓｅｒｖｉｃ
ｅ Ｄａｔａ Ｕｎｉｔ：ＩＰパケット、ＭＰＥＧフレ
ーム等）を取り出し、後述する機構にしたがって、これ
をＶＣＩの値などを参考にして、第１のＭＵＸ／ＤＥＭ
ＵＸ１００３を介して、ＩＰ／ＦＡＮＰ処理部１００
４、ＡＴＭ／１３９４乗せ換え部１００８、又はＡＴＭ
制御部１００９（シグナリングパケット等）に対して送
出する。また、第１のＭＵＸ／ＤＥＭＵＸ１００３から
のデータ（ＩＰパケット、ＭＰＥＧフレーム等）につい
て、これにＡＡＬ（ＡＴＭ Ａｄａｐｔａｔｉｏｎ Ｌ
ａｙｅｒ）処理を加えてＡＴＭセル化し、更にＡＴＭレ
イヤ処理を施して隣のＡＴＭ物理レイヤ処理部１００１
に送出する機能を有する。
【００９０】第１のＭＵＸ／ＤＥＭＵＸ１００３は、Ａ
ＴＭ／ＡＡＬ処理部１００３からのデータを、ＶＣＩの
値などに基づいてＩＰ／ＦＡＮＰ処理部１００４とＡＴ
Ｍ／１３９４乗せ換え部１００８、およびＡＴＭ制御部
１００９に分岐させる機能と、ＩＰ／ＦＡＮＰ処理部１
００４とＡＴＭ／１３９４乗せ換え部１００８、それに
ＡＴＭ制御部１００９からのデータをＡＴＭ／ＡＡＬ処
理部１００２に集線させる機能とを有する。
【００９１】ＩＰ／ＦＡＮＰ処理部１００４は、ＡＴＭ
側、１３９４側それぞれからのＩＰパケットや、ＦＡＮ
Ｐパケットを終端し、ＩＰ処理、およびＦＡＮＰ処理を
施す機能を有する。よって、ＡＴＭ側、および１３９４
側からのデフォルトＶＣ（後述するように１３９４側に
ついてはアシンクロナスチャネル）からのＩＰパケット
（ＦＡＮＰパケットなども含む）は、この処理部１００
４にフォワードされてくることになる。また、ＩＰアド
レスからデータリンクアドレス（ＡＴＭアドレス、１３
９４アドレス）へのアドレス解決などの一連のＡＲＰ手
順もこの部分の機能であるとする。
【００９２】ＩＰ／ＦＡＮＰ処理部１００４では、ＩＰ
ヘッダの宛先ＩＰアドレスに従って、パケットのルーチ
ング処理（該ＩＰパケットをどの物理ポートに送出する
かを決定する処理）は行うが、一般のルータと違って、
この部分でいわゆるＩＰルーチングプロトコルの処理は
行わない。
【００９３】第２のＭＵＸ／ＤＥＭＵＸ１００５は、Ｉ
Ｐ／ＦＡＮＰ処理部１００４とＡＴＭ／１３９４乗せ換
え部１００８からのデータを集線して、隣の１３９４リ
ンク処理部１００６に送出する機能と、１３９４リンク
処理部１００６からのデータをチャネル番号などを参照
して、ＩＰ／ＦＡＮＰ処理部１００４とＡＴＭ／１３９
４乗せ換え部１００８に分岐送出する機能を有する。
【００９４】１３９４リンク処理部１００６と、１３９
４物理処理部１００７は、それぞれＩＥＥＥ１３９４の
リンクレイヤの処理と物理レイヤの処理を行う。即ち、
第２のＭＵＸ／ＤＥＭＵＸ１００５からのデータを後述
する１３９４制御部１０１０と協調して、１３９４リン
ク処理部１００６が受信し、これを１３９４のフレーム
化等を行い、１３９４リンクに送出する機能と、逆に１
３９４リンクからの１３９４フレーム（同期、非同期両
方を含む）を、１３９４制御部１０１０と協調して１３
９４の各レイヤ処理を行った後に第２のＭＵＸ／ＤＥＭ
ＵＸ１００５に送出する機能を有する。
【００９５】ＡＴＭ／１３９４乗せ換え部１００８は、
ＡＴＭ側からのデータと１３９４側からのデータを、お
互いのフォーマットに合わせた上で、データリンク変換
して、フォワーディングする機能を有している。ここを
通るデータについては、前述のＩＰ／ＦＡＮＰ処理部８
０４を通過することなく、ＡＴＭ側と１３９４側との間
を流通することになる。これにより、ＩＰパケット、Ｍ
ＰＥＧフレーム等、情報の種類によらず、ＩＰ／ＦＡＮ
Ｐ処理部１００４によるＩＰ／ＦＡＮＰレイヤ処理を受
けることなくデータのフォワーディングが、ＡＴＭのＶ
ＰＩ／ＶＣＩや１３９４のチャネル番号等を通して、Ａ
ＴＭ／１３９４乗せ換え部１００８を通して直接できる
こととなり、大幅な処理の簡略化や処理時間の向上を期
待することができる。また、ＩＰ／ＦＡＮＰ処理部１０
０４の処理の軽減を図ることも可能となる。
【００９６】ＡＴＭ制御部１００９は、ＡＴＭ関連部分
の制御や、シグナリング処理等を行うものである。
【００９７】１３９４処理部１０１０は、主にＩＥＥＥ
１３９４のトランザクションレイヤ処理とシリアルバス
管理を行うものである。ＩＰ／ＦＡＮＰ処理部１００４
から／への必要なデータについて、上記処理を行って１
３９４リンク処理部１００７とデータのやり取りを行う
等の機能を有する。
【００９８】さて、以降では図７の手順に従って説明を
行う。
【００９９】ＮＩＵ１０４は、ＡＴＭ側で確立されたデ
フォルトＶＣ（図９の９０１）から入力されたデータの
うち、受信されたＩＰパケットについては、あらかじめ
内部のＩＰ／ＦＡＮＰ処理部１００４にフォワードされ
る設定となっている。
【０１００】当初、ＮＩＵ１０４（実際には、ＮＩＵ１
０４のみでなく、１３９４コネクタ１０５等のＦＡＮＰ
ノードも）は、第１１図のようなルーチングテーブルを
内部に有しており、どのＩＰ端末がどの方向の物理ポー
トに存在するかについての情報を持っている。これは、
ＩＰ端末それぞれについて、ソースルーチングを行う際
のルーチングテーブルを持っているような形（１つ１つ
のＩＰアドレスについて、ルーチングテーブルに登録さ
れている）となっている。また、ラーニングブリッジの
ように、該ノードのＩＰ／ＦＡＮＰ処理部１００４を通
過するＩＰパケットのうち、該ルーチングテーブルに登
録されていないＩＰアドレスが検出された場合には、こ
れを該ルーチングテーブルに次々と登録していくように
してもよい。また、一定時間、ＩＰパケットの通過が確
認されないＩＰアドレスについては、これをルーチング
テーブルから消去するようになっていてもよい。
【０１０１】さて、図７のステップＳ７０１の処理手順
を説明する。図１２に示すように、ＮＩＵ１０４のＩＰ
／ＦＡＮＰ処理部１００４では、受信したパケットがＡ
ＲＰ要求であり（ステップＳ１２０１）、また該ＡＲＰ
要求されたＩＰアドレスが自分のＩＰアドレスではなく
（ステップＳ１２０２）、かつ内部に持っているルーチ
ングテーブルに該ＩＰアドレスが登録されていないこと
確認すると（ステップＳ１２０３）、これを自分の持つ
他の物理ポート、例えば、本実施形態では、図１の第１
の１３９４バス（ネットワーク）１１２の物理ポートに
対してこのＡＲＰ要求をフォワードする（ステップＳ１
２０４）。このとき送出するＡＲＰ要求パケットの送出
元アドレスには自分（ＮＩＵ１０４）の１３９４アドレ
スを書いておくものとする。
【０１０２】図１３に、ＮＩＵ１０４から第１の１３９
４バス１１２に対して送出されるＡＲＰ要求のフレーム
／パケットフォーマットの一例を示す。このように、Ａ
ＲＰ要求は、ＡＲＰパケットが１３９４フレームにカプ
セル化される形で非同期チャネル、すなわち、図９の９
０２に送出される。
【０１０３】このＡＲＰ要求は、第１の１３９４バス１
１２へブロードキャストされるように送出されるため、
１３９４フレームの宛先ＩＤには「バスＩＤ＝ローカル
バス、物理ＩＤ＝放送」、あるいは「バスＩＤ＝自分の
属しているバスのＩＤ、物理ＩＤ＝放送」の形で送出さ
れる。送出元ＩＤには、自分のノードＩＤを入れてお
く。 なお、１３９４バス同士が１３９４トレードアソ
シエーションで今後標準化が進むとみられる１３９４ブ
リッジを介して相互接続される場合は、１３９４内にお
いては本発明の方法を使う代わりに、宛先ＩＤとして、
全ての１３９４バスに向かって送出する「放送バスＩ
Ｄ」を使用して、ＡＲＰをかける方法も考えられる。こ
の場合は、直接宛先の１３９４アドレスが解決されるの
で、１３９４の内部プロトコル（例えば、ＩＥＣ１８８
３等）で宛先端末まで同期チャネルの予約を行ってもよ
い。
【０１０４】図１３の説明に戻り、１３９４のデータ部
には、ＬＬＣ／ＳＮＡＰ領域に続いて、ＡＲＰパケット
が入る。カプセル化されるＡＲＰパケットについては、
ハードウエア種別として、ＩＥＥＥ１３９４の番号が、
プロトコル種別としてはＩＰ、そして長さ表示と、該パ
ケットがＡＲＰ要求である旨がＡＲＰヘッダに記述され
る。また、データ部には、自分の２つの１３９４アドレ
ス、具体的には、ＥＵＩ６４と呼ばれるバスリセット前
後で不変のＩＤ（ハードウエアベンダが工場出荷時に焼
き込んでおくＩＤ）と、その時点での１３９４アドレス
空間におけるアドレス（ノードＩＤおよびメモリ／レジ
スタ番地）を記述しておいてもよい（例えば、ＮＩＵ１
０４の場合、ＥＵＩ６４がＥ４でノードＩＤが（Ｂｂ、
２）が入る）。
【０１０５】更に、自分（ＮＩＵ１０４）のＩＰアドレ
スも記述しておく。未解決の宛先１３９４アドレスにつ
いては、ダミー値が入り、宛先ＩＰアドレス（解決要求
ＩＰアドレスＮｂ．１）のみが入る。
【０１０６】図１３に示したような１３９４フレーム
が、非同期チャネルを通じて、第１の１３９４バス１１
２に送出される。このフレームは、第１の１３９４バス
１１２に接続する全てのノードが受け取ることになる。
このうち、ＬＬＣ／ＳＮＡＰを理解できない端末や、Ｉ
Ｐ処理機能、ＦＡＮＰ処理機能を持たない端末は、即座
にこのフレームを廃棄する。また、ＩＰ処理機能を持っ
ている端末でも、ルータ機能、あるいはＦＡＮＰ機能を
持っておらず、かつ、自分のＩＰアドレスがＡＲＰの解
決要求ＩＰアドレスでない場合も、これを無視する。
【０１０７】第１の１３９４バス１１２において、該Ｉ
Ｐアドレス（Ｎｂ．１）を持っているＩＰ端末はない。
また、ＦＡＮＰ機能を持っているのは１３９４コネクタ
１０５である。
【０１０８】図１４は、１３９４コネクタ１０５の内部
構成例を示したものである。図１４に示すように、１３
９４コネクタ１０５は、第１の１３９４物理処理部１４
０１、第１の１３９４リンク処理部１４０２、第１のＭ
ＵＸ−ＤＥＭＵＸ１４０３、ＩＰ／ＦＡＮＰ処理部１４
０４、第２のＭＵＸ−ＤＥＭＵＸ１４０５、第２の１３
９４リンク処理部１４０６、第２の１３９４物理処理部
１４０７、１３９４スイッチ部１４０８、第１の１３９
４制御部１４０９、第２の１３９４制御部１４１０から
なる。
【０１０９】第１の１３９４物理処理部１４０１、第１
の１３９４リンク処理部１４０２、第１の１３９４制御
部１４０９は、それぞれ第１の１３９４バス１１２側の
ＩＥＥＥ１３９４の物理レイヤ、リンクレイヤ、トラン
ザクションレイヤ／シリアルバス管理の各機能を果た
し、第１のＭＵＸ−ＤＥＭＵＸ１４０３を通して、１３
９４のチャネル番号や宛先ＩＤの値から、同期チャネル
や非同期チャネルからのデータのフォワーディングをＩ
Ｐ／ＦＡＮＰ処理部１４０４、または１３９４スイッチ
部１４０８と双方向で行う。
【０１１０】第２の１３９４物理処理部１４０７、第２
の１３９４リンク処理部１４０６、第２の１３９４制御
部１４１０についても、説明は同様である。
【０１１１】ＩＰ／ＦＡＮＰ処理部１４０４について
は、図１０のＮＩＵ１０４におけるＩＰ／ＦＡＮＰ処理
部１００４と同様の機能を有する。よって、詳細な説明
は省略する。
【０１１２】１３９４スイッチ部１４０８は、第１のＭ
ＵＸ−ＤＥＭＵＸ１４０３と、第２のＭＵＸ−ＤＥＭＵ
Ｘ１４０５間で、ＩＰ／ＦＡＮＰ処理部１４０４におけ
る処理を伴わずに、直接複数の１３９４ポート間でデー
タのやりとりを行うための装置である。片側の１３９４
バスから、もう片側の１３９４バスに乗り換える場合の
バッファの役割を果たす。また、必要な場合、例えばＭ
ＰＥＧストリームのタイムスタンプの押し直しの様な処
理も行う。その際は、片側の１３９４バスのチャネル番
号の値から、直接属性、宛先物理ポート、変換後のチャ
ネル番号等の対応関係を記した図１９に示すような対応
テーブルを用意する。
【０１１３】図７のステップＳ７０２の処理手順を説明
する。
【０１１４】１３９４コネクタ１０５に到着したＩＰパ
ケットは、ＬＬＣ／ＳＮＡＰの解析を受けた後で、ここ
でも内部のＩＰ／ＦＡＮＰ処理部１４０４にフォワード
される設定となっている。
【０１１５】図１２と同様に、ＩＰ／ＦＡＮＰ処理部１
４０４では、受信したＩＰパケットがＡＲＰ要求であ
り、また該ＡＲＰ要求されたＩＰアドレスが自分のＩＰ
アドレスではなく、かつ内部に持っているルーチングテ
ーブルに該ＩＰアドレスが登録されていないこと確認す
ると（ステップＳ１２０１〜ステップＳ１２０３）、こ
れを自分の持つ他の物理ポート、本実施形態では、第２
の１３９４バス１１３の物理ポートに対してこのＡＲＰ
要求をフォワードする（ステップＳ１２０４）。このと
き送出するＡＲＰ要求パケットの送出元アドレスには自
分（１３９４コネクタ１０５）の第２の１３９４バス１
１３側の１３９４アドレスＥ２／（Ｂａ、２）を書いて
おくものとする。
【０１１６】このＡＲＰ要求も第２の１３９４バス１１
３上を放送される。これを受信した映像端末１０６は、
これが自分あてのＡＲＰ要求であることを認識し、ＡＲ
Ｐ応答を返す（図７のステップＳ７０４）。
【０１１７】その際は、図１５に示すように、ＡＲＰパ
ケット内の送信元アドレスと宛先アドレスとを入れ替
え、自分のＩＰアドレス（Ｎｂ．１）と１３９４アドレ
ス（Ｅ１／Ｂａ、１）を入れた上で、ＡＲＰ応答パケッ
トを生成する。そして、宛先アドレスを（Ｂａ、２）、
すなわち、１３９４コネクタ１０５として、１３９４フ
レームを生成し、これを第２の１３９４バス１１３の非
同期チャネル（図９の９０３）に送出する。
【０１１８】これを受信した１３９４コネクタ１０５
は、内部のルーチングテーブルに、第２の１３９４バス
の側にＩＰ端末Ｎｂ．１が存在することを登録するとと
もに、映像端末１０６のＩＰアドレス（Ｎｂ．１）と、
図１１に示すように、１３９４アドレスとの対応表も内
部のＡＲＰテーブルに登録する（図１２のステップＳ１
２０５〜ステップＳ１２０６）。ここで、ＡＲＰテーブ
ルとルーチングテーブルとは一体のものであっても良
い。図１１は、一体となったものを示してある。
【０１１９】１３９４コネクタ１０５は、映像端末１０
６に対するＡＲＰ要求が第１の１３９４バスの側からＮ
ＩＵ１０４よりきていたのを認識しているため、これへ
のＡＲＰ応答を引き続き返す（図７のステップＳ７０５
および図１２のステップＳ１２０７）。その際は、応答
１３９４アドレスとして、１３９４コネクタ１０５の１
３９４アドレス（Ｅ３／Ｂｂ、１）を答えるものとす
る。つまり、これも代理応答である。
【０１２０】ＮＩＵ１０４も同様にＡＲＰの代理応答
（即ち、解決ＡＴＭアドレスとして、ＮＩＵ１０４自身
のＡＴＭアドレスＡｂ．１を記載した上で）をアクセス
ＡＴＭ網１１１を介してセルスイッチルータ１０３に送
出する（図７のステップＳ７０６および図１２のステッ
プＳ１２０７）。その際は、ＶＣ９０１を用いる。
【０１２１】この時点で、１３９４コネクタ１０５に
は、第２の１３９４バスの側に映像端末１０６のＩＰア
ドレス（Ｎｂ．１）が存在することが、内部のルーチン
グテーブル上に登録され、その１３９４アドレス（映像
端末１０６の１３９４アドレス（Ｅ１／Ｂａ、１））が
内部のＡＲＰテーブルに登録されている。また、ＡＲＰ
要求パケットの処理の際に、第１の１３９４バス１１２
の側にＮＩＵ１０４のＩＰアドレスＮｂ．３と、その１
３９４アドレス（Ｅ４／Ｂｂ、２）も、ルーチングテー
ブルとＡＲＰテーブルにそれぞれ登録される（図３参
照）。
【０１２２】また、ＮＩＵ１０４には、第１の１３９４
バスの側に映像端末１０６のＩＰアドレス（Ｎｂ．１）
が存在することが、内部のルーチングテーブル上に登録
され、その１３９４アドレスとしては、代理応答のた
め、１３９４コネクタ１０５の１３９４アドレス（第１
の１３９４バスの側の１３９４アドレス（Ｅ３／Ｂｂ．
１））が内部のＡＲＰテーブルに登録されている。ま
た、ＡＲＰ要求パケットの処理の際に、アクセスＡＴＭ
網１１１の側にセルスイッチルータ１０３のＩＰアドレ
スＮｂ．４と、そのＡＴＭアドレスも、ルーチングテー
ブルとＡＲＰテーブルにそれぞれ登録される（図３参
照）。
【０１２３】また、セルスイッチルータ１０３には、ア
クセスＡＴＭ網１１１の側に映像端末１０６のＩＰアド
レス（Ｎｂ．１）が存在することが、内部のルーチング
テーブル上に登録され、そのＡＴＭアドレスとしては、
代理応答のため、ＮＩＵ１０４のＡＴＭアドレスＡｂ．
１が内部のＡＲＰテーブルに登録される（図３参照）。
この時点で、セルスイッチルータ１０３は映像端末１
０６宛のＩＰパケットの送出が行えることになる。即
ち、セルスイッチルータ１０３は、ＮＩＵ１０４との間
に確立されたデフォルトＶＣ（この時点で確立されてい
なかったら、確立する）９０１を通して、該ＩＰパケッ
トを送出する。
【０１２４】デフォルトＶＣはＮＩＵ１０４のＩＰ／Ｆ
ＡＮＰ処理部１００４に接続されるように確立される。
【０１２５】このＩＰパケットはＮＩＵ１０４に到達す
るとＩＰ／ＦＡＮＰ処理部１００４に運ばれる。ここ
で、ＩＰ／ＦＡＮＰ処理部１００４は、ルーチングテー
ブルを参照し、宛先ＩＰアドレスであるＮｂ．１が第１
の１３９４バス１１２の側にあることを認識し、内部の
ＡＲＰテーブルを参照してその１３９４アドレス（実際
には１３９４コネクタ１０５の１３９４アドレスＢｂ．
１）を認識して、該ＩＰパケットを、１３９４コネクタ
１０５宛の１３９４フレームにカプセル化し、これを非
同期チャネルを介して第１の１３９４バス１１２に送出
する。
【０１２６】図１６は、１３９４バス上に送出されるＩ
Ｐパケットのフォーマットを示したものである。図１６
に示したように、基本的にはＩＰパケットは１３９４の
非同期チャネルに送出され、１３９４の非同期フレーム
にカプセル化される。
【０１２７】１３９４の非同期チャネルを介して１３９
４コネクタ１０５に飛んできたＩＰパケット、ＦＡＮＰ
パケットなどは、ＬＬＣ／ＳＮＡＰヘッダの参照の上、
ＩＰ／ＦＡＮＰ処理部１４０４に接続されるようにあら
かじめ設定されているため、このＩＰパケットは１３９
４コネクタ１０５に到達するとＩＰ／ＦＡＮＰ処理部１
４０４に運ばれる。ここで、ＩＰ／ＦＡＮＰ処理部１４
０４は、ルーチングテーブルを参照し、宛先ＩＰアドレ
スであるＮｂ．１が第２の１３９４バス１１３の側にあ
ることを認識し、内部のＡＲＰテーブルを参照してその
１３９４アドレス（Ｂａ、１）を認識して、該ＩＰパケ
ットを、映像端末１０６宛の１３９４フレームにカプセ
ル化し、これを非同期チャネルを介して第２の１３９４
バス１１３に送出する。
【０１２８】こうして、該ＩＰパケットは映像端末１０
６に到達する（図７のステップＳ７０７〜ステップＳ７
０９、および図４のステップＳ４０１）。
【０１２９】以降案内サーバ１０２から送出される映像
端末１０６宛のパケットは、ＡＲＰ手順を踏むことな
く、映像端末１０６までルーチングされることが可能で
ある。
【０１３０】映像端末１０６では、これらのＩＰパケッ
トを通じて送られてくる番組案内を映像端末１０６上の
ブラウザを通じて表示する。ユーザは、このブラウザを
通して、見たい番組のリクエスト等を行う。このリクエ
ストも、ＩＰ／ＨＴＴＰを用いて行われる（図４のステ
ップＳ４０２）。もちろん、ユーザが使われている通信
プロトコルが何であるか、等ということを意識する必要
はない。
【０１３１】その後、案内サーバ１０２とユーザ（映像
端末１０６）間で、ユーザ認証、課金手続き等、映像サ
ービスを行うにあたっての種々の制御手続きを行う（図
４のステップＳ４０３）。この制御手続きもＩＰ／ＨＴ
ＴＰを使って行われる。
【０１３２】これらの手続きが終了すると、映像配信の
ための手続きにはいる。まず、案内サーバ１０２からビ
デオサーバ１０１に対して番組送信のための制御信号が
送られる（図４のステップＳ４０４）。この制御信号に
は、どの番組をどれだけの時間、誰に対して送るか等の
映像送信に関わる基本的な情報がやりとりされる。この
制御信号のやりとりは、案内サーバ１０２とビデオサー
バ１０１間のデフォルトＶＣ２０３を介して行われる。
これは、案内サーバのＣＧＩ等を通して行われてもよ
い。また、ＪＡＶＡ等の言語を用いて、手続きが直接ビ
デオサーバ１０１に対して行われる場合もある。
【０１３３】つづいて、ビデオサーバ１０１と映像端末
１０６間で、映像伝送に先立って必要な手続きが交換さ
れる。例えば、符号化方式の確認や、受信可能な帯域の
値の確認等を行う（図４のステップＳ４０５）。これら
のやりとりは、これまで説明してきたのと同様に、ＩＰ
／ＨＴＴＰを通じて行われてもよい。ビデオサーバ１０
１と映像端末１０６間で合意がとれると、ビデオサーバ
から映像端末へ向かって、帯域を保証するデータリンク
コネクションを確立する手順にはいる。
【０１３４】次に、この手順を図１７、図１８を参照し
て説明する。
【０１３５】映像端末１０６（ＩＰアドレスＮｂ．１）
に対して一定の帯域（例えば４Ｍｂｐｓ）で映像の送付
を行う場合を考える。ビデオサーバ１０１は、ＩＰアド
レスＮｂ．１についてアドレス解決を行い（ステップＳ
１７０１）、その解決アドレスであるセルスイッチルー
タ１０３との間に４Ｍｂｐｓの帯域を持ったＡＴＭコネ
クションを確立すべく、セルスイッチルータ１０３との
間にＡＴＭ呼設定を行う（ステップＳ１７０２）。
【０１３６】ここで、呼設定の場合に必要な細かなパラ
メータについては、あらかじめ適当な値がビデオサーバ
の側に設定されており、それをそのまま利用するものと
する。
【０１３７】呼設定が完了し、ビデオサーバ１０１とセ
ルスイッチルータ１０３間に４ＭｂｐｓのＡＴＭコネク
ション２１０１が確立すると、ビデオサーバ１０１は、
このＡＴＭコネクション２１０１を使って、ＦＡＮＰで
決められた処理を開始する。
【０１３８】このように、ＦＡＮＰノード間で、ある特
有のフローの伝送のために確立したデータリンクコネク
ションを専用データリンクコネクションと呼ぶ。
【０１３９】ＦＡＮＰは、データリンクのあるコネクシ
ョン（のＩＤ）と、そのコネクションを通して送付する
情報との関係を隣接ノードに通知するためのプロトコル
であり、以下にその手順を具体的に説明する。なお、本
発明では、従来のＦＡＮＰの機能に改良を加えたもの
で、以下、これを拡張されたＦＡＮＰの機能と呼ぶこと
がある。
【０１４０】以下、必要な場合（改良を加えた箇所）に
ついては、詳細な説明を付加する。
【０１４１】図１７のステップＳ１７０３では、まず最
初に、ビデオサーバ１０１は、図２１に示すように、確
立したＡＴＭコネクション２１０１を通して、ＶＣＩＤ
交換メッセージのやりとりを行う。このメッセージのや
りとりを通じて、両端の装置はＶＣＩＤ（後述）の値の
意味付けを共有する。これをＦＡＮＰのＶＣＩＤの交換
メッセージのやり取りを通じて行う（図２２参照）。
【０１４２】図２０に、ここで交換されるメッセージの
フォーマットの一例を示す。このメッセージのフォーマ
ットは、ＡＴＭ−ＬＡＮにおけるＡＲＰパケットのフォ
ーマットとほぼ同様である。ハードウエアタイプにはＡ
ＴＭ、プロトコル種別としてＩＰ、送信者ＩＰアドレス
としてはビデオサーバ１０１のＩＰアドレス、ターゲッ
トＩＰアドレスとしては映像端末１０６のＩＰアドレ
ス、ＶＣＩＤ（仮想コネクションＩＤ）としては、ビデ
オサーバ１０１のグローバルユニークなアドレス（ＡＴ
ＭボードのＭＡＣアドレス）と、ビデオサーバ１０１が
適当に定めたシーケンス番号が付与される。
【０１４３】ＶＣＩＤは、ＡＴＭではＶＣの両端でＶＰ
Ｉ／ＶＣＩが一般に異なるため、ＶＣの両端のノードで
共通に認識できる識別子である。
【０１４４】また、ＶＣＩＤ交換メッセージについて
は、ＡＣＫ、ＮＡＣＫも用意されており、これはオペレ
ーションコードによって区別する。ＡＣＫ／ＮＡＣＫに
ついては、図２２に示すように、デフォルトＶＣ５０２
を通じて配送される。ここで、ＡＣＫが返れば両端の装
置間でＶＣＩＤの値に合意が成立したことを意味する。
ＮＡＣＫが返れば、合意にいたらなかったことを意味す
る。
【０１４５】ＦＡＮＰノードがルータである場合は、Ａ
ＣＫのメッセージは単にオペレーションコードの値が変
更されるのみで返送される。ＦＡＮＰノードがルータで
ない場合についての説明は後述する。
【０１４６】ＶＣＩＤについて合意がとれると、ビデオ
サーバ１０１は、次にフロー交換メッセージのやりとり
を図２２に示すように開始する。
【０１４７】本発明では、このフロー交換メッセージを
通して、次段のノードに対して専用データリンクコネク
ションの確保を申請する。即ち、このフロー交換メッセ
ージに宛先ＩＰアドレス、確保してもらいたい帯域、通
信属性等の情報を付与して次段のＦＡＮＰノードに送付
し、こうして次段のＦＡＮＰノードに対象とする端末へ
のエンドエンドのコネクションの設定を申請する。
【０１４８】ＦＡＮＰノードは、必要な隣接ノード間で
次々に要求された条件を満たすデータリンクコネクショ
ン（専用データリンクコネクション）を確保し、その専
用データリンクコネクションと、前段から通知された専
用データリンクコネクションを互いに関連付ける。この
関連付けは、ＶＣＩテーブル上に行われる。この関連付
けが行われた後は、ＶＰＩ／ＶＣＩの値の参照のみで、
その予約帯域、属性（中を流れるデータがＭＰＥＧ映像
である、等）、出力ポート、出力ヘッダ（ＶＰＩ／ＶＣ
Ｉ）等の値がインプリシットに分かることになる。
【０１４９】これを宛先端末（本実施例では映像端末１
０６）まで次々と行い、最終的にエンド＝エンドのコネ
クションを確立する。
【０１５０】図２３にフロー交換メッセージのフォーマ
ットの一例を示す。このフロー交換メッセージのオペレ
ーションコードの部分で、フロー交換メッセージのタイ
プを示す。
【０１５１】フロー交換メッセージには、オファーメッ
セージ（オペレーションコード＝１）、リダイレクトメ
ッセージ（オペレーションコード＝２）、エラーメッセ
ージ（オペレーションコード＝３）、リリースメッセー
ジ（オペレーションコード＝４）、リリースＡＣＫメッ
セージ（オペレーションコード＝５）、ペンディングメ
ッセージ（オペレーションコード＝６）がある。詳細
は、特願平第０７−０５８１９６号に記載されている。
【０１５２】本実施形態では、ＶＣＩＤタイプには
「１」が固定的にはいる。ＶＣＩＤタイプ＝１の時は、
ＶＣＩＤには、ＥＳＩ（エンドシステムＩＤ、通常はエ
ンドシステムのＭＡＣアドレス）とシーケンス番号がは
いる。
【０１５３】このＶＣＩＤは、「このＶＣ（同期チャネ
ル）は、両端のＦＡＮＰノードでＶＣＩＤの値で呼びま
しょう」という合意した値という意味がある（なお、Ｖ
ＣＩＤの表現方式に異なる方式が登場した場合、他の値
が割り当てられる）。
【０１５４】フローＩＤタイプは、フローＩＤの表現方
式を指定する。ここで、フローとは、ある特定の意味を
持った情報（特定の送信元から特定の宛先に向けて送信
される特定の互いに意味のある情報の集まり。例えば、
映像情報を納めた一連のパケット群等）のことである。
フローＩＤは、あるフローを一意に識別するためのＩＤ
である。フローＩＤについての詳細は後述する。
【０１５５】他のパラメータはオプションであり、ＴＬ
Ｖ（タイプ、長さ、変数）ベースの記述がなされる。本
実施形態では、通信品質情報と、エンド・エンドＡＣＫ
（ｅ−ＡＣＫ）、通信属性が入る。
【０１５６】通信品質情報は、確立するコネクションに
要求する通信品質の値が入る。この値としては、例えば
ＩＥＴＦのｉｎｔ−ｓｅｒｖのＴスペックの値などが入
ってもよい。本実施形態では、必要な帯域の値である４
Ｍｂｐｓを意味する値が入れば良い。
【０１５７】ｅ−ＡＣＫフラグは、最終地点から送信地
点までのＡＣＫ信号の送信を要請するためのフラグであ
る。このエンド＝エンドのＡＣＫ信号は、送信装置（本
実施形態の場合、ビデオサーバ１０１）が、最終地点
（本実施形態の場合、映像端末１０６）までの間でコネ
クション確立に成功したかどうかを知るための目安とな
る。
【０１５８】ビデオサーバ１０１は、図２２に示すよう
に、フロー交換メッセージのうち、オファーメッセージ
を隣接ＦＡＮＰノードであるセルスイッチルータ１０３
に送付する。このメッセージの送付は、ビデオサーバ１
０１からセルスイッチルータ１０３間のデフォルトＶＣ
５０２を通して運ばれる。
【０１５９】このメッセージには、図２４に示すよう
に、オファーメッセージである旨のオペレーションコー
ド、ＶＣＩＤ、フローＩＤ、通信属性、通信品質（帯域
情報）、ｅ−ＡＣＫフラグが含まれる。後者の３つにつ
いては、ＴＬＶ形式にて表現されるオプションである。
【０１６０】ＶＣＩＤには、ビデオサーバ１０１のＭＡ
Ｃアドレスとビデオサーバ１０１が付与するシーケンス
番号が入る。
【０１６１】フローＩＤについては後述するが、基本的
に宛先ＩＰアドレスの値などが入る。
【０１６２】通信属性には、送付するデータがＭＰＥＧ
ストリームである旨が入る。
【０１６３】帯域情報には、該映像ストリームの帯域
（本実施例の場合４Ｍｂｐｓ）、ｅ−ＡＣＫフラグは、
エンド＝エンドのＡＣＫをビデオサーバ１０１が要求す
るため、オンとなっている。
【０１６４】これを受信した隣接ＦＡＮＰノードである
セルスイッチルータ１０３は、該パケットをＩＰ／ＦＡ
ＮＰ処理部６０１で処理する。
【０１６５】ｅ−ＡＣＫフラグを見て、送信側がエンド
＝エンドのコネクションの確保を要求していることが理
解できる。そこで、エンド＝エンドのコネクションの確
立を図るため、ＦＡＮＰメッセージの宛先ＩＰアドレス
（映像端末１０６）方向へのフォワードと、送信側（ビ
デオサーバ１０１）へ「コネクションの確立まで（ある
いは処理負荷が下がるまで）少し待ってほしい」旨を通
知するためのペンディングメッセージを定義する（図２
５参照）。
【０１６６】ペンディングメッセージには、対応するオ
ファーメッセージが有していたＶＣＩＤとフローＩＤが
付与されて転送される。
【０１６７】ペンディングメッセージを受信したビデオ
サーバ１０１は、先に送出したオファーメッセージに対
する返答をしばらくの間待つことになる。
【０１６８】また、セルスイッチルータ１０３は、この
ＦＡＮＰメッセージを映像端末１０６の方向にフォワー
ドして、エンド＝エンドのデータリンクコネクションを
確立し、オファーメッセージを映像端末１０６の方向に
向かって送出しようとする。
【０１６９】このとき、映像端末１０６の解決アドレス
はＮＩＵ１０４のＡＴＭアドレスであるため、ＮＩＵ１
０４との間に該オファーメッセージに記入された帯域
（４Ｍｂｐｓ）でＡＴＭコネクションを確立する（図１
７のステップＳ１７０４）。すなわち、図２１に示すよ
うに、デフォルトＶＣ９０１に加えて、映像伝送用のＡ
ＴＭコネクション２１０２が確立される。
【０１７０】このＡＴＭコネクション２１０２が確立す
ると、ビデオサーバ１０１の場合と同様にＡＴＭコネク
ション２１０２を通して、セルスイッチルータ１０３
は、ＶＣＩＤ交換メッセージを送出する（図１７のステ
ップＳ１７０５）。なお、このＡＴＭコネクション２１
０２を介して送られたデータは、ＮＩＵ１０４のＩＰ／
ＦＡＮＰ処理部１００４に送られるような設定にしてお
く。
【０１７１】これを受信したＮＩＵ１０４は、ＦＡＮＰ
メッセージの宛先ＩＰアドレスが自分ではなく、映像端
末１０６（ＩＰアドレス＝Ｎｂ．１）に向けられている
ことを、このＶＣＩＤ交換メッセージから知る。もし、
今後送付されてくるＦＡＮＰメッセージ（オファーメッ
セージなど）が、映像端末１０６のＩＰアドレス（Ｎ
ｂ．１）に宛てて出されるとすると、ＮＩＵ１０４のＩ
Ｐ／ＦＡＮＰ処理部１００４においては、ＩＰパケット
のプロトコル種別や、ポート番号まで確認しなければ、
それがＦＡＮＰパケットであることが確認できず、よっ
てＦＡＮＰ処理が行えない、あるいはＦＡＮＰ処理を行
おうとすると、ＩＰ／ＦＡＮＰ処理部１００４宛のパケ
ット全てについてプロトコル種別やポート番号の確認を
しなければいけないことになる。
【０１７２】これを避けるために、隣接ＦＡＮＰノード
であるセルスイッチルータ１０３に対して、隣接ＦＡＮ
Ｐノードは映像端末１０６ではなくて、ＮＩＵ１０４で
あることを通知する。そこで、ＶＣＩＤ交換メッセージ
中のターゲットＩＰアドレスの所に、自分のＩＰアドレ
ス（Ｎｂ．３）を入れて、プロポーズメッセージのＡＣ
Ｋを送り返す（図２０参照）。
【０１７３】このようにすることで、セルスイッチルー
タ１０３は、映像端末１０６に向かうルーチング経路
で、次段のＦＡＮＰノードは映像端末１０６ではなく、
ＮＩＵ１０４（ＩＰアドレス＝Ｎｂ．３）であることを
知ることができるようになり、該ＶＣＩＤの値について
の、後のＦＡＮＰメッセージ（つまり、映像端末１０６
に向けてのＦＡＮＰメッセージ）は、ＮＩＵ１０４に対
して送れば良いことを認識できる。
【０１７４】この後、フロー交換メッセージのオファー
メッセージをセルスイッチルータ１０３はＮＩＵ１０４
に送る。よって、ＡＲＰテーブルの検索より、このオフ
ァーメッセージは、デフォルトＶＣ９０１を通して送ら
れることになる。このオファーメッセージの宛先ＩＰア
ドレスはＮＩＵ１０４のＩＰアドレスＮｂ．３である。
【０１７５】ＮＩＵ１０４は、フローＩＤの部分を見る
ことによって、最終のターゲットＩＰアドレス（映像端
末１０６のＩＰアドレス）を知ることが可能である（フ
ローＩＤについては後述）。その他、通信属性、通信品
質、ｅ−ＡＣＫフラグなどがそのままフォワードされ
る。
【０１７６】これにより、映像端末１０６への４Ｍｂｐ
ｓのコネクション設定が必要であると認識したＮＩＵ１
０４は、内部のルーチングテーブルを参照して、映像端
末１０６が第１の１３９４バス１１２の方向にあること
を認識し、第１の１３９４バス上に４Ｍｂｐｓのアイソ
クロナス（同期）チャネルの確立を行う。
【０１７７】これは、ＮＩＵ１０４がアイソクロナスリ
ソースマネージャのレジスタを適当に設定し、帯域の確
保と、チャネル番号の確保を順次行うことによって、こ
れを行うこととなる（図１７のステップＳ１７０６）。
【０１７８】次に、ＮＩＵ１０４は、ＶＣＩＤ交換メッ
セージの送付を行うが（図１７のステップＳ１７０
７）、これにはいくつかの方法がある。
【０１７９】第１の方法は、１３９４の独自プロトコル
で１３９４コネクタ１０５に対して、先に獲得した同期
チャネルの番号を通知して、これをＩＰ／ＦＡＮＰ処理
部１４０４に接続するようにあらかじめ設定しておく方
法である。あるいは、確立した同期チャネルは、デフォ
ルトでＩＰ／ＦＡＮＰ処理部１４０４につながるように
なっていてもよい。また、ＬＬＣ／ＳＮＡＰヘッダを参
照して、これでＩＰ／ＦＡＮＰのパケットであることが
認識され、その後ＩＰ／ＦＡＮＰ処理部１４０４に転送
されるようになっていてもよい。
【０１８０】ＦＡＮＰノードは、ＩＰ／ＦＡＮＰ処理部
１４０４では、入力パケットがＩＰパケットか、ＦＡＮ
Ｐパケットかの区別を行い、ＦＡＮＰパケットならば、
ＦＡＮＰ処理を行うようになっていてもよい。
【０１８１】つづいて、図２６に示すようなＶＣＩＤ交
換メッセージを該同期チャネルに送出する。このＶＣＩ
Ｄ交換メッセージを受信した１３９４コネクタ１０５の
ＩＰ／ＦＡＮＰ処理部１４０４は、そのＡＣＫメッセー
ジに自分のＩＰアドレス（Ｎｂ．２）を入れて非同期チ
ャネルを通してＮＩＵ１０４に送り返す。
【０１８２】図１８に示すシーケンスは、第１の方法に
従って、図１７に示したシーケンスをより詳細に示した
ものである。
【０１８３】第２の方法は、ＶＣＩＤ交換メッセージを
非同期チャネルを使って、１３９４コネクタ１０５に向
かって送出する方法である。映像端末１０６の解決アド
レスは１３９４コネクタ１０５の１３９４アドレスとな
っている。このＶＣＩＤ交換メッセージが１３９４コネ
クタ１０５のＩＰ／ＦＡＮＰ処理部１４０４に到達する
様にしておく。その一つの方法として、ＶＣＩＤ交換メ
ッセージは自動的にＩＰ／ＦＡＮＰ処理部１４０４に到
達するようにあらかじめ設定しておく方法がある。２つ
目の方法は、ＮＩＵ１０４が、１３９４コネクタ１０５
の１３９４アドレスからＲＡＲＰ等を行い、１３９４コ
ネクタ１０５のＩＰアドレスＮｂ．２をあらかじめ調
べ、このＩＰアドレスＮｂ．２に向かってＶＣＩＤ交換
メッセージを送付する方法である。
【０１８４】第３の方法は、ＬＬＣ／ＳＮＡＰで該メッ
セージがＩＰ／ＦＡＮＰ処理部１４０４に運ばれるよう
な設定になっている場合である。これを受け取った１３
９４コネクタ１０５は、ＮＩＵ１０４の場合と同様に、
自分のＩＰアドレスをＶＣＩＤ交換メッセージのＡＣＫ
に加えてＮＩＵ１０４に送り返す。こうしてＮＩＵ１０
４も、映像端末１０６へつながる次段のＦＡＮＰノード
は１３９４コネクタ１０５（ＩＰアドレス＝Ｎｂ．２）
であることを認識でき、以降のＦＡＮＰパケット（フロ
ー交換メッセージ）を直接映像端末１０６に送るのでは
なく、１３９４コネクタ１０５に対して送ることができ
るようになる。
【０１８５】その後の１３９４コネクタ１０５での動作
は、先のＮＩＵ１０４での動作に準ずる。すなわち、フ
ロー交換メッセージを受信して、４Ｍｂｐｓの帯域の確
保を映像端末１０６との間に確立する必要を認識する。
前段のＦＡＮＰノードであるＮＩＵ１０４に対してはペ
ンディングメッセージを送出し、映像端末１０６に対し
ては、第２の１３９４バス１１３上に４Ｍｂｐｓの同期
チャネルとそのチャネル番号を確保し（図１７のステッ
プＳ１７０８）、先に記述したのと同様の方法で、映像
端末１０６に向かってＶＣＩＤ交換メッセージを送出す
る（図１７のステップＳ１７０９）。
【０１８６】映像端末１０６は、該ＶＣＩＤ交換メッセ
ージ（プロポーズメッセージ）については、その受け入
れが可能な場合、ＡＣＫ（プロポーズＡＣＫ）を送り返
す。そして、非同期チャネルを介してＦＡＮＰのフロー
交換メッセージを受信し、これが自分あてのメッセージ
であることを認識する。通信属性のフィールドより、中
のデータがＭＰＥＧストリームであることを認識しても
よいが、これには他の方法も考えられる。一例として、
映像端末１０６は、フローＩＤの値から、これからこの
チャンネルを通ってやってくるデータの属性を知ること
ができるようになっていてもよい。
【０１８７】例えば、ポート番号の何番から何番まで
は、ＭＰＥＧ２のトランスポートストリームである、等
の情報をあらかじめインプリシットに入れておくことに
より、これを行うことが可能である。また、ｅ−ＡＣＫ
フラグが立っていることから、送信端末（即ちビデオサ
ーバ１０１）に対して、ＦＡＮＰメッセージを受け入れ
たとのエンド＝エンドのＡＣＫメッセージを送信する必
要があることも知る。
【０１８８】受け入れが可能な場合は、フロー交換メッ
セージのやりとりとして、図２７に示すようなリダイレ
クトメッセージを前段の１３９４コネクタ１０５に対し
て送り返す。
【０１８９】リダイレクトメッセージは、第２の１３９
４バス１１３の非同期チャネルを使って、１３９４コネ
クタ１０５宛に送られる。
【０１９０】図２７に示すように、リダイレクトメッセ
ージには、ＶＣＩＤとフローＩＤの値が入っており、こ
れを受信した１３９４コネクタ１０５は、自分が先に送
ったどのオファーメッセージに対するリダイレクトであ
るのかを認識することができる。
【０１９１】また、エンド＝エンドＡＣＫ信号を、この
リダイレクトメッセージに含め、後述するように、これ
（エンド＝エンドＡＣＫ）を受け取ったＦＡＮＰノード
が上流にリダイレクトメッセージを送信する場合に、や
はりそのリダイレクトメッセージのエンド＝エンドＡＣ
Ｋ信号を立てて送信する、という方式を用いる事も可能
である。
【０１９２】このようにして、最終端末（本実施形態で
は映像端末１０６）から、送信端末（ビデオサーバ１０
１）に対して、エンド＝エンドのＡＣＫを返す事が可能
になる。なお、すべてのリダイレクトメッセージに、こ
のエンド＝エンドＡＣＫを乗せる必要はなく、例えば下
流からこれを受けた場合のみ、これを上流にも送信す
る、といった方式が可能である。
【０１９３】リダイレクトメッセージを受信した１３９
４コネクタ１０５は、先に送出したオファーメッセージ
が受け入れられたと解釈する。この時点で、１３９４コ
ネクタ１０５は、今後、第１の１３９４バス１１２の同
期チャネル２１０３から例えばＭＰＥＧ映像が入力され
てき、更にそれを第２の１３９４バス１１３の同期チャ
ネル２１０４に送出しなければいけない、ということを
認識する。そこで、ＩＰ／ＦＡＮＰ処理部１４０４は、
第１のＭＵＸ−ＤＥＭＵＸ１４０３について、同期チャ
ネル２１０３からのデータは１３９４スイッチ部１４０
８にフォワードするように、また、１３９４スイッチ部
１４０８では、データリンクレイヤ処理のみ（即ち１３
９４バス間での１３９４フレームのスイッチング）でこ
のデータを第２のＭＵＸ−ＤＥＭＵＸ１４０５に送出す
べく必要な設定（内部キューの初期化や、図１９の対応
テーブルの設定など）を行う。
【０１９４】また、第２のＭＵＸ−ＤＥＭＵＸ１４０５
に対し、第２の１３９４バス１１３の同期チャネル２１
０４に送出するように設定する。
【０１９５】さらに、前段のＮＩＵ１０４に対しても、
リダイレクトメッセージを送出する。
【０１９６】この際、下流からのリダイレクトメッセー
ジにｅ−ＡＣＫが立っている場合は、ここにもｅ−ＡＣ
Ｋを立てる。
【０１９７】このようなステップをビデオサーバ１０１
まで繰り返す。なお、ＮＩＵ１０４では、ＡＴＭ／１３
９４乗せ変え部１００８に、ＡＴＭから１３９４へのデ
ータリンクスイッチのみでＡＴＭコネクション２１０２
から第１の１３９４バス１１２の同期チャネル２１０３
とのデータリンクレイヤでの（ＩＰ／ＦＡＮＰ処理部で
の処理を介さない）データフォワーディングが出来るよ
うな設定（ＡＴＭのＶＰＩ／ＶＣＩの値から、直接１３
９４のチャネル番号まで変換できるように、その対応テ
ーブルの設定）がなされる。
【０１９８】また、セルスイッチルータ１０３では、Ａ
ＴＭコネクション２１０１とＡＴＭコネクション２１０
２とを内部のＡＴＭスイッチ６０２にて直接ＡＴＭレイ
ヤ接続（ＶＣＩテーブルの設定）する。この時点で、ビ
デオサーバ１０１から、映像端末１０６へのデータリン
クコネクションは全て確立したことになる。これを図２
８に示す。
【０１９９】さらに、エンド＝エンドＡＣＫの到着によ
り、ターゲットの端末である映像端末１０６が映像の受
信準備が整ったことが示される（図１７のステップＳ１
７１０）。
【０２００】ここで、ビデオサーバ１０１は、先に確立
し、ＦＡＮＰメッセージのやりとりを行ったＶＣである
２１０１に、映像の送出を開始することができる。送出
された映像データは、図２８のコネクションに沿って、
基本的に途中ＩＰレイヤ処理を何等受けることなく、映
像端末１０６まで到達する。なお、伝送されるデータ
は、生のＭＰＥＧデータであっても、ＭＰＥＧデータが
ＩＰパケットでカプセル化されたもの（いわゆるＭＰＥ
ＧｏｖｅｒＩＰ）であっても良い。
【０２０１】前者の場合、ＭＰＥＧデータがＡＴＭ上を
伝送されている間は、ＡＴＭフォーラムで標準化されて
いるＭＰＥＧｏｖｅｒＡＴＭの仕様（ＳＡＡＶｅｒ．１
の仕様）、１３９４上を伝送されている間は、デジタル
ＶＴＲ協議会にて標準化されているＭＰＥＧｏｖｅｒ１
３９４の仕様にしたがって伝送されることになる。ま
た、この場合、ＮＩＵ１０４のＡＴＭ／１３９４乗せ換
え部１００８では、ＭＰＥＧｏｖｅｒＡＴＭとＭＰＥＧ
ｏｖｅｒ１３９４との乗せ換え、フォーマット変換も行
われることになる。この場合は、生のＭＰＥＧ映像のデ
ータ転送のためのエンド・エンドのデータリンクレイヤ
コネクション設定を、ＦＡＮＰを使って行ったことにな
る。この場合、これらの処理のトリガは、データリンク
レイヤヘッダであるＶＰＩ／ＶＣＩの値によりなされ
る。
【０２０２】以上説明したように、上記第１の実施形態
によれば、 （１）ＡＴＭやＩＥＥＥ１３９４等の異種ネットワーク
技術（データリンク技術）が混在するような環境におい
ても、エンド＝エンドにデータリンクレイヤコネクショ
ンを確立して、データ転送が行う事ができるようにな
る。
【０２０３】（２）データリンク接続点において、デー
タの転送を行う場合に、ＩＰ／ＦＡＮＰ処理部による処
理でなく、直接データリンク同士を接続できるように、
相互接続装置を制御できるような自由度があるので、必
要なところには高速なデータ転送を行う事が可能とな
る。
【０２０４】（３）伝送するデータがＩＰパケットでは
ないとしても、コネクション確立の制御にＩＰ／ＦＡＮ
Ｐを用いる事によって、その経路設定を行う事ができ、
希望のところへの希望のデータ転送を実現できる。
【０２０５】（４）ＦＡＮＰノードには、従来のルータ
に様にＯＳＰＦ等のルーチングプロトコルが稼動はして
おらず、基本的に動的ルーチングのサポートは行わなく
てよいため、従来のルータと比べて、処理負荷が軽い。
【０２０６】さて、ひとたび、図２８に示したように、
直結されたコネクションが確立されると、これらのエン
ド・エンドのデータリンクレイヤコネクションは、その
まま固定的に維持されてもよい。
【０２０７】この場合は、明示的にコネクション開放の
制御メッセージが流れてこない限りは、該コネクション
は永続的に継続するので、コネクションはハードステー
トにて維持される事になる。この場合は、通信の終了の
際に、送信者、受信者、あるいは途中ノードがＦＡＮＰ
のフロー交換メッセージのコネクション開放メッセージ
を送出し、各ＦＡＮＰノードに、コネクションの開放を
促す事になる。
【０２０８】ここで、送信者がコネクションの開放を求
める場合とは、番組の終了時、予約時間の満了時等が考
えれられる。また、受信者がコネクションの開放を求め
る場合とは、ユーザが自主的にそのコネクションを切断
する場合や、受信端末の設定（例えばタイマ予約など）
等が考えられる。途中ノードがコネクションの開放を求
める場合とは、途中のケーブル断や電源断等を検出した
場合等が考えられる。
【０２０９】図２９に示すように、コネクションの開放
はフロー交換メッセージのリリース（解放）メッセージ
と、リリースＡＣＫメッセージの交換によって行われ
る。
【０２１０】コネクションの開放を行うノード２９０１
が、隣接ＦＡＮＰノード２９０２に対して、リリースメ
ッセージを送出し、このメッセージを受信したＦＡＮＰ
ノード２９０２が、リリースＡＣＫメッセージを送出す
る。なお、このコネクション開放は、あくまでＦＡＮＰ
ノードにおける「データリンクコネクションの相互接
続」の状態の開放（図２８の点線部分のパイプの開放）
であり、ＡＴＭ網におけるＶＣや、ＩＥＥＥ１３９４に
おける同期チャネル等のデータリンクレイヤコネクショ
ンの開放は必ずしも必要ない。
【０２１１】上流、あるいは下流からのコネクションの
開放要求を受け取り、（それ以上データの転送は、該コ
ネクションの開放により維持されなくなってしまうた
め）全体としてその下流、あるいは上流へのコネクショ
ンの維持に意味がないとノードが判断した場合は、更に
その下流、あるいは上流へとコネクションの開放要求を
該ノードが行っていく（フォワードしていく）ことにな
る。
【０２１２】また、図３０に示すように、コネクション
の維持をソフトステートにて行ってもよい。ソフトステ
ートとは、下流ノードが上流ノードに対して、定期的に
リダイレクトメッセージを送出して、該当するデータリ
ンクコネクションにおいてデータの継続受信が可能であ
ると認識し、該データリンクコネクションにデータを流
し続ける。このリダイレクトメッセージの送出は、図３
０に示す所定のリフレッシュ間隔の値ごととする。そし
て、リダイレクトメッセージが、所定のリフレッシュ時
間が経過しても上流ノードに到着しなかった場合（図３
０の３００２にて示される状態）、下流ノードが受信で
きなくなったと判断して、該データリンクコネクション
へのデータの転送をやめる、という一連の手順である。
【０２１３】下流ノードは、該データリンクコネクショ
ンにデータが流れている間は、リダイレクトメッセージ
を定期的に上流ノードに送信する。間隔は、オファーメ
ッセージで示された「リフレッシュ間隔」で送出する。
データが流れていない場合は、リダイレクトメッセージ
を送出しない。
【０２１４】このようにリダイレクトメッセージを送出
する事で、上流ノードでは、そのリダイレクトメッセー
ジに関連したデータリンクコネクション（２１０１、２
１０２、２１０３、２１０４のいずれか）が正常に動作
している事と、下流ノードの生存確認ができる。
【０２１５】ここで、上流ノードが何かの都合や不具合
でダウンした場合に、下流ノードが該データリンクコネ
クションが設定されたままになるのを防ぐため、下流ノ
ードで該データリンクコネクションにデータが流れない
状態が一定期間続いた時に、下流ノードから該データリ
ンクコネクションを開放することとする。
【０２１６】また、該データリンクコネクションにて転
送しているデータがＩＰパケットである場合は、該デー
タリンクコネクションでのＩＰパケットの転送を終了す
るのに伴い、該ＩＰパケットの転送を該専用データリン
クコネクションから、デフォルトＶＣ（デフォルトチャ
ネル＝非同期チャネル）に切替えを行ってもよい。
【０２１７】次に、先に説明したフローＩＤの使用方法
について説明する。
【０２１８】本発明の方法で確立したデータリンクレイ
ヤコネクションにＩＰパケットを通すという場合に、典
型的な使用方法は、フローＩＤとして、「送信端末のＩ
Ｐアドレス＋受信端末のＩＰアドレス」、または「送信
端末のＩＰアドレス＋送信端末のポート番号＋受信端末
のＩＰアドレス＋受信端末のポート番号」を用いる、と
いうものである。
【０２１９】ＩＰパケットを、この方法により直結され
たデータリンクレイヤコネクションにいれる場合は、途
中のＦＡＮＰノードは、いれるべきＩＰのフローの識別
に、ＩＰパケットのうち、特定の「送信元アドレス＋宛
先アドレス」、あるいは、「送信元アドレス＋送信元ポ
ート番号＋宛先アドレス＋宛先ポート番号」の組を持っ
たものを、該データリンクレイヤコネクションに入れて
いけばよい事になる。なお、これは途中のどのＦＡＮＰ
ノード（通常はルータ）がやってもよい。また、どこで
この直結コネクションが途切れてもよい。このように、
フローＩＤの値として、どのような値を用いるかについ
ては、フローＩＤタイプの番号により、各ＦＡＮＰノー
ドはこれを知ることができる。
【０２２０】次に、直結されたデータリンクレイヤコネ
クションに、ＩＰパケットではなく、生のデータ（例え
ばＭＰＥＧデータ等）をいれるような場合を考える。
【０２２１】まず、フローＩＤとして、「宛先ＩＰアド
レス＋宛先ポート番号」を入れる場合を考える。「宛先
ポート番号の値として、ある範囲内の値を用いる場合に
は、これは直結されたデータリンクレイヤコネクション
にはＩＰパケットではなく、生のデータが入る」といっ
た約束を送受信両側の端末が認識していれば、フローＩ
Ｄの宛先ポート番号の値を見て、ＦＡＮＰノードは、以
降流れて来るデータがＩＰパケットではないという事を
認識する事ができる。この場合は、通信属性に関する情
報を送らなくてもよい場合がある。
【０２２２】フローＩＤとして、「宛先ＩＰアドレス＋
送信端末が決定したユニークなＩＤ」を入れる場合を考
える。この「送信端末が決定したユニークなＩＤ」と
は、送信端末が、なんらかの意味付けを行って、送信端
末でユニークなＩＤを決定して、これを用いる物であ
る。これも、前者と同様に、「ユニークＩＤの値とし
て、ある範囲内の値を用いる場合には、これは直結され
たデータリンクレイヤコネクションには特定の生のデー
タが入る」といった約束を送受信両側の端末で認識しあ
っておく、という方法がまず考えられる。
【０２２３】フローＩＤは、２つ以上のソースから出力
される情報（同時に出力される事がなくてもよい）を、
あるＦＡＮＰノードでマージし、該ＦＡＮＰノードから
は同一のデータリンクレイヤコネクションにて出力する
場合に、各々のソースから流れてくる。
【０２２４】該データリンクにいれるべき情報（フロ
ー）に、同一のフローＩＤをつけておき、異なるソース
からの情報も１本のデータリンクレイヤコネクションに
まとめる事ができるようにするための識別子として使
う、という使用方法も考えられる。
【０２２５】この場合について、図３１を参照して説明
する。基本的に図１の構成と同様の構成をもったネット
ワークであるが（よって、構成要素の詳細の説明は省略
する）、ビデオサーバが複数台（例えば、ここでは、２
台のビデオサーバ３１２１、３１２２）存在する点が異
なる。
【０２２６】これらのビデオサーバからの映像データの
配信は、やはり番組案内配信サーバ３１０２より制御さ
れる。この時、案内サーバ３１０２は、配信を行わせる
ビデオサーバ３１２１、３１２２のいずれかに対して、
「この番号をフローＩＤ（の一部）として利用せよ」と
いう意味で、同一接続時間の同一の映像端末３１０６に
向けての映像データ配信の制御に、ある特定の番号を通
知する。ここで、同一接続時間における異なるビデオサ
ーバからの映像データの配信とは、映像端末３１０６の
ユーザが、見ている映像のチャンネル番号（番組）を変
更するような場合、それぞれ異なるビデオサーバがそれ
ぞれの番組を提供するような場合に発生する。このよう
な場合に、複数のビデオサーバが同一のフローＩＤ（の
一部）を投げる事で、ＦＡＮＰノード（この場合セルス
イッチルータ３１０３）は、これら両方のフローが、同
一のデータリンクコネクション３１０９にフォワードす
べきものである事を知ることができるようになり、ユー
ザによるチャンネルの切替え（すなわち、ビデオサーバ
の変更）が有るような場合にも、該ＦＡＮＰノード（こ
の場合セルスイッチルータ３１０３）より下流側におい
て、新たなデータリンクレイヤコネクションの確立の必
要もなく、各々のデータを適当なデータリンクレイヤコ
ネクションに送る事ができるようになる。
【０２２７】なお、この場合、リダイレクトメッセージ
が下流から流れてきた場合は、これを、ＦＡＮＰにより
関連づけられた複数の上流のＦＡＮＰノード（この場合
ビデオサーバ３１２１、３１２２）に送る必要がある。
【０２２８】また、データリンクレイヤ同士をつなぐス
イッチ（図の場合セルスイッチルータ３１０３内のＡＴ
Ｍスイッチ）は、多対１（異なる入力データリンクコネ
クションからのデータを、１つの出力データリンクコネ
クションにまとめて出力する形態）の接続形態になって
いる事が求められる場合がある。これは、同時に複数の
送信端末がデータを送出することはない、という前提に
立っていてもよい。
【０２２９】また、本発明で１３９４バスとして説明し
た部分が、１３９４コネクタあるいは１３９４ブリッジ
で相互接続された１３９４ネットワークであってもよ
い。
【０２３０】さらに、本発明においては、ルータは家庭
の外のＣＡＴＶヘッドエンドにおかれるものとして説明
してきたが、これが家庭内におかれるものとしても、も
ちろんよい。
【０２３１】本実施形態では、ビデオサーバ１０１から
映像端末１０６までの間の帯域の予約を拡張されたＦＡ
ＮＰにより行う例を紹介してきた。これに対し、既存の
ルータ（本実施形態においてはセルスイッチルータ１０
３）における帯域の予約制御はＲＳＶＰ（Ｒｅｓｏｕｒ
ｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：資
源予約型ネットワークプロトコル）やＳＴ２（Ｓｔｒｅ
ａｍ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ−２：ス
トリーム転送プロトコル）等のネットワークレイヤにお
けるシグナリングプロトコルを用いて行い、ＩＰサブネ
ットの中、すなわち、セルスイッチルータ１０３から映
像端末１０６の間の帯域の予約制御は本発明の拡張され
たＦＡＮＰにより行うことも可能である。この場合のシ
ーケンスを図３２に示す。
【０２３２】図３２には、ネットワークレイヤのシグナ
リングプロトコルとして、ＲＳＶＰを用いた例を示して
いる。なお、図３２には、ＡＲＰや、プロポーズメッセ
ージ、ペンディングメッセージなど、細かなメッセージ
のやり取りについては省略してある。
【０２３３】送信端末（ビデオサーバ１０１）、ルータ
（セルスイッチルータ１０３）、映像端末１０６間の帯
域の予約制御はＲＳＶＰやＳＴ２等のシグナリングプロ
トコルを用い、それらの間のサブネット内の帯域予約制
御は本発明の拡張されたＦＡＮＰを用いて行っている。
すなわち、本発明の拡張されたＦＡＮＰをＲＳＶＰノー
ド間の帯域制御のために使っていることになる。このよ
うにすることにより、既存ルータは、インターネットル
ータ間のデファクトスタンダードとなっており、広く使
われているＳＴ２やＲＳＶＰといった端末とルータ、ル
ータとルータ間の帯域予約プロトコルを使用することが
でき、これまで方法のなかったサブネット内の帯域予
約、特に仮想コネクション形ネットワークが混在するヘ
テロな環境のサブネットにおける帯域制御を、本発明の
拡張されたＦＡＮＰにより行うことができるようにな
る。
【０２３４】（第２の実施形態）次に、第２の実施形態
として、２つ以上の１３９４バスを、それぞれのバスに
接続されたハーフコネクタと呼ぶノードと、それぞれの
ハーフコネクタ間をつなぐ各種のネットワークにて構成
される通信ネットワークシステムについて説明する。
【０２３５】図３３は、第２の実施形態に係る通信ネッ
トワークシステム（例えば、家庭内の各電気機器を接続
するためのホームネットワークシステム）の全体構成例
を示す。図３３に示すように、この通信ネットワークシ
ステムは、送信端末４００１、第１のハーフコネクタ４
００２、第２のハーフコネクタ４００３、受信端末４０
０４、第１の１３９４バス４０１１、イーサネットケー
ブル４０１２、第２の１３９４バス４０１３からなる。
【０２３６】ここで、全ての系は第１の実施形態と同様
に、同一の家庭内においてネットワークを構成するもの
であるとする。よって、この系の上の端末のうち、ＩＰ
ノードであるものは、すべて同一のＩＰサブネットに属
するものとする。ここでは、ＩＰサブネットアドレスは
Ｎとし、それぞれのノードのＩＰアドレスは、それぞれ
送信端末４００１がＮ．１、第１のハーフコネクタ４０
０２がＮ．２、第２のハーフコネクタ４００３がＮ．
３、受信端末４００４がＮ．４であるとする。
【０２３７】また、これらのノードの１３９４アドレ
ス、及びイーサネットアドレスについても、図３３に示
すとおりである。
【０２３８】本実施形態における送信端末４００１、第
１のハーフコネクタ４００２、第２のハーフコネクタ４
００３、受信端末４００４は、すべて第１の実施形態に
て述べたＦＡＮＰノード、即ち本発明で説明している拡
張されたＦＡＮＰの機能を有しているノードである。
【０２３９】送信端末４００１は、ＩＰ端末でもある。
受信端末４００４とＩＰパケットのやりとりを行った
り、受信端末４００４に対して映像の配信を行ったりす
る機能を有する。
【０２４０】映像の配信は、ＩＰパケットに映像情報を
乗せる形で行っても良いし、映像データをそのまま指定
された１３９４の同期チャネルに送出する形でこれを行
っても良い。詳細は後述する。
【０２４１】第１のハーフコネクタ４００２および第２
のハーフコネクタ４００３は、１３９４バス同士を接続
するための機器である。即ち、第１の１３９４バス４０
１１と、第２の１３９４バス４０１３との間を接続する
ために、用いられる機器である。このようなケースは、
例えば第１の１３９４バス４０１１と、第２の１３９４
バス４０１３との間が非常に離れているような場合に、
これらを１本の１３９４バスにまとめるということが難
しい場合に起こり得る。
【０２４２】すなわち、１３９４バスは、その仕様上、
長大なケーブルを用いるのは好ましくないことになって
いる。このようなときに、各々の１３９４バスに、本発
明のハーフコネクタをそれぞれ接続し、これらのハーフ
コネクタ間を専用のケーブルにて接続することによっ
て、これを行う為のものである。詳細は後述する。
【０２４３】受信端末４００４は、ＩＰ端末でもある。
送信端末４００１とＩＰパケットのやりとりを行った
り、送信端末４００１から配送される映像の受信を行っ
たりする機能を有する。
【０２４４】第１のハーフコネクタ４００２と、第２の
ハーフコネクタ４００３との間は、例えば、イーサネッ
トケーブル４１０２にて接続されている。すなわち、本
実施形態では、２つのハーフコネクタ間はイーサネット
フレームにて、各々のデータのやりとりは行われること
になる。
【０２４５】図３４は、ハーフコネクタ４００２、４０
０３の内部構成例を示したものである。
【０２４６】図３４に示すように、ハーフコネクタは、
１３９４物理部４１０１、１３９４リンク部４１０２、
１３９４制御部４１０３、第１のＭＵＸ−ＤＥＭＵＸ４
１０４、ＩＰ／ＦＡＮＰ処理部４１０５、１３９４・イ
ーサ乗換部４１０６、第２のＭＵＸ−ＤＥＭＵＸ４１０
７、イーサインタフェース部４１０８からなる。
【０２４７】１３９４物理部４１０１、１３９４リンク
部４１０２、１３９４制御部４１０３は、それぞれ接続
された１３９４バス（４０１１あるいは４０１３）につ
いて、その物理レイヤ処理、リンクレイヤ処理、バス管
理及びとトランザクションレイヤ処理をそれぞれ行い、
送受信する１３９４フレームを、第１のＭＵＸ−ＤＥＭ
ＵＸ４１０４、または第２のＭＵＸ−ＤＥＭＵＸ４１０
７を通して、ＩＰ／ＦＡＮＰ処理部４１０５、または１
３９４・イーサ乗せ換え部４１０６とデータ（１３９４
から見ると、ＰＤＵ）のやりとりを行う。
【０２４８】ＩＰ／ＦＡＮＰ処理部４１０５は、受信し
たＩＰパケット、ＦＡＮＰパケット、ＡＲＰパケット等
について、ＩＰアドレスに基づくルーチング、ルーチン
グテーブルの管理、ＦＡＮＰ処理、ＡＲＰ処理等を行う
機能を持つ。
【０２４９】１３９４・イーサ乗せ換え部４１０６は、
１３９４側から受信したデータ、特に同期チャネルを通
して受信したデータを、その同期チャネル番号をキーと
して、特定のイーサネットのヘッダを付与した後に、こ
れをイーサネット側に送出する機能と、逆にイーサネッ
ト側から受信したデータを、そのヘッダ情報をキーとし
て、１３９４側の特定の同期チャネルに送出する機能を
有する。すなわち、この処理部におけるデータのフォワ
ーディングはＩＰレイア処理を介さず、データリンクレ
イヤ処理のみで行われる。例えば、図３５（１３９４側
から受信したデータをイーサネット側へ送出する場
合）、図３６（イーサネット側から受信したデータを１
３９４側に送出する場合）に示すような対応テーブルを
用い、ＭＡＣアドレスの値と１３９４バスの同期チャネ
ルのチャネル番号との対応テーブルを作成する。この各
々のマッピングについては、ＩＰ／ＦＡＮＰ処理部４１
０５が行う。
【０２５０】イーサインタフェース部４１０８は、物理
的に接続されたイーサネットとのインタフェースをとる
部分であり、第２のＭＵＸ−ＤＥＭＵＸ４１０７とやり
とりするデータと、イーサネットフレームとのカプセル
化、デカプセル化を行う。
【０２５１】次に、送信端末４００１から受信端末４０
０４にむけて、映像を送信する場合を例にとり、図３７
および図３８を参照しながら、そのシーケンスを時間を
追って説明する。
【０２５２】図３７に、ＡＲＰ（アドレス解決）のシー
ケンスを示す。
【０２５３】まず、送信端末４００１は、受信端末４０
０４のＩＰアドレスから、そのデータリンクレイヤアド
レスを知るために、アドレス解決を行うべく、ＡＲＰ要
求パケットを第１の１３９４バスに送出する（ステップ
Ｓ４２０１）。第１の実施形態でも述べたように、この
ＡＲＰ要求は、ローカルバス（すなわち、第１の１３９
４バス４０１１）上に放送される。
【０２５４】これを受信したＦＡＮＰノードである第１
のハーフコネクタ４００２は、自分がその端末ではない
ことを確認し、かつ、自分に入力されたポート（すなわ
ち、第１の１３９４バス４０１１）とは別のポート（す
なわち、イーサネットケーブル４０１２）が接続されて
いることを確認すると、このＡＲＰ要求をイーサネット
ケーブル４０１２にフォワードする（ステップＳ４２０
２）。ここで、宛先イーサネットアドレスはブロードキ
ャストアドレスである。
【０２５５】これを受信した第２のハーフコネクタ４０
０３も、第１のハーフコネクタ４００２とは逆の手順を
踏んで、該ＡＲＰ要求を第２の１３９４バスにフォワー
ドする（ステップＳ４２０３）。このとき、このＡＲＰ
要求は「ローカルバス」への放送の形で送出されてもよ
い。
【０２５６】これを受信した受信端末４００４は、自分
の１３９４アドレス（ＥＵＩ６４と「バスＩＤ＋物理Ｉ
Ｄ」）を記した上で、第２の１３９４バス上にこれを送
り返す（ステップＳ４２０４）。このとき、このＡＲＰ
応答の送信アドレスは第２のハーフコネクタの１３９４
アドレスである。
【０２５７】これを受信した第２のハーフコネクタ４０
０３は、自分のイーサネットアドレスを解決アドレスの
所に記して、代理応答を第１のハーフコネクタ４００２
に対して行う（ステップＳ４２０５）。このとき、宛先
は第１のハーフコネクタのイーサネットアドレスであ
る。また、第２の１３９４バス４０１３側に、受信端末
４００４のＩＰアドレスを持った端末が存在することを
認識し、これを内部のルーチングテーブルに記述する。
【０２５８】これを受信した第１のハーフコネクタ４０
０２は、自分の１３９４アドレスを解決アドレスの所に
記して、代理応答を送信端末４００１に対して行う（ス
テップＳ４２０６）。このとき、宛先は送信端末４００
１の１３９４アドレスである。また、イーサネット４０
１２側に、受信端末４００４のＩＰアドレスを持った端
末が存在することを認識し、これを内部のルーチングテ
ーブルに記述する。
【０２５９】このようにして、送信端末４００１は、受
信端末４００４へ向けてのＩＰパケットは、第１のハー
フコネクタ４００２（の１３９４アドレス）に対して送
出すれば良いことを知る。
【０２６０】なお、図３７では、ＡＲＰ要求が一度ター
ゲットノードまで到達し、そこから順次逆流していく形
でアドレス解決が行われる場合を示しているが、この場
合に限らず、途中ノードが、ターゲットノードについて
の情報を既に有している場合などにおいて、順次アドレ
ス解決を直接行ってしまうような場合も可能である。
【０２６１】さて、次に送信端末４００１は、自分がＦ
ＡＮＰノードであることを認識しており、更にこれから
受信端末４００４に対して送信するのが映像であること
を認識している。よって、これから送出する映像を途中
のＦＡＮＰノードにおいて、ＩＰ処理を伴わずにデータ
リンク処理のみでフォワードしてもらうことを意図して
いる。
【０２６２】このため、送信端末４００１は、受信端末
４００４との間で、ＩＰパケットによる初期設定や符号
化方式の確認、映像受付能力の可否などを確認した上
で、映像送出の準備にはいる。これのシーケンスを図３
８に示す。
【０２６３】まず、送信端末４００１は、第１の１３９
４バス４０１１上の同期リソースマネージャのレジスタ
にアクセスして、第１のハーフコネクタ４００２との間
に、映像送信に必要な帯域を予約し、同期チャネル番号
を取得する（ステップＳ４４０１）。図３９に、このと
き得られた同期チャンネル４３０１を示す。
【０２６４】そして、その同期チャネル４３０１を通し
て、第１のハーフコネクタ４００２に対して、ＦＡＮＰ
のプロポーズメッセージを送出する。これは、ＶＣＩＤ
として自分のＥＳＩとシーケンス番号をターゲットＩＰ
アドレスとして、受信端末４００４のＩＰアドレス
（Ｎ．４）を記して送信する（ステップＳ４４０２）。
【０２６５】これを受信した第１のハーフコネクタ４０
０２は、これがＦＡＮＰパケット（プロポーズメッセー
ジ）であることを認識すると、最終的な宛先ＩＰアドレ
ス（受信端末４００４）をターゲットＩＰアドレスより
確認し、それがイーサネットケーブル４０１２の側に存
在することを内部のルーチングテーブルを参照すること
により確認する。そして、プロポーズＡＣＫメッセージ
に自分のＩＰアドレスを記入した上で、第１の１３９４
バス４０１１の非同期チャネル上に送り返す（ステップ
Ｓ４４０３）。
【０２６６】これを受信した送信端末４００１は、オフ
ァーメッセージを、宛先ＩＰアドレスを第１のハーフコ
ネクタ４００２のＩＰアドレスとし、先のＶＣＩＤを記
述し、第１の実施形態と同様に、フローＩＤ中に最終的
な受信端末である４００４のＩＰアドレスを記し、さら
に必要な帯域の値と、エンド・エンドＡＣＫ要求等を含
めて、第１の１３９４バス４０１１の非同期チャネル上
に送出する（ステップＳ４４０４）。その際の、宛先１
３９４アドレスは当然第１のハーフコネクタ４００２の
１３９４アドレスとなる。
【０２６７】これを受信した第１のハーフコネクタ４０
０２は、これがＦＡＮＰパケットであることを認識する
と、最終的な宛先ＩＰアドレス（受信端末４００４）を
フローＩＤより確認し、それがイーサネットケーブル４
０１２の側に存在することを再度確認する。
【０２６８】そして、第２のハーフコネクタ４００３が
イーサネットヘッダの値の確認のみで、送信するデータ
を直接第２の１３９４バス４０１３上の同期チャネルに
送出できるように、第２のハーフコネクタ固有のイーサ
ネットアドレス「Ａ２」とは異なる値を、送出するイー
サネットフレームの宛先アドレスとして用いることにす
る。この値は、第１のハーフコネクタ４００２、及び第
２のハーフコネクタ４００３のイーサネットアドレスの
値と相異なるものであり、かつ、現在他のフローのデー
タリンクレイヤでの直接フォワーディングに既に使われ
ていない値であれば、どの様な値を用いても良い。
【０２６９】例えば、ここで第１のハーフコネクタ４０
０２が選択したイーサネットアドレスの値が「＃Ａ」で
あるとすると、今後宛先イーサネットアドレスに「＃
Ａ」と記されたイーサネットフレームには、受信端末４
００４に向けた映像情報のみが乗ることになる。これ
は、第１のハーフコネクタ４００２と第２のハーフコネ
クタ４００３の間に、「＃Ａ」をＶＣＩとした仮想コネ
クションが確立されたことと等価である。これを図３９
では、コネクション４３０２として示している。なお、
ハーフコネクタ４００２、４００３は、共に、どの様な
イーサネットアドレスに宛てられたフレームであって
も、それが１３９４・イーサ乗換部４１０６を通るもの
以外は、一度ＩＰ／ＦＡＮＰ処理部４１０５に、その宛
先イーサネットアドレスの値と共に渡されるように初期
設定がなされているとする。このようにすることによ
り、ＩＰ／ＦＡＮＰ処理部４１０５は、必要なイーサネ
ットアドレスについては、１３９４・イーサ乗換部４１
０６へ適切な設定により、データリンクレイヤにおける
スイッチングをするような設定をＦＡＮＰパケットの内
容によって行うことが可能となる。
【０２７０】図３９のコネクション４３０２を通して、
第１のハーフコネクタ４００２は、ＦＡＮＰのプロポー
ズメッセージを送出する（ステップＳ４４０６）。これ
は、ＶＣＩＤとして自分のＥＳＩとシーケンス番号を、
ターゲットＩＰアドレスとして受信端末４００４のＩＰ
アドレス（Ｎ．４）を記して送信する。
【０２７１】これを受信した第２のハーフコネクタ４０
０３は、これがＦＡＮＰパケット（プロポーズメッセー
ジ）であることを認識すると、最終的な宛先ＩＰアドレ
ス（受信端末４００４）をターゲットＩＰアドレスより
確認し、それが第２の１３９４バス４０１３の側に存在
することを内部のルーチングテーブルを参照することに
より確認する。そして、プロポーズＡＣＫメッセージを
ターゲットＩＰアドレスとして、自分のＩＰアドレスを
記入した上で、イーサネットケーブル４０１２に対し
て、宛先アドレスを第１のハーフコネクタ４００２のイ
ーサネットアドレスとして送り返す（ステップＳ４４０
７）。
【０２７２】この記述からもわかるように、通常のイー
サネットアドレスをイーサフレームの宛先ヘッダとして
用いて送る場合は、ＦＡＮＰでいう「デフォルトＶＣ」
にて送る場合に相当する。
【０２７３】これを受信した第１のハーフコネクタ４０
０２は、オファーメッセージを宛先ＩＰアドレスを第２
のハーフコネクタ４００３のＩＰアドレスとし、先のＶ
ＣＩＤを記述し、フローＩＤ中に最終的な受信端末であ
る４００４のＩＰアドレスを記し、さらに必要な帯域の
値と、エンド・エンドＡＣＫ要求を含めて、イーサネッ
トケーブル４０１２上に送出する（ステップＳ４４０
８）。その際の、宛先イーサネットアドレスは第２のハ
ーフコネクタ４００３のイーサネットアドレスとなる。
【０２７４】これを受信した第２のハーフコネクタ４０
０３は、これがＦＡＮＰパケットであることを認識する
と、最終的な宛先ＩＰアドレス（受信端末４００４）を
フローＩＤより確認し、それが第２の１３９４バス４０
１３の側に存在することを再度確認する。そして、受信
端末４００４まで必要な帯域を確保して、映像信号を送
信すべく、第２の１３９４バスの同期リソースマネージ
ャのレジスタの設定により帯域と同期チャネル番号を確
保する（ステップＳ４４１０）。図３９に、このとき得
られる同期チャンネル４３０３を示す。
【０２７５】そして、該同期チャネル４３０３を通して
ＦＡＮＰのプロポーズメッセージを送信する（ステップ
Ｓ４４１１）。
【０２７６】これを受信した受信端末４００４は、受け
入れが可能な場合は、プロポーズＡＣＫメッセージを、
第２のハーフコネクタ４００３に送信する（ステップＳ
４４１２）。
【０２７７】その後、第２のハーフコネクタ４００３
は、ＦＡＮＰのオファーメッセージを受信端末４００４
に送信する（ステップＳ４４１３）。
【０２７８】受信可能な場合は、受信端末４００４は、
リダイレクトメッセージを、上流のＦＡＮＰノード（こ
の場合第２のハーフコネクタ４００３）に、エンド・エ
ンドＡＣＫフラグをＯＮにして、送出する（ステップＳ
４４１４）。このエンド・エンドＡＣＫフラグは、受信
端末４００４に送信されてきたＦＡＮＰのオファーメッ
セージに、エンド・エンドＡＣＫ要求があり、かつ自分
が最終の端末であることに伴う処理である。
【０２７９】このリダイレクトメッセージを受信した第
２のハーフコネクタ４００３は、下流側（この場合、受
信端末４００４）の同期チャネルの使用準備が整ったと
判断し、第２のハーフコネクタ４００３内の１３９４・
イーサ乗換部４１０６にて、イーサネットアドレスが＃
Ａ（４３０２）でやってきたフレームのＳＤＵ（サービ
スデータユニット）を、ＩＰ／ＦＡＮＰ処理部４１０５
における処理無しに、直接データリンクレイヤフォワー
ディングできるように設定を行う。このようにすること
により、特定のイーサネットアドレス「＃Ａ」をつけて
やってきたフレームについては、図３６に示したような
対応テーブルを参照することにより、直接そのＳＤＵを
同期チャネル４３０３に送出できることになり、データ
フォワーディング処理の大幅な効率化、及び高速化が図
れることになる。
【０２８０】また、該処理がＩＰ／ＦＡＮＰ処理部４１
０５での処理が伴わないため、ＩＰ／ＦＡＮＰ処理部４
１０５の負荷の低減と、負荷分散が同時に図れることに
なる。さらに、ＩＰパケットではないデータも送信する
ことが可能である。
【０２８１】第２のハーフコネクタ４００３は、リダイ
レクトメッセージを上流のＦＡＮＰノード（この場合第
１のハーフコネクタ４００２）に送出する（ステップＳ
４４１５）。 このときも、下流側からのリダイレクト
メッセージのエンド・エンドＡＣＫフラグが立ち上がっ
ているため、ここでもエンド・エンドＡＣＫフラグはＯ
Ｎとしておく。
【０２８２】こうして、リダイレクトメッセージは第２
のハーフコネクタ４００３、第１のハーフコネクタ４０
０２をとおって、送信端末４００１まで配送される。
【０２８３】第１のハーフコネクタ４００２では、同期
チャネル４３０１と、イーサネットアドレスが「＃Ａ」
で示されるイーサネットフレーム４３０２への直接変換
が１３９４・イーサ乗換部４１０６に設定される。ま
た、リダイレクトメッセージのフォワーディングの際
は、各１３９４バスの非同期チャネル、またはイーサネ
ット上の正規のイーサネットアドレス「Ａ１」を使って
配送される。
【０２８４】こうして、送信端末４００１で、エンド・
エンドＡＣＫのフラグが立ったリダイレクトメッセージ
が受信されると（ステップＳ４４１６）、送信端末４０
０１は、同期チャネル４３０１が、最終的に受信端末４
００４までデータリンクレイヤのレベルで直結されたこ
とを確認できる。その後、送信端末４００１は、映像デ
ータの送信を同期チャネル４３０１を通してはじめる
（ステップＳ４４１７）。
【０２８５】これは、４３０２、４３０３を通して、受
信端末４００４に、データリンクレイヤ処理のみで、途
中ノードである各ハーフコネクタ４００２、４００３に
おけるＩＰ／ＦＡＮＰ処理部４１０５での処理のないま
ま配送されることが可能となる。
【０２８６】なお、ここで配送される映像情報は、第１
の実施形態と同様に、映像データをＩＰパケットにカプ
セル化したものであっても良いし、直接映像データを１
３９４の同期チャネル（あるいは宛先イーサネットアド
レスが「＃Ａ」で示されるイーサネットフレーム４３０
２）に乗せ込む形でも、どちらでもよい。また、イーサ
フレームに、直接１３９４フレームを乗せ込む形で伝送
してもよい。
【０２８７】第１の実施形態と同様に、ソフトステート
の維持にて、該コネクションの維持が行われる場合に
は、上記リダイレクトメッセージは定期的に上流方向の
送出される。このリダイレクトメッセージが一定時間以
上届かない場合や、上流方向から、明示的にコネクショ
ン断のためのメッセージ（リリースメッセージ）が送ら
れてきた場合には、該ソフトステートを解除し、該直結
データリンクレイヤコネクションについての１３９４・
イーサ乗せ換え部４１０６の設定もクリアする。
【０２８８】以上説明したように、複数のハーフコネク
タ（４００２、４００３）と、その間を結ぶイーサネッ
トケーブル（４０１２）を用いれば、１３９４ブリッジ
による１３９４同士の接続でなくとも、複数の１３９４
バス同士をハーフコネクタを用いて相互接続し、お互い
に通信ができるようになる事が分かる。
【０２８９】図４０に、ハーフコネクタとイーサネット
ケーブルの使用形態の一例を示す。図４０に示すよう
に、１３９４間相互接続ケーブルの物理形状は、２つの
ハーフコネクタ４００２、４００３間に長大なイーサネ
ットケーブル４５０３があらかじめつながれている。こ
のケーブル部分は、ＵＴＰ５や同軸ケーブルなどの電気
ケーブルにて接続されていてもよいし、プラスチック光
ファイバのような光ケーブルにて接続されていても良
い。ただし、物理レイヤの伝送方式は、イーサネットの
標準に従うものとする。
【０２９０】また、各々のハーフコネクタには、比較的
短いケーブル（１３９４専用ケーブル）を介して、１３
９４コネクタ４５０１、４５０２が接続されている。こ
こには、１３９４専用ケーブルが接続されているため、
両ハーフコネクタ４００２、４００３のための給電は、
それぞれ１３９４コネクタ４５０１、４５０２、及び１
３９４ケーブルを介して行うことができる。よって、図
４０の系については、特別な給電を行う必要はない。こ
れは、２つの１３９４バスを相互接続したいユーザの立
場から見ると、これを行うには、単に第１の１３９４バ
ス４０１１に、ケーブルの片方の端（４５０１）を接続
し、第２の１３９４バス４０１３にケーブルのもう片方
の端（４５０２）を接続すれば、その接続は基本的に完
了であり、接続の利便性を飛躍的に向上させる事が可能
となる。
【０２９１】また、１３９４のケーブルは基本的に４．
５ｍが上限であるのに対し、本発明の方式では、両ハー
フコネクタ４００２、４００３間を接続するケーブルは
長大なもの（具体的には、例えば、数百メータ）を選択
可能であり、お互いに遠く離れた１３９４バス同士を接
続するといった場合に、非常に有益である。
【０２９２】なお、ここでは長大ケーブルとして例を示
してきたが、図４１に示すように、ハーフコネクタ４０
０２、４００３間を無線で接続することも可能である。
【０２９３】４８０１、４８０２は１３９４コネクタ、
４８０３、４８０４は無線による相互接続のための無線
送受信装置である。
【０２９４】無線での伝送方式にＭＡＣフレームを用い
る場合は、本実施形態の手法が基本的にそのまま使え
る。このように、ハーフコネクタ間を無線のインタフェ
ースとすると、この間の接続が配線レスとなり、ユーザ
は容易な配線を行うことができるようになるという特徴
がある。
【０２９５】なお、１３９４間相互接続ケーブルは、本
発明のような（図４０、図４１に示したような）１３９
４ハーフコネクタ間の接続については言うにおよばず、
一般の１３９４ブリッジをハーフブリッジの構成にし
て、これを実現する場合についても適用できることは明
らかである。その場合、上記までの実施形態の説明で
「宛先ＩＰアドレスを指定」として説明していた個所
を、１３９４アドレスと置き換えて処理させれば、１３
９４ブリッジとしての機能の実現が可能である。
【０２９６】ところで、図４２に示すように、送信端末
として、デジタル衛星放送（またはデジタルＣＡＴＶ
等）からのＭＰＥＧ映像を受信し、これをＭＰＥＧｏｖ
ｅｒ１３９４のフォーマットに直して、あるいはＭＰＥ
Ｇデコーダにより生の映像データに変換した後、これを
１３９４の同期チャネルのデータとして送出するように
すれば、ＩＰパケット等のネットワークレイヤ、あるい
はＩＥＥＥ１３９４等のデータリンクレイヤフレーム
等、家庭における転送パケットに当初収まっていなかっ
た映像データ（あるいは音声データ、通常データなど）
についても、本ホームネットワークにおいて転送するこ
とが可能となり、映像放送のためのケーブル配線をわざ
わざやり直さなくても、本ホームネットワーク上へのデ
ータの流通が可能となる。
【０２９７】図４３に、これを実現する送信端末４９０
１の内部構成例を示す。図４３において、送信端末４９
０１は、衛星放送受信インタフェース部９００１、ＭＰ
ＥＧデータフォーマット変換部９００２、ＩＰ／ＦＡＮ
Ｐ処理部９００３、ＭＵＸ／ＤＥＭＵＸ９００４、１３
９４インタフェース部９００５からなる。
【０２９８】衛星放送受信インタフェース部９００１
は、衛星放送からのデータを受信するインタフェースで
あり、データの整形の後、これをＭＰＥＧデータフォー
マット変換部９００２に送出する。
【０２９９】ＭＰＥＧデータフォーマット変換部９００
２では、送られてきたＭＰＥＧデータについて、衛星放
送用のＭＰＥＧデータフォーマットから、ＩＥＥＥ１３
９４上のＭＰＥＧデータフォーマットに変換し、ＭＵＸ
／ＤＥＭＵＸ９００４に送出する。ここでデスクランブ
ル処理等を行ってもよい。
【０３００】ＩＰ・ＦＡＮＰ処理部９００３、１３９４
インタフェース処理部９００５は、前述の同名の処理部
と同様の機能を持つので、詳細の説明は省略する。
【０３０１】ＭＰＥＧデータフォーマット変換部９００
２では、送られてきたＭＰＥＧデータに、適切なフォー
マット変換が施されるので、衛星放送からのＭＰＥＧデ
ータを、１３９４バスを通して映像端末までデータを送
ることができるわけである。
【０３０２】図４４は、衛星放送により受信したＭＰＥ
Ｇデータを送信端末４９０１においてデコード（復号
化）してしまい、生の映像データとなったものを、１３
９４バスを通して映像端末にフォワードする場合の送信
端末４９０１の内部構成例について示したものである。
【０３０３】図４４では、ＭＰＥＧデコード部９１０５
において、ＭＰＥＧデコードを行い、生の映像データを
１３９４バスに送出する点が、図４３と異なる部分であ
る。
【０３０４】ＭＰＥＧデコーダ、あるいはＭＰＥＧｏｖ
ｅｒ１３９４への整合を行う機能に、さらに、同時に数
チャンネルの処理機能が備わっていれば、該ホームネッ
トワークに同時に数チャンネルの映像情報の流通が可能
となり、例えば一家の複数の構成員がそれぞれ同時にテ
レビを見ている場合など、複数の映像を見ることが望ま
れる場合において非常に有益である。なお、ここのＭＰ
ＥＧデコーダ、もしくは、ＭＰＥＧｏｖｅｒ１３９４整
合部において、ＩＰパケットへのカプセル化は、行って
もよいし、行わなくてもよい。
【０３０５】なお、本実施形態として「送信端末」とし
て説明してきたものは、一般に「セットトップボック
ス」として知られるものであってもよい。
【０３０６】また、本実施形態では、ＩＥＥＥ１３９４
バスを例に説明を行ってきたが、ＡＴＭ等他のデータリ
ンクレイヤ技術においても適用が可能であることは明ら
かである。その場合は、チャネル番号の代わりに、ＶＰ
Ｉ／ＶＣＩの値を用いればよい。
【０３０７】（第３の実施形態）次に、第３の実施形態
として、２つ以上の１３９４バスを接続して構成される
通信ネットワークシステム、すなわち、それぞれの１３
９４バスに接続されたハーフコネクタと呼ぶノードと、
それぞれのハーフコネクタ間をつなぐネットワークにて
構成される通信ネットワークシステムについて説明す
る。なお、ここでは、ハーフコネクタ間をつなぐネット
ワークとして、イーサネットを用い、かつハーフコネク
タ間に複数のＦＡＮＰ機能付きイーサネットスイッチを
配置する場合について示す。
【０３０８】図４５は、第３の実施形態に係る通信ネッ
トワークシステム（例えば、家庭内の各電気機器を接続
するためのホームネットワークシステム）の全体構成例
を示す。
【０３０９】図４５において、この通信ネットワークシ
ステムは、送信端末５００１、第１のハーフコネクタ５
００２、ＦＡＮＰイーサスイッチ５００３、第２のハー
フコネクタ５００４、受信端末５００５、第１の１３９
４バス５０１１、第１のイーサネットケーブル５０１
２、第２のイーサネットケーブル５０１３、第２の１３
９４バス５０１４からなる。
【０３１０】ここで、全ての系は第１の実施形態と同様
に、同一の家庭内において、ネットワークを構成するも
のであるとする。よって、この系の上の端末のうち、Ｉ
Ｐノードであるものは、すべて同一のＩＰサブネットに
属するものとする。ここでも、ＩＰサブネットアドレス
はＮとし、それぞれのノードのＩＰアドレスは、それぞ
れ送信端末５００１がＮ．１、第１のハーフコネクタ５
００２がＮ．２、ＦＡＮＰイーサスイッチ５００３が
Ｎ．３、第２のハーフコネクタ５００４がＮ．４、受信
端末５００５がＮ．５であるとする。
【０３１１】また、これらのノードの１３９４アドレ
ス、及びイーサネットアドレスについても、図４５に示
すとおりである。
【０３１２】本実施形態における送信端末５００１、第
１のハーフコネクタ５００２、ＦＡＮＰイーサスイッチ
５００３、第２のハーフコネクタ５００４、受信端末５
００５は、すべて第１の実施形態にて述べたＦＡＮＰノ
ード、即ち本発明で説明している拡張されたＦＡＮＰの
機能を有しているノードである。
【０３１３】送信端末５００１、第１のハーフコネクタ
５００２、ＦＡＮＰイーサスイッチ５００３、第２のハ
ーフコネクタ５００４、受信端末５００５は、すべて第
２の実施形態で説明した同名の装置と同様の機能を有す
る。よって、詳細の説明は省略する。
【０３１４】本実施形態でも、第１のハーフコネクタ５
００２と、第２のハーフコネクタ５００４との間は、イ
ーサネットケーブル５０１２、５０１３にて接続されて
いる。すなわち、本実施形態においても、２つのハーフ
コネクタ間はイーサネットフレームにて、各々のデータ
のやりとりが行われることになる。
【０３１５】ＦＡＮＰイーサスイッチ５００３は、ＦＡ
ＮＰ機能を有するイーサネットスイッチであるが、後述
のように、入力されてきたＦＡＮＰパケットについて
は、これを内部のＩＰ／ＦＡＮＰ処理部に取り込むとい
う特徴（これは、イーサネットフレームのプロトコル種
別を見る事によって行う）と、フレームの入出力前後
で、あらかじめ内部のテーブルに設定されたように、フ
レームのイーサネットアドレスを書き換えて、これを出
力する機能とを持つ。特に後者は、ＡＴＭスイッチノー
ドがＡＴＭセルの入出力の前後にＶＰＩ／ＶＣＩを書き
換えるのと、同様の動作を行うためのものである。
【０３１６】本実施形態では、ＦＡＮＰイーサスイッチ
５００３（あるいは内部のスイッチ）は２ポートの物理
構成であるが、多ポートのＦＡＮＰイーサネットスイッ
チも、同様の構成方法、仕組みで構築が可能である。
【０３１７】図４６にＦＡＮＰイーサスイッチ５００３
の内部構成例を示す。図４６において、ＦＡＮＰイーサ
スイッチ５００３は、第１のイーサインタフェース部５
１０１、第１のＭＵＸ−ＤＥＭＵＸ５１０２、ＩＰ／Ｆ
ＡＮＰ処理部５１０３、イーサフレームスイッチ部及び
イーサヘッダ書き換え部５１０４、第２のＭＵＸ−ＤＥ
ＭＵＸ５１０５、第２のイーサインタフェース部５１０
６からなる。
【０３１８】イーサインタフェース部５１０１、５１０
６は、物理的に接続されたイーサネットとのインタフェ
ースを司る部分であり、ＭＵＸ−ＤＥＭＵＸ５１０２、
５１０５とやりとりするデータと、イーサネットフレー
ムとのカプセル化、デカプセル化を行う。
【０３１９】ＩＰ／ＦＡＮＰ処理部５１０３は、受信し
たＩＰパケット、ＦＡＮＰパケット、ＡＲＰパケット等
について、ＩＰアドレスに基づくルーチング、ルーチン
グテーブルの管理、ＦＡＮＰ処理、ＡＲＰ処理等を行う
機能を持つと共に、イーサフレームスイッチ及びイーサ
ヘッダ書き換え部への適切な設定を行う機能を有する。
【０３２０】イーサフレームスイッチ及びイーサヘッダ
乗せ換え部５１０４は、両インタフェースから受信した
イーサフレームを、その宛先イーサネットアドレスを参
照して、これをもとにして、適当な出力ポートにスイッ
チングする機能と、あらかじめＩＰ／ＦＡＮＰ処理部５
１０３からの設定にしたがって、該スイッチングの際に
イーサネットアドレスの少くなくとも一部を書き換えて
出力する機能を有する。このため、ＡＴＭスイッチのよ
うに、内部にヘッダ変換テーブルを持っていても良い。
また、イーサネットアドレスの学習機能も有しており、
入力されたイーサネットフレームのソースアドレスを参
照し、これを入力ポートと共に、一定時間記憶しておく
機能がある。
【０３２１】なお、このモジュールを通過するイーサネ
ットフレームについては、ＩＰ／ＦＡＮＰ処理部５１０
３による処理は伴わずに通過できる。
【０３２２】次に、送信端末５００１から受信端末５０
０５にむけて、映像を送信する場合を例に、図４７、図
４８を参照ながら、そのシーケンスを時間を追って説明
する。
【０３２３】図４７は、ＡＲＰのシーケンスを示したも
のである。
【０３２４】まず、送信端末５００１は、受信端末５０
０５のＩＰアドレスから、そのデータリンクレイヤアド
レスを知るために、アドレス解決を行うべく、ＡＲＰ要
求パケットを第１の１３９４バス５０１１に送出する
（ステップＳ５４０１）。第２の実施形態でも述べたよ
うに、このＡＲＰ要求は、ローカルバス（即ち第１の１
３９４バス）上に放送される。
【０３２５】これを受信したＦＡＮＰノードである第１
のハーフコネクタ５００２の処理は第２の実施形態の場
合と同様である。その結果、このＡＲＰ要求をイーサネ
ットケーブル５０１２に、宛先アドレスはイーサネット
ブロードキャストアドレスとして、フォワードする（ス
テップＳ５４０２）。
【０３２６】ＦＡＮＰイーサスイッチ５００３も、これ
を受信するが、該当するＩＰアドレスを持っていないた
め、ＡＲＰ応答を送ることはない。また、イーサフレー
ムスイッチ部５１０４を通して、該ＡＲＰ要求は第２の
イーサネットケーブル５０１３宛にフォワードされる。
なお、この時（宛先アドレスがブロードキャストアドレ
スの時）は、イーサネットアドレスの書き換えが行われ
ることはなく、そのままフォワードされる。
【０３２７】これを受信した第２のハーフコネクタ５０
０４、受信端末５００５の処理は、第２の実施形態の場
合と同様である（ステップＳ５４０３）。すなわち、こ
れを受信した受信端末５００５は、自分の１３９４アド
レス（ＥＵＩ６４と「バスＩＤ＋物理ＩＤ」）を記した
上で、ＡＲＰ応答を送り返し（ステップＳ５４０４）、
これがＦＡＮＰイーサスイッチ５００３に到達する。こ
の時、イーサフレームの宛先アドレスは第１のハーフコ
ネクタ５００２のイーサネットアドレス「Ａ１」となっ
ている。
【０３２８】前述のように、ＦＡＮＰイーサスイッチ５
００３は、学習機能を有しており、ＡＲＰ要求の際に第
１のハーフコネクタ５００２のイーサネットアドレス
と、その物理ポートの方向（すなわち、第１のイーサネ
ットケーブル５０１２の側）をテーブルとして有してい
るため、イーサフレームスイッチ部５１０４にてスイッ
チングされて、第１のハーフコネクタ５００２に到達す
る（ステップＳ５４０５）。
【０３２９】そして、第１のハーフコネクタ５００２が
ＡＲＰ応答（代理応答）を返す事で（ステップＳ５４０
６）、最終的に該ＡＲＰ応答は送信端末５００１に到達
する。
【０３３０】このようにして、送信端末５００１は、受
信端末５００５へ向けてのＩＰパケットは、第１のハー
フコネクタ５００２（の１３９４アドレス）に対して送
出すれば良いことを知る。
【０３３１】次に、送信端末５００１は、第２の実施形
態と同様に、これから送出する映像を途中のＦＡＮＰノ
ードにおいて、ＩＰ処理を伴わずにデータリンク処理の
みでフォワードしてもらうことを意図し、受信端末５０
０５との間で、ＩＰパケットによる初期設定や符号化方
式の確認、映像受付能力の可否などを確認した上で、映
像送出の準備にはいる。これを図４８に示すシーケンス
を参照しながら説明する。
【０３３２】送信端末５００１および第１のハーフコネ
クタ５００２の処理のうち、両者のメッセージのやり取
り（ＦＡＮＰのペンディングメッセージの送信まで）に
ついては、第２の実施形態の場合と同様である（ステッ
プＳ５５０１〜ステップＳ５５０５）。
【０３３３】送信端末５００１から、オファーメッセー
ジを受信した第１のハーフコネクタ５００２は、これが
ＦＡＮＰパケットであることを認識すると、最終的な宛
先ＩＰアドレス（受信端末５００５）をフローＩＤより
確認し、それがイーサネットケーブル５０１２の側に存
在することを確認する。そして、次の段のＦＡＮＰノー
ドがイーサネットヘッダの確認のみで、送信するデータ
を直接データリンクレイヤスイッチングできるように、
第２のハーフコネクタ固有のイーサネットアドレスとは
異なる値を、送出するイーサネットフレームの宛先アド
レスとして用いることにする。この値は、第１のハーフ
コネクタ５００２および第２のハーフコネクタ５００４
のイーサネットアドレスの値と相異なるものであれば、
どの様な値を用いても良い。
【０３３４】例えば、ここで第１のハーフコネクタ５０
０２が選択したイーサネットアドレスが「＃Ａ」である
とする。今後宛先イーサネットアドレスに「＃Ａ」と記
されたイーサネットフレームには、受信端末５００５に
向けた映像情報のみが乗ることになる。
【０３３５】これは、第１のハーフコネクタ５００２と
次段のＦＡＮＰノード（具体的にはＦＡＮＰイーサスイ
ッチ５００３）の間に、「＃Ａ」をＶＣＩとした仮想コ
ネクションが確立されたことと等価である。これを図４
９に５３０２と付して示している。
【０３３６】このコネクション５３０２を通して、第１
のハーフコネクタ５００２は、ＦＡＮＰのプロポーズメ
ッセージを送出する（ステップＳ５５０６）。その際、
イーサネットフレームのプロトコル種別には、ＦＡＮＰ
を意味する番号が記されているものとする。またプロポ
ーズメッセージは、ＶＣＩＤとして自分のＥＳＩとシー
ケンス番号を、ターゲットＩＰアドレスとして受信端末
５００５のＩＰアドレスを記して送信する。
【０３３７】これを受信したＦＡＮＰイーサスイッチ５
００３は、イーサネットフレームのプロトコル種別のフ
ィールドを参照し、これがＦＡＮＰパケット（プロポー
ズメッセージ）であることを認識すると、これを内部の
ＩＰ／ＦＡＮＰ処理部５１０３に転送する。そして、該
イーサネットフレームの宛先イーサネットアドレスが第
２のハーフコネクタ５００４側に存在する事を確認し、
これを最終的な宛先ＩＰアドレス（受信端末５００５）
と関連づけて、内部のルーチングテーブルに、登録す
る。そして、プロポーズＡＣＫメッセージを自分のＩＰ
アドレスを記入した上で、第１のイーサネットケーブル
５０１２に対して、宛先アドレスを第１のハーフコネク
タ５００２のイーサネットアドレスとして送り返す（ス
テップＳ５５０７）。
【０３３８】これを受信した第１のハーフコネクタ５０
０２は、オファーメッセージを宛先ＩＰアドレスをＦＡ
ＮＰイーサスイッチ５００３のＩＰアドレス「Ｎ．３」
とし、先のＶＣＩＤを記述し、フローＩＤ中に最終的な
受信端末である５００５のＩＰアドレス「Ｎ．５」を記
し、さらに必要な帯域の値と、エンド・エンドＡＣＫ要
求を含めて、第１のイーサネットケーブル５０１２上に
送出する（ステップＳ５５０８）。その際の宛先イーサ
ネットアドレスはＦＡＮＰイーサスイッチ５００３のイ
ーサネットアドレス「Ａ２」となる。この場合も、イー
サネットフレームのプロトコル種別にはＦＡＮＰを意味
する番号が記されていてもよい。
【０３３９】該オファーメッセージを受信したＦＡＮＰ
イーサスイッチ５００３は、これがＦＡＮＰパケットで
あることを認識すると、これをＩＰ／ＦＡＮＰ処理部５
１０３に転送する。ここにて、最終的な宛先ＩＰアドレ
ス（受信端末５００５）をフローＩＤより確認し、それ
が第２のイーサネットケーブル５０１３の側に存在する
ことを確認する。そして、次の段のＦＡＮＰノード（具
体的には第２のハーフコネクタ５００４）がイーサネッ
トヘッダの確認のみで、送信するデータを直接データリ
ンクレイヤスイッチングできるように、ここでも、第２
のハーフコネクタ固有のイーサネットアドレスとは異な
る値を、送出するイーサネットフレームの宛先アドレス
として用いることにする。
【０３４０】例えば、ＦＡＮＰイーサスイッチ５００３
が選択したイーサネットアドレスが「＃Ｂ」であるとす
る。これは、ＦＡＮＰイーサスイッチ５００３と次段の
ＦＡＮＰノードであるＦＡＮＰイーサスイッチ５００３
の間に、「＃Ｂ」をＶＣＩとした仮想コネクションが確
立されたことと等価である。これを図４９では、５３０
３と付して示している。
【０３４１】この５３０３を通して、ＦＡＮＰイーサス
イッチ５００３は、ＦＡＮＰのプロポーズメッセージを
送出する（ステップＳ５５１０）。以降の手続きは、第
２の実施形態の場合と同様である。
【０３４２】さて、下流側からのリダイレクトメッセー
ジを受信した（ステップＳ５５１９）ＦＡＮＰイーサス
イッチ５００３は、下流側（この場合、第２のハーフコ
ネクタ５００４）の専用の仮想チャネル（具体的には、
「＃Ｂ」を宛先イーサネットアドレスとするフレーム）
の使用準備が整ったと判断し、ＦＡＮＰイーサスイッチ
５００３内のイーサフレームスイッチ及びイーサヘッダ
書換え部５１０４にて、イーサネットアドレスが第１の
イーサネットケーブル５０１２側から「＃Ａ」でやって
きたイーサネットフレームを、ＩＰ／ＦＡＮＰ処理部５
１０３における処理無しに、直接データリンクレイヤフ
ォワーディング（イーサネットスイッチング）できるよ
うに、設定を行う。このとき、宛先イーサネットアドレ
スを「＃Ａ」から「＃Ｂ」に変換し、かつ、適切な出力
ポート（本実施形態の場合は、第２のイーサケーブル５
０１３）にスイッチングするように、内部のイーサヘッ
ダ変換テーブルに設定も行う。
【０３４３】これにより、今後第１のイーサネットケー
ブル５０１２から、特定のイーサネットアドレス「＃
Ａ」をつけてやってきたフレームについては、イーサネ
ットヘッダ変換を行った後、直接イーサネットスイッチ
ングで第２のイーサネットケーブル５０１３に、宛先イ
ーサアドレスを「＃Ｂ」に変換した上で送出できること
になり、データフォワーディング処理の大幅な効率化、
及び高速化が図れることになる。また、該処理がＩＰ／
ＦＡＮＰ処理部５１０３での処理が伴わないため、ＩＰ
／ＦＡＮＰ処理部５１０３の負荷の低減と、負荷分散が
同時に図れることになる。
【０３４４】また、イーサネット５０１２、５０１３内
にて仮想コネクションと同様の概念を導入する事が可能
となり、もって、上記データフォワーディングが可能と
なる。
【０３４５】こうして、ＦＡＮＰイーサスイッチ５００
３は、リダイレクトメッセージを上流のＦＡＮＰノード
（この場合、第１のハーフコネクタ５００２）に送出す
る（ステップＳ５５２０）。下流側からのリダイレクト
メッセージのエンド・エンドＡＣＫフラグが立ち上がっ
ているため、ここでもエンド・エンドＡＣＫフラグはＯ
Ｎとしておく。
【０３４６】以降の動作処理は、第２の実施形態と同様
に、送信端末４００１までエンド・エンドＡＣＫのフラ
グが立ったリダイレクトメッセージが送られる（ステッ
プＳ５５２１）。
【０３４７】送信端末５００１は、同期チャネル５３０
１が、最終的に受信端末５００５までデータリンクレイ
ヤのレベルで直結されたことを確認できる。その後、送
信端末５００１は、映像データの送信を同期チャネル５
３０１を通してはじめる（ステップＳ５５２２）。これ
は、５３０２、５３０３、５３０４を通して、受信端末
５００５に、データリンクレイヤ処理のみで、即ち途中
ノードである各ハーフコネクタ５００２、５００４、Ｆ
ＡＮＰイーサスイッチ５００３におけるＩＰ／ＦＡＮＰ
処理部での処理のないまま配送されることが可能とな
り、実時間を確保した映像情報の転送が容易になる。
【０３４８】なお、ここで配送される映像情報は、第２
の実施形態と同様に、映像データをＩＰパケットにカプ
セル化したものであっても良いし、直接映像データを１
３９４の同期チャネル（あるいは宛先イーサネットアド
レスが「＃Ａ」、「＃Ｂ」で示されるイーサネットフレ
ーム）に乗せ込む形でも、どちらでもよい。
【０３４９】また、イーサフレームは、１３９４の同期
チャネルのフレームをそのまま（あるいは適当な処理を
施した後）乗せる形になっていてもよい。
【０３５０】また、ソフトステートの維持のためのリダ
イレクトメッセージ等についても第２の実施形態の場合
と同様である。
【０３５１】さて、この第３の実施形態においても、複
数のハーフコネクタ（５００２、５００４）と、その間
を結ぶイーサネットケーブル（５０１２、５０１３）お
よびＦＡＮＰイーサスイッチ５００３を用いれば、複数
の１３９４バス同士を相互接続し、お互いに通信ができ
るようになる事が分かる。
【０３５２】さらに、例えば、ＦＡＮＰイーサスイッチ
５００３に３つ以上のハーフコネクタを接続することも
可能である。
【０３５３】次に、図５０に、ハーフコネクタとイーサ
ネットケーブルの他の使用形態を示す。図５０に示す１
３９４間相互接続ケーブルの物理形状は、１３９４コネ
クタ５５０１が、比較的短い１３９４専用ケーブル５５
０２に接続されている形で、ハーフコネクタ５５０３に
接続されている。また、ハーフコネクタ５５０３から長
大なイーサネットケーブル５５０４があらかじめつなが
れている。
【０３５４】この部分は、ＵＴＰ５や同軸ケーブルなど
の電気ケーブルにて接続されていてもよいし、プラスチ
ック光ファイバのような光ケーブルにて接続されていて
も良い。ただし、物理レイヤの伝送方式は、イーサネッ
トの標準に従うものとする。
【０３５５】コネクタ５５０５は、該物理レイヤの伝送
方式にあわせたコネクタである。
【０３５６】このようなケーブルを、１３９４コネクタ
５５０１は、接続したい１３９４バスに接続し、コネク
タ５５０５の側にはＦＡＮＰイーサスイッチ５００３に
接続する。ＦＡＮＰイーサスイッチ５００３は、複数の
コネクタの差込口を持っていても良い。
【０３５７】前述のように、ハーフコネクタ５５０３に
は、比較的短い１３９４専用ケーブルを介して、１３９
４コネクタ５５０１が接続されている。このため、ハー
フコネクタ５５０３のための給電は、１３９４コネクタ
５５０１および１３９４ケーブル５５０２を介して行う
ことができる。よって、図５０の系については、特別な
給電を行う必要はない。（ＦＡＮＰイーサスイッチ５０
０３への給電は基本的に必要である）これは、２つの１
３９４バスを相互接続したいユーザの立場から見ると、
これを行うには、単に接続したい１３９４バスに、ケー
ブルの片方の端（５５０１）を接続し、もう片方の端
（５５０５）にＦＡＮＰイーサスイッチ５００３を接続
すれば、基本的に完了であり、接続の利便性を飛躍的に
向上させる事が可能となる。
【０３５８】ハーフコネクタ５５０３からＦＡＮＰイー
サスイッチ５００３へと接続されるケーブルは長大なも
の（具体的には、例えば、数１００ｍ）を選択可能であ
り、お互いに遠く離れた１３９４バス同士を接続すると
いった場合に、非常に有益である。
【０３５９】なお、このような１３９４間相互接続ケー
ブルは、本発明のような１３９４ハーフコネクタ間の接
続については言うにおよばず、一般の１３９４ブリッジ
をハーフブリッジの構成にして、これを実現する場合に
ついても適用できることは明らかである。この場合は、
第２の実施形態と同様にＩＰアドレスのかわりに１３９
４アドレスを用いて、その制御を行えばよい。
【０３６０】第２、第３の実施形態においては、ハーフ
コネクタ間の伝送方式として、イーサネットを用いて説
明してきたが、トークンリングやＦＤＤＩ等のネットワ
ークを用いて、メカニズムを変更することなくこれを実
現することも可能である。
【０３６１】（第４の実施形態）第２の実施形態、ある
いは第３の実施形態においては、ハーフコネクタ間のデ
ータの伝送方式はイーサネットを用いてきた。また、こ
のイーサネット上で、宛先イーサネットアドレスを仮想
コネクション識別子として使用し、次段のＦＡＮＰノー
ドにおけるデータリンクレイヤフォワーディング（デー
タリンクレイヤヘッダのみを参照して、次段のノードへ
のデータフォワーディング／データスイッチングを行う
こと）を行ってきた。
【０３６２】同様の方法を、ハーフコネクタ間のデータ
伝送方式をＡＴＭとしたときにも可能である。ただし、
ここでは、伝送方式がイーサネットの場合に用いてきた
仮想コネクションＩＤとして、宛先イーサネットアドレ
スを用いるのではなく、ＡＴＭのＶＰＩ／ＶＣＩを用い
て、これを行う。
【０３６３】図５１に、図３３に示した第２の実施形態
に係るホームネットワークシステムにおいて、ハーフコ
ネクタ間をＡＴＭ伝送方式にて接続する場合について示
す。また、図５２に、ハーフコネクタ６００２、６００
３の内部構成例を示す。
【０３６４】図５１、図５２において、第２の実施形態
と異なる部分は、ハーフコネクタ６００２、６００３間
の接続をＡＴＭ伝送方式により行っていることにより、
ＶＰＩ／ＶＣＩの値を仮想コネクション識別子として用
いていること、デフォルトＶＣ（用語の意味については
第１の実施形態を参照）として、当初から定義されてお
り、かつ両ハーフコネクタが認識しているＶＰＩ／ＶＣ
Ｉの値が予約されている点、それにＡＴＭケーブルの長
さに制限がない点である。
【０３６５】図５３に、図４５に示した第３の実施形態
に係るホームネットワークシステムにおいて、ハーフコ
ネクタ間をＡＴＭ伝送方式にて接続する場合について示
す。図５３において図４５と異なる部分は、ＦＡＮＰイ
ーサスイッチ５００３に代わり、ＦＡＮＰ−ＡＴＭスイ
ッチ６２０３が配置されている。
【０３６６】図５４に、ＦＡＮＰ−ＡＴＭスイッチ６２
０３の内部構成例を示す。
【０３６７】図５３、図５４におて、第３の実施形態と
異なる部分は、ハーフコネクタ６２０２、６２０３間の
接続をＡＴＭ伝送方式により行っていることにより、Ｖ
ＰＩ／ＶＣＩの値を仮想コネクション識別子として用い
ていること、デフォルトＶＣ（用語の意味については第
１の実施形態を参照）として、当初から定義されてお
り、かつ両ハーフコネクタが認識しているＶＰＩ／ＶＣ
Ｉの値が予約されている点、それにＡＴＭケーブルの長
さに制限がない点である。また、ＦＡＮＰ−ＡＴＭスイ
ッチ６２０３のアーキテクチャがあげられる。
【０３６８】ここでは、デフォルトＶＣは、ＩＰ／ＦＡ
ＮＰ処理部６３０２（図５４参照）にて終端され、ＩＰ
／ＦＡＮＰ処理部６３０２にセルがたどり着く前にＡＴ
Ｍスイッチ６３０３を通過することになる。
【０３６９】よって、両ＡＴＭインタフェース部６３０
１、６３０４間の直結のデータリンクレイヤコネクショ
ン、即ちＡＴＭコネクションを確立するためには、ＩＰ
／ＦＡＮＰ処理部６３０２は、ＡＴＭスイッチ６３０３
内部のヘッダ変換テーブルの値の設定を適切に行い、Ａ
ＴＭケーブル６２１２の、特定のＡＴＭ−ＶＣと、ＡＴ
Ｍケーブル６２１３の特定のＡＴＭ−ＶＣ間をＡＴＭレ
イヤで直結する機能が求められる。
【０３７０】このように、ハーフコネクタ間の接続の実
現は、イーサネット、ＡＴＭ等の伝送方式のみでなく、
一般のコネクションレス、及びコネクションオリエンテ
ッドの伝送方式を包含する。
【０３７１】（第５の実施形態）次に、第５の実施形態
として、以上の実施形態で説明してきた本発明の手法を
「ＭＡＣアドレスによる経路の設定と、帯域の予約」に
用いる場合について以下に説明する。
【０３７２】図５５に、第５の実施形態に係る通信ネッ
トワークシステムの全体構成例を示す。図５５におい
て、このネットワークは、送信端末８００１、第１のコ
ネクタ８００２、第２のコネクタ８００３、第３のコネ
クタ８００４、受信端末８００５、ＡＴＭネットワーク
８０１１、第１のイーサネット８０１２、第２のイーサ
ネット８０１３、１３９４バス８０１４からなる。
【０３７３】ここで、全ての系は第１の実施形態の場合
と同様に、同一の家庭内において、ネットワークを構成
するものであるとする。よって、この系上の端末のう
ち、ＩＰノードであるものは、すべて同一のＩＰサブネ
ットに属するものとする。ここでは、ＩＰサブネットア
ドレスはＮとする。しかし、第２の実施形態の場合と異
なり、第１のイーサネット、第２のイーサネット、１３
９４バス間をそれぞれ接続する２つのコネクタ（第２の
コネクタ８００３、第３のコネクタ８００４）は、それ
ぞれブリッジであるため、必ずしもＩＰアドレスを持っ
ていなくてもよい（ＩＰ処理部がなくてもよい）。
【０３７４】各ノードのＩＰアドレスは、それぞれ送信
端末８００１がＮ．１、第１のハーフコネクタ８００２
がＮ．２、受信端末８００５がＮ．３であるとする。ま
た、これらのノードの１３９４アドレス、及びイーサネ
ットアドレスについても、図５５に示すとおりである。
【０３７５】ここで、１３９４バス８０１４につながる
ノード（第３のコネクタ８００４、受信端末８００５）
にもＭＡＣアドレスが割り当てられている。これには、
いくつかの場合が考えられて、 （１）１３９４バス８０１４がイーサネット等のＩＥＥ
Ｅ８０２系ネットワークのエミュレーションを行ってい
る。
【０３７６】（２）１３９４アドレスの一部の領域を用
いて、ＭＡＣアドレスを表現している。
【０３７７】即ち、本実施形態においては、例えば「Ｅ
ＵＩ６４の値をＭＡＣアドレスにて表現する」等の表現
方法が用いられている。このように、ＭＡＣアドレスを
用いることにより、１３９４バス８０１４上のノードを
一意に識別できるようになっている状況であればよい。
【０３７８】本実施形態における送信端末８００１、第
１のハーフコネクタ８００２、第２のハーフコネクタ８
００３、第３のハーフコネクタ８００４、受信端末４０
０５は、すべて本発明で説明している拡張されたＦＡＮ
Ｐの機能を有しているノードであるが、第１の実施形態
と異なるのは、ＩＰアドレスではなく、ＭＡＣアドレス
においてもその経路設定と、帯域（通信資源）の予約が
行える点である。以下にそれを説明する。
【０３７９】送信端末８００１は、ＡＴＭ網に接続され
ている点以外は、第２の実施形態の送信端末４００１と
同等の機能を有する。よって、詳細な説明は省略する。
【０３８０】第１のコネクタ８００２は、ＡＴＭネット
ワーク８０１１と、第１のイーサネット８０１２とを相
互接続するＦＡＮＰノードである。機能としては、第１
のイーサネット８０１２の方向に対して、ＭＡＣアドレ
ス対応でＦＡＮＰの制御メッセージを送出・受信する点
を除いては、第２の実施形態のハーフコネクタ（４００
２、４００３）と同等の機能を有する。
【０３８１】第２のコネクタ８００３、第３のコネクタ
８００４はそれぞれイーサネット間、イーサネットと１
３９４バス間を相互接続するが、第１のコネクタ８００
２との大きな違いは、これらはＩＰアドレスではなく、
ＭＡＣアドレスで経路の設定や帯域の予約などができる
点である。即ち、第２のコネクタ８００３、第３のコネ
クタ８００４はＭＡＣアドレス対応ＦＡＮＰの中継ノー
ドである。
【０３８２】第２のコネクタ８００３、第３のコネクタ
８００４はそれぞれＭＡＣアドレスの学習機能を有した
ラーニングブリッジである。入力されたフレーム（イー
サフレーム、１３９４非同期フレーム）の入力アドレス
を参照し、これを入力ポートと共に一定時間記憶してお
く機能を有する。
【０３８３】受信端末８００５は、ＩＰ端末でもある。
送信端末８００１とＩＰパケットのやりとりを行った
り、送信端末８００１から配送される映像の受信を行っ
たりする機能を有するが、第２の実施形態の受信端末４
００４との違いは、この端末がＭＡＣアドレス対応ＦＡ
ＮＰの終端機能を有している点である。
【０３８４】図５６に第３のコネクタ８００４の内部構
成例を示す。図５６において、コネクタ８００４は、イ
ーサインタフェース部８１０１、第１のＭＵＸ−ＤＥＭ
ＵＸ８１０２、イーサ・１３９４乗換部８１０３、ＦＡ
ＮＰ処理部８１０４、第２のＭＵＸ−ＤＥＭＵＸ８１０
５、１３９４インタフェース部８１０６からなる。
【０３８５】イーサインタフェース部８１０１は、物理
的に接続されたイーサネットとのインタフェースをとる
部分であり、第１のＭＵＸ−ＤＥＭＵＸ８１０２とやり
とりするデータと、イーサネットフレームとのカプセル
化、デカプセル化を行う。
【０３８６】第１のＭＵＸ−ＤＥＭＵＸ８１０２は、受
信したイーサフレームのプロトコル種別のフィールドを
参照し、それがＦＡＮＰのフレームであることが記載さ
れていたならば、このフレームをＦＡＮＰ処理部８１０
４に転送し、それ以外の場合はイーサ・１３９４乗換部
８１０３に転送する機能を有する。
【０３８７】ＦＡＮＰ処理部８１０４は、受信したＦＡ
ＮＰパケットについて、イーサ・１３９４乗せ換え部８
１０３内のＭＡＣアドレスとその出力ポートの間の対応
テーブルを参照して、ＭＡＣアドレスに基づくルーチン
グ、ＦＡＮＰ処理等を行う機能を持つ。
【０３８８】イーサ・１３９４乗せ換え部８１０４は、
１３９４側から受信したデータ、特に同期チャネルを通
して受信したデータを、その同期チャネル番号をキーと
して、特定のイーサネットのヘッダを付与した後に、こ
れをイーサネット側に送出する機能と、逆にイーサネッ
ト側から受信したデータを、そのヘッダ情報をキーとし
て、１３９４側の特定の同期チャネルに送出する機能、
それにラーニングブリッジとして、フレームの宛先アド
レス（ＭＡＣアドレス）の値に従って、内部のＭＡＣア
ドレスと出力ポートの対応テーブルを常時更新しなが
ら、これらをフォワーディングする機能を有する。即
ち、この処理部におけるデータのフォワーディングはデ
ータリンクレイヤ処理のみで行われる。また、ここでで
きる対応テーブルは、図３５、図３６と全く同様のもの
になる。
【０３８９】１３９４インタフェース部８１０６は、接
続された１３９４バス８０１４について、１３９４の物
理レイヤ処理、リンクレイヤ処理、バス管理及びトラン
ザクションレイヤ処理をそれぞれ行い、送受信する１３
９４フレームを、第２のＭＵＸ−ＤＥＭＵＸ８１０５を
通して、ＦＡＮＰ処理部８１０４、またはイーサ・１３
９４乗せ換え部８１０４とデータ（１３９４から見る
と、ＰＤＵ）のやりとりを行う。
【０３９０】なお、第２のＭＵＸ−ＤＥＭＵＸ８１０５
は、１３９４インタフェース部８１０６から受信した１
３９４フレームに、それがＦＡＮＰフレームである旨の
情報が記載されていたならば、これをＦＡＮＰ処理部８
１０４に転送する機能がある。
【０３９１】次に、送信端末８００１から受信端末８０
０５にむけて、映像を送信する場合について図５７を参
照しながら説明する。
【０３９２】まず、送信端末８００１は、受信端末８０
０５のＩＰアドレスから、そのデータリンクレイヤアド
レスを知るために、アドレス解決を行うべく、ＡＲＰ要
求パケットをＡＴＭネットワークに送出する。このＡＲ
Ｐ要求はＡＴＭネットワーク内のＡＴＭ−ＡＲＰとして
処理される（ステップＳ５７０１）。
【０３９３】このＡＲＰ要求は、第１のコネクタ８００
２により第１のイーサネット８０１２にフォワードされ
る。第１のイーサネット８０１２、第２のイーサネット
８０１３、１３９４バス８０１４は、それぞれブリッジ
接続されているため、このＡＲＰ要求はブリッジ接続さ
れたこれらネットワーク内をブロードキャストされ、受
信端末８００５に直接到達する（ステップＳ５７０
２）。
【０３９４】受信端末８００５は、ＡＲＰ応答を直接第
１のコネクタ８００２に行い、第１のコネクタ８００２
は、送信端末８００１に代理ＡＲＰ応答を行う。この
時、第１のコネクタ８００２は受信端末８００５が第１
のイーサネット８０１２の側にいることを記憶する（ス
テップＳ５７０３、ステップＳ５７０４）。
【０３９５】さて、次に送信端末８００１は、自分がＦ
ＡＮＰノードであることを認識しており、更にこれから
受信端末８００５に対して送信するのが映像であること
を認識している。よって、これから送出する映像を途中
のＦＡＮＰノードにおいて、ＩＰ処理を伴わずにデータ
リンク処理のみでフォワードしてもらうことを意図して
いる。このため、送信端末８００１は、受信端末８００
４との間で、ＩＰパケットによる初期設定や符号化方式
の確認、映像受付能力の可否などを確認した上で、映像
送出の準備にはいる。
【０３９６】まず、送信端末８００１は、ＡＴＭシグナ
リングを行い、適当なＶＣを取得する（ステップＳ５７
０５）。そして、そのＶＣを通して、第１のコネクタ８
００２に対して、ＦＡＮＰのやり取りを行う。やり取り
については、第１の実施形態と同様である（ステップＳ
５７０６〜ステップＳ５７０９）。
【０３９７】さて、第１のコネクタ８００２は、プロポ
ーズメッセージには、宛先となるＩＰアドレスとＭＡＣ
アドレスの両方が記述されている（ステップＳ５７１
０）。
【０３９８】受信ＦＡＮＰノードである第２のコネクタ
８００３は、ＭＡＣアドレスのみに対応するＦＡＮＰノ
ードであるので、このＭＡＣアドレスのフィールドのみ
を参照する。そして、自分がＭＡＣアドレスのみに対応
するＦＡＮＰノードであることを知らせるため、プロポ
ーズＡＣＫメッセージをＭＡＣアドレスのみを記述して
第１のコネクタ８００２に送り返す（ステップＳ５７１
１）。
【０３９９】これを受信した第１のコネクタ８００２
は、下流側のＦＡＮＰノードがＭＡＣアドレスによるＦ
ＡＮＰを希望していることを知ることができる。そこ
で、第１のコネクタ８００２は宛先ＭＡＣアドレスを含
んだオファーメッセージを隣接ＦＡＮＰノードである第
２のコネクタ８００３に送出する。これは、オファーメ
ッセージの宛先ＭＡＣアドレスを受信端末８００５のＭ
ＡＣアドレスにして、これを行ってもよいし、ＦＡＮＰ
メッセージに、新たなオプションフィールドを設けてこ
れを行ってもよい（ステップＳ５７１２）。
【０４００】第２のコネクタ８００３による、ＦＡＮＰ
メッセージのＦＡＮＰ処理部への取り込みは、イーサネ
ットフレームのプロトコル種別のフィールドを参照する
ことにより行う。
【０４０１】このようにして、順次受信端末８００５ま
でＦＡＮＰ処理を行っていき、順にリダイレクトメッセ
ージを逆方向に送信することで、おのおののコネクタで
の設定が完了していく。最後にリダイレクトメッセージ
を受信した送信端末８００１は、このＶＣを通して、映
像データの送信を開始する。上記の手続きにより、途中
経路における通信資源の確保が第１〜第４の実施形態の
場合と同様に行われることから通信品質を保証する形で
の映像データ配信が可能になることがわかる。
【０４０２】ここで、第１のイーサネット８０１２、第
２のイーサネット８０１３において、映像専用のＭＡＣ
アドレスを第２の実施形態のように取得してもよいが、
本来のＭＡＣアドレス（この場合Ｍ．２）をつかって、
そのまま帯域予約を行ってもよい。この場合、第１のイ
ーサネット８０１２、第２のイーサネット８０１３にお
いては、受信端末８００５宛のＭＡＣアドレスが、イー
サフレームの宛先フィールドに記載されているものにつ
いては、すべて途中のブリッジ（第２のコネクタ８００
３、第３のコネクタ８００４）において要求した通信品
質が保証されたものになっている。すなわち、本発明で
は、単純なブリッジ接続型のネットワークにおいても、
宛先ＭＡＣアドレス毎に、必要な通信品質の予約等がで
きるメカニズムになっている。また、このメカニズム
は、ブリッジとルータ、あるいは、ＩＰアドレス対応の
ＦＡＮＰノード等が混在した環境（第１の実施形態や、
第５の実施形態のような環境）において、エンド−エン
ドに経路の制御と通信品質の予約、それに対応するデー
タリンクレイヤの制御とその接続を行うことができる点
で、より柔軟なものである。
【０４０３】以上、５つの実施形態を示してきたが、こ
れらは、主にＩＰアドレスによる制御である。しかし、
本発明は、Ｅ．１６４やコルバ、あるいは拡張ＯＬＥと
いった、「あらゆるネットワークを束ねることのできる
アドレス体系」について拡張可能である事は明らかであ
る。
【０４０４】また、ここまでの説明は現行のインターネ
ット（即ちＩＰｖ４）を念頭に行ってきたが、次世代の
インターネット（ＩＰｖ６）においても、同様の運用が
可能であることは言うまでもない。
【０４０５】
【発明の効果】以上説明したように、本発明の通信端末
装置、中継装置、ＩＥＥＥ１３９４間接続ケーブルを接
続してネットワークを構成することにより、１３９４バ
スを含んだ家庭ネットワークの大規模化、及び多様化
（種々のネットワークを使用）が可能となる。また、こ
れらの方式は、公衆網、インターネットとも親和性が良
い。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係る通信ネットワー
クの構成例を概略的に示した図。
【図２】ＩＰサブネットＮａ側のＩＰアドレスとデータ
リンクレイヤアドレス（ＡＴＭアドレス）の対応例を示
した図。
【図３】ＩＰサブネットＮｂ側のＩＰアドレスとデータ
リンクレイヤアドレス（ＡＴＭアドレス）の対応例を示
した図。
【図４】案内サーバと映像端末間のシーケンスを説明す
るための図。
【図５】局内ＡＴＭバックボーン網内のデフォルトＶＣ
を概略的に示した図。
【図６】セルスイッチルータの構成例を示した図。
【図７】セルスイッチルータと映像端末間のアドレス解
決のシーケンスを説明するための図。
【図８】セルスイッチルータと映像端末間のアドレス解
決の他のシーケンスを説明するための図。
【図９】ＡＲＰパケットの受渡しに用いられるチャンネ
ルの一例を示した図。
【図１０】ＮＩＵ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃ
ｅ Ｕｎｉｔ）の構成例を示した図。
【図１１】ＦＡＮＰノードに具備されるルーチングテー
ブルの一例を示した図。
【図１２】ＡＲＰ処理シーケンスを説明するためのフロ
ーチャート。
【図１３】１３９４バス上のＡＲＰ要求パケットのフォ
ーマットの一例を示した図。
【図１４】１３９４コネクタの構成例を示した図。
【図１５】１３９４バス上のＡＲＰ応答パケットのフォ
ーマットの一例を示した図。
【図１６】１３９４バス上に送出されるＩＰパケットの
フォーマットの一例を示した図。
【図１７】ビデオサーバから映像端末への映像送信のシ
ーケンスを説明するための図。
【図１８】図１７のシーケンスをより詳細に示した図。
【図１９】１３９４コネクタの１３９４スイッチ部に具
備される対応テーブルの一例を示した図。
【図２０】ＶＣＩＤ交換メッセージのフォーマットの一
例を示した図。
【図２１】ビデオサーバと映像端末間のデフォルトデー
タコネクション（ＶＣ）と専用データコネクションの一
例を示した図。
【図２２】案内サーバとセルスイッチルータ間のＦＡＮ
Ｐメッセージの交換の際のシーケンスを説明するための
図。
【図２３】フロー交換メッセージのフォーマットの一例
を示した図。
【図２４】フロー交換メッセージ（オファーメッセー
ジ）の一例を示した図。
【図２５】フロー交換メッセージ（ペンディングメッセ
ージ）の一例を示した図。
【図２６】１３９４バス上のＶＣＩＤ交換メッセージの
一例を示した図。
【図２７】１３９４バス上のフロー交換メッセージ（リ
ダイレクトメッセージ）の一例を示した図。
【図２８】ビデオサーバから映像端末へのデータリンク
コネクションの一例を示した図。
【図２９】データリンクコネクションの開放シーケンス
を説明するための図。
【図３０】データリンクコネクションの維持と開放をソ
フトステートにて行う場合のシーケンスを説明するため
の図。
【図３１】２つ以上のソースからの情報データのフロー
を同一のデータリンクコネクションにマージする場合の
フローＩＤの使用方法を説明するための図。
【図３２】セルスイッチルータから映像端末の間の帯域
の予約制御を拡張されたＦＡＮＰにより行う場合のシー
ケンスを説明するための図。
【図３３】本発明の第２の実施形態に係る通信ネットワ
ークの構成例を概略的に示した図。
【図３４】ハーフコネクタの構成例を示した図。
【図３５】ハーフコネクタの１３９４・イーサ乗せ換え
部に具備される（１３９４側から受信したデータをイー
サネット側へ送出する場合の）対応テーブルの一例を示
した図。
【図３６】ハーフコネクタの１３９４・イーサ乗せ換え
部に具備される（イーサネット側から受信したデータを
１３９４側へ送出する場合の）対応テーブルの一例を示
した図。
【図３７】ＡＲＰのシーケンスを説明するための図。
【図３８】映像伝送までのシーケンスを詳細に説明する
たの図。
【図３９】送信端末から受信端末までの映像の通信経路
の一例を示した図。
【図４０】１３９４間相互接続ケーブルの物理形状の一
例を示した図で、２つのハーフコネクタ間に接続される
ケーブルがイーサネットケーブルの場合を示したもので
ある。
【図４１】１３９４間相互接続ケーブルの物理形状の他
の例を示した図で、２つのハーフコネクタ間を無線伝送
路にて接続する場合を示したものである。
【図４２】送信端末がデジタル衛星放送（またはデジタ
ルＣＡＴＶ等）からのＭＰＥＧ映像を受信する機能を具
備し、これをＭＰＥＧｏｖｅｒ１３９４のフォーマット
に直して、あるいはＭＰＥＧデコーダにより生の映像デ
ータに変換した後、受信端末へ送信する場合のホームネ
ットワークの構成例を示した図。
【図４３】図４２の送信端末の構成例を示した図。
【図４４】図４２の送信端末の他の構成例を示した図。
【図４５】本発明の第３の実施形態に係る通信ネットワ
ークの構成を概略的に示した図。
【図４６】図４５のＦＡＮＰノード装置の構成例を示し
た図。
【図４７】ＡＲＰシーケンスを説明するための図。
【図４８】映像伝送までのシーケンスを詳細に説明する
ための図。
【図４９】送信端末から受信端末までの映像の通信経路
の一例を示した図。
【図５０】１３９４間相互接続ケーブルの物理形状のさ
らに他の例を示した図で、１３９４コネクタが、比較的
短い１３９４専用ケーブルに接続されている形で、ハー
フコネクタに接続され、ハーフコネクタから長大なイー
サネットケーブルがあらかじめつながれている場合を示
している。
【図５１】本発明の第４の実施形態に係る通信ネットワ
ークの構成例を概略的に示した図で、２つのハーフコネ
クタ間をＡＴＭ通信路で接続する場合である。
【図５２】ハーフコネクタの構成例を示した図で、１３
９４とＡＴＭ間の乗せ替えを行うものである。
【図５３】本発明の第４の実施形態に係る通信ネットワ
ークの他の構成例を概略的に示した図で、２つのハーフ
コネクタ間にＦＡＮＰ−ＡＴＭスイッチが接続されてい
る場合である。
【図５４】図５３のＦＡＮＰ−ＡＴＭスイッチの構成例
を示した図。
【図５５】本発明の第５の実施形態に係る通信ネットワ
ークの構成例を概略的に示した図。
【図５６】ハーフコネクタの構成例を示したものでイー
サと１３９４間の乗せ替えを行うものである。
【図５７】第５の実施形態に係る通信ネットワークにお
けるＡＲＰから映像伝送までのシーケンスを説明するた
めの図。
【符号の説明】 １０１…ビデオサーバ（通信端末）、１０２…案内サー
バ（通信端末）、１０３…セルスイッチルータ（中継装
置）、１０４…ＮＩＵ（中継装置）、１０５…１３９４
コネクタ（中継装置）、１０６…映像端末（通信端
末）、４００２…第１のハーフコネクタ（中継装置）、
４００３…第２のハーフコネクタ（中継装置）。
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.6 識別記号 ＦＩ Ｈ０４Ｎ 7/24 Ｈ０４Ｌ 13/00 ３０７Ｚ Ｈ０４Ｑ 3/00 Ｈ０４Ｎ 7/13 Ｚ (72)発明者 釜谷 幸男 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内

Claims (22)

    【特許請求の範囲】
  1. 【請求項１】 １または複数の物理ネットワークを介し
    て相手端末装置へ情報データを送信する際、少なくと
    も、その相手端末装置のＩＰアドレス情報と物理ネット
    ワークに依存するヘッダ若しくはチャネル情報を含む制
    御メッセージを送信する第１の送信手段と、 この第１の送信手段で送信された制御メッセージに呼応
    した、前記相手端末装置までの情報データを送信するた
    めの経路が設定された旨を通知する応答メッセージを受
    信する第１の受信手段と、 この第１の受信手段で前記応答メッセージが受信された
    とき、少なくとも前記ヘッダ若しくはチャネル情報を含
    む情報データを前記ＩＰアドレス情報に対応するプロト
    コルレイヤより上位のレイヤパケットにて前記相手端末
    装置に送信する第２の送信手段と、 を具備したことを特徴とする通信端末装置。
  2. 【請求項２】 １または複数の物理ネットワークを介し
    て相手端末装置へ情報データを送信する際、少なくと
    も、その相手端末装置のＩＰアドレス情報と物理ネット
    ワークに依存するヘッダ若しくはチャネル情報と通信リ
    ソース量を含む制御メッセージを送信する第１の送信手
    段と、 この第１の送信手段で送信された制御メッセージに呼応
    した、前記相手端末装置までの情報データを送信するた
    めの経路が設定された旨を通知する応答メッセージを受
    信する第１の受信手段と、 この第１の受信手段で前記応答メッセージが受信された
    とき、少なくとも前記ヘッダ若しくはチャネル情報を含
    む情報データを前記相手端末装置に送信する第２の送信
    手段と、 を具備したことを特徴とする通信端末装置。
  3. 【請求項３】 デジタル映像およびまたはデジタル音声
    を受信する第２の受信手段をさらに具備し、 前記第２の送信手段は、前記第２の受信手段で受信され
    たデジタル映像およびまたはデジタル音声を所定の物理
    ネットワークの伝送フォーマットに整合して、前記相手
    端末装置に送信することを特徴とする請求項１または請
    求項２記載の通信端末装置。
  4. 【請求項４】 圧縮されたデジタル映像およびまたはデ
    ジタル音声を受信する第２の受信手段をさらに具備し、 前記第２の送信手段は、前記第２の受信手段で受信され
    た圧縮されたデジタル映像およびまたはデジタル音声を
    伸長し、前記相手端末装置に送信することを特徴とする
    請求項１または請求項２記載の通信端末装置。
  5. 【請求項５】 互いにデータリンクレイヤ方式の相異な
    る少なくとも２つの物理ネットワークを接続し、一方の
    物理ネットワークからの受信データを他方の物理ネット
    ワークへ送信する中継装置において、 前記一方の物理ネットワークから、少なくとも、データ
    送信先の端末装置の第１のアドレス情報と前記一方の物
    理ネットワークに依存する第１のヘッダあるいはチャン
    ネル情報を含む第１の制御メッセージを受信する受信手
    段と、 この受信手段で前記第１の制御メッセージを受信したと
    き、少なくとも、前記第１のアドレス情報から求められ
    る前記他方の物理ネットワークに依存する第２のヘッダ
    若しくはチャネル情報と前記第１のアドレス情報を含む
    第２の制御メッセージを前記他方の物理ネットワークに
    送信する第１の送信手段と、 前記受信手段で前記第１の制御メッセージを受信したと
    き、前記第１のヘッダ若しくはチャネル情報と前記第２
    のヘッダ若しくはチャネル情報の対応関係を記憶する記
    憶手段と、 前記一方の物理ネットワークから、前記第１のヘッダ若
    しくはチャネル情報を含むデータを受信したとき、その
    第１のヘッダ若しくはチャネル情報に対応する第２のヘ
    ッダ若しくはチャネル情報を前記記憶手段に記憶された
    対応関係から求め、それを前記受信データに付加して前
    記他方の物理ネットワークに送信する第２の送信手段
    と、 を具備したことを特徴とする中継装置。
  6. 【請求項６】 少なくとも２つの物理ネットワークを接
    続し、一方の物理ネットワークからの受信データを他方
    の物理ネットワークへ送信する中継装置において、 前記一方の物理ネットワークから、少なくとも、データ
    送信先の端末装置の第１のアドレス情報と、前記一方の
    物理ネットワークに依存する第１のヘッダ若しくはチャ
    ネル情報を含む第１の制御メッセージを受信する受信手
    段と、 この受信手段で前記第１の制御メッセージを受信したと
    き、少なくとも、前記第１のアドレス情報から求められ
    る前記他方の物理ネットワークに依存する第２のヘッダ
    若しくはチャネル情報と前記第１のアドレス情報を含む
    第２の制御メッセージを前記他方の物理ネットワークに
    送信する第１の送信手段と、 前記受信手段で前記第１の制御メッセージを受信したと
    き、前記第１のヘッダ若しくはチャネル情報と前記第２
    のヘッダ若しくはチャネル情報の対応関係を記憶する記
    憶手段と、 前記一方の物理ネットワークから、前記第１のヘッダ若
    しくはチャネル情報を含むデータを受信したとき、その
    第１のヘッダ若しくはチャネル情報に対応する第２のヘ
    ッダ若しくはチャネル情報を前記記憶手段に記憶された
    対応関係をから求め、それを前記受信データに付加して
    前記他方の物理ネットワークに送信する第２の送信手段
    と、 前記第２の送信手段で送信されるデータの伝送フォーマ
    ットを前記一方の物理ネットワークの伝送フォーマット
    から前記他方の物理ネットワークの伝送フォーマットに
    変換する変換手段と、 を具備したことを特徴とする中継装置。
  7. 【請求項７】 前記変換手段は、前記第２の送信手段に
    て送信されるＭＰＥＧデータの伝送フォーマットを、前
    記一方の物理ネットワークのＭＰＥＧデータの伝送フォ
    ーマットから前記他方の物理ネットワークのＭＰＥＧデ
    ータの伝送フォーマットに変換することを特徴とする請
    求項６記載の中継装置。
  8. 【請求項８】 少なくとも２つの物理ネットワークを接
    続し、一方の物理ネットワークからの受信データを他方
    の物理ネットワークへ送信する中継装置において、 前記一方の物理ネットワークから、少なくとも、データ
    送信先の端末装置のＩＰアドレス情報と、前記一方の物
    理ネットワークに依存する第１のヘッダ若しくはチャネ
    ル情報を含む第１の制御メッセージを受信する受信手段
    と、 この受信手段で前記第１の制御メッセージを受信したと
    き、少なくとも、前記ＩＰアドレス情報から求められる
    前記他方の物理ネットワークに依存する第２のヘッダ若
    しくはチャネル情報と前記ＩＰアドレス情報を含む第２
    の制御メッセージを前記他方の物理ネットワークに送信
    する第１の送信手段と、 前記受信手段で前記第１の制御メッセージを受信したと
    き、前記第１のヘッダ若しくはチャネル情報と前記第２
    のヘッダ若しくはチャネル情報の対応関係を記憶する記
    憶手段と、 前記一方の物理ネットワークから、前記第１のヘッダ若
    しくはチャネル情報を含むデータを受信したとき、その
    第１のヘッダ若しくはチャネル情報に対応する第２のヘ
    ッダ若しくはチャネル情報を前記記憶手段に記憶された
    対応関係をから求め、それを前記受信データに付加して
    前記他方の物理ネットワークに送信する第２の送信手段
    と、 を具備し、前記第１のヘッダ若しくはチャネル情報を含
    むデータは、前記ＩＰレイヤより上位のレイヤパケット
    であることを特徴とする中継装置。
  9. 【請求項９】 第１の物理ネットワークであるＩＥＥＥ
    １３９４バスと、第２の物理ネットワークを接続し、一
    方の物理ネットワークからの受信データを他方の物理ネ
    ットワークへ送信する中継装置において、 前記一方の物理ネットワークから、少なくとも、データ
    送信先の端末装置の第１のアドレス情報と、前記一方の
    物理ネットワークに依存する第１のヘッダ若しくはチャ
    ネル情報を含む第１の制御メッセージを受信する受信手
    段と、 この受信手段で前記第１の制御メッセージを受信したと
    き、少なくとも、前記第１のアドレス情報から求められ
    る前記他方の物理ネットワークに依存する第２のヘッダ
    若しくはチャネル情報と前記第１のアドレス情報を含む
    第２の制御メッセージを前記他方の物理ネットワークに
    送信する第１の送信手段と、 前記受信手段で前記第１の制御メッセージを受信したと
    き、前記第１のヘッダ若しくはチャネル情報と前記第２
    のヘッダ若しくはチャネル情報の対応関係を記憶する記
    憶手段と、 前記一方の物理ネットワークから、前記第１のヘッダ若
    しくはチャネル情報を含むデータを受信したとき、その
    第１のヘッダ若しくはチャネル情報に対応する第２のヘ
    ッダ若しくはチャネル情報を前記記憶手段に記憶された
    対応関係をから求め、それを前記受信データに付加して
    前記他方の物理ネットワークに送信する第２の送信手段
    と、 を具備したことを特徴とする中継装置。
  10. 【請求項１０】 前記第２の物理ネットワークは、ＩＥ
    ＥＥ１３９４バスとは異なる物理ネットワークであるこ
    とを特徴とする請求項９記載の中継装置。
  11. 【請求項１１】 前記ＩＥＥＥ１３９４バスにおいて転
    送されるデータに含まれる前記ヘッダ若しくはチャネル
    情報は、ＩＥＥＥ１３９４バスの同期チャネル番号であ
    ることを特徴とする請求項９の中継装置。
  12. 【請求項１２】 前記一方の物理ネットワークはＩＥＥ
    Ｅ１３９４バスであり、前記第２の物理ネットワークは
    イーサネットまたはトークンリングまたはＦＤＤＩであ
    り、前記第２の物理ネットワークに依存するヘッダ若し
    くはチャネル情報はＭＡＣアドレスであることを特徴と
    する請求項９記載の中継装置。
  13. 【請求項１３】 前記第２の物理ネットワークはＡＴＭ
    ネットワークであり、前記第２の物理ネットワークに依
    存するヘッダ若しくはチャネル情報はＶＰＩ／ＶＣＩで
    あることを特徴とする請求項９記載の中継装置。
  14. 【請求項１４】 前記一方の物理ネットワークはＩＥＥ
    Ｅ１３９４バスであり、前記第２の物理ネットワークは
    無線ネットワークであり、前記第２の物理ネットワーク
    に依存するヘッダ若しくはチャネル情報は無線パケット
    の宛先データリンクレイヤアドレスあるいは仮想識別子
    であることを特徴とする請求項９記載の中継装置。
  15. 【請求項１５】 前記第１のアドレス情報は、ＩＰアド
    レスであることを特徴とする請求項５または請求項６ま
    たは請求項９記載の中継装置。
  16. 【請求項１６】 少なくとも２つの物理ネットワークを
    接続し、一方の物理ネットワークからの受信データを他
    方の物理ネットワークへ送信する中継装置において、 前記一方の物理ネットワークから、少なくとも、データ
    送信先の端末装置の第１のＭＡＣアドレス情報と、前記
    一方の物理ネットワークに依存する第１のヘッダ情報を
    含む第１の制御メッセージを受信する受信手段と、 この受信手段で前記第１の制御メッセージを受信したと
    き、少なくとも、前記第１のＭＡＣアドレス情報から求
    められる前記他方の物理ネットワークに依存する第２の
    ヘッダ情報と前記第１のＭＡＣアドレス情報を含む第２
    の制御メッセージを前記他方の物理ネットワークに送信
    する第１の送信手段と、 前記受信手段で前記第１の制御メッセージを受信したと
    き、前記第１のヘッダ情報と前記第２のヘッダ情報の対
    応関係を記憶する記憶手段と、 前記一方の物理ネットワークから、前記第１のヘッダ情
    報を含むデータを受信したとき、その第１のヘッダ情報
    に対応する第２のヘッダ情報を前記記憶手段に記憶され
    た対応関係をから求め、それを前記受信データに付加し
    て前記他方の物理ネットワークに送信する第２の送信手
    段と、 を具備したことを特徴とする中継装置。
  17. 【請求項１７】 前記第１および第２の制御メッセージ
    は、データパケット転送のために確保すべき通信リソー
    ス量を含み、前記受信手段で前記第１の制御メッセージ
    を受信したとき、前記通信リソース量に基づき前記他方
    の物理ネットワーク上に通信リソースを確保することを
    特徴とする請求項５または請求項６または請求項９また
    は請求項１６記載の中継装置。
  18. 【請求項１８】 前記第１および第２の制御メッセージ
    は、前記データパケットにて転送されるデータの属性情
    報を含むことを特徴とする請求項５または請求項６また
    は請求項９または請求項１６記載の中継装置。
  19. 【請求項１９】 第１のネットワークケーブルと、第１
    の中継装置と、第３のケーブルと、第２の中継装置と、
    第２のネットワークケーブルとがこの順に接続されて構
    成されるネットワーク間接続ケーブルであって、 前記第３のケーブルは、第１およびまたは第２のネット
    ワークケーブルよりも長く、前記第１および第２の中継
    装置は、請求項５記載の中継装置であることを特徴とす
    るネットワーク間接続ケーブル。
  20. 【請求項２０】 前記第１および第２のネットワークケ
    ーブルは、ＩＥＥＥ１３９４バスケーブルであることを
    特徴とする請求項１９記載のネットワーク間接続ケーブ
    ル。
  21. 【請求項２１】 前記第１のネットワークケーブルと前
    記第１の中継装置、前記第１の中継装置と前記第３のケ
    ーブル、前記第３のケーブルと前記第２の中継装置、前
    記第２の中継装置と前記第２のネットワークケーブルの
    うちの少なくとも１組は着脱自在であることを特徴とす
    る請求項１９記載のネットワーク間接続ケーブル。
  22. 【請求項２２】 前記第１および第２の中継装置は、第
    １のネットワークケーブル、第２のネットワークケーブ
    ルからそれぞれ電力供給を受けることを特徴とする請求
    項１９記載のネットワーク間接続ケーブル。
JP26449696A 1996-10-04 1996-10-04 通信端末装置及び中継装置 Expired - Fee Related JP3719789B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP26449696A JP3719789B2 (ja) 1996-10-04 1996-10-04 通信端末装置及び中継装置
EP19970117278 EP0835037A3 (en) 1996-10-04 1997-10-06 Data transmitting node, and network inter-connection node suitable for home network environment
US09/036,197 US6751221B1 (en) 1996-10-04 1998-03-06 Data transmitting node and network inter-connection node suitable for home network environment
US10/830,020 US7466705B2 (en) 1996-10-04 2004-04-23 Data transmitting node and network inter-connection node suitable for home network environment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP26449696A JP3719789B2 (ja) 1996-10-04 1996-10-04 通信端末装置及び中継装置

Publications (2)

Publication Number Publication Date
JPH10112730A true JPH10112730A (ja) 1998-04-28
JP3719789B2 JP3719789B2 (ja) 2005-11-24

Family

ID=17404054

Family Applications (1)

Application Number Title Priority Date Filing Date
JP26449696A Expired - Fee Related JP3719789B2 (ja) 1996-10-04 1996-10-04 通信端末装置及び中継装置

Country Status (2)

Country Link
EP (1) EP0835037A3 (ja)
JP (1) JP3719789B2 (ja)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999059302A1 (fr) * 1998-05-12 1999-11-18 Sony Corporation Procede et appareil d'emission, de reception et d'emission/reception de donnees, et support d'enregistrement
WO1999063717A1 (fr) * 1998-05-29 1999-12-09 Sony Corporation Procede et appareil pour relayer des donnees, systeme de communication et support d'enregistrement
JPH11341040A (ja) * 1998-05-26 1999-12-10 Toshiba Corp サービス提供方法および通信装置
JP2000358061A (ja) * 1999-04-29 2000-12-26 Mitsubishi Electric Inf Technol Center America Inc 外部ネットワークと内部ネットワークの間でデータをフォーマットし、かつルーティングする方法、およびその方法を行わせる１つまたは複数の命令シーケンスを格納したコンピュータ読み取り可能な記録媒体
JP2001223733A (ja) * 1999-12-30 2001-08-17 Sony Internatl Europ Gmbh インターフェースリンク層装置及び分散ネットワーク
JP2002542665A (ja) * 1999-04-12 2002-12-10 インテル・コーポレーション １つまたは複数の１３９４バスを有するネットワークにおける同報通信ディスカバリー
US6542506B1 (en) 1998-08-17 2003-04-01 Samsung Electronics Co., Ltd. Method of transferring data between networks
JP2008228303A (ja) * 2007-03-09 2008-09-25 Ntt Docomo Inc ＱｏＳリソースを確保し、マルチキャストネットワークリソースを設定する方法および装置
CN100423509C (zh) * 2001-10-22 2008-10-01 松下电器产业株式会社 数据流选择输出装置和数据流选择输出方法
WO2013113238A1 (zh) * 2012-02-01 2013-08-08 华为技术有限公司 增强VoIP数据上行覆盖的方法、终端及基站
JP2015162907A (ja) * 2014-02-26 2015-09-07 住友電気工業株式会社 電力計測装置、端末装置、電力計測システム、通信制御方法および通信制御プログラム

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6032261A (en) * 1997-12-30 2000-02-29 Philips Electronics North America Corp. Bus bridge with distribution of a common cycle clock to all bridge portals to provide synchronization of local buses, and method of operation thereof
WO1999055051A1 (en) * 1998-04-17 1999-10-28 Koninklijke Kpn N.V. Multimedia subscriber network
EP0951157A1 (en) * 1998-04-17 1999-10-20 Koninklijke KPN N.V. Multimedia subscriber network
KR100385967B1 (ko) * 1998-05-23 2003-07-16 삼성전자주식회사 네트웍상에서의서버기기접속방법
WO2000011840A2 (en) * 1998-08-25 2000-03-02 Mitsubishi Electric Corporation Home gateway
KR100335432B1 (ko) 1998-11-18 2002-06-20 윤종용 Ieee 1394 등시성 데이타의 외부 동기 네트워크로의 전송시에 채널 재배열 방법 및 그 장치
GB9921049D0 (en) * 1999-09-07 1999-11-10 Koninkl Philips Electronics Nv Clustered networked devices
FR2804812A1 (fr) 2000-02-08 2001-08-10 Canon Kk Procede et dispositif de communication entre un premier et un deuxieme reseau
FI110151B (fi) * 2000-11-14 2002-11-29 Nokia Corp Menetelmä pakettien siirtämiseksi piirikytkentäisen verkon yli
KR20020079785A (ko) * 2000-12-27 2002-10-19 마쯔시다덴기산교 가부시키가이샤 홈버스 시스템에서의 라우팅 처리 및 방법
US7212511B2 (en) 2001-04-06 2007-05-01 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for VoIP wireless terminals
GB2375264B (en) 2001-05-02 2004-10-13 Mitel Knowledge Corp Remote assembly of messages for distributed applications
DE10160844B4 (de) * 2001-12-12 2005-07-07 Grundig Multimedia B.V. System zur Übertragung eines Datenstroms über ein Netzwerk an unterschiedliche Netzwerkprotokolle unterstützende Empfänger
CA2494093A1 (en) * 2002-08-01 2004-02-12 General Instrument Corporation Method and apparatus for integrating non-ip and ip traffic on a home network
US7970863B1 (en) 2003-12-29 2011-06-28 AOL, Inc. Using a home-networking gateway to manage communications
JP2009278288A (ja) * 2008-05-13 2009-11-26 Funai Electric Co Ltd ネットワーク機器

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999059302A1 (fr) * 1998-05-12 1999-11-18 Sony Corporation Procede et appareil d'emission, de reception et d'emission/reception de donnees, et support d'enregistrement
JPH11341040A (ja) * 1998-05-26 1999-12-10 Toshiba Corp サービス提供方法および通信装置
WO1999063717A1 (fr) * 1998-05-29 1999-12-09 Sony Corporation Procede et appareil pour relayer des donnees, systeme de communication et support d'enregistrement
US6542506B1 (en) 1998-08-17 2003-04-01 Samsung Electronics Co., Ltd. Method of transferring data between networks
JP2002542665A (ja) * 1999-04-12 2002-12-10 インテル・コーポレーション １つまたは複数の１３９４バスを有するネットワークにおける同報通信ディスカバリー
JP2000358061A (ja) * 1999-04-29 2000-12-26 Mitsubishi Electric Inf Technol Center America Inc 外部ネットワークと内部ネットワークの間でデータをフォーマットし、かつルーティングする方法、およびその方法を行わせる１つまたは複数の命令シーケンスを格納したコンピュータ読み取り可能な記録媒体
JP2001223733A (ja) * 1999-12-30 2001-08-17 Sony Internatl Europ Gmbh インターフェースリンク層装置及び分散ネットワーク
CN100423509C (zh) * 2001-10-22 2008-10-01 松下电器产业株式会社 数据流选择输出装置和数据流选择输出方法
JP2008228303A (ja) * 2007-03-09 2008-09-25 Ntt Docomo Inc ＱｏＳリソースを確保し、マルチキャストネットワークリソースを設定する方法および装置
JP4567758B2 (ja) * 2007-03-09 2010-10-20 株式会社エヌ・ティ・ティ・ドコモ ＱｏＳリソースを確保し、マルチキャストネットワークリソースを設定する方法および装置
WO2013113238A1 (zh) * 2012-02-01 2013-08-08 华为技术有限公司 增强VoIP数据上行覆盖的方法、终端及基站
JP2015162907A (ja) * 2014-02-26 2015-09-07 住友電気工業株式会社 電力計測装置、端末装置、電力計測システム、通信制御方法および通信制御プログラム

Also Published As

Publication number Publication date
JP3719789B2 (ja) 2005-11-24
EP0835037A3 (en) 2008-03-12
EP0835037A2 (en) 1998-04-08

Similar Documents

Publication Publication Date Title
JP3719789B2 (ja) 通信端末装置及び中継装置
JP3660443B2 (ja) データ転送制御システム及び中継装置
US6751218B1 (en) Method and system for ATM-coupled multicast service over IP networks
US6751221B1 (en) Data transmitting node and network inter-connection node suitable for home network environment
CA2155768C (en) Methods and systems for interprocess communication and inter-network data transfer
US6496479B1 (en) Network resource reservation control method and apparatus, receiving terminal, sending terminal, and relay apparatus
JP2001502509A (ja) 優先順位付けされたパケットの送信用ａｔｍセルを用いたケーブルネットワーク
US7383341B1 (en) Data transfer control device, relay device and control device suitable for home network environment
JPH11103298A (ja) パケット伝送制御方法および装置
JP3677153B2 (ja) 蓄積装置
US20010028648A1 (en) Label request packet transmission method, packet transfer network and method thereof, and packet transfer device
JP3519628B2 (ja) 中継装置
JPH10308758A (ja) 通信装置
KR100610522B1 (ko) 다른 전송 특성들을 사용하는 통신 네트워크
JP4327746B2 (ja) 中継装置
JP3531412B2 (ja) マルチキャスト通信システムおよびａｔｍセル化装置
JP2002537726A (ja) Ａｔｍノードの内部制御経路の確立
JPH10308764A (ja) ネットワーク間接続装置および通信装置および通信方法
KR20010022374A (ko) 중계 장치 및 방법, 통신 시스템, 및 기록 매체
JP3098183B2 (ja) 通信網の中継経路設定方法及び通信システム並びに通信装置
KR100231697B1 (ko) 단일링에 기반한 댁내망 장치
JP2009135950A (ja) 中継装置
JP2001507915A (ja) ルーティングの柔軟性が改善された通信ネットワーク
KR100264349B1 (ko) 랜 애뮬레이션에서의 비.유.에스 처리 방법
JPH11103294A (ja) パケット伝送制御方法および装置

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20041209

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20041214

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050214

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20050412

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050613

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: 20050830

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20050906

LAPS Cancellation because of no payment of annual fees