以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。
まず、無線アダプタ装置(STA)と無線アクセスポイント(QAP)とで構成される無線通信システムについて説明する。尚、STAとQAPとは、IEEE802.11eで検討中のQoS機能を有するものとする。また、無線通信はIEEE802.11a/b/g規格の無線LANにIEEE802.11eで検討中のQoS機能を追加したものとする。
[第1の実施形態]
第1の実施形態では、STAに接続されるデバイスとの間で実施される設定メッセージを解析し、その結果に応じてQoS関連プロトコルの処理を制御する。
図1は、第1の実施形態における無線通信システムの構成の一例を示す図である。図1において、101〜105はそれぞれSTAであり、IEEE1394、USB、又は有線LANケーブルを用いて入出力機能を備えたデバイスに接続可能である。106はQAPであり、グローバル側はインターネット或いはイントラネットなどのネットワークに接続され、STA101〜105を無線サービスエリア内に接続収容する。
107はチューナー(TUNER)であり、IEEE1394ケーブル114を用いてSTA101に接続される。108はハードディスクレコーダ(HDR)であり、有線LANケーブル115を用いてSTA102に接続される。109はデジタルビデオカメラ(DVC)であり、USBケーブル116を用いてSTA103に接続される。
110は液晶テレビ(DISP)であり、IEEE1394ケーブル114を用いてSTA104に接続される。111はノートパソコン(PC)111であり、有線LANケーブル115を用いてSTA105に接続される。112は放送用信号を受信する放送用受信アンテナである。113は分波器であり、放送用受信アンテナ112で受信した信号をチューナー107とHDR108にそれぞれ分配して送信する。
図1に示す無線通信システムは、QAP106がSTA101〜105からの無線伝送帯域の割り当て要求に対して無線サービスエリア内のQoSを考慮した伝送帯域の割当てに関するスケジューリングを実施する機能を備える。更に、STA101〜105から所望のSTAとの間で直接的な無線通信路の確立要求を受信した際にSTA101〜105間の通信路を確立するダイレクトリンクサービスを実施する機能を備える。
図2は、第1の実施形態における無線アダプタ装置のソフトウェア構成を示す図である。図2において、202はSTA全体を制御するシステム制御部である。203は複数の入出力デバイス107〜111が接続された際に、それぞれのデバイスに応じて使用選択されるアプリケーションプログラムである。204はRTP/RTCPのようなセッション層で実現されるQoSプロトコル処理部である。205はデータ処理部であり、TCP/UDP/IPのようなネットワークプロトコルを処理する。206は無線LAN制御部(WLAN制御部)である。207はアンテナであり、WLAN制御部206に接続され、他のSTAとの間でデータの送受信を行う。
209はIEEE1394制御部であり、例えばIEEE1394ケーブル114でチューナー107や液晶テレビ110が接続される。210はUSB制御部であり、例えばUSBケーブル116でDVC109が接続される。211は有線LAN制御部であり、例えば有線LANケーブル115でHDR108やノートPC111が接続される。
208は記憶領域部であり、各ソフト機能ブロック202〜206、209〜211によって使用される。また、システム制御部202がSTA全体を制御する際に、各ソフト機能ブロック202〜206、209〜211は、プログラムやパラメータとしてROMに格納される。場合によっては、ROMから展開されるプログラムやデータを記憶領域部208であるRAMに一時記憶する。そして、201はROM,RAM,CPUをソフト管理するオペレーティングシステム(OS)である。
次に、QAP106によるDLSの制御下において送信側デバイスのチューナー107からSTA101及びSTA104を介して受信側デバイスの液晶テレビ110へ動画をストリーム伝送する際の処理を説明する。
図3は、チューナー107から液晶テレビ110へ直接動画をストリーム伝送する状態を示す図である。図3に示すように、チューナー107はIEEE1394ケーブル114を介してSTA101に接続され、液晶テレビ110はIEEE1394ケーブル114を介してSTA104に接続される。
図4は、図3に示すストリーム伝送で送受信されるメッセージのシーケンスを示す図である。また、図4に示すシーケンス内のメッセージは、第1の実施形態に関する主なもののみを明記し、一部のメッセージは省略している。
図5は、図4に示す送信側STA101における送信フレームの処理フローを示す図である。図5に示す例は、チューナー107がQoSプロトコル処理をサポートしていない場合である。図5において、501はデバイス側のメモリ制御処理であり、チューナー107からIEEE1394制御部209を介して受信したデータを記憶領域部208のデコード用バッファメモリ(Dbuf)に書き込む。503はRTP処理部であり、チューナー107がRTP機能をサポートしていない場合、記憶領域部208に書き込み格納されたデータに対してQoSプロトコルであるRTPヘッダを付加する。ここで、設定シーケンスで予め未サポートが判っている場合や、動画像データのQoSプロトコルであるRTPの使用の検出を行い、その結果、未使用である場合を含む。504はUDP処理部であり、トランスポート層プロトコルの処理を行う。505はIP処理部であり、ネットワーク層プロトコルの処理を行う。
502はネットワーク側のメモリ制御処理であり、RTP処理部503、UDP処理部504、IP処理部505を経て付加されたヘッダ部により構成されたデータを記憶領域部208の送信用メモリバッファ(mbuf)に書き込む。506はIEEE802.3変換処理部であり、送信用メモリバッファの送信データをWLAN制御部206で送信できるデータに変換する。
507はRTP処理部503でRTPヘッダを付加したRTP送信処理フレームである。508はRTP送信処理フレーム507にUDP処理部504でUDPヘッダを付加したUDP送信処理フレームである。509はUDP送信処理フレーム508にIP処理部505でIPヘッダを付加したIP送信処理フレームである。510はIP送信処理フレーム509に802.3変換処理部506で802.3ヘッダを付加した802.3送信処理フレームである。
図6は、チューナー107がQoSプロトコル処理をサポートする場合の送信フレームの処理フローを示す図である。尚、図5と同じものには同一符号を付し、ここでの説明は省略する。図6において、601はUDP処理部504でUDPヘッダを付加したUDP送信処理フレーム(UDPペイロードにチューナー107によるRTPプロトコルを含む)である。602はUDP送信処理フレーム601にIP処理部505でIPヘッダを付加したIP送信処理フレームである。603はIP送信処理フレーム602に802.3変換処理部506で802.3ヘッダを付加した802.3送信処理フレームである。
図7は、図4に示す受信側STA104における受信フレームの処理フローを示す図である。図7に示す例は、液晶テレビ110がQoSプロトコル処理をサポートしていない場合であり、図5に示す送信フレームに対応するものである。
図7において、707はWLAN制御部206から受信した802.3受信処理フレームである。706は802.3変換処理部であり、802.3受信処理フレーム707から802.3ヘッダを除去する。702はネットワーク側のメモリ制御処理であり、802.3ヘッダが除去された受信処理フレームを記憶領域部208の受信用バッファメモリ(mbuf)に書き込む。708は受信用バッファメモリに書き込まれたIP受信処理フレームである。709はIP受信処理フレーム708のIPヘッダーをIP処理部705で除去したUDP受信処理フレームである。710はUDP受信処理フレーム709のUDPヘッダをUDP処理部704で除去したRTP受信処理フレームである。
尚、RTP受信処理フレームは、デバイス側のメモリ制御処理701により、記憶領域部208にあるエンコード用バッファメモリ(Ebuf)に書き込まれる。この処理の際に、液晶テレビ110がRTP機能をサポートしていない場合、RTP処理部703は、記憶領域部208に書込み格納されたデータに対してQoSプロトコルであるRTPヘッダを除去する。ここで、設定シーケンスで予め未サポートが判っている場合や、動画像データのQoSプロトコルであるRTPの使用の検出を行い、その結果、未使用である場合を含む。
図8は、液晶テレビ110がQoSプロトコル処理をサポートしている場合の受信フレームの処理フローを示す図である。尚、図7と同じものには同一符号を付し、その説明は省略する。図8において、801はWLAN制御部206から受信した802.3受信処理フレームである。802は受信用バッファメモリ(mbuf)の802.3受信処理フレーム801の802.3ヘッダを802.3変換処理部706が除去したIP受信処理フレームである。803はIP受信処理フレーム802のIPヘッダーをIP処理部705で除去したUDP受信処理フレームである。
尚、UDP受信処理フレーム803は、UDPペイロードにデバイスによるRTPプロトコルを含み、デバイス側のメモリ制御処理701により記憶領域部208のエンコード用バッファメモリ(Ebuf)に書き込まれる。この処理の際に、液晶テレビ110がRTP機能をサポートしている場合、RTP処理部703は記憶領域部208に書き込み格納されたデータに対してQoSプロトコル関連の処理を実施しない。ここで、設定シーケンスで予めわかっている場合、QoSプロトコルであるRTPの使用検出を行い、その結果、デバイスで使用中である場合を含む。
ここで、図9〜図17を用いて、図4に示すシーケンスに従って動画をストリーム伝送する処理の詳細を説明する。
図9は、第1の実施形態における入出力デバイスの処理を示すフローチャートである。入出力デバイスは、チューナー107と液晶テレビ110である。図10は、第1の実施形態における無線アダプタ装置の共通処理を示すフローチャートである。図11は、第1の実施形態における送信側STA101の処理を示すフローチャートである。図12は、第1の実施形態における受信側STA104の処理を示すフローチャートである。図13及び図14は、第1の実施形態におけるQAP106の処理を示すフローチャートである。
図15は、第1の実施形態におけるRTP処理の実装状態と無線データ形式との関係を示すテーブルである。このテーブルにおいて、「RTP機能」は入出力デバイスにおけるRTPプロトコルのサポートである。また、「実装」はSTA間で送受信するDVデータにRTPヘッダを付加することを示し、データ形式は[RTP+DVデータ]と表される。また、「なし」はRTPプロトコルのサポートを実施しないことを示す。
また、「RTPヘッダー処理」はSTAにおけるRTPプロトコルのサポートを示し、「―」はRTPプロトコルのサポートが無いことを意味する。また、「追加」はデバイスとの間で送受信するDVデータにRTPヘッダを付加することを示し、データ形式は(RTP)+[DVデータ]と表される。そして、「削除」はデバイスとの間で送受信するDVデータのRTPヘッダを除去することを示し、データ形式は[DVデータ]となる。
図4に示すシーケンスにおいて、まず送信デバイス側のSTA101がQAP106のサービスエリア内に設置されるか、STA101の電源が投入されると、QAP106との間でアソシエーション処理(M401)を行う。そして、ステップS1001において、STA101がアソシエーション処理(M401)を完了するとステップS1002へ進み、STA101はチューナー107とのIEEE1394接続処理(M403)の完了判定を行う。
一方、送信デバイスであるチューナー107では、STA101との接続操作、或いはデバイス本体の電源投入などが行われる。そして、ステップS901で、STA101との間でIEEE1394接続シーケンス処理(M403)を完了するとステップS902へ進み、システム内に収容する全てのSTAの更新情報をSTA101から受信する。
次に、STA101がIEEE1394接続シーケンス処理(M403)を完了するとステップS1003へ進み、接続デバイスに関する情報を端末種別情報として種別登録メッセージ(M406)に含めてQAP106に送信する。ここで、接続デバイスに関する情報は、デバイス名称、インターフェース種別「IEEE1394」、転送モード「アイソクロナス」、RTP/RTCPプロトコルのサポート状況「あり」である。そして、ステップS1004において、システム内に収容する全ての端末の更新情報をQAP106から受信するのを待つ。
一方、QAP106は、ステップS1301でSTA101との間でアソシエーション処理(M401)が完了するとステップS1302へ進み、チューナー107に関する情報を含む種別登録メッセージ(M406)の受信を待つ。そして、STA101から種別登録メッセージ(M406)を受信するとステップS1303へ進み、端末種別情報を、例えば図16に示すデバイス管理テーブルの形態でメモリに格納し、ステップS1304で更新情報があるか否かを判断する。ここで、新規にアソシエーション処理によりSTAが登録される場合、又は以前のデバイスとは異なるデバイスが接続されたことにより該当するSTAからの種別登録メッセージの情報が変化したと判断された場合にはステップS1305へ進む。ステップS1305では、例えば図16に示すデバイス管理テーブルのデバイス情報を最新情報としてSTA101に種別情報メッセージ(M409)を送信し、接続中状態へと遷移する。
一方、STA101がQAP106から種別情報メッセージ(M409)を受信するとステップS1005へ進み、例えば図16に示すデバイス管理テーブルの形態で記憶領域208に格納する。そして、ステップS1006でチューナー107にシステム端末情報メッセージ(M410)を送信し、接続中状態へと遷移する。
次に、チューナー107がSTA101からシステム端末情報メッセージ(M410)を受信するとステップS903へ進み、通信可能な接続デバイスに関する情報を図16に示すデバイス管理テーブルの形態で格納する。そして、システム内にあるデバイスの収容状況、性能及び状態をLCDなどの表示部に表示する。ここで、チューナー107は、ステップS904へ進み、接続中状態となる。また、接続デバイスに関する情報は、デバイス名称、インターフェース種別「IEEE1394」、転送モード「アイソクロナス」、RTP/RTCPプロトコルのサポート状況「あり」である。
尚、図4において、受信側のデバイスである液晶テレビ110と受信側のSTA104とQAP106との間でも、上述した送信側と同様に処理が行われる。ここでは、送信側のチューナー107と受信側の液晶テレビ110とで異なる処理について説明する。
まず、ステップS903で、チューナー107はシステム内にあるデバイスの収容状況、性能、及び状態を表示したが、液晶テレビ110は、例えばアイコン等を採用し、視覚的に送受信可能なデバイスを認識可能に表示する。つまり、液晶テレビ110は大画面の液晶画面の一部、或いは接続デバイス表示専用の画面に切り替え、システム内に接続収容されている送受信可能なデバイスの収容状況、性能、及び状態を表示する。
次に、図4において、液晶テレビ110の画面上でチューナー107のアイコンが選択されるとステップS905へ進み、液晶テレビ110はチューナー107を特定する情報を含む接続要求メッセージ(M411)をSTA104に送信する。
一方、ステップS1201において、メッセージ受信の待ち状態にあるSTA104が液晶テレビ110からメッセージを受信するとステップS1202へ進む。ここで、受信したメッセージが接続要求メッセージ(M411)か判定し、YESの場合はステップS1211へ進む。ステップS1211では、QAP106のダイレクトリンクサービスの制御下において異なるSTAとの直接通信が可能か否かの判断を行い、直接通信が不可能な場合はステップS1213へ進む。
ステップS1213では、液晶テレビ110に対して通信不可能である旨の情報を含む接続応答メッセージを送信し、ステップS1201に戻る。また、ステップS1211で直接通信が可能な場合はステップS1212へ進み、QAP106に対してダイレクトリンクサービスの設定要求(DLS要求)メッセージ(M412)を送信し、ステップS1201に戻る。
一方、ステップS1401でQAP106がSTA104からメッセージを受信するとステップS1402へ進み、受信メッセージがDLS要求メッセージ(M412)か否かを判断する。YESの場合はステップS1403へ進み、QAP106のダイレクトリンクサービスの制御下において異なるSTAとの直接通信が可能か否かを判断し、直接通信が不可能な場合はステップS1405へ進む。ステップS1405では、通信不可能である旨の情報を含むDLS応答メッセージをSTA104に送信し、ステップS1401に戻る。
また、ステップS1403で直接通信が可能な場合はステップS1404へ進み、DLS要求メッセージ(M413)をSTA101に送信し、ステップS1401に戻る。
次に、ステップS1101で、接続中のSTA101がQAP106からメッセージを受信するとステップS1102へ進み、受信メッセージがDLS接続要求メッセージ(M413)か否かを判断する。YESの場合はステップS1103へ進み、QAP106のダイレクトリンクサービスの制御下において異なるSTAとの直接通信が可能か否かを判断し、直接通信が不可能な場合はステップS1315へ進む。ステップS1315では、通信不可能である旨の情報を含むDLS応答メッセージ(M414)をQAP106に送信し、ステップS1101に戻る。
また、ステップS1103で直接通信が可能な場合はステップS1104へ進み、転送モードや通信情報が一致するか判定する。ここで、転送モードの判定は、例えば図17に示す転送モード対向テーブルに基づいて行う。図17は、デバイス転送モードと使用プロトコルの関連テーブルを示す図である。入力系デバイス―アダプタ間のインターフェースと転送モード及び出力(表示)系デバイス―アダプタ間のインターフェースと転送モードの関係により選択される(最上位の)使用プロトコルを示すテーブルである。
例えば、パターン番号7(インターフェース:IEEE1394、転送モード;アイソクロナス、QoS:RTP)の場合、最上位レイヤの通信プロトコルとしてQoSプロトコルであるRTPを確認する。また、動画ストリーム以外のパターン番号6(インターフェース:IEEE1394、転送モード;アシンクロナス、QoS:TCP)の場合、最上位レイヤの通信プロトコルとしてTCPを確認する。また、図16に示すデバイス管理テーブルより液晶テレビ110に関するデバイス管理情報1604とチューナー107のデバイス管理情報1601、特にQoS制御に関わるRTP/RTCPプロトコルのサポート状況の整合性を検証する。
尚、この検証は、DLS接続要求メッセージ(M413)に含まれる要求元(受信デバイス側)STA104の識別情報に基づいて行うものである。
ここで、動画像ストリームの通信が不可能と判断した場合はステップS1315へ進み、通信不可能である旨の情報を含むDLS応答メッセージ(M414)をQAP106に送信し、ステップS1101に戻る。
また、ステップS1104で、動画像ストリームを通信可能と判断した場合はステップS1105へ進み、通信可能である旨の情報を含むDLS応答メッセージ(M414)をQAP106に送信する。また、接続要求メッセージ(M417)をチューナー107に送信する。
次に、ステップS1106で、チューナー107から接続要求メッセージ(M417)に対する接続応答メッセージ(M418)を受信するとステップS1107へ進み、送信タイミングが遅れているか判定する。この時点では、送信側デバイス(被選択側)であるチューナー107から送信データを受けていないため、ステップS1110のデータ受信待ち状態へ遷移する。尚、送信タイミングが遅れる場合については更に後述する。
一方、QAP106がSTA101からDLS応答メッセージ(M414)を受信した場合はステップS1401、S1402、S1406を経てS1407へ進む。ステップS1407では、通信可能である旨の情報を含むDLS応答メッセージ(M415)をSTA104に送信し、ステップS1401に戻る。これにより、STA104がDLS応答メッセージ(M415)を受信した場合はステップS1204へ進み、接続要求メッセージ(M411)の応答を示す接続応答メッセージ(M416)を液晶テレビ110に送信する。そして、ステップS1205へ進み、データ受信待ち状態に遷移する。
一方、受信側デバイス(選択側)である液晶テレビ110がステップS906で、接続応答メッセージ(M416)を受信するとステップS910へ進む。そして、デバイスの入出力判定を行い、出力デバイスであるためステップS911へ進み、液晶テレビ110の実装するRTP/RTCPプロトコルのサポート機能を確認する。ここでサポート可能であればステップS912へ進み、以降受信側STA104から受信する通信データ(M421)の受信処理時において、RTPプロトコルヘッダの除去処理を起動するように制御処理に設定する。即ち、液晶テレビ110はRTPヘッダ処理を実施し、STA104は非処理となる。そして、ステップS913のデータ受信処理へ進む。また、RTP/RTCPプロトコルのサポート機能を確認し、未サポートであればステップS913のデータ受信処理へ進む。この場合、液晶テレビ110のRTPヘッダ処理に関しては未対応で、STA104がRTP処理を行う。
また、ステップS907で、チューナー107がSTA101から接続要求メッセージ(M417)を受信するとステップS908へ進み、接続応答メッセージ(M418)をSTA101に送信する。そして、ステップS909で、STA101と接続が完了するとステップS910へ進み、デバイスの入出力判定を行う。ここで、入力デバイスであるため、ステップS914へ進み、RTP/RTCPプロトコルのサポート機能を確認し、サポート可能であればステップS915へ進む。ステップS915では、以降STA101に送信する通信データ(M419)の送信処理時において、RTPプロトコルヘッダの付加処理を起動するように制御処理に設定する。即ち、チューナー107はRTPヘッダ処理を実施し、STA101は非処理となる。そして、ステップS916のデータ送信処理へ進む。また、RTP/RTCPプロトコルのサポート機能を確認し、未サポートであればステップS916のデータ送信処理へ進む。この場合、チューナー107のRTPヘッダ処理に関しては未対応で、STA101がRTP処理を行う。
以上、送信側デバイス(被選択側)であるチューナー107と受信側デバイス(選択側)である液晶テレビ110のそれぞれで接続中状態からデータ通信状態へ遷移する場合の制御処理を説明した。
次に、チューナー107が接続されるSTA101及び液晶テレビ110が接続されるSTA104のデータ送受信状態により、QoSプロトコル制御処理と動画像ストリーム通信中の無線帯域の予約処理を説明する。
ステップS1110で、データ受信待ち状態にあるSTA101がチューナー107のデータ送信処理でRTPヘッダを付加したデジタル動画データ(M419)を受信するとステップS1111へ進む。ステップS1111では、チューナー107の実装するRTP/RTCPプロトコルのサポート状態を判定する。この判定は、デバイス間で送受信された設定メッセージで得られた情報を保存しているデバイス管理テーブルを参照して行う。
ここで、未サポートであればステップS1112へ進み、以降STA104に送信する通信データ(M420)の送信処理時に、RTPプロトコルヘッダの付加処理を起動するように制御処理に設定する。そして、ステップS1113のデータ送信処理を行う。この場合、チューナー107のRTPヘッダ処理に関しては未対応で、STA101がRTP処理を行う。また、サポート可能であればステップS1113へ進み、データ送信処理を行う。この場合、チューナー107がRTPヘッダ処理を行い、STA101では非処理となる。そして、ステップS1114において、通信の完了を確認し、通信が完了すると、接続中状態に遷移する。また、通信継続の場合にはステップS1117に戻る。
ここで、チューナー107から受信した例えば、直前の動画データ(M419)の受信処理に要する時間とSTA104に送信する送信データ(M420)の送信処理に要する時間とを比較する。その結果、「受信処理時間≧送信処理時間」となった場合、チューナー107から受信する動画データ(M422)の受信処理と、送信データ(M423)の制御処理(ステップS1107〜S1114)を繰り返す。
そして、ステップS1107で「受信処理時間<送信処理時間」となった場合、即ち、受信データのオーバーフロー状態の危険性が予測されるような場合はステップS1108へ進む。ステップS1108では、IEEE802.11e標準で規定される帯域予約シーケンス(M428)をQAP106間で起動する。そして、ステップS1109で、その帯域予約シーケンス(M428)が完了するとステップS1110へ進み、データ受信及びデータ送信処理の各処理を繰り返す。
従って、以降の受信データ(M425)の受信処理と、STA104に送信される無線データ(M426)の送信処理との処理タイミングを調整することができる。
次に、STA101からSTA104へ送信される無線データ(M420,M423,M426)を受信するSTA104の受信処理を説明する。
まず、ステップS1205において、STA104がSTA101より送信された無線データ(M420、M423,M426)を受信した場合はステップS1206へ進み、液晶テレビ110の実装するRTP/RTCPプロトコルのサポート機能を確認する。未サポートであればステップS1207へ進み、以降液晶テレビ110に送信する動画像データ(M421、M424,M427)の送信処理時にRTPプロトコルヘッダの除去処理を起動するように制御処理に設定する。即ち、液晶テレビ110がRTPヘッダ処理に関しては未対応で、STA104がRTP処理を行う。そして、ステップS1208でデータ受信処理を行い、ステップS1209で液晶テレビ110へのデータ送信処理を行う。そして、ステップS1210で通信完了を判定し、完了でなければステップS1205に戻り、上述の処理を繰り返す。また、ステップS1206で、サポート可能であればステップS1207をスキップしてステップS1208へ進み、上述の処理を行う。
以上、送信側デバイス(被選択側)と受信側デバイス(選択側)との間の通信データに対するQoS関連プロトコル(RTP/RTCP)のサポート状態をSTAが解析し、QoS関連プロトコルの付加処理を回避することができる。これにより、特にリアルタイム性の要求される入出力データに対する適切なQoS関連プロトコル処理の提供が可能となる。
[第2の実施形態]
次に、図面を参照しながら本発明に係る第2の実施形態について詳細に説明する。第2の実施形態では、実際に送信されるデータのプロトコルヘッダ情報を解析し、その結果に応じてQoS関連プロトコルの処理を制御する。具体的には、STA101がチューナー107から受信したDVデータにRTPヘッダーが付加されているか否かを判断するものである。そして、付加されていない場合、RTPヘッダーを付加してSTA104へ送信する。
図18は、第2の実施形態におけるストリーム伝送で送受信されるメッセージのシーケンスを示す図である。図19は、第2の実施形態における送信側STA101の処理を示すフローチャートである。図20は、第2の実施形態における受信側STA104の処理を示すフローチャートである。
尚、STA101、104における通信中までの処理及びQAP106の処理は、第1の実施形態の図9、図10及び図14を用いて説明する。
図18に示すシーケンスにおいて、メッセージ(M401〜M410)及びメッセージ交換に関連する処理については、第1の実施形態と同様であり、説明は省略する。
まず、ステップS904において、チューナー107から液晶テレビ110を指定するリモコン操作等が行われるとステップS905へ進み、液晶テレビ110を特定する情報を含む接続要求メッセージ(M1800)をSTA101に送信する。
一方、接続中のSTA101がチューナー107から接続要求メッセージ(M1800)を受信するとステップS1901からステップS1902、S1910、S1911へ進む。ステップS1911では、IEEE802.11e標準で規定される帯域予約シーケンス(M1801)をQAP106間で起動する。そして、ステップS1912で、帯域予約シーケンス(M1801)が完了するとステップS1913へ進み、ダイレクトリンクサービスの設定要求(DLS要求)メッセージ(M1802)をQAP106に送信し、ステップS1901に戻る。
また、ステップS1401において、接続中のQAP106がSTA101からDLS要求メッセージ(M1802)を受信するとステップS1402からステップS1403へ進む。ステップS1403では、QAP106のダイレクトリンクサービスの制御下において異なるSTAとの直接通信が可能か否かの判断を行い、直接通信が不可能な場合はステップS1405へ進む。ステップS1405では、STA101に通信不可能である旨の情報を含むDLS応答メッセージを送信し、ステップS1401に戻る。また、直接通信が可能な場合はステップS1404へ進み、DLS要求メッセージ(M1803)をSTA104に送信し、ステップS1401に戻る。
一方、ステップS2001において、STA104がQAP106からDLS接続要求メッセージ(M1803)を受信すると、ステップS2002からステップS2003へ進む。ステップS2003では、QAP106のダイレクトリンクサービスの制御下において異なるSTAとの直接通信が可能か否かの判断を行い、直接通信が不可能な場合はステップS2013へ進む。ステップS2013では、通信不可能である旨の情報を含むDLS応答メッセージ(M1804)をQAP106に送信し、ステップS2001に戻る。
また、ステップS2003において、直接通信が可能な場合はステップS2004へ進み、第1の実施形態と同様に、転送モードや通信情報が一致するか否かを判断する。ここで、相互通信の整合性を検証し、動画像ストリームの通信が可能と判断するとステップS2005へ進み、通信可能である旨の情報を含むDLS応答メッセージ(M1804)をQAP106に送信する。そして、液晶テレビ110に接続要求メッセージ(M1807)を送信する。次に、ステップS2006において、液晶テレビ110から接続応答メッセージ(M1808)の受信を待ち、受信するとステップS2007へ進み、データ受信待ち状態に遷移する。
また、ステップS1401において、QAP106がSTA104からDLS応答メッセージ(M1804)を受信すると、ステップS1402からS1406のYESへ進む。そして、ステップS1407において、通信可能である旨の情報を含むDLS応答メッセージ(M1805)をSTA101に送信し、ステップS1401に戻る。
一方、ステップS1901において、STA101がDLS応答メッセージ(M1805)を受信すると、ステップS1902からステップS1903へ進む。ステップS1903では、接続応答メッセージ(M1806)をチューナー107に送信し、ステップS1904へ進み、データ受信待ち状態に遷移する。
これにより、ステップS906において、チューナー107が接続応答メッセージ(M1806)を受信するとステップS910へ進み、入力デバイスであるためにステップS914へ進む。ステップS914では、チューナー107の実装するRTP/RTCPプロトコルのサポート機能を確認し、サポート可能であればステップS915へ進み、第1の実施形態と同様にRTPヘッダ付加処理を行う。また、未サポートであれば、そのままステップS916へ進み、データ送信処理を行う。
次に、ステップS1904で、データ受信待ちのSTA101がチューナー107からデータ(M1809)を受信すると、ステップS1905へ進み、データ解析処理を実行する。そして、ステップS1906で、受信したデータのRTP/RTCPプロトコルヘッダ情報を確認し、RTPヘッダが付加されていなければ、ステップS1907へ進む。ステップS1907では、RTPヘッダを付加し、ステップS1908で、STA104へデータ送信処理を行う。また、ステップS1906で、RTPヘッダが付加されていれば、ステップS1908へ進み、STA104へデータ送信処理を行う。そして、全てのデータを送信完了するまでステップS1904に戻り、上述の処理を繰り返す。
一方、ステップS2007で、データ受信待ちのSTA104がSTA101からデータ(M1810)を受信すると、ステップS2008へ進み、プロトコルをチェックし、RTPカプセル化を判断する。これ以降の処理(S2008〜S2012)は、第1の実施形態で説明した図12のS1206〜S1210と同様であり、その説明は省略する。
第2の実施形態によれば、第1の実施形態と同様に、送受信データに対する不要なQoS関連プロトコルの付加処理を回避し、特にリアルタイム性の要求される入出力データに対する適切なQoS関連プロトコル処理の提供が可能となる。
[第3の実施形態]
次に、図面を参照しながら本発明に係る第3の実施形態について詳細に説明する。第3の実施形態では、プロトコルヘッダ部に含まれるパケットデータのプライオリティを解析し、その結果に応じてQoS関連プロトコルの処理を制御する。第1及び第2の実施形態では、チューナー107と液晶テレビ110との間のストリーム伝送を説明したが、第3の実施形態ではHDR108とノートPC111との間のストリーム伝送を説明する。
図21は、HDR108からノートPC111へ直接動画をストリーム伝送する状態を示す図である。図21に示すように、HDR108は有線LANケーブル115を介してSTA102に接続され、ノートPC111は有線LANケーブル115を介してSTA105に接続される。
図22は、図21に示すストリーム伝送で送受信されるメッセージのシーケンスを示す図である。また、図22に示すシーケンス内のメッセージは、第3の実施形態に関する主なもののみを明記し、一部のメッセージについては省略している。
図23は、入力側(HDR108が接続される)STA102における受信フレームの処理フローを示す図である。図23に示す例は、HDR108がQoSプロトコル処理をサポートしていない場合である。
図23において、2301は有線LAN制御部211から受信したIEEE802.1p準拠のユーザプライオリティフィールドをもつIEEE802.1QのVLANタグヘッダ(VLANタグパケット)の受信フレームである。2302は受信用バッファメモリ(mbuf)にあるVLANタグパケットの受信処理フレーム2301のVLANタグヘッダをIEEE802.3⇔IEEE802.1p相互変換処理部2300により除去したIP受信処理フレームである。2303はIP受信処理フレーム2302のIPヘッダをIP処理部705により除去したUDP/TCP受信処理フレームである。2304はUDP/TCP受信処理フレーム2303のUDP/TCPヘッダをUDP/TCP処理部2305により除去した動画像フレームである。
2305はUDP又はTCPのトランスポート層のネットワークプロトコル処理を行うTCP/UDP処理部である。また、メモリ制御処理(ネットワーク側)702はVLANタグパケットの受信処理フレームを記憶領域部208にある受信用バッファメモリ(mbuf)に対して書込み制御を実施する。
図24は、入力側(HDR108が接続される)STA102における送信フレームの処理フローを示す図である。この例では、STA102においてQoSプロトコル処理をサポートする場合を示している。
図24において、2401はRTP送信処理フレームであり、動画像フレームに対してQoSプロトコルであるRTPの使用の検出を行い、未使用である場合、動画像フレームに対してQoSプロトコルであるRTPヘッダの付加が行われる。2402はRTP送信処理フレーム2401にUDP/TCP処理部2305でUDPヘッダを付加したUDP送信処理フレームである。2403はUDP送信処理フレーム2402にIP処理部505でIPヘッダを付加したIP送信処理フレームである。2404はIP送信処理フレーム2403にIEEE802.3変換処理部506で802.3ヘッダを付加したIEEE802.3送信処理フレームである。
図25は、出力側(ノートPC111が接続される)STA105における受信フレームの処理フローを示す図である。この例では、STA105においてQoSプロトコル処理をサポートする場合を示している。
図25において、2501は無線LAN制御部206から受信したIEEE802.11無線データをIEEE802.3変換処理部706で802.3ヘッダに変換したIEEE802.3受信処理フレームである。また、メモリ制御処理(ネットワーク側)702は、IEEE802.3受信処理フレームを記憶領域部208にある受信用バッファメモリ(mbuf)に対して書込み制御を実施する。2502は受信用バッファメモリ(mbuf)にあるIEEE802.3受信処理フレーム2501の802.3ヘッダをIEEE802.3変換処理部706で除去したIP受信処理フレームである。2503はIP受信処理フレーム2502のIPヘッダーをIP処理部705で除去したUDP/TCP受信処理フレームである。2504はUDP/TCP受信処理フレーム2503のUDPヘッダをUDP/TCP処理部2305で除去したRTP受信処理フレーム(ペイロードには、動画像データを含む)である。
図26は、出力側(ノートPC111が接続される)STA105における送信フレームの処理フローを示す図である。この例では、ノートPC111にQoSプロトコル処理がサポートされない場合を示している。
図26において、RTP処理部503がデータ送信先で接続されるデバイスであるノートPC111のQoSプロトコルであるRTPのサポートの検出を行う。その結果、未サポートである場合、記憶領域部208に書込み格納されている動画像フレーム2804に対してQoSプロトコルであるRTPヘッダが除去される。2601はQoSプロトコルであるRTPヘッダが除去された動画像フレームである。2602は動画像フレーム2601にUDP/TCP処理部2305でUDPヘッダを付加したUDP送信処理フレームである。2603はUDP送信処理フレーム2602にIP処理部505でIPヘッダを付加したIP送信処理フレームである。2604はIP送信処理フレーム2603にIEEE802.1p変換処理部2300で802.1pヘッダを付加したIEEE802.1p送信処理フレームである。
図27は、IEEE802.1p準拠のユーザプライオリティフィールドを持つIEEE802.1QのVLANタグヘッダ送信フレーム(IEEE802.1p)の構成を示す図である。図27において、2701はVLANタグヘッダ・フレームを識別するためのTPID(TagProtocolID(0x8100))である。2702はフレームの優先順位情報であるUP(User Priority)である。また、プライオリティは、8つのレベル(0−7)で表現される。
図28は、UPとQoSプロトコル処理との関係を表す管理テーブルである。図28において、2801はRTP/RTCP処理の対応、非対応を表す。2802はIEEE802.1p準拠のユーザプライオリティである。2803はユーザプライオリティに対する802.1Dの記号である。2804は記号3103の名称である。
図29は、無線MAC送信フレーム(802.3)の構成を示す図である。図29において「あて先MACアドレス」は、あて先装置のMACアドレスでレングスは6バイト。「送信元アドレス」は、送信元装置のMACアドレスでレングス6バイト。「長さ」は、後に続くデータ部の長さを表す。プロトコルIDは、0x5DC(1500)よりも大きな値を用いることで識別が可能。「DSAP」は、Destination SAPを意味する。これは、送信先のネットワーク層のプロトコルを識別するためのフィールドで1バイト(WLAN:0xAA)。「SSAP」は、Source SAPのことで、送信元のネットワーク層のプロトコルを識別する。DSAPと同じく、1バイトで通常、送信先と送信元は同じプロトコルを利用するのでDSAP、SSAPは同じものになる(WLAN:0xAA)。「制御」は、データリンクレベルでコネクションの確立やフロー制御を行うためのフィールド。これも1バイトの大きさ(WLAN:0x03)。「組織ID」は、MACアドレスの上位3バイトの組織IDと同じ。IEEEがベンダ毎に組織IDを割り当て、レングス3バイト。「タイプ」は、ETH(イーサネット:登録商標)Ver2のフレームフォーマットのタイプと同じ。レングス2バイト。これによりETHver2との互換性も保て、2バイトなのでベンダ毎に固有のプロトコルを作った場合も十分とされる(WLAN:0x0800)。
ここで、図22に示すシーケンスに従ってHDR108からノートPC111へ動画をストリーム伝送する処理の詳細を説明する。
図30は、第3の実施形態における送信側STA102の処理を示すフローチャートである。また、図31は、第3の実施形態における受信側STA105の処理を示すフローチャートである。
尚、STA102、105における通信中までの処理とQAP106の処理は、第1の実施形態で用いた図9、図10と図13及び図14を参照して説明する。
図22に示すシーケンス図において、送信デバイス側STA102が、QAP106のサービスエリア内に設置されるか、STA102の電源が投入されると、QAP106との間でアソシエーション処理(M401)を行う。そして、ステップS1001において、STA102がアソシエーション処理(M401)を完了するとステップS1002へ進む。ステップS1002では、STA102はHDR108との間で有線LANケーブル115を用いて接続し、HDR108の転送速度やQoSプロトコルであるRTPのサポート状態に関するETH接続シーケンス処理(M2201)を実施する。
一方、送信デバイスであるHDR108では、STA102との接続操作や、デバイス本体の電源投入操作などが行われる。そして、ステップS901で、STA102との間でETH接続シーケンス処理(M2201)を完了するとステップS902へ進み、システム内に収容する全ての端末の更新情報をSTA102から受信する。
次に、STA102がETH接続シーケンス処理(M2201)を完了するとステップS1003へ進み、接続デバイスに関する情報を端末種別情報として種別登録メッセージ(M406)に含めてQAP106に送信する。ここで、接続デバイスに関する情報は、デバイス名称、インターフェース種別「有線LAN」、転送モード「802.1p準拠」、RTP/RTCPプロトコルのサポート状況「あり」である。そして、ステップS1004において、システム内に収容する全ての端末の更新情報をQAP106から受信するのを待つ。
一方、QAP106は、ステップS1301でSTA102との間でアソシエーション処理(M401)が完了するとステップS1302へ進み、HDR108に関する情報を含む種別登録メッセージ(M406)の受信を待つ。そして、STA102から種別登録メッセージ(M406)を受信するとステップS1303へ進み、端末種別情報を、例えばデバイス管理テーブルの形態でメモリに格納し、ステップS1304で更新情報があるか否かを判断する。ここで、新規にアソシエーション処理によりSTAが登録される場合、又は以前のデバイスとは異なるデバイスが接続されたことにより該当するSTAからの種別登録メッセージの情報が変化したと判断された場合にはステップS1305へ進む。ステップS1305では、例えばデバイス管理テーブルのデバイス情報を最新情報としてSTA102に種別情報メッセージ(M409)を送信し、接続中状態へと遷移する。
一方、STA102がQAP106から種別情報メッセージ(M409)を受信するとステップS1005へ進み、例えばデバイス管理テーブルの形態で記憶領域208に格納する。そして、ステップS1006でHDR108にシステム端末情報メッセージ(M2204)を送信し、接続中状態へと遷移する。
次に、HDR108がSTA102からシステム端末情報メッセージ(M2204)を受信するとステップS903へ進み、通信可能な接続デバイスに関する情報をデバイス管理テーブルの形態で格納する。そして、システム内にあるデバイスの収容状況、性能及び状態をLCDなどに表示する。ここで、HDR108は、ステップS904へ進み、接続中状態となる。また、接続デバイスに関する情報は、デバイス名称、インターフェース種別「有線LAN」、転送モード「802.1p準拠」、RTP/RTCPプロトコルのサポート状況「あり」である。
尚、受信側のデバイスであるノートPC111と受信側のSTA105とQAP106との間でも、上述した送信側と同様に処理が行われる。ここでは、送信側のHDR108と受信側のノートPC111とで異なる処理について説明する。
まず、ステップS903で、HDR108はシステム内にあるデバイスの収容状況、性能、及び状態をLCDなどに表示したが、ノートPC111は液晶ディスプレイである。従って、ノートPC111のアプリケーションソフトを用いて液晶ディスプレイの一部、或いは専用ウインドウ画面に切り替え、システム内に接続収容されている送受信可能なデバイスの収容状況、性能、及び状態をアイコン等を採用し、視覚的に明示する。
次に、図22において、ノートPC111の画面上でHDR108のアイコンが選択するとステップS905へ進み、HDR108を特定する情報を含む接続要求メッセージ(M2205)を有線LANケーブル115を介してSTA105に送信する。
一方、ステップS3101において、メッセージ受信の待ち状態にあるSTA105がHDR108からメッセージを受信するとステップS3102へ進む。ここで、受信したメッセージが接続要求メッセージ(M2205)の場合はステップS3113へ進み、QAP106のダイレクトリンクサービスの制御下において異なるSTAとの直接通信が可能か否かの判断を行う。その結果、直接通信が不可能な場合はステップS3115へ進み、ノートPC111に対して通信不可能である旨の情報を含む接続応答メッセージを送信する。
また、直接通信が可能な場合はステップS3414へ進み、QAP106に対してダイレクトリンクサービスの設定要求(DLS要求)メッセージ(M412)を送信し、ステップS3101に戻る。
一方、ステップS1401でQAP106がSTA105からメッセージを受信するとステップS1402へ進み、受信メッセージがDLS要求メッセージ(M412)か否かを判断する。YESの場合はステップS1403へ進み、QAP106のダイレクトリンクサービスの制御下において異なるSTAとの直接通信が可能か否かを判断し、直接通信が不可能な場合はステップS1405へ進む。ステップS1405では、通信不可能である旨の情報を含むDLS応答メッセージ(M415)をSTA105に送信し、ステップS1401に戻る。
また、ステップS1403で直接通信が可能な場合はステップS1404へ進み、DLS要求メッセージ(M413)をSTA102に送信し、ステップS1401に戻る。
次に、ステップS3001で、接続中のSTA102がQAP106からメッセージを受信するとステップS3202へ進み、受信メッセージがDLS接続要求メッセージ(M413)か否かを判断する。YESの場合はステップS3203へ進み、QAP106のダイレクトリンクサービスの制御下において異なるSTAとの直接通信が可能か否かを判断し、直接通信が不可能な場合はステップS3005へ進む。ステップS3005では、通信不可能である旨の情報を含むDLS応答メッセージ(M414)を送信し、ステップS3001に戻る。
また、ステップS3003で直接通信が可能な場合はステップS3004へ進み、転送モードや通信情報が一致するか判定する。判定処理は、第1の実施形態と同様に、DLS接続要求メッセージ(M413)に含まれる接続要求元(受信デバイス側)STA105の識別情報に基づいて行う。即ち、第1の実施形態と同様に、転送モード対向テーブルに基づいて転送モードの判定を行い、デバイス管理テーブルに基づいてQoSサポート状況の整合性を検証する。
ここで、動画像ストリームの通信が不可能と判断した場合はステップS3305へ進み、通信不可能である旨の情報を含むDLS応答メッセージ(M414)をQAP106に送信し、ステップS3001に戻る。
また、ステップS3004で、動画像ストリームを通信可能と判断した場合はステップS3006へ進み、通信可能である旨の情報を含むDLS応答メッセージ(M414)をQAP106に送信する。そして、ステップS3007において、IEEE802.11eで規定の帯域予約シーケンス(M2207)をQAP106との間で起動する。その後、ステップS3008で帯域予約シーケンス(M2207)が完了するとステップS3009へ進み、接続要求メッセージ(M2208)をHDR108に送信する。
次に、ステップS3010において、HDR108から接続要求メッセージ(M2208)に対する接続応答メッセージ(M2209)を受信した場合はステップS3011へ進み、データ受信待ち状態に遷移する。
一方、QAP106がSTA102からDLS応答メッセージ(M414)を受信した場合はステップS1407へ進む。ステップS1407では、通信可能である旨の情報を含むDLS応答メッセージ(M415)をSTA105に送信し、ステップS1401に戻る。これにより、STA105がDLS応答メッセージ(M415)を受信した場合はステップS3103へ進み、接続要求メッセージ(M2205)の応答を示す接続応答メッセージ(M2206)をノートPC111に送信する。そして、ステップS3104へ進み、データ受信待ち状態に遷移する。
一方、受信側デバイス(選択側)であるノートPC111がステップS906で、接続応答メッセージ(M2206)を受信するとステップS910へ進む。そして、デバイスの入出力判定を行い、出力デバイスであるためステップS911へ進み、ノートPC111の実装するRTP/RTCPプロトコルのサポート機能を確認する。ここで、サポート不可能であるのでステップS913へ進み、通常のデータ受信処理を実施する(デバイス111のRTPヘッダ処理に関しては未対応:STA105でRTP処理を実施する)。
また、ステップS907で、HDR108がSTA102から接続要求メッセージ(M2208)を受信するとステップS908へ進み、接続応答メッセージ(M2209)をSTA102に送信する。そして、ステップS909で、STA102と接続が完了するとステップS910へ進み、デバイスの入出力判定を行う。ここで、入力デバイスであるため、ステップS914へ進み、HDR108の実装するRTP/RTCPプロトコルのサポート機能を確認し、サポート不可能であるのでステップS916へ進む。ステップS916では、以降、STA102に対して送信する通信データ(M2210、M2213)の通常データ送信処理を実施する。この場合、HDR108のRTPヘッダ処理に関しては未対応で、STA102がRTP処理を行う。
以上、送信側デバイス(被選択側)であるHDR108と受信側デバイス(選択側)であるノートPC111のそれぞれで接続中状態からデータ通信状態に遷移する場合の制御処理を説明した。
次に、HDR108が接続されるSTA102及びノートPC111が接続されるSTA105のデータ送受信状態におり、QoSプロトコル制御処理と動画像ストリーム通信について説明する。
ステップS3011で、データ受信待ち状態にあるSTA102がHDR108のデータ送信処理によりデジタル動画データ(M2210、M2213)を受信するとステップS3012へ進む。ステップS3012では、HDR108から受信したデータパケットのヘッダを解析し、ステップS3013において、データパケットのヘッダにあるユーザプライオリティ2702を確認する。このとき、ユーザプライオリティ2702の値が、ユーザプライオリティ毎にQoS対応管理テーブルに示す5(ビデオなどのストリーム系データ)又は6(オーディオ、電話などの音声系データ)であれば、ステップS3014へ進む。ステップS3014では、以降、通信データ(M2210)の送信処理時において、RTPプロトコルヘッダの付加処理を起動するように制御処理を設定し、ステップS3015のデータ送信処理を行う。この場合、STA102でRTP処理を行う。
また、ステップS3012で、ユーザプライオリティ2702の値が、ストリーム系や音声系のデータ以外の場合、ユーザプライオリティ毎にQoS対応管理テーブルに示す0〜4という値の場合ステップS3015へ進む。ステップS3015では、RTPを使用しないTCP/UDPによるデータ送信処理を行う。
そして、ステップS3016において、通信の完了を確認し、通信完了時は接続中状態に遷移する。また、通信継続の場合にはステップS301に戻り、上述の処理を繰り返し実行する。
次に、STA102からSTA105へ送信される無線データ(M2211、M2214)を受信するSTA105の受信処理を説明する。
まず、ステップS3104において、STA105がSTA102より送信された無線データ(M2211、M2214)を受信した場合はステップS3105へ進み、データ解析を行う。ここで、RTP/RTCPプロトコルヘッダ情報が付加されていない場合はステップS3107へ進み、RTPを使用しないTCP/UDPによるデータ送信処理を行う。また、RTP/RTCPプロトコルヘッダ情報が付加されている場合はステップS3106へ進み、データの受信処理(ステップS3107)で、RTPプロトコルヘッダの除去処理を行うように設定する。そして、ステップS3107において、STA102からのデータ受信処理を行う。
次に、ステップS3108において、デバイス管理テーブルを参照し、ノートPC111に関するデバイス情報の転送モードを調べ、「802.1p準拠」である場合はステップS3109へ進む。ステップS3109では、HDR108より受信したデータのRTPペイロードを解析し、プライオリティ変換及びプロトコル変換を行う。例えば、ストリーム系データ(例えばビデオ)であれば5を、また音声系データ(例えばオーディオ、電話)であれば6というユーザプライオリティ毎のQoS対応管理テーブルに示す値をプロトコル変換する。そして、IEEE802.1p準拠のデータフレーム(図27参照)のヘッダ部におけるユーザプライオリティ2702の値としてコーディングする。
一方、ステップS3108において、「802.1p準拠」でない場合はステップS3110へ進み、ノートPC111に対するデータ送信処理を行う。ここでは、ノートPC111にプロトコル変換データを送信する。そして、ステップS3111において、通信の完了を確認し、通信完了時には接続中状態に遷移する。また、通信継続の場合にはステップS3104に戻り、上述のデータ受信処理手順を繰り返す。
以上、STA102とSTA105において、HDR108とノートPC111のデバイス間で送受信されるデータパケットに対する優先順位を解析することにより、データパケットに対する効果的なQoS関連プロトコルの付加処理を実施できる。従って、リアルタイム性の要求される入出力データに対する適切なQoS関連プロトコル処理を提供することが可能となる。
[第4の実施形態]
次に、図面を参照しながら本発明に係る第4の実施形態について詳細に説明する。第4の実施形態では、送信側STAが受信側STAから要求されたアプリ種別に応じてQoSプロトコルを選択してデータ伝送を行う。
図32は、第4の実施形態におけるアプリ種別とQoSプロトコル処理対応テーブルの構成を示す図である。図32に示すアプリ種別管理テーブルにおいて、3201はアプリ種別エントリ番号(ID)である。3202はアプリケーション種別である。3203はQoS関連プロトコルの起動(RTP/RTCPを使用すること)又は解除(TCPを使用すること)に伴うプロトコル処理である。
第4の実施形態では、第3の実施形態で説明したHDR108からノートPC111へ直接動画をストリーム伝送する要求に加え、ファイル転送が要求された場合について説明する。
図33は、第4の実施実施形態におけるメッセージのシーケンスを示す図である。尚、図33に示すシーケンス内のメッセージは、第4の実施形態に関する主なもののみを明記し、一部のメッセージについては省略している。
図34は、入力側(HDR108が接続される)STA102における送受信フレームの処理フローを示す図である。図34では、STA102において、送画像ファイルデータの転送を行う場合を示している。
図34において、3400はイーサフレームヘッダ変換処理部であり、有線LANインターフェースより受信するデータパケットの処理を行う。3401は有線LAN制御部211から受信したETH受信処理フレームである。3402は受信用バッファメモリ(mbuf)にあるETH受信処理フレーム3401のETHヘッダがイーサフレームヘッダ変換処理部3400で除去されたIP送受信処理フレームである。3403はIP送受信処理フレーム3402にIEEE802.3変換処理部506が802.3ヘッダを付加したIEEE802.3送信処理フレームである。
図35は、出力側(ノートPC111が接続される)STA105における受信フレームの処理フローを示す図である。図35では、STA105において、ファイルデータの転送を行う場合を示している。
図35において、3501は無線LAN制御部206から受信したIEEE802.11無線データをIEEE802.3変換処理部706で802.3ヘッダに変換されたIEEE802.3受信処理フレームである。また、メモリ制御処理(ネットワーク側)702は、IEEE802.3受信処理フレームを記憶領域部208にある受信用バッファメモリ(mbuf)に対して書込み制御を実施する。3502は受信用バッファメモリ(mbuf)にあるIEEE802.3受信処理フレーム3501の802.3ヘッダがIEEE802.3変換処理部706で除去されたIP送受信処理フレームである。3503はIP送信処理フレーム3501にイーサフレームヘッダ変換処理部3400でETHヘッダを付加したETH送信処理フレームである。
ここで、図33に示すシーケンスに従ってアプリ種別が動画の場合はRTPを使用し、ファイル転送の場合はTCPを使用してデータ伝送を行う処理の詳細を説明する。
図36は、第4の実施形態における送信側STA102の処理を示すフローチャートである。また、図37は、第4の実施形態における受信側STA105の処理を示すフローチャートである。
図33において、一連のメッセージ(M401〜M409、M2201〜M2203)及びメッセージ交換に関連するそれぞれの制御処理は、第3の実施形態(図22)と同様であり、その説明は省略する。
また、ノートPC111は、HDR108とIPネットワーク上で接続され、HDR108の内部データにアクセスする場合には、例えばノートPC111上のWEBビューアアプリケーションを用いる。そして、HDR108内部で起動中のHTTPサーバ機能を利用するものとする。また、HDR108の内部データは、メニュー形式で選択することが可能であり、録画済みの番組の確認や再生、録画データのバックアップを目的とした、複写・保存操作ができる。このように、受信側デバイスであるノートPC111の画面上では、HDR108内に保存されるデータファイルの一覧が参照できる(データファイル取得シーケンス(M3300)に相当する)。
このとき、HDR108にある動画像ファイルに対して実行されるサービスとしては、図32に示すように、例えば「動画再生」及び「複写・保存」などがある。「動画再生」サービスの場合、図32に示すアプリ種別管理テーブルのエントリ番号4が選択される。即ち、この場合は、アプリケーション3202として「ビデオストリーム」が使用され、プロトコル処理として「RTP/RTCP」が使用される。また、「複写・保存」サービスの場合、エントリ番号3が選択され、アプリケーション3202として「ファイル転送」が使用され、プロトコル処理として「TCP」が使用される。
データファイル取得シーケンス(M3300)により、ノートPC111の画面上で、HDR108内に保存される再生ファイルの一覧を参照し、所望の動画ファイルに対するサービスとして「動画再生」が選択されるとステップS905へ進む。ステップS905では、ノートPC111はHDR108を特定する情報とアプリ種別情報に「ストリームデータ」を含む接続要求メッセージ(M3301)を有線LANケーブル115を介してSTA105に送信する。
一方、ステップS3701において、STA105がノートPC111からメッセージを受信し、そのメッセージが接続要求メッセージ(M3301)の場合はステップS3714へ進む。ステップS3714では、接続要求メッセージ(M3301)に含まれる、ノートPC111の指定したアプリ種別「ストリームデータ」を記憶領域部208に格納する。そして、ステップS3715において、QAP106のダイレクトリンクサービスの制御下において異なるSTAとの直接通信が可能か否かの判断を行い、直接通信が不可能な場合はステップS3717へ進む。ステップS3717では、通信不可能である旨の情報を含む接続応答メッセージ(M3307)をノートPC111に送信し、ステップS3701に戻る。また、直接通信が可能な場合はステップS3716へ進み、ダイレクトリンクサービスの設定要求(DLS要求)メッセージ(M412)をQAP106に送信し、ステップS3701に戻る。
このメッセージ(M412)を受信し、(M415)を送信するまでのQAP106の処理は第3の実施形態と同様であり、その説明は省略する。
また、ステップS3701において、STA105がQAP106からメッセージを受信し、そのメッセージがDLS応答メッセージ(M415)の場合はステップS3704へ進む。ステップS3704では、記憶領域部208に格納したアプリ種別「ストリームデータ」を含む接続要求メッセージ(M3302)をSTA102に送信する。そして、ステップS3705において、その接続要求メッセージ(M3302)の応答メッセージ待ち状態となる。
一方、ステップS3601において、STA102がSTA105から接続要求メッセージ(M3302)を受信するとステップS3604へ進む。ステップS3604では、デバイス管理テーブルのデバイス管理情報に基づいてインターフェース種別が一致するか否かを判断する。ここで、インターフェース種別が異なる場合はステップS3619へ進み、通信不可能である旨の情報を含む接続応答メッセージをSTA105に送信し、ステップS3601に戻る。また、整合性を検証し、送受信デバイス双方共にインターフェース種別が一致する場合はステップS3605へ進む。
ステップS3605では、接続要求メッセージ(M3302)に含まれるアプリ種別「ストリームデータ」を記憶領域部208に格納し、アプリ種別情報「ストリームデータ」を含む接続要求メッセージ(M3303)をHDR108に送信する。そして、ステップS3606において、EEE802.11eで規定される帯域予約(M3304)をQAP106との間で行う。そして、ステップS5307において、帯域予約(M3304)が完了するとステップS3608へ進み、HDR108からの接続応答メッセージ(M3305)の受信確認待ち状態となる。
ここで、HDR108の処理は、第3の実施形態と同様であり、その説明は省略する。そして、ステップS3608において、STA102がHDR108から接続応答メッセージ(M3305)を受信するとステップS3609へ進み、接続応答メッセージ(M3306)をSTA105に送信する。そして、ステップS3610で、HDR108からのデータ受信待ち状態に遷移する。
一方、ステップS3705において、STA105がSTA102から接続応答メッセージ(M3306)を受信するとステップS3706へ進む。ステップS3706では、接続要求メッセージ(M3301)に対する応答を示す接続応答メッセージ(M3307)をノートPC111に送信し、ステップS3707で、STA102からのデータ受信待ち状態に遷移する。ここで、ノートPC111の処理は、第3の実施形態と同様であり、その説明は省略する。
次に、ステップS3610において、データ受信待ち状態にあるSTA102がHDR108からデジタル動画データ(M3308)を受信するとステップS3611へ進み、記憶領域部208に格納したアプリ種別を確認する。ここで、アプリ種別が「ストリームデータ」の場合、通信プロトコルにRTPを使用するため、ステップS3612のYESからステップS3613へ進む。ステップS3613で、STA105に送信する動画像データ(M3309)の送信処理時において、RTPプロトコルヘッダの付加処理を起動するように制御処理に設定し、ステップS3614でデータ送信処理を実施する。また、例えばエントリ番号7にある監視カメラなどのモニタリングシステムで通信プロトコルにUDPを使用する場合も、アプリ種別が「ストリームデータ」でRTPを使用する。しかし、この場合は、ステップS3612からステップS3614へ進み、RTPプロトコルヘッダの付加処理の起動制御を回避して、データ送信処理を実施する。そして、ステップS3615において、通信の完了を確認し、通信完了で、接続中状態に遷移する。また、通信継続の場合にはステップS3610に戻り、データ受信処理を繰り返す。
一方、STA102から動画像データ(M3309)を受信したSTA105での処理は、第3の実施形態と同様であり、その説明は省略する。
ここで、動画像ファイルに対するサービスとして「複写・保存」を選択した際のアプリ種別情報である「ファイル転送」処理を説明する。
ノートPC111で動画像データ(M3310)の再生を停止し、データファイル取得シーケンス(M3300)と同様に、ノートPC111の画面上でHDR108内に保存された再生ファイルの一覧を参照する。そして、ユーザが所望の動画ファイルの「保存」を選択すると、ノートPC111はアプリ種別情報に「ファイル転送」と指定ファイル情報を含む複写・保存要求メッセージ(M3311)をSTA105に送信する。
一方、STA105がノートPC111から複写・保存要求メッセージ(M3311)を受信すると、メッセージに含まれるアプリ種別「ファイル転送」を記憶領域部208に格納する。そして、HDR108の接続されたSTA102に対して、アプリ種別情報に「ファイル転送」と指定ファイル情報を含む複写・保存要求メッセージ(M3312)を送信する。
ここで、STA102がSTA105から複写・保存要求メッセージ(M3312)を受信すると、メッセージに含まれるアプリ種別「ファイル転送」を記憶領域部208に格納する。そして、アプリ種別情報に「ファイル転送」と指定ファイル情報を含む複写・保存要求メッセージ(M3313)をHDR108に送信する。
これにより、HDR108がアプリ種別情報に「ファイル転送」と指定ファイル情報を含む複写・保存要求メッセージ(M3313)を受信すると、指定ファイル情報より該当する動画動ファイルデータ(M3314)をSTA102に送信する。
一方、動画像データの場合と同様に、STA102がHDR108から動画動ファイルデータ(M3314)を受信すると、記憶領域部208に格納したアプリ種別を確認する。ここで、アプリ種別が「ファイル転送」の場合は、通信プロトコルにTCPを使用するためステップS3611のYESへ進み、ステップS3614のデータ送信処理でSTA105に動画動ファイルデータ(M3315)を送信する。これ以降の処理は、上述した動画像データの場合と同様である。
一方、STA105が動画像ファイルデータ(M3315)を受信すると、ステップS3708でデータ解析を行う。ここで、受信したデータにRTP/RTCPプロトコルヘッダ情報が付加されていないので、ステップS3711へ進み、RTPを使用しないTCPによるデータ受信処理を行う。そして、ステップS3712において、動画像ファイルデータ(M3316)をノートPC111に送信し、ステップS3713で通信の完了を確認し、通信完了であれば、接続中状態に遷移する。また、通信継続の場合はステップS3707に戻り、データ受信処理を繰り返す。
以上、STA102とSTA105において、HDR108とノートPC111のデバイス間で起動されるアプリケーションの種別に応じて使用するプロトコル処理を制御する。これにより、確実性の要求される送受信データに対する不要なQoS関連プロトコルの付加処理を回避できる。従って、リアルタイム性の要求される入出力データに対する適切なQoS関連プロトコル処理を提供することが可能となる。
[第5の実施形態]
次に、図面を参照しながら本発明に係る第5の実施形態について詳細に説明する。第5の実施形態では、DVC109と液晶テレビ110のように、デバイスが異なるインターフェースでSTAに接続される場合について説明する。
図38は、DVC109から液晶テレビ110へ直接動画をストリーム伝送する状態を示す図である。図38に示すように、DVC109はUSBケーブル116を介してSTA103に接続され、液晶テレビ110はIEEE1394ケーブル114を介してSTA104に接続される。
図39は、図38に示すストリーム伝送で送受信されるメッセージのシーケンスを示す図である。また、図39に示すシーケンス内のメッセージは、第5の実施形態に関する主なもののみを明記し、一部のメッセージについては省略している。
図40は、図39に示す送信側STA103における送信フレームの処理フローを示す図である。図40に示す例は、DVC109がQoSプロトコル処理をサポートしていない場合である。図40において、4001はデバイス側のメモリ制御処理であり、DVC109からUSB制御部210を介して受信した動画像データを記憶領域部208のデコード用バッファメモリ(Dbuf)に書き込む。RTP処理部503以降は、図5に示す第1の実施形態と同様であり、その説明は省略する。
図41は、DVC109がQoSプロトコル処理をサポートする場合の送信フレームの処理フローを示す図である。尚、図41は、デバイス側のメモリ制御処理が異なるだけで、図6に示す第1の実施形態と同様であり、その説明は省略する。
また、受信側STA104における受信フレームの処理は、図7及び図8に示す第1の実施形態と同様であり、その説明は省略する。
ここで、図39に示すシーケンスに従ってDVC109から液晶テレビ110へ動画をストリーム伝送する処理の詳細を説明する。
図42は、第5の実施形態における送信側STA103の処理を示すフローチャートである。図43は、第5の実施形態における受信側STA104の処理のフローチャートである。
図39に示すシーケンスにおいて、まず送信デバイス側STA103がQAP106のサービスエリア内に設置されるか、STA103の電源が投入されると、QAP106との間でアソシエーション処理(M401)を行う。そして、ステップS1001において、STA103がアソシエーション処理(M401)を完了するとステップS1002へ進み、STA103はDVC109とのUSB接続シーケンス処理(M3901)の完了判定を行う。
一方、送信デバイスであるDVC109では、STA103との接続操作、或いはデバイス本体の電源投入などが行われる。そして、ステップS901で、STA103との間でUSB接続シーケンス処理(M3901)を完了するとステップS902へ進み、システム内に収容する全てのSTAの更新情報をSTA103から受信する。
次に、STA104におけるアソシエーション処理(M402)、液晶テレビ110におけるIEEE1394接続シーケンス処理(M404)、種別登録処理が第1の実施形態と同様に行われる。
次に、液晶テレビ110の画面上にあるシステム内に接続収容されている送受信可能なデバイスの収容状況、性能、及び状態を明示したアイコンよりDVC109が選択されるとステップS905へ進む。ステップS905では、液晶テレビ110はDVC109を特定する情報と動画像データのフォーマット形式(MPEG-TS)を含む接続要求メッセージ(M3903)をSTA104に送信する。
一方、ステップS4301において、STA104が液晶テレビ110から接続要求のメッセージを受信するとステップS4313へ進み、液晶テレビ110の「動画像データのフォーマット形式(MPEG-TS)情報」を記憶領域部208に格納する。次に、ステップS4314において、QAP106のダイレクトリンクサービスの制御下において異なるSTAとの直接通信が可能か否かの判断を行い、直接通信が不可能な場合はステップS4316へ進む。ステップS4316では、通信不可能である旨の情報を含む接続応答メッセージ(M3908)を液晶テレビ110に送信し、ステップS4301に戻る。また、直接通信が可能な場合はステップS4315へ進み、ダイレクトリンクサービスの設定要求(DLS要求)メッセージ(M412)をQAP106に送信し、ステップS4301に戻る。
ここで、QAP106、STA103、及びSTA104との間でDLS処理が第1の実施形態と同様に行われ、STA104がDLS応答メッセージ(M415)を受信するとステップS4304へ進む。ステップS4304では、DVC109を特定する情報と記憶領域部208に格納した液晶テレビ110の「動画像データのフォーマット形式情報(MPEG-TS)」とを含む接続要求メッセージ(M3904)をSTA103に送信する。そして、ステップS4305において、接続応答メッセージ待ち状態となる。
一方、STA103がSTA104から接続要求メッセージ(M3904)を受信するとステップS4204へ進み、転送モードや通信情報が一致するか判定する。この処理は接続要求メッセージに含まれる要求元(受信デバイス側)STA104の識別情報に基づいて判定を行う。ここで、動画像ストリームの通信が可能と判断された場合はステップS4205へ進み、動画像データのフォーマット形式情報(MPEG-TS)を記憶領域部208に格納する。そして、動画像データのフォーマット形式情報(MPEG-TS)を含む接続要求メッセージ(M3905)をDVC109に送信する。
そして、ステップS4206において、DVC109から動画像データのフォーマット形式情報(MPEG-TS)を含む接続応答メッセージ(M3906)を受信するとステップS4207へ進む。ステップS4207では、動画像データのフォーマット形式情報(MPEG-TS)を含む接続要求メッセージ(M3907)をSTA104に送信する。そして、ステップS4208において、IEEE802.11e標準で規定される帯域予約シーケンス(M3909)をQAP106との間で行う。
次に、ステップS4209において、帯域予約シーケンス(M3909)が完了するとステップS4210へ進み、接続完了表示メッセージ(M3910)をDVC109に送信する。この時点では、DVC109からの送信データを受けていないため、ステップS4211のデータ受信待ち状態に遷移する。これ以降、動画像データの受信処理が第1の実施形態と同様に行われる。
一方、ステップS4305において、STA104が動画像データのフォーマット形式情報(MPEG-TS)を含む接続要求メッセージ(M3907)を受信するとステップS4306へ進む。ステップS4306では、動画像データのフォーマット形式情報(MPEG-TS)を含む接続応答メッセージ(M3908)を液晶テレビ110に送信し、データ受信待ち状態へ遷移する。その後、第1の実施形態と同様に、DVC109からSTA103へ動画像データが送信され、STA104を介して液晶テレビ110に送信される。
以上、STA103とSTA104において、デバイス間のインターフェースにおける転送モードの整合性を検証することにより、効果的なQoS関連プロトコルの付加処理を行うことができる。従って、リアルタイム性の要求される入出力データに対する適切なQoS関連プロトコル処理を提供することが可能となる。
[他の実施形態]
上述した実施形態では、STAがデバイスのQoS対応状況を把握し、動画像データに対してRTPヘッダの付加或いは除去を行い、リアルタイム性の要求される入出力データに対する適切なQoS関連プロトコル処理のサポートについて説明した。しかし、RTPヘッダ以下のRTPペイロードを拡張し、送信側STAの入力デバイスからのデータ受信処理におけるバッファメモリの使用状況を受信側STAに送信し、メモリバッファ制御用の情報として使用するようにしても良い。
図44は、他の実施形態1におけるRTP送信処理フレームを示す図である。図44に示すように、RTPペイロードを拡張して受信側STAのバッファ情報を送信するものである。ここで、「全バッファ」とは、受信側STAの受信バッファの総数であり、「空きバッファ」とは、受信側STAの受信バッファの空きバッファ数である。
以上、メモリバッファの状態情報の送信により、送受信するSTA間でのバッファオーバーラン、及びバッファアンダーランの発生を抑制し、メモリバッファ制御処理が可能となる。これにより、リアルタイム性の要求される入出力データに対する更に適切なQoSが実現される。
上述した実施形態では、種別登録を行った後、システム内に収容する全ての端末の更新情報である種別情報をデバイスに送信しているが、図45に示すように、この処理を省略しても良い。
図45は、他の実施形態2におけるメッセージのシーケンスを示す図である。図45に示すように、STAと任意のデバイス間をIEEE1394ケーブルで接続した際のバスID及びノードIDを用いて特定の機器を識別する。これにより、接続初期時における所定の設定処理の一部を省略することができる。
この場合、任意の入出力デバイスとSTA間の接続形態がIEEE1394インターフェース、又はUSBインターフェースの場合、デバイス識別情報を図46に示すように管理しても良い。
図46は、STAと任意のデバイスをIEEE1394ケーブル又はUSBケーブルで接続した際のインターフェース毎の識別子と転送モードとを対応させたテーブルである。図46において、4601はIEEE1394インターフェースのバスIDである。4602はIEEE1394インターフェースのノードIDである。4603はUSBインターフェースのアドレスである。そして、4604はID毎の転送モードであり、4605はID毎のQoSサポート状況を示したものである。
また、通信終了時に、使用したサービス固有のアプリケーション種別の履歴を保存し、データ通信の再起動時に、前回のデータ通信で使用したサービス固有のアプリケーション種別の履歴を読み出し、QoS関連プロトコル処理を制御しても良い。
図47は、USBインターフェースのアプリケーションを識別する図である。図47において、4701はアプリケーション1のエンドポイント群であり、4702はアプリケーション2のエンドポイント群である。
図47に示すように、STAとデバイスにおいて、エンドポイント毎にサービスを区別し、対応するQoS関連プロトコルの処理を制御する。
上述した第3の実施形態では、ユーザプライオリティを解析し、QoS関連プロトコル処理を制御しているが、図48に示すように、RSVP、IntServ、DiffServの使用に応じて制御しても良い。
図48は、他の実施形態におけるデバイス管理情報の構成を示す図である。4801はSTA102のQoS処理(DiffServ)のサポートを示し、4802はSTA105のQoS処理(DiffServ)のサポートを示す。また、4803はSTA102のQoS処理(IntServ/RSVP)のサポートを示し、4804はSTA105のQoS処理(IntServ/RSVP)のサポートを示す。
また、種別情報メッセージをQAP106から受信した際に、記憶領域部208に保存しているが、STAに接続されるデバイスの電源オフやインターフェースの切断の際に、デバイス情報を削除する。
図49は、デバイス管理情報の消去を説明するための図である。図49において、4901は切断されたデバイスの管理情報を検出し、4902はその管理情報を削除した状態である。
また、デバイスとSTAとの間のインターフェース種別が「IEEE1394」で、転送モードが「アイソクロナス」によるストリーム型の動画像データ通信を説明したが、これだけに限るものではない。例えば、インターフェース種別が「USB」で、転送モードが「アイソクロナス」によるストリーム型の動画像データ通信でに適用することができる。
また、システム端末情報メッセージに含まれるデバイスの最新情報として、全収容中のデバイスとSTAの情報ではなく、新規で登録されたデバイス情報の差分のみを送信するようにしても良い。更に、システム端末情報メッセージは新規接続収容手順が実施される度に、収容中の全STAに送信されるように構成しても良い。
以上説明した実施形態によれば、入出力機能を備えたデバイスをIPネットワーク環境に収容する際に用いられるアダプタ装置において、デバイス間で送受信される通信データに対するQoS関連プロトコルの冗長性を回避できる。
また、リアルタイム性の要求される入出力データに対する適切なQoS関連プロトコルのカプセル化、デカプセル化が可能となる。
本実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ(CPU若しくはMPU)が記録媒体に格納されたプログラムコードを読出し実行する。これによっても、本発明の目的が達成されることは言うまでもない。
この場合、記録媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
このプログラムコードを供給するための記録媒体として、例えばフレキシブルディスク,ハードディスク,光ディスク,光磁気ディスク,CD−ROM,CD−R,磁気テープ,不揮発性のメモリカード,ROMなどを用いることができる。
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、次の場合も含まれることは言うまでもない。即ち、プログラムコードの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)などが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合である。
更に、記録媒体から読出されたプログラムコードがコンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込む。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合も含まれることは言うまでもない。