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

Abstract

【課題】データサイズの大きな通信を行う場合においても、データの転送効率を向上することが可能な通信装置を提供すること。
【解決手段】他の通信相手との間で信号の送受信を行う物理層１０８と、上位のユーザアプリケーション１００と物理層１０８との間を接続するデータ移送部（ＤＴＬ１０４）とを備え、ＤＴＬ１０４は、ユーザアプリケーション１００からの指示に基づいて、送信データファイルに対してデータファイルの種別を表すプロファイルＩＤを付加するプロファイルＩＤ付加部を含み、プロファイルＩＤが付されたデータファイルを、物理層１０８を介して連続的に送信する。
【選択図】図６

Description

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

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

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

近時においては、通信装置に多種の上位アプリケーションが搭載されることが想定され、通信装置側で各種の上位アプリケーションに対応する必要がある。しかしながら、例えば上位アプリケーションがＵＳＢの場合のパケット転送では、図２２に示すように、ホストからターゲットへのデータ転送時に、１Ｋバイトのデータ毎にトークンパケット、データパケット、ハンドシェイクパケットを組み合わせたトランザクションを発行する必要があった。このため、大きなサイズのデータを送信する際に、実際に送信したいデータパケット以外の、トークンパケット、ハンドシェイクパケットの通信が多くなるという問題が生じる。このため、データ転送量が増大し、データの転送速度を落としてしまうという問題があった。また、ＵＳＢの場合はハンドシェイクパケットによりデータファイルの終端を検知するため、終端検知のためにはハンドシェイクパケットの送受信が不可欠であり、データ転送量が増大するという問題があった。

また、上位アプリケーション層（ＦＴＰ）でのファイル転送では、ファイル全体の転送が完了したか否かについて、上位アプリケーション層でＥＯＦ(end-of-file)を検出することによりファイルの終端を知ることができる。しかしながら、下位層であるＴＣＰ層ではトランザクション単位でデータ転送を行うため、上記と同様のハンドシェイクが発生しており、上記ＵＳＢと同様にデータ転送量が増大してしまうという問題があった。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、データサイズの大きな通信を行う場合においても、データの転送効率を向上することが可能な、新規かつ改良された通信装置、通信システム、通信方法及びプログラムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、他の通信相手との間で信号の送受信を行う物理層と、上位層と前記物理層との間を接続するデータ移送部とを備え、前記データ移送部は、前記上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報を付加する識別情報付加部を含み、前記物理層は、前記識別情報が付されたデータを連続的に送受信する通信装置が提供される。

上記構成によれば、物理層により他の通信相手との間で信号の送受信が行われ、データ移送部により上位層と物理層との間が接続される。データ移送部には、上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報を付加する識別情報付加部が含まれる。そして、識別情報が付されたデータは、物理層により連続的に送受信される。識別情報が付加されたデータを物理層が連続的に送受信することで、トランザクション単位での送信が不要となり、データの転送効率を向上することが可能となる。

また、前記データ移送部は、前記物理層を介して受信したデータから前記識別情報を取得して受信データの種別を認識する識別情報取得部を含むものであってもよい。かかる構成によれば、識別情報から受信データの種別を認識することができる。

また、前記識別情報は、送信データに続きがあること、送信データが最後のデータであること、又は送信データが前記データ移送部を制御するための制御コマンドであること、を示す情報であってもよい。かかる構成によれば、データを受信した通信相手側では、識別情報に基づいて、送信データに続きがあること、送信データが最後のデータであること、又は送信データがデータ移送部を制御するための制御コマンドであること、を認識することができる。

また、前記データ移送部は、前記識別情報取得部により最後のデータであることを示す識別情報が取得された場合に、ファイル受信完了通知を前記上位層に通知するファイル受信完了通知部を含むものであってもよい。かかる構成によれば、最後のデータであることを示す識別情報が取得された場合に、ファイル受信完了通知が通知されるため、上位層側では通信が終了することを認識できる。

また、前記データ移送部は、前記識別情報取得部により送信データに続きがあることを示す識別情報が取得された場合に、所定時間内に次のデータを受信しなかった場合は、エラー通知を前記上位層に通知するエラー通知部を含むものであってもよい。かかる構成によれば、送信データに続きがある場合において、所定時間内に次のデータを受信しなかった場合はエラー通知が上位層に通知されるため、上位アプリケーション側ではエラーが発生したことを認識できる。

また、上記課題を解決するために、本発明の別の観点によれば、通信装置同士が通信を行う通信システムであって、前記通信装置は、他の通信相手との間で信号の送受信を行う物理層と、上位層と前記物理層との間を接続するデータ移送部とを備え、前記データ移送層は、前記上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報を付加する識別情報付加部と、前記物理層を介して受信したデータから前記識別情報を取得して受信データの種別を認識する識別情報取得部と、を含み、前記識別情報が付されたデータを、前記物理層を介して送受信する通信システムが提供される。

上記構成によれば、通信装置同士が通信を行う通信システムにおいて、通信装置では、物理層により他の通信相手との間で信号の送受信が行われ、データ移送部により上位層と物理層との間が接続される。データ移送部には、上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報を付加する識別情報付加部が含まれる。そして、識別情報が付されたデータは、物理層を介して連続的に送信される。識別情報が付加されたデータを連続的に送信することで、トランザクション単位での送信が不要となり、データの転送効率を向上することが可能となる。

また、上記課題を解決するために、本発明の別の観点によれば、他の通信相手との間で信号の送受信を行う物理層と、上位層と前記物理層との間を接続するデータ移送部とを備える通信装置における通信方法であって、前記上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報を付加するステップと、前記識別情報が付されたデータを、前記物理層を介して他の通信装置に連続的に送信するステップと、を備える通信方法が提供される。

上記構成によれば、他の通信相手との間で信号の送受信を行う物理層と、上位層と物理層との間を接続するデータ移送部とを備える通信装置における通信方法において、上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報が付加され、識別情報が付されたデータは、物理層を介して他の通信装置へ連続的に送信される。従って、識別情報が付加されたデータを連続的に送信することで、トランザクション単位での送信が不要となり、データの転送効率を向上することが可能となる。

また、上記課題を解決するために、本発明の別の観点によれば、他の通信相手との間で信号の送受信を行う物理層と、上位層と前記物理層との間を接続するデータ移送部とを備える通信装置におけるプログラムであって、前記上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報を付加する手段、前記識別情報が付されたデータを、前記物理層を介して他の通信装置に送信する手段、としてコンピュータを機能させるためのプログラムが提供される。

上記構成によれば、他の通信相手との間で信号の送受信を行う物理層と、上位層と物理層との間を接続するデータ移送部とを備える通信装置におけるプログラムにおいて、上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報が付加され、識別情報が付されたデータは、物理層を介して他の通信装置へ連続的に送信される。従って、識別情報が付加されたデータを連続的に送信することで、トランザクション単位での送信が不要となり、データの転送効率を向上することが可能となる。

本発明によれば、データサイズの大きな通信を行う場合においても、データの転送効率を向上することが可能となる。

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

本実施形態の無線通信システムは、一対の機器の間でデータを送受信することを目的とした通信方式であり、近距離の機器間で無線によりデータの送受信を行う。図１は、本実施形態の無線通信システムを構成する２つの機器（通信装置）を示す模式図である。２つの機器は、それぞれレスポンダー(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の単位でデータ転送を行う。ＤＴＬ１０４はCSDU送信時に以下の３種類のプロファイルＩＤ(T_DATA, LT_DATA, CNL_DATA)をCSDUに対して付与する。さらに、CSDU受信時は、プロファイルＩＤの種類に応じた処理を行う。

T_DATA, LT_DATA
DTL１０４は、ユーザデータを転送するCSDUに対して、T_DATA(Profile ID=0)を付与する。ただし、CSDUペイロードへの分割において、最終のCSDUとなる場合にはLT_DATA(Profile ID=2)を付与する。CSDUのペイロードには、ユーザデータのみが格納され、ＤＴＬ１０４がヘッダ情報などを埋め込むことはない。

CNL_DATA
ＤＴＬ１０４は、JETシステム固有の制御データを転送するCSDUに対して、CNL_DATA(Profile ID=1)を付与する。制御データの例としては、パラメータ情報などがある。

CSDUペイロードにはヘッダ情報(詳細はTBD)が埋め込まれる。ＤＴＬ１０４はこのヘッダ情報を解釈し、適切な処理を行う。ＣＮＬ１０６は、上位のＤＴＬ１０４の要求に応じて、物理層１０８のサービスを利用した通信を行う他、物理層１０８の接続の確立、切断、データの連続性の保障などを行う。

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

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

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

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

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

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

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

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

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

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

図８に示すように、ＤＴＬ１０４は、上述したプロファイルＩＤを付加するプロファイルＩＤ付加部１０４ａ、受信データ中からプロファイルＩＤを取得するプロファイルＩＤ取得部１０４ｂ、正常にファイルの受信を完了した場合にその旨を通知するファイル受信完了通知部１０４ｃ、及び送信エラー（通信断）が発生した場合にエラーを通知するエラー通知部１０４ｄを備えている。

次に、上述したプロファイルＩＤ(Profile ID)と、これに伴う処理について説明する。図７で説明したように、ＤＴＬ１０４は、ＣＳＤＵペイロードにＣＳＤＵヘッダーを付加する。ＣＳＤＵヘッダーは、プロファイルＩＤとデータサイズ(Data Length)からなる。プロファイルＩＤは、０，１，２のいずれかの値に設定される。

プロファイルＩＤの値は、上層から送られたデータの種別を表している。プロファイルＩＤ＝０の場合は、送信データに続きがある場合を示している。また、プロファイルＩＤ＝１の場合は、ＤＴＬコマンドを送信していることを示している。また、プロファイルＩＤ＝２の場合は、送信データの最後であることを示している。

図９〜図１１は、送信データのパケットを示す模式図である。ここで、図９はプロファイルＩＤ＝０の場合、図１０はプロファイルＩＤ＝２の場合、図１１はプロファイルＩＤ＝１の場合をそれぞれ示している。

図９〜図１１に示すように、プロファイルＩＤは、ＣＳＤＵヘッダー中のサブＣＮＬヘッダー(Sub CNL Header)の中のデータヘッダー(DATA Header)の中にデータサイズ(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デバイス間で交換されるＪＥＴバージョン内のＰＣＬバージョン情報から、互いに適合するエミュレーションを持っているかを確認する。

図１８は、ＪＥＴバージョン情報を説明するための模式図である。ＰＣＬ１０２は、自機のバージョン情報と、接続先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 (8)

1. 他の通信相手との間で信号の送受信を行う物理層と、
   上位層と前記物理層との間を接続するデータ移送部とを備え、
   前記データ移送部は、
   前記上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報を付加する識別情報付加部を含み、
   前記物理層は、前記識別情報が付されたデータを連続的に送受信することを特徴とする、通信装置。
2. 前記データ移送部は、前記物理層を介して受信したデータから前記識別情報を取得して受信データの種別を認識する識別情報取得部を含むことを特徴とする、請求項１に記載の通信装置。
3. 前記識別情報は、送信データに続きがあること、送信データが最後のデータであること、又は送信データが前記データ移送部を制御するための制御コマンドであること、を示す情報であることを特徴とする、請求項１に記載の通信装置。
4. 前記データ移送部は、前記識別情報取得部により最後のデータであることを示す識別情報が取得された場合に、ファイル受信完了通知を前記上位層に通知するファイル受信完了通知部を含むことを特徴とする、請求項３に記載の通信装置。
5. 前記データ移送部は、前記識別情報取得部により送信データに続きがあることを示す識別情報が取得された場合に、所定時間内に次のデータを受信しなかった場合は、エラー通知を前記上位アプリケーションに通知するエラー通知部を含むことを特徴とする、請求項２に記載の通信装置。
6. 通信装置同士が通信を行う通信システムであって、
   前記通信装置は、
   他の通信相手との間で信号の送受信を行う物理層と、
   上位層と前記物理層との間を接続するデータ移送部とを備え、
   前記データ移送層は、
   前記上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報を付加する識別情報付加部と、
   前記物理層を介して受信したデータから前記識別情報を取得して受信データの種別を認識する識別情報取得部と、を含み、
   前記識別情報が付されたデータを、前記物理層を介して連続的に送受信することを特徴とする、通信システム。
7. 他の通信相手との間で信号の送受信を行う物理層と、上位層と前記物理層との間を接続するデータ移送部とを備える通信装置における通信方法であって、
   前記上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報を付加するステップと、
   前記識別情報が付されたデータを、前記物理層を介して他の通信装置に連続的に送信するステップと、
   を備えることを特徴とする、通信方法。
8. 他の通信相手との間で信号の送受信を行う物理層と、上位層と前記物理層との間を接続するデータ移送部とを備える通信装置におけるプログラムであって、
   前記上位層からの指示に基づいて、送信データに対してデータの種別を表す識別情報を付加する手段、
   前記識別情報が付されたデータを、前記物理層を介して他の通信装置に送信する手段、
   としてコンピュータを機能させるためのプログラム。
   

Images