(57)【要約】【課題】上位アプリケーションとの通信の互換性を確保するとともに、データ転送効率を向上することができ、且つ処理負荷を最小限に抑えること。【解決手段】他の通信相手との間で信号の送受信を行う物理層１０８と、上位のユーザアプリケーション１００と物理層１０８との間を接続するプロトコル変換部（ＰＣＬ）１０２とを備え、プロトコル変換部１０２は、ユーザアプリケーション１００から送られた通信開始要求データ（ＣＢＷ）から、所定のパラメータを抽出するパラメータ抽出部１０２ｃと、ユーザアプリケーション１００から送られた送信データに抽出したパラメータを含むヘッダを付加するヘッダ付加部１０２ｄと、を含み、物理層１０８は、ヘッダが付加された送信データを送信する。【選択図】図８
2009182459.tif 000002
【特許請求の範囲】
【請求項１】
他の通信相手との間で信号の送受信を行う物理層と、
上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、
前記プロトコル変換部は、
前記上位アプリケーションから送られた通信開始要求データから、所定のパラメータを抽出するパラメータ抽出部と、
前記上位アプリケーションから送られた送信データに前記パラメータを含むヘッダを付加するヘッダ付加部と、を含み、
前記物理層は、前記ヘッダが付加された前記送信データを送信することを特徴とする、通信装置。
【請求項２】
前記プロトコル変換部は、前記送信データを所定のデータ量毎に分割するデータ分割部を含み、
前記ヘッダ付加部は、前記データ分割部による分割で得られた複数の送信データに対して１つの前記ヘッダを付加することを特徴とする、請求項１に記載の通信装置。
【請求項３】
前記プロトコル変換部は、前記物理層を介して他の通信相手から受信した受信データから前記パラメータを取得するパラメータ取得部を含むことを特徴とする、請求項１に記載の通信装置。
【請求項４】
前記パラメータに基づいて、前記受信データを記憶領域の所定位置に書き込むデータ書込部を備えることを特徴とする、請求項１に記載の通信装置。
【請求項５】
前記パラメータは、データの送信方向を示すエンドポイント情報、データのサイズを示すサイズ情報を含むことを特徴とする、請求項１に記載の通信装置。
【請求項６】
通信装置同士が通信を行う通信システムであって、
前記通信装置は、
通信相手となる通信装置の間で信号の送受信を行う物理層と、
上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、
前記プロトコル変換部は、
前記上位アプリケーションから送られた通信開始要求データから、所定のパラメータを抽出するパラメータ抽出部と、
前記上位アプリケーションから送られた送信データに前記パラメータを含むヘッダを付加するヘッダ付加部と、を含み、
前記ヘッダが付加された前記送信データを、前記物理層を介して送受信することを特徴とする、通信システム。
【請求項７】
他の通信相手との間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備える通信装置における通信方法であって、
前記上位アプリケーションから送られた通信開始要求データから、所定のパラメータを抽出するステップと、
前記上位アプリケーションから送られた送信データに前記パラメータを含むヘッダを付加するステップと、
前記ヘッダが付加された前記送信データを、前記物理層を介して送信するステップと、
を備えることを特徴とする、通信方法。
【請求項８】
他の通信相手との間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備える通信装置におけるプログラムであって、
前記上位アプリケーションから送られた通信開始要求データから、所定のパラメータを抽出する手段、
前記上位アプリケーションから送られた送信データに前記パラメータを含むヘッダを付加する手段、
前記ヘッダが付加された前記送信データを、前記物理層を介して送信する手段、
としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信システム、通信方法及びプログラムに関する。
【背景技術】
【０００２】
従来、例えば下記の特許文献１に記載されているように、移動体の利用者が所有する汎用の携帯端末に移動体の情報を発信できることを意図した移動体通信システムが知られている。
【０００３】
【特許文献１】特開２００５−１９１８１９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
近時においては、通信装置に多種の上位アプリケーションが搭載されることが想定され、通信装置側で各種の上位アプリケーションに対応する必要がある。しかしながら、通信装置が備える物理層と各種の上位アプリケーションとの互換性を持たせることを想定した場合、上位アプリケーションが想定している物理層のデータを、通信装置が備える、転送サイズ等が異なる別の種類の物理層に流す必要が発生する。このため、データの結合、分割等の処理を行う必要が生じ、装置の負荷が増大するという問題が生じる。
【０００５】
また、データを受信した装置においても、受信したデータを全て解析した上で、上位アプリケーションに渡すために、データの種別、メモリ上での書き込み位置等を解析する必要が生じ、やはり装置の負荷が増大するという問題がある。
【０００６】
例えば上位アプリケーションがＵＳＢの場合のパケット転送において、通常は、図１８に示すように、ＵＳＢ物理層を介してＵＳＢホストとＵＳＢターゲットとの間で通信が行われる。この場合、ＵＳＢホストからＵＳＢターゲットへの通信要求（ＣＢＷ）送信、データ（ＤＡＴＡ）転送、ＵＳＢターゲットからＵＳＢホストへの完了通知（ＣＳＷ）の送信という流れの処理になる。なお、データの転送方向は、ＣＢＷの内容に応じて変わり、図１８に示すように、ＵＳＢホストが読み出し動作（ＲＥＡＤ動作）を行う場合は、ＵＳＢターゲットからＵＳＢホストへデータが送られる。また、ＵＳＢホストが書き込み動作（ＷＲＩＴＥ動作）を行う場合は、ＵＳＢホストからＵＳＢターゲットへデータが送られる。ＣＢＷ、ＣＳＷは数１０バイト程度のデータ量である。一方、ＵＳＢ物理層では、データが５１２バイトを超える場合は、分割して送信される。５１２バイトのデータを何回送るかについては、ＣＢＷのデータに記載されている。
【０００７】
図１８の場合において、ＵＳＢ物理層の代わりに複数のアプリケーションに対応可能な互換性のある物理層を設けた場合、上位アプリケーション（ＵＳＢ物理層）のデータそのものを、別の転送サイズを持つ物理層に流す必要が生じる。このため、上位アプリケーション（ＵＳＢ物理層）のデータを、互換性のある物理層の転送サイズに合わせて更に結合したり、分割したりすることになる。これにより、処理の負荷が増えると共に、実質的なデータ以外のデータ転送が増加し、転送効率が低下してしまう。また、受信装置側では、受信データを上位アプリケーションに送るために、データの再結合処理を行う必要があり、負荷が増大してしまう。
【０００８】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、上位アプリケーションとの通信の互換性を確保するとともに、データ転送効率を向上することができ、且つ処理負荷を最小限に抑えることが可能な、新規かつ改良された通信装置、通信システム、通信方法及びプログラムを提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明のある観点によれば、他の通信相手との間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、前記プロトコル変換部は、前記上位アプリケーションから送られた通信開始要求データから、所定のパラメータを抽出するパラメータ抽出部と、前記上位アプリケーションから送られた送信データに前記パラメータを含むヘッダを付加するヘッダ付加部と、を含み、前記物理層は、前記ヘッダが付加された前記送信データを送信する通信装置が提供される。
【００１０】
上記構成によれば、物理層により他の通信相手との間で信号の送受信が行われ、プロトコル変換部により上位アプリケーションと物理層との間が接続される。パラメータ抽出部により、上位アプリケーションから送られた通信開始要求データから所定のパラメータが抽出され、ヘッダ付加部により、上位アプリケーションから送られた送信データに抽出されたパラメータを含むヘッダが付加される。そして、物理層により、ヘッダが付加された送信データが送信される。従って、通信開始要求より必要最小限のパラメータを抽出してヘッダとして付加することで、転送速度を高速化することが可能になるとともに、データを受信した機器側において、パラメータ解析に要する負荷を大幅に軽減することが可能となる。
【００１１】
また、前記プロトコル変換部は、前記送信データを所定のデータ量毎に分割するデータ分割部を含み、前記ヘッダ付加部は、前記データ分割部による分割で得られた複数の送信データに対して１つの前記ヘッダを付加するものであってもよい。かかる構成によれば、通信の大部分を占める送信データに、細かいヘッダ情報を１度にまとめることで、転送効率を高めることが可能となる。
【００１２】
また、前記プロトコル変換部は、前記物理層を介して他の通信相手から受信した受信データから前記パラメータを取得するパラメータ取得部を含むものであってもよい。かかる構成によれば、受信データからパラメータを取得することで、パラメータに基づいて受信データに関する各種情報を取得することが可能となる。
【００１３】
また、前記パラメータに基づいて、前記受信データを記憶領域の所定位置に書き込むデータ書込部を備えるものであってもよい。かかる構成によれば、パラメータから受信データの記録位置を取得することで、受信データ全てを解析することなく受信データを所定の位置に書き込むことができる。
【００１４】
また、前記パラメータは、データの送信方向を示すエンドポイント情報、データのサイズを示すサイズ情報を含むものであってもよい。かかる構成によれば、パラメータに基づいてデータの転送方向又はサイズ情報を取得することが可能となる。
【００１５】
また、上記課題を解決するために、本発明の別の観点によれば、通信装置同士が通信を行う通信システムであって、前記通信装置は、通信相手となる通信装置の間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、前記プロトコル変換部は、前記上位アプリケーションから送られた通信開始要求データから、所定のパラメータを抽出するパラメータ抽出部と、前記上位アプリケーションから送られた送信データに前記パラメータを含むヘッダを付加するヘッダ付加部と、を含み、前記ヘッダが付加された前記送信データを、前記物理層を介して送受信する通信システムが提供される。
【００１６】
上記構成によれば、通信装置同士が通信を行う通信システムにおいて、通信装置では、物理層により他の通信相手との間で信号の送受信が行われ、プロトコル変換部により上位アプリケーションと物理層との間が接続される。また、パラメータ抽出部により、上位アプリケーションから送られた通信開始要求データから所定のパラメータが抽出され、ヘッダ付加部により、上位アプリケーションから送られた送信データに抽出されたパラメータを含むヘッダが付加される。そして、物理層により、ヘッダが付加された送信データが送信される。従って、通信開始要求より必要最小限のパラメータを抽出してヘッダとして付加することで、転送速度を高速化することが可能になるとともに、データを受信した機器側において、パラメータ解析に要する負荷を大幅に軽減することが可能となる。
【００１７】
また、上記課題を解決するために、本発明の別の観点によれば、他の通信相手との間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備える通信装置における通信方法であって、前記上位アプリケーションから送られた通信開始要求データから、所定のパラメータを抽出するステップと、前記上位アプリケーションから送られた送信データに前記パラメータを含むヘッダを付加するステップと、前記ヘッダが付加された前記送信データを、前記物理層を介して送信するステップと、を備える通信方法が提供される。
【００１８】
上記構成によれば、他の通信相手との間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備える通信装置における通信方法において、上位アプリケーションから送られた通信開始要求データから所定のパラメータが抽出され、上位アプリケーションから送られた送信データに抽出されたパラメータを含むヘッダが付加され、ヘッダが付加された送信データが物理層を介して送信される。従って、通信開始要求より必要最小限のパラメータを抽出してヘッダとして付加することで、転送速度を高速化することが可能になるとともに、データを受信した機器側において、パラメータ解析に要する負荷を大幅に軽減することが可能となる。
【００１９】
また、上記課題を解決するために、本発明の別の観点によれば、他の通信相手との間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備える通信装置におけるプログラムであって、前記上位アプリケーションから送られた通信開始要求データから、所定のパラメータを抽出する手段、前記上位アプリケーションから送られた送信データに前記パラメータを含むヘッダを付加する手段、前記ヘッダが付加された前記送信データを、前記物理層を介して送信する手段、としてコンピュータを機能させるためのプログラムが提供される。
【００２０】
上記構成によれば、他の通信相手との間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備える通信装置におけるプログラムにおいて、上位アプリケーションから送られた通信開始要求データから所定のパラメータが抽出され、上位アプリケーションから送られた送信データに抽出されたパラメータを含むヘッダが付加され、ヘッダが付加された送信データが物理層を介して送信される。従って、通信開始要求より必要最小限のパラメータを抽出してヘッダとして付加することで、転送速度を高速化することが可能になるとともに、データを受信した機器側において、パラメータ解析に要する負荷を大幅に軽減することが可能となる。
【発明の効果】
【００２１】
本発明によれば、上位アプリケーションとの通信の互換性を確保するとともに、データ転送効率を向上することができ、且つ処理負荷を最小限に抑えることが可能となる。
【発明を実施するための最良の形態】
【００２２】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００２３】
本実施形態の無線通信システムは、一対の機器の間でデータを送受信することを目的とした通信方式であり、近距離の機器間で無線によりデータの送受信を行う。図１は、本実施形態の無線通信システムを構成する２つの機器（通信装置）を示す模式図である。２つの機器は、それぞれレスポンダー(Responder)とイニシエータ(Initiator)という役割を有する。イニシエータは「接続要求を出す側」であり、レスポンダーは「接続要求を受ける側」であり、本実施形態では１対１(P2P)の通信が行われる。接続の際、イニシエータは接続要求を出し、レスポンダーは持ち受け状態となるが、両者は接続の際の役割が異なるのみで、接続に関係する機器の構成は同一である。イニシエータとしては例えばパーソナルコンピュータ、携帯機器、電子カードなどが該当し、レスポンダーとしてはパーソナルコンピュータ、携帯機器、電子カードなどの機器が該当する。
【００２４】
図１では、本実施形態の各機器のそれぞれが備える物理層を介して無線通信が行われる様子を模式的に示している。本実施形態では、物理層としてＪＥＴ物理層と称されるものを例示するが、物理層はこれに限定されるものではなく、通信用の汎用的な物理層に適用することができる。ＪＥＴ物理層は、後述するプロファイルＩＤ、ＣＳＤＵ等を用いることで写真、動画などの大容量のデータ通信に特に適したものである。また、本明細書において、イニシエータ、レスポンダーの双方の機器を総称してＪＥＴデバイス（または単にＪＥＴ）と称する場合がある。
【００２５】
図２は、本実施形態に係る無線通信システムにおいて、イニシエータ、レスポンダーの各機器の構成を階層構造として示した模式図である。図２に示すように、本実施形態では、上層から順にユーザアプリケーション(User Application)１００、ＰＣＬ(Protocol Conversion Layer)１０２、ＤＴＬ(Data Transfer Layer)１０４、ＣＮＬ(Connection Layer)１０６、物理層(Physical Layer)１０８が構成されている。
【００２６】
ユーザアプリケーション１００は、本実施形態による近距離無線通信が可能な物理層１０８を搭載する機器において、物理層１０８の上層のソフトウェアの提供するサービスを用いて、データ通信を行うための上位プロトコル（例えばUSB、TCP/IP、OBEXなど）や、UI(User Interface)等のJETを含めた機器操作を行うアプリケーション（例えばウィンドウズ(Windows(登録商標）)、リナックス(Linux)などのＯＳ）が該当する。ＪＥＴデバイスでは、これらの上位プロトコル、またはユーザアプリケーションについては特に規定されるものではなく、機器を構成するユーザ（メーカ）が自由に設定することができる。従って、各機器は、複数の上位プロトコル、またはユーザアプリケーション１００を備えていても良い。
【００２７】
ＰＣＬ１０２（プロトコル変換部）は、機器を構成するユーザが使用する任意のプロトコル（USB、TCP/IP、OBEX等）を、JET独自のプロトコルに相互変換する、プロトコル変換(Protocol Conversion)機能をサポートする。これにより、複数の種類のプロトコルをJETの物理層(PHY Layer)１０８に流すことで、様々なプロトコルをサポートすることが可能である。なお、同じＵＳＢであっても、Windows、LinuxなどのＯＳの違いによってプロトコル変換が異なる場合がある。ＰＣＬ１０２は、上位のユーザアプリケーション１００が生成する音声、映像等のコンテンツデータ、その他のプロトコルのデータ、コマンド等を下位のＤＴＬ１０４が扱うことが可能なデータ形式に変換する処理を行う。また、ＰＣＬ１０２は、接続、切断、機器認証、動作モード設定、初期化等のJETの通信に必要な処理を行う。
【００２８】
図３は、イニシエータ、レスポンダーにおけるデータの流れを示す模式図である。図３に示すように、ユーザアプリケーション１００はJETによる接続と、データ転送の２種類の制御を行うことになる。JETとしては最上位ＰＣＬ１０２でこれらの機能を実現するために必要なサービスを提供し、JET独自のプロトコルへの変換と、接続管理を行う。さらにJET規格に準拠したCSDU (CNL service data unit)を生成するＤＴＬ１０４、ＣＮＬ１０６への受け渡しを行う。
【００２９】
ＤＴＬ１０４は、上位のＰＣＬ１０２から受け取ったデータを、所定のパケット構造に整形し、下位のＣＮＬ１０６が提供するサービスを用いて、イニシエータ、レスポンダー間の送信を行う。また、受信においては、ＣＮＬ１０６が受信したデータを解析し、ＣＳＤＵを抽出し、そのペイロードを上位のＰＣＬ１０２に引き渡す。ＣＳＤＵには、物理層(PHY Layer)１０８による通信以外のユーザアプリケーション１００で利用可能なステータス情報も含まれており、ＤＴＬ１０４は、これらの生成処理、エラー通知等も行う。
【００３０】
ＤＴＬ１０４は、上位プロトコルの種別に関わらず、上位から入力されたデータをDTLパケットに整形して下位のＣＮＬ１０６に渡し、下位からの受信データからDTLパケットを抽出し、上位にDTLパケットペイロードを受け渡すことが可能である。ただし、ＤＴＬ１０４自身は、ＰＣＬ１０２からの異なるprotocolから送られてくるデータを受け入れることが可能ではあるが、ＪＥＴでは異なるプロトコルのデータの送受信は一度セッションの切断を必要とするため、複数プロトコルでのＤＴＬサービスの利用は行わない。
【００３１】
この制限により、後述する複数のＰＣＬエミュレーションからＤＴＬ１０４へデータの入力が行われたとしても、ＤＴＬ１０４はそのデータのＭｕｘを行うことはない。また、ＣＮＬ１０６からの受信データに複数のプロトコルが含まれていた場合であっても、そのプロトコルの解析、それぞれのプロトコル内容に合わせたＰＣＬ１０２への配信、またはエラー検知によるセッションの切断等の処理は行わない。
【００３２】
このため、ＤＴＬ１０４によるサービスを利用するＰＣＬ１０２側では、必ず利用するプロトコルを１種類に確定した状態でＤＴＬ１０４によるサービスを利用する必要がある。これらのプロトコル方式を確定させるための判断と、必要な送受信を行うのは後述するＰＣＬコモンの役割であり、プロトコルデータの生成、パースはＰＣＬエミュレーションが行う。複数のプロトコルから同時にＤＴＬサービスを利用できないよう排他処理もＰＣＬコモンの役割である。
【００３３】
ＤＴＬ１０４はＰＣＬコモンが接続を確立するのに必要なサービス、接続確立後にＰＣＬエミュレーションがデータの送受信を行うのに必要なサービスを提供する。
【００３４】
また、ＤＴＬ１０４は、現在実行されているサービスが、全転送サイズの途中データなのか、最後のデータなのか、もしくは、データではなくパラメータなのかを示すプロファイルＩＤ(Profile ID)、サイズをＰＣＬ１０２よりパラメータとして受け取り、下位のＣＮＬサービスを利用して生成するCSDUパケットヘッダに挿入する。ＤＴＬ１０４は、送信パラメータを、JETがデータを送信する際に生成するCSDUパケットの一部に埋め込むことで図６のような複数の論理チャネル(Channel)を１つの物理層(PHY Layer)１０８上で実現する。
【００３５】
ＤＴＬ１０４は、JET規格に定義されているCSDUパケットを生成する機能を有する。ＤＴＬ１０４では、CSDUパケットの種別を理解するためのパラメータをCSDUパケットヘッダに付加する。付加するものはProfile ID , Size , Data Payloadである。
【００３６】
ＤＴＬ１０４はCNL１０６が提供するCSDUの単位でデータ転送を行う。DTL１０４はCSDU送信時に以下の３種類のプロファイルＩＤ(T_DATA, LT_DATA, CNL_DATA)をCSDUに対して付与する。さらに、CSDU受信時は、プロファイルＩＤの種類に応じた処理を行う。
【００３７】
T_DATA, LT_DATA
DTL１０４は、ユーザデータを転送するCSDUに対して、T_DATAを付与する。ただし、CSDUペイロードへの分割において、最終のCSDUとなる場合にはLT_DATAを付与する。CSDUのペイロードには、ユーザデータのみが格納され、DTL１０４がヘッダ情報などを埋め込むことはない。
【００３８】
CNL_DATA
ＤＴＬ１０４は、JETシステム固有の制御データを転送するCSDUに対して、CNL_DATAを付与する。制御データの例としては、パラメータ情報などがある。CSDUペイロードにはヘッダ情報(詳細はTBD)が埋め込まれる。ＤＴＬ１０４はこのヘッダ情報を解釈し、適切な処理を行う。
【００３９】
ＣＮＬ１０６は、上位のＤＴＬ１０４の要求に応じて、物理層１０８のサービスを利用した通信を行う他、物理層１０８の接続の確立、切断、データの連続性の保障などを行う。
【００４０】
物理層１０８は、本実施形態による近距離大容量通信が可能な無線通信システムのＪＥＴ物理層であり、誤り訂正機能、プリアンブルセンス(preamble sense)機能を含む。
【００４１】
図４は、ＪＥＴデバイスを搭載する機器のソフトウェアの役割に基づいて、図２の構成をＯＳＩ参照モデルで示したものである。図４に示すように、物理層（第１層）１０８は、データを通信回線に送出するための電気的な変換や機械的な作業を受け持つ。ピンの形状やケーブルの特性なども第１層で定められる。
【００４２】
ＤＴＬ１０４、ＣＮＬ１０６は、データリンク層（第２層）、トランスポート層（第４層）に対応する。データリンク層は、通信相手との物理的な通信路を確保し、通信路を流れるデータのエラー検出などを行う。また、トランスポート層は、通信相手まで確実に効率良くデータを届けるためのデータ圧縮や誤り訂正、再送制御などを行う。なお、本実施形態のシステムはP2P通信であるため、ＯＳＩ参照モデルにおけるネットワーク層（第３層）は設けられておらず、システムを簡略化することができる。
【００４３】
ＰＣＬ１０２は、セッション層（第５層）とプレゼンテーション層（第６層）が対応する。セッション層は、通信プログラム同士がデータの送受信を行うための仮想的な経路（コネクション）の確立や解放を行う。プレゼンテーション層は、セッション層から受け取ったデータをユーザが分かり易い形式に変換したり、アプリケーション層から送られてくるデータを通信に適した形式に変換するなどの処理を行う。
【００４４】
ユーザアプリケーション１００は、アプリケーション層（第７層）に対応する。アプリケーション層は、データ通信を利用した様々なサービスを人間や他のプログラムに提供する。
【００４５】
次に、本実施形態の通信装置におけるデータの流れを説明する。図５は、データフローを示す模式図であって、JET機器内の各レイヤーにおけるファイル、データの送受信のデータフローを示している。なお、ＰＣＬ１０２は、ＰＣＬコモンとＰＣＬエミュレーションに機能が分かれる。データ転送で利用するのはＰＣＬエミュレーションであるため、図５に示すＰＣＬ１０２による処理はＰＣＬエミュレーションによって実現される機能である。物理層１０８に入力されるCSDUは、データフォーマットとして規定されており、そのヘッダ情報等の生成、解析を行うＤＴＬ１０４が扱うデータフォーマットも同様である。
【００４６】
また、後述するように、共通機能を提供するためのＰＣＬコモンについては規定されているが、ＰＣＬエミュレーションは、ユーザプロトコルに準じたデータ変換処理を行うため、それぞれのプロトコルに応じたシステム仕様に依存する。
【００４７】
JET通信では、ファイル等のデータだけではなく、ＰＣＬ１０２、ＤＴＬ１０４内での管理パラメータや、通信先の同一レイヤー間でのデータの送受信が存在する。これらのファイル、パラメータ類は、ＣＮＬ１０６によって最終的にCSDUフォーマットに準拠した形式で伝送される。図６は、CSDUによる論理的なチャネルを示す模式図である。図６に示すように、データの種別を特定するにはProfile IDを用いる。これにより、物理層１０８のレベルで、複数の伝送Channelを論理的に用いることが可能となる。従って、通信レートを大幅に向上させることができ、特に動画などの大容量のデータ通信に適している。
【００４８】
図７は、CSDUがマッピングされる様子を示す模式図である。CSDUは、ＣＮＬ１０６とＤＴＬ１０４の間でやり取りされるデータユニットであり、図７に示すように、CNLフレームにマッピングされる。ユーザアプリケーション１００が送受信するユーザデータサイズは特に規定されない。ＰＣＬ１０２は、データの長さがデータ分割長（最大4096バイト）を超えた場合、複数のCSDUペイロードへ分割する。ＰＣＬ１０２はCSDUペイロードの単位で、ＤＴＬサービスを呼び出してユーザデータの送受信を行う。ＤＴＬ１０４はCSDUペイロードにヘッダを追加して下位のＣＮＬ１０６に渡す。CSDUヘッダはProfile IDとCSDUペイロードの長さを示すLengthで構成される。
【００４９】
図８は、本システムの機器のハードウェア構成を示す模式図である。図５に示すように、イニシエータとレスポンダーのそれぞれは、物理層１０８を構成するチップ２００と、ＣＰＵ２１０とを有して構成される。物理層１０８は、ベースバンド部を含んでいる。上述したユーザアプリケーション１００、ＰＣＬ１０２、ＤＴＬ１０４、ＣＮＬ１０６は、ソフトウェア（プログラム）によりＣＰＵ２１０を機能させることによって実現される。ソフトウェアは、イニシエータ、レスポンダーを構成する通信装置が備えるメモリ、または通信装置の外部の記録媒体などに格納される。
【００５０】
図８に示すように、ＰＣＬ１０２は、通信開始要求データ（ＣＢＷ）から、エンドポイント情報、データサイズなどの所定のパラメータを抽出するパラメータ抽出部１０２ｃ、送信データに抽出したパラメータを含むヘッダを付加するヘッダ付加部１０２ｄ、送信データを４Ｋバイト毎に分割するデータ分割部１０２ｅ、受信データからパラメータを取得するパラメータ取得部１０２ｆを備えている。これらの機能ブロックは、主として後述するＰＣＬエミュレーション１０２ｂによって実現される。
【００５１】
図９は、各レイヤーが提供するサービスのアクセスポイントと、レイヤー間の関係を示す模式図である。ＰＣＬ１０２の上位は、ユーザアプリケーション１００となる。ＰＣＬ１０２は、下位ＤＴＬ１０４を利用したサービスを提供するレイヤーである。ＰＣＬ１０２は、上位のユーザアプリケーション１００に対しては、制御をＰＣＬコモン１０２ａ（共通処理部）が行い、データ転送はＰＣＬエミュレーション１０２ｂ（変換処理部）が行うというように、役割が分かれるため、ＰＣＬ１０２のサービスはそれぞれに対して規定される。
【００５２】
ＰＣＬコモン１０２ａによるサービスは、ユーザアプリケーション１００の要求に応じて、ＤＴＬ１０４の接続／切断／その他の制御のサービスを呼び出すことで下記のサービスを提供する。
・接続、切断などの制御サービス
・エラーなどのイベント通知サービス
・エミュレーション制御サービス
【００５３】
ＰＣＬエミュレーション１０２ｂによるサービスは、対応するプロトコルごとに個別に存在する。個々のＰＣＬエミュレーションはCSDUのペイロード上に汎用プロトコル(USB、TCP/IP、OBEX等)のコマンド、データを乗せて通信することを可能にするプロトコルサービスである。
【００５４】
ＰＣＬ１０２では、ＰＣＬエミュレーションサービスにより選択されたプロトコル方式に該当するサービスのみ起動することが許可される。ＰＣＬエミュレーションサービス内部では上位プロトコルの要求にしたがって、ＤＴＬ１０４によるサービスを利用するためのCSDUペイロードを生成する。ＰＣＬエミュレーション１０２ｂによるサービスを複数持つことで、１つのJET機器で複数のエミュレーションサービス(Emulation Service)を実現することが可能になる。ＰＣＬコモン１０２ａにより、１度のセッションで利用できるエミュレーションサービスは１種類のみであるように管理される。
【００５５】
図９に示すように、ＰＣＬ１０２は、ＰＣＬコモン(PCL Common)１０２ａと、ＰＣＬエミュレーション(PCL Emulation)１０２ｂにその機能が分割される。ＰＣＬコモン１０２ａは、上位のユーザアプリケーション１００の要求によって、下位レイヤのサービスの初期化や、接続、切断等の基本機能を提供する。ＰＣＬコモン１０２ａでは基本機能の処理を行うため、どのプロトコルが選択された場合においても同様の処理が行われる。一方、PCLエミュレーション１０２ｂは、ＰＣＬコモン１０２ａにより起動が完了した後、ユーザアプリケーション１００が有する任意のプロトコルを下位のＤＴＬ１０４、ＣＮＬ１０６が扱うプロトコル形式に変換する。
【００５６】
上述のように、ＰＣＬコモン１０２ａは、初期化、基本通信（接続、切断、機器認証）等の共通機能サービスをユーザアプリケーション１００に対して提供する。ＰＣＬコモン１０２ａは、全てのＪＥＴデバイスで共通に設けられるソフトウェアである。従って、ＰＣＬ１０２は、ＰＣＬエミュレーション１０２ｂのみの構成では動作することができない。
【００５７】
ＰＣＬエミュレーション１０２ｂは、ＰＣＬコモン１０２ａによって接続が行われた後、ユーザデータ転送を行うもので、ユーザプロトコル(USB、TCP/IP、OBEX等の汎用プロトコルデータ)をＤＴＬ１０４が扱うデータ形式に相互変換する役割を持つ。ＰＣＬエミュレーション１０２ｂは、ユーザアプリケーション１００から送られてくるユーザプロトコルデータを、下位のＤＴＬ１０４が解釈できる形式に変換する役割を有する。ＰＣＬ１０２内のエミュレーションブロック（ＰＣＬエミュレーション１０２ｂの変換モジュール）は、ユーザアプリケーション１００から見た場合に、既存のUSB MSC,NFC等のデバイスを制御するのと同等の方式でデータ転送機能を提供するためのサービスを提供する。但し、ＰＣＬエミュレーション１０２ｂは、機器を構成するユーザー固有のプロトコル数だけ存在する。
【００５８】
ＤＴＬ１０４は、上位の２種類のＰＣＬ（PCL Common１０２ａ, PCL Emulation１０２ｂ）に対して、下位ＣＮＬ１０６のサービスを利用した機能を、ＤＴＬサービスとして提供する。ＰＣＬエミュレーション１０２ｂは、後で詳細に説明するように、ユーザプロトコルごとに変換モジュール(Protocol A, Protocol B, Protocol C,・・・Protocol Z)を有するが、１度のセッション（接続）で利用できるのは１種類だけであり、その制御はＰＣＬコモン１０２ａによって行われる。例えば、上位プロトコルがＵＳＢの場合、マスストレージクラスであるか、あるいは他の方式かによって異なる変換モジュールが用意されている。
【００５９】
ＪＥＴデバイスにおいて、機器を構成するユーザは、上位のプロトコルに対応した変換モジュールを自由に設定してＰＣＬエミュレーション１０２ｂを構築することができる。また、変換モジュールの追加、削除もユーザが自由に行うことができる。一方、ＰＣＬコモン１０２ａはプロトコル変換の基本機能であるため、全てのＪＥＴデバイスにおいて共通であることが義務付けられる。
【００６０】
図９では、ユーザプロトコルとしてProtocol A〜Zが示されており、このうちProtocol Bがアクティブとされ、Protocol Bにより接続が行われている状態を示している。この場合、イニシエータとレスポンダーの双方でProtocol Bによる接続が行われる。どのプロトコルで接続するかは、イニシエータとレスポンダーとの間のネゴシエーションによって決定される。
【００６１】
図１０は、本実施形態のシステムにおける状態遷移を示す模式図である。ＰＣＬ１０２は、物理層１０８によるイニシエータとレスポンダーの接続状態の変化や、ユーザアプリケーションからＰＣＬ Serviceを利用することにより、図１０に示すような状態遷移を行う。
【００６２】
図１０において、先ず、レスポンダーはイニシエータからの接続待ち状態とされ、イニシエータは接続先のレスポンダーをサーチしている状態とされる。イニシエータとレスポンダーの接続が開始されると(Start Connection)、イニシエータとレスポンダー間でネゴシエーション(Negotiation)が行われる。この状態では、ＪＥＴデバイス間でソフトウェアのバージョンの確認、エミュレーション方式（互いにどのようなプロトコルを有しているか）の確認が行われる。
【００６３】
ネゴシエーションの結果、バージョン、エミュレーション方式が一致した場合は、接続が行われ、物理層１０８による接続が完了する(Connected)。その後、エミュレーションが開始され(Emulation)、ユーザアプリケーション１００間でデータ転送が可能な状態とされる。一方、ソフトウェアのバージョン情報が一致しなかった場合、または双方が保有するプロトコルが一致せず、エミュレーション方式が一致しなかった場合は、接続が行われない(Disconnect)。接続がされなかった場合(Disconnect)、エミュレーションが終了した場合(End Emulation)は、レスポンダーが接続待ち状態となる。
【００６４】
ＰＣＬコモン１０２ａは、ＰＣＬ１０２のバージョン(Version)情報に基づいて、バージョンチェック(Version Check)及びエミュレーション方式の判別を行うネゴシエーション機能を備える。ネゴシエーションの結果、バージョン及びエミュエーション方式が一致すれば、イニシエータとレスポンダーの間で同じプロトコルによる接続が行われる。ネゴシエーションに必要なバージョン管理機能(PCL Version Management)及び、エミュレーション判別機能(PCL
Select Emulation)については後で説明する。ネゴシエーションはユーザアプリケーション１００に対して提供されるサービスではなく、接続待機中の状態で、接続を検知した際に自動で実行される内部機能である。
【００６５】
図１１は、ネゴシエーションの処理を示す模式図である。図１１の処理は、図２の各層のソフトウェアによりＣＰＵ２１０を機能させることで実現できる。一例として、判別自体はレスポンダーが行い、イニシエータはその判別結果を待つ。接続先のバージョン情報の取得はＣＮＬ１０６が行い、接続時にバージョン情報が自動的に交換される（ステップＳ１）。このとき交換されるバージョン情報をＪＥＴバージョンと称することとする。
【００６６】
ＰＣＬ１０２では、下位のＣＮＬ１０６、ＤＴＬ１０４からのイベントにより、接続を検知した時点で接続先ＪＥＴデバイスのＪＥＴバージョンの情報を既に取得できている。このため、先ず、図１１に示すように、ＣＮＬ１０６のソフトウェアのバージョンチェック(CNL Ver check)とＤＴＬのソフトウェアのバージョンチェック(DTL Ver check)が行われる。ＰＣＬ１０２の内部で行われるのは、ＪＥＴバージョン内に含まれるＰＣＬバージョンのチェックによるエミュレーション方式の判別である。
【００６７】
エミュレーション方式の判別は、例えばレスポンダーが主導して行う。イニシエータとレスポンダーの双方でＰＣＬ１０２のバージョン情報が交換され、ＰＣＬコモン１０２ａのＰＣＬバージョンチェック機能により、ＰＣＬ１０２のソフトウェアのバージョン情報がチェックされる(PCL Ver check)。
【００６８】
次に、イニシエータとレスポンダーの双方でエミュレーションタイプの情報が交換され、図１１に示すように、ＰＣＬコモン１０２ａのエミュレーションタイプチェック機能により、エミュレーションのタイプがチェックされる(EMU Type check)。エミュレーションタイプは、互いのＪＥＴデバイスが通信可能なエミュレーション方式（プロトコル）を記述したパラメータである。
【００６９】
レスポンダー側では、イニシエータとレスポンダーの互いのエミュレーションタイプの比較を行い、同一のものがあれば接続可能であると判断する。PCL１０２は、エミュレーションタイプが確定した時点でユーザアプリケーション１００に通知を行い、ユーザアプリケーション１００がPCL_start_emu serviceを呼び出す（ステップＳ２）。そして、ＰＣＬコモン１０２ａからＰＣＬエミュレーション１０２ｂへStart_Emuというコマンドを送る。これによりＰＣＬコモン１０２ａによる起動が完了し、ＰＣＬエミュレーション１０２ｂによるエミュレーションが開始される（ステップＳ３）。そして、ＰＣＬエミュレーション１０２ｂによりユーザアプリケーション１００のプロトコルを変換して、下位のＤＴＬ１０４、ＣＴＬ１０６と通信を行うことが可能となる。
【００７０】
また、イニシエータとレスポンダーで同一のエミュレーションタイプを複数有している場合は、ユーザアプリケーション１００にその旨を通知する。ユーザアプリケーション１００側でこれらの複数のエミュレーションタイプの１つを指定する場合は、その旨の情報がＰＣＬ１０２に送られる。この際、ユーザアプリケーション１００側では、予め指定された１つのエミュレーションタイプを指定することができる。また、イニシエータとレスポンダーの一方が携帯機器の場合など、高速通信可能なプロトコルを使う必要が比較的低い場合は、通信速度に応じた適切なプロトコルのエミュレーションタイプを選択することができる。これらの仕様は、ＪＥＴデバイス、またはユーザアプリケーション１００を構成するユーザが自由に設定することができる。
【００７１】
次に、ＰＣＬ１０２によるエミュレーション選択について説明する。エミュレーション選択は、イニシエータからの接続検知を検知したレスポンダー側でネゴシエーションを行う際にＰＣＬコモン１０２ａの内部で実行される機能である。接続時にＪＥＴデバイス間で交換されるＪＥＴバージョン内のＰＣＬバージョン情報から、互いに適合するエミュレーションを持っているかを確認する。
【００７２】
図１２は、ＪＥＴバージョン情報を説明するための模式図である。ＰＣＬ１０２は、自機のバージョン情報と、接続先JETデバイスのバージョン情報の２つを管理する。自機のバージョン情報は必ず起動時にロードされ、接続検知時、接続中は、接続先デバイスのバージョン情報を保持する。
【００７３】
図１２に示すように、ＪＥＴのバージョン情報は合計１０バイトであり、上層から順にプラットフォーム(Platform)情報(1byte)、ＪＥＴドライババージョン情報(2byte)、ＣＮＬバージョン情報(1byte)、ＤＴＬバージョン情報(2byte)、ＰＣＬバージョン情報(2byte)、リザーブド(2byte)の情報がある。
【００７４】
ＰＣＬバージョン情報(2byte)のうち、前半の1バイトは、システムの互換性維持のためのソフトウェアのVersion No (T.B.D)である。後半の１バイトは、装置（JETデバイス）が対応するエミュレーション方式を示している。図１２では、エミュレーション方式としてＵＳＢ，ＴＣＰ／ＩＰ，ＯＢＥＸ・・・が例示され、各方式に１ビットのデータが与えられている。そして、ビットが１の場合はそのエミュレーション方式に対応することを表しており、ビットが０の場合はそのエミュレーション方式に対応していないことを表している。１つのJETデバイスで対応するエミュレーション方式の最大値には規定はないが、最低でも1つのエミュレーション方式には対応しなければならない。
【００７５】
なお、バージョン情報のチェックは、図１１に示すように、図１２の上層側（プラットフォーム側）の情報から順次に行われる。ＰＣＬ１０２のバージョン情報のチェック後、エミュレーションタイプのチェックが行われる。
【００７６】
接続の実行結果として、互いに通信可能なエミュレーション方式を記述したエミュレーションタイプが選択され、選択されたエミュレーションタイプは、レスポンダー側からユーザアプリケーション１００に通知され、また許可待ちをしているイニシエータに通知される。図１３は、エミュレーション選択のシーケンスを示す模式図である。図１３において、選択されたエミュレーションタイプ(EMUTYPE)は、レスポンダーのユーザアプリケーション１００(UsrAppl)に対してはPCL_conf_r.indとして、イニシエータ側に対してはPCL_conf_i.indとして通知される（図１３参照）。
【００７７】
図１４及び図１５は、ＰＣＬエミュレーション１０２ｂに関係するサービスを示す模式図である。以下、各サービスについて説明する。起動、終了はＰＣＬコモン１０２ａによって行われるが、データの送信、受信は、ユーザアプリケーション１００からＰＣＬエミュレーション１０２ｂに通信を行うことで実行できる。従って、ＰＣＬコモン１０２ａとの間で提供されるサービス（図１４）と、ユーザアプリケーション１００との間で提供されるサービス（図１５）に分けられる。
【００７８】
Start service（Mandatory；図１４）
Start serviceは、標準で提供されるサービスであり、エミュレーションを開始する際、ＰＣＬコモン１０２ａにより実行されるＰＣＬエミュレーション１０２ｂの初期化処理を提供するサービスである。Startが完了した時点で、ユーザアプリケーション１００から、ユーザプロトコルを用いたデータ送受信が可能となる。
【００７９】
End service（Mandatory；図１４）
End serviceは、標準で提供されるサービスであり、エミュレーションを終了する際、ＰＣＬコモン１０２ａにより実行されるエミュレーションの終了処理を提供するサービスである。Endが完了した時点で、ユーザアプリケーション１００から、ユーザプロトコルを用いたデータ送受信は不可能となる。ＰＣＬコモン１０２ａはエミュレーションがStartされていた場合、切断(PCL_Disconect)を実行する前に、このサービスを実行する。
【００８０】
Open service（Mandatory；図１５）
Open serviceは、ユーザプロトコル上での通信路のオープン時に必要な処理を提供するサービスである。
【００８１】
Close service（Mandatory；図１５）
Close serviceは、ユーザプロトコル上での通信路のクローズ時に必要な処理を提供するサービスである。
【００８２】
Read service（Mandatory；図１５）
Read serviceは、ユーザプロトコル上で、接続先のデータを取得する際に必要な処理を提供するサービスである。
【００８３】
Write service（Mandatory；図１５）
Write serviceは、ユーザプロトコル上で、接続先にデータを送信する際に必要な処理を提供するサービスである。
【００８４】
以上のように、Open service、Close serviceは、ＰＣＬ１０２による上位プロトコルの初期化処理に対応する処理である。また、Read service、Write serviceは、ユーザアプリケーション１００によるデータの送信、受信に関する処理である。
【００８５】
User customize service（Option；図１５）
上述のサービスに該当しないサービスであり、装置を構成するユーザが独自のサービスとして定義できるものである。通信路を“開く(Open)”、“閉じる(Close)”、データを“送る(Write)”、“受ける(Read)”以外の部分は、ＪＥＴデバイスを構成するユーザが自由に設定できるカスタマイズ領域とされ、例えばユーザアプリケーション１００の種類（Windows, Linux等）に応じて、ユーザが自由に設定することができる。但し、どのアプリケーションを使用した場合でも、上述のようにＰＣＬコモン１０２ａによる“Start”、“End”は必要であり、全てのＪＥＴデバイスで共通である。
【００８６】
以上のように、本実施形態では、ユーザアプリケーション１００のプロトコルを変換するＰＣＬ１０２を設け、各通信装置に共通に設けられたＰＣＬコモン１０２ａにより、ユーザアプリケーション１００の１又は複数のプロトコルの中から通信相手のプロトコルと一致するプロトコルが選択される。そして、選択されたプロトコルが物理層１０８で通信を行うためのプロトコルに変換されるため、通信相手のユーザアプリケーション１００のプロトコルに応じて通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。
【００８７】
次に、図１６に基づいて、上位アプリケーションがＵＳＢの場合に、ＵＳＢマスストレージクラスのプロトコル上で、イニシエータ側のＰＣＬ１０２（主にＰＣＬエミュレーション１０２ｂ）で必要なデータをあらかじめ抽出し、効率的なデータの転送を実現する処理について説明する。図１６は、ネゴシエーションが行われた後の処理を示しており、図中に示す“変換”の処理は、主としてＰＣＬエミュレーション１０２ｂで行われる。そして、図１６は、ＵＳＢ以外の物理層、すなわち本実施形態の通信装置の物理層１００で扱うデータ形式に対して、ＵＳＢマスストレージのデータ形式を本実施形態に係るＪＥＴデバイスの通信方式に変換してマッピングする手法を示している。
【００８８】
なお、図１６において、ヘッダ、データは個別のパケットとして送信されるものであり、ヘッダとデータが同じパケットで送信されることはない。また、ＵＳＢで転送されるデータはＵＲＢという単位で扱われる。これは、送信側、受信側それぞれの中でのデータを扱う単位なので、ＵＲＢ自体の設定値などの互換性は無い。ＵＲＢはホスト側で扱うデータサイズによって変わるが、同等のサイズ情報がＣＢＷに記載される。更に、コマンド、データの向きに関するエンドポイント番号（ＥＰ）もＣＢＷに記述される。
【００８９】
図１６において、ＵＳＢホスト(USBHOST)は、イニシエータの上位アプリケーションを示している。また、ＵＳＢターゲット(USBTGT)は、レスポンダーの上位アプリケーションを示している。
【００９０】
図１６では、イニシエータがレスポンダーへデータを送り、レスポンダーのメモリ、ハードディスク等にデータを書き込む場合（Ｗｒｉｔｅ動作）を示している。図１６に示すように、書き込み用のデータを送る前に、ＵＳＢホスト側からＵＳＢターゲット側へ通信要求を示すＣＢＷが送られる（ステップＳ３１）。ＣＢＷは、ＣＢＷ自体のエンドポイントとサイズを示すパラメータ（ＰＡＲＡＭ）、及びＣＢＷのデータ自体から構成される。なお、図中に示す各パラメータは、ＵＳＢデータを送る前に予めどのようなデータであるかを示すエンドポイント（ＥＰ）番号と、次に送るデータの総量から構成される。エンドポイント番号が２の場合は、ＵＳＢホストからＵＳＢターゲットへ送られるデータであることを示し、エンドポイント番号が１の場合はＵＳＢターゲットからＵＳＢホストへ返信されるデータを示している。
【００９１】
ＵＳＢターゲットは、ＣＢＷを受信すると、ＣＢＷに付加されたパラメータに基づいてサイズとエンドポイントを認識し、ＣＢＷのデータ自体にはＭＳＣ(Mass Strage Class)処理が行われる（ステップＳ３２）。これにより、ＵＳＢターゲット側では、ＣＢＷにより次に書き込み用のデータが送られてくることを認識でき、データの待ち受けを開始する。
【００９２】
また、ＵＳＢホスト側では、ＣＢＷのデータから書き込み用データのエンドポイントと書き込み用データの総サイズを抽出する（ステップＳ３３）。また、書き込み用のデータを複数に分割する（ステップＳ３４）。そして、ＣＢＷから抽出したエンドポイントと総サイズを複数の書き込み用のデータに付加してＵＳＢターゲットに送る（ステップＳ３５）。ＣＢＷには、その後に送られる書き込み用データに関する情報（エンドポイント、サイズ等）が含まれる。従って、ＣＢＷから必要な情報のみを抽出して書き込み用のデータに付加することで、ＵＳＢのデータの全てをＪＥＴデバイスの物理層１０８に合わせて変換する必要がなく、送信側の装置の処理量を最小限に抑えることができる。また、受信側の装置においても、書き込み用データに付加されたパラメータを参照することで、必要な情報を得ることができるため、送られたデータの全てを解析する必要がなく、処理の負荷を最小限に抑えることが可能である。
【００９３】
ＵＳＢホスト側は、データの送信後、ＵＳＢターゲット側からの完了通知待ちうけ状態に遷移する。ＵＳＢターゲット側では、書き込み用のデータを受信すると、付加されているエンドポイントと総サイズを認識し、書き込み用のデータにはＭＳＣ一括処理が施される（ステップＳ３６）。ＭＳＣ一括処理が施されたデータは、エンドポイント、サイズと結合されて上位アプリケーションの記憶領域、またはメモリ等へのデータの書き込みが行われる。
【００９４】
ＵＳＢターゲット側での書き込みが完了すると、ＵＳＢターゲット側からＵＳＢホスト側へ完了通知であるＣＳＷが送られる。ＣＳＷは、ＣＳＷ自体のエンドポイントとサイズを示すパラメータ、及びＣＳＷのデータ自体から構成される。完了通知待ち受け状態のＵＳＢホストがＣＳＷを受信すると、ＵＳＢホストからＵＳＢターゲットへのデータの書き込みが完了する。
【００９５】
以上の処理において、ＣＢＷ、ＣＳＷはデータ量としては小さいものであるので、書き込み用データの送信前に、必要最小限のデータとしてのＣＢＷを先に送ることで、待ち受け側のＵＳＢターゲット側でＳＷの準備が先行して行うことが可能となり、処理全体のパフォーマンスを上げることができる。
【００９６】
更に、ＵＳＢホスト側から書き込み用のデータを送る際には、ＣＢＷから書き込み用データのエンドポイント番号、データサイズを抽出し、書き込み用データのパラメータとしてヘッダに付加する。この際、データ送信時に分割されたＵＲＢの最初のデータにだけヘッダを付加し、以降の分割ＵＲＢにはヘッダを付加しない。
【００９７】
これにより、転送の大部分を占めるデータ送受信時のパラメータ送信を複数回に一回のトランザクションとすることができ、変換によるパフォーマンス低下を抑止するとともに、トランザクションの増加を大幅に省くことができ、システムの負荷を軽減することができる。
【００９８】
また、データが書き込まれるＵＳＢターゲット側では、書き込み用のデータに付加されたエンドポイントを参照することにより、バッファ内のどの位置にデータを書き込むかを認識することができる。ＵＳＢターゲット側では、接続時にＵＳＢホスト側と互いに必要なエンドポイントの情報をやり取りする（ＵＳＢのエナミュレーションに相当）。そして、この情報のやり取りに基づいて、必要なエンドポイントのバッファ領域を確保し、データのエンドポイント番号を見てどのバッファに書き込むかを判断する。従って、書き込み用データの全てを解析する必要がなく、書き込み用データのヘッダに付加されたパラメータを参照するのみで、書き込み用データを上位のユーザアプリケーション１００の所定の位置に送り、記録することが可能である。
【００９９】
図１６では、イニシエータからレスポンダーへの書き込み動作を示したが、ＵＳＢホストからＵＳＢターゲットへの読出し動作（図１８参照）についても同様に処理することができる。読出し動作の場合は、イニシエータからレスポンダーへデータの読出しを要求するＣＢＷが送られた後、レスポンダー側でＣＢＷからエンドポイント番号、サイズ等のパラメータを抽出する。そして、レスポンダー側でイニシエータに送るデータを分割して、複数の分割されたデータに対して、抽出したパラメータを含む１つのヘッダを付加して、イニシエータへ送信する。データを受信したイニシエータでは、パラメータに基づいて上位アプリケーションの所定の位置に受信データを送ることができる。
【０１００】
図１７は、図１６の処理をより具体的に示した模式図であって、イニシエータ側の処理を示している。イニシエータ側のユーザアプリケーション１００であるＵＳＢホストからＣＢＷによる書き込み開始が指示されると（ステップＳ４１）、ＣＢＷは一旦ＵＳＢバッファ(USB BUF)に書き込まれ、下位レイヤ（ＰＣＬ１０４）のドングルＳＷ(DONGLE  SW)において図１６のパラメータを含むヘッダ生成とＣＢＷ書き込みが行われ、ＣＢＷは、JET  Header  64bitとData  31  Byte(CBW)に変換されて、ＭＡＣバッファ(MAC BUF)に書き込まれる。ＭＡＣバッファに書き込まれたヘッダ、データは、物理層１０８を介してＵＳＢターゲット側へ送信(TX)される。
【０１０１】
次に、ＵＳＢホスト側のユーザアプリケーションにより書き込みデータ送信が指示されると（ステップＳ４２）、データは一旦ＵＳＢバッファ(USB BUF)に書き込まれ、下位レイヤ（ＰＣＬ１０４）において、ＣＢＷからヘッダが生成される。また、書き込み用データが４Ｋｂｙｔｅのデータに分割されて、ヘッダ(JET  Header  64bit)とともに複数の４Ｋｂｙｔｅのデータ(Data 4096Byte)がＭＡＣバッファ(MAC BUF)に書き込まれる。このように、書き込み用データは、ＪＥＴデバイスの物理層１０８に合わせて４Ｋｂｙｔｅ毎のデータに分割される。これにより、１つのデータのサイズを最大限に大きくすることができ、装置の負荷を軽減することができる。ＭＡＣバッファに書き込まれたヘッダ、データは、物理層１０８を介してＵＳＢターゲット側へ送信(TX)される。なお、図１７では、ＵＳＢ物理層とＪＥＴデバイスの物理層１０８との変換を行う機器の例として外部機器（ドングルＳＷ）を用い、ＰＣＬ１０４が外部機器に構成され、ＰＣＬ１０４よりも上位のユーザアプリケーションがパーソナルコンピュータ等の機器に構成される例を示している。外部機器を用いることなく、パーソナルコンピュータ等の単体機器でイニシエータを構成することも勿論可能である。ここで、ドングルＳＷは、ＵＳＢにおけるＨＵＢ、カードリーダなどの機器に相当する。
【０１０２】
ＵＳＢターゲット側から受信(RX)したＣＳＷは、レスポンダー側での同様の処理によりJET  Header  64bitとData  13  Byte(CSW)から構成され、ＭＡＣバッファに溜められる。このデータはドングルＳＷにおいてヘッダが解析され、ＵＳＢバッファにデータが書き込まれる。なお、ＣＢＷのデータサイズは３１Ｂｙｔｅであるが、ＣＳＷのデータサイズは１３Ｂｙｔｅである。ユーザアプリケーション１００では、ＵＳＢバッファのデータを受けて、書き込み要求の完了通知を出す（ステップＳ４３）。以降のステップＳ４４〜Ｓ４６の処理も、ステップＳ４１〜Ｓ４３と同様に行われる。
【０１０３】
以上説明したように本実施形態によれば、ＵＳＢマスストレージプロトコルで、通信の大部分を占めるデータ送信時に、細かいヘッダ情報を１度にまとめることで、転送効率を高めることが可能となる。また、ＣＢＷより必要最小限のパラメータを抽出することで、ユーザアプリケーション１００から異なる物理層１０８に変換されたデータを受信した機器側において、パラメータ解析に要する負荷を大幅に軽減することが可能となる。なお、上述した例では、ＵＳＢのマスストレージクラスのプロトコル変換を示したが、本発明はこれに限定されるものではなく、他のプロトコル変換においても同様の手法を用いることで高速化を達成することが可能である。また、上述した例では、無線通信システムを例に挙げて説明したが、通信システムは有線のものであってもよい。
【０１０４】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【０１０５】
【図１】本実施形態の無線通信システムを構成する２つの機器を示す模式図である。
【図２】イニシエータ、レスポンダーの各機器の構成を階層構造として示した模式図である。
【図３】イニシエータ、レスポンダーにおけるデータの流れを示す模式図である。
【図４】図２の構成をＯＳＩ参照モデルで示した模式図である。
【図５】機器内の各レイヤーにおけるファイル、データの送受信のデータフローを示す模式図である。
【図６】CSDUによる論理的なチャネルを示す模式図である。
【図７】CSDUがマッピングされる様子を示す模式図である。
【図８】機器のハードウェア構成を示す模式図である。
【図９】各レイヤーが提供するサービスのアクセスポイントと、レイヤー間の関係を示す模式図である。
【図１０】本実施形態のシステムにおける状態遷移を示す模式図である。
【図１１】ネゴシエーションの処理を示す模式図である。
【図１２】ＰＣＬバージョン情報を説明するための模式図である。
【図１３】エミュレーション選択のシーケンスを示す模式図である。
【図１４】ＰＣＬエミュレーションのサービスを示す模式図である。
【図１５】ＰＣＬエミュレーションのサービスを示す模式図である。
【図１６】ＵＳＢマスストレージクラスのプロトコル上で、イニシエータ側のＰＣＬで必要なデータをあらかじめ抽出し、効率的なデータの転送を実現する処理を示す模式図である。
【図１７】図１６の処理をより具体的に示す模式図である。
【図１８】ＵＳＢ物理層を介してＵＳＢホストとＵＳＢターゲットとの間で通信が行われる様子を示す模式図である。
【符号の説明】
【０１０６】
１００    ユーザアプリケーション
１０２    ＰＣＬ
１０２ｃ    パラメータ抽出部
１０２ｄ    ヘッダ付加部
１０２ｅ    データ分割部
１０２ｆ    パラメータ取得部
１０８    物理層
２１０    ＣＰＵ
【図１】
2009182459.tif 000003
【図２】
2009182459.tif 000004
【図３】
2009182459.tif 000005
【図４】
2009182459.tif 000006
【図５】
2009182459.tif 000007
【図６】
2009182459.tif 000008
【図７】
2009182459.tif 000009
【図８】
2009182459.tif 000010
【図９】
2009182459.tif 000011
【図１０】
2009182459.tif 000012
【図１１】
2009182459.tif 000013
【図１２】
2009182459.tif 000014
【図１３】
2009182459.tif 000015
【図１４】
2009182459.tif 000016
【図１５】
2009182459.tif 000017
【図１６】
2009182459.tif 000018
【図１７】
2009182459.tif 000019
【図１８】
2009182459.tif 000020