JP4312633B2 - 送信方法および送信装置 - Google Patents

Description

本発明は、複数の端末間で送受信されるデータの送信方法および送信装置に関するものである。本発明のデータの送信方法および送信装置は、とくに、たとえば、無線通信におけるデータパケットを、送信のスケジューリングを考慮して送信する方法およびこの方法を用いた無線通信装置に関し、Bluetooth(商標)を搭載した無線通信装置に適用できるものである。

音声や映像などのマルチメディアサービスを提供するシステムにおいて用いられるマルチメディアアプリケーションは、音響、音声およびビデオに関するデータを処理する。このシステムにおいては、最小の通信遅延、最大スループットが要求される。すなわち、マルチメディア関連データなどのネットワーク内の特定のデータに対して、優先処理が必要であることは従来より認識されている。このようなマルチメディアサービスに求められる品質を提供するために、システム資源の適切な割当て、すなわちスケジューリングが必要になる。

通信サービスの品質は、QoS(Quality of Service)と呼ばれる。QoSを保証する技術としては、特許文献１や特許文献２に記載されたものがある。特許文献１に記載の技術は、データがビデオデータ、オーディオデータ、テキストデータであるかどうかにより、送信の優先順位を決めて、QoSを保証する。特許文献２に記載の技術は、各サービスに対して一度決定したQoSの程度を、リソースが不足したときに再調整することに関するものである。

ところで、近距離での無線通信手段に用いられる無線通信規格としてBluetooth通信規格がある。Bluetooth通信規格に従った通信装置においても、音声データ等が送受信され、QoSを保証することが要求される場合がある。

Bluetooth通信規格に従った通信装置は、１つの装置が、ホストと呼ばれる上位部分と、Bluetoothモジュールと呼ばれる下位部分から構成されている。ホストは、OSI参照モデルのアプリケーション層等を含み、Bluetoothモジュールは、物理層等を含む。

ホストとBluetoothモジュールとの間では、送受信すべきデータは、HCI(Host Controller Interface)データパケットと呼ばれるデータパケットに変換されてやり取りされる。Bluetooth通信規格によると、HCIデータパケットにおいては送受信の相手を、HCIデータパケット内の、コネクションハンドルと呼ばれるデータによって識別する。

Bluetooth通信規格によると、同じ送受信の相手に対して、すなわち同じコネクションハンドルを有する相手に対して、複数のアプリケーションのデータを送受信することができる。しかし、Bluetoothモジュールは、処理すべきデータがこれらのアプリケーションのうちのどのアプリケーションに係わるデータであるかを、HCIデータパケットを用いて識別することが現状では不可能である。なぜならば、Bluetooth通信規格上、Bluetoothモジュールが送受信の相手を識別するための手段とされるコネクションハンドルが同じだからである。コネクションハンドルが同じであるが、アプリケーションが異なるデータパケットをBluetoothモジュールは識別することができない。

Bluetoothモジュール上で、QoSを保証したサービスを実現するには、データパケットを優先順位付けして、プライオリティの高いデータパケットを優先的に送出する必要がある。

しかしBluetooth通信規格では、同じコネクションハンドルを有するデータパケットをBluetoothモジュールは識別できないため、プライオリティの高いアプリケーションが処理するためプライオリティを高くする必要があるデータパケットであっても、先に処理を開始したプライオリティの低いデータパケットがあるときは、この低いデータパケットを全部送信し終わるまで、プライオリティの高いデータパケットの送信を行うことができない。よって、同じコネクションハンドルを利用する複数のアプリケーションがあるとき、QoS保証サービスを実現するのは困難である。

また、HCIパケットのデータフォーマットは、Bluetooth通信規格で決められており、同じコネクションハンドルを有する複数のアプリケーションを識別できるようにHCIパケットのデータフォーマットを変更することは、ユーザにはできない。

このような問題は、Bluetooth通信規格に従った通信プロトコルに限って生じるものではなく、パケット等の送信時のデータ単位に、優先順位を表すデータ(たとえば優先順位を表すフラッグ)を含ませることができない通信プロトコルにも生じる。

特開平７―５８８０９号公報 特開２０００−１１５２４０号公報

本発明はこのような従来技術の欠点を解消し、複数の端末間で送受信されるデータの送信方法および装置において、QoSを保障したサービスを可能にした方法および装置を提供することを目的とする。とくに、パケット等の送信時のデータ単位に、優先順位を表すデータを含ませることができない通信プロトコルに従った端末、たとえばBluetooth通信規格に従ったデバイスを含む無線通信端末において、QoSを保障したサービスを可能にした方法および装置を提供する。

本発明は上述の課題を解決するために、複数の端末間で送受信されるデータの送信方法において、送信すべきデータを、該データに対して要求される送信の優先順位に応じて、所定の大きさのデータに分割し、分割されたデータを含むデータ単位を生成する第１の工程と、生成されたデータ単位に含まれるデータの大きさから送信の優先順位を決定する第２の工程と、決定された優先順位に従ってデータ単位を送信する第３の工程とを含むこととしたものである。

本発明によれば、データ単位に、優先順位を表すデータを含ませることができない通信プロトコルにおいて、優先順位に従ってデータ単位を送信することができる。

たとえば、Bluetooth通信規格に従ったBluetoothモジュールにおいて、リンクマネージャ層（LM: Link Manager)が、HCIデータパケットに含まれるデータの大きさをあらわすデータ(レングス(length)と呼ばれ、HCIデータパケットの一部である。)に基づいて、HCIデータパケットの優先順位、すなわち、プライオリティを識別して、プライオリティに応じたデータパケットの送信スケジューリングが可能となる。

次に添付図面を参照して本発明によるデータの送受信装置の実施例を詳細に説明する。図１を参照すると、本実施例は、本発明に係るデータの送信装置を、Bluetooth通信規格に従った無線通信装置10に適用した場合である。最初に本実施例の概要を述べる。QoSを保証したサービスを実現するためには、各アプリケーションが出力するデータパケットの優先順位を、無線通信装置10のBluetoothモジュールが認識する必要がある。データパケットの優先順位をBluetoothモジュールに簡単に識別させるため、優先順位ごとにHCIデータパケットの長さを規定する。

このために、Bluetoothモジュールを制御するホスト内の論理リンク管理層(L2CAP: Logical Link Control and Adaptation Protocol。論理リンク管理層の詳細は後述する)が、ホスト内のアプリケーションから受け取るL2CAPデータパケットをHCIデータパケットに分解する機能を有することを利用する。この機能を用いて、各優先順位に応じた固定の長さに各アプリケーションのデータを分解する。本実施例では、優先順位は２段階である。各優先順位に対応するデータの長さは、たとえば、以下のように、２段階に規定する。

優先順位 高い（ギャランティサービス要） データレングス 300バイト
優先順位 低い（ギャランティサービス不要） データレングス 100バイト

本実施例では、優先順位は２段階としたが、本発明はこれに限られるものではなく、優先順位は何段階でも可能である。また、本実施例では、優先順位が高いデータのレングスを300バイト、優先順位の低いデータのレングスを100バイトとしたが、本発明では、データレングスはこれに限られるものではなく、Bluetooth通信規格が許容するデータレングスの範囲内で設定できる。データレングスの大きさについても、固定された大きさではなく、あるレングスより大きいデータを優先順位が高いとし、あるレングスより小さいデータを優先順位が低いとすることもできる。

さらに、本実施例では、優先順位が高いデータのレングスは、優先順位の低いデータのレングスより大きいとしたが、本発明では、優先順位が高いデータのレングスを、優先順位の低いデータのレングスより小さいとすることもできる。

本実施例では、Bluetoothモジュールは、ホストから300バイトもしくは100バイトのデータを受け取り、データの長さが300バイトであるか、100バイトであるかによって、データの優先順位を判断し、判断結果に従って送信の順番を決定する。

図１は、無線通信装置10のプロトコルスタックを示すブロック図である。なお、本発明と直接関係のない部分について図示および説明を省略する。以下の説明では、信号およびデータは、その現れる接続線の参照番号で示す。

無線通信装置10は具体的には、たとえばパソコンや携帯電話である。無線通信装置10におけるプロトコルスタックについて簡単に説明する。プロトコルスタックは、上位層であるホスト12と、下位層であるBluetoothモジュール14と、これらの層間にあるUSB/RS232C （Universal Serial Bus/Recommended Standard 232）部16とに分けられる。ホスト12がBluetoothモジュール14を制御し、ホスト12とBluetoothモジュール14とは、シリアルインターフェース規格であるUSBまたはRS232Cに従って動作するUSB/RS232C部16を介してデータのやり取りを行う。

ホスト12には、アプリケーション18、API (Application Program Interface) 20、TCP/IP (Transmission Control Protocol/Internet Protocol) 22、RFCOMM 24、論理リンク管理層26、HCIドライバ28が階層的に配されている。

アプリケーション18は、たとえばWWWブラウザやメールソフト等である。API 20は、TCP/IP 22やRFCOMM 24などのプロトコルをアプリケーション18から利用する際のインターフェースである。TCP/IP 22は、WWWブラウザやメールソフト用プロトコルである。RFCOMM 24は、パソコンのCOMポート、たとえばEIA-232シリアルポートをエミュレートするプロトコルである。論理リンク管理層26は、論理チャネル管理、プロトコル多重、パケット分割(これはフラグメント化とも呼ばれる)、パケット再構築、QoS管理などを行う。HCIドライバ28は、USB/RS232C部16を介して、下位層であるBluetoothモジュール14とデータのやり取りを行う。

Bluetoothモジュール14は、HCI 30、リンクマネージャ層32、ベースバンド層34、無線（RF）に関する物理層36を含む。HCI 30は、USB/RS232C部16を介して、上位層であるホスト12とデータのやり取りを行う。リンクマネージャ層32は、通信リンクの設定や切断などの通信リンクに関する制御を行う。ベースバンド層34は、通信リンクを提供し、送受信周波数の指定、切替え等を行う。物理層36は、周波数ホッピング型のスペクトル拡散方式による通信を行う。

図２に、図１に示す無線通信装置10のハードウェア構成を示す。ホスト12は、アプリケーション18、API 20、TCP/IP 22、RFCOMM 24、論理リンク管理層26を実行するソフトウェアを格納するメモリ38と、メモリ38からこれらのソフトウェアを読み込んでアプリケーション18、API 20、TCP/IP 22、RFCOMM 24、論理リンク管理層26を実行する制御部40と、HCIドライバ 28を含む。制御部40はHCIドライバ28を制御して、HCIドライバ28にBluetoothモジュール14とのデータのやり取りを行わせる。

Bluetoothモジュール14は、HCI 30と、リンクマネージャ層32を実行するソフトウェアを格納するメモリ42と、ベースバンド層34であるベースバンド部34と、物理層36であるトランシーバ36およびアンテナ44と、制御部46とを含む。制御部46はメモリ42から、リンクマネージャ層32を実行するソフトウェアを読み込んで実行するとともに、HCI 30、メモリ42、ベースバンド部34、およびトランシーバ36を制御する。

本実施例においては、論理リンク管理層26より上位にあるアプリケーション、すなわちアプリケーション18、TCP/IP 22、RFCOMM 24等が送信を要求するデータを論理リンク管理層26に出力する。論理リンク管理層26は、このデータに対してアプリケーション18、TCP/IP 22、RFCOMM 24等が要求する送信の優先順位に応じて、所定の大きさのデータに分割する。そして論理リンク管理層26は、この分割されたデータを含むHCIデータパケットを生成する。

リンクマネージャ層32は、生成されたHCIデータパケットに含まれるレングスから、HCIデータパケットに含まれるデータの大きさを読み取り、大きさから送信の優先順位を決定し、決定された優先順位に従ってデータパケットを送信する。

ここで、リンクマネージャ層32が、HCIデータパケットに含まれるレングスからデータの大きさを読み取り、送信の優先順位を決定するという方法を採用した理由を、図３を参照して述べる。

図３は、Bluetooth通信規格に従った２台の無線通信装置10-1、10-2の間で、無線通信装置10-1から無線通信装置10-2にデータを送る場合のデータの流れを示す。図３においては、図１に示す構成要素のうち、優先順位の決定に直接関係のないものは、省略してある。

送信側の無線通信装置10-1のアプリケーション1 18-1、アプリケーション2 18-2、アプリケーション3 18-3が、受信側の無線通信装置10-2のそれぞれ対応するアプリケーション1 18-4、アプリケーション2 18-5、アプリケーション3 18-6にデータを送る場合を考える。

これらのアプリケーションは、通信相手の装置内にある同じアプリケーションにデータを送るとき、チャネル識別子（CID: Channel Identifier)により、相手を識別する。これらのアプリケーションは、通信相手の同じアプリケーションにデータを送るとき、チャネル識別子を指定して、データを論理リンク管理層26に出力する。すなわちアプリケーションは、チャネル識別子を含むデータ単位であるL2CAPデータパケット18-1a, 18-2a, 18-3aを論理リンク管理層26に出力する。

たとえばアプリケーション1 18-1、アプリケーション4 18-4には、チャネル識別子１(CID1)が割り当てられ、アプリケーション2 18-2、アプリケーション5 18-5には、チャネル識別子２(CID2)が割り当てられ、アプリケーション3 18-3、アプリケーション6 18-6には、チャネル識別子３(CID3)が割り当てられる。

論理リンク管理層26は、チャネル識別子により、処理対象である複数のアプリケーションを識別する。一方、Bluetooth通信規格においては、通信装置10-1,10-2同士は、実際の物理接続を識別するために、コネクションハンドルと呼ばれるものを用いる。すなわち、論理リンク管理層26より下位の層においては、コネクションハンドルにより送信相手を識別することがBluetooth通信規格において規定されている。

論理リンク管理層26-1は、直接の下位の層であるHCIドライバ28に対して、コネクションハンドルを含むデータ単位であるHCIデータパケット26-3を出力する。同一の通信相手に対して、論理リンク管理層26から、複数の異なるチャネル識別子CID1, CID2, CID3のL2CAPデータパケット18-1a, 18-2a, 18-3aをHCIドライバ28に出力するとき、論理リンク管理層26-1はL2CAPデータパケット18-1a, 18-2a, 18-3aを、同一のコネクションハンドルを含むHCIデータパケット26-3に変換して出力する。これらのHCIデータパケット26-3をどの通信相手に送るかを指示するために、同じ通信相手に対しては、同じコネクションハンドルを使う。リンクマネージャ層32-1がコネクションハンドルに基づいて送信相手を決定する。また、リンクマネージャ層32-1はHCIデータパケット26-3を、Bluetooth通信規格に従った所定のデータ形式を有する送信データ32-3に変換する。送信データは、コネクションハンドルに対応する物理リンク32-3を介して送信される。

このように、論理リンク管理層26より下位の層においては、コネクションハンドルによってのみデータは識別され、チャネル識別子はデータの識別には用いられない。後述するように、論理リンク管理層26より下位の層においては、チャネル識別子を含まないデータも処理される。また、上述のように、コネクションハンドルは通信装置の識別に用いられ、チャネル識別子は、アプリケーションの識別に用いられるため、コネクションハンドルとチャネル識別子とは、無関係に決められるものである。

したがって、通信処理を実際に行うリンクマネージャ層32以下においては、コネクションハンドルにより、アプリケーションを識別することができないため、同じコネクションハンドルを割り当てられた(すなわち、同じ通信相手に送られる)異なるアプリケーションのデータを識別することができない。そのため、異なるアプリケーションを、異なる優先順位で送ること（すなわち、QoSを保証すること）が、従来はできなかった。

相手側の通信装置10-2のリンクマネージャ層32-2が、送信データ32-3を受信すると、このデータ32-3をHCIデータパケット32-4に変換する。その後、リンクマネージャ層32-2はHCIデータパケット32-4を論理リンク管理層26-2に出力する。論理リンク管理層26-2はHCIデータパケット32-4から、アプリケーション18-4, 18-5, 18-6にそれぞれ対応するL2CAPデータパケット18-1a, 18-2a, 18-3aを生成し、L2CAPデータパケット18-1a, 18-2a, 18-3aのチャネル識別子CID1, CID2, CID3を解析し、アプリケーション18-4, 18-5, 18-6に送る。

ここで、論理リンク管理層26-1がL2CAPデータパケット18-1a, 18-2a, 18-3aを、同一のコネクションハンドルを含むHCIデータパケット26-3に変換する処理(パケット分割、またはフラグメント化と呼ばれる)、および論理リンク管理層26-2が、HCIデータパケット32-4からL2CAPデータパケット18-4a, 18-5a, 18-6aを生成する処理(再構成と呼ばれる)について、図４を参照して説明する。パケット分割と再構成は、併せてSAR（Segmentation and Reassembly) と呼ばれる。

図４は、論理リンク管理層26がL2CAPデータパケット18-1aを、コネクションハンドルを含むHCIデータパケット26-3に変換するパケット分割を示す。論理リンク管理層26が、アプリケーション18-1から入力されるL2CAPデータパケット18-1aは、その長さが最大64Kバイトまで、Bluetooth通信規格により許容されている。しかし、リンクマネージャ層32が、通信相手に送信できるデータの長さは、最大339バイトまでと、Bluetooth通信規格により規定されている。そこで、図４に示すように、論理リンク管理層26はL2CAPデータパケット18-1a全体を分割して、HCIデータパケット26-3a, 26-3b, 26-3c, 26-3d に変換する。

L2CAPデータパケット18-1aは、２バイトのレングスフィールド48と、２バイトのCIDフィールド50と、データ本体である64Kバイト以下であるペイロード52からなる。レングスフィールド48には、ペイロード52の大きさをバイト単位で示すデータが格納される。CIDフィールド50には、このL2CAPデータパケットを出力したアプリケーション18-1を識別するためのチャネル識別子(CID1)が格納されている。

HCIデータパケット26-3a, 26-3b, 26-3c, 26-3d は、12ビットのコネクションハンドル(CH: Connection Handle)フィールド54と、２ビットのL-CHフィールド56と、9ビットのレングスフィールド58と、データ本体である300バイトまたは100バイトのペイロード60からなる。コネクションハンドルフィールド54には、コネクションハンドルが格納される。レングスフィールド58には、ペイロード60の大きさをバイト単位で示すデータが格納される。

L-CHフィールド56には、先頭のHCIデータパケット26-3aでは「10」が格納され、後続するHCIデータパケット26-3b, 26-3c, 26-3d では「01」というデータが格納される。「10」は、HCIデータパケット26-3aが、分割されたHCIデータパケットのうち、先頭のHCIデータパケットであることを示し、「01」は、先頭のHCIデータパケットではないことを示す。L2CAPデータパケット18-1aのデータが少ないときは、先頭のHCIデータパケット26-3aのみであり、後続するHCIデータパケット26-3b, 26-3c, 26-3d は存在しないこともある。

また、分割された最後のHCIデータパケット26-3d のデータの大きさは、300バイト未満または100バイト未満のこともありうる。HCIデータパケット26-3d のデータの大きさは、本実施例の場合、300バイトまたは100バイトでなければならないため、不足するデータ分のダミーデータをHCIデータパケット26-3d に付加する。

ただし、このダミーデータは、本来のデータと識別するための特別なキャラクタコードである必要ない。なぜならば、受信側の論理リンク管理層26-2は、受信したHCIデータパケット26-3a, 26-3b, 26-3c, 26-3d を、図４とは逆に再構成して、L2CAPデータパケット18-1aを再現し、L2CAPデータパケット18-1aに含まれるレングス48より、受信すべき全データの長さを知ることができるからである。この情報から、付加されたデータのみを廃棄することができる。ダミーデータは、たとえば、すべて「0」でよい。

論理リンク管理層26-2が、HCIデータパケット26-3からL2CAPデータパケット18-4a, 18-5a, 18-6aのそれぞれを生成する再構成は、上述の論理リンク管理層26-1がL2CAPデータパケット18-1aを、コネクションハンドルを含むHCIデータパケット26-3に変換するパケット分割を逆に行えばよい。

なお、１台のBluetoothモジュールには１個の論理リンク管理層接続しか存在できず、この論理リンク管理層に対して、何個ものアプリケーションがアクセスできるため、チャネル識別子(CID)は複数個ある。たとえば、１台のBluetoothモジュールが他の１台のBluetoothモジュールと接続しているとする。２台のBluetoothモジュールの論理リンク管理層 レベルの通信は、２つの論理リンク管理層間で行われ、図３の場合、論理リンク管理層上には３個のアプリケーションが走っている。また１台のBluetoothモジュールは、同時に７本の物理リンク(すなわち、他の７台のBluetoothモジュール)を接続できるため、コネクションハンドルも、通信相手である端末１台当たり１個、最大７個まで存在できる。

本実施例では、同一のコネクションハンドルを有する送信相手、すなわち、同一の端末に対して、複数のアプリケーションがデータを送信する場合を述べる。そして、異なるアプリケーションが、異なる優先順位をつけて送信する場合を述べる。

なお、異なるコネクションハンドルを有する送信相手、すなわち、異なる端末に対して、複数のアプリケーションがデータを送信する場合は、論理リンク管理層およびリンクマネージャ層は、端末識別子であるコネクションハンドルにより、送信相手を識別できるため、コネクションハンドルごとに優先順位を付けることができる。

具体的には、論理リンク管理層に、優先データ用バッファと、非優先データ用バッファとを設け、論理リンク管理層は、優先されるコネクションハンドルのデータと、優先されないコネクションハンドルのデータとを受け付けたときは、優先されるコネクションハンドルのデータを優先データ用バッファに格納し、優先されないコネクションハンドルのデータを非優先データ用バッファに格納し、優先的に優先データ用バッファのデータをリンクマネージャ層に送る。

また、同一のコネクションハンドルのデータについては、優先されるアプリケーションのデータを優先的にリンクマネージャ層に送る。

リンクマネージャ層は、同一のコネクションハンドルを有する複数のデータに、長さの異なるデータがある場合、優先度の高いデータ、すなわち長いデータを優先的に送信する。また、優先されるコネクションハンドルのデータを優先的に送信する。

図１に戻って本実施例をさらに説明する。以下の説明では、Bluetooth通信規格に従った通信のための接続は、Bluetooth通信規格に従った手順によりすでに確立され、通信端末は、通信端末間でデータを送受信可能な状態にあるとする。接続はすでに確立されているため、各通信端末は、コネクションハンドルおよびチャネル識別子に関する情報を得ている。

ホスト12の論理リンク管理層26より上位にあるアプリケーション、すなわちアプリケーション18、TCP/IP 22、RFCOMM 24等(以下「アプリケーション等」と呼ぶ)が送信を行うとき、Bluetooth通信規格に従ったQoSコマンドを発行することができる。QoSコマンドは、物理リンク（コネクションハンドル）に対するQoSを要求するものであり、本発明のように、同一のコネクションハンドルを有する複数のデータに対して、優先順位を付けるものではない。QoSコマンドにより、優先される物理リンク（コネクションハンドル）が識別される。なお、本実施例に係わるQoSを、Bluetooth通信規格に従った従来のQoSと区別するために、本実施例に係わるQoSを以下ではQoS保証と呼ぶ。

アプリケーション等は、出力するデータに対して、QoS保証を要求する場合、すなわちデータの優先順位を高くして処理してもらいたいときは、QoSコマンドを発行した後、ベンダコマンドを使って、論理リンク管理層26にQoS保証要求を提出する。QoS保証を要求しないアプリケーション等は、論理リンク管理層26にQoS保証要求を提出しない。ここで「ベンダコマンド」とは、Bluetooth通信規格には規定されていないコマンドのことである。

QoS保証要求を受けたとき、論理リンク管理層26は、ベンダコマンドを使って、リンクマネージャ層32に、優先順位のレベル数と、各優先順位に対応するデータの長さ（HCIデータパケットのペイロードの大きさ）を通知する。リンクマネージャ層32はこの情報を用いて、各データの長さから各データパケットの優先順位を認識することができる。また、QoSコマンドをアプリケーション等から受けたとき、論理リンク管理層26は、QoSコマンドを使って、リンクマネージャ層32に、優先される物理リンク(コネクションハンドル)を伝える。

本実施例では、優先順位のレベル数は、「高い」、「低い」の２レベルであり、各優先順位に対応するデータの長さは、300バイトと100バイトである。優先順位は、既述のようにデータの長さが大きいものほど、高い。

論理リンク管理層26は、アプリケーション等からQoS保証要求を受けた場合、同じコネクションハンドルを用いる複数のアプリケーション等で、QoS保証要求をするアプリケーション等(以下では、要求アプリケーションと呼ぶ)と、QoS保証要求をしないアプリケーション等(以下では、非要求アプリケーションと呼ぶ)があるとき、図４に示すように、要求アプリケーションからのL2CAPデータパケットを、300バイトの長さを有する複数のHCIデータパケットに分解する。また論理リンク管理層26は、非要求アプリケーションからのL2CAPデータパケットを、100バイトの長さを有する複数のHCIデータパケットに分解する。論理リンク管理層26は分解後、HCIデータパケットをHCIドライバ28に送出する。

なお論理リンク管理層26は、送信時にアプリケーション等から受け取った１個のL2CAPデータパケット内のデータの大きさ(レングス)が、300バイトまたは100バイトを超えている場合、L2CAPデータパケットを、300バイトまたは100バイト以下の複数のHCIデータパケットに分割するが、300バイトまたは100バイト以下の場合、L2CAPデータパケットを、複数のHCIデータパケットに分割することはしない。

HCIデータパケットは、HCIドライバ28、USB/RS232C部16、HCI 30を介して、リンクマネージャ層32に送られる。リンクマネージャ層32は、HCI 30を通じて受信したHCIデータパケットのコネクションハンドル54を最初に調べる。QoSが設定されているコネクションハンドル54によって転送されるデータパケットであれば、リンクマネージャ層32は、続いてHCIデータパケットのレングス48を調べる。

レングス48により300バイトの大きさのパケットであることがわかれば、リンクマネージャ層32がこのパケットを優先送信バッファに入れる、レングス48により100バイトの大きさのパケットであることがわかれば、リンクマネージャ層32がこのパケットを非優先送信バッファに入れる。優先送信バッファにあるデータが常に非優先送信バッファにあるデータより先に送信される。

これを、図５を参照してさらに説明する。要求アプリケーション62からのL2CAPデータパケット64を、300バイトの長さを有する複数のHCIデータパケット66に分解する。また論理リンク管理層26は、非要求アプリケーション68からのL2CAPデータパケット70を、100バイトの長さを有する複数のHCIデータパケット72に分解する。論理リンク管理層26は分解後、HCIデータパケット66、72をHCIドライバ28、USB/RS232C部16、HCI 30を介してリンクマネージャ層32に送出する。

リンクマネージャ層32は、データレングスによるスケジューリング方法を実行するために、データレングスに対応するデータバッファ74、76を有する。すなわち、優先的に送信されるパケット用の優先送信バッファ74と非優先で送信されるパケット用の非優先送信バッファ76をリンクマネージャ層32は持つ。

QoS要求をしないコネクションハンドルを有するHCIデータパケットや、QoSを要求するコネクションハンドルを有するHCIデータパケット72ではあるが、このパケットを発する非優先アプリケーション68がQoS保証を要求しないものである場合は、非優先送信バッファ76に格納される。QoS保証要求があるコネクションハンドルを有するHCIデータパケット66は、優先送信バッファ74に格納される。なお、優先送信バッファ74および非優先送信バッファ76は、コネクションハンドルごとに設けることが好ましい。

データ送信時は、QoS保証要求があるコネクションハンドルと、QoS保証要求がないコネクションハンドルとがある場合は、リンクマネージャ層32は、QoS保証要求があるコネクションハンドルを有するHCIデータパケットを、QoS保証要求がないコネクションハンドルを有するHCIデータパケットよりも優先的に送信する。図５は、説明の簡単化のために、コネクションハンドルが１つのみであり、当該コネクションハンドルがQoSを要求し、かつ、当該コネクションハンドルを介して、QoS保証を要求する優先アプリケーションと、QoS保証を要求しない非優先アプリケーションがデータを送信する場合を示す。

リンクマネージャ層32はHCIデータパケットに含まれるレングスから、HCIデータパケットの大きさを得て、QoS保証要求をする優先アプリケーション62からのものであるかどうかを判断する。

レングスにより300バイトの大きさのパケットであることがわかれば、リンクマネージャ層32がこのパケットを優先送信バッファ74に入れる。レングスにより100バイトの大きさのパケットであることがわかれば、リンクマネージャ層32がこのパケットを非優先送信バッファ76に入れる。優先送信バッファ74にあるデータが常に非優先送信バッファ76にあるデータより先に送信される。

ところで、優先送信バッファ74内のデータを優先的に送信することによる非優先送信バッファ76内のデータの送信停止を回避するために、優先送信バッファ74から一定の量のデータを送信したときに、非優先送信バッファ76の送信を開始する必要がある。そのために、優先送信バッファ74および非優先送信バッファ76が送信したデータ量を計測するためのカウンタPBC、NPBCを設ける。

優先送信バッファ74の容量に対してどの程度のデータ量を送信したら、非優先バッファ76の送信を開始するかはベンダコマンドによって、論理リンク管理層26がリンクマネージャ層32に事前に通知する。

このように、リンクマネージャ層32は、論理リンク管理層26から受け付けたデータを優先送信バッファ74と非優先送信バッファ76に振り分けると同時に、振り分けられたデータを、優先送信バッファ74内のデータを優先して送信する。

ところで、優先および非優先アプリケーション62、68は、連続的にデータを論理リンク管理層26に出力し、そのデータを論理リンク管理層26が処理して、リンクマネージャ層32に連続的にデータを出力することがある。このとき、リンクマネージャ層32は、データを上記２つの送信バッファ74、76に振り分けて格納する格納処理と、データを上記２つの送信バッファ74、76から取り出して送信する送信処理を交互に繰り返すことになる。格納処理と、送信処理を切替えるタイミングは、さまざまな方法で設定される。

たとえば、格納処理で所定量のデータを処理すると、格納処理を中断して、送信処理を開始し、送信処理で所定量のデータを処理すると、送信処理を中断して、格納処理を開始する。もしくはタイマーを設けて、所定時間ごとに、格納処理と、送信処理を切替えるとしてもよい。

また、リンクマネージャ層32をリアルタイムオペレティングシステム（RTOS: Real Time Operating System)の一つのタスクとして実装し、データを送信するリンクコントローラ(LC: Link ControI)を別のタスクとして実装してもよい。この場合、論理リンク管理層26から受信するとすぐに振り分け作業を開始する。バッファにデータが入ると、リンクコントローラが起動されて、データの送信を開始する。このとき優先送信バッファが先に送信される。この二つのタスクは、ほぼ同時に動作する。

送信処理では、「優先送信バッファ74がバッファの容量に対して一定の量のデータを送信してから、非優先送信バッファ76の送信を開始する」が、これを具体的に実施するためのフローチャートの一例を図６に示す。

このフローチャートにおいては、優先送信バッファ(PB)74内にデータがなく、かつ非優先送信バッファ76内にもデータがないとき、処理を終了する。優先バッファ用カウンタPBCは、送信済みの優先送信バッファ(PB)74のデータ量をカウントするためのものであり、非優先バッファ用カウンタNPBCは、送信済みの非優先送信バッファ(NPB)76のデータ量をカウントするためのものである。優先バッファ用カウンタPBCおよび非優先バッファ用カウンタNPBCは、いわゆるファーストインファーストアウト(FIFO)型のバッファである。

送信処理が開始されると、優先バッファ用カウンタPBCと非優先バッファ用カウンタNPBCをリセットするために、それぞれに「０」を入れる(S1)。優先送信バッファ(PB)74にデータがあるかどうかを調べる。データがあるときはステップS3に進み、無いときはステップS6に進む(S2)。ステップS3では、データを300バイト送信する、すなわち１回の送信では、１個のデータパケットを送信する。優先バッファ用カウンタPBCの内容は１増やす(S3)。次に優先バッファ用カウンタPBCが所定の大きさになったかを判定する。所定の大きさになっていないときは、ステップS2に戻り、送信を繰り返す。所定の大きさに達したときは、優先バッファ74内のデータの送信を中止して、ステップS5に進む(S4)。ステップS5では、優先バッファ用カウンタPBCをクリアして(S5)、ステップS6に進み、非優先送信バッファ(NPB)76のデータ送信処理を開始する。

ステップS6では最初に非優先送信バッファ(NPB)76にデータがあるかどうかを調べる。データがあるときはステップS7に進み、無いときは送信処理を終了する(S6)。ステップS7では、データを100バイト送信する、すなわち１回の送信では、１個のデータパケットを送信する。非優先バッファ用カウンタNPBCの内容を１増やす(S7)。次に非優先バッファ用カウンタNPBCが所定の大きさになったかを判定する。所定の大きさになっていないときは、ステップS6に戻り、送信を繰り返す。所定の大きさに達したときは、非優先バッファ76内のデータの送信を中止して、ステップS9に進む(S8)。ステップS9では、非優先バッファ用カウンタNPBCをクリアして(S9)、ステップS2に進み、優先送信バッファ(PB)74内のデータ送信処理を開始する。以上でフローチャートの説明を終える。

なお、ハードウェアによって自動的に優先送信バッファ74からのデータ送信を監視し、一定量のデータを送信したら、割り込みで非優先送信バッファ76からのデータ送信を開始するようにしてもよい。

リンクマネージャ層32が、データを下位の層に出力するときは、HCIデータパケットを、Bluetooth通信規格に従って所定の別のデータパケット形式を有するデータパケットに変換してから出力する。

本発明に従った受信装置においては、図５に示す送信装置の逆の処理を行う。すなわち受信装置は、図５に示す送信装置からデータパケットを受信すると、リンクマネージャ層32は、受信したデータパケットからHCIデータパケットを生成する。次にリンクマネージャ層32は、生成されたHCIデータパケットに含まれるレングス58から優先順位を決定し、優先送信バッファ74または優先送信バッファ76に振り分けて格納した後、優先順位に従って、優先送信バッファ74または優先送信バッファ76から取り出す。取り出されたHCIデータパケットは、HCI 30、USB/RS232C部16、HCIドライバ28を介して、論理リンク管理層26に送られる。

論理リンク管理層26は、送られてきたHCIデータパケットを再構成して、L2CAPデータパケットを生成し、生成されたL2CAPデータパケット内のチャネル識別子に従って、生成されたL2CAPデータパケットを対応するアプリケーションに転送する。

以上のように、リンクマネージャ層がHCIデータパケットのレングスを識別して、各レングスに対応する優先順位を認識でき、優先順位に対応したデータパケット転送のスケジューリングができる。

そのときに、リンクマネージャ層に優先送信バッファと非優先送信バッファを用意することで、リンクマネージャ層によりスケジューリングされたデータパケットが確実に優先順位順で送信され、QoS保証サービスが簡単に実現できる。また、ベンダコマンドの設定或いはハードウェアの監視によって、一定量の優先パケットを送信した後に、非優先データパケットを送信することにより、非優先データパケット転送の渋滞が回避できる。

本発明の実施例は、Bluetooth通信規格に従った通信プロトコルに適用したものであるが、データパケットに優先順位を表すフラッグを付与することができない他の通信プロトコルにも適用できる。

上記の実施例は、データの長さにより、送受信の優先順位を決定するものであるが、本発明はこれに限られるものではなく、データの長さにより、当該データの処理の優先順位を決定することができる。処理の例としては、送受信に直接係わらない処理、たとえば、データの表示処理等がある。

本発明に係わるデータの送受信装置の一実施例である無線通信装置のプロトコルスタックを示すブロック図である。 図１に示す無線通信装置のハードウェア構成を示すブロック図である。 図３は、Bluetooth通信規格に従った無線通信装置の間で、データを送る場合のデータの流れを示すブロック図である。 図４は、論理リンク管理層 がL2CAPデータパケットを、コネクションハンドルを含むHCIデータパケットに変換するパケット分割を示す説明図である。 図５は、優先送信バッファと、非優先送信バッファを用いたデータ処理を示すブロック図である。 図６は、優先送信バッファおよび非優先送信バッファからのデータ送信を示すフローチャートである。

符号の説明

10 無線通信装置
14 Bluetoothモジュール
18 アプリケーション
26 論理リンク管理層
32 リンクマネージャ層
48、58 レングス
50 チャネル識別子
52、60 ペイロード
54 コネクションハンドル
74 優先バッファ
76 非優先バッファ

Claims (15)

1. 複数のアプリケーションを有する端末からデータを送信する送信方法において、該方法は、
   前記複数のアプリケーションによってそれぞれ送信する優先順位を指定された送信すべき複数のデータを、該データに対する前記優先順位に応じた大きさのデータに分割し、該分割されたデータを含むデータ単位を生成する第１の工程と、
   該生成されたデータ単位に含まれるデータの大きさから送信の優先順位を決定する第２の工程と、
   該決定された優先順位に従って該データ単位を送信する第３の工程とを含むことを特徴とする送信方法。
2. 請求項１に記載の送信方法において、前記データ単位は、Bluetooth通信規格に従ったデータパケットであることを特徴とする送信方法。
3. 請求項２に記載の送信方法において、
   前記第１の工程では、Bluetooth通信規格に従った同一のコネクションハンドルを有する複数のデータパケットが生成され、
   前記第２の工程では、該データパケットに含まれるデータの大きさから送信の優先順位を決定し、
   前記第３の工程では、該決定された優先順位に従って該データパケットを送信し、
   同一のコネクションハンドルを有するデータパケットのうち、優先順位の高いデータパケットを優先的に送信することを特徴とする送信方法。
4. 請求項１から３までのいずれかに記載の送信方法において、
   前記第２の工程では、優先順位が決定されると、前記データ単位を、優先順位に応じて設けられた複数のデータバッファのいずれかに格納し、
   前記第３の工程では、優先順位の高いデータ単位が格納された前記データバッファにある前記データ単位を優先的に送信することを特徴とする送信方法。
5. 複数のアプリケーションを有する端末から送信されたデータを受信する受信方法において、該方法は、
   前記複数のアプリケーションによってそれぞれ送信する優先順位を指定された複数のデータが前記優先順位に応じた大きさのデータに分割され、該分割されたデータを含むデータ単位に含まれるデータの大きさに基づく送信の優先順位に従って送信されたデータ単位を受信する第１の工程と、
   該受信したデータ単位に含まれるデータの大きさから、該受信したデータ単位の処理の優先順位を決定する第２の工程と、
   該決定された優先順位に従って、前記複数の受信したデータ単位から、前記複数のデータを構成する第３の工程とを含むことを特徴とする受信方法。
6. 請求項５に記載の受信方法において、前記データ単位は、Bluetooth通信規格に従ったデータパケットであることを特徴とする受信方法。
7. 複数のアプリケーションに応じたデータを送信する送信装置において、該装置は、
   前記複数のアプリケーションによってそれぞれ送信する優先順位を指定された送信すべき複数のデータを、該データに対する前記優先順位に応じた大きさのデータに分割し、該分割されたデータを含むデータ単位を生成するデータ生成部と、
   該生成されたデータ単位に含まれるデータの大きさから送信の優先順位を決定し、該決定された優先順位に従って該データ単位を送信するデータ送信部とを含むことを特徴とする送信装置。
8. 請求項７に記載の送信装置において、前記データ単位は、Bluetooth通信規格に従ったデータパケットであることを特徴とする送信装置。
9. 請求項８に記載の送信装置において、
   前記データ生成部は、Bluetooth通信規格に従った同一のコネクションハンドルを有する複数のデータパケットを生成し、
   前記データ送信部は、該データパケットに含まれるデータの大きさから送信の優先順位を決定し、該決定された優先順位に従って該データパケットを送信し、 同一のコネクションハンドルを有するデータパケットのうち、優先順位の高いデータパケットを優先的に送信することを特徴とする送信装置。
10. 請求項７から９までのいずれかに記載の送信装置において、
    前記データ送信部は、優先順位が決定されると、前記データ単位を、優先順位に応じて設けられた複数のデータバッファのいずれかに格納し、優先順位の高いデータ単位が格納された該データバッファにある前記データ単位を優先的に送信することを特徴とする送信装置。
11. 複数のアプリケーションを有する端末から送信されたデータを受信する受信装置において、該装置は、
    前記複数のアプリケーションによってそれぞれ送信する優先順位を指定された複数のデータが前記優先順位に応じた大きさのデータに分割され、該分割されたデータを含むデータ単位に含まれるデータの大きさに基づく優先順位に従って送信された該データ単位を受信するデータ受信部と、
    該受信したデータ単位に含まれるデータの大きさから、該受信したデータ単位の処理の優先順位を決定し、該決定された優先順位に従って、前記複数の受信したデータ単位から、前記複数のデータを構成するデータ構成部とを含むことを特徴とする受信装置。
12. 請求項１１に記載の受信装置において、前記データ単位は、Bluetooth通信規格に従ったデータパケットであることを特徴とする受信装置。
13. それぞれが複数のアプリケーションを有する複数の端末間でデータを送受信する通信方法において、該方法は、
    前記複数のアプリケーションによってそれぞれ処理する優先順位を指定された処理すべき複数のデータを、該データに対する前記優先順位に応じた大きさのデータに分割し、該分割されたデータを含むデータ単位を生成する第１の工程と、
    該生成されたデータ単位に含まれるデータの大きさから処理の優先順位を決定する第２の工程と、
    該決定された優先順位に従って該データ単位を処理する第３の工程とを含むことを特徴とする通信方法。
14. 請求項１３に記載の通信方法において、前記データ単位は、Bluetooth通信規格に従ったデータパケットであることを特徴とする通信方法。
15. 請求項１４に記載の通信方法において、
    前記第１の工程では、Bluetooth通信規格に従った同一のコネクションハンドルを有する複数のデータパケットが生成され、
    前記第２の工程では、該データパケットに含まれるデータの大きさから処理の優先順位を決定し、
    前記第３の工程では、該決定された優先順位に従って該データパケットを処理し、
    同一のコネクションハンドルを有するデータパケットのうち、優先順位の高いデータパケットを優先的に処理することを特徴とする通信方法。

Images