JP4028539B2 - データ通信装置及びデータ通信方法 - Google Patents

データ通信装置及びデータ通信方法 Download PDF

Info

Publication number
JP4028539B2
JP4028539B2 JP2004265827A JP2004265827A JP4028539B2 JP 4028539 B2 JP4028539 B2 JP 4028539B2 JP 2004265827 A JP2004265827 A JP 2004265827A JP 2004265827 A JP2004265827 A JP 2004265827A JP 4028539 B2 JP4028539 B2 JP 4028539B2
Authority
JP
Japan
Prior art keywords
obex
request
packet
protocol stack
expected value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004265827A
Other languages
English (en)
Other versions
JP2006081112A (ja
Inventor
村 卓 也 川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2004265827A priority Critical patent/JP4028539B2/ja
Publication of JP2006081112A publication Critical patent/JP2006081112A/ja
Application granted granted Critical
Publication of JP4028539B2 publication Critical patent/JP4028539B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Description

本発明は、要求及び応答方式である通信プロトコルを利用してデータの交換を行うデータ通信装置及びデータ通信方法に関する。
Bluetooth SIG(Special Interest Group)によって規格化されているBluetoothＴＭと呼ばれる無線通信方式の仕様（http://www.bluetooth.orgより取得可能）では、無線デバイス、通信プロトコル及びアプリケーションモデルまでを規定している。アプリケーションモデルの仕様はプロファイルと呼ばれる。例えば、ファイル転送方法、電子名刺情報の交換方法、写真電子画像の交換方法等はそれぞれFile Transfer Profile、Object Push Profile、 Basic Imaging Profileと呼ばれる。各プロファイルでは、それぞれデータ交換に関する仕様が規定されている。
File Transfer Profile、Object Push Profile、 Basic Imaging Profileといったプロファイルは、OBEXと呼ばれる通信プロトコルを利用して電子情報の交換を行うことを特徴としている。OBEXプロトコルは、電子情報をオブジェクトとして交換する方法を規定した通信プロトコルであって、コネクション設定機能、コネクション切断機能、オブジェクト送信機能、オブジェクト受信機能等を有する。OBEXの詳細は、「Infrared Data Association, IrDA Object Exchange Protocol (IrOBEX) with Published Errata, Version 1.2, April 1999.」に記述されている。現在、OBEXで規定されているコマンドを記すと以下の通りである。

コマンド 意味
Connect choose your partner, negotiate capabilities
Disconnect signal the end of the session
Put send an object
Get get an object
SetPath modifies the current path on the receiving side
Abort abort the current operation

なお、上述のコネクションという表現は、意味フィールドのsession（セッション）と同じ意味であり、以降もセッションとコネクションの両方の表現を用いる。
特開２００４−４８２８０公報
OBEXプロトコルでは、通信シーケンスが、要求（Request）及び応答（Response）方式であり、一つのOBEXセッション（コネクション）において、ある要求パケットを送信した後、それに対する応答パケットを受信するまで、次の要求パケットを送信することができない。一方サーバ側では、要求パケットを受信してから次に応答パケットを送信するまでには処理時間が必要となる。また、クライアント側の処理において、応答パケットを受信してから次の要求パケットを送信するまたの処理時間が無視できない場合もある。従って、通信路の伝送速度が速い場合には、クライアントが要求パケットを送信してから次の要求パケットを送信するまでの時間において、サーバにおける処理、また、クライアにおける処理の時間が占める割合が大きくなる可能性がある。
このようにOBEXプロトコルでは、要求パケットを送信した後、次の要求パケットを送信できるまでの待ち時間が存在することから転送効率が悪く、小さなオブジェクトの送受信には向くが、大きな情報の送受信では転送効率の悪さが目立つ。
OBEXプロトコルの転送効率を上げる方法として、Pi Huang等による「“OBEX Performance Evaluation and Parameter Optimization for High Speed IrDA Links” (Submitted to IEEE ICC 2004)」が提案されている。
Pi Huang等の提案では、OBEXのパケットサイズを最適なサイズにして送信することで転送効率が上がるとされる。なお、現在のOBEXの要求及び応答方式ではなく、バースト的にデータを連続して送信する方式を採用することでも転送効率はかなり向上する。バースト的に送信する方法として,「“赤外線通信技術による高速バースト転送方式(IrBurst)の一提案”, 2002年電子情報通信学会総合大会B-6-45(2002年3月)」、や 「”赤外線通信方式における転送効率向上に関する一検討”, 2003年情報処理学会 全国大会(2003年3月)」などの提案がある。
しかし、転送効率を上げるためにOBEXのパケットサイズを最適に設定する方法では、必ずしも最適な値を設定できる補償はない。それは、例えば、実装の際に、その通信機器の送信バッファや受信バッファのサイズが制限され、設定可能なパケットサイズに限界が生じるからである。
本発明の目的は、要求及び応答方式の通信プロトコルを利用しつつも効率的なデータ転送を行うことを可能としたデータ通信装置及びデータ通信方法を提供することにある。
本発明の一態様に従ったデータ通信装置は、ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第Ｎ層に備えたデータ通信装置であって、前記第N層のプロトコルスタックを処理するプロトコルスタック処理手段と、前記プロトコルスタック処理手段が、前記第Ｎ層の下位の第Ｎ−１層によって提供されるサービスアクセスポイントを介して所定長の要求パケットを送出してから、前記要求パケットの要求先に前記第N層の通信プロトコルとしての処理を受けるまでに要する時間の期待値を第１の期待値として格納する第１の期待値格納手段と、要求先に前記第N層の通信プロトコルとして前記要求パケットが受け入れられてから、該要求パケットに対する応答パケットが前記第N層の通信プロトコルに従って送出されるまでの時間の期待値を第２の期待値として格納する第２の期待値格納手段と、を有し、前記第１の期待値と前記第２の期待値とに基づいて、前記第Ｎ−１層によって提供される前記サービスアクセスポイントに設定すべき前記第Ｎ層におけるコネクション数を計算する多重度計算手段を備える。
本発明の一態様に従ったデータ通信装置は、ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第Ｎ層に備えたデータ通信装置であって、前記第N層のプロトコルスタックを処理するプロトコルスタック処理手段と、前記プロトコルスタック処理手段が行った要求に対する、該要求の要求先からの前記第N層の通信プロトコルによる所定長の応答パケットが送出されてから、前記プロトコルスタック処理手段が該応答パケットを受け取るまでの時間の期待値を第１の期待値として格納する第１の期待値格納手段と、前記プロトコルスタック処理手段が前記応答パケットを受け取ってから前記応答パケットに対応してさらなる要求パケットを送出するまでの時間の期待値を第２の期待値として格納する第２の期待値格納手段と、を有し、前記第１の期待値と前記第２の期待値とに基づいて、前記第Ｎ層の下位の第Ｎ−１層によって提供されるサービスアクセスポイントに設定すべき前記第Ｎ層におけるコネクション数を計算する多重度計算手段を備える。
本発明の一態様に従ったデータ通信装置は、ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第Ｎ層に備えたデータ通信装置であって、前記第N層のプロトコルスタックを処理するプロトコルスタック処理手段と、前記プロトコルスタック処理手段が、前記第N層の下位の第Ｎ−１層によって提供されるサービスアクセスポイントを介して所定長の要求パケットを送信してから、該要求パケットの要求先から該要求パケットに対する前記通信プロトコルによる応答パケットを受信したことを受けて次の要求パケットを送信するまでの合計時間において、前記第Ｎ−１層以下のプロトコルスタックを処理するために必要な時間の期待値を第１の期待値として格納する第１の期待値格納手段と、前記合計時間に含まれる第Ｎ層のプロトコルスタックを処理するために必要な時間の期待値を第２の期待値として格納する第２の期待値格納手段と、を有し、前記第１の期待値と前記第２の期待値とに基づいて、前記第Ｎ−１層によって提供される前記サービスアクセスポイントに設定すべき前記第Ｎ層におけるコネクション数を計算する多重度計算手段を備える。
本発明の一態様に従ったデータ通信方法は、ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第N層として用いるデータ通信方法であって、前記第Ｎ層の通信プロトコルを処理するプロトコルスタックから、該第Ｎ層の下位のプロトコルスタックである第Ｎ−１層によって提供されるサービスアクセスポイントを介して所定長の要求パケットを送出してから、前記要求パケットが該要求パケットの要求先に前記第N層の通信プロトコルとして処理を受けるまでに要する時間の期待値と、要求先に前記第N層の通信プロトコルとして前記要求パケットが受け入れられてから、該要求パケットに対する応答パケットが前記第N層の通信プロトコルに従って送出されるまでの時間の期待値とに基づいて、前記第Ｎ−１層によって提供される前記サービスアクセスポイントに設定する前記第Ｎ層におけるコネクション数を計算することを特徴とする。
本発明の一態様に従ったデータ通信方法は、ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第Ｎ層として用いるデータ通信方法であって、前記要求の要求先からの前記第N層の通信プロトコルによる所定長の応答パケットが送出されてから、該応答パケットが前記第N層の通信プロトコルを処理するプロトコルスタックに到達するまでの時間の期待値と、前記第Ｎ層の通信プロトコルを処理するプロトコルスタックが前記応答パケットを受け取ってから前記応答パケットに対応してさらなる要求パケットを送出するまでの時間の期待値とに基づいて、前記第Ｎ層の下位の第Ｎ−１層によって提供されるサービスアクセスポイントに設定すべき前記第Ｎ層におけるコネクション数を計算することを特徴とする。
本発明の一態様に従ったデータ通信方法は、ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第Ｎ層として用いるデータ通信方法であって、前記第N層の通信プロトコルを処理するプロトコルスタックから、前記第N層の下位のプロトコルスタックである第Ｎ−１層によって提供されるサービスアクセスポイントを介して所定長の要求パケットを送出してから、該要求パケットの要求先から該要求パケットに対する前記通信プロトコルによる応答パケットを受信したことを受けて次の要求パケットを送信するまでの合計時間において、前記第Ｎ−１層以下のプロトコルスタックを処理するために必要な時間の期待値と、前記合計時間に含まれる第Ｎ層のプロトコルスタックを処理するために必要な時間の期待値とに基づいて、前記第Ｎ−１層によって提供される前記サービスアクセスポイントに設定すべき前記第Ｎ層におけるコネクション数を計算することを特徴とする。
本発明により、要求及び応答方式の通信プロトコルを利用しつつも効率的なデータ転送を行うことができる。
まず、OBEXプロトコルについて簡単に説明する。
OBEXプロトコルは、電子情報をオブジェクトとして交換する方法を規定した通信プロトコルであり、コネクション設定機能、コネクション切断機能、オブジェクト送信機能、オブジェクト受信機能等を有する。
OBEXプロトコルのセッションモデルでは、機器をクライアント（Client）とサーバ（Server）として定義し、クライアントが発行する要求(Request)に対してサーバが応答（Response）を行う形式をとる。
図１は、OBEXのセッションモデルを示す。
OBEXセッションではクライアント１１が要求パケットを発行し、それに対しサーバ１２が応答パケットを返すことでデータ交換が行われる。
図２及び図３は、要求パケットと応答パケットの基本的なパケットフォーマットを示す。
図２に示すように、要求パケットは、その要求の種類を示すopコード（opcode）を記載するフィールド、要求パケットの長さ(packet length)を記載するフィールド、及びOBEXヘッダ（OBEX header）から構成される。一方、図３に示すように、応答パケットは、その応答の意味（成功やエラーなど）を示す応答コード（response code）を記載するフィールド、応答パケットの長さを記載するフィールド、及びOBEX ヘッダから構成される。なお、OBEXセッションの構築（接続）処理時は、３から６バイト目にOBEXのバージョン番号、最大OBEXパケットサイズ等の情報が付加され、OBEX ヘッダは７バイト目からとなる。図４及び図５に、opコードの定義と、応答コードの定義の一部を示す。
OBEXで交換するオブジェクト（オブジェクト本体、オブジェクトの長さ、オブジェクトのタイプ、ファイル名、セッションの識別子など）はOBEX ヘッダとして表現される。OBEXヘッダは図６に示すようにヘッダID(HI)とヘッダ Value(HV)より構成される。OBEXヘッダのヘッダID (HI)の定義を図７に示す。
図８から図１１に、OBEXセッション構築（Connect処理）、オブジェクト送信（Put処理）、オブジェクト取得（Get処理）、OBEXセッション切断（Disconnect処理）の通信シーケンス例を示しておく。
以下、図面を参照しながら、本発明の実施の形態について、詳細に説明する。
（第１の実施の形態）
図１２は、本発明の実施の形態に従った通信機器１の構成を示す。
通信機器１はBluetoothの無線送受信機能を有する機器であり、通信プロトコルとしてOBEXを具備した機器である。
通信機器１は、BluetoothTMによる無線通信を実行するように設計された無線通信デバイス１０１と、無線通信デバイス１０１を制御しOBEXプロトコルに対して通信リンクを提供する下位プロトコルスタック部１０２と、下位プロトコルスタック部１０２を利用してOBEXプロトコルに従った動作を行うOBEX部１０３と、OBEX部１０３を利用して動作する上位アプリケーション１０４とを有する。
下位プロトコルスタック部１０２は、BluetoothTMの規格で規格化されているOBEXプロトコル以下のプロトコルスタックとして、ＲＦＣＯＭＭ，ＳＤＰ，Ｌ２ＣＡＰなどのプロトコルスタックの機能を実装する。
OBEX部１０３は下位プロトコルスタック部１０２を利用して通信相手機器におけるOBEX部とデータの送受信を行う。OBEX部１０３のデータ送受信機能は、IrOBEX（IrDA Object Exchange Protocol）のオブジェクト交換サービスの手順に従うと共に、Bluetooth Special Interest Group (SIG)によって規定されたGeneric Object Exchange Profileをサポートするように設計され実装されている。
なお、図１２では、本発明で示す機能改善を実現する上で直接影響を及ぼすことがない構成要素（例えばＣＰＵ等）は省略している。
図１３は、図１２に示す通信機器１同士が通信を行う様子を示す。より詳細には、図１３は、OBEXクライアントとして動作するクライアント機器１と、OBEXサーバとして動作するサーバ機器１’とが通信を行う様子を示す。クライアント機器１は、サーバ機器１’に対して、OBEXのセッション（コネクション）を設定し、OBEXプロトコルに従って、オブジェクトを送信または取得する。
以下、本発明の大きな特徴の１つとなるOBEX部１０３について詳細に説明する。
OBEX部１０３は、下位プロトコルスタック部１０２がOBEX部１０３に対して提供する１つのサービスアクセスポイント（Bluetoothのプロトコルスタックで説明すると、RFCOMMの提供する一本のリンク）に対して複数のOBEXのコネクションを多重化し利用することを特徴とする。多重化の様子を図１４に示す。
まず、OBEX部１０３の構成要素のうち基本構成要素についての説明を行う。
図１５及び図１６は、OBEX部１０３における基本構成要素の構成を示す図である。より詳細には、図１５はOBEXクライアントとして動作する場合におけるOBEX部の処理の流れを含み、図１６はOBEXサーバとして動作する場合におけるOBEX部の処理の流れを含む。
図１５及び図１６に示すように、特に図１５に示すように、OBEX部１０３の基本構成要素は、OBEXインタフェース１０００、OBEXクライアントエンジン２０００、OBEXサーバエンジン３０００である。
OBEXインタフェース１０００は、複数のOBEXクライアントエンジン（２００１,２００２,…であり、その中の一つを表す場合には２００Ｘと表記する）とOBEXサーバエンジン（３００１,３００２,…であり、その中の一つを表す場合には３００Ｙと表記する）の管理を行う。
OBEXインタフェース１０００は、上位アプリケーション１０４に対して、OBEXプロトコルのインタフェース（IF）関数(ConnectRequest、PutRequest、GetRequest、DisconnectRequestなど)を提供する。上位アプリケーション１０４からインタフェース関数が実行されると、OBEXインタフェース１０００は適切なOBEXクライアントエンジン２００Ｘを一つ選択し、上位アプリケーション１０４から指示された処理を命令する。
また、OBEXインタフェース１０００はパケットの受信管理を行っており下位プロトコルスタック部１０２から受信したパケットを適切なOBEXクライアントエンジン２００ＸあるいはOBEXサーバエンジン３００Ｙへと振り分けて渡す。例えば、受信したパケットが応答パケットであれば、適切なOBEXクライアントエンジン２００Ｘへと渡し、受信したパケットが要求パケットであれば、図１６に示すように、適切なOBEXサーバエンジン３００Ｙへと渡す。受信したパケットから適切なOBEXクライアントエンジン２００ＸまたはOBEXサーバエンジン３００Ｙを選択する方法については後ほど改めて説明する。
図１５に示すように、OBEXクライアントエンジン２００Ｘは、OBEXのクライアントとしての処理を実行する。OBEXインタフェース１０００からConnectRequest、PutRequest、GetRequest、DisconnectRequestなどの処理命令が入力されると、OBEXのクライアントとして適切な処理をした後に、要求パケットを生成して下位プロトコルスタック部１０２へと出力する。また、OBEXインタフェース１０００から応答パケットが入力されると、それに応じた処理を行う。上位アプリケーション１０４にステータスを通知する場合は、OBEXインタフェース１０００を介して、イベントやメッセージの通知を行う。次の要求を送信する必要があれば、別の要求パケットを生成して下位プロトコルスタック部１０２へと出力する。
図１６に示すように、OBEXサーバエンジン３００Ｙは、OBEXのサーバとしての処理を実行する。OBEXインタフェース１０００から要求パケットが入力されると、それに応じた処理を行う。上位アプリケーション１０４にステータスを通知する場合は、OBEXインタフェース１０００を介して、イベントやメッセージの通知を行う。また、OBEXサーバエンジン３００Ｙは、応答パケットを生成して下位プロトコルスタック部１０２へと出力する。
以下、OBEX部により行われる具体的な処理内容について説明する。
まず、OBEXセッション（あるいはOBEXコネクションと呼ぶ）の接続処理と切断処理について説明する。なお、以下の説明においてはクライアント機器１とサーバ機器１’とで通信を行う場合を示すが、クライアント機器１とサーバ機器１’の構成は同じであるとし、サーバ機器１’の構成要素については「’」の文字をつけて説明する。
［接続処理］
（１）OBEX部がクライアントとして動作する場合
図１５において、上位アプリケーション１０４はOBEXインタフェース１０００が用意するOBEXコネクションの設定要求(ConnectRequest)関数を実行する。その際、上位アプリケーション１０４は、相手サーバ側のアプリケーション１０４’への接続パラメータを指定する。
ConnectRequest 関数が実行されると、OBEXインタフェース １０００はそのOBEXコネクションのためにOBEXクライアントエンジン２００Ｘ を一つ割り当て、OBEXコネクションの設定処理を進める。
より詳細には、OBEXクライアントエンジン２００Ｘは、OBEXのConnectRequestパケットの送信を行う前に、下位プロトコルスタック部１０２に対して下位リンクの接続を要求する。下位プロトコルスタック部１０２による下位リンク接続完了（あるいは、既にリンクが存在していること）を検知すると、OBEXクライアントエンジン２００Ｘは接続された相手サーバへ対しConnectRequestパケットを送信する。
その後、相手サーバから成功(OK_Success)を通知するConnectResponseパケットを受信するとクライアントとしてのOBEXコネクションの設定処理が完了し、上位アプリケーション１０４に成功を通知する。
もし、相手サーバからUnauthorizedを受信した場合は、OBEX間の認証(Authentication)処理が必要となるため、認証パスワードを確認後、再度相手サーバへ対しConnectRequestパケットを送信する。
コネクションが設定されると、その設定されたコネクションを識別するためにクライアント側のOBEXインタフェース １０００はローカルコネクションＩＤという識別子を割り当てることにより、設定されたコネクションとOBEXクライアントエンジン２００Ｘとの対応を管理する。ローカルコネクションＩＤは同時に同じ値のものは存在しないように割り当てられるものとする。
上位アプリケーション１０４はOBEXインタフェース１０００からローカルコネクションＩＤの情報を取得することができる。あるいは、OBEXインタフェース１０００が上位アプリケーション１０４にローカルコネクションＩＤを通知しても良い。
（２）OBEX部がサーバとして動作する場合
図１６において、相手機器との下位プロトコルスタック部１０２’におけるリンク接続が完了した後、ConnectRequestパケットの受信をOBEXインタフェース１０００’が検知すると、OBEXインタフェース１０００’ はそのOBEXコネクションのためにOBEXサーバエンジン３００Ｙ’を一つ割り当て、OBEXコネクションの設定処理を進める。
処理の結果、OBEXサーバエンジン３００Ｙ’は相手クライアントへ対しConnectResponseパケットを送信する。相手サーバへ成功(OK_Success)を通知するConnectResponseパケットを送信した時点でサーバとしてのOBEXコネクションの設定処理が完了する。OBEXサーバエンジン３００Ｙ’は、上位アプリケーション１０４’が存在するのであれば、上位アプリケーション１０４’に対してコネクションが設定されたことを通知する。
コネクションが設定された際に、サーバはそのコネクションを管理するためのコネクションＩＤを内部にて割り当て、それをConnectResponseパケットに含めてクライアント側の機器へと渡す。
コネクションＩＤは同時に同じ値のコネクションＩＤは存在しないものとし、OBEXインタフェース１０００’は、割り当てられたコネクションＩＤとOBEXサーバエンジン３００Ｙ’との対応を管理する。
なお、上記で説明したサーバ側で割り当てるコネクションＩＤとクライアント側で割り当てるローカルコネクションＩＤはそれぞれの機器において決められるものであり、必ずしも等しい値ではない。
［切断処理］
（１）OBEX部がクライアントとして動作する場合
図１５において、上位アプリケーション１０４はOBEXインタフェース１０００が用意するOBEXコネクションの切断要求(DisconnectRequest)関数を実行する。その際、上位アプリケーション１０４は、ローカルコネクションＩＤを指定する。
DisconnectRequest関数が実行されると、OBEXインタフェース１０００ はローカルコネクションＩＤから対応するOBEXクライアントエンジン ２００Ｘを選択し、OBEXコネクションの切断処理を進める。
すなわち、OBEXクライアントエンジン２００Ｘは相手サーバへ対しDisconnectRequestパケットを送信し、相手サーバからDisconnectResponseパケットを受信した時点でクライアントとしてのOBEXコネクションの切断処理が完了する。
ここで、DisconnectRequestパケットには、ローカルコネクションＩＤではなく、サーバ側で設定されたコネクションＩＤが含まれている。なお、OBEXコネクションの切断処理が完了した際に、下位プロトコルスタック部１０２のリンクについても一緒に切断しても良い。
（２）OBEX部がサーバとして動作する場合
図１６において、DisconnectRequestパケットの受信をOBEXインタフェース１０００’が検知すると、OBEXインタフェース１０００’ はコネクションＩＤに対応するOBEXサーバエンジン３００Ｙ’を選択し、OBEXコネクションの切断処理を進める。
処理の結果、OBEXサーバエンジン３００Ｙ’は相手クライアントへ対しDisconnectResponseパケットを送信する。相手サーバへ成功(OK_Success)を通知するDisconnectResponseパケットを送信した時点でサーバとしてのOBEXコネクションの切断処理が完了する。上位アプリケーション１０４’が存在するのであれば、上位アプリケーション１０４’に対してコネクションが切断されたことを通知する。
次に、上述したOBEXセッション（OBEXコネクション）の接続処理及び切断処理以外の要求処理(オブジェクトの送信または取得)とそれに対応する応答処理とについて説明する。
[オブジェクトの送信要求処理または取得要求処理]
以下、OBEX部が、クライアントとして相手サーバに諸要求を行う場合の処理について説明する。
図１５において、相手サーバに諸要求を行う場合、上位アプリケーション１０４はOBEXインタフェース１０００が用意するOBEXコネクションの要求関数のうちから適切な要求(XXXRequest)関数を実行する。その際、上位アプリケーション１０４は、ローカルコネクションＩＤを指定するものとし、また、それぞれの要求関数毎に定められたパラメータを入力する。
XXXRequest関数が実行されると、OBEXインタフェース１０００ はローカルコネクションＩＤから対応するOBEXクライアントエンジン ２００Ｘを選択し処理を進める。
すなわち、OBEXクライアントエンジン２００ＸはOBEXのXXXRequestパケット送信を行う。このXXXRequestパケットはサーバ側のコネクションIDを含む。その後、相手サーバから成功(OK_Success)を通知するXXXResponseパケットを受信、あるいは、エラーを通知するXXXResponseパケットを受信すると、要求送信処理が完了し、上位アプリケーション１０４に処理の完了を通知する。OBEXクライアントエンジン２００ＸはOBEXのXXXRequestパケット送信を行った後で、継続(Continue)を通知するXXXResponseパケットを受信した場合は、OBEXクライアントエンジン２００Ｘ内部で適切な処理をした後、処理を継続するためにXXXRequestパケット送信を行う。
[オブジェクトの送信応答処理または取得応答処理]
以下、OBEX部が、サーバとして相手クライアントに対し応答を行う場合の処理について説明する。
図１６において、OBEXの要求(YYYRequest)パケットの受信をOBEXインタフェース１０００’が検知すると、OBEXインタフェース１０００’はコネクションＩＤに対応するOBEXサーバエンジン３００Ｙ’を選択し、YYYRequestに対応する処理を進める。
処理の結果、OBEXサーバエンジン３００Ｙ’は相手クライアントへ対しYYYResponseパケットを送信する。相手クライアントへ成功(OK_Success)を通知するYYYResponseパケットを送信した時点、あるいは、相手クライアントへエラーを通知するYYYResponseパケットを送信した時点でサーバとしての応答処理が完了し、上位アプリケーション１０４’が存在するのであれば、上位アプリケーションに対して処理の完了を通知する。OBEXサーバエンジン３００Ｙ’はOBEXのXXXRequestパケット受信して、OBEXサーバエンジン３００Ｙ’内部で処理を行った結果、クライアント機器側からの更なるRequestPacketを受信する必要がある場合には、継続(Continue)を通知するXXXResponseパケット送信を行う。
ここで、先に説明を省略した受信したパケットから適切なOBEXクライアントエンジン２００ＸまたはOBEXサーバエンジン３００Ｙを選択する方法について補足する。
OBEXインタフェース１０００は受信したパケットが要求パケットであるか、応答パケットであるかは、次のようにして判断する。すなわち、受信パケットの最初のバイトを確認し、その値がOBEXプロトコルの仕様で規定されたopコードの値である場合は要求パケットと判断し、応答コードの値である場合は応答パケットと判断する。
OBEXクライアントエンジン２００Ｘが、コネクションを設定するために送信するConnectRequestパケットにOBEXプロトコルの仕様で規定されたTargetヘッダが含まれている場合には、OBEXインタフェース１０００はOBEXクライアントエンジン２００Ｘとそれが送信するTargetの値とを記憶する。
OBEXプロトコルの仕様では、Targetヘッダが含まれたConnectRequestパケットを受信したサーバ側は応答として返すConnectResponseパケットにはWhoヘッダとConnectionIDヘッダとを含める。Whoヘッダの値はTargetと同じ値とし、ConnectionIDヘッダには設定したコネクションを識別するためのコネクションＩＤの値を含めることになっている。
そこで、OBEXインタフェース１０００は、サーバからConnectResponseパケットを受信した場合に、Whoヘッダに含まれる値を確認し、先に記憶しているTargetの値と比較することで、適切なOBEXクライアントエンジン２００Ｘを選択し、そこに受信したConnectResponseパケットを渡すことができる。その際に、OBEXインタフェース１０００は、OBEXクライアントエンジン２００ＸとTargetの値との対応に、更に、コネクションＩＤを追加し、OBEXクライアントエンジン２００ＸとコネクションＩＤとの対応がとれるように管理する。
OBEXサーバエンジン３００Ｙ’が送信するConnectResponseパケットには、コネクションＩＤの情報が含まれていることから、OBEXインタフェース１０００はOBEXサーバエンジン３００Ｙ’とコネクションＩＤとの対応がとれるように管理することは容易である。
本実施の形態におけるOBEX部１０３では、OBEXクライアントエンジン２０００及びOBEXサーバエンジン３０００は、Targetを指定して設定したOBEXコネクションにおいて、コネクション成立後に送信する全ての要求パケットおよび応答パケットに、必ずサーバ側で設定されたコネクションＩＤを含むConnectionIDヘッダを付加することとする。
なお、OBEXの仕様には応答パケットにConnectionIDヘッダを付加することは規定されていないが、本実施の形態のOBEX部１０３では応答パケットにもConnectionIDを付加する。これにより、例えばクライアント側が応答パケットを同時に受け取ったとしても各応答パケットを識別できる。つまり、OBEX部１０３同士で通信を行う場合、下位プロトコルスタック部１０２によって設定された一本の通信リンク上に複数のOBEXコネクションを多重化して通信を行うことができる。
OBEX部１０３の構成要素のうち基本構成要素における動作は上記に説明した通りである。すなわち、以上では、OBEXクライアントエンジン２００ＸとOBEXサーバエンジン３００Ｙ’間でコネクションを設定しオブジェクトの送信や取得などの処理を行う方法について説明した。
以下では、OBEX部１０３の詳細構成要素を説明し、下位プロトコルスタック部１０２によって設定された一本の通信リンク上に複数のOBEXのコネクションを多重化し利用する方法について説明する。すなわち、同時に複数のOBEXクライアントエンジン２００ＸとOBEXサーバエンジン３００Ｙ’を連携させながら動作させる多重化の仕組みについて説明する。
図１７は、OBEX部１０３の詳細構成を示す図である。
OBEX部１０３は、OBEXインタフェース１０００、OBEXクライアントエンジン２０００、OBEXサーバエンジン３０００に加えて、多重化処理実行部４０００と多重化処理解析部５０００とを備える。
図１８は、多重化処理実行部４０００と多重化処理解析部５０００の内部構成例を含むOBEX部１０３の詳細構成図である。
多重化処理実行部４０００におけるＴ１検出部４００１は、OBEXサーバエンジン３０００がPut要求を受信してからPut応答を送信するまでの処理時間として見込まれる期待値（例えば平均値）をＴ１秒として予め記憶する。Ｔ１検出部４００１は、当該Ｔ１を相手機器から取得して記憶してもよく、また、相手機器の性能を想定した上で所定長のデータ（例えばOBEXクライアントエンジン２０００で設定しているＰｕｔ要求の最大パケット長）を用いて当該Ｔ１の値を自ら算出して記憶してもよい。
また、多重化処理実行部４０００におけるＴ２設定部４００２は、OBEXクライアントエンジン２０００で設定しているＰｕｔ要求の最大パケット長のパケット要求を送信後、相手機器のOBEXサーバエンジン３０００へ届くまでの伝送時間として見込まれる期待値（例えば平均値）をＴ２として予め記憶する。Ｔ２設定部４００２は、当該Ｔ２の値を、通信路の伝送速度等に基づいて自ら算出して記憶してもよい。また、Ｔ２設定部４００２は、下位通信プロトコルスタック部１０４からＴ２の値を取得可能であれば、取得したＴ２の値を下位通信プロトコルスタック部１０４から取得して記憶しても良い。
多重化処理実行部４０００におけるＮ計算部４００３は、多重度ＮとしてＮ＝[Ｔ１／Ｔ２]＋１を計算するものとする。但し、[Ｔ１／Ｔ２]＋１は一例であり、例えば（[Ｔ１／Ｔ２]＋２であってもよく、本実施の形態は、Ｔ１とＴ２の比率を利用して多重度Ｎを導くことを特徴とするものである。ここで、 [ ]はガウス記号であり、[Ｔ１／Ｔ２] はＴ１／Ｔ２を超えない最大の整数値であるとする。
また、Ｎ計算部４００３は、下位プロトコルスタック部１０２が提供するＳＤＰのサービスを利用して、相手機器が自らと同じOBEX部１０３を有するか否かを判別する機能を備える。判別する方法については、例えばＳＤＰで規定されているサービスレコードに特有の情報を含め、それを検出する方法により判別可能である。
多重利用OBEXクライアントエンジン管理部４００４は、Ｎ計算部４００３から指定された多重度Ｎに基づき、必要なOBEXクライアントエンジン２０００を利用して、コネクションの設定、オブジェクトの送信、コネクションの切断などの多重処理ができるように各OBEXクライアントエンジン２０００を管理する。多重利用OBEXクライアントエンジン管理部４００４は、多重化されたコネクションに１つ割り当てられるローカルコネクションＩＤについても管理を行う。多重利用OBEXクライアントエンジン管理部４００４は、上位アプリケーション１０４からの命令を複数のOBEXクライアントエンジン２０００へ分岐して伝えるとともに、各OBEXクライアントエンジン２０００の処理の結果を統合して、上位アプリケーション１０４へ通知する。
オブジェクト分割部４００５は、送信するオブジェクトを複数に分割する機能を備える。オブジェクト分割部４００５は、上位アプリケーション１０４からオブジェクトの送信が命令された場合に、Ｎ計算部が計算した多重度Ｎの値に従い対象となるオブジェクトをＮ個に分割する。多重利用OBEXクライアントエンジン管理部４００４がオブジェクト送信命令を複数のOBEXクライアントエンジン２０００へ分岐して伝える際、各OBEXクライアントエンジン２０００が送信するオブジェクトとして、オブジェクト分割部によって分割されたオブジェクトを指定する。
多重利用OBEXサーバエンジン管理部５００１は、複数のOBEXサーバエンジン３０００を利用して、コネクションの設定、オブジェクトの送信、コネクションの切断などの多重処理ができるように各OBEXサーバエンジン３０００を管理する。多重利用OBEXサーバエンジン管理部５００１は、複数のOBEXサーバエンジン３０００がそれぞれコネクション設定処理の際に受信したConnectRequestパケットにコネクションが同一であることを示す識別情報が含まれていることを検知した場合に、多重化処理を行うOBEXサーバエンジン３０００の情報を記憶管理する。
分割オブジェクト構築部５００２は、多重利用OBEXサーバエンジン管理部５００１が管理する複数のOBEXサーバエンジン３０００で受信したオブジェクトを統合して一つのオブジェクトを構築する機能を備える。
以下、図１８に示すOBEX部を備えたクライアント機器及びサーバ機器により構成されるシステムの動作について説明する。
クライアント側における上位アプリケーション１０４がOBEX部１０３に対し、OBEXコネクションの設定要求(ConnectRequest)関数を実行した場合、多重化処理実行部４０００は、上位アプリケーション１０４が指定した相手サーバ側の上位アプリケーション１０４’への接続パラメータから、相手機器が自らと同じOBEX部１０３を有するか否かを判別する。
同じOBEX部１０３を有さないと判断した場合は、多重化処理実行部４０００は処理をスキップし、OBEXインタフェース１０００の処理として上記で説明した基本構成要素のみの場合の通りの動作を行う。
一方、同じOBEX部１０３を有すると判断した場合は、Ｎ個のOBEXクライアントエンジン２００Ｘ１,…２００ＸＮを利用し、それぞれからOBEXのConnectRequestパケット送信を行う。
このとき、送信する複数のConnectRequestパケットには、それらが本来は同一であることを示す識別情報を含めているものとする。また、Targetヘッダの値は複数のConnectRequestパケットで異なる値を設定して送信する。識別情報については、別途特別な識別情報を付加してもよいが、Targetヘッダの値を利用することで同一であることを判断することも可能である。なお、下位プロトコルスタック部１０２のリンクを設定する方法は先に述べた通りである。
一方、BEX部１０３’を有するサーバ側の機器は、クライアント側の機器から複数のConnectRequestパケットを受信し、それぞれにOBEXサーバエンジン３００Ｙ１’,….３００ＹＮ’を割り当て、独立して処理を行う。
このとき、サーバ側の多重化処理解析部５０００’は、受信した複数のConnectRequestパケットにこれらが同一であることを示す識別情報が含まれているかいないかを検出する。含まれていることを検出した場合には、それらがクライアント機器側の多重化処理実行部４０００により分離された要求であることを認識し、それらに対応づけられたOBEXサーバエンジン３００Ｙ１’,….３００ＹＮ’の情報を記憶管理する。
以上のようにOBEX部１０３においては、上位アプリケーションからの１回のOBEXコネクションの設定要求に対して複数のOBEXコネクションを設定することになる。但し、上位アプリケーション１０４へは、複数のOBEXコネクションのうち代表する一つのOBEXコネクションに割り当てられたローカルコネクションＩＤのみが提供されるものとする。
上位アプリケーション１０４がOBEX部１０３に対し、OBEXのオブジェクト送信要求(PutRequest)関数を実行した場合、多重化処理実行部４０００はPutRequestで指定されているローカルコネクションＩＤが複数のコネクションの代表であるか否かを判断する。
ローカルコネクションＩＤが複数のコネクションの代表でない場合は、多重化処理実行部４０００は処理をスキップし、OBEXインタフェース１０００の処理として上記で説明した基本構成要素のみの場合の通りの動作を行う。
ローカルコネクションＩＤが複数のコネクションの代表である場合は、多重化処理実行部４０００は、PutRequestで送信すべきオブジェクトをＮ個に分割し、Ｎ個のOBEXクライアントエンジン２００Ｘ１,…２００ＸＮを利用して並列に送信する。
OBEX部１０３’を有するサーバ側の機器は、クライアント側の機器から複数のPutRequestパケットを受信する。それぞれについてのオブジェクトの受信処理は、Ｎ個のOBEXサーバエンジン３００Ｙ１’,….３００ＹＮ’が独立して行う。それぞれのOBEXサーバエンジン３００Ｙ１’,….３００ＹＮ’が受信した分割されたオブジェクトの情報は多重化処理解析部５０００’へと通知されるものとする。
ここで、オブジェクトの分割ルールについてはサーバ側とクライアント側とで予め合意がとれているものとする。従って、クライアント側の多重化処理実行部４０００がオブジェクトを分割する際に、ブロック１、ブロック２・・・ブロックＮに分割した場合には、サーバ側の多重化処理解析部５０００’は受信したブロック1、ブロック２・・・ブロックＮから元のオブジェクトを生成できる。
また、Ｎ個のOBEXクライアントエンジン２００Ｘ１,…２００ＸＮを利用して並列に送信する場合、それぞれから送信される最初のPutRequestパケットには、オブジェクトの名前情報が含まれたNameヘッダが付加される。Nameヘッダの設定方法については、最初に送信されるN個のPutRequestパケットすべてにオリジナルのオブジェクトの名前情報を含めて送信する方法と、代表としてOBEXクライアントエンジン２００Ｘ１から送信されるPutRequestパケットのみにオリジナルのオブジェクトの名前情報を含め他のN-1個のPutRequestパケットにはオリジナルと異なる名前情報を含めて送信する方法とが考えられる。
例えば、オリジナルのオブジェクトの名前が”test.txt”であった場合、前者の方法ではN個のPutRequestパケットのNameヘッダそれぞれに”test.txt”を含めて送信する。一方、後者の方法では代表する１個のPutRequestパケットのNameヘッダに”test.txt”を含めて、他は、” 2_N”、”3_N”・・・”N_N”と簡易化して送信してもよい。
分割されたオブジェクトをサーバ側で受信し統合する際には、OBEXサーバエンジン３００Y１が受信したPutRequestパケットに含まれるNameヘッダの値からオリジナルのオブジェクトの名前を検出することで、オブジェクトを生成することが可能である。
上位アプリケーション１０４がOBEX部１０３に対し、OBEXのコネクション切断要求(DisconnectRequest)関数を実行した場合、多重化処理実行部４０００はDisconnectRequestで指定されているローカルコネクションＩＤが複数のコネクションの代表であるか否かを判断する。
ローカルコネクションＩＤが複数のコネクションの代表でない場合は、多重化処理実行部４０００は処理をスキップし、OBEXインタフェース１０００の処理として上記で説明した基本構成要素のみの場合の通りの動作を行う。
ローカルコネクションＩＤが複数のコネクションの代表である場合は、多重化処理実行部４０００は、Ｎ個のOBEXクライアントエンジン２００Ｘ１,…２００ＸＮのそれぞれからOBEXコネクションの切断処理が実行されるようにする。
一方、OBEX部１０３’を有するサーバ側の機器は、クライアント側の機器から複数のDisconnectRequestパケットを受信する。それぞれのコネクションの切断処理をＮ個のOBEXサーバエンジン３００Ｙ１’,….３００ＹＮ’が独立して行う。それぞれのOBEXサーバエンジン３００Ｙ１’,….３００ＹＮ’での切断処理の終了は多重化処理解析部５０００’へと通知されるものとする。
以上のように、本実施の形態によれば、通信機器１におけるOBEX部１０３は、上位アプリケーション１０４からの１つのコネクション設定要求に対して、内部処理として複数のOBEXコネクションを設定でき、また、オブジェクトを送信する場合に、それを分割して並列に送信することができるため、図１９に示すような通信シーケンスにより効率的なデータの送信が可能となる。従来の通信機器における通信シーケンスを示す図２０と比較しても分かるように、本実施の形態では、効率的なデータの送信が可能である。
（第２の実施の形態）
図２１は、本実施の形態におけるOBEX部の詳細構成を示す図である。
構成上、第１の実施の形態における図１８に示す構成要素との違いは、多重化処理解析部５０００がＴ３設定部５００３を備える点にある。Ｔ３設定部５００３は、Put要求を受信してからPut応答を送信するまでの処理時間を測定することが可能である。Ｔ３設定部５００３は、処理時間の平均値（あるいは期待値）をＴ３として保持し、OBEXサーバエンジン３０００に通知可能である。OBEXサーバエンジン３０００は、ConnectResponseパケットにＴ３の情報を含めて送信する。
以下、図２１のOBEX部を備えたクライアント機器及びサーバ機器により構成されるシステムの動作について説明する。
まず、クライアント側の機器において、上位アプリケーション１０４がOBEX部１０３に対し、OBEXコネクションの設定要求(ConnectRequest)関数を実行する。多重化処理実行部４０００はここでは処理をスキップし、OBEXインタフェース１０００の処理として第1の実施の形態で説明した基本構成要素のみの場合の動作を行う。すなわち、OBEXクライアントエンジン２００Ｘ１を利用して、ConnectRequestパケットを下位プロトコルスタック部１０２へ出力する。
OBEX部１０３’を有するサーバ側の機器は、クライアント側の機器からConnectRequestパケットを受信し、OBEXサーバエンジン３００Ｙ１’を割り当てて処理を行い、ConnectResponseパケットを下位プロトコルスタック部１０２’へ出力する。このConnectResponseパケットには先に記した通り、Ｔ３の情報が含まれている。
クライアント側の機器のOBEXインタフェース１０００は、Ｔ３の情報が含まれたConnectResponseパケットを受信すると、それをOBEXクライアントエンジン２００Ｘ１へ通知すると共に、Ｔ３の情報を多重化処理実行部４０００へ入力する。
多重化処理実行部４０００はＴ３の情報が入力されると、先に上位アプリケーション１０４からOBEX部１０３に対し設定が要求されたOBEXコネクションは多重化が可能であることを認識する。多重化処理実行部４０００はＴ３の値をＴ１として扱い、多重度ＮとしてＮ＝（Ｔ３／Ｔ２）＋１を計算する。
多重化処理実行部４０００は多重度Ｎの計算に成功すると、Ｎ−１個のOBEXクライアントエンジン２００Ｘ２,…２００ＸＮを利用し、それぞれからOBEXのConnectRequestパケット送信を行う。
このとき、送信する複数のConnectRequestパケットには、OBEXクライアントエンジン２００Ｘ１が設定したコネクションと同一であることを示す識別情報を含めるものとする。また、Targetヘッダの値はOBEXクライアントエンジン２００Ｘ１が利用した値とそれぞれ異なる値としてConnectRequestパケットに設定されて送信される。なお、識別情報については、別途特別な識別情報を付加してもよいが、Targetヘッダの値を利用することで上記コネクションが同一であることを判断することも可能である。
OBEX部１０３’を有するサーバ側の機器は、クライアント側の機器からＮ−１のConnectRequestパケットを受信する。サーバ側の機器は、それぞれにOBEXサーバエンジン３００Ｙ２’,….３００ＹＮ’を割り当て、各OBEXサーバエンジン３００Ｙ２’,….３００ＹＮ’はそれぞれ独立して処理を行う。
このとき、サーバ側の多重化処理解析部５０００’は、ConnectRequestパケットに含まれる識別情報から、これらのConnectRequestパケットは、OBEXサーバエンジン３００Ｙ１’で設定したコネクションと関連していることを認識し、OBEXサーバエンジン３００Ｙ１’,….３００ＹＮ’の情報を記憶管理する。
クライアント側のOBEX部１０３は、第１の実施の形態と同じく、上位アプリケーションからの１回のOBEXコネクションの設定要求に対して複数のOBEXコネクションを設定することになるが、上位アプリケーション１０４へは、複数のOBEXコネクションのうち代表する一つのOBEXコネクションに割り当てられたローカルコネクションＩＤのみを提供するものとする。本実施の形態において、代表となるローカルコネクションＩＤはOBEXクライアントエンジン２００Ｘ１に割り当てられた値とする。
なお、複数のコネクションを利用してオブジェクト送信要求(PutRequest)の処理を実行する方法、また複数のコネクションを切断する方法については、第１の実施の形態で説明した通りである。
本実施の形態においては、クライアント側の機器が、相手機器が自らと同じOBEX部１０３を有するか否かを受信したConnectResponseパケットから検知することが可能であり、必要に応じて多重化のためのコネクションを設定することが可能となる。また、本実施の形態においては、多重度Ｎを計算するにあたり、Put要求を受信してからPut応答を送信するまでの処理時間の平均値（あるいは期待値）を相手機器側から取得するため、第１の実施の形態にくらべて、相手機器の受信能力を適正に反映させた多重度Ｎの計算を行うことが可能である。
（第３の実施の形態）
第２の実施の形態では、クライアント側の機器のOBEXインタフェース１０００は、Ｔ３の情報が含まれたConnectResponseパケットを受信すると、多重化処理実行部４０００はそれに含まれるＴ３の情報を利用して多重度Ｎを計算する。そして、多重度Ｎの計算に成功すると、Ｎ−１個のOBEXクライアントエンジン２００Ｘ２,…２００ＸＮを利用し、それぞれからOBEXのConnectRequestパケット送信を行う。
これに対し、本実施の形態では、多重度Ｎの計算に成功しても、すぐには複数のOBEXクライアントエンジン２０００を利用してコネクションを設定することはしない。
本実施の形態におけるOBEX部１０３においては、上位アプリケーション１０４がOBEX部１０３に対し、OBEXのオブジェクト送信要求(PutRequest)関数を実行したことを起因としてコネクションの設定を行う。より詳細には、上位アプリケーション１０４がオブジェクト送信要求(PutRequest)関数を実行したら、多重化処理実行部４０００は、オブジェクト送信要求(PutRequest)の処理を一旦保留する。多重化処理実行部４０００は、第２の実施の形態で説明したように、Ｎ−１個のOBEXクライアントエンジン２００Ｘ２,…２００ＸＮを利用し、それぞれからOBEXのConnectRequestパケット送信を行って、多重送信用の複数のコネクション設定を行う。複数のコネクション設定が完了すると、多重化処理実行部４０００は保留していたオブジェクト送信要求(PutRequest)の処理を再開する。なお、複数のコネクションを利用してオブジェクト送信要求(PutRequest)の処理を実行する方法については、第１の実施の形態で説明した通りである。また、複数のコネクションを切断する方法についても、第１の実施の形態で説明した通りである。
本実施の形態によれば、オブジェクトの送信など多重化による送信が必要な場合にのみ、多重化コネクションを設定するため、例えば、単にコネクション設定及び切断のみを行うなどの場合に無駄な多重化コネクションを設定することを避けることが可能である。
（第４の実施の形態）
以下、本発明の第４の実施の形態について図２２及び図２３を用いて説明する。
本実施の形態では、第１〜第３の実施の形態で説明した多重コネクションを利用してオブジェクトを送信する場合において、送信するオブジェクトの合計サイズに応じて、利用する多重コネクション数を可変とする方法について説明する。
OBEXプロトコルでは、コネクション設定時に、設定したコネクションで以後送受信を行うパケットの最大サイズについてネゴシエーションを行う。ネゴシエーションの結果決まる最大パケットサイズに基づき、OBEXパケットのBodyヘッダあるいはEndofBodyヘッダ（図７参照）を用いて 一度に送信可能なオブジェクトのサイズＬ１を計算することが可能である。
オブジェクトを分割して送信する場合に、第１〜第３の実施の形態で計算したＮの値を固定的に使うのではなく、送信するオブジェクトの合計サイズＬ２、および、一度に送信可能なオブジェクトのサイズＬ１の値を用いて、多重度の値を動的に変更する。
図２２は、多重度の値を動的に決める方法の一例を示すフローチャートである。
多重度Nの値が３で、送信するオブジェクトの合計サイズＬ２が１５００バイトであるとの前提の下、まず、一度に送信可能な最大サイズＬ１の値を計算する（ステップS301）。ここでは、Ｌ１の値は１０００バイトであるとする。
次に、Ｌ２／Ｌ１を計算し、小数点以下を切り上げることにより整数値ｍを求める。（ステップS302）。本例ではｍ＝２となる。
整数値ｍがN以下である場合は（ステップS303のNO）、多重度をｍとする（ステップS304）。本例はこれに該当し、従って、２つのコネクションを利用してオブジェクトを送る。例えば、１０００バイトと５００バイト、あるいは、７５０バイトと７５０バイトをそれぞれのコネクションで送信する。
一方、整数値ｍがNより大きい場合は（ステップS303のYES）多重度をNとする（ステップS305）。従って、第１〜第３の実施の形態と同様、送信するオブジェクトを３つに分割し、３つのコネクションを利用して、それぞれのコネクションで５００バイトずつ送信を行う。
図２３は、多重度の値を決める別の方法を示すフローチャートである。
この方法では、送信するオブジェクトの合計サイズＬ２が、閾値ＬＴより大きい場合は（ステップS401のYES）、多重度Ｎで多重送信を行い（ステップS402）、閾値ＬＴ以下である場合は（ステップS401のNO）、多重度を１として（ステップS403）、単一のコネクションにて送信する。
以上のように、本実施の形態によれば、送信するオブジェクトの合計サイズに応じて多重度を変更するため、例えば送信するオブジェクトの合計サイズが小さい場合などは多重化するコネクション数を減らすことで、処理負担を削減することが可能である。
（第５の実施の形態）
第１〜第３の実施の形態では多重コネクションを利用してオブジェクトを送信する場合を説明したが、本実施の形態では、多重コネクションを利用してオブジェクトを取得する場合について説明する。
図２４は、本実施の形態におけるOBEX部１０３の詳細構成を示す図である。
第１の実施の形態で説明した図１８の構成要素との違いは、多重化処理実行部４０００が分割オブジェクト構築部４００６を、多重化処理解析部５０００がオブジェクト分割部５００４を備える点にある。なお、本実施の形態においては、第１の実施の形態と同様の方法により、Ｔ２とＴ１を利用して多重度Ｎを計算するものとする。
以下、第１の実施の形態との違い中心に説明する。
多重利用OBEXクライアントエンジン管理部４００４は、Ｎ計算部４００３から指定された多重度Ｎに基づき、必要なOBEXクライアントエンジン２０００を利用して、オブジェクトの取得の多重処理ができるように各OBEXクライアントエンジン２０００を管理する。
また、多重利用OBEXクライアントエンジン管理部４００４は多重化されたコネクションに１つ割り当てられるローカルコネクションＩＤについても管理を行う。多重利用OBEXクライアントエンジン管理部４００４は、上位アプリケーション１０４からのGet命令を複数のOBEXクライアントエンジン２０００へ分岐して伝えるとともに、各OBEXクライアントエンジン２０００の処理の結果を統合して、上位アプリケーション１０４へ通知する。
分割オブジェクト構築部４００６は、多重利用OBEXクライアントエンジン管理部４００４が管理する複数のOBEXクライアントエンジン２０００で取得したオブジェクトを統合し一つのオブジェクトを構築する機能を備える。
オブジェクトの取得要求を行うクライアント側が送信する最初のGetRequestパケットは、OBEXクライアントエンジン２００Ｘ１から送信されるものとし、そのGetRequestパケットには取得を要求するオブジェクトを識別できるパラメータが含まれているものとする。
多重利用OBEXサーバエンジン管理部５００１は、複数のOBEXサーバエンジン３０００を利用して、オブジェクトの取得の多重処理ができるように各OBEXサーバエンジン３０００を管理する。
クライアント側の機器のOBEXクライアントエンジン２００Ｘ１との間でコネクションを設定しているOBEXサーバエンジン３００Ｙ１が最初のGetRequestを受信した場合、OBEXサーバエンジン３００Ｙ１は、そのGetRequestに含まれているパラメータに基づき、提供するオブジェクトを識別し、その情報を多重化処理解析部５０００のオブジェクト分割部５００４へ通知する。
オブジェクト分割部５００４は、クライアント側の機器から取得要求されたオブジェクトを複数に分割する機能を備える。オブジェクト分割部５００４は、OBEXサーバエンジン３００Ｙ１から分割するオブジェクト情報が通知された場合、多重度Ｎの値に従って、対象となるオブジェクトをＮ個に分割する。オブジェクト分割部によってＮ個に分割されたオブジェクトに関する情報は、それぞれが対応するOBEXサーバエンジン３００Ｙ１〜OBEXサーバエンジン３００ＹＮのいずれかに通知される。
OBEXサーバエンジン３００Ｙ１〜OBEXサーバエンジン３００ＹＮはその後の取得要求に対する応答処理において、それらの分割されたオブジェクトをGetResponseパケットに格納して、それぞれがコネクションを設定している先のOBEXクライアントエンジン２００Ｘ１〜OBEXクライアントエンジン２００ＸＮへと送信する。
以上のように、本実施の形態によれば、通信機器１におけるOBEX部１０３は、上位アプリケーション１０４からの１つのコネクション設定要求に対して、内部処理として複数のOBEXコネクションを設定し、取得対象となるオブジェクトを複数に分割して並列に取得するため、図１９に示す通信シーケンスにより効率的なデータの取得が可能となる。
（第６の実施の形態）
図２５は、本実施の形態におけるOBEX部の詳細構成を示す図である。
第１〜第４の実施の形態では、多重コネクションを利用してオブジェクトを送信する場合に、多重度Ｎを、OBEXサーバエンジン３０００がPut要求を受信してからPut応答を送信するまでの処理時間の平均値（あるいは期待値）であるＴ１秒と、OBEXクライアントエンジン２０００で設定しているＰｕｔ要求の最大パケット長のパケット要求を送信後、相手機器のOBEXサーバエンジン３０００へ届くまでの伝送時間の平均値（あるいは期待値）Ｔ２とから計算していた。また、第５の実施の形態で説明した多重コネクションを利用してオブジェクトを取得する場合においても、オブジェクトを送信する場合と同様に多重度ＮをＴ１とＴ２とから計算していた。
図２５において、多重化処理実行部４０００におけるＴ４検出部４００７は、OBEXクライアントエンジン２０００がContinueを示すGet応答を受信してから次のGet要求を送信するまでの処理時間の平均値（あるいは期待値）を予め計算して、Ｔ４秒として記憶する。
Ｔ５設定部４００８は、OBEXサーバエンジン３０００がGet要求に対する応答パケットを返す場合に、最大パケット長の応答パケットを送信後、OBEXクライアントエンジン２０００へ届くまでの伝送時間の平均値（あるいは期待値）を、上述したＴ２設定部４００２と同様にして計算又は取得して、Ｔ５秒として記憶する。
Ｎ計算部４００３は、多重度Ｎ１＝[Ｔ１／Ｔ２]＋１、N２＝[Ｔ４／Ｔ５]＋１の２つを計算し、記憶管理する。
Ｎ１とN２が異なる場合、以下のようにして多重送信を行う。
例えば第３の実施の形態で示したようにコネクション設定時にすぐに多重コネクションを設定するのではなくブジェクトの送信要求が発生したときに初めて多重化コネクションを設定する場合は、オブジェクトの送信要求が発生した際にＮ１本のコネクションを設定して多重送信を行う。一方、オブジェクトの取得要求が発生した場合に初めて多重化コネクションを設定する場合は、N２本のコネクションを設定して多重送信を行う。
また、第１の実施の形態で示したようにコネクション設定時にすぐに多重コネクションを設定する場合には、Ｎ１とN２のいずれか小さい方を選択して多重化コネクションを設定する方法などが考えられる。なお、必ずしも小さい値を選択しなくてもよく、例えば、Ｎ１とN２をランダムで選択する方法としてもよい。
以上のように、本実施の形態によれば、通信機器１におけるOBEX部１０３は、上位アプリケーション１０４からの１つのコネクション設定要求に対して、内部処理として複数のOBEXコネクションを設定し、オブジェクトを送信する場合はそれを分割して並列に送信し、オブジェクトを取得する場合はそれを分割して並列に取得するため、効率的なデータ転送を実現できる。また、本実施の形態によれば、必要に応じて、オブジェクトを分割して並列に送信する場合のコネクションの多重度と、オブジェクトを分割して並列に取得する場合のコネクションの多重度とを異なる値にすることも可能である。
（第７の実施の形態）
第６の実施の形態では図２５を用いて、Ｇｅｔを行う場合を例として説明を行ったが、本実施の形態では、Ｐｕｔを行う場合において、クライアントがサーバからの応答を受信してから送信するまでの時間がある程度かかる場合に多重度を計算する方法について説明する。
本実施の形態においては、図２５に示す構成要素のうち、Ｔ１検出部とＴ２設定部を削除した構成であってもよい。
図２５において、多重化処理実行部４０００におけるＴ５設定部４００８は、ＯＢＥＸクライアントエンジン２０００が最大パケット長のＰｕｔ要求を送信後、OBEXサーバエンジン３０００が送信するPut応答を受信するまでの時間を計測し、計測した値をＴ５秒として記憶する。
Ｔ４検出部４００７は、OBEXクライアントエンジン２０００がContinueを示すＰｕｔ応答を受信してから次のＰｕｔ要求を送信するまでの処理時間を計測し、計測した値をＴ４秒として記憶する。
Ｎ計算部４００３は、多重度N２＝[Ｔ４／Ｔ５]＋１を計算し、記憶管理する。
以上のように、本実施の形態によれば、時間測定をクライアント側で行うだけで多重度の計算を行うことができ、サーバ側での処理時間が無視できる場合に有効である。また、常に多重度を計算することによって、例えば、非常に大きなファイルを転送中に多重度の値が変化したことを検知し、変化した状態が継続するようであれば、必要に応じて利用するコネクション数を変化させるなどの工夫も可能となる。
以上までに説明した本発明の第１〜第７の実施の形態によれば、通信シーケンスが要求及び応答方式である通信プロトコルを用いてオブジェクトを送信する場合に、オブジェクトを複数に分割して並列に送信することが可能であることから効率的なデータ送信が可能となる。また、通信シーケンスが要求及び応答方式である通信プロトコルを用いてオブジェクトを取得する場合に、オブジェクトを複数に分割して並列に取得することが可能であることから効率的なデータ送信が可能となる。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
OBEXのセッションモデルを示す図 OBEXプロトコルの要求パケットの基本的なパケットフォーマットを示す図 OBEXプロトコルの応答パケットの基本的なパケットフォーマットを示す図 OBEXプロトコルにおけるopコードの定義を示す図 OBEXプロトコルにおける応答コードの定義を示す図 OBEXプロトコルにおけるOBEXヘッダの構成を示す図 OBEXプロトコルにおけるOBEX ヘッダのヘッダID(HI)の定義を示す図 OBEXプロトコルによるセッション構築（Connect処理）の通信シーケンスを示す図 OBEXプロトコルによるオブジェクト送信（Put処理）の通信シーケンスを示す図 OBEXプロトコルによるオブジェクト取得（Get処理）の通信シーケンスを示す図 OBEXプロトコルによるセッション切断（Disconnect処理）の通信シーケンスを示す図 通信機器１の概略構成を示すブロック図 通信機器１と通信機器１’との通信の様子を示す図 OBEXコネクションの多重化の様子を示す図 OBEX部１０３の基本構成要素におけるクライアント動作時の処理の流れを示す図 OBEX部１０３の基本構成要素におけるサーバ動作時の処理の流れを示す図 第１の実施の形態におけるOBEX部１０３の構成を示すブロック図 第１の実施の形態におけるOBEX部１０３の詳細構成を示すブロック図 OBEXの多重コネクションを利用した場合の通信シーケンスを示す図 OBEXプロトコルによる一般的な通信シーケンスを示す図 第２の実施の形態におけるOBEX部１０３の詳細構成を示すブロック図 多重度Nを動的に決める方法を説明するフローチャート 多重度Nを動的に決める別の方法を説明するフローチャート 第５の実施の形態におけるOBEX部１０３の詳細構成を示すブロック図 第６の実施の形態におけるOBEX部１０３の詳細構成を示すブロック図
符号の説明
１、１’ ‥‥ 通信機器
１１ ‥‥ クライアント
１２ ‥‥ サーバ
１０１ ‥‥ 無線通信デバイス
１０２ ‥‥ 下位プロトコルスタック部
１０３ ‥‥ OBEX部
１０４ ‥‥ 上位アプリケーション
１０００ ‥‥ OBEXインタフェース
２０００ ‥‥ OBEXクライアントエンジン群
３０００ ‥‥ OBEXサーバエンジン群
４０００ ‥‥ 多重化処理実行部
４００１ ‥‥ Ｔ１検出部
４００２ ‥‥ Ｔ２検出部
４００３ ‥‥ N計算部
４００４ ‥‥ 多重利用OBEXクライアントエンジン管理部
４００５ ‥‥ オブジェクト分割部
４００６ ‥‥ 分割オブジェクト構築部
５０００ ‥‥ 多重化処理解析部
５００１ ‥‥ 多重利用OBEXサーバエンジン管理部
５００２ ‥‥ 分割オブジェクト構築部
５００３ ‥‥ Ｔ３設定部
５００４ ‥‥ オブジェクト分割部

Claims (15)

  1. ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第Ｎ層に備えたデータ通信装置であって、
    前記第N層のプロトコルスタックを処理するプロトコルスタック処理手段と、
    前記プロトコルスタック処理手段が、前記第Ｎ層の下位の第Ｎ−１層によって提供されるサービスアクセスポイントを介して所定長の要求パケットを送出してから、前記要求パケットの要求先に前記第N層の通信プロトコルとしての処理を受けるまでに要する時間の期待値を第１の期待値として格納する第１の期待値格納手段と、
    要求先に前記第N層の通信プロトコルとして前記要求パケットが受け入れられてから、該要求パケットに対する応答パケットが前記第N層の通信プロトコルに従って送出されるまでの時間の期待値を第２の期待値として格納する第２の期待値格納手段と、を有し、
    前記第１の期待値と前記第２の期待値とに基づいて、前記第Ｎ−１層によって提供される前記サービスアクセスポイントに設定すべき前記第Ｎ層におけるコネクション数を計算する多重度計算手段を備えたデータ通信装置。
  2. ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第Ｎ層に備えたデータ通信装置であって、
    前記第N層のプロトコルスタックを処理するプロトコルスタック処理手段と、
    前記プロトコルスタック処理手段が行った要求に対する、該要求の要求先からの前記第N層の通信プロトコルによる所定長の応答パケットが送出されてから、前記プロトコルスタック処理手段が該応答パケットを受け取るまでの時間の期待値を第１の期待値として格納する第１の期待値格納手段と、
    前記プロトコルスタック処理手段が前記応答パケットを受け取ってから前記応答パケットに対応してさらなる要求パケットを送出するまでの時間の期待値を第２の期待値として格納する第２の期待値格納手段と、を有し、
    前記第１の期待値と前記第２の期待値とに基づいて、前記第Ｎ層の下位の第Ｎ−１層によって提供されるサービスアクセスポイントに設定すべき前記第Ｎ層におけるコネクション数を計算する多重度計算手段を備えたデータ通信装置。
  3. ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第Ｎ層に備えたデータ通信装置であって、
    前記第N層のプロトコルスタックを処理するプロトコルスタック処理手段と、
    前記プロトコルスタック処理手段が、前記第N層の下位の第Ｎ−１層によって提供されるサービスアクセスポイントを介して所定長の要求パケットを送信してから、該要求パケットの要求先から該要求パケットに対する前記通信プロトコルによる応答パケットを受信したことを受けて次の要求パケットを送信するまでの合計時間において、
    前記第Ｎ−１層以下のプロトコルスタックを処理するために必要な時間の期待値を第１の期待値として格納する第１の期待値格納手段と、
    前記合計時間に含まれる第Ｎ層のプロトコルスタックを処理するために必要な時間の期待値を第２の期待値として格納する第２の期待値格納手段と、
    を有し、
    前記第１の期待値と前記第２の期待値とに基づいて、前記第Ｎ−１層によって提供される前記サービスアクセスポイントに設定すべき前記第Ｎ層におけるコネクション数を計算する多重度計算手段を備えたデータ通信装置。
  4. 前記所定長は、前記パケットの最大長であることを特徴とする請求項１乃至３のいずれかに記載のデータ通信装置。
  5. 前記多重度計算手段は、前記コネクション数を、（前記第２の期待値÷前記第１の期待値）＋２を越えない正の整数値とすることを特徴とする請求項１乃至３のいずれかに記載のデータ通信装置。
  6. 前記プロトコルスタック処理手段はさらに、前記要求先から前記第２の期待値を取得する取得手段を有することを特徴とする請求項１乃至３のいずれかに記載のデータ通信装置。
  7. 前記プロトコルスタック処理手段は、前記コネクション数分のコネクションを前記サービスアクセスポイントを介して設定するコネクション設定手段をさらに備えたことを特徴とする請求項１乃至３のいずれかに記載のデータ通信装置。
  8. 前記プロトコルスタック処理手段は、
    送出対象となるオブジェクトを、前記多重度計算手段によって計算された前記コネクション数に分割するオブジェクト分割手段と、
    前記オブジェクト分割手段によって生成された各分割オブジェクトを、前記サービスアクセスポイントに設定された前記コネクション数分の複数のコネクションを用いて送出する送出手段と
    をさらに備えたことを特徴とする請求項７に記載のデータ通信装置。
  9. 前記プロトコルスタック処理手段は、前記送出対象となるオブジェクトのサイズを検出するサイズ検出手段をさらに備え、
    前記オブジェクトのサイズがある閾値による基準を満たした場合は、前記コネクション設定手段は前記サービスアクセスポイントを介して前記コネクション数分のコネクションを設定し、前記オブジェクト分割手段は前記送出対象となるオブジェクトを前記コネクション数分の分割オブジェクトに分割することを特徴とする請求項８に記載のデータ通信装置。
  10. 前記プロトコルスタック処理手段は、前記要求先から要求されたコネクション数と同数のコネクションを、前記第Ｎ−１層によって提供されるサービスアクセスポイントを介して設定するコネクション設定手段をさらに備えたことを特徴とする請求項１乃至３のいずれかに記載のデータ通信装置。
  11. 前記プロトコルスタック処理手段は、
    送出対象となるオブジェクトを、前記コネクション数に分割するオブジェクト分割手段と、
    前記オブジェクト分割手段によって生成された各分割オブジェクトを、前記サービスアクセスポイントを介して設定された前記コネクション数分の複数のコネクションを用いて送出する送出手段と、
    をさらに備えたことを特徴とする請求項１０に記載のデータ通信装置。
  12. Bluetooth規格に従った通信を行い、且つ、前記第Ｎ層の通信プロトコルはOBEXプロトコルであることを特徴とする請求項１乃至１１のいずれかに記載のデータ通信装置。
  13. ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第N層として用いるデータ通信方法であって、
    前記第Ｎ層の通信プロトコルを処理するプロトコルスタックから、該第Ｎ層の下位のプロトコルスタックである第Ｎ−１層によって提供されるサービスアクセスポイントを介して所定長の要求パケットを送出してから、前記要求パケットが該要求パケットの要求先に前記第N層の通信プロトコルとして処理を受けるまでに要する時間の期待値と、
    要求先に前記第N層の通信プロトコルとして前記要求パケットが受け入れられてから、該要求パケットに対する応答パケットが前記第N層の通信プロトコルに従って送出されるまでの時間の期待値とに基づいて、
    前記第Ｎ−１層によって提供される前記サービスアクセスポイントに設定する前記第Ｎ層におけるコネクション数を計算することを特徴とするデータ通信方法。
  14. ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第Ｎ層として用いるデータ通信方法であって、
    前記要求の要求先からの前記第N層の通信プロトコルによる所定長の応答パケットが送出されてから、該応答パケットが前記第N層の通信プロトコルを処理するプロトコルスタックに到達するまでの時間の期待値と、
    前記第Ｎ層の通信プロトコルを処理するプロトコルスタックが前記応答パケットを受け取ってから前記応答パケットに対応してさらなる要求パケットを送出するまでの時間の期待値とに基づいて、
    前記第Ｎ層の下位の第Ｎ−１層によって提供されるサービスアクセスポイントに設定すべき前記第Ｎ層におけるコネクション数を計算することを特徴とするデータ通信方法。
  15. ある要求を行い該要求に応答する通信プロトコルを、プロトコルスタックの第Ｎ層として用いるデータ通信方法であって、
    前記第N層の通信プロトコルを処理するプロトコルスタックから、前記第N層の下位のプロトコルスタックである第Ｎ−１層によって提供されるサービスアクセスポイントを介して所定長の要求パケットを送出してから、該要求パケットの要求先から該要求パケットに対する前記通信プロトコルによる応答パケットを受信したことを受けて次の要求パケットを送信するまでの合計時間において、
    前記第Ｎ−１層以下のプロトコルスタックを処理するために必要な時間の期待値と、
    前記合計時間に含まれる第Ｎ層のプロトコルスタックを処理するために必要な時間の期待値とに基づいて、
    前記第Ｎ−１層によって提供される前記サービスアクセスポイントに設定すべき前記第Ｎ層におけるコネクション数を計算することを特徴とするデータ通信方法。
JP2004265827A 2004-09-13 2004-09-13 データ通信装置及びデータ通信方法 Expired - Fee Related JP4028539B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2004265827A JP4028539B2 (ja) 2004-09-13 2004-09-13 データ通信装置及びデータ通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004265827A JP4028539B2 (ja) 2004-09-13 2004-09-13 データ通信装置及びデータ通信方法

Publications (2)

Publication Number Publication Date
JP2006081112A JP2006081112A (ja) 2006-03-23
JP4028539B2 true JP4028539B2 (ja) 2007-12-26

Family

ID=36160162

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004265827A Expired - Fee Related JP4028539B2 (ja) 2004-09-13 2004-09-13 データ通信装置及びデータ通信方法

Country Status (1)

Country Link
JP (1) JP4028539B2 (ja)

Also Published As

Publication number Publication date
JP2006081112A (ja) 2006-03-23

Similar Documents

Publication Publication Date Title
JP5882353B2 (ja) ファイルシステムセッションにおけるマルチコネクションのための方法及びシステム
JP4198741B2 (ja) 通信機器、通信システム、通信方法、通信プログラム、通信回路
US7787391B2 (en) Communication device, communication system, communication method, communication program, and communication circuit
US8117318B2 (en) Electronic apparatus and communication control method
CN111083161A (zh) 数据传输的处理方法及装置、物联网设备
KR20090053791A (ko) 무선 통신 네트워크에서 데이터를 전송 및 분석하기 위한 방법 및 그의 장치
EP3908017A1 (en) Method and apparatus for establishing bluetooth data channel
WO2017088494A1 (zh) 一种链路管理方法及装置
US8798097B2 (en) Communication devices that communicate using frames and computer-readable media for controlling communication devices
JP4028539B2 (ja) データ通信装置及びデータ通信方法
JP2009182458A (ja) 通信装置、通信システム、通信方法及びプログラム
CN101006706B (zh) 通信装置、通信系统和通信方法
JP2005513871A5 (ja)
JP2008079330A (ja) 通信機器、通信方法、通信プログラム、通信回路、携帯電話、表示装置、印刷装置、記録装置
EP1422885A2 (en) Method and apparatus of exchanging transfer parameters in a mobile communication system
JP2008005442A (ja) 通信装置、通信システム、および通信方法
JP2007174625A (ja) 送信機、受信機、通信システム、通信方法、通信プログラム
US7613127B2 (en) Verifying packets received over a physical link
WO2009084506A1 (ja) 通信装置、通信システム、通信方法及びプログラム
US9106608B2 (en) Communication device, communication method, and non-transitory computer-readable recording medium
US10349456B2 (en) Video communication system, video transmission terminal, video reception terminal, communication method, and recording medium
KR100573820B1 (ko) 통신 프레임 생성 방법 및 상기 방법을 실행하기 위한 프로그램을 기록한 매체
US20240048990A1 (en) Bluetooth connection method and system, intelligent terminal, and computer storage medium
JP2009053841A (ja) 画像形成システム及び画像形成装置
JP3678238B2 (ja) データ転送方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070809

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20071002

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20071011

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101019

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101019

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111019

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111019

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121019

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131019

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees