JP4963566B2 - 通信装置及びその制御方法 - Google Patents

通信装置及びその制御方法 Download PDF

Info

Publication number
JP4963566B2
JP4963566B2 JP2006128578A JP2006128578A JP4963566B2 JP 4963566 B2 JP4963566 B2 JP 4963566B2 JP 2006128578 A JP2006128578 A JP 2006128578A JP 2006128578 A JP2006128578 A JP 2006128578A JP 4963566 B2 JP4963566 B2 JP 4963566B2
Authority
JP
Japan
Prior art keywords
terminal device
communication
sta
real
header
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
JP2006128578A
Other languages
English (en)
Other versions
JP2007300555A (ja
JP2007300555A5 (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.)
Canon Inc
Original Assignee
Canon Inc
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 Canon Inc filed Critical Canon Inc
Priority to JP2006128578A priority Critical patent/JP4963566B2/ja
Priority to US11/742,767 priority patent/US8081653B2/en
Publication of JP2007300555A publication Critical patent/JP2007300555A/ja
Publication of JP2007300555A5 publication Critical patent/JP2007300555A5/ja
Application granted granted Critical
Publication of JP4963566B2 publication Critical patent/JP4963566B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本発明は、通信装置及びその制御方法に関する。
近年、ＩＰ（Internet Protocol）ネットワークを利用したビデオ会議システムやビデオオンデマンド（ＶｏＤ：Video on Demand）システムのようなストリーム配信システムがある。このストリーム配信システムで、音声や動画像をリアルタイムに再生する場合、パケットの廃棄やデータエラー時に再送制御を行うＴＣＰ（Transport Control Protocol）は、通常リアルタイム性を保つことが困難である。
そこで、ビデオ会議システムやビデオオンデマンドシステムのような複数の通信ノードを想定したシステムでは、ＴＣＰではなくＵＤＰ（User Datagram Protocol）を使用することが多い。しかし、ＵＤＰヘッダには、ＴＣＰヘッダに存在するようなパケットの順番を表すシーケンス番号を格納するフィールドが存在しないため、ネットワークでパケットの順序が変わってしまった場合、その順序を正確に入れ替える制御が困難である。
これを解決するために、ＲＴＰ（Real-time Transport Protocol）がＩＰネットワークにおいてリアルタイムに音声や動画を送受信するためのトランスポートプロトコルとして提案されている。また、ＲＴＣＰ（RTP Control Protocol）がリアルタイムに音声や動画を送受信するための制御プロトコルとして提案されている。
通常、ＲＴＰはＵＤＰ上で用いられるが、データ受信側でパケットの順序訂正が可能となる点、ネットワークでの遅延揺らぎを吸収することができる点などの様々な利点がある。そのため、ＲＴＰは、ビデオ会議システムやビデオオンデマンドシステム等で音声や動画像をリアルタイムに再生する場合の技術として広く知られている。
このように、トランスポート層よりも上層でＱｏＳ（Quality of Service）を確保する技術としては、ＲＴＰ／ＲＴＣＰが一般的であった。
ＱｏＳを確保する技術としてのＲＴＰで、ＭＰＥＧ−ＴＳなどの動画データを伝送する際に使用されるＴＳパケットのタイムスタンプ（ＰＣＲ）と正確に同期したＲＴＰタイムスタンプを付加できるものがある（例えば、特許文献１参照）。
一方、インターネットにおけるＱｏＳの取り組みとして、ストリーム指向のアプリケーションの登場を受けて1989年頃から研究が開始され、以下のような技術の標準化が進められている。
・IntServ（Integrated Service）：IETF（Internet Engineering Task Force）におけるワーキンググループで、アプリケーションフロー毎にＱｏＳ制御を行う技術
・RSVP（Resource reSerVasion Protocol）：通信系路上の資源を必要に応じて動的に確保する技術
また、IntServとは異なるＱｏＳ技術として、以下のようなものがある。
・DiffServ（Diffrentiated Service）：アプリケーションのパケットを分類しグループ化し、そのグループに対して優先度を定義して優先度に応じたデータ転送を行う技術
・IEEE802.1ｐ準拠のプライオリティタグに基づくIEEE802.1QのVLANタグヘッダを用いた技術。このタグヘッダには、３ビットのユーザプライオリティフィールドが設けられており、このフィールド値により、パケット毎にネットワーク内で取り扱われる優先度が決定する。
また、動画像ストリームデータを無線で伝送するために、無線伝送区間にＱｏＳという概念を導入し、データの内容や用途によって優先順位や通信帯域を保証するべくIEEE802.11eで検討が行われている。このIEEE802.11eでは、無線アクセスポイント経由で行われていた端末局間の相互通信だけではなく、伝送帯域の有効活用を目的とした端末局間の直接通信に関する制御方式を規定している。この直接通信は、ＤＬＳ（Direct Link Setup）という名称で呼ばれている。
特開２００１−３２０４１３号公報
しかしながら、音声や動画像といったリアルタイム性を要求される動画像通信データの入出力機能を備えたデバイスをＩＰネットワーク環境に収容する際に用いられるアダプタ装置では、以下のようにサービス上の不都合が生じる。
デバイス間で送受信される動画像データに対するＱｏＳプロトコル（例えば、ＲＴＰ／ＲＴＣＰ）のサポート状態が把握できないため、送受信データに対して不要なＱｏＳ関連プロトコルを（余計に）付加していた。また、ＱｏＳ関連プロトコルを必要とする際に、例えばデバイスにＱｏＳプロトコルのサポート機能がない場合、ＱｏＳ関連プロトコルを付加していなかった。
本発明は、通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定することで、実時間伝送プロトコルの冗長性を回避することを目的とする。
本発明は、通信装置の制御方法であって、前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定工程と、前記判定工程における判定に応じて、前記端末装置との間で送受信する通信データを変換する変換工程と、を有し、前記判定工程では、前記通信装置に接続される端末装置からの通信の設定メッセージを解析し、当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、前記変換工程では、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする。
また、本発明は、通信装置であって、前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定手段と、前記判定手段による判定に応じて、前記端末装置との間で送受信する通信データを変換する変換手段と、を有し、前記判定手段は、前記通信装置に接続される端末装置からの通信の設定メッセージを解析し、当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、前記変換手段は、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする。
本発明によれば、通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定することで、実時間伝送プロトコルの冗長性を回避することができる。
以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。
まず、無線アダプタ装置（ＳＴＡ）と無線アクセスポイント（ＱＡＰ）とで構成される無線通信システムについて説明する。尚、ＳＴＡとＱＡＰとは、IEEE802.11eで検討中のＱｏＳ機能を有するものとする。また、無線通信はIEEE802.11a/b/g規格の無線ＬＡＮにIEEE802.11eで検討中のＱｏＳ機能を追加したものとする。
［第１の実施形態］
第１の実施形態では、ＳＴＡに接続されるデバイスとの間で実施される設定メッセージを解析し、その結果に応じてＱｏＳ関連プロトコルの処理を制御する。
図１は、第１の実施形態における無線通信システムの構成の一例を示す図である。図１において、１０１〜１０５はそれぞれＳＴＡであり、IEEE1394、ＵＳＢ、又は有線ＬＡＮケーブルを用いて入出力機能を備えたデバイスに接続可能である。１０６はＱＡＰであり、グローバル側はインターネット或いはイントラネットなどのネットワークに接続され、ＳＴＡ１０１〜１０５を無線サービスエリア内に接続収容する。
１０７はチューナー（TUNER）であり、IEEE1394ケーブル１１４を用いてＳＴＡ１０１に接続される。１０８はハードディスクレコーダ（ＨＤＲ）であり、有線ＬＡＮケーブル１１５を用いてＳＴＡ１０２に接続される。１０９はデジタルビデオカメラ（ＤＶＣ）であり、ＵＳＢケーブル１１６を用いてＳＴＡ１０３に接続される。
１１０は液晶テレビ（DISP）であり、IEEE1394ケーブル１１４を用いてＳＴＡ１０４に接続される。１１１はノートパソコン（ＰＣ）１１１であり、有線ＬＡＮケーブル１１５を用いてＳＴＡ１０５に接続される。１１２は放送用信号を受信する放送用受信アンテナである。１１３は分波器であり、放送用受信アンテナ１１２で受信した信号をチューナー１０７とＨＤＲ１０８にそれぞれ分配して送信する。
図１に示す無線通信システムは、ＱＡＰ１０６がＳＴＡ１０１〜１０５からの無線伝送帯域の割り当て要求に対して無線サービスエリア内のＱｏＳを考慮した伝送帯域の割当てに関するスケジューリングを実施する機能を備える。更に、ＳＴＡ１０１〜１０５から所望のＳＴＡとの間で直接的な無線通信路の確立要求を受信した際にＳＴＡ１０１〜１０５間の通信路を確立するダイレクトリンクサービスを実施する機能を備える。
図２は、第１の実施形態における無線アダプタ装置のソフトウェア構成を示す図である。図２において、２０２はＳＴＡ全体を制御するシステム制御部である。２０３は複数の入出力デバイス１０７〜１１１が接続された際に、それぞれのデバイスに応じて使用選択されるアプリケーションプログラムである。２０４はＲＴＰ／ＲＴＣＰのようなセッション層で実現されるＱｏＳプロトコル処理部である。２０５はデータ処理部であり、ＴＣＰ／ＵＤＰ／ＩＰのようなネットワークプロトコルを処理する。２０６は無線ＬＡＮ制御部（ＷＬＡＮ制御部）である。２０７はアンテナであり、ＷＬＡＮ制御部２０６に接続され、他のＳＴＡとの間でデータの送受信を行う。
２０９はIEEE1394制御部であり、例えばIEEE1394ケーブル１１４でチューナー１０７や液晶テレビ１１０が接続される。２１０はＵＳＢ制御部であり、例えばＵＳＢケーブル１１６でＤＶＣ１０９が接続される。２１１は有線ＬＡＮ制御部であり、例えば有線ＬＡＮケーブル１１５でＨＤＲ１０８やノートＰＣ１１１が接続される。
２０８は記憶領域部であり、各ソフト機能ブロック２０２〜２０６、２０９〜２１１によって使用される。また、システム制御部２０２がＳＴＡ全体を制御する際に、各ソフト機能ブロック２０２〜２０６、２０９〜２１１は、プログラムやパラメータとしてＲＯＭに格納される。場合によっては、ＲＯＭから展開されるプログラムやデータを記憶領域部２０８であるＲＡＭに一時記憶する。そして、２０１はＲＯＭ，ＲＡＭ，ＣＰＵをソフト管理するオペレーティングシステム（ＯＳ）である。
次に、ＱＡＰ１０６によるＤＬＳの制御下において送信側デバイスのチューナー１０７からＳＴＡ１０１及びＳＴＡ１０４を介して受信側デバイスの液晶テレビ１１０へ動画をストリーム伝送する際の処理を説明する。
図３は、チューナー１０７から液晶テレビ１１０へ直接動画をストリーム伝送する状態を示す図である。図３に示すように、チューナー１０７はIEEE1394ケーブル１１４を介してＳＴＡ１０１に接続され、液晶テレビ１１０はIEEE1394ケーブル１１４を介してＳＴＡ１０４に接続される。
図４は、図３に示すストリーム伝送で送受信されるメッセージのシーケンスを示す図である。また、図４に示すシーケンス内のメッセージは、第１の実施形態に関する主なもののみを明記し、一部のメッセージは省略している。
図５は、図４に示す送信側ＳＴＡ１０１における送信フレームの処理フローを示す図である。図５に示す例は、チューナー１０７がＱｏＳプロトコル処理をサポートしていない場合である。図５において、５０１はデバイス側のメモリ制御処理であり、チューナー１０７からIEEE1394制御部２０９を介して受信したデータを記憶領域部２０８のデコード用バッファメモリ（Dbuf）に書き込む。５０３はＲＴＰ処理部であり、チューナー１０７がＲＴＰ機能をサポートしていない場合、記憶領域部２０８に書き込み格納されたデータに対してＱｏＳプロトコルであるＲＴＰヘッダを付加する。ここで、設定シーケンスで予め未サポートが判っている場合や、動画像データのＱｏＳプロトコルであるＲＴＰの使用の検出を行い、その結果、未使用である場合を含む。５０４はＵＤＰ処理部であり、トランスポート層プロトコルの処理を行う。５０５はＩＰ処理部であり、ネットワーク層プロトコルの処理を行う。
５０２はネットワーク側のメモリ制御処理であり、ＲＴＰ処理部５０３、ＵＤＰ処理部５０４、ＩＰ処理部５０５を経て付加されたヘッダ部により構成されたデータを記憶領域部２０８の送信用メモリバッファ（mbuf）に書き込む。５０６はIEEE802.3変換処理部であり、送信用メモリバッファの送信データをＷＬＡＮ制御部２０６で送信できるデータに変換する。
５０７はＲＴＰ処理部５０３でＲＴＰヘッダを付加したＲＴＰ送信処理フレームである。５０８はＲＴＰ送信処理フレーム５０７にＵＤＰ処理部５０４でＵＤＰヘッダを付加したＵＤＰ送信処理フレームである。５０９はＵＤＰ送信処理フレーム５０８にＩＰ処理部５０５でＩＰヘッダを付加したＩＰ送信処理フレームである。５１０はＩＰ送信処理フレーム５０９に802.3変換処理部５０６で802.3ヘッダを付加した802.3送信処理フレームである。
図６は、チューナー１０７がＱｏＳプロトコル処理をサポートする場合の送信フレームの処理フローを示す図である。尚、図５と同じものには同一符号を付し、ここでの説明は省略する。図６において、６０１はＵＤＰ処理部５０４でＵＤＰヘッダを付加したＵＤＰ送信処理フレーム（ＵＤＰペイロードにチューナー１０７によるＲＴＰプロトコルを含む）である。６０２はＵＤＰ送信処理フレーム６０１にＩＰ処理部５０５でＩＰヘッダを付加したＩＰ送信処理フレームである。６０３はＩＰ送信処理フレーム６０２に802.3変換処理部５０６で802.3ヘッダを付加した802.3送信処理フレームである。
図７は、図４に示す受信側ＳＴＡ１０４における受信フレームの処理フローを示す図である。図７に示す例は、液晶テレビ１１０がＱｏＳプロトコル処理をサポートしていない場合であり、図５に示す送信フレームに対応するものである。
図７において、７０７はＷＬＡＮ制御部２０６から受信した802.3受信処理フレームである。７０６は802.3変換処理部であり、802.3受信処理フレーム７０７から802.3ヘッダを除去する。７０２はネットワーク側のメモリ制御処理であり、802.3ヘッダが除去された受信処理フレームを記憶領域部２０８の受信用バッファメモリ（mbuf）に書き込む。７０８は受信用バッファメモリに書き込まれたＩＰ受信処理フレームである。７０９はＩＰ受信処理フレーム７０８のＩＰヘッダーをＩＰ処理部７０５で除去したＵＤＰ受信処理フレームである。７１０はＵＤＰ受信処理フレーム７０９のＵＤＰヘッダをＵＤＰ処理部７０４で除去したＲＴＰ受信処理フレームである。
尚、ＲＴＰ受信処理フレームは、デバイス側のメモリ制御処理７０１により、記憶領域部２０８にあるエンコード用バッファメモリ（Ebuf）に書き込まれる。この処理の際に、液晶テレビ１１０がＲＴＰ機能をサポートしていない場合、ＲＴＰ処理部７０３は、記憶領域部２０８に書込み格納されたデータに対してＱｏＳプロトコルであるＲＴＰヘッダを除去する。ここで、設定シーケンスで予め未サポートが判っている場合や、動画像データのＱｏＳプロトコルであるＲＴＰの使用の検出を行い、その結果、未使用である場合を含む。
図８は、液晶テレビ１１０がＱｏＳプロトコル処理をサポートしている場合の受信フレームの処理フローを示す図である。尚、図７と同じものには同一符号を付し、その説明は省略する。図８において、８０１はＷＬＡＮ制御部２０６から受信した802.3受信処理フレームである。８０２は受信用バッファメモリ（mbuf）の802.3受信処理フレーム８０１の802.3ヘッダを802.3変換処理部７０６が除去したＩＰ受信処理フレームである。８０３はＩＰ受信処理フレーム８０２のＩＰヘッダーをＩＰ処理部７０５で除去したＵＤＰ受信処理フレームである。
尚、ＵＤＰ受信処理フレーム８０３は、ＵＤＰペイロードにデバイスによるＲＴＰプロトコルを含み、デバイス側のメモリ制御処理７０１により記憶領域部２０８のエンコード用バッファメモリ（Ebuf）に書き込まれる。この処理の際に、液晶テレビ１１０がＲＴＰ機能をサポートしている場合、ＲＴＰ処理部７０３は記憶領域部２０８に書き込み格納されたデータに対してＱｏＳプロトコル関連の処理を実施しない。ここで、設定シーケンスで予めわかっている場合、ＱｏＳプロトコルであるＲＴＰの使用検出を行い、その結果、デバイスで使用中である場合を含む。
ここで、図９〜図１７を用いて、図４に示すシーケンスに従って動画をストリーム伝送する処理の詳細を説明する。
図９は、第１の実施形態における入出力デバイスの処理を示すフローチャートである。入出力デバイスは、チューナー１０７と液晶テレビ１１０である。図１０は、第１の実施形態における無線アダプタ装置の共通処理を示すフローチャートである。図１１は、第１の実施形態における送信側ＳＴＡ１０１の処理を示すフローチャートである。図１２は、第１の実施形態における受信側ＳＴＡ１０４の処理を示すフローチャートである。図１３及び図１４は、第１の実施形態におけるＱＡＰ１０６の処理を示すフローチャートである。
図１５は、第１の実施形態におけるＲＴＰ処理の実装状態と無線データ形式との関係を示すテーブルである。このテーブルにおいて、「ＲＴＰ機能」は入出力デバイスにおけるＲＴＰプロトコルのサポートである。また、「実装」はＳＴＡ間で送受信するＤＶデータにＲＴＰヘッダを付加することを示し、データ形式は［ＲＴＰ＋ＤＶデータ］と表される。また、「なし」はＲＴＰプロトコルのサポートを実施しないことを示す。
また、「ＲＴＰヘッダー処理」はＳＴＡにおけるＲＴＰプロトコルのサポートを示し、「―」はＲＴＰプロトコルのサポートが無いことを意味する。また、「追加」はデバイスとの間で送受信するＤＶデータにＲＴＰヘッダを付加することを示し、データ形式は（ＲＴＰ）＋［ＤＶデータ］と表される。そして、「削除」はデバイスとの間で送受信するDVデータのＲＴＰヘッダを除去することを示し、データ形式は［ＤＶデータ］となる。
図４に示すシーケンスにおいて、まず送信デバイス側のＳＴＡ１０１がＱＡＰ１０６のサービスエリア内に設置されるか、ＳＴＡ１０１の電源が投入されると、ＱＡＰ１０６との間でアソシエーション処理（Ｍ４０１）を行う。そして、ステップＳ１００１において、ＳＴＡ１０１がアソシエーション処理（Ｍ４０１）を完了するとステップＳ１００２へ進み、ＳＴＡ１０１はチューナー１０７とのIEEE1394接続処理（Ｍ４０３）の完了判定を行う。
一方、送信デバイスであるチューナー１０７では、ＳＴＡ１０１との接続操作、或いはデバイス本体の電源投入などが行われる。そして、ステップＳ９０１で、ＳＴＡ１０１との間でIEEE1394接続シーケンス処理（Ｍ４０３）を完了するとステップＳ９０２へ進み、システム内に収容する全てのＳＴＡの更新情報をＳＴＡ１０１から受信する。
次に、ＳＴＡ１０１がIEEE1394接続シーケンス処理（Ｍ４０３）を完了するとステップＳ１００３へ進み、接続デバイスに関する情報を端末種別情報として種別登録メッセージ（Ｍ４０６）に含めてＱＡＰ１０６に送信する。ここで、接続デバイスに関する情報は、デバイス名称、インターフェース種別「IEEE1394」、転送モード「アイソクロナス」、RTP/RTCPプロトコルのサポート状況「あり」である。そして、ステップＳ１００４において、システム内に収容する全ての端末の更新情報をＱＡＰ１０６から受信するのを待つ。
一方、ＱＡＰ１０６は、ステップＳ１３０１でＳＴＡ１０１との間でアソシエーション処理（Ｍ４０１）が完了するとステップＳ１３０２へ進み、チューナー１０７に関する情報を含む種別登録メッセージ（Ｍ４０６）の受信を待つ。そして、ＳＴＡ１０１から種別登録メッセージ（Ｍ４０６）を受信するとステップＳ１３０３へ進み、端末種別情報を、例えば図１６に示すデバイス管理テーブルの形態でメモリに格納し、ステップＳ１３０４で更新情報があるか否かを判断する。ここで、新規にアソシエーション処理によりＳＴＡが登録される場合、又は以前のデバイスとは異なるデバイスが接続されたことにより該当するＳＴＡからの種別登録メッセージの情報が変化したと判断された場合にはステップＳ１３０５へ進む。ステップＳ１３０５では、例えば図１６に示すデバイス管理テーブルのデバイス情報を最新情報としてＳＴＡ１０１に種別情報メッセージ（Ｍ４０９）を送信し、接続中状態へと遷移する。
一方、ＳＴＡ１０１がＱＡＰ１０６から種別情報メッセージ（Ｍ４０９）を受信するとステップＳ１００５へ進み、例えば図１６に示すデバイス管理テーブルの形態で記憶領域２０８に格納する。そして、ステップＳ１００６でチューナー１０７にシステム端末情報メッセージ（Ｍ４１０）を送信し、接続中状態へと遷移する。
次に、チューナー１０７がＳＴＡ１０１からシステム端末情報メッセージ（Ｍ４１０）を受信するとステップＳ９０３へ進み、通信可能な接続デバイスに関する情報を図１６に示すデバイス管理テーブルの形態で格納する。そして、システム内にあるデバイスの収容状況、性能及び状態をＬＣＤなどの表示部に表示する。ここで、チューナー１０７は、ステップＳ９０４へ進み、接続中状態となる。また、接続デバイスに関する情報は、デバイス名称、インターフェース種別「IEEE1394」、転送モード「アイソクロナス」、RTP/RTCPプロトコルのサポート状況「あり」である。
尚、図４において、受信側のデバイスである液晶テレビ１１０と受信側のＳＴＡ１０４とＱＡＰ１０６との間でも、上述した送信側と同様に処理が行われる。ここでは、送信側のチューナー１０７と受信側の液晶テレビ１１０とで異なる処理について説明する。
まず、ステップＳ９０３で、チューナー１０７はシステム内にあるデバイスの収容状況、性能、及び状態を表示したが、液晶テレビ１１０は、例えばアイコン等を採用し、視覚的に送受信可能なデバイスを認識可能に表示する。つまり、液晶テレビ１１０は大画面の液晶画面の一部、或いは接続デバイス表示専用の画面に切り替え、システム内に接続収容されている送受信可能なデバイスの収容状況、性能、及び状態を表示する。
次に、図４において、液晶テレビ１１０の画面上でチューナー１０７のアイコンが選択されるとステップＳ９０５へ進み、液晶テレビ１１０はチューナー１０７を特定する情報を含む接続要求メッセージ（Ｍ４１１）をＳＴＡ１０４に送信する。
一方、ステップＳ１２０１において、メッセージ受信の待ち状態にあるＳＴＡ１０４が液晶テレビ１１０からメッセージを受信するとステップＳ１２０２へ進む。ここで、受信したメッセージが接続要求メッセージ（Ｍ４１１）か判定し、ＹＥＳの場合はステップＳ１２１１へ進む。ステップＳ１２１１では、ＱＡＰ１０６のダイレクトリンクサービスの制御下において異なるＳＴＡとの直接通信が可能か否かの判断を行い、直接通信が不可能な場合はステップＳ１２１３へ進む。
ステップＳ１２１３では、液晶テレビ１１０に対して通信不可能である旨の情報を含む接続応答メッセージを送信し、ステップＳ１２０１に戻る。また、ステップＳ１２１１で直接通信が可能な場合はステップＳ１２１２へ進み、ＱＡＰ１０６に対してダイレクトリンクサービスの設定要求（ＤＬＳ要求）メッセージ（Ｍ４１２）を送信し、ステップＳ１２０１に戻る。
一方、ステップＳ１４０１でＱＡＰ１０６がＳＴＡ１０４からメッセージを受信するとステップＳ１４０２へ進み、受信メッセージがＤＬＳ要求メッセージ（Ｍ４１２）か否かを判断する。ＹＥＳの場合はステップＳ１４０３へ進み、ＱＡＰ１０６のダイレクトリンクサービスの制御下において異なるＳＴＡとの直接通信が可能か否かを判断し、直接通信が不可能な場合はステップＳ１４０５へ進む。ステップＳ１４０５では、通信不可能である旨の情報を含むＤＬＳ応答メッセージをＳＴＡ１０４に送信し、ステップＳ１４０１に戻る。
また、ステップＳ１４０３で直接通信が可能な場合はステップＳ１４０４へ進み、ＤＬＳ要求メッセージ（Ｍ４１３）をＳＴＡ１０１に送信し、ステップＳ１４０１に戻る。
次に、ステップＳ１１０１で、接続中のＳＴＡ１０１がＱＡＰ１０６からメッセージを受信するとステップＳ１１０２へ進み、受信メッセージがＤＬＳ接続要求メッセージ（Ｍ４１３）か否かを判断する。ＹＥＳの場合はステップＳ１１０３へ進み、ＱＡＰ１０６のダイレクトリンクサービスの制御下において異なるＳＴＡとの直接通信が可能か否かを判断し、直接通信が不可能な場合はステップＳ１３１５へ進む。ステップＳ１３１５では、通信不可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ４１４）をＱＡＰ１０６に送信し、ステップＳ１１０１に戻る。
また、ステップＳ１１０３で直接通信が可能な場合はステップＳ１１０４へ進み、転送モードや通信情報が一致するか判定する。ここで、転送モードの判定は、例えば図１７に示す転送モード対向テーブルに基づいて行う。図１７は、デバイス転送モードと使用プロトコルの関連テーブルを示す図である。入力系デバイス―アダプタ間のインターフェースと転送モード及び出力（表示）系デバイス―アダプタ間のインターフェースと転送モードの関係により選択される（最上位の）使用プロトコルを示すテーブルである。
例えば、パターン番号７（インターフェース：IEEE1394、転送モード；アイソクロナス、ＱｏＳ：ＲＴＰ）の場合、最上位レイヤの通信プロトコルとしてＱｏＳプロトコルであるＲＴＰを確認する。また、動画ストリーム以外のパターン番号６（インターフェース：IEEE1394、転送モード；アシンクロナス、ＱｏＳ：ＴＣＰ）の場合、最上位レイヤの通信プロトコルとしてＴＣＰを確認する。また、図１６に示すデバイス管理テーブルより液晶テレビ１１０に関するデバイス管理情報１６０４とチューナー１０７のデバイス管理情報１６０１、特にＱｏＳ制御に関わるRTP/RTCPプロトコルのサポート状況の整合性を検証する。
尚、この検証は、ＤＬＳ接続要求メッセージ（Ｍ４１３）に含まれる要求元（受信デバイス側）ＳＴＡ１０４の識別情報に基づいて行うものである。
ここで、動画像ストリームの通信が不可能と判断した場合はステップＳ１３１５へ進み、通信不可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ４１４）をＱＡＰ１０６に送信し、ステップＳ１１０１に戻る。
また、ステップＳ１１０４で、動画像ストリームを通信可能と判断した場合はステップＳ１１０５へ進み、通信可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ４１４）をＱＡＰ１０６に送信する。また、接続要求メッセージ（Ｍ４１７）をチューナー１０７に送信する。
次に、ステップＳ１１０６で、チューナー１０７から接続要求メッセージ（Ｍ４１７）に対する接続応答メッセージ（Ｍ４１８）を受信するとステップＳ１１０７へ進み、送信タイミングが遅れているか判定する。この時点では、送信側デバイス（被選択側）であるチューナー１０７から送信データを受けていないため、ステップＳ１１１０のデータ受信待ち状態へ遷移する。尚、送信タイミングが遅れる場合については更に後述する。
一方、ＱＡＰ１０６がＳＴＡ１０１からＤＬＳ応答メッセージ（Ｍ４１４）を受信した場合はステップＳ１４０１、Ｓ１４０２、Ｓ１４０６を経てＳ１４０７へ進む。ステップＳ１４０７では、通信可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ４１５）をＳＴＡ１０４に送信し、ステップＳ１４０１に戻る。これにより、ＳＴＡ１０４がＤＬＳ応答メッセージ（Ｍ４１５）を受信した場合はステップＳ１２０４へ進み、接続要求メッセージ（Ｍ４１１）の応答を示す接続応答メッセージ（Ｍ４１６）を液晶テレビ１１０に送信する。そして、ステップＳ１２０５へ進み、データ受信待ち状態に遷移する。
一方、受信側デバイス（選択側）である液晶テレビ１１０がステップＳ９０６で、接続応答メッセージ（Ｍ４１６）を受信するとステップＳ９１０へ進む。そして、デバイスの入出力判定を行い、出力デバイスであるためステップＳ９１１へ進み、液晶テレビ１１０の実装するRTP/RTCPプロトコルのサポート機能を確認する。ここでサポート可能であればステップＳ９１２へ進み、以降受信側ＳＴＡ１０４から受信する通信データ（Ｍ４２１）の受信処理時において、ＲＴＰプロトコルヘッダの除去処理を起動するように制御処理に設定する。即ち、液晶テレビ１１０はＲＴＰヘッダ処理を実施し、ＳＴＡ１０４は非処理となる。そして、ステップＳ９１３のデータ受信処理へ進む。また、RTP/RTCPプロトコルのサポート機能を確認し、未サポートであればステップＳ９１３のデータ受信処理へ進む。この場合、液晶テレビ１１０のＲＴＰヘッダ処理に関しては未対応で、ＳＴＡ１０４がＲＴＰ処理を行う。
また、ステップＳ９０７で、チューナー１０７がＳＴＡ１０１から接続要求メッセージ（Ｍ４１７）を受信するとステップＳ９０８へ進み、接続応答メッセージ（Ｍ４１８）をＳＴＡ１０１に送信する。そして、ステップＳ９０９で、ＳＴＡ１０１と接続が完了するとステップＳ９１０へ進み、デバイスの入出力判定を行う。ここで、入力デバイスであるため、ステップＳ９１４へ進み、RTP/RTCPプロトコルのサポート機能を確認し、サポート可能であればステップＳ９１５へ進む。ステップＳ９１５では、以降ＳＴＡ１０１に送信する通信データ（Ｍ４１９）の送信処理時において、ＲＴＰプロトコルヘッダの付加処理を起動するように制御処理に設定する。即ち、チューナー１０７はＲＴＰヘッダ処理を実施し、ＳＴＡ１０１は非処理となる。そして、ステップＳ９１６のデータ送信処理へ進む。また、RTP/RTCPプロトコルのサポート機能を確認し、未サポートであればステップＳ９１６のデータ送信処理へ進む。この場合、チューナー１０７のＲＴＰヘッダ処理に関しては未対応で、ＳＴＡ１０１がＲＴＰ処理を行う。
以上、送信側デバイス（被選択側）であるチューナー１０７と受信側デバイス（選択側）である液晶テレビ１１０のそれぞれで接続中状態からデータ通信状態へ遷移する場合の制御処理を説明した。
次に、チューナー１０７が接続されるＳＴＡ１０１及び液晶テレビ１１０が接続されるＳＴＡ１０４のデータ送受信状態により、ＱｏＳプロトコル制御処理と動画像ストリーム通信中の無線帯域の予約処理を説明する。
ステップＳ１１１０で、データ受信待ち状態にあるＳＴＡ１０１がチューナー１０７のデータ送信処理でＲＴＰヘッダを付加したデジタル動画データ（Ｍ４１９）を受信するとステップＳ１１１１へ進む。ステップＳ１１１１では、チューナー１０７の実装するRTP/RTCPプロトコルのサポート状態を判定する。この判定は、デバイス間で送受信された設定メッセージで得られた情報を保存しているデバイス管理テーブルを参照して行う。
ここで、未サポートであればステップＳ１１１２へ進み、以降ＳＴＡ１０４に送信する通信データ（Ｍ４２０）の送信処理時に、ＲＴＰプロトコルヘッダの付加処理を起動するように制御処理に設定する。そして、ステップＳ１１１３のデータ送信処理を行う。この場合、チューナー１０７のＲＴＰヘッダ処理に関しては未対応で、ＳＴＡ１０１がＲＴＰ処理を行う。また、サポート可能であればステップＳ１１１３へ進み、データ送信処理を行う。この場合、チューナー１０７がＲＴＰヘッダ処理を行い、ＳＴＡ１０１では非処理となる。そして、ステップＳ１１１４において、通信の完了を確認し、通信が完了すると、接続中状態に遷移する。また、通信継続の場合にはステップＳ１１１７に戻る。
ここで、チューナー１０７から受信した例えば、直前の動画データ（Ｍ４１９）の受信処理に要する時間とＳＴＡ１０４に送信する送信データ（Ｍ４２０）の送信処理に要する時間とを比較する。その結果、「受信処理時間≧送信処理時間」となった場合、チューナー１０７から受信する動画データ（Ｍ４２２）の受信処理と、送信データ（Ｍ４２３）の制御処理（ステップＳ１１０７〜Ｓ１１１４）を繰り返す。
そして、ステップＳ１１０７で「受信処理時間＜送信処理時間」となった場合、即ち、受信データのオーバーフロー状態の危険性が予測されるような場合はステップＳ１１０８へ進む。ステップＳ１１０８では、IEEE802.11e標準で規定される帯域予約シーケンス（Ｍ４２８）をＱＡＰ１０６間で起動する。そして、ステップＳ１１０９で、その帯域予約シーケンス（Ｍ４２８）が完了するとステップＳ１１１０へ進み、データ受信及びデータ送信処理の各処理を繰り返す。
従って、以降の受信データ（Ｍ４２５）の受信処理と、ＳＴＡ１０４に送信される無線データ（Ｍ４２６）の送信処理との処理タイミングを調整することができる。
次に、ＳＴＡ１０１からＳＴＡ１０４へ送信される無線データ（Ｍ４２０，Ｍ４２３，Ｍ４２６）を受信するＳＴＡ１０４の受信処理を説明する。
まず、ステップＳ１２０５において、ＳＴＡ１０４がＳＴＡ１０１より送信された無線データ（Ｍ４２０、Ｍ４２３，Ｍ４２６）を受信した場合はステップＳ１２０６へ進み、液晶テレビ１１０の実装するRTP/RTCPプロトコルのサポート機能を確認する。未サポートであればステップＳ１２０７へ進み、以降液晶テレビ１１０に送信する動画像データ（Ｍ４２１、Ｍ４２４，Ｍ４２７）の送信処理時にＲＴＰプロトコルヘッダの除去処理を起動するように制御処理に設定する。即ち、液晶テレビ１１０がＲＴＰヘッダ処理に関しては未対応で、ＳＴＡ１０４がＲＴＰ処理を行う。そして、ステップＳ１２０８でデータ受信処理を行い、ステップＳ１２０９で液晶テレビ１１０へのデータ送信処理を行う。そして、ステップＳ１２１０で通信完了を判定し、完了でなければステップＳ１２０５に戻り、上述の処理を繰り返す。また、ステップＳ１２０６で、サポート可能であればステップＳ１２０７をスキップしてステップＳ１２０８へ進み、上述の処理を行う。
以上、送信側デバイス（被選択側）と受信側デバイス（選択側）との間の通信データに対するＱｏＳ関連プロトコル（RTP/RTCP）のサポート状態をＳＴＡが解析し、ＱｏＳ関連プロトコルの付加処理を回避することができる。これにより、特にリアルタイム性の要求される入出力データに対する適切なＱｏＳ関連プロトコル処理の提供が可能となる。
［第２の実施形態］
次に、図面を参照しながら本発明に係る第２の実施形態について詳細に説明する。第２の実施形態では、実際に送信されるデータのプロトコルヘッダ情報を解析し、その結果に応じてＱｏＳ関連プロトコルの処理を制御する。具体的には、ＳＴＡ１０１がチューナー１０７から受信したＤＶデータにＲＴＰヘッダーが付加されているか否かを判断するものである。そして、付加されていない場合、ＲＴＰヘッダーを付加してＳＴＡ１０４へ送信する。
図１８は、第２の実施形態におけるストリーム伝送で送受信されるメッセージのシーケンスを示す図である。図１９は、第２の実施形態における送信側ＳＴＡ１０１の処理を示すフローチャートである。図２０は、第２の実施形態における受信側ＳＴＡ１０４の処理を示すフローチャートである。
尚、ＳＴＡ１０１、１０４における通信中までの処理及びＱＡＰ１０６の処理は、第１の実施形態の図９、図１０及び図１４を用いて説明する。
図１８に示すシーケンスにおいて、メッセージ（Ｍ４０１〜Ｍ４１０）及びメッセージ交換に関連する処理については、第１の実施形態と同様であり、説明は省略する。
まず、ステップＳ９０４において、チューナー１０７から液晶テレビ１１０を指定するリモコン操作等が行われるとステップＳ９０５へ進み、液晶テレビ１１０を特定する情報を含む接続要求メッセージ（Ｍ１８００）をＳＴＡ１０１に送信する。
一方、接続中のＳＴＡ１０１がチューナー１０７から接続要求メッセージ（Ｍ１８００）を受信するとステップＳ１９０１からステップＳ１９０２、Ｓ１９１０、Ｓ１９１１へ進む。ステップＳ１９１１では、IEEE802.11e標準で規定される帯域予約シーケンス（Ｍ１８０１）をＱＡＰ１０６間で起動する。そして、ステップＳ１９１２で、帯域予約シーケンス（Ｍ１８０１）が完了するとステップＳ１９１３へ進み、ダイレクトリンクサービスの設定要求（ＤＬＳ要求）メッセージ（Ｍ１８０２）をＱＡＰ１０６に送信し、ステップＳ１９０１に戻る。
また、ステップＳ１４０１において、接続中のＱＡＰ１０６がＳＴＡ１０１からＤＬＳ要求メッセージ（Ｍ１８０２）を受信するとステップＳ１４０２からステップＳ１４０３へ進む。ステップＳ１４０３では、ＱＡＰ１０６のダイレクトリンクサービスの制御下において異なるＳＴＡとの直接通信が可能か否かの判断を行い、直接通信が不可能な場合はステップＳ１４０５へ進む。ステップＳ１４０５では、ＳＴＡ１０１に通信不可能である旨の情報を含むＤＬＳ応答メッセージを送信し、ステップＳ１４０１に戻る。また、直接通信が可能な場合はステップＳ１４０４へ進み、ＤＬＳ要求メッセージ（Ｍ１８０３）をＳＴＡ１０４に送信し、ステップＳ１４０１に戻る。
一方、ステップＳ２００１において、ＳＴＡ１０４がＱＡＰ１０６からＤＬＳ接続要求メッセージ（Ｍ１８０３）を受信すると、ステップＳ２００２からステップＳ２００３へ進む。ステップＳ２００３では、ＱＡＰ１０６のダイレクトリンクサービスの制御下において異なるＳＴＡとの直接通信が可能か否かの判断を行い、直接通信が不可能な場合はステップＳ２０１３へ進む。ステップＳ２０１３では、通信不可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ１８０４）をＱＡＰ１０６に送信し、ステップＳ２００１に戻る。
また、ステップＳ２００３において、直接通信が可能な場合はステップＳ２００４へ進み、第１の実施形態と同様に、転送モードや通信情報が一致するか否かを判断する。ここで、相互通信の整合性を検証し、動画像ストリームの通信が可能と判断するとステップＳ２００５へ進み、通信可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ１８０４）をＱＡＰ１０６に送信する。そして、液晶テレビ１１０に接続要求メッセージ（Ｍ１８０７）を送信する。次に、ステップＳ２００６において、液晶テレビ１１０から接続応答メッセージ（Ｍ１８０８）の受信を待ち、受信するとステップＳ２００７へ進み、データ受信待ち状態に遷移する。
また、ステップＳ１４０１において、ＱＡＰ１０６がＳＴＡ１０４からＤＬＳ応答メッセージ（Ｍ１８０４）を受信すると、ステップＳ１４０２からＳ１４０６のＹＥＳへ進む。そして、ステップＳ１４０７において、通信可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ１８０５）をＳＴＡ１０１に送信し、ステップＳ１４０１に戻る。
一方、ステップＳ１９０１において、ＳＴＡ１０１がＤＬＳ応答メッセージ（Ｍ１８０５）を受信すると、ステップＳ１９０２からステップＳ１９０３へ進む。ステップＳ１９０３では、接続応答メッセージ（Ｍ１８０６）をチューナー１０７に送信し、ステップＳ１９０４へ進み、データ受信待ち状態に遷移する。
これにより、ステップＳ９０６において、チューナー１０７が接続応答メッセージ（Ｍ１８０６）を受信するとステップＳ９１０へ進み、入力デバイスであるためにステップＳ９１４へ進む。ステップＳ９１４では、チューナー１０７の実装するRTP/RTCPプロトコルのサポート機能を確認し、サポート可能であればステップＳ９１５へ進み、第１の実施形態と同様にRTPヘッダ付加処理を行う。また、未サポートであれば、そのままステップＳ９１６へ進み、データ送信処理を行う。
次に、ステップＳ１９０４で、データ受信待ちのＳＴＡ１０１がチューナー１０７からデータ（Ｍ１８０９）を受信すると、ステップＳ１９０５へ進み、データ解析処理を実行する。そして、ステップＳ１９０６で、受信したデータのRTP/RTCPプロトコルヘッダ情報を確認し、RTPヘッダが付加されていなければ、ステップＳ１９０７へ進む。ステップＳ１９０７では、RTPヘッダを付加し、ステップＳ１９０８で、ＳＴＡ１０４へデータ送信処理を行う。また、ステップＳ１９０６で、RTPヘッダが付加されていれば、ステップＳ１９０８へ進み、ＳＴＡ１０４へデータ送信処理を行う。そして、全てのデータを送信完了するまでステップＳ１９０４に戻り、上述の処理を繰り返す。
一方、ステップＳ２００７で、データ受信待ちのＳＴＡ１０４がＳＴＡ１０１からデータ（Ｍ１８１０）を受信すると、ステップＳ２００８へ進み、プロトコルをチェックし、RTPカプセル化を判断する。これ以降の処理（Ｓ２００８〜Ｓ２０１２）は、第１の実施形態で説明した図１２のＳ１２０６〜Ｓ１２１０と同様であり、その説明は省略する。
第２の実施形態によれば、第１の実施形態と同様に、送受信データに対する不要なＱｏＳ関連プロトコルの付加処理を回避し、特にリアルタイム性の要求される入出力データに対する適切なＱｏＳ関連プロトコル処理の提供が可能となる。
［第３の実施形態］
次に、図面を参照しながら本発明に係る第３の実施形態について詳細に説明する。第３の実施形態では、プロトコルヘッダ部に含まれるパケットデータのプライオリティを解析し、その結果に応じてＱｏＳ関連プロトコルの処理を制御する。第１及び第２の実施形態では、チューナー１０７と液晶テレビ１１０との間のストリーム伝送を説明したが、第３の実施形態ではＨＤＲ１０８とノートＰＣ１１１との間のストリーム伝送を説明する。
図２１は、ＨＤＲ１０８からノートＰＣ１１１へ直接動画をストリーム伝送する状態を示す図である。図２１に示すように、ＨＤＲ１０８は有線ＬＡＮケーブル１１５を介してＳＴＡ１０２に接続され、ノートＰＣ１１１は有線ＬＡＮケーブル１１５を介してＳＴＡ１０５に接続される。
図２２は、図２１に示すストリーム伝送で送受信されるメッセージのシーケンスを示す図である。また、図２２に示すシーケンス内のメッセージは、第３の実施形態に関する主なもののみを明記し、一部のメッセージについては省略している。
図２３は、入力側（ＨＤＲ１０８が接続される）ＳＴＡ１０２における受信フレームの処理フローを示す図である。図２３に示す例は、ＨＤＲ１０８がＱｏＳプロトコル処理をサポートしていない場合である。
図２３において、２３０１は有線ＬＡＮ制御部２１１から受信したIEEE802.1p準拠のユーザプライオリティフィールドをもつIEEE802.1QのVLANタグヘッダ（VLANタグパケット）の受信フレームである。２３０２は受信用バッファメモリ（mbuf）にあるVLANタグパケットの受信処理フレーム２３０１のVLANタグヘッダをIEEE802.3⇔IEEE802.1p相互変換処理部２３００により除去したＩＰ受信処理フレームである。２３０３はＩＰ受信処理フレーム２３０２のＩＰヘッダをＩＰ処理部７０５により除去したUDP/TCP受信処理フレームである。２３０４はUDP/TCP受信処理フレーム２３０３のUDP/TCPヘッダをUDP/TCP処理部２３０５により除去した動画像フレームである。
２３０５はUDP又はTCPのトランスポート層のネットワークプロトコル処理を行うTCP/UDP処理部である。また、メモリ制御処理（ネットワーク側）７０２はVLANタグパケットの受信処理フレームを記憶領域部２０８にある受信用バッファメモリ（mbuf）に対して書込み制御を実施する。
図２４は、入力側（ＨＤＲ１０８が接続される）ＳＴＡ１０２における送信フレームの処理フローを示す図である。この例では、ＳＴＡ１０２においてＱｏＳプロトコル処理をサポートする場合を示している。
図２４において、２４０１はＲＴＰ送信処理フレームであり、動画像フレームに対してＱｏＳプロトコルであるＲＴＰの使用の検出を行い、未使用である場合、動画像フレームに対してＱｏＳプロトコルであるＲＴＰヘッダの付加が行われる。２４０２はＲＴＰ送信処理フレーム２４０１にUDP/TCP処理部２３０５でＵＤＰヘッダを付加したＵＤＰ送信処理フレームである。２４０３はＵＤＰ送信処理フレーム２４０２にＩＰ処理部５０５でＩＰヘッダを付加したＩＰ送信処理フレームである。２４０４はＩＰ送信処理フレーム２４０３にIEEE802.3変換処理部５０６で802.3ヘッダを付加したIEEE802.3送信処理フレームである。
図２５は、出力側（ノートＰＣ１１１が接続される）ＳＴＡ１０５における受信フレームの処理フローを示す図である。この例では、ＳＴＡ１０５においてＱｏＳプロトコル処理をサポートする場合を示している。
図２５において、２５０１は無線LAN制御部２０６から受信したIEEE802.11無線データをIEEE802.3変換処理部７０６で802.3ヘッダに変換したIEEE802.3受信処理フレームである。また、メモリ制御処理（ネットワーク側）７０２は、IEEE802.3受信処理フレームを記憶領域部２０８にある受信用バッファメモリ（mbuf）に対して書込み制御を実施する。２５０２は受信用バッファメモリ（mbuf）にあるIEEE802.3受信処理フレーム２５０１の802.3ヘッダをIEEE802.3変換処理部７０６で除去したＩＰ受信処理フレームである。２５０３はＩＰ受信処理フレーム２５０２のＩＰヘッダーをＩＰ処理部７０５で除去したUDP/TCP受信処理フレームである。２５０４はUDP/TCP受信処理フレーム２５０３のＵＤＰヘッダをUDP/TCP処理部２３０５で除去したＲＴＰ受信処理フレーム（ペイロードには、動画像データを含む）である。
図２６は、出力側（ノートＰＣ１１１が接続される）ＳＴＡ１０５における送信フレームの処理フローを示す図である。この例では、ノートＰＣ１１１にＱｏＳプロトコル処理がサポートされない場合を示している。
図２６において、ＲＴＰ処理部５０３がデータ送信先で接続されるデバイスであるノートＰＣ１１１のＱｏＳプロトコルであるＲＴＰのサポートの検出を行う。その結果、未サポートである場合、記憶領域部２０８に書込み格納されている動画像フレーム２８０４に対してＱｏＳプロトコルであるＲＴＰヘッダが除去される。２６０１はＱｏＳプロトコルであるＲＴＰヘッダが除去された動画像フレームである。２６０２は動画像フレーム２６０１にUDP/TCP処理部２３０５でＵＤＰヘッダを付加したＵＤＰ送信処理フレームである。２６０３はＵＤＰ送信処理フレーム２６０２にＩＰ処理部５０５でＩＰヘッダを付加したＩＰ送信処理フレームである。２６０４はＩＰ送信処理フレーム２６０３にIEEE802.1p変換処理部２３００で802.1pヘッダを付加したIEEE802.1p送信処理フレームである。
図２７は、IEEE802.1p準拠のユーザプライオリティフィールドを持つIEEE802.1QのVLANタグヘッダ送信フレーム（IEEE802.1p）の構成を示す図である。図２７において、２７０１はVLANタグヘッダ・フレームを識別するためのTPID（TagProtocolID（0x8100））である。２７０２はフレームの優先順位情報であるＵＰ（User Priority）である。また、プライオリティは、８つのレベル（０−７）で表現される。
図２８は、ＵＰとＱｏＳプロトコル処理との関係を表す管理テーブルである。図２８において、２８０１はRTP/RTCP処理の対応、非対応を表す。２８０２はIEEE802.1p準拠のユーザプライオリティである。２８０３はユーザプライオリティに対する802.1Dの記号である。２８０４は記号３１０３の名称である。
図２９は、無線MAC送信フレーム（８０２．３）の構成を示す図である。図２９において「あて先MACアドレス」は、あて先装置のMACアドレスでレングスは６バイト。「送信元アドレス」は、送信元装置のMACアドレスでレングス６バイト。「長さ」は、後に続くデータ部の長さを表す。プロトコルIDは、0x5DC(1500)よりも大きな値を用いることで識別が可能。「DSAP」は、Destination SAPを意味する。これは、送信先のネットワーク層のプロトコルを識別するためのフィールドで１バイト（WLAN：0xAA）。「SSAP」は、Source SAPのことで、送信元のネットワーク層のプロトコルを識別する。DSAPと同じく、１バイトで通常、送信先と送信元は同じプロトコルを利用するのでDSAP、SSAPは同じものになる（WLAN：0xAA）。「制御」は、データリンクレベルでコネクションの確立やフロー制御を行うためのフィールド。これも１バイトの大きさ（WLAN：0x03）。「組織ID」は、MACアドレスの上位３バイトの組織IDと同じ。IEEEがベンダ毎に組織IDを割り当て、レングス３バイト。「タイプ」は、ＥＴＨ（イーサネット：登録商標）Ver2のフレームフォーマットのタイプと同じ。レングス２バイト。これによりＥＴＨver2との互換性も保て、２バイトなのでベンダ毎に固有のプロトコルを作った場合も十分とされる（WLAN：0x0800）。
ここで、図２２に示すシーケンスに従ってＨＤＲ１０８からノートＰＣ１１１へ動画をストリーム伝送する処理の詳細を説明する。
図３０は、第３の実施形態における送信側ＳＴＡ１０２の処理を示すフローチャートである。また、図３１は、第３の実施形態における受信側ＳＴＡ１０５の処理を示すフローチャートである。
尚、ＳＴＡ１０２、１０５における通信中までの処理とＱＡＰ１０６の処理は、第１の実施形態で用いた図９、図１０と図１３及び図１４を参照して説明する。
図２２に示すシーケンス図において、送信デバイス側ＳＴＡ１０２が、ＱＡＰ１０６のサービスエリア内に設置されるか、ＳＴＡ１０２の電源が投入されると、ＱＡＰ１０６との間でアソシエーション処理（Ｍ４０１）を行う。そして、ステップＳ１００１において、ＳＴＡ１０２がアソシエーション処理（Ｍ４０１）を完了するとステップＳ１００２へ進む。ステップＳ１００２では、ＳＴＡ１０２はＨＤＲ１０８との間で有線ＬＡＮケーブル１１５を用いて接続し、ＨＤＲ１０８の転送速度やＱｏＳプロトコルであるＲＴＰのサポート状態に関するＥＴＨ接続シーケンス処理（Ｍ２２０１）を実施する。
一方、送信デバイスであるＨＤＲ１０８では、ＳＴＡ１０２との接続操作や、デバイス本体の電源投入操作などが行われる。そして、ステップＳ９０１で、ＳＴＡ１０２との間でＥＴＨ接続シーケンス処理（Ｍ２２０１）を完了するとステップＳ９０２へ進み、システム内に収容する全ての端末の更新情報をＳＴＡ１０２から受信する。
次に、ＳＴＡ１０２がＥＴＨ接続シーケンス処理（Ｍ２２０１）を完了するとステップＳ１００３へ進み、接続デバイスに関する情報を端末種別情報として種別登録メッセージ（Ｍ４０６）に含めてＱＡＰ１０６に送信する。ここで、接続デバイスに関する情報は、デバイス名称、インターフェース種別「有線ＬＡＮ」、転送モード「802.1p準拠」、RTP/RTCPプロトコルのサポート状況「あり」である。そして、ステップＳ１００４において、システム内に収容する全ての端末の更新情報をＱＡＰ１０６から受信するのを待つ。
一方、ＱＡＰ１０６は、ステップＳ１３０１でＳＴＡ１０２との間でアソシエーション処理（Ｍ４０１）が完了するとステップＳ１３０２へ進み、ＨＤＲ１０８に関する情報を含む種別登録メッセージ（Ｍ４０６）の受信を待つ。そして、ＳＴＡ１０２から種別登録メッセージ（Ｍ４０６）を受信するとステップＳ１３０３へ進み、端末種別情報を、例えばデバイス管理テーブルの形態でメモリに格納し、ステップＳ１３０４で更新情報があるか否かを判断する。ここで、新規にアソシエーション処理によりＳＴＡが登録される場合、又は以前のデバイスとは異なるデバイスが接続されたことにより該当するＳＴＡからの種別登録メッセージの情報が変化したと判断された場合にはステップＳ１３０５へ進む。ステップＳ１３０５では、例えばデバイス管理テーブルのデバイス情報を最新情報としてＳＴＡ１０２に種別情報メッセージ（Ｍ４０９）を送信し、接続中状態へと遷移する。
一方、ＳＴＡ１０２がＱＡＰ１０６から種別情報メッセージ（Ｍ４０９）を受信するとステップＳ１００５へ進み、例えばデバイス管理テーブルの形態で記憶領域２０８に格納する。そして、ステップＳ１００６でＨＤＲ１０８にシステム端末情報メッセージ（Ｍ２２０４）を送信し、接続中状態へと遷移する。
次に、ＨＤＲ１０８がＳＴＡ１０２からシステム端末情報メッセージ（Ｍ２２０４）を受信するとステップＳ９０３へ進み、通信可能な接続デバイスに関する情報をデバイス管理テーブルの形態で格納する。そして、システム内にあるデバイスの収容状況、性能及び状態をＬＣＤなどに表示する。ここで、ＨＤＲ１０８は、ステップＳ９０４へ進み、接続中状態となる。また、接続デバイスに関する情報は、デバイス名称、インターフェース種別「有線ＬＡＮ」、転送モード「802.1p準拠」、RTP/RTCPプロトコルのサポート状況「あり」である。
尚、受信側のデバイスであるノートＰＣ１１１と受信側のＳＴＡ１０５とＱＡＰ１０６との間でも、上述した送信側と同様に処理が行われる。ここでは、送信側のＨＤＲ１０８と受信側のノートＰＣ１１１とで異なる処理について説明する。
まず、ステップＳ９０３で、ＨＤＲ１０８はシステム内にあるデバイスの収容状況、性能、及び状態をＬＣＤなどに表示したが、ノートＰＣ１１１は液晶ディスプレイである。従って、ノートＰＣ１１１のアプリケーションソフトを用いて液晶ディスプレイの一部、或いは専用ウインドウ画面に切り替え、システム内に接続収容されている送受信可能なデバイスの収容状況、性能、及び状態をアイコン等を採用し、視覚的に明示する。
次に、図２２において、ノートＰＣ１１１の画面上でＨＤＲ１０８のアイコンが選択するとステップＳ９０５へ進み、ＨＤＲ１０８を特定する情報を含む接続要求メッセージ（Ｍ２２０５）を有線ＬＡＮケーブル１１５を介してＳＴＡ１０５に送信する。
一方、ステップＳ３１０１において、メッセージ受信の待ち状態にあるＳＴＡ１０５がＨＤＲ１０８からメッセージを受信するとステップＳ３１０２へ進む。ここで、受信したメッセージが接続要求メッセージ（Ｍ２２０５）の場合はステップＳ３１１３へ進み、ＱＡＰ１０６のダイレクトリンクサービスの制御下において異なるＳＴＡとの直接通信が可能か否かの判断を行う。その結果、直接通信が不可能な場合はステップＳ３１１５へ進み、ノートＰＣ１１１に対して通信不可能である旨の情報を含む接続応答メッセージを送信する。
また、直接通信が可能な場合はステップＳ３４１４へ進み、ＱＡＰ１０６に対してダイレクトリンクサービスの設定要求（ＤＬＳ要求）メッセージ（Ｍ４１２）を送信し、ステップＳ３１０１に戻る。
一方、ステップＳ１４０１でＱＡＰ１０６がＳＴＡ１０５からメッセージを受信するとステップＳ１４０２へ進み、受信メッセージがＤＬＳ要求メッセージ（Ｍ４１２）か否かを判断する。ＹＥＳの場合はステップＳ１４０３へ進み、ＱＡＰ１０６のダイレクトリンクサービスの制御下において異なるＳＴＡとの直接通信が可能か否かを判断し、直接通信が不可能な場合はステップＳ１４０５へ進む。ステップＳ１４０５では、通信不可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ４１５）をＳＴＡ１０５に送信し、ステップＳ１４０１に戻る。
また、ステップＳ１４０３で直接通信が可能な場合はステップＳ１４０４へ進み、ＤＬＳ要求メッセージ（Ｍ４１３）をＳＴＡ１０２に送信し、ステップＳ１４０１に戻る。
次に、ステップＳ３００１で、接続中のＳＴＡ１０２がＱＡＰ１０６からメッセージを受信するとステップＳ３２０２へ進み、受信メッセージがＤＬＳ接続要求メッセージ（Ｍ４１３）か否かを判断する。ＹＥＳの場合はステップＳ３２０３へ進み、ＱＡＰ１０６のダイレクトリンクサービスの制御下において異なるＳＴＡとの直接通信が可能か否かを判断し、直接通信が不可能な場合はステップＳ３００５へ進む。ステップＳ３００５では、通信不可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ４１４）を送信し、ステップＳ３００１に戻る。
また、ステップＳ３００３で直接通信が可能な場合はステップＳ３００４へ進み、転送モードや通信情報が一致するか判定する。判定処理は、第１の実施形態と同様に、ＤＬＳ接続要求メッセージ（Ｍ４１３）に含まれる接続要求元（受信デバイス側）ＳＴＡ１０５の識別情報に基づいて行う。即ち、第１の実施形態と同様に、転送モード対向テーブルに基づいて転送モードの判定を行い、デバイス管理テーブルに基づいてＱｏＳサポート状況の整合性を検証する。
ここで、動画像ストリームの通信が不可能と判断した場合はステップＳ３３０５へ進み、通信不可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ４１４）をＱＡＰ１０６に送信し、ステップＳ３００１に戻る。
また、ステップＳ３００４で、動画像ストリームを通信可能と判断した場合はステップＳ３００６へ進み、通信可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ４１４）をＱＡＰ１０６に送信する。そして、ステップＳ３００７において、IEEE802.11eで規定の帯域予約シーケンス（Ｍ２２０７）をＱＡＰ１０６との間で起動する。その後、ステップＳ３００８で帯域予約シーケンス（Ｍ２２０７）が完了するとステップＳ３００９へ進み、接続要求メッセージ（Ｍ２２０８）をＨＤＲ１０８に送信する。
次に、ステップＳ３０１０において、ＨＤＲ１０８から接続要求メッセージ（Ｍ２２０８）に対する接続応答メッセージ（Ｍ２２０９）を受信した場合はステップＳ３０１１へ進み、データ受信待ち状態に遷移する。
一方、ＱＡＰ１０６がＳＴＡ１０２からＤＬＳ応答メッセージ（Ｍ４１４）を受信した場合はステップＳ１４０７へ進む。ステップＳ１４０７では、通信可能である旨の情報を含むＤＬＳ応答メッセージ（Ｍ４１５）をＳＴＡ１０５に送信し、ステップＳ１４０１に戻る。これにより、ＳＴＡ１０５がＤＬＳ応答メッセージ（Ｍ４１５）を受信した場合はステップＳ３１０３へ進み、接続要求メッセージ（Ｍ２２０５）の応答を示す接続応答メッセージ（Ｍ２２０６）をノートＰＣ１１１に送信する。そして、ステップＳ３１０４へ進み、データ受信待ち状態に遷移する。
一方、受信側デバイス（選択側）であるノートＰＣ１１１がステップＳ９０６で、接続応答メッセージ（Ｍ２２０６）を受信するとステップＳ９１０へ進む。そして、デバイスの入出力判定を行い、出力デバイスであるためステップＳ９１１へ進み、ノートＰＣ１１１の実装するRTP/RTCPプロトコルのサポート機能を確認する。ここで、サポート不可能であるのでステップＳ９１３へ進み、通常のデータ受信処理を実施する（デバイス１１１のＲＴＰヘッダ処理に関しては未対応：ＳＴＡ１０５でＲＴＰ処理を実施する）。
また、ステップＳ９０７で、ＨＤＲ１０８がＳＴＡ１０２から接続要求メッセージ（Ｍ２２０８）を受信するとステップＳ９０８へ進み、接続応答メッセージ（Ｍ２２０９）をＳＴＡ１０２に送信する。そして、ステップＳ９０９で、ＳＴＡ１０２と接続が完了するとステップＳ９１０へ進み、デバイスの入出力判定を行う。ここで、入力デバイスであるため、ステップＳ９１４へ進み、ＨＤＲ１０８の実装するRTP/RTCPプロトコルのサポート機能を確認し、サポート不可能であるのでステップＳ９１６へ進む。ステップＳ９１６では、以降、ＳＴＡ１０２に対して送信する通信データ（Ｍ２２１０、Ｍ２２１３）の通常データ送信処理を実施する。この場合、ＨＤＲ１０８のＲＴＰヘッダ処理に関しては未対応で、ＳＴＡ１０２がＲＴＰ処理を行う。
以上、送信側デバイス（被選択側）であるＨＤＲ１０８と受信側デバイス（選択側）であるノートＰＣ１１１のそれぞれで接続中状態からデータ通信状態に遷移する場合の制御処理を説明した。
次に、ＨＤＲ１０８が接続されるＳＴＡ１０２及びノートＰＣ１１１が接続されるＳＴＡ１０５のデータ送受信状態におり、ＱｏＳプロトコル制御処理と動画像ストリーム通信について説明する。
ステップＳ３０１１で、データ受信待ち状態にあるＳＴＡ１０２がＨＤＲ１０８のデータ送信処理によりデジタル動画データ（Ｍ２２１０、Ｍ２２１３）を受信するとステップＳ３０１２へ進む。ステップＳ３０１２では、ＨＤＲ１０８から受信したデータパケットのヘッダを解析し、ステップＳ３０１３において、データパケットのヘッダにあるユーザプライオリティ２７０２を確認する。このとき、ユーザプライオリティ２７０２の値が、ユーザプライオリティ毎にＱｏＳ対応管理テーブルに示す５（ビデオなどのストリーム系データ）又は６（オーディオ、電話などの音声系データ）であれば、ステップＳ３０１４へ進む。ステップＳ３０１４では、以降、通信データ（Ｍ２２１０）の送信処理時において、ＲＴＰプロトコルヘッダの付加処理を起動するように制御処理を設定し、ステップＳ３０１５のデータ送信処理を行う。この場合、ＳＴＡ１０２でＲＴＰ処理を行う。
また、ステップＳ３０１２で、ユーザプライオリティ２７０２の値が、ストリーム系や音声系のデータ以外の場合、ユーザプライオリティ毎にＱｏＳ対応管理テーブルに示す０〜４という値の場合ステップＳ３０１５へ進む。ステップＳ３０１５では、ＲＴＰを使用しないＴＣＰ／ＵＤＰによるデータ送信処理を行う。
そして、ステップＳ３０１６において、通信の完了を確認し、通信完了時は接続中状態に遷移する。また、通信継続の場合にはステップＳ３０１に戻り、上述の処理を繰り返し実行する。
次に、ＳＴＡ１０２からＳＴＡ１０５へ送信される無線データ（Ｍ２２１１、Ｍ２２１４）を受信するＳＴＡ１０５の受信処理を説明する。
まず、ステップＳ３１０４において、ＳＴＡ１０５がＳＴＡ１０２より送信された無線データ（Ｍ２２１１、Ｍ２２１４）を受信した場合はステップＳ３１０５へ進み、データ解析を行う。ここで、RTP/RTCPプロトコルヘッダ情報が付加されていない場合はステップＳ３１０７へ進み、ＲＴＰを使用しないTCP/UDPによるデータ送信処理を行う。また、RTP/RTCPプロトコルヘッダ情報が付加されている場合はステップＳ３１０６へ進み、データの受信処理（ステップＳ３１０７）で、ＲＴＰプロトコルヘッダの除去処理を行うように設定する。そして、ステップＳ３１０７において、ＳＴＡ１０２からのデータ受信処理を行う。
次に、ステップＳ３１０８において、デバイス管理テーブルを参照し、ノートＰＣ１１１に関するデバイス情報の転送モードを調べ、「802.1p準拠」である場合はステップＳ３１０９へ進む。ステップＳ３１０９では、ＨＤＲ１０８より受信したデータのＲＴＰペイロードを解析し、プライオリティ変換及びプロトコル変換を行う。例えば、ストリーム系データ（例えばビデオ）であれば５を、また音声系データ（例えばオーディオ、電話）であれば６というユーザプライオリティ毎のＱｏＳ対応管理テーブルに示す値をプロトコル変換する。そして、IEEE802.1p準拠のデータフレーム（図２７参照）のヘッダ部におけるユーザプライオリティ２７０２の値としてコーディングする。
一方、ステップＳ３１０８において、「802.1p準拠」でない場合はステップＳ３１１０へ進み、ノートＰＣ１１１に対するデータ送信処理を行う。ここでは、ノートＰＣ１１１にプロトコル変換データを送信する。そして、ステップＳ３１１１において、通信の完了を確認し、通信完了時には接続中状態に遷移する。また、通信継続の場合にはステップＳ３１０４に戻り、上述のデータ受信処理手順を繰り返す。
以上、ＳＴＡ１０２とＳＴＡ１０５において、ＨＤＲ１０８とノートＰＣ１１１のデバイス間で送受信されるデータパケットに対する優先順位を解析することにより、データパケットに対する効果的なＱｏＳ関連プロトコルの付加処理を実施できる。従って、リアルタイム性の要求される入出力データに対する適切なＱｏＳ関連プロトコル処理を提供することが可能となる。
［第４の実施形態］
次に、図面を参照しながら本発明に係る第４の実施形態について詳細に説明する。第４の実施形態では、送信側ＳＴＡが受信側ＳＴＡから要求されたアプリ種別に応じてＱｏＳプロトコルを選択してデータ伝送を行う。
図３２は、第４の実施形態におけるアプリ種別とＱｏＳプロトコル処理対応テーブルの構成を示す図である。図３２に示すアプリ種別管理テーブルにおいて、３２０１はアプリ種別エントリ番号（ＩＤ）である。３２０２はアプリケーション種別である。３２０３はＱｏＳ関連プロトコルの起動（RTP/RTCPを使用すること）又は解除（TCPを使用すること）に伴うプロトコル処理である。
第４の実施形態では、第３の実施形態で説明したＨＤＲ１０８からノートＰＣ１１１へ直接動画をストリーム伝送する要求に加え、ファイル転送が要求された場合について説明する。
図３３は、第４の実施実施形態におけるメッセージのシーケンスを示す図である。尚、図３３に示すシーケンス内のメッセージは、第４の実施形態に関する主なもののみを明記し、一部のメッセージについては省略している。
図３４は、入力側（ＨＤＲ１０８が接続される）ＳＴＡ１０２における送受信フレームの処理フローを示す図である。図３４では、ＳＴＡ１０２において、送画像ファイルデータの転送を行う場合を示している。
図３４において、３４００はイーサフレームヘッダ変換処理部であり、有線ＬＡＮインターフェースより受信するデータパケットの処理を行う。３４０１は有線ＬＡＮ制御部２１１から受信したＥＴＨ受信処理フレームである。３４０２は受信用バッファメモリ（mbuf）にあるＥＴＨ受信処理フレーム３４０１のＥＴＨヘッダがイーサフレームヘッダ変換処理部３４００で除去されたＩＰ送受信処理フレームである。３４０３はＩＰ送受信処理フレーム３４０２にIEEE802.3変換処理部５０６が802.3ヘッダを付加したIEEE802.3送信処理フレームである。
図３５は、出力側（ノートＰＣ１１１が接続される）ＳＴＡ１０５における受信フレームの処理フローを示す図である。図３５では、ＳＴＡ１０５において、ファイルデータの転送を行う場合を示している。
図３５において、３５０１は無線ＬＡＮ制御部２０６から受信したIEEE802.11無線データをIEEE802.3変換処理部７０６で802.3ヘッダに変換されたIEEE802.3受信処理フレームである。また、メモリ制御処理（ネットワーク側）７０２は、IEEE802.3受信処理フレームを記憶領域部２０８にある受信用バッファメモリ（mbuf）に対して書込み制御を実施する。３５０２は受信用バッファメモリ（mbuf）にあるIEEE802.3受信処理フレーム３５０１の802.3ヘッダがIEEE802.3変換処理部７０６で除去されたＩＰ送受信処理フレームである。３５０３はＩＰ送信処理フレーム３５０１にイーサフレームヘッダ変換処理部３４００でＥＴＨヘッダを付加したＥＴＨ送信処理フレームである。
ここで、図３３に示すシーケンスに従ってアプリ種別が動画の場合はＲＴＰを使用し、ファイル転送の場合はＴＣＰを使用してデータ伝送を行う処理の詳細を説明する。
図３６は、第４の実施形態における送信側ＳＴＡ１０２の処理を示すフローチャートである。また、図３７は、第４の実施形態における受信側ＳＴＡ１０５の処理を示すフローチャートである。
図３３において、一連のメッセージ（Ｍ４０１〜Ｍ４０９、Ｍ２２０１〜Ｍ２２０３）及びメッセージ交換に関連するそれぞれの制御処理は、第３の実施形態（図２２）と同様であり、その説明は省略する。
また、ノートＰＣ１１１は、ＨＤＲ１０８とＩＰネットワーク上で接続され、ＨＤＲ１０８の内部データにアクセスする場合には、例えばノートＰＣ１１１上のＷＥＢビューアアプリケーションを用いる。そして、ＨＤＲ１０８内部で起動中のＨＴＴＰサーバ機能を利用するものとする。また、ＨＤＲ１０８の内部データは、メニュー形式で選択することが可能であり、録画済みの番組の確認や再生、録画データのバックアップを目的とした、複写・保存操作ができる。このように、受信側デバイスであるノートＰＣ１１１の画面上では、ＨＤＲ１０８内に保存されるデータファイルの一覧が参照できる（データファイル取得シーケンス（Ｍ３３００）に相当する）。
このとき、ＨＤＲ１０８にある動画像ファイルに対して実行されるサービスとしては、図３２に示すように、例えば「動画再生」及び「複写・保存」などがある。「動画再生」サービスの場合、図３２に示すアプリ種別管理テーブルのエントリ番号４が選択される。即ち、この場合は、アプリケーション３２０２として「ビデオストリーム」が使用され、プロトコル処理として「RTP/RTCP」が使用される。また、「複写・保存」サービスの場合、エントリ番号３が選択され、アプリケーション３２０２として「ファイル転送」が使用され、プロトコル処理として「TCP」が使用される。
データファイル取得シーケンス（Ｍ３３００）により、ノートＰＣ１１１の画面上で、ＨＤＲ１０８内に保存される再生ファイルの一覧を参照し、所望の動画ファイルに対するサービスとして「動画再生」が選択されるとステップＳ９０５へ進む。ステップＳ９０５では、ノートＰＣ１１１はＨＤＲ１０８を特定する情報とアプリ種別情報に「ストリームデータ」を含む接続要求メッセージ（Ｍ３３０１）を有線ＬＡＮケーブル１１５を介してＳＴＡ１０５に送信する。
一方、ステップＳ３７０１において、ＳＴＡ１０５がノートＰＣ１１１からメッセージを受信し、そのメッセージが接続要求メッセージ（Ｍ３３０１）の場合はステップＳ３７１４へ進む。ステップＳ３７１４では、接続要求メッセージ（Ｍ３３０１）に含まれる、ノートＰＣ１１１の指定したアプリ種別「ストリームデータ」を記憶領域部２０８に格納する。そして、ステップＳ３７１５において、ＱＡＰ１０６のダイレクトリンクサービスの制御下において異なるＳＴＡとの直接通信が可能か否かの判断を行い、直接通信が不可能な場合はステップＳ３７１７へ進む。ステップＳ３７１７では、通信不可能である旨の情報を含む接続応答メッセージ（Ｍ３３０７）をノートＰＣ１１１に送信し、ステップＳ３７０１に戻る。また、直接通信が可能な場合はステップＳ３７１６へ進み、ダイレクトリンクサービスの設定要求（ＤＬＳ要求）メッセージ（Ｍ４１２）をＱＡＰ１０６に送信し、ステップＳ３７０１に戻る。
このメッセージ（Ｍ４１２）を受信し、（Ｍ４１５）を送信するまでのＱＡＰ１０６の処理は第３の実施形態と同様であり、その説明は省略する。
また、ステップＳ３７０１において、ＳＴＡ１０５がＱＡＰ１０６からメッセージを受信し、そのメッセージがＤＬＳ応答メッセージ（Ｍ４１５）の場合はステップＳ３７０４へ進む。ステップＳ３７０４では、記憶領域部２０８に格納したアプリ種別「ストリームデータ」を含む接続要求メッセージ（Ｍ３３０２）をＳＴＡ１０２に送信する。そして、ステップＳ３７０５において、その接続要求メッセージ（Ｍ３３０２）の応答メッセージ待ち状態となる。
一方、ステップＳ３６０１において、ＳＴＡ１０２がＳＴＡ１０５から接続要求メッセージ（Ｍ３３０２）を受信するとステップＳ３６０４へ進む。ステップＳ３６０４では、デバイス管理テーブルのデバイス管理情報に基づいてインターフェース種別が一致するか否かを判断する。ここで、インターフェース種別が異なる場合はステップＳ３６１９へ進み、通信不可能である旨の情報を含む接続応答メッセージをＳＴＡ１０５に送信し、ステップＳ３６０１に戻る。また、整合性を検証し、送受信デバイス双方共にインターフェース種別が一致する場合はステップＳ３６０５へ進む。
ステップＳ３６０５では、接続要求メッセージ（Ｍ３３０２）に含まれるアプリ種別「ストリームデータ」を記憶領域部２０８に格納し、アプリ種別情報「ストリームデータ」を含む接続要求メッセージ（Ｍ３３０３）をＨＤＲ１０８に送信する。そして、ステップＳ３６０６において、EEE802.11eで規定される帯域予約（Ｍ３３０４）をＱＡＰ１０６との間で行う。そして、ステップＳ５３０７において、帯域予約（Ｍ３３０４）が完了するとステップＳ３６０８へ進み、ＨＤＲ１０８からの接続応答メッセージ（Ｍ３３０５）の受信確認待ち状態となる。
ここで、ＨＤＲ１０８の処理は、第３の実施形態と同様であり、その説明は省略する。そして、ステップＳ３６０８において、ＳＴＡ１０２がＨＤＲ１０８から接続応答メッセージ（Ｍ３３０５）を受信するとステップＳ３６０９へ進み、接続応答メッセージ（Ｍ３３０６）をＳＴＡ１０５に送信する。そして、ステップＳ３６１０で、ＨＤＲ１０８からのデータ受信待ち状態に遷移する。
一方、ステップＳ３７０５において、ＳＴＡ１０５がＳＴＡ１０２から接続応答メッセージ（Ｍ３３０６）を受信するとステップＳ３７０６へ進む。ステップＳ３７０６では、接続要求メッセージ（Ｍ３３０１）に対する応答を示す接続応答メッセージ（Ｍ３３０７）をノートＰＣ１１１に送信し、ステップＳ３７０７で、ＳＴＡ１０２からのデータ受信待ち状態に遷移する。ここで、ノートＰＣ１１１の処理は、第３の実施形態と同様であり、その説明は省略する。
次に、ステップＳ３６１０において、データ受信待ち状態にあるＳＴＡ１０２がＨＤＲ１０８からデジタル動画データ（Ｍ３３０８）を受信するとステップＳ３６１１へ進み、記憶領域部２０８に格納したアプリ種別を確認する。ここで、アプリ種別が「ストリームデータ」の場合、通信プロトコルにＲＴＰを使用するため、ステップＳ３６１２のＹＥＳからステップＳ３６１３へ進む。ステップＳ３６１３で、ＳＴＡ１０５に送信する動画像データ（Ｍ３３０９）の送信処理時において、ＲＴＰプロトコルヘッダの付加処理を起動するように制御処理に設定し、ステップＳ３６１４でデータ送信処理を実施する。また、例えばエントリ番号７にある監視カメラなどのモニタリングシステムで通信プロトコルにＵＤＰを使用する場合も、アプリ種別が「ストリームデータ」でＲＴＰを使用する。しかし、この場合は、ステップＳ３６１２からステップＳ３６１４へ進み、ＲＴＰプロトコルヘッダの付加処理の起動制御を回避して、データ送信処理を実施する。そして、ステップＳ３６１５において、通信の完了を確認し、通信完了で、接続中状態に遷移する。また、通信継続の場合にはステップＳ３６１０に戻り、データ受信処理を繰り返す。
一方、ＳＴＡ１０２から動画像データ（Ｍ３３０９）を受信したＳＴＡ１０５での処理は、第３の実施形態と同様であり、その説明は省略する。
ここで、動画像ファイルに対するサービスとして「複写・保存」を選択した際のアプリ種別情報である「ファイル転送」処理を説明する。
ノートＰＣ１１１で動画像データ（Ｍ３３１０）の再生を停止し、データファイル取得シーケンス（Ｍ３３００）と同様に、ノートＰＣ１１１の画面上でＨＤＲ１０８内に保存された再生ファイルの一覧を参照する。そして、ユーザが所望の動画ファイルの「保存」を選択すると、ノートＰＣ１１１はアプリ種別情報に「ファイル転送」と指定ファイル情報を含む複写・保存要求メッセージ（Ｍ３３１１）をＳＴＡ１０５に送信する。
一方、ＳＴＡ１０５がノートＰＣ１１１から複写・保存要求メッセージ（Ｍ３３１１）を受信すると、メッセージに含まれるアプリ種別「ファイル転送」を記憶領域部２０８に格納する。そして、ＨＤＲ１０８の接続されたＳＴＡ１０２に対して、アプリ種別情報に「ファイル転送」と指定ファイル情報を含む複写・保存要求メッセージ（Ｍ３３１２）を送信する。
ここで、ＳＴＡ１０２がＳＴＡ１０５から複写・保存要求メッセージ（Ｍ３３１２）を受信すると、メッセージに含まれるアプリ種別「ファイル転送」を記憶領域部２０８に格納する。そして、アプリ種別情報に「ファイル転送」と指定ファイル情報を含む複写・保存要求メッセージ（Ｍ３３１３）をＨＤＲ１０８に送信する。
これにより、ＨＤＲ１０８がアプリ種別情報に「ファイル転送」と指定ファイル情報を含む複写・保存要求メッセージ（Ｍ３３１３）を受信すると、指定ファイル情報より該当する動画動ファイルデータ（Ｍ３３１４）をＳＴＡ１０２に送信する。
一方、動画像データの場合と同様に、ＳＴＡ１０２がＨＤＲ１０８から動画動ファイルデータ（Ｍ３３１４）を受信すると、記憶領域部２０８に格納したアプリ種別を確認する。ここで、アプリ種別が「ファイル転送」の場合は、通信プロトコルにＴＣＰを使用するためステップＳ３６１１のＹＥＳへ進み、ステップＳ３６１４のデータ送信処理でＳＴＡ１０５に動画動ファイルデータ（Ｍ３３１５）を送信する。これ以降の処理は、上述した動画像データの場合と同様である。
一方、ＳＴＡ１０５が動画像ファイルデータ（Ｍ３３１５）を受信すると、ステップＳ３７０８でデータ解析を行う。ここで、受信したデータにRTP/RTCPプロトコルヘッダ情報が付加されていないので、ステップＳ３７１１へ進み、ＲＴＰを使用しないＴＣＰによるデータ受信処理を行う。そして、ステップＳ３７１２において、動画像ファイルデータ（Ｍ３３１６）をノートＰＣ１１１に送信し、ステップＳ３７１３で通信の完了を確認し、通信完了であれば、接続中状態に遷移する。また、通信継続の場合はステップＳ３７０７に戻り、データ受信処理を繰り返す。
以上、ＳＴＡ１０２とＳＴＡ１０５において、ＨＤＲ１０８とノートＰＣ１１１のデバイス間で起動されるアプリケーションの種別に応じて使用するプロトコル処理を制御する。これにより、確実性の要求される送受信データに対する不要なＱｏＳ関連プロトコルの付加処理を回避できる。従って、リアルタイム性の要求される入出力データに対する適切なＱｏＳ関連プロトコル処理を提供することが可能となる。
［第５の実施形態］
次に、図面を参照しながら本発明に係る第５の実施形態について詳細に説明する。第５の実施形態では、ＤＶＣ１０９と液晶テレビ１１０のように、デバイスが異なるインターフェースでＳＴＡに接続される場合について説明する。
図３８は、ＤＶＣ１０９から液晶テレビ１１０へ直接動画をストリーム伝送する状態を示す図である。図３８に示すように、ＤＶＣ１０９はＵＳＢケーブル１１６を介してＳＴＡ１０３に接続され、液晶テレビ１１０はIEEE1394ケーブル１１４を介してＳＴＡ１０４に接続される。
図３９は、図３８に示すストリーム伝送で送受信されるメッセージのシーケンスを示す図である。また、図３９に示すシーケンス内のメッセージは、第５の実施形態に関する主なもののみを明記し、一部のメッセージについては省略している。
図４０は、図３９に示す送信側ＳＴＡ１０３における送信フレームの処理フローを示す図である。図４０に示す例は、ＤＶＣ１０９がＱｏＳプロトコル処理をサポートしていない場合である。図４０において、４００１はデバイス側のメモリ制御処理であり、ＤＶＣ１０９からＵＳＢ制御部２１０を介して受信した動画像データを記憶領域部２０８のデコード用バッファメモリ（Dbuf）に書き込む。ＲＴＰ処理部５０３以降は、図５に示す第１の実施形態と同様であり、その説明は省略する。
図４１は、ＤＶＣ１０９がＱｏＳプロトコル処理をサポートする場合の送信フレームの処理フローを示す図である。尚、図４１は、デバイス側のメモリ制御処理が異なるだけで、図６に示す第１の実施形態と同様であり、その説明は省略する。
また、受信側ＳＴＡ１０４における受信フレームの処理は、図７及び図８に示す第１の実施形態と同様であり、その説明は省略する。
ここで、図３９に示すシーケンスに従ってＤＶＣ１０９から液晶テレビ１１０へ動画をストリーム伝送する処理の詳細を説明する。
図４２は、第５の実施形態における送信側ＳＴＡ１０３の処理を示すフローチャートである。図４３は、第５の実施形態における受信側ＳＴＡ１０４の処理のフローチャートである。
図３９に示すシーケンスにおいて、まず送信デバイス側ＳＴＡ１０３がＱＡＰ１０６のサービスエリア内に設置されるか、ＳＴＡ１０３の電源が投入されると、ＱＡＰ１０６との間でアソシエーション処理（Ｍ４０１）を行う。そして、ステップＳ１００１において、ＳＴＡ１０３がアソシエーション処理（Ｍ４０１）を完了するとステップＳ１００２へ進み、ＳＴＡ１０３はＤＶＣ１０９とのＵＳＢ接続シーケンス処理（Ｍ３９０１）の完了判定を行う。
一方、送信デバイスであるＤＶＣ１０９では、ＳＴＡ１０３との接続操作、或いはデバイス本体の電源投入などが行われる。そして、ステップＳ９０１で、ＳＴＡ１０３との間でＵＳＢ接続シーケンス処理（Ｍ３９０１）を完了するとステップＳ９０２へ進み、システム内に収容する全てのＳＴＡの更新情報をＳＴＡ１０３から受信する。
次に、ＳＴＡ１０４におけるアソシエーション処理（Ｍ４０２）、液晶テレビ１１０におけるIEEE1394接続シーケンス処理（Ｍ４０４）、種別登録処理が第１の実施形態と同様に行われる。
次に、液晶テレビ１１０の画面上にあるシステム内に接続収容されている送受信可能なデバイスの収容状況、性能、及び状態を明示したアイコンよりＤＶＣ１０９が選択されるとステップＳ９０５へ進む。ステップＳ９０５では、液晶テレビ１１０はＤＶＣ１０９を特定する情報と動画像データのフォーマット形式（MPEG-TS）を含む接続要求メッセージ（Ｍ３９０３）をＳＴＡ１０４に送信する。
一方、ステップＳ４３０１において、ＳＴＡ１０４が液晶テレビ１１０から接続要求のメッセージを受信するとステップＳ４３１３へ進み、液晶テレビ１１０の「動画像データのフォーマット形式（MPEG-TS）情報」を記憶領域部２０８に格納する。次に、ステップＳ４３１４において、ＱＡＰ１０６のダイレクトリンクサービスの制御下において異なるＳＴＡとの直接通信が可能か否かの判断を行い、直接通信が不可能な場合はステップＳ４３１６へ進む。ステップＳ４３１６では、通信不可能である旨の情報を含む接続応答メッセージ（Ｍ３９０８）を液晶テレビ１１０に送信し、ステップＳ４３０１に戻る。また、直接通信が可能な場合はステップＳ４３１５へ進み、ダイレクトリンクサービスの設定要求（ＤＬＳ要求）メッセージ（Ｍ４１２）をＱＡＰ１０６に送信し、ステップＳ４３０１に戻る。
ここで、ＱＡＰ１０６、ＳＴＡ１０３、及びＳＴＡ１０４との間でＤＬＳ処理が第１の実施形態と同様に行われ、ＳＴＡ１０４がＤＬＳ応答メッセージ（Ｍ４１５）を受信するとステップＳ４３０４へ進む。ステップＳ４３０４では、ＤＶＣ１０９を特定する情報と記憶領域部２０８に格納した液晶テレビ１１０の「動画像データのフォーマット形式情報（MPEG-TS）」とを含む接続要求メッセージ（Ｍ３９０４）をＳＴＡ１０３に送信する。そして、ステップＳ４３０５において、接続応答メッセージ待ち状態となる。
一方、ＳＴＡ１０３がＳＴＡ１０４から接続要求メッセージ（Ｍ３９０４）を受信するとステップＳ４２０４へ進み、転送モードや通信情報が一致するか判定する。この処理は接続要求メッセージに含まれる要求元（受信デバイス側）ＳＴＡ１０４の識別情報に基づいて判定を行う。ここで、動画像ストリームの通信が可能と判断された場合はステップＳ４２０５へ進み、動画像データのフォーマット形式情報（MPEG-TS）を記憶領域部２０８に格納する。そして、動画像データのフォーマット形式情報（MPEG-TS）を含む接続要求メッセージ（Ｍ３９０５）をＤＶＣ１０９に送信する。
そして、ステップＳ４２０６において、ＤＶＣ１０９から動画像データのフォーマット形式情報（MPEG-TS）を含む接続応答メッセージ（Ｍ３９０６）を受信するとステップＳ４２０７へ進む。ステップＳ４２０７では、動画像データのフォーマット形式情報（MPEG-TS）を含む接続要求メッセージ（Ｍ３９０７）をＳＴＡ１０４に送信する。そして、ステップＳ４２０８において、IEEE802.11e標準で規定される帯域予約シーケンス（Ｍ３９０９）をＱＡＰ１０６との間で行う。
次に、ステップＳ４２０９において、帯域予約シーケンス（Ｍ３９０９）が完了するとステップＳ４２１０へ進み、接続完了表示メッセージ（Ｍ３９１０）をＤＶＣ１０９に送信する。この時点では、ＤＶＣ１０９からの送信データを受けていないため、ステップＳ４２１１のデータ受信待ち状態に遷移する。これ以降、動画像データの受信処理が第１の実施形態と同様に行われる。
一方、ステップＳ４３０５において、ＳＴＡ１０４が動画像データのフォーマット形式情報（MPEG-TS）を含む接続要求メッセージ（Ｍ３９０７）を受信するとステップＳ４３０６へ進む。ステップＳ４３０６では、動画像データのフォーマット形式情報（MPEG-TS）を含む接続応答メッセージ（Ｍ３９０８）を液晶テレビ１１０に送信し、データ受信待ち状態へ遷移する。その後、第１の実施形態と同様に、ＤＶＣ１０９からＳＴＡ１０３へ動画像データが送信され、ＳＴＡ１０４を介して液晶テレビ１１０に送信される。
以上、ＳＴＡ１０３とＳＴＡ１０４において、デバイス間のインターフェースにおける転送モードの整合性を検証することにより、効果的なＱｏＳ関連プロトコルの付加処理を行うことができる。従って、リアルタイム性の要求される入出力データに対する適切なＱｏＳ関連プロトコル処理を提供することが可能となる。
［他の実施形態］
上述した実施形態では、ＳＴＡがデバイスのＱｏＳ対応状況を把握し、動画像データに対してＲＴＰヘッダの付加或いは除去を行い、リアルタイム性の要求される入出力データに対する適切なＱｏＳ関連プロトコル処理のサポートについて説明した。しかし、ＲＴＰヘッダ以下のＲＴＰペイロードを拡張し、送信側ＳＴＡの入力デバイスからのデータ受信処理におけるバッファメモリの使用状況を受信側ＳＴＡに送信し、メモリバッファ制御用の情報として使用するようにしても良い。
図４４は、他の実施形態１におけるＲＴＰ送信処理フレームを示す図である。図４４に示すように、ＲＴＰペイロードを拡張して受信側ＳＴＡのバッファ情報を送信するものである。ここで、「全バッファ」とは、受信側ＳＴＡの受信バッファの総数であり、「空きバッファ」とは、受信側ＳＴＡの受信バッファの空きバッファ数である。
以上、メモリバッファの状態情報の送信により、送受信するＳＴＡ間でのバッファオーバーラン、及びバッファアンダーランの発生を抑制し、メモリバッファ制御処理が可能となる。これにより、リアルタイム性の要求される入出力データに対する更に適切なＱｏＳが実現される。
上述した実施形態では、種別登録を行った後、システム内に収容する全ての端末の更新情報である種別情報をデバイスに送信しているが、図４５に示すように、この処理を省略しても良い。
図４５は、他の実施形態２におけるメッセージのシーケンスを示す図である。図４５に示すように、ＳＴＡと任意のデバイス間をIEEE1394ケーブルで接続した際のバスＩＤ及びノードＩＤを用いて特定の機器を識別する。これにより、接続初期時における所定の設定処理の一部を省略することができる。
この場合、任意の入出力デバイスとＳＴＡ間の接続形態がIEEE1394インターフェース、又はＵＳＢインターフェースの場合、デバイス識別情報を図４６に示すように管理しても良い。
図４６は、ＳＴＡと任意のデバイスをIEEE1394ケーブル又はＵＳＢケーブルで接続した際のインターフェース毎の識別子と転送モードとを対応させたテーブルである。図４６において、４６０１はIEEE1394インターフェースのバスＩＤである。４６０２はIEEE1394インターフェースのノードＩＤである。４６０３はＵＳＢインターフェースのアドレスである。そして、４６０４はＩＤ毎の転送モードであり、４６０５はＩＤ毎のＱｏＳサポート状況を示したものである。
また、通信終了時に、使用したサービス固有のアプリケーション種別の履歴を保存し、データ通信の再起動時に、前回のデータ通信で使用したサービス固有のアプリケーション種別の履歴を読み出し、ＱｏＳ関連プロトコル処理を制御しても良い。
図４７は、ＵＳＢインターフェースのアプリケーションを識別する図である。図４７において、４７０１はアプリケーション１のエンドポイント群であり、４７０２はアプリケーション２のエンドポイント群である。
図４７に示すように、ＳＴＡとデバイスにおいて、エンドポイント毎にサービスを区別し、対応するＱｏＳ関連プロトコルの処理を制御する。
上述した第３の実施形態では、ユーザプライオリティを解析し、ＱｏＳ関連プロトコル処理を制御しているが、図４８に示すように、RSVP、IntServ、DiffServの使用に応じて制御しても良い。
図４８は、他の実施形態におけるデバイス管理情報の構成を示す図である。４８０１はＳＴＡ１０２のＱｏＳ処理（DiffServ）のサポートを示し、４８０２はＳＴＡ１０５のＱｏＳ処理（DiffServ）のサポートを示す。また、４８０３はＳＴＡ１０２のＱｏＳ処理（IntServ/RSVP）のサポートを示し、４８０４はＳＴＡ１０５のＱｏＳ処理（IntServ/RSVP）のサポートを示す。
また、種別情報メッセージをＱＡＰ１０６から受信した際に、記憶領域部２０８に保存しているが、ＳＴＡに接続されるデバイスの電源オフやインターフェースの切断の際に、デバイス情報を削除する。
図４９は、デバイス管理情報の消去を説明するための図である。図４９において、４９０１は切断されたデバイスの管理情報を検出し、４９０２はその管理情報を削除した状態である。
また、デバイスとＳＴＡとの間のインターフェース種別が「IEEE1394」で、転送モードが「アイソクロナス」によるストリーム型の動画像データ通信を説明したが、これだけに限るものではない。例えば、インターフェース種別が「USB」で、転送モードが「アイソクロナス」によるストリーム型の動画像データ通信でに適用することができる。
また、システム端末情報メッセージに含まれるデバイスの最新情報として、全収容中のデバイスとＳＴＡの情報ではなく、新規で登録されたデバイス情報の差分のみを送信するようにしても良い。更に、システム端末情報メッセージは新規接続収容手順が実施される度に、収容中の全ＳＴＡに送信されるように構成しても良い。
以上説明した実施形態によれば、入出力機能を備えたデバイスをＩＰネットワーク環境に収容する際に用いられるアダプタ装置において、デバイス間で送受信される通信データに対するＱｏＳ関連プロトコルの冗長性を回避できる。
また、リアルタイム性の要求される入出力データに対する適切なＱｏＳ関連プロトコルのカプセル化、デカプセル化が可能となる。
本実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵ若しくはＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行する。これによっても、本発明の目的が達成されることは言うまでもない。
この場合、記録媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
このプログラムコードを供給するための記録媒体として、例えばフレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、次の場合も含まれることは言うまでもない。即ち、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合である。
更に、記録媒体から読出されたプログラムコードがコンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込む。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
第１の実施形態における無線通信システムの構成の一例を示す図である。 第１の実施形態における無線アダプタ装置のソフトウェア構成を示す図である。 チューナー１０７から液晶テレビ１１０へ直接動画をストリーム伝送する状態を示す図である。 図３に示すストリーム伝送で送受信されるメッセージのシーケンスを示す図である。 図４に示す送信側ＳＴＡ１０１における送信フレームの処理フローを示す図である。 チューナー１０７がＱｏＳプロトコル処理をサポートする場合の送信フレームの処理フローを示す図である。 図４に示す受信側ＳＴＡ１０４における受信フレームの処理フローを示す図である。 液晶テレビ１１０がＱｏＳプロトコル処理をサポートしている場合の受信フレームの処理フローを示す図である。 第１の実施形態における入出力デバイスの処理を示すフローチャートである。 第１の実施形態における無線アダプタ装置の共通処理を示すフローチャートである。 第１の実施形態における送信側ＳＴＡ１０１の処理を示すフローチャートである。 第１の実施形態における受信側ＳＴＡ１０４の処理を示すフローチャートである。 、 第１の実施形態におけるＱＡＰ１０６の処理を示すフローチャートである。 第１の実施形態におけるＲＴＰ処理の実装状態と無線データ形式との関係を示すテーブルである。 デバイス管理テーブルの構成の一例を示す図である。 デバイス転送モードと使用プロトコルの関連テーブルを示す図である。 第２の実施形態におけるストリーム伝送で送受信されるメッセージのシーケンスを示す図である。 第２の実施形態における送信側ＳＴＡ１０１の処理を示すフローチャートである。 第２の実施形態における受信側ＳＴＡ１０４の処理を示すフローチャートである。 ＨＤＲ１０８からノートＰＣ１１１へ直接動画をストリーム伝送する状態を示す図である。 図２１に示すストリーム伝送で送受信されるメッセージのシーケンスを示す図である。 入力側（ＨＤＲ１０８が接続される）ＳＴＡ１０２における受信フレームの処理フローを示す図である。 入力側（ＨＤＲ１０８が接続される）ＳＴＡ１０２における送信フレームの処理フローを示す図である。 出力側（ノートＰＣ１１１が接続される）ＳＴＡ１０５における受信フレームの処理フローを示す図である。 出力側（ノートＰＣ１１１が接続される）ＳＴＡ１０５における送信フレームの処理フローを示す図である。 IEEE802.1p準拠のユーザプライオリティフィールドを持つIEEE802.1QのVLANタグヘッダ送信フレーム（IEEE802.1p）の構成を示す図である。 ＵＰとＱｏＳプロトコル処理との関係を表す管理テーブルである。 無線MAC送信フレーム（８０２．３）の構成を示す図である。 第３の実施形態における送信側ＳＴＡ１０２の処理を示すフローチャートである。 第３の実施形態における受信側ＳＴＡ１０５の処理を示すフローチャートである。 第４の実施形態におけるアプリ種別とＱｏＳプロトコル処理対応テーブルの構成を示す図である。 第４の実施実施形態におけるメッセージのシーケンスを示す図である。 入力側（ＨＤＲ１０８が接続される）ＳＴＡ１０２における送受信フレームの処理フローを示す図である。 出力側（ノートＰＣ１１１が接続される）ＳＴＡ１０５における受信フレームの処理フローを示す図である。 第４の実施形態における送信側ＳＴＡ１０２の処理を示すフローチャートである。 第４の実施形態における受信側ＳＴＡ１０５の処理を示すフローチャートである。 ＤＶＣ１０９から液晶テレビ１１０へ直接動画をストリーム伝送する状態を示す図である。 図３８に示すストリーム伝送で送受信されるメッセージのシーケンスを示す図である。 図３９に示す送信側ＳＴＡ１０３における送信フレームの処理フローを示す図である。 ＤＶＣ１０９がＱｏＳプロトコル処理をサポートする場合の送信フレームの処理フローを示す図である。 第５の実施形態における送信側ＳＴＡ１０３の処理を示すフローチャートである。 第５の実施形態における受信側ＳＴＡ１０４の処理のフローチャートである。 他の実施形態１におけるＲＴＰ送信処理フレームを示す図である。 他の実施形態２におけるメッセージのシーケンスを示す図である。 ＳＴＡと任意のデバイスをIEEE1394ケーブル又はＵＳＢケーブルで接続した際のインターフェース毎の識別子と転送モードとを対応させたテーブルである。 ＵＳＢインターフェースのアプリケーションを識別する図である。 他の実施形態におけるデバイス管理情報の構成を示す図である。 デバイス管理情報の消去を説明するための図である。

Claims (12)

  1. 通信装置の制御方法であって、
    前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定工程と、
    前記判定工程における判定に応じて、前記端末装置との間で送受信する通信データを変換する変換工程と、を有し、
    前記判定工程では、前記通信装置に接続される端末装置からの通信の設定メッセージを解析し、当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、
    前記変換工程では、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする通信装置の制御方法。
  2. 通信装置の制御方法であって、
    前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定工程と、
    前記判定工程における判定に応じて、前記端末装置との間で送受信する通信データを変換する変換工程と、を有し、
    前記判定工程では、前記端末装置との間のインターフェース種別と転送モードとに基づいて当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、
    前記変換工程では、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする通信装置の制御方法。
  3. 通信装置の制御方法であって、
    前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定工程と、
    前記判定工程における判定に応じて、前記端末装置との間で送受信する通信データを変換する変換工程と、を有し、
    前記判定工程では、前記通信装置に接続される端末装置との間で送受信される通信データを解析し、当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、
    前記変換工程では、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする通信装置の制御方法。
  4. 通信装置の制御方法であって、
    前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定工程と、
    前記判定工程における判定に応じて、前記端末装置との間で送受信する通信データを変換する変換工程と、を有し、
    前記判定工程では、前記通信装置に接続される端末装置との間で送受信される通信データに含まれるプライオリティに関する情報に応じて当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、
    前記変換工程では、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする通信装置の制御方法。
  5. 通信装置の制御方法であって、
    前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定工程と、
    前記判定工程における判定に応じて、前記端末装置との間で送受信する通信データを変換する変換工程と、を有し、
    前記判定工程では、前記通信装置に接続される端末装置が送信する通信データのアプリケーション種別に基づいて当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、
    前記変換工程では、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする通信装置の制御方法。
  6. 請求項１乃至５の何れか一項記載の通信装置の制御方法をコンピュータに実行させるためのプログラム。
  7. 請求項６記載のプログラムを記録したコンピュータにより読み取り可能な記録媒体。
  8. 通信装置であって、
    前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定手段と、
    前記判定手段による判定に応じて、前記端末装置との間で送受信する通信データを変換する変換手段と、を有し、
    前記判定手段は、前記通信装置に接続される端末装置からの通信の設定メッセージを解析し、当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、
    前記変換手段は、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする通信装置。
  9. 通信装置であって、
    前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定手段と、
    前記判定手段による判定に応じて、前記端末装置との間で送受信する通信データを変換する変換手段と、を有し、
    前記判定手段は、前記端末装置との間のインターフェース種別と転送モードとに基づいて当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、
    前記変換手段は、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする通信装置。
  10. 通信装置であって、
    前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定手段と、
    前記判定手段による判定に応じて、前記端末装置との間で送受信する通信データを変換する変換手段と、を有し、
    前記判定手段は、前記通信装置に接続される端末装置との間で送受信される通信データを解析し、当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、
    前記変換手段は、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする通信装置。
  11. 通信装置であって、
    前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定手段と、
    前記判定手段による判定に応じて、前記端末装置との間で送受信する通信データを変換する変換手段と、を有し、
    前記判定手段は、前記通信装置に接続される端末装置との間で送受信される通信データに含まれるプライオリティに関する情報に応じて当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、
    前記変換手段は、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする通信装置。
  12. 通信装置であって、
    前記通信装置に接続される端末装置が実時間伝送プロトコルをサポートしているか否かを判定する判定手段と、
    前記判定手段による判定に応じて、前記端末装置との間で送受信する通信データを変換する変換手段と、を有し、
    前記判定手段は、前記通信装置に接続される端末装置が送信する通信データのアプリケーション種別に基づいて当該端末装置が実時間伝送プロトコルをサポートしているか否かを判定し、
    前記変換手段は、前記端末装置から受信した通信データに前記実時間伝送プロトコルで規定されるヘッダーを付加し、或いは前記端末装置へ送信する通信データから前記ヘッダーを削除することを特徴とする通信装置。
JP2006128578A 2006-05-02 2006-05-02 通信装置及びその制御方法 Expired - Fee Related JP4963566B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2006128578A JP4963566B2 (ja) 2006-05-02 2006-05-02 通信装置及びその制御方法
US11/742,767 US8081653B2 (en) 2006-05-02 2007-05-01 Communication apparatus and control method thereof

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006128578A JP4963566B2 (ja) 2006-05-02 2006-05-02 通信装置及びその制御方法

Publications (3)

Publication Number Publication Date
JP2007300555A JP2007300555A (ja) 2007-11-15
JP2007300555A5 JP2007300555A5 (ja) 2009-06-18
JP4963566B2 true JP4963566B2 (ja) 2012-06-27

Family

ID=38661071

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006128578A Expired - Fee Related JP4963566B2 (ja) 2006-05-02 2006-05-02 通信装置及びその制御方法

Country Status (2)

Country Link
US (1) US8081653B2 (ja)
JP (1) JP4963566B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4968021B2 (ja) * 2007-11-29 2012-07-04 ブラザー工業株式会社 通信装置とコンピュータプログラム
DE102008049600A1 (de) * 2008-09-30 2010-04-01 Bayerische Motoren Werke Aktiengesellschaft Ethernet-MOST-Gateway-Einrichtung und Verfahren zum Koppeln eines Ethernet-Netzknotens mit einem MOST-Empfänger
JP4490499B2 (ja) * 2008-11-26 2010-06-23 パナソニック株式会社 通信端末、中継機器、無線通信システム、無線通信制御方法、及びプログラム
JP6032278B2 (ja) * 2012-03-28 2016-11-24 富士通株式会社 Ｌａｎ多重化装置

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6560242B1 (en) * 1999-04-16 2003-05-06 Alcatel Canada Inc. Method and apparatus for connection format conversion in a communications network
US7158491B1 (en) * 1999-11-05 2007-01-02 Nokia Corporation Terminal-based link adaptation scheme having a detector which monitors application signaling and a requestor which requests a special channel based on the detection
JP2001186193A (ja) * 1999-12-24 2001-07-06 Fujitsu Ltd Ｉｐ通信インタフェース装置、回線交換機及びｉｐ通信ネットワークシステム
JP4407007B2 (ja) 2000-05-02 2010-02-03 ソニー株式会社 データ送信装置及び方法
JP4265087B2 (ja) * 2000-06-29 2009-05-20 ソニー株式会社 データ変換装置及び方法、データ送受信装置及び方法、ネットワークシステム
US20050037779A1 (en) * 2000-12-08 2005-02-17 Clarinet Systems, Inc. Method and interface for facilitating communication of location specific contents between a wireless device and other devices or systems via an interface
ES2258160T3 (es) * 2001-09-26 2006-08-16 Siemens Aktiengesellschaft Procedimiento para la transmision de un telegrama de datos entre un dominio en tiempo real y un dominio no en tiempo real y unidad de acoplamiento.
US20030219007A1 (en) * 2002-05-23 2003-11-27 Craig Barrack Reusable multi-protocol meta-architecture for Voice-over-IP playback
US7315553B2 (en) * 2002-08-15 2008-01-01 Alcatel Lucent Integrated server module and method of resource management therefor
US7688833B2 (en) * 2002-08-30 2010-03-30 Nortel Networks Limited Synchronous transmission network node
US7430602B2 (en) * 2002-12-20 2008-09-30 Qualcomm Incorporated Dynamically provisioned mobile station and method therefor
KR100547139B1 (ko) * 2003-09-03 2006-01-26 학교법인 고황재단 ＩＥＴＦ ＱｏＳ 프로토콜을 이용한 ＭＰＥＧ 미디어데이터 전송 방법 및 장치
US20050071427A1 (en) * 2003-09-29 2005-03-31 Elmar Dorner Audio/video-conferencing with presence-information using content based messaging
US20050124306A1 (en) * 2003-12-05 2005-06-09 Cheng Brett A. Method and apparatus for obtaining and maintaining accurate time
US7571249B2 (en) * 2005-04-15 2009-08-04 Alcatel Lucent System and method for routing communication sessions based on priority, presence and preference information
US20070178901A1 (en) * 2006-02-01 2007-08-02 Airnet Communications Corporation Distributed base station controller

Also Published As

Publication number Publication date
US8081653B2 (en) 2011-12-20
JP2007300555A (ja) 2007-11-15
US20070258367A1 (en) 2007-11-08

Similar Documents

Publication Publication Date Title
JP5288710B2 (ja) マルチメディアデータを記録した情報保存媒体、その再生方法及び再生装置
EP1113644B1 (en) Data transfer method and radio terminal for executing transport layer protocol on radio network
US20010013128A1 (en) Data reception/playback method, data reception/playback apparatus, data transmission method, and data transmission apparatus
US20190014358A1 (en) Information processing apparatus and information processing method
US20030122862A1 (en) Data processing apparatus, data processing server, data processing system, method of controlling data processing apparatus, method of controlling data processing server, computer program, and computer readable storage medium
JP2002010182A (ja) データ蓄積方法およびそれを実現した受信装置および放送システム
US9509947B2 (en) Method and apparatus for transmitting file during video call in electronic device
JP4671422B2 (ja) 通信システム、通信装置及びそれらの表示方法
JP4963566B2 (ja) 通信装置及びその制御方法
US11522933B2 (en) Information processing apparatus and information processing method
JP2003230117A (ja) 動画像データの送信システム、同送信装置、同送信方式および同送信方法
CN104219479A (zh) 视频通信业务处理方法与***
WO2009093473A1 (ja) 中継装置、端末、優先通信制御方法、プログラム及び記録媒体
JP3790761B2 (ja) 録画装置、ｏｓｄ表示制御方法、プログラム、及び記録媒体
US7539292B2 (en) Contents distribution system, contents server, contents receiving apparatus, contents distribution method, program and storage media
JP2006148942A (ja) Ｏｓｄ表示制御方法、プログラム、及び記録媒体
JP4889567B2 (ja) 情報記録支援装置、情報記録システムおよび情報記録方法
US20050068976A1 (en) Data transmitting apparatus, data transmitting/receiving system, and data transmitting/receiving method
WO2004109683A2 (en) Network recording system and recording device
WO2006001600A1 (en) Dmb/mobile telecommunication integrated service terminal apparatus and method for network linkage between dmb and mobile telecommunication
JP3425048B2 (ja) デジタルサービス処理方法およびデジタルサービス受信端末装置
JP2005190029A (ja) メディアデータ変換装置
JP2001258025A (ja) マルチメディア受信システム
JP4551724B2 (ja) 放送受信装置、放送受信システム、放送受信装置の制御方法、及び放送受信方法
WO2008048047A1 (en) Method and apparatus of referring to stream included in other saf session for laser service and apparatus for providing laser service

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090428

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090428

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110905

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110912

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111101

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

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120326

R151 Written notification of patent or utility model registration

Ref document number: 4963566

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150406

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees