図面 (/)

技術 送信方法および送信装置

出願人 ラピスセミコンダクタ株式会社
発明者 汪超
出願日 2004年3月15日 (16年8ヶ月経過) 出願番号 2004-071905
公開日 2005年9月22日 (15年2ヶ月経過) 公開番号 2005-260768
状態 特許登録済
技術分野 小規模ネットワーク(3)ループ,バス以外 通信制御 移動無線通信システム
主要キーワード 保証要求 優先アプリケーション ベンダコマンド ギャランティ サービス要 非優先データ 上位部分 下位部分
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2005年9月22日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (7)

課題

パケット等に、優先順位を表すデータを含ませることができない通信プロトコルにおいて、QoSを保証したサービスを可能にした方法および装置を提供する。

解決手段

論理リンク管理層26は、送信すべきデータ64、70を、このデータに対して要求される送信の優先順位に応じて、300バイトまたは100バイトのデータに分割し、分割されたデータを含むHCIデータパケット66、72を生成する。リンクマネージャ層32は、HCIデータパケット66、72に含まれるデータの大きさから送信の優先順位を決定し、決定された優先順位に従って優先バッファ74と非優先バッファ76に振り分けた後、HCIデータパケット66、72を送信する。

概要

背景

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

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

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

Bluetooth通信規格に従った通信装置は、1つの装置が、ホストと呼ばれる上位部分と、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通信規格に従った通信プロトコルに限って生じるものではなく、パケット等の送信時のデータ単位に、優先順位を表すデータ(たとえば優先順位を表すフラッグ)を含ませることができない通信プロトコルにも生じる。

特開平7—58809号公報
特開2000−115240号公報

概要

パケット等に、優先順位を表すデータを含ませることができない通信プロトコルにおいて、QoSを保証したサービスを可能にした方法および装置を提供する。論理リンク管理層26は、送信すべきデータ64、70を、このデータに対して要求される送信の優先順位に応じて、300バイトまたは100バイトのデータに分割し、分割されたデータを含むHCIデータパケット66、72を生成する。リンクマネージャ層32は、HCIデータパケット66、72に含まれるデータの大きさから送信の優先順位を決定し、決定された優先順位に従って優先バッファ74と非優先バッファ76に振り分けた後、HCIデータパケット66、72を送信する。

目的

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

効果

実績

技術文献被引用数
1件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

複数の端末間で送受信されるデータの送信方法において、送信すべきデータを、該データに対して要求される送信の優先順位に応じて、所定の大きさのデータに分割し、該分割されたデータを含むデータ単位を生成する第1の工程と、該生成されたデータ単位に含まれるデータの大きさから送信の優先順位を決定する第2の工程と、該決定された優先順位に従って該データ単位を送信する第3の工程とを含むことを特徴とする送信方法。

請求項2

請求項1に記載の送信方法において、前記データ単位は、Bluetooth通信規格に従ったデータパケットであることを特徴とする送信方法。

請求項3

請求項2に記載の送信方法において、前記第1の工程では、Bluetooth通信規格に従った同一のコネクションハンドルを有する複数のデータパケットが生成され、前記第2の工程では、該データパケットに含まれるデータの大きさから送信の優先順位を決定し、前記第3の工程では、該決定された優先順位に従って該データパケットを送信し、同一のコネクションハンドルを有するデータパケットのうち、優先順位の高いデータパケットを優先的に送信できることを特徴とする送信方法。

請求項4

請求項1から3までのいずれかに記載の送信方法において、前記第2の工程では、優先順位が決定されると、前記データ単位を、優先順位に応じて設けられた複数のデータバッファのいずれかに格納し、前記第3の工程では、優先順位の高いデータ単位が格納された前記データバッファにある前記データ単位を優先的に送信することを特徴とする送信方法。

請求項5

複数の端末間で送受信されるデータの受信方法において、送信すべきデータを、該データに対して要求される送信の優先順位に応じて、所定の大きさのデータに分割し、該分割されたデータを含むデータ単位を生成し、該生成されたデータ単位に含まれるデータの大きさから送信の優先順位を決定し、該決定された優先順位に従って該データ単位を送信することにより送信されたデータ単位を受信する第1の工程と、該受信したデータ単位に含まれるデータの大きさから、該受信したデータ単位の処理の優先順位を決定する第2の工程と、決定された優先順位に従って、複数の該受信したデータ単位から、前記送信すべきデータを構成する第3の工程とを含むことを特徴とする受信方法。

請求項6

複数の端末間で送受信されるデータの送信装置において、送信すべきデータを、該データに対して要求される送信の優先順位に応じて、所定の大きさのデータに分割し、該分割されたデータを含むデータ単位を生成するデータ生成部と、該生成されたデータ単位に含まれるデータの大きさから送信の優先順位を決定し、該決定された優先順位に従って該データ単位を送信するデータ送信部とを含むことを特徴とする送信装置。

請求項7

請求項6に記載の送信装置において、前記データ単位は、Bluetooth通信規格に従ったデータパケットであることを特徴とする送信装置。

請求項8

請求項7に記載の送信装置において、前記データ生成部は、Bluetooth通信規格に従った同一のコネクションハンドルを有する複数のデータパケットを生成し、前記データ送信部は、該データパケットに含まれるデータの大きさから送信の優先順位を決定し、該決定された優先順位に従って該データパケットを送信し、同一のコネクションハンドルを有するデータパケットのうち、優先順位の高いデータパケットを優先的に送信できることを特徴とする送信装置。

請求項9

請求項5から8までのいずれかに記載の送信装置において、前記データ送信部は、優先順位が決定されると、前記データ単位を、優先順位に応じて設けられた複数のデータバッファのいずれかに格納し、優先順位の高いデータ単位が格納された該データバッファにある前記データ単位を優先的に送信することを特徴とする送信装置。

請求項10

複数の端末間で送受信されるデータの受信装置において、送信すべきデータを、該データに対して要求される送信の優先順位に応じて、所定の大きさのデータに分割し、該分割されたデータを含むデータ単位を生成し、該生成されたデータ単位に含まれるデータの大きさから送信の優先順位を決定し、該決定された優先順位に従って送信された該データ単位を受信するデータ受信部と、該受信したデータ単位に含まれるデータの大きさから、該受信したデータ単位の処理の優先順位を決定し、該決定された優先順位に従って、複数の該受信したデータ単位から、前記送信すべきデータを構成するデータ構成部とを含むことを特徴とする受信装置。

請求項11

複数の端末間で送受信されるデータの通信方法において、処理すべきデータを、該データに対して要求される処理の優先順位に応じて、所定の大きさのデータに分割し、該分割されたデータを含むデータ単位を生成する第1の工程と、該生成されたデータ単位に含まれるデータの大きさから処理の優先順位を決定する第2の工程と、該決定された優先順位に従って該データ単位を処理する第3の工程とを含むことを特徴とする通信方法。

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

0005

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

0006

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

0007

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

0008

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

0009

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

0010

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

0011

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

0012

特開平7—58809号公報
特開2000−115240号公報

発明が解決しようとする課題

0013

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

課題を解決するための手段

0014

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

発明の効果

0015

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

0016

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

発明を実施するための最良の形態

0017

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

0018

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

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

0019

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

0020

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

0021

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

0022

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

0023

無線通信装置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を介してデータのやり取りを行う。

0024

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

0025

アプリケーション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とデータのやり取りを行う。

0026

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

0027

図2に、図1に示す無線通信装置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とのデータのやり取りを行わせる。

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

論理リンク管理層26は、直接の下位の層であるHCIドライバ28に対して、コネクションハンドルを含むデータ単位であるHCIデータパケット26-3を出力する。同一の通信相手に対して、論理リンク管理層26から、複数の異なるチャネル識別子CID1, CID2, CID3のL2CAPデータパケット18-1a, 18-2a, 18-3aをHCIドライバ28に出力するとき、論理リンク管理層26は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を介して送信される。

0038

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

0039

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

0040

相手側の通信装置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に送る。

0041

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

0042

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

0043

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

0044

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

0045

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 は存在しないこともある。

0046

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

0047

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

0048

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

0049

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

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

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

0063

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

0064

これを、図5を参照してさらに説明する。要求アプリケーション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に送出する。

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

0074

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

0075

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

0076

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

0077

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

0078

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

0079

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

0080

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

0081

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

0082

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

0083

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

0084

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

0085

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

0086

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

0087

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

図面の簡単な説明

0088

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

符号の説明

0089

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ