通信装置、通信システム、通信方法及びプログラム
【課題】上位アプリケーションが1又は複数のプロトコルを備える場合に、通信の互換性を確実に確保することが可能な通信装置を提供すること。
【解決手段】無線通信により他の通信相手との間で信号の送受信を行う物理層108と、上位のユーザアプリケーション100と物理層108との間を接続するプロトコル変換部(PCL)102とを備え、プロトコル変換部102は、互いに通信可能な各装置に共通に設けられ、プロトコル変換のための基本処理を行うPCLコモン102aと、ユーザアプリケーション102の1又は複数のプロトコルに対応して設けられ、PCLコモン102aにより1又は複数のプロトコルの中から選択されたプロトコルを物理層108で通信するためのプロトコルに変換する変換処理部と、を含む。
【解決手段】無線通信により他の通信相手との間で信号の送受信を行う物理層108と、上位のユーザアプリケーション100と物理層108との間を接続するプロトコル変換部(PCL)102とを備え、プロトコル変換部102は、互いに通信可能な各装置に共通に設けられ、プロトコル変換のための基本処理を行うPCLコモン102aと、ユーザアプリケーション102の1又は複数のプロトコルに対応して設けられ、PCLコモン102aにより1又は複数のプロトコルの中から選択されたプロトコルを物理層108で通信するためのプロトコルに変換する変換処理部と、を含む。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信装置、通信システム、通信方法及びプログラムに関する。
【背景技術】
【0002】
従来、例えば下記の特許文献1に記載されているように、移動体の利用者が所有する汎用の携帯端末に移動体の情報を発信できることを意図した移動体通信システムが知られている。
【0003】
【特許文献1】特開2005−191819号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
近時においては、通信装置に複数の上位アプリケーションが搭載されることが想定されている。このような装置においては、上位アプリケーションのプロトコルが複数になることが想定される。
【0005】
しかしながら、上位アプリケーションのプロトコルが複数になると、どのプロトコルを使用して通信を実現するかが問題となり、使用するプロトコルによっては、通信相手との接続の際に互換性が無くなる事態が想定される。この場合、通信装置側で複数アプリケーションによる多機能を実現したとしても、他の装置との間で通信の互換性が得られなくなり、結果としてシステム上の制約が生じてしまう。
【0006】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、上位アプリケーションが1又は複数のプロトコルを備える場合に、通信の互換性を確実に確保することが可能な、新規かつ改良された通信装置、通信システム、通信方法及びプログラムを提供することにある。
【課題を解決するための手段】
【0007】
上記課題を解決するために、本発明のある観点によれば、他の通信相手との間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、前記プロトコル変換部は、互いに通信可能な各装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、前記上位アプリケーションの1又は複数のプロトコルに対応して設けられ、前記共通処理部により前記1又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含む通信装置が提供される。
【0008】
上記構成によれば、物理層により他の通信相手との間で信号の送受信が行われ、プロトコル変換部により上位アプリケーションと物理層との間が接続される。プロトコル変換部の共通処理部は、互いに通信可能な各装置に共通に設けられ、共通処理部によりプロトコル変換のための基本処理が行われる。プロトコル変換部の変換処理部は、上位アプリケーションの1又は複数のプロトコルに対応して設けられる。そして、共通処理部により1又は複数のプロトコルの中から選択されたプロトコルは、変換処理部により物理層で通信するためのプロトコルに変換される。従って、互いに通信可能な各装置に共通に設けられた共通処理部により、1又は複数のプロトコルの中からプロトコルが選択されるため、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。
【0009】
また、前記共通処理部は、少なくとも前記プロトコル変換の起動、停止を含む基本動作を行うものであってもよい。かかる構成によれば、互いに通信可能な各装置に共通に設けられた共通処理部により、プロトコル変換の起動、停止を含む基本動作を実現することができる。
【0010】
また、前記共通処理部は、前記通信相手とのネゴシエーションの結果に応じて、前記1又は複数のプロトコルの中から前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択するものであってもよい。かかる構成によれば、通信相手とのネゴシエーションの結果に応じて、1又は複数のプロトコルの中から通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが選択されるため、通信相手との互換性を確保し、通信相手との通信を確実に行うことができる。
【0011】
また、前記共通処理部は、前記1又は複数のプロトコルの中に、前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが存在しなかった場合は、当該通信相手との接続を行わないものであってもよい。かかる構成によれば、1又は複数のプロトコルの中に、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが存在しなかった場合は、当該通信相手との接続を行わないため、不要な処理が行われることを抑止することができる。
【0012】
また、前記共通処理部は、通信相手とのネゴシエーションの結果に応じて、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致するか否かを判定するバージョンチェック機能を備えるものであってもよい。かかる構成によれば、通信相手とのネゴシエーションの結果に応じて、プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致するか否かが判定されるため、通信相手との互換性を確保し、通信相手との通信を確実に行うことができる。
【0013】
また、前記共通処理部は、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致しなかった場合は、当該通信相手との接続を行わないものであってもよい。かかる構成によれば、プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致しなかった場合は、当該通信相手との接続を行わないため、不要な処理が行われることを抑止することができる。
【0014】
また、前記物理層は、前記変換処理部でプロトコルが変換されたデータに対してデータの種別を表すプロファイルIDが付されたデータを通信相手との間で通信するものであってもよい。かかる構成によれば、複数の論理チャネルを1つの物理層上で実現することが可能となる。
【0015】
また、上記課題を解決するために、本発明の別の観点によれば、通信装置同士が通信を行う通信システムであって、前記通信装置は、通信相手となる通信装置の間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、前記プロトコル変換部は、互いに通信可能な各通信装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、前記上位アプリケーションの1又は複数のプロトコルに対応して設けられ、前記共通処理部により前記1又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含む通信システムが提供される。
【0016】
上記構成によれば、通信装置同士が通信を行う通信システムにおいて、物理層により通信相手となる通信装置の間で信号の送受信が行われ、プロトコル変換部により上位アプリケーションと物理層との間が接続される。プロトコル変換部の共通処理部は、互いに通信可能な各装置に共通に設けられ、共通処理部によりプロトコル変換のための基本処理が行われる。プロトコル変換部の変換処理部は、上位アプリケーションの1又は複数のプロトコルに対応して設けられる。そして、共通処理部により1又は複数のプロトコルの中から選択されたプロトコルは、変換処理部により物理層で通信するためのプロトコルに変換される。従って、互いに通信可能な各装置に共通に設けられた共通処理部により、1又は複数のプロトコルの中からプロトコルが選択されるため、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。
【0017】
また、上記課題を解決するために、本発明の別の観点によれば、通信装置同士が通信を行う通信方法であって、前記通信装置が通信相手となる他の通信装置との間でプロトコル情報を交換するステップと、前記プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択するステップと、選択されたプロトコルを通信相手と通信するためのプロトコルに変換するステップと、を備える通信方法が提供される。
【0018】
上記構成によれば、通信装置同士が通信を行う通信方法において、通信相手となる他の通信装置との間でプロトコル情報が交換され、プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが選択され、選択されたプロトコルが通信相手と通信するためのプロトコルに変換される。従って、通信相手との間で交換されたプロトコル情報に基づいて、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。
【0019】
また、上記課題を解決するために、本発明の別の観点によれば、通信相手となる他の通信装置との間でプロトコル情報を交換する手段、前記プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択する手段、選択されたプロトコルを通信相手と通信するためのプロトコルに変換する手段、としてコンピュータを機能させるためのプログラムが提供される。
【0020】
上記構成によれば、通信相手となる他の通信装置との間でプロトコル情報が交換され、プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが選択され、選択されたプロトコルが通信相手と通信するためのプロトコルに変換される。従って、通信相手との間で交換されたプロトコル情報に基づいて、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。
【発明の効果】
【0021】
本発明によれば、上位アプリケーションが1又は複数のプロトコルを備える場合に、通信の互換性を確実に確保することが可能となる。
【発明を実施するための最良の形態】
【0022】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0023】
本実施形態の無線通信システムは、一対の機器の間でデータを送受信することを目的とした通信方式であり、近距離の機器間で無線によりデータの送受信を行う。図1は、本実施形態の無線通信システムを構成する2つの機器(通信装置)を示す模式図である。2つの機器は、それぞれレスポンダー(Responder)とイニシエータ(Initiator)という役割を有する。イニシエータは「接続要求を出す側」であり、レスポンダーは「接続要求を受ける側」であり、本実施形態では1対1(P2P)の通信が行われる。接続の際、イニシエータは接続要求を出し、レスポンダーは持ち受け状態となるが、両者は接続の際の役割が異なるのみで、接続に関係する機器の構成は同一である。イニシエータとしては例えば携帯機器、電子カードなどが該当し、レスポンダーとしてはパーソナルコンピュータ、携帯機器、電子カードなどの機器が該当する。
【0024】
図1では、本実施形態の各機器のそれぞれが備える物理層を介して無線通信が行われる様子を模式的に示している。本実施形態では、物理層としてJET物理層と称されるものを例示するが、物理層はこれに限定されるものではなく、通信用の汎用的な物理層に適用することができる。JET物理層は、後述するプロファイルID、CSDU等を用いることで写真、動画などの大容量のデータ通信に特に適したものである。また、本明細書において、イニシエータ、レスポンダーの双方の機器を総称してJETデバイス(または単にJET)と称する場合がある。
【0025】
図2は、本実施形態に係る無線通信システムにおいて、イニシエータ、レスポンダーの各機器の構成を階層構造として示した模式図である。図2に示すように、本実施形態では、上層から順にユーザアプリケーション(User Application)100、PCL(Protocol Conversion Layer)102、DTL(Data Transfer Layer)104、CNL(Connection Layer)106、物理層(Physical Layer)108が構成されている。
【0026】
ユーザアプリケーション100は、本実施形態による近距離無線通信が可能な物理層108を搭載する機器において、物理層108の上層のソフトウェアの提供するサービスを用いて、データ通信を行うための上位プロトコル(例えばUSB、TCP/IP、OBEXなど)や、UI(User Interface)等のJETを含めた機器操作を行うアプリケーション(例えばウィンドウズ(Windows(登録商標))、リナックス(Linux)などのOS)が該当する。JET deviceでは、これらの上位プロトコル、またはユーザアプリケーションについては特に規定されるものではなく、機器を構成するユーザ(メーカ)が自由に設定することができる。従って、各機器は、複数の上位プロトコル、またはユーザアプリケーション100を備えていても良い。
【0027】
PCL102(プロトコル変換部)は、機器を構成するユーザが使用する任意のプロトコル(USB,OBEX等)を、JET独自のプロトコルに相互変換する、プロトコル変換(Protocol Conversion)機能をサポートする。これにより、複数の種類のプロトコルをJETの物理層(PHY Layer)108に流すことで、様々なプロトコルをサポートすることが可能である。なお、同じUSBであっても、Windows、LinuxなどのOSの違いによってプロトコル変換が異なる場合がある。PCL102は、上位のユーザアプリケーション100が生成する音声、映像等のコンテンツデータ、その他のプロトコルのデータ、コマンド等を下位のDTL104が扱うことが可能なデータ形式に変換する処理を行う。また、PCL102は、接続、切断、機器認証、動作モード設定、初期化等のJETの通信に必要な処理を行う。
【0028】
図3は、イニシエータ、レスポンダーにおけるデータの流れを示す模式図である。図3に示すように、ユーザアプリケーション100はJETによる接続と、データ転送の2種類の制御を行うことになる。JETとしては最上位PCL102でこれらの機能を実現するために必要なサービスを提供し、JET独自のプロトコルへの変換と、接続管理を行う。さらにJET規格に準拠したCSDU (CNL service data unit)を生成するDTL104、CNL106への受け渡しを行う。
【0029】
DTL104は、上位のPCL102から受け取ったデータを、所定のパケット構造に整形し、下位のCNL106が提供するサービスを用いて、イニシエータ、レスポンダー間の送信を行う。また、受信においては、CNL106が受信したデータを解析し、CSDUを抽出し、そのペイロードを上位のPCL102に引き渡す。CSDUには、物理層(PHY Layer)108による通信以外のユーザアプリケーション100で利用可能なステータス情報も含まれており、DTL104は、これらの生成処理、エラー通知等も行う。
【0030】
DTL104は、上位プロトコルの種別に関わらず、上位から入力されたデータをDTLパケットに整形して下位のCNL106に渡し、下位からの受信データからDTLパケットを抽出し、上位にDTLパケットペイロードを受け渡すことが可能である。ただし、DTL104自身は、PCL102からの異なるprotocolから送られてくるデータを受け入れることが可能ではあるが、JETでは異なるプロトコルのデータの送受信は一度セッションの切断を必要とするため、複数プロトコルでのDTLサービスの利用は行わない。
【0031】
この制限により、後述する複数のPCLエミュレーションからDTL104へデータの入力が行われたとしても、DTL104はそのデータのMuxを行うことはない。また、CNL106からの受信データに複数のプロトコルが含まれていた場合であっても、そのプロトコルの解析、それぞれのプロトコル内容に合わせたPCL102への配信、またはエラー検知によるセッションの切断等の処理は行わない。
【0032】
このため、DTL104によるサービスを利用するPCL102側では、必ず利用するプロトコルを1種類に確定した状態でDTL104によるサービスを利用する必要がある。これらのプロトコル方式を確定させるための判断と、必要な送受信を行うのは後述するPCLコモンの役割であり、プロトコルデータの生成、パースはPCLエミュレーションが行う。複数のプロトコルから同時にDTLサービスを利用できないよう排他処理もPCLコモンの役割である。
【0033】
DTL104はPCLコモンが接続を確立するのに必要なサービス、接続確立後にPCLエミュレーションがデータの送受信を行うのに必要なサービスを提供する。
【0034】
また、DTL104は、現在実行されているサービスが、全転送サイズの途中データなのか、最後のデータなのか、もしくは、データではなくパラメータなのかを示すプロファイルID(Profile ID)、サイズをPCL102よりパラメータとして受け取り、下位のCNLサービスを利用して生成するCSDUパケットヘッダに挿入する。DTL104は、送信パラメータを、JETがデータを送信する際に生成するCSDUパケットの一部に埋め込むことで図6のような複数の論理チャネル(Channel)を1つの物理層(PHY Layer)108上で実現する。
【0035】
DTL104は、JET規格に定義されているCSDUパケットを生成する機能を有する。DTL104では、CSDUパケットの種別を理解するためのパラメータをCSDUパケットヘッダに付加する。付加するものはProfile ID , Size , Data Payloadである。
【0036】
DTL104はCNL106が提供するCSDUの単位でデータ転送を行う。 DTL104はCSDU送信時に以下の3種類のプロファイルID(T_DATA, LT_DATA, CNL_DATA)をCSDUに対して付与する。さらに、CSDU受信時は、プロファイルIDの種類に応じた処理を行う。
【0037】
T_DATA, LT_DATA
DTL104は、ユーザデータを転送するCSDUに対して、T_DATAを付与する。ただし、CSDUペイロードへの分割において、最終のCSDUとなる場合にはLT_DATAを付与する。CSDUのペイロードには、ユーザデータのみが格納され、DTL104がヘッダ情報などを埋め込むことはない。
【0038】
CNL_DATA
DTL104は、JETシステム固有の制御データを転送するCSDUに対して、CNL_DATAを付与する。制御データの例としては、パラメータ情報(詳細はTBD)などがある。CSDUペイロードにはヘッダ情報(詳細はTBD)が埋め込まれる。DTL104はこのヘッダ情報を解釈し、適切な処理を行う。
【0039】
CNL106は、上位のDTL104の要求に応じて、物理層108のサービスを利用した通信を行う他、物理層108の接続の確立、切断、データの連続性の保障などを行う。
【0040】
物理層108は、本実施形態による近距離大容量通信が可能な無線通信システムのJET物理層であり、誤り訂正機能、プリアンブルセンス(preamble sense)機能を含む。
【0041】
図4は、JET
deviceを搭載する機器のソフトウェアの役割に基づいて、図2の構成をOSI参照モデルで示したものである。図4に示すように、物理層(第1層)108は、データを通信回線に送出するための電気的な変換や機械的な作業を受け持つ。ピンの形状やケーブルの特性なども第1層で定められる。
【0042】
DTL104、CNL106は、データリンク層(第2層)、トランスポート層(第4層)に対応する。データリンク層は、通信相手との物理的な通信路を確保し、通信路を流れるデータのエラー検出などを行う。また、トランスポート層は、通信相手まで確実に効率良くデータを届けるためのデータ圧縮や誤り訂正、再送制御などを行う。なお、本実施形態のシステムはP2P通信であるため、OSI参照モデルにおけるネットワーク層(第3層)は設けられておらず、システムを簡略化することができる。
【0043】
PCL102は、セッション層(第5層)とプレゼンテーション層(第6層)が対応する。セッション層は、通信プログラム同士がデータの送受信を行うための仮想的な経路(コネクション)の確立や解放を行う。プレゼンテーション層は、セッション層から受け取ったデータをユーザが分かり易い形式に変換したり、アプリケーション層から送られてくるデータを通信に適した形式に変換するなどの処理を行う。
【0044】
ユーザアプリケーション100は、アプリケーション層(第7層)に対応する。アプリケーション層は、データ通信を利用した様々なサービスを人間や他のプログラムに提供する。
【0045】
次に、本実施形態の通信装置におけるデータの流れを説明する。図5は、データフローを示す模式図であって、JET機器内の各レイヤーにおけるファイル、データの送受信のデータフローを示している。なお、PCL102は、PCLコモンとPCLエミュレーションに機能が分かれる。データ転送で利用するのはPCLエミュレーションであるため、図5に示すPCL102による処理はPCLエミュレーションによって実現される機能である。物理層108に入力されるCSDUは、データフォーマットとして規定されており、そのヘッダ情報等の生成、解析を行うDTL104が扱うデータフォーマットも同様である。
【0046】
また、後述するように、共通機能を提供するためのPCLコモンについては規定されているが、PCLエミュレーションは、ユーザプロトコルに準じたデータ変換処理を行うため、それぞれのプロトコルに応じたシステム仕様に依存する。
【0047】
JET通信では、ファイル等のデータだけではなく、PCL102、DTL104内での管理パラメータや、通信先の同一レイヤー間でのデータの送受信が存在する。これらのファイル、パラメータ類は、CNL106によって最終的にCSDUフォーマットに準拠した形式で伝送される。図6は、CSDUによる論理的なチャネルを示す模式図である。図6に示すように、データの種別を特定するにはProfile IDを用いる。これにより、物理層108のレベルで、複数の伝送Channelを論理的に用いることが可能となる。従って、通信レートを大幅に向上させることができ、特に動画などの大容量のデータ通信に適している。
【0048】
図7は、CSDUがマッピングされる様子を示す模式図である。CSDUは、CNL106とDTL104の間でやり取りされるデータユニットであり、図7に示すように、CNLフレームにマッピングされる。ユーザアプリケーション100が送受信するユーザデータサイズは特に規定されない。PCL102は、データの長さがデータ分割長(最大4096バイト)を超えた場合、複数のCSDUペイロードへ分割する。PCL102はCSDUペイロードの単位で、DTLサービスを呼び出してユーザデータの送受信を行う。DTL104はCSDUペイロードにヘッダを追加して下位のCNL106に渡す。CSDUヘッダはProfile IDとCSDUペイロードの長さを示すLengthで構成される。
【0049】
図8は、本システムの機器のハードウェア構成を示す模式図である。図5に示すように、イニシエータとレスポンダーのそれぞれは、物理層108を構成するチップ200と、CPU210とを有して構成される。物理層108は、ベースバンド部を含んでいる。上述したユーザアプリケーション100、PCL102、DTL104、CNL106は、ソフトウェア(プログラム)によりCPU210を機能させることによって実現される。ソフトウェアは、イニシエータ、レスポンダーを構成する通信装置が備えるメモリ、または通信装置の外部の記録媒体などに格納される。
【0050】
図9は、各レイヤーが提供するサービスのアクセスポイントと、レイヤー間の関係を示す模式図である。PCL102の上位は、ユーザアプリケーション100となる。PCL102は、下位DTL104を利用したサービスを提供するレイヤーである。PCL102は、上位のユーザアプリケーション100に対しては、制御をPCLコモン102a(共通処理部)が行い、データ転送はPCLエミュレーション102b(変換処理部)が行うというように、役割が分かれるため、PCL102のサービスはそれぞれに対して規定される。
【0051】
PCLコモン102aによるサービスは、ユーザアプリケーション100の要求に応じて、DTL104の接続/切断/その他の制御のサービスを呼び出すことで下記のサービスを提供する。
・接続、切断などの制御サービス
・エラーなどのイベント通知サービス
・エミュレーション制御サービス
【0052】
PCLエミュレーション102bによるサービスは、対応するプロトコルごとに個別に存在する。個々のPCLエミュレーションはCSDUのペイロード上に汎用プロトコル(USB,OBEX等)のコマンド、データを乗せて通信することを可能にするプロトコルサービスである。
【0053】
PCL102では、PCLエミュレーションサービスにより選択されたプロトコル方式に該当するサービスのみ起動することが許可される。PCLエミュレーションサービス内部では上位プロトコルの要求にしたがって、DTL104によるサービスを利用するためのCSDUペイロードを生成する。PCLエミュレーション102bによるサービスを複数持つことで、1つのJET機器で複数のエミュレーションサービス(Emulation Service)を実現することが可能になる。PCLコモン102aにより、1度のセッションで利用できるエミュレーションサービスは1種類のみであるように管理される。
【0054】
図9に示すように、PCL102は、PCLコモン(PCL Common)102aと、PCLエミュレーション(PCL Emulation)102bにその機能が分割される。PCLコモン102aは、上位のユーザアプリケーション100の要求によって、下位レイヤのサービスの初期化や、接続、切断等の基本機能を提供する。PCLコモン102aでは基本機能の処理を行うため、どのプロトコルが選択された場合においても同様の処理が行われる。一方、PCLエミュレーション102bは、PCLコモン102aにより起動が完了した後、ユーザアプリケーション100が有する任意のプロトコルを下位のDTL104、CNL106が扱うプロトコル形式に変換する。
【0055】
上述のように、PCLコモン102aは、初期化、基本通信(接続、切断、機器認証)等の共通機能サービスをユーザアプリケーション100に対して提供する。PCLコモン102aは、全てのJETデバイスで共通に設けられるソフトウェアである。従って、PCL102は、PCLエミュレーション102bのみの構成では動作することができない。
【0056】
PCLエミュレーション102bは、PCLコモン102aによって接続が行われた後、ユーザデータ転送を行うもので、ユーザプロトコル(USB,OBEX等の汎用プロトコルデータ)をDTL104が扱うデータ形式に相互変換する役割を持つ。PCLエミュレーション102bは、ユーザアプリケーション100から送られてくるユーザプロトコルデータを、下位のDTL104が解釈できる形式に変換する役割を有する。PCL102内のエミュレーションブロック(PCLエミュレーション102bの変換モジュール)は、ユーザアプリケーション100から見た場合に、既存のUSB MSC,NFC等のデバイスを制御するのと同等の方式でデータ転送機能を提供するためのサービスを提供する。但し、PCLエミュレーション102bは、機器を構成するユーザー固有のプロトコル数だけ存在する。
【0057】
DTL104は、上位の2種類のPCL(PCL Common102a, PCL Emulation102b)に対して、下位CNL106のサービスを利用した機能を、DTLサービスとして提供する。PCLエミュレーション102bは、後で詳細に説明するように、ユーザプロトコルごとに変換モジュール(Protocol A, Protocol B, Protocol C,・・・Protocol Z)を有するが、1度のセッション(接続)で利用できるのは1種類だけであり、その制御はPCLコモン102aによって行われる。例えば、上位プロトコルがUSBの場合、マスストレージクラスであるか、あるいは他の方式かによって異なる変換モジュールが用意されている。
【0058】
JETデバイスにおいて、機器を構成するユーザは、上位のプロトコルに対応した変換モジュールを自由に設定してPCLエミュレーション102bを構築することができる。また、変換モジュールの追加、削除もユーザが自由に行うことができる。一方、PCLコモン102aはプロトコル変換の基本機能であるため、全てのJETデバイスにおいて共通であることが義務付けられる。
【0059】
図9では、ユーザプロトコルとしてProtocol A〜Zが示されており、このうちProtocol Bがアクティブとされ、Protocol Bにより接続が行われている状態を示している。この場合、イニシエータとレスポンダーの双方でProtocol Bによる接続が行われる。どのプロトコルで接続するかは、イニシエータとレスポンダーとの間のネゴシエーションによって決定される。
【0060】
図10は、本実施形態のシステムにおける状態遷移を示す模式図である。PCL102は、物理層108によるイニシエータとレスポンダーの接続状態の変化や、ユーザアプリケーションからPCL Serviceを利用することにより、図10に示すような状態遷移を行う。
【0061】
図10において、先ず、レスポンダーはイニシエータからの接続待ち状態とされ、イニシエータは接続先のレスポンダーをサーチしている状態とされる。イニシエータとレスポンダーの接続が開始されると(Start Connection)、イニシエータとレスポンダー間でネゴシエーション(Negotiation)が行われる。この状態では、JETデバイス間でソフトウェアのバージョンの確認、エミュレーション方式(互いにどのようなプロトコルを有しているか)の確認が行われる。
【0062】
ネゴシエーションの結果、バージョン、エミュレーション方式が一致した場合は、接続が行われ、物理層108による接続が完了する(Connected)。その後、エミュレーションが開始され(Emulatiion)、ユーザアプリケーション100間でデータ転送が可能な状態とされる。一方、ソフトウェアのバージョン情報が一致しなかった場合、または双方が保有するプロトコルが一致せず、エミュレーション方式が一致しなかった場合は、接続が行われない(Disconnect)。接続がされなかった場合(Disconnect)、エミュレーションが終了した場合(End Emulation)は、レスポンダーが接続待ち状態となる。
【0063】
PCLコモン102aは、PCL102のバージョン(Version)情報に基づいて、バージョンチェック(Version Check)及びエミュレーション方式の判別を行うネゴシエーション機能を備える。ネゴシエーションの結果、バージョン及びエミュエーション方式が一致すれば、イニシエータとレスポンダーの間で同じプロトコルによる接続が行われる。ネゴシエーションに必要なバージョン管理機能(PCL Version Management)及び、エミュレーション判別機能(PCL Select Emulation)については後で説明する。ネゴシエーションはユーザアプリケーション100に対して提供されるサービスではなく、接続待機中の状態で、接続を検知した際に自動で実行される内部機能である。
【0064】
図11は、ネゴシエーションの処理を示す模式図である。図11の処理は、図2の各層のソフトウェアによりCPU210を機能させることで実現できる。一例として、判別自体はレスポンダーが行い、イニシエータはその判別結果を待つ。接続先のバージョン情報の取得はCNL106が行い、接続時にバージョン情報が自動的に交換される(ステップS1)。このとき交換されるバージョン情報をJETバージョンと称することとする。
【0065】
PCL102では、下位のCNL106、DTL104からのイベントにより、接続を検知した時点で接続先JETデバイスのJETバージョンの情報を既に取得できている。このため、先ず、図11に示すように、CNL106のソフトウェアのバージョンチェック(CNL Ver check)とDTLのソフトウェアのバージョンチェック(DTL Ver check)が行われる。PCL102の内部で行われるのは、JETバージョン内に含まれるPCLバージョンのチェックによるエミュレーション方式の判別である。
【0066】
エミュレーション方式の判別は、例えばレスポンダーが主導して行う。イニシエータとレスポンダーの双方でPCL102のバージョン情報が交換され、PCLコモン102aのPCLバージョンチェック機能により、PCL102のソフトウェアのバージョン情報がチェックされる(PCL Ver check)。
【0067】
次に、イニシエータとレスポンダーの双方でエミュレーションタイプの情報が交換され、図11に示すように、PCLコモン102aのエミュレーションタイプチェック機能により、エミュレーションのタイプがチェックされる(EMU Type check)。エミュレーションタイプは、互いのJETデバイスが通信可能なエミュレーション方式(プロトコル)を記述したパラメータである。
【0068】
レスポンダー側では、イニシエータとレスポンダーの互いのエミュレーションタイプの比較を行い、同一のものがあれば接続可能であると判断する。PCL102は、エミュレーションタイプが確定した時点でユーザアプリケーション100に通知を行い、ユーザアプリケーション100がPCL_start_emu serviceを呼び出す(ステップS2)。そして、PCLコモン102aからPCLエミュレーション102bへStart_Emuというコマンドを送る。これによりPCLコモン102aによる起動が完了し、PCLエミュレーション102bによるエミュレーションが開始される(ステップS3)。そして、PCLエミュレーション102bによりユーザアプリケーション100のプロトコルを変換して、下位のDTL104、CTL106と通信を行うことが可能となる。
【0069】
また、イニシエータとレスポンダーで同一のエミュレーションタイプを複数有している場合は、ユーザアプリケーション100にその旨を通知する。ユーザアプリケーション100側でこれらの複数のエミュレーションタイプの1つを指定する場合は、その旨の情報がPCL102に送られる。この際、ユーザアプリケーション100側では、予め指定された1つのエミュレーションタイプを指定することができる。また、イニシエータとレスポンダーの一方が携帯機器の場合など、高速通信可能なプロトコルを使う必要が比較的低い場合は、通信速度に応じた適切なプロトコルのエミュレーションタイプを選択することができる。これらの仕様は、JETデバイス、またはユーザアプリケーション100を構成するユーザが自由に設定することができる。
【0070】
次に、PCL102によるエミュレーション選択について説明する。エミュレーション選択は、イニシエータからの接続検知を検知したレスポンダー側でネゴシエーションを行う際にPCLコモン102aの内部で実行される機能である。接続時にJETデバイス間で交換されるJETバージョン内のPCLバージョン情報から、互いに適合するエミュレーションを持っているかを確認する。
【0071】
図12は、JETバージョン情報を説明するための模式図である。PCL102は、自機のバージョン情報と、接続先JETデバイスのバージョン情報の2つを管理する。自機のバージョン情報は必ず起動時にロードされ、接続検知時、接続中は、接続先デバイスのバージョン情報を保持する。
【0072】
図12に示すように、JETのバージョン情報は合計10バイトであり、上層から順にプラットフォーム(Platform)情報(1byte)、JETドライババージョン情報(2byte)、CNLバージョン情報(1byte)、DTLバージョン情報(2byte)、PCLバージョン情報(2byte)、リザーブド(2byte)の情報がある。
【0073】
PCLバージョン情報(2byte)のうち、前半の1バイトは、システムの互換性維持のためのソフトウェアのVersion No (T.B.D)である。後半の1バイトは、装置(JETデバイス)が対応するエミュレーション方式を示している。図12では、エミュレーション方式としてUSB,TCP/IP,OBEX・・・が例示され、各方式に1ビットのデータが与えられている。そして、ビットが1の場合はそのエミュレーション方式に対応することを表しており、ビットが0の場合はそのエミュレーション方式に対応していないことを表している。1つのJETデバイスで対応するエミュレーション方式の最大値には規定はないが、最低でも1つのエミュレーション方式には対応しなければならない。
【0074】
なお、バージョン情報のチェックは、図11に示すように、図12の上層側(プラットフォーム側)の情報から順次に行われる。PCL102のバージョン情報のチェック後、エミュレーションタイプのチェックが行われる。
【0075】
接続の実行結果として、互いに通信可能なエミュレーション方式を記述したエミュレーションタイプが選択され、選択されたエミュレーションタイプは、レスポンダー側からユーザアプリケーション100に通知され、また許可待ちをしているイニシエータに通知される。図13は、エミュレーション選択のシーケンスを示す模式図である。図13において、選択されたエミュレーションタイプ(EMUTYPE)は、レスポンダーのユーザアプリケーション100(UsrAppl)に対してはPCL_conf_r.indとして、イニシエータ側に対してはPCL_conf_i.indとして通知される(図13参照)。
【0076】
図14及び図15は、PCLエミュレーション102bに関係するサービスを示す模式図である。以下、各サービスについて説明する。起動、終了はPCLコモン102aによって行われるが、データの送信、受信は、ユーザアプリケーション100からPCLエミュレーション102bに通信を行うことで実行できる。従って、PCLコモン102aとの間で提供されるサービス(図14)と、ユーザアプリケーション100との間で提供されるサービス(図15)に分けられる。
【0077】
Start service(Mandatory;図14)
Start serviceは、標準で提供されるサービスであり、エミュレーションを開始する際、PCLコモン102aにより実行されるPCLエミュレーション102bの初期化処理を提供するサービスである。Startが完了した時点で、ユーザアプリケーション100から、ユーザプロトコルを用いたデータ送受信が可能となる。
【0078】
End service(Mandatory;図14)
End serviceは、標準で提供されるサービスであり、エミュレーションを終了する際、PCLコモン102aにより実行されるエミュレーションの終了処理を提供するサービスである。Endが完了した時点で、ユーザアプリケーション100から、ユーザプロトコルを用いたデータ送受信は不可能となる。PCLコモン102aはエミュレーションがStartされていた場合、切断(PCL_Disconect)を実行する前に、このサービスを実行する。
【0079】
Open service(Mandatory;図15)
Open serviceは、ユーザプロトコル上での通信路のオープン時に必要な処理を提供するサービスである。
【0080】
Close service(Mandatory;図15)
Close serviceは、ユーザプロトコル上での通信路のクローズ時に必要な処理を提供するサービスである。
【0081】
Read service(Mandatory;図15)
Read serviceは、ユーザプロトコル上で、接続先のデータを取得する際に必要な処理を提供するサービスである。
【0082】
Write service(Mandatory;図15)
Write serviceは、ユーザプロトコル上で、接続先にデータを送信する際に必要な処理を提供するサービスである。
【0083】
以上のように、Open service、Close serviceは、PCLコモン102aによる上位プロトコルの初期化処理に対応する処理である。また、Read service、Write serviceは、ユーザアプリケーション100によるデータの送信、受信に関する処理である。
【0084】
User customize service(Option;図15)
上述のサービスに該当しないサービスであり、装置を構成するユーザが独自のサービスとして定義できるものである。通信路を“開く(Open)”、“閉じる(Close)”、データを“送る(Write)”、“受ける(Read)”以外の部分は、JETデバイスを構成するユーザが自由に設定できるカスタマイズ領域とされ、例えばユーザアプリケーション100の種類(Windows, Linux等)に応じて、ユーザが自由に設定することができる。但し、どのアプリケーションを使用した場合でも、上述のようにPCLコモン102aによる“Start”、“End”は必要であり、全てのJETデバイスで共通である。
【0085】
以上説明したように本実施形態によれば、ユーザアプリケーション100のプロトコルを変換するPCL102を設け、各通信装置に共通に設けられたPCLコモン102aにより、ユーザアプリケーション100の1又は複数のプロトコルの中から通信相手のプロトコルと一致するプロトコルが選択される。そして、選択されたプロトコルが物理層108で通信を行うためのプロトコルに変換されるため、通信相手のユーザアプリケーション100のプロトコルに応じて通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。なお、上述した例では、無線通信システムを例に挙げて説明したが、通信システムは有線のものであってもよい。
【0086】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【0087】
【図1】本実施形態の無線通信システムを構成する2つの機器を示す模式図である。
【図2】イニシエータ、レスポンダーの各機器の構成を階層構造として示した模式図である。
【図3】イニシエータ、レスポンダーにおけるデータの流れを示す模式図である。
【図4】図2の構成をOSI参照モデルで示した模式図である。
【図5】機器内の各レイヤーにおけるファイル、データの送受信のデータフローを示す模式図である。
【図6】CSDUによる論理的なチャネルを示す模式図である。
【図7】CSDUがマッピングされる様子を示す模式図である。
【図8】機器のハードウェア構成を示す模式図である。
【図9】各レイヤーが提供するサービスのアクセスポイントと、レイヤー間の関係を示す模式図である。
【図10】本実施形態のシステムにおける状態遷移を示す模式図である。
【図11】ネゴシエーションの処理を示す模式図である。
【図12】PCLバージョン情報を説明するための模式図である。
【図13】エミュレーション選択のシーケンスを示す模式図である。
【図14】PCLエミュレーションのサービスを示す模式図である。
【図15】PCLエミュレーションのサービスを示す模式図である。
【符号の説明】
【0088】
100 ユーザアプリケーション
102 PCL
102a PCLコモン
102b PCLエミュレーション
108 物理層
210 CPU
【技術分野】
【0001】
本発明は、通信装置、通信システム、通信方法及びプログラムに関する。
【背景技術】
【0002】
従来、例えば下記の特許文献1に記載されているように、移動体の利用者が所有する汎用の携帯端末に移動体の情報を発信できることを意図した移動体通信システムが知られている。
【0003】
【特許文献1】特開2005−191819号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
近時においては、通信装置に複数の上位アプリケーションが搭載されることが想定されている。このような装置においては、上位アプリケーションのプロトコルが複数になることが想定される。
【0005】
しかしながら、上位アプリケーションのプロトコルが複数になると、どのプロトコルを使用して通信を実現するかが問題となり、使用するプロトコルによっては、通信相手との接続の際に互換性が無くなる事態が想定される。この場合、通信装置側で複数アプリケーションによる多機能を実現したとしても、他の装置との間で通信の互換性が得られなくなり、結果としてシステム上の制約が生じてしまう。
【0006】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、上位アプリケーションが1又は複数のプロトコルを備える場合に、通信の互換性を確実に確保することが可能な、新規かつ改良された通信装置、通信システム、通信方法及びプログラムを提供することにある。
【課題を解決するための手段】
【0007】
上記課題を解決するために、本発明のある観点によれば、他の通信相手との間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、前記プロトコル変換部は、互いに通信可能な各装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、前記上位アプリケーションの1又は複数のプロトコルに対応して設けられ、前記共通処理部により前記1又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含む通信装置が提供される。
【0008】
上記構成によれば、物理層により他の通信相手との間で信号の送受信が行われ、プロトコル変換部により上位アプリケーションと物理層との間が接続される。プロトコル変換部の共通処理部は、互いに通信可能な各装置に共通に設けられ、共通処理部によりプロトコル変換のための基本処理が行われる。プロトコル変換部の変換処理部は、上位アプリケーションの1又は複数のプロトコルに対応して設けられる。そして、共通処理部により1又は複数のプロトコルの中から選択されたプロトコルは、変換処理部により物理層で通信するためのプロトコルに変換される。従って、互いに通信可能な各装置に共通に設けられた共通処理部により、1又は複数のプロトコルの中からプロトコルが選択されるため、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。
【0009】
また、前記共通処理部は、少なくとも前記プロトコル変換の起動、停止を含む基本動作を行うものであってもよい。かかる構成によれば、互いに通信可能な各装置に共通に設けられた共通処理部により、プロトコル変換の起動、停止を含む基本動作を実現することができる。
【0010】
また、前記共通処理部は、前記通信相手とのネゴシエーションの結果に応じて、前記1又は複数のプロトコルの中から前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択するものであってもよい。かかる構成によれば、通信相手とのネゴシエーションの結果に応じて、1又は複数のプロトコルの中から通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが選択されるため、通信相手との互換性を確保し、通信相手との通信を確実に行うことができる。
【0011】
また、前記共通処理部は、前記1又は複数のプロトコルの中に、前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが存在しなかった場合は、当該通信相手との接続を行わないものであってもよい。かかる構成によれば、1又は複数のプロトコルの中に、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが存在しなかった場合は、当該通信相手との接続を行わないため、不要な処理が行われることを抑止することができる。
【0012】
また、前記共通処理部は、通信相手とのネゴシエーションの結果に応じて、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致するか否かを判定するバージョンチェック機能を備えるものであってもよい。かかる構成によれば、通信相手とのネゴシエーションの結果に応じて、プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致するか否かが判定されるため、通信相手との互換性を確保し、通信相手との通信を確実に行うことができる。
【0013】
また、前記共通処理部は、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致しなかった場合は、当該通信相手との接続を行わないものであってもよい。かかる構成によれば、プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致しなかった場合は、当該通信相手との接続を行わないため、不要な処理が行われることを抑止することができる。
【0014】
また、前記物理層は、前記変換処理部でプロトコルが変換されたデータに対してデータの種別を表すプロファイルIDが付されたデータを通信相手との間で通信するものであってもよい。かかる構成によれば、複数の論理チャネルを1つの物理層上で実現することが可能となる。
【0015】
また、上記課題を解決するために、本発明の別の観点によれば、通信装置同士が通信を行う通信システムであって、前記通信装置は、通信相手となる通信装置の間で信号の送受信を行う物理層と、上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、前記プロトコル変換部は、互いに通信可能な各通信装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、前記上位アプリケーションの1又は複数のプロトコルに対応して設けられ、前記共通処理部により前記1又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含む通信システムが提供される。
【0016】
上記構成によれば、通信装置同士が通信を行う通信システムにおいて、物理層により通信相手となる通信装置の間で信号の送受信が行われ、プロトコル変換部により上位アプリケーションと物理層との間が接続される。プロトコル変換部の共通処理部は、互いに通信可能な各装置に共通に設けられ、共通処理部によりプロトコル変換のための基本処理が行われる。プロトコル変換部の変換処理部は、上位アプリケーションの1又は複数のプロトコルに対応して設けられる。そして、共通処理部により1又は複数のプロトコルの中から選択されたプロトコルは、変換処理部により物理層で通信するためのプロトコルに変換される。従って、互いに通信可能な各装置に共通に設けられた共通処理部により、1又は複数のプロトコルの中からプロトコルが選択されるため、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。
【0017】
また、上記課題を解決するために、本発明の別の観点によれば、通信装置同士が通信を行う通信方法であって、前記通信装置が通信相手となる他の通信装置との間でプロトコル情報を交換するステップと、前記プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択するステップと、選択されたプロトコルを通信相手と通信するためのプロトコルに変換するステップと、を備える通信方法が提供される。
【0018】
上記構成によれば、通信装置同士が通信を行う通信方法において、通信相手となる他の通信装置との間でプロトコル情報が交換され、プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが選択され、選択されたプロトコルが通信相手と通信するためのプロトコルに変換される。従って、通信相手との間で交換されたプロトコル情報に基づいて、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。
【0019】
また、上記課題を解決するために、本発明の別の観点によれば、通信相手となる他の通信装置との間でプロトコル情報を交換する手段、前記プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択する手段、選択されたプロトコルを通信相手と通信するためのプロトコルに変換する手段、としてコンピュータを機能させるためのプログラムが提供される。
【0020】
上記構成によれば、通信相手となる他の通信装置との間でプロトコル情報が交換され、プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが選択され、選択されたプロトコルが通信相手と通信するためのプロトコルに変換される。従って、通信相手との間で交換されたプロトコル情報に基づいて、通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。
【発明の効果】
【0021】
本発明によれば、上位アプリケーションが1又は複数のプロトコルを備える場合に、通信の互換性を確実に確保することが可能となる。
【発明を実施するための最良の形態】
【0022】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0023】
本実施形態の無線通信システムは、一対の機器の間でデータを送受信することを目的とした通信方式であり、近距離の機器間で無線によりデータの送受信を行う。図1は、本実施形態の無線通信システムを構成する2つの機器(通信装置)を示す模式図である。2つの機器は、それぞれレスポンダー(Responder)とイニシエータ(Initiator)という役割を有する。イニシエータは「接続要求を出す側」であり、レスポンダーは「接続要求を受ける側」であり、本実施形態では1対1(P2P)の通信が行われる。接続の際、イニシエータは接続要求を出し、レスポンダーは持ち受け状態となるが、両者は接続の際の役割が異なるのみで、接続に関係する機器の構成は同一である。イニシエータとしては例えば携帯機器、電子カードなどが該当し、レスポンダーとしてはパーソナルコンピュータ、携帯機器、電子カードなどの機器が該当する。
【0024】
図1では、本実施形態の各機器のそれぞれが備える物理層を介して無線通信が行われる様子を模式的に示している。本実施形態では、物理層としてJET物理層と称されるものを例示するが、物理層はこれに限定されるものではなく、通信用の汎用的な物理層に適用することができる。JET物理層は、後述するプロファイルID、CSDU等を用いることで写真、動画などの大容量のデータ通信に特に適したものである。また、本明細書において、イニシエータ、レスポンダーの双方の機器を総称してJETデバイス(または単にJET)と称する場合がある。
【0025】
図2は、本実施形態に係る無線通信システムにおいて、イニシエータ、レスポンダーの各機器の構成を階層構造として示した模式図である。図2に示すように、本実施形態では、上層から順にユーザアプリケーション(User Application)100、PCL(Protocol Conversion Layer)102、DTL(Data Transfer Layer)104、CNL(Connection Layer)106、物理層(Physical Layer)108が構成されている。
【0026】
ユーザアプリケーション100は、本実施形態による近距離無線通信が可能な物理層108を搭載する機器において、物理層108の上層のソフトウェアの提供するサービスを用いて、データ通信を行うための上位プロトコル(例えばUSB、TCP/IP、OBEXなど)や、UI(User Interface)等のJETを含めた機器操作を行うアプリケーション(例えばウィンドウズ(Windows(登録商標))、リナックス(Linux)などのOS)が該当する。JET deviceでは、これらの上位プロトコル、またはユーザアプリケーションについては特に規定されるものではなく、機器を構成するユーザ(メーカ)が自由に設定することができる。従って、各機器は、複数の上位プロトコル、またはユーザアプリケーション100を備えていても良い。
【0027】
PCL102(プロトコル変換部)は、機器を構成するユーザが使用する任意のプロトコル(USB,OBEX等)を、JET独自のプロトコルに相互変換する、プロトコル変換(Protocol Conversion)機能をサポートする。これにより、複数の種類のプロトコルをJETの物理層(PHY Layer)108に流すことで、様々なプロトコルをサポートすることが可能である。なお、同じUSBであっても、Windows、LinuxなどのOSの違いによってプロトコル変換が異なる場合がある。PCL102は、上位のユーザアプリケーション100が生成する音声、映像等のコンテンツデータ、その他のプロトコルのデータ、コマンド等を下位のDTL104が扱うことが可能なデータ形式に変換する処理を行う。また、PCL102は、接続、切断、機器認証、動作モード設定、初期化等のJETの通信に必要な処理を行う。
【0028】
図3は、イニシエータ、レスポンダーにおけるデータの流れを示す模式図である。図3に示すように、ユーザアプリケーション100はJETによる接続と、データ転送の2種類の制御を行うことになる。JETとしては最上位PCL102でこれらの機能を実現するために必要なサービスを提供し、JET独自のプロトコルへの変換と、接続管理を行う。さらにJET規格に準拠したCSDU (CNL service data unit)を生成するDTL104、CNL106への受け渡しを行う。
【0029】
DTL104は、上位のPCL102から受け取ったデータを、所定のパケット構造に整形し、下位のCNL106が提供するサービスを用いて、イニシエータ、レスポンダー間の送信を行う。また、受信においては、CNL106が受信したデータを解析し、CSDUを抽出し、そのペイロードを上位のPCL102に引き渡す。CSDUには、物理層(PHY Layer)108による通信以外のユーザアプリケーション100で利用可能なステータス情報も含まれており、DTL104は、これらの生成処理、エラー通知等も行う。
【0030】
DTL104は、上位プロトコルの種別に関わらず、上位から入力されたデータをDTLパケットに整形して下位のCNL106に渡し、下位からの受信データからDTLパケットを抽出し、上位にDTLパケットペイロードを受け渡すことが可能である。ただし、DTL104自身は、PCL102からの異なるprotocolから送られてくるデータを受け入れることが可能ではあるが、JETでは異なるプロトコルのデータの送受信は一度セッションの切断を必要とするため、複数プロトコルでのDTLサービスの利用は行わない。
【0031】
この制限により、後述する複数のPCLエミュレーションからDTL104へデータの入力が行われたとしても、DTL104はそのデータのMuxを行うことはない。また、CNL106からの受信データに複数のプロトコルが含まれていた場合であっても、そのプロトコルの解析、それぞれのプロトコル内容に合わせたPCL102への配信、またはエラー検知によるセッションの切断等の処理は行わない。
【0032】
このため、DTL104によるサービスを利用するPCL102側では、必ず利用するプロトコルを1種類に確定した状態でDTL104によるサービスを利用する必要がある。これらのプロトコル方式を確定させるための判断と、必要な送受信を行うのは後述するPCLコモンの役割であり、プロトコルデータの生成、パースはPCLエミュレーションが行う。複数のプロトコルから同時にDTLサービスを利用できないよう排他処理もPCLコモンの役割である。
【0033】
DTL104はPCLコモンが接続を確立するのに必要なサービス、接続確立後にPCLエミュレーションがデータの送受信を行うのに必要なサービスを提供する。
【0034】
また、DTL104は、現在実行されているサービスが、全転送サイズの途中データなのか、最後のデータなのか、もしくは、データではなくパラメータなのかを示すプロファイルID(Profile ID)、サイズをPCL102よりパラメータとして受け取り、下位のCNLサービスを利用して生成するCSDUパケットヘッダに挿入する。DTL104は、送信パラメータを、JETがデータを送信する際に生成するCSDUパケットの一部に埋め込むことで図6のような複数の論理チャネル(Channel)を1つの物理層(PHY Layer)108上で実現する。
【0035】
DTL104は、JET規格に定義されているCSDUパケットを生成する機能を有する。DTL104では、CSDUパケットの種別を理解するためのパラメータをCSDUパケットヘッダに付加する。付加するものはProfile ID , Size , Data Payloadである。
【0036】
DTL104はCNL106が提供するCSDUの単位でデータ転送を行う。 DTL104はCSDU送信時に以下の3種類のプロファイルID(T_DATA, LT_DATA, CNL_DATA)をCSDUに対して付与する。さらに、CSDU受信時は、プロファイルIDの種類に応じた処理を行う。
【0037】
T_DATA, LT_DATA
DTL104は、ユーザデータを転送するCSDUに対して、T_DATAを付与する。ただし、CSDUペイロードへの分割において、最終のCSDUとなる場合にはLT_DATAを付与する。CSDUのペイロードには、ユーザデータのみが格納され、DTL104がヘッダ情報などを埋め込むことはない。
【0038】
CNL_DATA
DTL104は、JETシステム固有の制御データを転送するCSDUに対して、CNL_DATAを付与する。制御データの例としては、パラメータ情報(詳細はTBD)などがある。CSDUペイロードにはヘッダ情報(詳細はTBD)が埋め込まれる。DTL104はこのヘッダ情報を解釈し、適切な処理を行う。
【0039】
CNL106は、上位のDTL104の要求に応じて、物理層108のサービスを利用した通信を行う他、物理層108の接続の確立、切断、データの連続性の保障などを行う。
【0040】
物理層108は、本実施形態による近距離大容量通信が可能な無線通信システムのJET物理層であり、誤り訂正機能、プリアンブルセンス(preamble sense)機能を含む。
【0041】
図4は、JET
deviceを搭載する機器のソフトウェアの役割に基づいて、図2の構成をOSI参照モデルで示したものである。図4に示すように、物理層(第1層)108は、データを通信回線に送出するための電気的な変換や機械的な作業を受け持つ。ピンの形状やケーブルの特性なども第1層で定められる。
【0042】
DTL104、CNL106は、データリンク層(第2層)、トランスポート層(第4層)に対応する。データリンク層は、通信相手との物理的な通信路を確保し、通信路を流れるデータのエラー検出などを行う。また、トランスポート層は、通信相手まで確実に効率良くデータを届けるためのデータ圧縮や誤り訂正、再送制御などを行う。なお、本実施形態のシステムはP2P通信であるため、OSI参照モデルにおけるネットワーク層(第3層)は設けられておらず、システムを簡略化することができる。
【0043】
PCL102は、セッション層(第5層)とプレゼンテーション層(第6層)が対応する。セッション層は、通信プログラム同士がデータの送受信を行うための仮想的な経路(コネクション)の確立や解放を行う。プレゼンテーション層は、セッション層から受け取ったデータをユーザが分かり易い形式に変換したり、アプリケーション層から送られてくるデータを通信に適した形式に変換するなどの処理を行う。
【0044】
ユーザアプリケーション100は、アプリケーション層(第7層)に対応する。アプリケーション層は、データ通信を利用した様々なサービスを人間や他のプログラムに提供する。
【0045】
次に、本実施形態の通信装置におけるデータの流れを説明する。図5は、データフローを示す模式図であって、JET機器内の各レイヤーにおけるファイル、データの送受信のデータフローを示している。なお、PCL102は、PCLコモンとPCLエミュレーションに機能が分かれる。データ転送で利用するのはPCLエミュレーションであるため、図5に示すPCL102による処理はPCLエミュレーションによって実現される機能である。物理層108に入力されるCSDUは、データフォーマットとして規定されており、そのヘッダ情報等の生成、解析を行うDTL104が扱うデータフォーマットも同様である。
【0046】
また、後述するように、共通機能を提供するためのPCLコモンについては規定されているが、PCLエミュレーションは、ユーザプロトコルに準じたデータ変換処理を行うため、それぞれのプロトコルに応じたシステム仕様に依存する。
【0047】
JET通信では、ファイル等のデータだけではなく、PCL102、DTL104内での管理パラメータや、通信先の同一レイヤー間でのデータの送受信が存在する。これらのファイル、パラメータ類は、CNL106によって最終的にCSDUフォーマットに準拠した形式で伝送される。図6は、CSDUによる論理的なチャネルを示す模式図である。図6に示すように、データの種別を特定するにはProfile IDを用いる。これにより、物理層108のレベルで、複数の伝送Channelを論理的に用いることが可能となる。従って、通信レートを大幅に向上させることができ、特に動画などの大容量のデータ通信に適している。
【0048】
図7は、CSDUがマッピングされる様子を示す模式図である。CSDUは、CNL106とDTL104の間でやり取りされるデータユニットであり、図7に示すように、CNLフレームにマッピングされる。ユーザアプリケーション100が送受信するユーザデータサイズは特に規定されない。PCL102は、データの長さがデータ分割長(最大4096バイト)を超えた場合、複数のCSDUペイロードへ分割する。PCL102はCSDUペイロードの単位で、DTLサービスを呼び出してユーザデータの送受信を行う。DTL104はCSDUペイロードにヘッダを追加して下位のCNL106に渡す。CSDUヘッダはProfile IDとCSDUペイロードの長さを示すLengthで構成される。
【0049】
図8は、本システムの機器のハードウェア構成を示す模式図である。図5に示すように、イニシエータとレスポンダーのそれぞれは、物理層108を構成するチップ200と、CPU210とを有して構成される。物理層108は、ベースバンド部を含んでいる。上述したユーザアプリケーション100、PCL102、DTL104、CNL106は、ソフトウェア(プログラム)によりCPU210を機能させることによって実現される。ソフトウェアは、イニシエータ、レスポンダーを構成する通信装置が備えるメモリ、または通信装置の外部の記録媒体などに格納される。
【0050】
図9は、各レイヤーが提供するサービスのアクセスポイントと、レイヤー間の関係を示す模式図である。PCL102の上位は、ユーザアプリケーション100となる。PCL102は、下位DTL104を利用したサービスを提供するレイヤーである。PCL102は、上位のユーザアプリケーション100に対しては、制御をPCLコモン102a(共通処理部)が行い、データ転送はPCLエミュレーション102b(変換処理部)が行うというように、役割が分かれるため、PCL102のサービスはそれぞれに対して規定される。
【0051】
PCLコモン102aによるサービスは、ユーザアプリケーション100の要求に応じて、DTL104の接続/切断/その他の制御のサービスを呼び出すことで下記のサービスを提供する。
・接続、切断などの制御サービス
・エラーなどのイベント通知サービス
・エミュレーション制御サービス
【0052】
PCLエミュレーション102bによるサービスは、対応するプロトコルごとに個別に存在する。個々のPCLエミュレーションはCSDUのペイロード上に汎用プロトコル(USB,OBEX等)のコマンド、データを乗せて通信することを可能にするプロトコルサービスである。
【0053】
PCL102では、PCLエミュレーションサービスにより選択されたプロトコル方式に該当するサービスのみ起動することが許可される。PCLエミュレーションサービス内部では上位プロトコルの要求にしたがって、DTL104によるサービスを利用するためのCSDUペイロードを生成する。PCLエミュレーション102bによるサービスを複数持つことで、1つのJET機器で複数のエミュレーションサービス(Emulation Service)を実現することが可能になる。PCLコモン102aにより、1度のセッションで利用できるエミュレーションサービスは1種類のみであるように管理される。
【0054】
図9に示すように、PCL102は、PCLコモン(PCL Common)102aと、PCLエミュレーション(PCL Emulation)102bにその機能が分割される。PCLコモン102aは、上位のユーザアプリケーション100の要求によって、下位レイヤのサービスの初期化や、接続、切断等の基本機能を提供する。PCLコモン102aでは基本機能の処理を行うため、どのプロトコルが選択された場合においても同様の処理が行われる。一方、PCLエミュレーション102bは、PCLコモン102aにより起動が完了した後、ユーザアプリケーション100が有する任意のプロトコルを下位のDTL104、CNL106が扱うプロトコル形式に変換する。
【0055】
上述のように、PCLコモン102aは、初期化、基本通信(接続、切断、機器認証)等の共通機能サービスをユーザアプリケーション100に対して提供する。PCLコモン102aは、全てのJETデバイスで共通に設けられるソフトウェアである。従って、PCL102は、PCLエミュレーション102bのみの構成では動作することができない。
【0056】
PCLエミュレーション102bは、PCLコモン102aによって接続が行われた後、ユーザデータ転送を行うもので、ユーザプロトコル(USB,OBEX等の汎用プロトコルデータ)をDTL104が扱うデータ形式に相互変換する役割を持つ。PCLエミュレーション102bは、ユーザアプリケーション100から送られてくるユーザプロトコルデータを、下位のDTL104が解釈できる形式に変換する役割を有する。PCL102内のエミュレーションブロック(PCLエミュレーション102bの変換モジュール)は、ユーザアプリケーション100から見た場合に、既存のUSB MSC,NFC等のデバイスを制御するのと同等の方式でデータ転送機能を提供するためのサービスを提供する。但し、PCLエミュレーション102bは、機器を構成するユーザー固有のプロトコル数だけ存在する。
【0057】
DTL104は、上位の2種類のPCL(PCL Common102a, PCL Emulation102b)に対して、下位CNL106のサービスを利用した機能を、DTLサービスとして提供する。PCLエミュレーション102bは、後で詳細に説明するように、ユーザプロトコルごとに変換モジュール(Protocol A, Protocol B, Protocol C,・・・Protocol Z)を有するが、1度のセッション(接続)で利用できるのは1種類だけであり、その制御はPCLコモン102aによって行われる。例えば、上位プロトコルがUSBの場合、マスストレージクラスであるか、あるいは他の方式かによって異なる変換モジュールが用意されている。
【0058】
JETデバイスにおいて、機器を構成するユーザは、上位のプロトコルに対応した変換モジュールを自由に設定してPCLエミュレーション102bを構築することができる。また、変換モジュールの追加、削除もユーザが自由に行うことができる。一方、PCLコモン102aはプロトコル変換の基本機能であるため、全てのJETデバイスにおいて共通であることが義務付けられる。
【0059】
図9では、ユーザプロトコルとしてProtocol A〜Zが示されており、このうちProtocol Bがアクティブとされ、Protocol Bにより接続が行われている状態を示している。この場合、イニシエータとレスポンダーの双方でProtocol Bによる接続が行われる。どのプロトコルで接続するかは、イニシエータとレスポンダーとの間のネゴシエーションによって決定される。
【0060】
図10は、本実施形態のシステムにおける状態遷移を示す模式図である。PCL102は、物理層108によるイニシエータとレスポンダーの接続状態の変化や、ユーザアプリケーションからPCL Serviceを利用することにより、図10に示すような状態遷移を行う。
【0061】
図10において、先ず、レスポンダーはイニシエータからの接続待ち状態とされ、イニシエータは接続先のレスポンダーをサーチしている状態とされる。イニシエータとレスポンダーの接続が開始されると(Start Connection)、イニシエータとレスポンダー間でネゴシエーション(Negotiation)が行われる。この状態では、JETデバイス間でソフトウェアのバージョンの確認、エミュレーション方式(互いにどのようなプロトコルを有しているか)の確認が行われる。
【0062】
ネゴシエーションの結果、バージョン、エミュレーション方式が一致した場合は、接続が行われ、物理層108による接続が完了する(Connected)。その後、エミュレーションが開始され(Emulatiion)、ユーザアプリケーション100間でデータ転送が可能な状態とされる。一方、ソフトウェアのバージョン情報が一致しなかった場合、または双方が保有するプロトコルが一致せず、エミュレーション方式が一致しなかった場合は、接続が行われない(Disconnect)。接続がされなかった場合(Disconnect)、エミュレーションが終了した場合(End Emulation)は、レスポンダーが接続待ち状態となる。
【0063】
PCLコモン102aは、PCL102のバージョン(Version)情報に基づいて、バージョンチェック(Version Check)及びエミュレーション方式の判別を行うネゴシエーション機能を備える。ネゴシエーションの結果、バージョン及びエミュエーション方式が一致すれば、イニシエータとレスポンダーの間で同じプロトコルによる接続が行われる。ネゴシエーションに必要なバージョン管理機能(PCL Version Management)及び、エミュレーション判別機能(PCL Select Emulation)については後で説明する。ネゴシエーションはユーザアプリケーション100に対して提供されるサービスではなく、接続待機中の状態で、接続を検知した際に自動で実行される内部機能である。
【0064】
図11は、ネゴシエーションの処理を示す模式図である。図11の処理は、図2の各層のソフトウェアによりCPU210を機能させることで実現できる。一例として、判別自体はレスポンダーが行い、イニシエータはその判別結果を待つ。接続先のバージョン情報の取得はCNL106が行い、接続時にバージョン情報が自動的に交換される(ステップS1)。このとき交換されるバージョン情報をJETバージョンと称することとする。
【0065】
PCL102では、下位のCNL106、DTL104からのイベントにより、接続を検知した時点で接続先JETデバイスのJETバージョンの情報を既に取得できている。このため、先ず、図11に示すように、CNL106のソフトウェアのバージョンチェック(CNL Ver check)とDTLのソフトウェアのバージョンチェック(DTL Ver check)が行われる。PCL102の内部で行われるのは、JETバージョン内に含まれるPCLバージョンのチェックによるエミュレーション方式の判別である。
【0066】
エミュレーション方式の判別は、例えばレスポンダーが主導して行う。イニシエータとレスポンダーの双方でPCL102のバージョン情報が交換され、PCLコモン102aのPCLバージョンチェック機能により、PCL102のソフトウェアのバージョン情報がチェックされる(PCL Ver check)。
【0067】
次に、イニシエータとレスポンダーの双方でエミュレーションタイプの情報が交換され、図11に示すように、PCLコモン102aのエミュレーションタイプチェック機能により、エミュレーションのタイプがチェックされる(EMU Type check)。エミュレーションタイプは、互いのJETデバイスが通信可能なエミュレーション方式(プロトコル)を記述したパラメータである。
【0068】
レスポンダー側では、イニシエータとレスポンダーの互いのエミュレーションタイプの比較を行い、同一のものがあれば接続可能であると判断する。PCL102は、エミュレーションタイプが確定した時点でユーザアプリケーション100に通知を行い、ユーザアプリケーション100がPCL_start_emu serviceを呼び出す(ステップS2)。そして、PCLコモン102aからPCLエミュレーション102bへStart_Emuというコマンドを送る。これによりPCLコモン102aによる起動が完了し、PCLエミュレーション102bによるエミュレーションが開始される(ステップS3)。そして、PCLエミュレーション102bによりユーザアプリケーション100のプロトコルを変換して、下位のDTL104、CTL106と通信を行うことが可能となる。
【0069】
また、イニシエータとレスポンダーで同一のエミュレーションタイプを複数有している場合は、ユーザアプリケーション100にその旨を通知する。ユーザアプリケーション100側でこれらの複数のエミュレーションタイプの1つを指定する場合は、その旨の情報がPCL102に送られる。この際、ユーザアプリケーション100側では、予め指定された1つのエミュレーションタイプを指定することができる。また、イニシエータとレスポンダーの一方が携帯機器の場合など、高速通信可能なプロトコルを使う必要が比較的低い場合は、通信速度に応じた適切なプロトコルのエミュレーションタイプを選択することができる。これらの仕様は、JETデバイス、またはユーザアプリケーション100を構成するユーザが自由に設定することができる。
【0070】
次に、PCL102によるエミュレーション選択について説明する。エミュレーション選択は、イニシエータからの接続検知を検知したレスポンダー側でネゴシエーションを行う際にPCLコモン102aの内部で実行される機能である。接続時にJETデバイス間で交換されるJETバージョン内のPCLバージョン情報から、互いに適合するエミュレーションを持っているかを確認する。
【0071】
図12は、JETバージョン情報を説明するための模式図である。PCL102は、自機のバージョン情報と、接続先JETデバイスのバージョン情報の2つを管理する。自機のバージョン情報は必ず起動時にロードされ、接続検知時、接続中は、接続先デバイスのバージョン情報を保持する。
【0072】
図12に示すように、JETのバージョン情報は合計10バイトであり、上層から順にプラットフォーム(Platform)情報(1byte)、JETドライババージョン情報(2byte)、CNLバージョン情報(1byte)、DTLバージョン情報(2byte)、PCLバージョン情報(2byte)、リザーブド(2byte)の情報がある。
【0073】
PCLバージョン情報(2byte)のうち、前半の1バイトは、システムの互換性維持のためのソフトウェアのVersion No (T.B.D)である。後半の1バイトは、装置(JETデバイス)が対応するエミュレーション方式を示している。図12では、エミュレーション方式としてUSB,TCP/IP,OBEX・・・が例示され、各方式に1ビットのデータが与えられている。そして、ビットが1の場合はそのエミュレーション方式に対応することを表しており、ビットが0の場合はそのエミュレーション方式に対応していないことを表している。1つのJETデバイスで対応するエミュレーション方式の最大値には規定はないが、最低でも1つのエミュレーション方式には対応しなければならない。
【0074】
なお、バージョン情報のチェックは、図11に示すように、図12の上層側(プラットフォーム側)の情報から順次に行われる。PCL102のバージョン情報のチェック後、エミュレーションタイプのチェックが行われる。
【0075】
接続の実行結果として、互いに通信可能なエミュレーション方式を記述したエミュレーションタイプが選択され、選択されたエミュレーションタイプは、レスポンダー側からユーザアプリケーション100に通知され、また許可待ちをしているイニシエータに通知される。図13は、エミュレーション選択のシーケンスを示す模式図である。図13において、選択されたエミュレーションタイプ(EMUTYPE)は、レスポンダーのユーザアプリケーション100(UsrAppl)に対してはPCL_conf_r.indとして、イニシエータ側に対してはPCL_conf_i.indとして通知される(図13参照)。
【0076】
図14及び図15は、PCLエミュレーション102bに関係するサービスを示す模式図である。以下、各サービスについて説明する。起動、終了はPCLコモン102aによって行われるが、データの送信、受信は、ユーザアプリケーション100からPCLエミュレーション102bに通信を行うことで実行できる。従って、PCLコモン102aとの間で提供されるサービス(図14)と、ユーザアプリケーション100との間で提供されるサービス(図15)に分けられる。
【0077】
Start service(Mandatory;図14)
Start serviceは、標準で提供されるサービスであり、エミュレーションを開始する際、PCLコモン102aにより実行されるPCLエミュレーション102bの初期化処理を提供するサービスである。Startが完了した時点で、ユーザアプリケーション100から、ユーザプロトコルを用いたデータ送受信が可能となる。
【0078】
End service(Mandatory;図14)
End serviceは、標準で提供されるサービスであり、エミュレーションを終了する際、PCLコモン102aにより実行されるエミュレーションの終了処理を提供するサービスである。Endが完了した時点で、ユーザアプリケーション100から、ユーザプロトコルを用いたデータ送受信は不可能となる。PCLコモン102aはエミュレーションがStartされていた場合、切断(PCL_Disconect)を実行する前に、このサービスを実行する。
【0079】
Open service(Mandatory;図15)
Open serviceは、ユーザプロトコル上での通信路のオープン時に必要な処理を提供するサービスである。
【0080】
Close service(Mandatory;図15)
Close serviceは、ユーザプロトコル上での通信路のクローズ時に必要な処理を提供するサービスである。
【0081】
Read service(Mandatory;図15)
Read serviceは、ユーザプロトコル上で、接続先のデータを取得する際に必要な処理を提供するサービスである。
【0082】
Write service(Mandatory;図15)
Write serviceは、ユーザプロトコル上で、接続先にデータを送信する際に必要な処理を提供するサービスである。
【0083】
以上のように、Open service、Close serviceは、PCLコモン102aによる上位プロトコルの初期化処理に対応する処理である。また、Read service、Write serviceは、ユーザアプリケーション100によるデータの送信、受信に関する処理である。
【0084】
User customize service(Option;図15)
上述のサービスに該当しないサービスであり、装置を構成するユーザが独自のサービスとして定義できるものである。通信路を“開く(Open)”、“閉じる(Close)”、データを“送る(Write)”、“受ける(Read)”以外の部分は、JETデバイスを構成するユーザが自由に設定できるカスタマイズ領域とされ、例えばユーザアプリケーション100の種類(Windows, Linux等)に応じて、ユーザが自由に設定することができる。但し、どのアプリケーションを使用した場合でも、上述のようにPCLコモン102aによる“Start”、“End”は必要であり、全てのJETデバイスで共通である。
【0085】
以上説明したように本実施形態によれば、ユーザアプリケーション100のプロトコルを変換するPCL102を設け、各通信装置に共通に設けられたPCLコモン102aにより、ユーザアプリケーション100の1又は複数のプロトコルの中から通信相手のプロトコルと一致するプロトコルが選択される。そして、選択されたプロトコルが物理層108で通信を行うためのプロトコルに変換されるため、通信相手のユーザアプリケーション100のプロトコルに応じて通信に最適なプロトコルを選択することが可能となり、通信の互換性を確保することができる。なお、上述した例では、無線通信システムを例に挙げて説明したが、通信システムは有線のものであってもよい。
【0086】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【0087】
【図1】本実施形態の無線通信システムを構成する2つの機器を示す模式図である。
【図2】イニシエータ、レスポンダーの各機器の構成を階層構造として示した模式図である。
【図3】イニシエータ、レスポンダーにおけるデータの流れを示す模式図である。
【図4】図2の構成をOSI参照モデルで示した模式図である。
【図5】機器内の各レイヤーにおけるファイル、データの送受信のデータフローを示す模式図である。
【図6】CSDUによる論理的なチャネルを示す模式図である。
【図7】CSDUがマッピングされる様子を示す模式図である。
【図8】機器のハードウェア構成を示す模式図である。
【図9】各レイヤーが提供するサービスのアクセスポイントと、レイヤー間の関係を示す模式図である。
【図10】本実施形態のシステムにおける状態遷移を示す模式図である。
【図11】ネゴシエーションの処理を示す模式図である。
【図12】PCLバージョン情報を説明するための模式図である。
【図13】エミュレーション選択のシーケンスを示す模式図である。
【図14】PCLエミュレーションのサービスを示す模式図である。
【図15】PCLエミュレーションのサービスを示す模式図である。
【符号の説明】
【0088】
100 ユーザアプリケーション
102 PCL
102a PCLコモン
102b PCLエミュレーション
108 物理層
210 CPU
【特許請求の範囲】
【請求項1】
他の通信相手との間で信号の送受信を行う物理層と、
上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、
前記プロトコル変換部は、
互いに通信可能な各装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、
前記上位アプリケーションの1又は複数のプロトコルに対応して設けられ、前記共通処理部により前記1又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含むことを特徴とする、通信装置。
【請求項2】
前記共通処理部は、少なくとも前記プロトコル変換の起動、停止を含む基本動作を行うことを特徴とする、請求項1に記載の通信装置。
【請求項3】
前記共通処理部は、前記通信相手とのネゴシエーションの結果に応じて、前記1又は複数のプロトコルの中から前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択することを特徴とする、請求項1に記載の通信装置。
【請求項4】
前記共通処理部は、前記1又は複数のプロトコルの中に、前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが存在しなかった場合は、当該通信相手との接続を行わないことを特徴とする、請求項3に記載の通信装置。
【請求項5】
前記共通処理部は、通信相手とのネゴシエーションの結果に応じて、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致するか否かを判定するバージョンチェック機能を備えることを特徴とする、請求項1に記載の通信装置。
【請求項6】
前記共通処理部は、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致しなかった場合は、当該通信相手との接続を行わないことを特徴とする、請求項5に記載の通信装置。
【請求項7】
前記物理層は、前記変換処理部でプロトコルが変換されたデータに対してデータの種別を表すプロファイルIDが付されたデータを通信相手との間で通信することを特徴とする、請求項1に記載の通信装置。
【請求項8】
通信装置同士が通信を行う通信システムであって、
前記通信装置は、
通信相手となる通信装置の間で信号の送受信を行う物理層と、
上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、
前記プロトコル変換部は、
互いに通信可能な各通信装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、
前記上位アプリケーションの1又は複数のプロトコルに対応して設けられ、前記共通処理部により前記1又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含むことを特徴とする、通信システム。
【請求項9】
通信装置同士が通信を行う通信方法であって、
前記通信装置が通信相手となる他の通信装置との間でプロトコル情報を交換するステップと、
前記プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択するステップと、
選択されたプロトコルを通信相手と通信するためのプロトコルに変換するステップと、
を備えることを特徴とする、通信方法。
【請求項10】
通信相手となる他の通信装置との間でプロトコル情報を交換する手段、
前記プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択する手段、
選択されたプロトコルを通信相手と通信するためのプロトコルに変換する手段、
としてコンピュータを機能させるためのプログラム。
【請求項1】
他の通信相手との間で信号の送受信を行う物理層と、
上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、
前記プロトコル変換部は、
互いに通信可能な各装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、
前記上位アプリケーションの1又は複数のプロトコルに対応して設けられ、前記共通処理部により前記1又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含むことを特徴とする、通信装置。
【請求項2】
前記共通処理部は、少なくとも前記プロトコル変換の起動、停止を含む基本動作を行うことを特徴とする、請求項1に記載の通信装置。
【請求項3】
前記共通処理部は、前記通信相手とのネゴシエーションの結果に応じて、前記1又は複数のプロトコルの中から前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択することを特徴とする、請求項1に記載の通信装置。
【請求項4】
前記共通処理部は、前記1又は複数のプロトコルの中に、前記通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルが存在しなかった場合は、当該通信相手との接続を行わないことを特徴とする、請求項3に記載の通信装置。
【請求項5】
前記共通処理部は、通信相手とのネゴシエーションの結果に応じて、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致するか否かを判定するバージョンチェック機能を備えることを特徴とする、請求項1に記載の通信装置。
【請求項6】
前記共通処理部は、前記プロトコル変換部のソフトウェアのバージョンが、通信相手が備えるプロトコル変換部のソフトウェアのバージョンと一致しなかった場合は、当該通信相手との接続を行わないことを特徴とする、請求項5に記載の通信装置。
【請求項7】
前記物理層は、前記変換処理部でプロトコルが変換されたデータに対してデータの種別を表すプロファイルIDが付されたデータを通信相手との間で通信することを特徴とする、請求項1に記載の通信装置。
【請求項8】
通信装置同士が通信を行う通信システムであって、
前記通信装置は、
通信相手となる通信装置の間で信号の送受信を行う物理層と、
上位アプリケーションと前記物理層との間を接続するプロトコル変換部とを備え、
前記プロトコル変換部は、
互いに通信可能な各通信装置に共通に設けられ、プロトコル変換のための基本処理を行う共通処理部と、
前記上位アプリケーションの1又は複数のプロトコルに対応して設けられ、前記共通処理部により前記1又は複数のプロトコルの中から選択されたプロトコルを前記物理層で通信するためのプロトコルに変換する変換処理部と、を含むことを特徴とする、通信システム。
【請求項9】
通信装置同士が通信を行う通信方法であって、
前記通信装置が通信相手となる他の通信装置との間でプロトコル情報を交換するステップと、
前記プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択するステップと、
選択されたプロトコルを通信相手と通信するためのプロトコルに変換するステップと、
を備えることを特徴とする、通信方法。
【請求項10】
通信相手となる他の通信装置との間でプロトコル情報を交換する手段、
前記プロトコル情報に基づいて、上位アプリケーションの1又は複数のプロトコルの中から、通信相手が備える上位アプリケーションのプロトコルと一致するプロトコルを選択する手段、
選択されたプロトコルを通信相手と通信するためのプロトコルに変換する手段、
としてコンピュータを機能させるためのプログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【公開番号】特開2009−163361(P2009−163361A)
【公開日】平成21年7月23日(2009.7.23)
【国際特許分類】
【出願番号】特願2007−340440(P2007−340440)
【出願日】平成19年12月28日(2007.12.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.リナックス
2.Linux
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
【公開日】平成21年7月23日(2009.7.23)
【国際特許分類】
【出願日】平成19年12月28日(2007.12.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.リナックス
2.Linux
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
[ Back to top ]