JP2009163361A - 通信装置、通信システム、通信方法及びプログラム - Google Patents

Abstract

【課題】上位アプリケーションが１又は複数のプロトコルを備える場合に、通信の互換性を確実に確保することが可能な通信装置を提供すること。
【解決手段】無線通信により他の通信相手との間で信号の送受信を行う物理層１０８と、上位のユーザアプリケーション１００と物理層１０８との間を接続するプロトコル変換部（ＰＣＬ）１０２とを備え、プロトコル変換部１０２は、互いに通信可能な各装置に共通に設けられ、プロトコル変換のための基本処理を行うＰＣＬコモン１０２ａと、ユーザアプリケーション１０２の１又は複数のプロトコルに対応して設けられ、ＰＣＬコモン１０２ａにより１又は複数のプロトコルの中から選択されたプロトコルを物理層１０８で通信するためのプロトコルに変換する変換処理部と、を含む。
【選択図】図９

Description

本発明は、通信装置、通信システム、通信方法及びプログラムに関する。

従来、例えば下記の特許文献１に記載されているように、移動体の利用者が所有する汎用の携帯端末に移動体の情報を発信できることを意図した移動体通信システムが知られている。

特開２００５−１９１８１９号公報

近時においては、通信装置に複数の上位アプリケーションが搭載されることが想定されている。このような装置においては、上位アプリケーションのプロトコルが複数になることが想定される。

しかしながら、上位アプリケーションのプロトコルが複数になると、どのプロトコルを使用して通信を実現するかが問題となり、使用するプロトコルによっては、通信相手との接続の際に互換性が無くなる事態が想定される。この場合、通信装置側で複数アプリケーションによる多機能を実現したとしても、他の装置との間で通信の互換性が得られなくなり、結果としてシステム上の制約が生じてしまう。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、上位アプリケーションが１又は複数のプロトコルを備える場合に、通信の互換性を確実に確保することが可能な、新規かつ改良された通信装置、通信システム、通信方法及びプログラムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、他の通信相手との間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、前記プロトコル変換部は、互いに通信可能な各装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、前記上位アプリケーションの１又は複数のプロトコルに対応して設けられ、前記共通処理部により前記１又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含む通信装置が提供される。

上記構成によれば、物理層により他の通信相手との間で信号の送受信が行われ、プロトコル変換部により上位アプリケーションと物理層との間が接続される。プロトコル変換部の共通処理部は、互いに通信可能な各装置に共通に設けられ、共通処理部によりプロトコル変換のための基本処理が行われる。プロトコル変換部の変換処理部は、上位アプリケーションの１又は複数のプロトコルに対応して設けられる。そして、共通処理部により１又は複数のプロトコルの中から選択されたプロトコルは、変換処理部により物理層で通信するためのプロトコルに変換される。従って、互いに通信可能な各装置に共通に設けられた共通処理部により、１又は複数のプロトコルの中からプロトコルが選択されるため、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。

また、前記共通処理部は、少なくとも前記プロトコル変換の起動、停止を含む基本動作を行うものであってもよい。かかる構成によれば、互いに通信可能な各装置に共通に設けられた共通処理部により、プロトコル変換の起動、停止を含む基本動作を実現することができる。

また、前記共通処理部は、前記通信相手とのネゴシエーションの結果に応じて、前記１又は複数のプロトコルの中から前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択するものであってもよい。かかる構成によれば、通信相手とのネゴシエーションの結果に応じて、１又は複数のプロトコルの中から通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが選択されるため、通信相手との互換性を確保し、通信相手との通信を確実に行うことができる。

また、前記共通処理部は、前記１又は複数のプロトコルの中に、前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが存在しなかった場合は、当該通信相手との接続を行わないものであってもよい。かかる構成によれば、１又は複数のプロトコルの中に、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが存在しなかった場合は、当該通信相手との接続を行わないため、不要な処理が行われることを抑止することができる。

また、前記共通処理部は、通信相手とのネゴシエーションの結果に応じて、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致するか否かを判定するバージョンチェック機能を備えるものであってもよい。かかる構成によれば、通信相手とのネゴシエーションの結果に応じて、プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致するか否かが判定されるため、通信相手との互換性を確保し、通信相手との通信を確実に行うことができる。

また、前記共通処理部は、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致しなかった場合は、当該通信相手との接続を行わないものであってもよい。かかる構成によれば、プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致しなかった場合は、当該通信相手との接続を行わないため、不要な処理が行われることを抑止することができる。

また、前記物理層は、前記変換処理部でプロトコルが変換されたデータに対してデータの種別を表すプロファイルＩＤが付されたデータを通信相手との間で通信するものであってもよい。かかる構成によれば、複数の論理チャネルを１つの物理層上で実現することが可能となる。

また、上記課題を解決するために、本発明の別の観点によれば、通信装置同士が通信を行う通信システムであって、前記通信装置は、通信相手となる通信装置の間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、前記プロトコル変換部は、互いに通信可能な各通信装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、前記上位アプリケーションの１又は複数のプロトコルに対応して設けられ、前記共通処理部により前記１又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含む通信システムが提供される。

上記構成によれば、通信装置同士が通信を行う通信システムにおいて、物理層により通信相手となる通信装置の間で信号の送受信が行われ、プロトコル変換部により上位アプリケーションと物理層との間が接続される。プロトコル変換部の共通処理部は、互いに通信可能な各装置に共通に設けられ、共通処理部によりプロトコル変換のための基本処理が行われる。プロトコル変換部の変換処理部は、上位アプリケーションの１又は複数のプロトコルに対応して設けられる。そして、共通処理部により１又は複数のプロトコルの中から選択されたプロトコルは、変換処理部により物理層で通信するためのプロトコルに変換される。従って、互いに通信可能な各装置に共通に設けられた共通処理部により、１又は複数のプロトコルの中からプロトコルが選択されるため、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。

また、上記課題を解決するために、本発明の別の観点によれば、通信装置同士が通信を行う通信方法であって、前記通信装置が通信相手となる他の通信装置との間でプロトコル情報を交換するステップと、前記プロトコル情報に基づいて、上位アプリケーションの１又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択するステップと、選択されたプロトコルを通信相手と通信するためのプロトコルに変換するステップと、を備える通信方法が提供される。

上記構成によれば、通信装置同士が通信を行う通信方法において、通信相手となる他の通信装置との間でプロトコル情報が交換され、プロトコル情報に基づいて、上位アプリケーションの１又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが選択され、選択されたプロトコルが通信相手と通信するためのプロトコルに変換される。従って、通信相手との間で交換されたプロトコル情報に基づいて、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。

また、上記課題を解決するために、本発明の別の観点によれば、通信相手となる他の通信装置との間でプロトコル情報を交換する手段、前記プロトコル情報に基づいて、上位アプリケーションの１又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択する手段、選択されたプロトコルを通信相手と通信するためのプロトコルに変換する手段、としてコンピュータを機能させるためのプログラムが提供される。

上記構成によれば、通信相手となる他の通信装置との間でプロトコル情報が交換され、プロトコル情報に基づいて、上位アプリケーションの１又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが選択され、選択されたプロトコルが通信相手と通信するためのプロトコルに変換される。従って、通信相手との間で交換されたプロトコル情報に基づいて、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。

本発明によれば、上位アプリケーションが１又は複数のプロトコルを備える場合に、通信の互換性を確実に確保することが可能となる。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

本実施形態の無線通信システムは、一対の機器の間でデータを送受信することを目的とした通信方式であり、近距離の機器間で無線によりデータの送受信を行う。図１は、本実施形態の無線通信システムを構成する２つの機器（通信装置）を示す模式図である。２つの機器は、それぞれレスポンダー(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,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を付与する。制御データの例としては、パラメータ情報(詳細はTBD)などがある。CSDUペイロードにはヘッダ情報(詳細はTBD)が埋め込まれる。ＤＴＬ１０４はこのヘッダ情報を解釈し、適切な処理を行う。

ＣＮＬ１０６は、上位のＤＴＬ１０４の要求に応じて、物理層１０８のサービスを利用した通信を行う他、物理層１０８の接続の確立、切断、データの連続性の保障などを行う。

物理層１０８は、本実施形態による近距離大容量通信が可能な無線通信システムのＪＥＴ物理層であり、誤り訂正機能、プリアンブルセンス(preamble sense)機能を含む。

図４は、JET
deviceを搭載する機器のソフトウェアの役割に基づいて、図２の構成をＯＳＩ参照モデルで示したものである。図４に示すように、物理層（第１層）１０８は、データを通信回線に送出するための電気的な変換や機械的な作業を受け持つ。ピンの形状やケーブルの特性なども第１層で定められる。

ＤＴＬ１０４、ＣＮＬ１０６は、データリンク層（第２層）、トランスポート層（第４層）に対応する。データリンク層は、通信相手との物理的な通信路を確保し、通信路を流れるデータのエラー検出などを行う。また、トランスポート層は、通信相手まで確実に効率良くデータを届けるためのデータ圧縮や誤り訂正、再送制御などを行う。なお、本実施形態のシステムはP2P通信であるため、ＯＳＩ参照モデルにおけるネットワーク層（第３層）は設けられておらず、システムを簡略化することができる。

ＰＣＬ１０２は、セッション層（第５層）とプレゼンテーション層（第６層）が対応する。セッション層は、通信プログラム同士がデータの送受信を行うための仮想的な経路（コネクション）の確立や解放を行う。プレゼンテーション層は、セッション層から受け取ったデータをユーザが分かり易い形式に変換したり、アプリケーション層から送られてくるデータを通信に適した形式に変換するなどの処理を行う。

ユーザアプリケーション１００は、アプリケーション層（第７層）に対応する。アプリケーション層は、データ通信を利用した様々なサービスを人間や他のプログラムに提供する。

次に、本実施形態の通信装置におけるデータの流れを説明する。図５は、データフローを示す模式図であって、JET機器内の各レイヤーにおけるファイル、データの送受信のデータフローを示している。なお、ＰＣＬ１０２は、ＰＣＬコモンとＰＣＬエミュレーションに機能が分かれる。データ転送で利用するのはＰＣＬエミュレーションであるため、図５に示すＰＣＬ１０２による処理はＰＣＬエミュレーションによって実現される機能である。物理層１０８に入力されるCSDUは、データフォーマットとして規定されており、そのヘッダ情報等の生成、解析を行うＤＴＬ１０４が扱うデータフォーマットも同様である。

また、後述するように、共通機能を提供するためのＰＣＬコモンについては規定されているが、ＰＣＬエミュレーションは、ユーザプロトコルに準じたデータ変換処理を行うため、それぞれのプロトコルに応じたシステム仕様に依存する。

JET通信では、ファイル等のデータだけではなく、ＰＣＬ１０２、ＤＴＬ１０４内での管理パラメータや、通信先の同一レイヤー間でのデータの送受信が存在する。これらのファイル、パラメータ類は、ＣＮＬ１０６によって最終的にCSDUフォーマットに準拠した形式で伝送される。図６は、CSDUによる論理的なチャネルを示す模式図である。図６に示すように、データの種別を特定するにはProfile IDを用いる。これにより、物理層１０８のレベルで、複数の伝送Channelを論理的に用いることが可能となる。従って、通信レートを大幅に向上させることができ、特に動画などの大容量のデータ通信に適している。

図７は、CSDUがマッピングされる様子を示す模式図である。CSDUは、ＣＮＬ１０６とＤＴＬ１０４の間でやり取りされるデータユニットであり、図７に示すように、CNLフレームにマッピングされる。ユーザアプリケーション１００が送受信するユーザデータサイズは特に規定されない。ＰＣＬ１０２は、データの長さがデータ分割長（最大4096バイト）を超えた場合、複数のCSDUペイロードへ分割する。ＰＣＬ１０２はCSDUペイロードの単位で、ＤＴＬサービスを呼び出してユーザデータの送受信を行う。ＤＴＬ１０４はCSDUペイロードにヘッダを追加して下位のＣＮＬ１０６に渡す。CSDUヘッダはProfile IDとCSDUペイロードの長さを示すLengthで構成される。

図８は、本システムの機器のハードウェア構成を示す模式図である。図５に示すように、イニシエータとレスポンダーのそれぞれは、物理層１０８を構成するチップ２００と、ＣＰＵ２１０とを有して構成される。物理層１０８は、ベースバンド部を含んでいる。上述したユーザアプリケーション１００、ＰＣＬ１０２、ＤＴＬ１０４、ＣＮＬ１０６は、ソフトウェア（プログラム）によりＣＰＵ２１０を機能させることによって実現される。ソフトウェアは、イニシエータ、レスポンダーを構成する通信装置が備えるメモリ、または通信装置の外部の記録媒体などに格納される。

図９は、各レイヤーが提供するサービスのアクセスポイントと、レイヤー間の関係を示す模式図である。ＰＣＬ１０２の上位は、ユーザアプリケーション１００となる。ＰＣＬ１０２は、下位ＤＴＬ１０４を利用したサービスを提供するレイヤーである。ＰＣＬ１０２は、上位のユーザアプリケーション１００に対しては、制御をＰＣＬコモン１０２ａ（共通処理部）が行い、データ転送はＰＣＬエミュレーション１０２ｂ（変換処理部）が行うというように、役割が分かれるため、ＰＣＬ１０２のサービスはそれぞれに対して規定される。

ＰＣＬコモン１０２ａによるサービスは、ユーザアプリケーション１００の要求に応じて、ＤＴＬ１０４の接続／切断／その他の制御のサービスを呼び出すことで下記のサービスを提供する。
・接続、切断などの制御サービス
・エラーなどのイベント通知サービス
・エミュレーション制御サービス

ＰＣＬエミュレーション１０２ｂによるサービスは、対応するプロトコルごとに個別に存在する。個々のＰＣＬエミュレーションはCSDUのペイロード上に汎用プロトコル(USB,OBEX等)のコマンド、データを乗せて通信することを可能にするプロトコルサービスである。

ＰＣＬ１０２では、ＰＣＬエミュレーションサービスにより選択されたプロトコル方式に該当するサービスのみ起動することが許可される。ＰＣＬエミュレーションサービス内部では上位プロトコルの要求にしたがって、ＤＴＬ１０４によるサービスを利用するためのCSDUペイロードを生成する。ＰＣＬエミュレーション１０２ｂによるサービスを複数持つことで、１つのJET機器で複数のエミュレーションサービス(Emulation Service)を実現することが可能になる。ＰＣＬコモン１０２ａにより、１度のセッションで利用できるエミュレーションサービスは１種類のみであるように管理される。

図９に示すように、ＰＣＬ１０２は、ＰＣＬコモン(PCL Common)１０２ａと、ＰＣＬエミュレーション(PCL Emulation)１０２ｂにその機能が分割される。ＰＣＬコモン１０２ａは、上位のユーザアプリケーション１００の要求によって、下位レイヤのサービスの初期化や、接続、切断等の基本機能を提供する。ＰＣＬコモン１０２ａでは基本機能の処理を行うため、どのプロトコルが選択された場合においても同様の処理が行われる。一方、PCLエミュレーション１０２ｂは、ＰＣＬコモン１０２ａにより起動が完了した後、ユーザアプリケーション１００が有する任意のプロトコルを下位のＤＴＬ１０４、ＣＮＬ１０６が扱うプロトコル形式に変換する。

上述のように、ＰＣＬコモン１０２ａは、初期化、基本通信（接続、切断、機器認証）等の共通機能サービスをユーザアプリケーション１００に対して提供する。ＰＣＬコモン１０２ａは、全てのＪＥＴデバイスで共通に設けられるソフトウェアである。従って、ＰＣＬ１０２は、ＰＣＬエミュレーション１０２ｂのみの構成では動作することができない。

ＰＣＬエミュレーション１０２ｂは、ＰＣＬコモン１０２ａによって接続が行われた後、ユーザデータ転送を行うもので、ユーザプロトコル(USB,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)。その後、エミュレーションが開始され(Emulatiion)、ユーザアプリケーション１００間でデータ転送が可能な状態とされる。一方、ソフトウェアのバージョン情報が一致しなかった場合、または双方が保有するプロトコルが一致せず、エミュレーション方式が一致しなかった場合は、接続が行われない(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デバイス間で交換されるＪＥＴバージョン内のＰＣＬバージョン情報から、互いに適合するエミュレーションを持っているかを確認する。

図１２は、ＪＥＴバージョン情報を説明するための模式図である。ＰＣＬ１０２は、自機のバージョン情報と、接続先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”は必要であり、全てのＪＥＴデバイスで共通である。

以上説明したように本実施形態によれば、ユーザアプリケーション１００のプロトコルを変換するＰＣＬ１０２を設け、各通信装置に共通に設けられたＰＣＬコモン１０２ａにより、ユーザアプリケーション１００の１又は複数のプロトコルの中から通信相手のプロトコルと一致するプロトコルが選択される。そして、選択されたプロトコルが物理層１０８で通信を行うためのプロトコルに変換されるため、通信相手のユーザアプリケーション１００のプロトコルに応じて通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。なお、上述した例では、無線通信システムを例に挙げて説明したが、通信システムは有線のものであってもよい。

以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

本実施形態の無線通信システムを構成する２つの機器を示す模式図である。 イニシエータ、レスポンダーの各機器の構成を階層構造として示した模式図である。 イニシエータ、レスポンダーにおけるデータの流れを示す模式図である。 図２の構成をＯＳＩ参照モデルで示した模式図である。 機器内の各レイヤーにおけるファイル、データの送受信のデータフローを示す模式図である。 CSDUによる論理的なチャネルを示す模式図である。 CSDUがマッピングされる様子を示す模式図である。 機器のハードウェア構成を示す模式図である。 各レイヤーが提供するサービスのアクセスポイントと、レイヤー間の関係を示す模式図である。 本実施形態のシステムにおける状態遷移を示す模式図である。 ネゴシエーションの処理を示す模式図である。 ＰＣＬバージョン情報を説明するための模式図である。 エミュレーション選択のシーケンスを示す模式図である。 ＰＣＬエミュレーションのサービスを示す模式図である。 ＰＣＬエミュレーションのサービスを示す模式図である。

符号の説明

１００ ユーザアプリケーション
１０２ ＰＣＬ
１０２ａ ＰＣＬコモン
１０２ｂ ＰＣＬエミュレーション
１０８ 物理層
２１０ ＣＰＵ

Claims (10)

1. 他の通信相手との間で信号の送受信を行う物理層と、
   上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、
   前記プロトコル変換部は、
   互いに通信可能な各装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、
   前記上位アプリケーションの１又は複数のプロトコルに対応して設けられ、前記共通処理部により前記１又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含むことを特徴とする、通信装置。
2. 前記共通処理部は、少なくとも前記プロトコル変換の起動、停止を含む基本動作を行うことを特徴とする、請求項１に記載の通信装置。
3. 前記共通処理部は、前記通信相手とのネゴシエーションの結果に応じて、前記１又は複数のプロトコルの中から前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択することを特徴とする、請求項１に記載の通信装置。
4. 前記共通処理部は、前記１又は複数のプロトコルの中に、前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが存在しなかった場合は、当該通信相手との接続を行わないことを特徴とする、請求項３に記載の通信装置。
5. 前記共通処理部は、通信相手とのネゴシエーションの結果に応じて、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致するか否かを判定するバージョンチェック機能を備えることを特徴とする、請求項１に記載の通信装置。
6. 前記共通処理部は、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致しなかった場合は、当該通信相手との接続を行わないことを特徴とする、請求項５に記載の通信装置。
7. 前記物理層は、前記変換処理部でプロトコルが変換されたデータに対してデータの種別を表すプロファイルＩＤが付されたデータを通信相手との間で通信することを特徴とする、請求項１に記載の通信装置。
8. 通信装置同士が通信を行う通信システムであって、
   前記通信装置は、
   通信相手となる通信装置の間で信号の送受信を行う物理層と、
   上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、
   前記プロトコル変換部は、
   互いに通信可能な各通信装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、
   前記上位アプリケーションの１又は複数のプロトコルに対応して設けられ、前記共通処理部により前記１又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含むことを特徴とする、通信システム。
9. 通信装置同士が通信を行う通信方法であって、
   前記通信装置が通信相手となる他の通信装置との間でプロトコル情報を交換するステップと、
   前記プロトコル情報に基づいて、上位アプリケーションの１又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択するステップと、
   選択されたプロトコルを通信相手と通信するためのプロトコルに変換するステップと、
   を備えることを特徴とする、通信方法。
10. 通信相手となる他の通信装置との間でプロトコル情報を交換する手段、
    前記プロトコル情報に基づいて、上位アプリケーションの１又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択する手段、
    選択されたプロトコルを通信相手と通信するためのプロトコルに変換する手段、
    としてコンピュータを機能させるためのプログラム。

Images