[go: up one dir, main page]

JP3719789B2 - 通信端末装置及び中継装置 - Google Patents

通信端末装置及び中継装置 Download PDF

Info

Publication number
JP3719789B2
JP3719789B2 JP26449696A JP26449696A JP3719789B2 JP 3719789 B2 JP3719789 B2 JP 3719789B2 JP 26449696 A JP26449696 A JP 26449696A JP 26449696 A JP26449696 A JP 26449696A JP 3719789 B2 JP3719789 B2 JP 3719789B2
Authority
JP
Japan
Prior art keywords
address
data
fanp
information
physical 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.)
Expired - Fee Related
Application number
JP26449696A
Other languages
English (en)
Other versions
JPH10112730A (ja
Inventor
健 斉藤
由彰 高畠
幹生 橋本
幸男 釜谷
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

Images

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)
  • Automation & Control Theory (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

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

Claims (11)

  1. 第１の物理ネットワークと第２の物理ネットワークを含む複数の物理ネットワークを介して前記第２のネットワークに接続された相手端末装置へ映像データを送信する前記第１の物理ネットワークに接続された通信端末装置であって、
    少なくとも、前記第１の物理ネットワークに依存するヘッダ情報若しくはチャネル情報、前記相手端末装置へ送信する情報データを識別するための前記相手端末装置のアドレスを含むフローＩＤ及び帯域情報を含む制御メッセージを送信する第１の送信手段と、
    この第１の送信手段で送信された制御メッセージに呼応した、前記フローＩＤに対応する前記相手端末装置までの経路が設定された旨を通知する応答メッセージを受信する第１の受信手段と、
    この第１の受信手段で前記応答メッセージが受信されたとき、少なくとも前記ヘッダ情報若しくはチャネル情報と、前記フローＩＤとを含む前記情報データを前記相手端末装置に送信する第２の送信手段と、
    を具備したことを特徴とする通信端末装置。
  2. 圧縮されたデジタル映像データおよびまたはデジタル音声データを受信する第２の受信手段と、
    前記第２の受信手段で受信された圧縮されたデジタル映像データおよびまたはデジタル音声データを伸長する伸長手段とをさらに具備し、
    前記第２の送信手段は、前記伸長手段で伸長されたデジタル映像データ及びまたはデジタル音声データと、前記ヘッダ情報若しくはチャネル情報と、前記フローＩＤとを含む前記情報データを前記相手端末装置に送信することを特徴とする請求項１記載の通信端末装置。
  3. 第１の物理ネットワークと第２の物理ネットワークに接続し、前記第１の物理ネットワークから送信されるデータパケットを受信して、前記第２の物理ネットワークへ送信する中継装置において、
    前記第１の物理ネットワークから、少なくとも、前記第１の物理ネットワークに依存する第１のヘッダ情報若しくはチャネル情報と、受信端末へ送信されるデータパケット群を識別するための前記受信端末のアドレス情報を含むフローＩＤとを含む第１の制御メッセージを受信する第１の受信手段と、
    この第１の受信手段で前記第１の制御メッセージを受信したとき、前記アドレス情報から求められる前記第２の物理ネットワーク上の前記データパケット群の送信先に、前記フローＩＤを含む第２の制御メッセージを送信する第１の送信手段と、
    前記第１の送信手段で送信された第２の制御メッセージに呼応した、前記フローＩＤに対応する前記受信装置までの経路が設定された旨を通知する応答メッセージを前記第２の物理ネットワークから受信する第２の受信手段と、
    受信された前記応答メッセージを前記第１の物理ネットワークへ送信する第２の送信手段と、
    前記第１の物理ネットワークから、前記第１のヘッダ若しくはチャネル情報と、前記フローＩＤとを含むデータパケットを受信し、前記フローＩＤに対応するデータパケット群を送信する際に用いられる第２のヘッダ情報若しくはチャネル情報を当該データパケットに付加して前記第２の物理ネットワークへ送信する転送手段と、
    を具備したことを特徴とする中継装置。
  4. 前記第１の物理ネットワークは、ＩＥＥＥ１３９４バスであり、第１のヘッダ情報若しくはチャネル情報は、ＩＥＥＥ１３９４バスの同期チャネル番号であることを特徴とする請求項３記載の中継装置。
  5. 第２のヘッダ情報若しくはチャネル情報は、ＭＡＣ（Media access control）アドレスであることを特徴とする請求項３記載の中継装置。
  6. 前記第１の物理ネットワークはＡＴＭ(Asynchronous Transfer Mode)ネットワークであり、前記第１のヘッダ情報若しくはチャネル情報は、ＶＰＩ(Virtual Path Identifier)／ＶＣＩ(Virtual Channel identifier)であることを特徴とする請求項３記載の中継装置。
  7. 前記第２の物理ネットワークは無線ネットワークであり、前記第２のヘッダ情報若しくはチャネル情報は、無線パケットの宛先データリンクレイヤアドレスあるいは仮想識別子であることを特徴とする請求項３記載の中継装置。
  8. 前記アドレス情報は、ＩＰアドレスであることを特徴とする３記載の中継装置。
  9. 前記のアドレス情報は、ＩＰアドレスであることを特徴とする１記載の通信端末装置。
  10. 前記第１および第２の制御メッセージは、後に前記データパケット群を転送するために確保する必要のある帯域を示す帯域情報を含み、
    前記第１の受信手段で前記第１の制御メッセージを受信したとき、前記帯域情報に基づき前記第２の物理ネットワーク上に前記帯域を確保することを特徴とする請求項３記載の中継装置。
  11. 前記第１および第２の制御メッセージは、前記データパケット群にて転送されるデータの属性情報を含むことを特徴とする請求項３記載の中継装置。
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 JPH10112730A (ja) 1998-04-28
JP3719789B2 true 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)

Families Citing this family (27)

* 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
EP0951157A1 (en) * 1998-04-17 1999-10-20 Koninklijke KPN N.V. Multimedia subscriber network
AU3821899A (en) * 1998-04-17 1999-11-08 Koninklijke Kpn N.V. Multimedia subscriber network
JP4168302B2 (ja) * 1998-05-12 2008-10-22 ソニー株式会社 情報受信装置および方法、並びに記録媒体
KR100385967B1 (ko) * 1998-05-23 2003-07-16 삼성전자주식회사 네트웍상에서의서버기기접속방법
JP3571912B2 (ja) * 1998-05-26 2004-09-29 株式会社東芝 通信装置およびサービス提供方法
WO1999063717A1 (fr) * 1998-05-29 1999-12-09 Sony Corporation Procede et appareil pour relayer des donnees, systeme de communication et support d'enregistrement
KR100311020B1 (ko) 1998-08-17 2001-12-20 윤종용 네트웍간 데이터 전송 방법
US6505255B1 (en) * 1999-04-29 2003-01-07 Mitsubishi Electric Information Technology Center America, Inc. (Ita) Method for formatting and routing data between an external network and an internal network
WO2000011840A2 (en) * 1998-08-25 2000-03-02 Mitsubishi Electric Corporation Home gateway
KR100335432B1 (ko) * 1998-11-18 2002-06-20 윤종용 Ieee 1394 등시성 데이타의 외부 동기 네트워크로의 전송시에 채널 재배열 방법 및 그 장치
US6466549B1 (en) * 1999-04-12 2002-10-15 Intel Corporation Broadcast discovery in a network having one or more 1394 buses
GB9921049D0 (en) 1999-09-07 1999-11-10 Koninkl Philips Electronics Nv Clustered networked devices
DE69940781D1 (de) * 1999-12-30 2009-06-04 Sony Deutschland Gmbh Schnittstellenverbindungsschicht- Einrichtung zum Aufbau eines verteilten Netzwerks
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
CN1437814A (zh) * 2000-12-27 2003-08-20 松下电器产业株式会社 家庭总线系统上的路由处理及方法
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
JP2003204482A (ja) * 2001-10-22 2003-07-18 Matsushita Electric Ind Co Ltd 放送装置
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
WO2004014063A2 (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
EP1968251A1 (en) * 2007-03-09 2008-09-10 NTT DoCoMo, Inc. Method and apparatus for QoS resource reservation and configuration of multicast network resources
JP2009278288A (ja) * 2008-05-13 2009-11-26 Funai Electric Co Ltd ネットワーク機器
CN103248604B (zh) * 2012-02-01 2016-12-21 华为技术有限公司 增强VoIP数据上行覆盖的方法、终端及基站
JP6260346B2 (ja) * 2014-02-26 2018-01-17 住友電気工業株式会社 電力計測装置、端末装置、電力計測システム、通信制御方法および通信制御プログラム

Also Published As

Publication number Publication date
JPH10112730A (ja) 1998-04-28
EP0835037A2 (en) 1998-04-08
EP0835037A3 (en) 2008-03-12

Similar Documents

Publication Publication Date Title
JP3719789B2 (ja) 通信端末装置及び中継装置
JP3660443B2 (ja) データ転送制御システム及び中継装置
US6751221B1 (en) Data transmitting node and network inter-connection node suitable for home network environment
US6751218B1 (en) Method and system for ATM-coupled multicast service over IP networks
CA2155768C (en) Methods and systems for interprocess communication and inter-network data transfer
JP3649367B2 (ja) パケット伝送制御方法および装置
US7383341B1 (en) Data transfer control device, relay device and control device suitable for home network environment
WO1999059295A1 (fr) Dispositif et procede de reception d'information, dispositif de production d'information et systeme de communication d'information
JP3677153B2 (ja) 蓄積装置
JP2001077831A (ja) 通信制御装置および方法、通信システム、並びにプログラム格納媒体
JPH10308758A (ja) 通信装置
JP3519628B2 (ja) 中継装置
JP4409776B2 (ja) Ａｔｍノードの内部制御経路の確立
KR100610522B1 (ko) 다른 전송 특성들을 사용하는 통신 네트워크
JP4327746B2 (ja) 中継装置
JPH10308764A (ja) ネットワーク間接続装置および通信装置および通信方法
US7636375B2 (en) Method for multimedia flow transport
KR20010022374A (ko) 중계 장치 및 방법, 통신 시스템, 및 기록 매체
JP2004531936A (ja) マルチキャスティング実現のためのマルチキャスティング中継方法
US20030200312A1 (en) Communication system with improved access network
KR100264349B1 (ko) 랜 애뮬레이션에서의 비.유.에스 처리 방법
JP3098183B2 (ja) 通信網の中継経路設定方法及び通信システム並びに通信装置
JP2009135950A (ja) 中継装置
JPH11103294A (ja) パケット伝送制御方法および装置
JP3848338B2 (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