JP4690144B2 - 拡張ＶｏＩＰ（ボイス・オーバ・インターネット・プロトコル） - Google Patents

Description

本発明は、一般に、電気通信システムに関し、より詳細には、無線通信システムに関する。

一般に、音声およびデータは、２つの基本的な交換技術を用いて有線および／または無線ネットワークを介して送信することができる。従来の音声電話通話、ならびにモデムによって提供されるデータは、回線交換接続を用いて送信される。あるいは、音声およびデータは、ボイス・オーバ・インターネット・プロトコル（しばしば、ＶｏＩＰと呼ばれる）を用いて、パケット交換ネットワークを介して伝送することもできる。回線交換ネットワークとパケット交換ネットワークは共に、有線接続および／または無線接続を含むことができる。ボイス・オーバ・インターネット・プロトコルは、ますます一般的なものとなっているが、それは、少なくとも一つには、ＶｏＩＰが音声通信とデータ通信を同種のものとして処理できるという理由による。さらに、ＶｏＩＰを用いて音声を送信することは、運用コストを低減するのに役立つ。ＰＤＡ（ｐｅｒｓｏｎａｌ ｄａｔａ ａｓｓｉｓｔａｎｔ、携帯情報端末）やラップトップ・コンピュータ、デスクトップ・コンピュータなどの装置に音声通信を組み込むために、従来の陸上回線電話および携帯電話（ｃｅｌｌｕｌａｒ ｔｅｌｅｐｈｏｎｅ）に加えて、ＶｏＩＰを使用することができる。

ＶｏＩＰなどのインターネット・プロトコルは、多種多様のネットワーク（例えば、ローカル・エリア・ネットワーク、広域ネットワーク、およびワールド・ワイド・ウェブ）を実施するために使用されるが、代替の通信プロトコルもまた、他のタイプのネットワークを形成するのに使用することができる。例えば、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）規格は、メンバー装置の定義された組を有する、時にはピコネットとも呼ばれる近距離無線ネットワークを実施するために一般に使用される。ブルートゥース互換装置は、周波数ホッピング技法を用いて、約２．４ＧＨｚの産業科学医療（ＩＳＭ）バンド中で、データおよび／または音声を送信する。このブルートゥース規格は当業者に周知のものであり、したがって、明確化のため、本発明にとって重要なブルートゥース規格の側面についてのみ本明細書で述べるものとする。

ブルートゥース規格に準拠する装置は、音声の実時間的性質を維持するために回線交換プロトコルを使用し、音声通信を無線インターフェースまたは無線通信リンクを介して送信することができる。ブルートゥース規格によると、さらに、準拠する装置はインターネット・プロトコルを用いてデータを送信することもできる。一つにはブルートゥース規格の周波数ホッピング特性によって、ブルートゥース規格に従って形成された通信リンクは、干渉の存在下でリンク品質を維持できる可能性を十分有している。したがって、ブルートゥース規格は、ＶｏＩＰベースの音声およびデータ通信ソリューションを組み込むための良い候補である。しかし、現在のブルートゥース規格はまた、ＶｏＩＰベースの音声通信およびデータ通信をその規格内で実施することに干渉する、あるいは妨げるおそれのあるいくつかの欠点を有する。

図１は、従来のブルートゥース・スタック１００を概念的に示す。当業者であれば、この従来のブルートゥース・スタック１００が、見やすくするために図１に示していない追加のエレメントを含み得ることを理解されたい。さらに、当業者であれば、図１に示すエレメントおよび／またはその組合わせを、単一の装置中であるいは複数の装置中で実施可能であることも理解されたい。ブルートゥース・スタック１００は、ＷＡＥ（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）ブロック１０５、ＴＣＳ Ｂｉｎ（Ｔｅｌｅｐｈｏｎｙ Ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｂｉｎａｒｙ）ブロック１１０、オーディオ・ブロック１１５、および／またはブルートゥース仕様で定義された他のブロックで、様々な通信を受信することができる。

例えば、パケットは、ＷＡＥブロック１０５によって受信され、ＷＡＰ（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ブロック１２０、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ブロック１２２、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ブロック１２４、ＩＰ（インターネット・プロトコル）ブロック１２６、ＰＰＰ（ポイント・ツー・ポイント・プロトコル）ブロック１２８を介して、次いで、ＲＦＣＯＭＭ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）ブロック１３０へと渡され、そこで、他のパケット・フローと多重化することもできる。ＲＦＣＯＭＭブロック１３０は、多重化された信号をＬ２ＣＡＰ（Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ ａｎｄ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、論理リンク制御および適応プロトコル）ブロック１３２に送り、そのブロックはまた、ＴＣＳ Ｂｉｎ（Ｔｅｌｅｐｈｏｎｙ Ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｂｉｎａｒｙ）ブロック１１０から信号を受信することもできる。Ｌ２ＣＡＰブロック１３２は、ホスト・コントローラ・インターフェース１３４を介して、ベースバンド・ブロック１３８中の非同期接続コントローラ１３６に信号を送る。他の実施例では、オーディオ・ブロック１１５でオーディオ信号を受信することができ、それは、ベースバンド・ブロック１３８中の同期コントローラ１４０に信号を送る。同期コントローラ１４０は、通常、オーディオ信号に対する事前定義の品質および遅延制約を維持するよう試みる。ベースバンド・ブロック１３８は、ＬＭＰ（Ｌｉｎｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）ブロック１４４の制御下で、無線インターフェースとも呼ばれる通信リンクを介して伝送するためのブルートゥース・ラジオ（Ｂｌｕｅｔｏｏｔｈ ｒａｄｉｏ）１４２に信号を送る。

図２は、汎用アクセス・ブルートゥース・プロファイル２００を概念的に示す。当業者であれば、プロファイルは、各プロトコル・レイヤ中の選択肢、ならびにプロトコルごとのパラメータ範囲を定義可能であることを理解されたい。当業者であればさらに、汎用アクセス・ブルートゥース・プロファイル２００は、見やすくするために、図２には示していない追加のプロファイルを含み得ることも理解されたい。汎用アクセス・ブルートゥース・プロファイル２００は、ＴＣＳ Ｂｉｎプロファイル２０５、シリアル・ポート・プロファイル２１０、およびブルートゥース規格によって定義できる他のプロファイルを含む。

現在のブルートゥース規格は、ローカル・エリア・ネットワーク・アクセス・プロファイル２１５、またはコードレス電話プロファイル２２０を用いて音声サービスを提供することができる。コードレス電話プロファイル２２０は、ＴＣＳ Ｂｉｎプロファイル２０５に依存しており、またローカル・エリア・ネットワーク・アクセス・プロファイル２１５は、シリアル・ポート・プロファイル２１０に依存している。ブルートゥース規格によると、第１のプロファイルが、第２のプロファイルを暗黙的にかつ／または明示的に参照することにより第２のプロファイルの部分を再使用する場合、第１のプロファイルは、第２のプロファイルに依存しているものと見なされる。音声通信にとって重要なローカル・エリア・ネットワーク・アクセス・プロファイル２１５およびコードレス電話プロファイル２２０の側面については、以下で検討するものとする。

コードレス電話プロファイル２２０は、２つの役割、すなわち、ゲートウェイおよび端末を定義する。コードレス電話プロファイル２２０は、通常、１つのゲートウェイと、少数の端末、例えば、１から７の間の数の端末を含むトポロジをサポートする。ゲートウェイは、インターネット・プロトコル・ベースのネットワークなどの外部ネットワークに結合することができる。ゲートウェイは、外部ネットワークから見ると端末の終点として動作し、そのネットワークへのすべての相互作用を処理する。ゲートウェイは、外部のコールに対する中心点と見なされ、それは、ゲートウェイが、外部のネットワークへのかつ／または外部のネットワークからのセットアップ要求をすべて処理することを意味する。例えば、ゲートウェイは、カプセル化解除された元のＧ．７１１またはＧ．７３２音声パケットである音声パケットを受信することができる。ゲートウェイ装置は、ＰＳＴＮ（公衆電話交換網）のホーム基地局、ＩＳＤＮ（総合サービス・デジタル通信網）のホーム基地局、ＧＳＭゲートウェイ、サテライト・ゲートウェイ、Ｈ．３２３ゲートウェイを含むことができる。端末とは無線ユーザ端末のことであり、それは、コードレス電話、デュアルモードの携帯／コードレス電話、デスクトップ・コンピュータ、ラップトップ・コンピュータ、ＰＤＡ（ｐｅｒｓｏｎａｌ ｄａｔａ ａｓｓｉｓｔａｎｔ、携帯情報端末）などを含むことができる。例えば、端末は、Ｋ３コードレス電話プロファイルに従って動作する３イン１電話とすることができる。

図３は、図２に示すコードレス電話プロファイル２２０を用いて実施することが可能なＫ３コードレス電話プロファイル・スタック３００を概念的に示す。当業者であれば、本発明に重要なＫ３コードレス電話プロファイル・スタック３００のエレメントだけを本明細書に示していることを理解されたい。音声パケットは、電話アプリケーション３０５によって受信され、それは、その音声パケットおよび他の制御信号をＴＣＳ Ｂｉｎブロック３１０および音声同期化コントローラ３１５に送る。ＴＣＳ Ｂｉｎブロック３１０内のコール制御（ＣＣ）ブロック３２０は、音声同期化コントローラ３１５を有するインターフェース３２５、およびＬＭＰ（ｌｉｎｋ ｍａｎａｇｅｒ ｐｒｏｔｏｃｏｌ）ブロック３３５を有するインターフェース３３０を介して音声チャネルを管理する。例えば、コール制御ブロック３２０は、インターフェース３２５を介して、信号を音声同期化コントローラ３１５に送ることにより内部の音声経路を接続および／または接続解除することができ、またインターフェース３３０を介してＬＭＰ（ｌｉｎｋ ｍａｎａｇｅｒ ｐｒｏｔｏｃｏｌ）ブロック３３５に信号を送ることにより、音声同期化制御リンクを確立し、かつ／または解放すことができる。ＬＭＰ（ｌｉｎｋ ｍａｎａｇｅｒ ｐｒｏｔｏｃｏｌ）ブロック３３５は、非同期制御ブロック３３７に結合されている。

インターフェース３２５、３３０により、音声同期化コントローラ３１５が、電話アプリケーション３０５からベースバンド３４５中の同期コントローラ３４０への音声経路を直接制御することができる。したがって、通常、電話アプリケーション３０５は、保障された品質および／または遅延特性を取得することができる。しかし、音声同期化コントローラ３１５を含む音声経路がパケット・データを処理するためのプロトコル・レイヤを何も含んでいないため、パケット・データを提供する電話アプリケーション３０５の能力が危殆化する（ｃｏｍｐｒｏｍｉｓｅｄ）。他の実施例では、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）プロトコルに従って動作する電話は、音声アプリケーションを同様な方式で処理する。したがって、その技法によると、電話アプリケーション３０５からの音声通信はデータ・トラフィック・ストリームと同種のものとして処理されず、システムの柔軟性に望ましくない制限を加えるようになり得る。したがって、その技法は将来の第４世代（４Ｇ）システムの多くの機能を利用できないことになる。

図２に戻って参照すると、シリアル・ポート・プロファイル２１０中のローカル・エリア・ネットワーク・アクセス・プロファイル２１５を用いて、音声通信を行うこともできる。その手法では、ＶｏＩＰアプリケーションから受信したパケットが、他の任意のローカル・エリア・ネットワーク・アクセスと同様な方式で処理される。すなわち、そのＶｏＩＰアプリケーションは、好ましいトランスポート機構としてインターネット・プロトコルを利用する普通のインターネット・アプリケーションと見なされる。しかし、その手法は、ＶｏＩＰアプリケーションに、優先順位、品質保証、または遅延保証を何ら与えることはない。例えば、そのＶｏＩＰアプリケーションは、図１に示すベースバンド１３８中の非同期接続１３６など、非同期接続を介してベースバンド・レイヤで接続されている。他の実施例では、ＶｏＩＰアプリケーションに関連するパケットは、図１に示すＲＦＣＯＭＭ１３０などのＲＦＣＯＭＭシリアル・ポートを用いて、他のアプリケーション１４６からのパケットとコンテンション（ｃｏｎｔｅｎｔｉｏｎ）式に多重化される。他のアプリケーション１４６からのパケットは、ＶｏＩＰアプリケーションと競争（ｃｏｍｐｅｔｅ）および／または競合（ｃｏｎｆｌｉｃｔ）を起こす可能性がある。さらに、シリアル・ポート・プロファイル２１０を用いることは、ＶｏＩＰアプリケーションによって提供されるパケットに、ブルートゥース・スタック中のさらに多くの制御ブロックを通過させることになる可能性もある。
本発明は、上述の１つまたは複数の問題による結果に対処することを対象としている。

本発明の一実施形態では、定義された組に属する複数の装置がその中で互いに通信するネットワークを介して、音声または他の時間依存型のパケット・データを送信するための方法が提供される。本方法は、音声データを含む少なくとも１つの第１のパケットを受信すること、実時間のパケット対応スタックを用いて、少なくとも１つの第２のパケットを形成するように少なくとも１つの第１のパケットを処理すること、およびネットワークを介して送信するために、その少なくとも１つの第２のパケットを同期コントローラに送ることを含む。

本発明の他の実施形態では、定義された組に属する複数の装置がその中で互いに通信する第１のネットワークから、音声または他の時間依存型のパケット・データを受信するための方法が提供される。本方法は、第１のネットワークから音声データを含む少なくとも１つのパケットを受信すること、その少なくとも１つのパケットを同期コントローラに送ること、およびその少なくとも１つのパケットを実時間のパケット対応スタックを用いて処理することを含む。
本発明は、添付の図面と共に以下の説明を参照することにより理解することができよう。図中、同様な参照番号は、同様なエレメントを識別する。

本発明は、様々な変更および代替形態を行うことが可能であるが、例示のために、その特有の諸実施形態を図面で示し、ここで詳細に説明する。しかし、その特有の実施形態の説明は、本発明を開示された特定の形態に限定するものではなく、反対に、本発明は、添付の特許請求の範囲で定義された本発明の趣旨および範囲に含まれる変更形態、等価な形態、および代替策をすべて包含することを意図していることを理解されたい。

本発明の例示的な諸実施形態を以下に説明する。明確化のために、実際の実装についての機能のすべてを本明細書中に述べてはいない。このような実際の実施形態の開発において、実装形態ごとに変化するシステムおよびビジネスに関係する制約の順守など、開発者特有の目標を達成するために、数多くの実装特有の決定を行わなければならないことも当然理解されよう。さらに、かかる開発努力は複雑で時間のかかることかもしれないが、それは、本開示の利益を受ける当業者によって行われる通常の手順（ｒｏｕｔｉｎｅ）であることが理解されよう。

図４は、定義された組４１５に属する複数の装置４０５、４１０（１〜３）が、その中で互いに通信するネットワーク４００を概念的に示している。本明細書では、本発明をブルートゥース規格に即して説明する。したがって、例示の実施形態では、定義された組４１５は、ブルートゥース規格に準拠したピコネット４１５である。複数の装置４０５、４１０（１〜３）は、ブルートゥース対応装置であり、具体的には、装置４０５がマスターであり、装置４１０（１〜３）はスレーブである。しかし、本発明は、ブルートゥース規格に限定するものではない。当業者であれば、ブルートゥース規格は、定義された組４１５に属する複数の装置４０５、４１０（１〜３）相互間で容易に通信するために使用できる規格の一実施例に過ぎないということを理解されたい。代替の実施形態では、いわゆる「ネットワーク内ネットワーク（ｎｅｔｗｏｒｋ−ｗｉｔｈｉｎ−ａ−ｎｅｔｗｏｒｋ）」規格など所望の任意の規格を使用することもできる。

図４に示すピコネット４１５は、１つのマスター４０５と、３つのスレーブ４１０（１〜３）を含む。しかし、当業者であれば、本発明は、４つの装置に限定するものではないことを理解されたい。代替の実施形態では、ピコネット４１５には、４１０（１〜３）より多くのまたは少数のスレーブを含むことができる。例えば、ブルートゥース規格によると、通常、ピコネット４１５中に１から７の間の数のスレーブ４１０（１〜３）を含むことができる。各スレーブ４１０（１〜３）は、マスター４０５と通信リンク４１７（１〜３）を形成することができる。しかし、スレーブ４１０（１〜３）は、通常、他の各スレーブ４１０（１〜３）と通信リンクを形成しない。

マスター４０５はまた、第２のネットワーク４２０と通信リンク４１８を形成することができる。一実施形態では、第２のネットワーク４２０はまた、ピコネットなどのブルートゥース対応ネットワークであり、その場合、マスター４０５は、第２のネットワーク４２０中の第２のマスター（図示せず）と通信リンクを確立する。しかし、本発明は、ブルートゥース対応ネットワーク相互間の通信に限定しない。代替の実施形態では、第２のネットワーク４２０は、所望の任意のタイプのネットワークとすることもできる。例えば、第２のネットワーク４２０は、ローカル・エリア・ネットワーク、広域ネットワーク、ワールド・ワイド・ウェブ、ＩＳＤＮ（総合サービス・デジタル通信網）ネットワーク、イントラネットなどのインターネット・プロトコルに準拠したネットワークを含むことができる。あるいは、第２のネットワーク４２０は、公衆電話交換網、ＰＯＴＳ（ｐｌａｉｎ ｏｌｄ ｔｅｌｅｐｈｏｎｅ ｓｅｒｖｉｃｅ）ネットワーク、コードレス電話ネットワーク、携帯電話ネットワーク、サテライト・ネットワークなどとすることもできる。当業者であれば、第２のネットワーク４２０はまた、前述の諸ネットワークの様々な組合わせから形成され得ることを理解されたい。

マスター４０５は、実時間のパケット対応スタック４２５を含み、各スレーブ４１０（１〜３）は、実時間のパケット対応スタック４３０（１〜３）を含む。実時間のパケット対応スタック４２５、４３０（１〜３）は、一緒に動作する１組のネットワーク・プロトコル・レイヤであり、以下で詳細に述べる。しかし、当業者であれば、スタックという用語はまた、実時間のパケット対応スタック４２５、４３０（１〜３）によって定義されるプロトコルを処理する実際のソフトウェアおよび／またはハードウェアを指すこともできることを理解されたい。したがって、本明細書の詳細な説明のいくつかの部分は、コンピューティング・システムまたはコンピューティング装置中のメモリ内のデータ・ビットに対する動作の記号表示を含むソフトウェアで実施されるプロセスに関して示される。それらの説明および表示は、当業者が自分の仕事内容を他の当業者に最も効率的に伝えるために用いられる手段である。そのプロセスおよび動作は、物理量の物理的な操作が必要である。通常、必ずしも必要なことではないが、それらの量は、記憶され、転送され、組み合わされ、比較され、また他の方法で操作されることが可能な電気的、磁気的、または光学的な信号の形をとる。主として、一般に使用されているという理由で、その信号を、ビット、値、エレメント、記号、文字、語句、数字などと呼ぶのが便利な場合もあることが分っている。

しかし、それらのまた類似の用語はすべて、適切な物理量と関連付けられるべきものであり、またその量に適用される簡易的なラベルに過ぎないことに留意されたい。本開示を通じて、具体的に述べていなければ、あるいは自明でない限り、それらの記述は、何らかの電子装置のストレージ内の物理（電子、磁気、光学）的な量として表されるデータを操作し、かつそのデータを、ストレージ内の、または送信装置もしくは表示装置中の物理量として同様に表される他のデータへと変換する電子装置のアクションおよびプロセスを指すものとする。このような記述を示す用語の実施例としては、限定するものではないが、用語「処理すること（ｐｒｏｃｅｓｓｉｎｇ）」、「コンピュータ処理すること（ｃｏｍｐｕｔｉｎｇ）」、「計算すること（ｃａｌｃｕｌａｔｉｎｇ）」、「判定すること（ｄｅｔｅｒｍｉｎｉｎｇ）」、「表示すること（ｄｉｓｐｌａｙｉｎｇ）」などがある。

ソフトウェアで実施される本発明の態様は、通常、プログラム記憶媒体の何らかの形態上にエンコードされ、または伝送媒体の何らかのタイプを介して実施されることにも留意されたい。プログラム記憶媒体は、磁気的な物（例えば、フロッピー（登録商標）・ディスクまたはハード・ドライブ）、または光学的な物（例えば、コンパクト・ディスク読出し専用メモリ、すなわち「ＣＤ−ＲＯＭ」）とすることができ、また読出し専用またはランダム・アクセスとすることもできる。同様に、伝送媒体は、ツイストペア線、同軸ケーブル、光ファイバ、無線通信リンク（「無線インターフェース」と呼ばれることもある）、または当技術分野で知られている何らかの他の適切な伝送媒体とすることができる。本発明は、所与の任意の実装形態のその態様によって限定されることはない。

実時間のパケット対応スタック４２５、４３０（１〜３）は、通信リンク４１７（１〜３）、４１８を介して音声データを交換するのに使用される。一実施形態では、その実時間のパケット対応スタック４２５、４３０（１〜３）は、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）に従って音声パケット・データを処理する。しかし、本発明は、ＶｏＩＰに限定するものではなく、代替の実施形態では、音声パケット・データを処理するために、所望の任意のプロトコルをその実時間のパケット対応スタック４２５、４３０（１〜３）中で実施することができる。

実時間のパケット対応スタック４２５、４３０（１〜３）を用いて音声パケット・データを処理することにより、マスター４０５およびスレーブ４１０（１〜３）は、マスター４０５と１つまたは複数のスレーブ４１０（１〜３）の間で、またはマスター４０５と第２のネットワーク４２０の間で音声パケット・データを送信するときに望ましい品質保証および／または遅延保証を提供することができる。さらに、マスター４０５およびスレーブ４１０（１〜３）によって処理される音声パケットは、時間依存型ではないデータ・パケットよりも高い優先順位で処理することができる。

一実施形態では、ピコネット４１５は、第２のネットワーク４２０など既存の電話ネットワークを拡張または増設するのに使用することができる。ピコネット４１５を用いて、第２のネットワーク４２０を拡張または増設することは、第２のネットワーク４２０を直接拡張または増設することよりも大幅に経費を下げることができる。例えば、オフィスビルに専用の追加の携帯電話タワーを設けることによってオフィスビル中の携帯電話ネットワークを拡張または増設するには、膨大な経費がかかる可能性がある。実時間のパケット対応スタック４２５、４３０（１〜３）を含むピコネット４１５によると、非常に低い経費で設置することができる。

図５は、実時間のパケット対応スタック５０５を含むブルートゥース・スタック５００を概念的に示す。上記のように、ブルートゥース・スタック５００は、ＷＡＥブロック５０８、ＴＣＳ Ｂｉｎブロック５１０、オーディオ・ブロック５１５、ＷＡＰブロック５２０、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ブロック５２２、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ブロック５２４、ＩＰ（インターネット・プロトコル）ブロック５２６、ＰＰＰ（ポイント・ツー・ポイント・プロトコル）ブロック５２８、ＲＦＣＯＭＭ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ）ブロック５３０、Ｌ２ＣＡＰ（Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ ａｎｄ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、論理リンク制御および適応プロトコル）ブロック５３２、ホスト・コントローラ・インターフェース５３４、非同期接続コントローラ５３６、ベースバンド・ブロック５３８、リンク・マネジメント・プロトコル・ブロック５４４、および通信リンクを介して無線インターフェース中に記号（ｓｙｍｂｏｌ）を送信するためのブルートゥース・ラジオ５４２を含むことができる。

ブルートゥース・スタック５００が送信モードで使用されたとき、オーディオ・ブロック５１５は、１つまたは複数の音声パケットを受信し処理する。当業者であれば、１つまたは複数の音声パケットを処理することは、ヘッダの追加もしくは除去すること、１つまたは複数の音声パケットの経路指定をすること、複数の音声パケットを連結すること、音声パケットを分割すること、あるいは他の任意の方式で音声パケットを変更することを含むことができることを理解されたい。次いで、オーディオ・ブロック５１５は、その１つまたは複数の音声パケットを、実時間のパケット対応スタック５０５に送る。例示の実施形態では、実時間のパケット対応スタック５０５は、ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）ブロック５４６、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ブロック５４８、ＩＰ（インターネット・プロトコル）ブロック５５０、およびＰＰＰ（ポイント・ツー・ポイント・プロトコル）ブロック５５２を含む。

しかし、本発明は、その特定の組のプロトコルに限定されるものではなく、代替の実施形態では、実時間のパケット対応スタック５０５は、音声パケットの実時間処理を実施するために、プロトコル・レイヤの所望の任意の組合わせを用いることもできる。さらに、代替の一実施形態では、実時間のパケット対応スタック５０５を分岐することが可能であり、それによって、第１の分岐が元の音声処理を扱い、また第２の分岐を帯域幅区分のために確保することができる。例えば、分岐された実時間のパケット対応スタック５０５により、多重化された時間依存型のインターネット・プロトコル・データ・フローを処理することができる。

実時間のパケット対応スタック５０５は、処理された音声パケットを同期コントローラ５５５に送る。同期コントローラ５５５は、音声パケットに対する事前定義の品質と遅延の制約を維持するよう試みる。同期コントローラ５５５によって受信された音声パケットは、非同期コントローラ５３６によって受信されたパケットよりも高い優先順位が与えられる。さらに、実時間のパケット対応スタック５０５および同期コントローラ５５５によって処理された音声パケットは、他のアプリケーション５６０からのパケットと競合／または競争しないはずである。次いで、同期コントローラ５５５およびベースバンド・ブロック５３８は、無線インターフェースを介して送信するために、１つまたは複数の音声パケットに基づく信号をブルートゥース・ラジオ５４２に送る。

ブルートゥース・スタック５００が受信モードで使用されたとき、ブルートゥース・ラジオ５４２は、無線インターフェースを介して１つまたは複数の音声パケットを受信し、その受信した１つまたは複数の音声パケットをベースバンド５３８中の同期コントローラ５５５に送る。前に検討したように、同期コントローラ５５５は、受信した音声パケットの優先順位付けを行い、さらに、受信した音声パケットに対して品質保証および／または遅延保証を提供することができる。同期コントローラ５５５は、受信した音声パケットを処理し、次いで、それを実時間のパケット対応スタック５０５に送り、それはさらに、受信した音声パケットを処理し、次いで、それをオーディオ・ブロック５１５に送る。次いで、オーディオ・ブロック５１５からの１つまたは複数の信号を、図４に示す第２のネットワーク４２０などの外部ネットワークに送信するために、中継器（図示せず）に送ることができる。

音声パケットは、ＳＣＯ（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｃｏｎｔｒｏｌ ｏｂｊｅｃｔ）ハンドルを含んでいるため、もともと前述のインターフェース・システムへの識別可能なマッピングを有している。したがって、少なくとも一つにはその識別可能なＳＣＯハンドルを有していることにより、追加の制御プロトコルをそのＳＣＯハンドルに結合することによって、音声サービスに追加の拡張を行うことができる。例えば、適切なプロトコル拡張により制御タイプ・フィールドがＴＣＳ Ｂｉｎブロック５１０に公開されることになる追加のプロトコル拡張を、ＳＩＰなど追加のＶｏＩＰシグナリング・プロトコルと組み合わせることができる。さらに、標準の携帯電話の移動性（ｍｏｂｉｌｉｔｙ）の代わりに、モバイル・インターネット・プロトコルを示すフィールド拡張を含むことにより、同様な方式で移動性を拡張することもできる。

図６は、コードレス電話プロファイル・スタック６００の例示的な実施形態を概念的に示す。当業者であれば、本明細書に重要なコードレス電話プロファイル６００のエレメントだけをここに示していることを理解されたい。明確化のために、コードレス電話プロファイル６００の動作を送信モードで動作する装置に関して説明する。しかし、当業者であれば、コードレス電話プロファイル６００はまた、上記で詳細に述べたように、受信モードでも動作できることを理解されたい。

その動作においては、電話アプリケーション６０５は、１つまたは複数の音声パケットおよび他の制御信号を形成し、かつ／またはそれをＴＣＳ Ｂｉｎブロック６１０および音声同期化コントローラ６１５に送る。例えば、電話アプリケーション６０５は、ＶｏＩＰに準拠する少なくとも１つのパケットを提供するインターネット電話アプリケーションとすることができる。ＴＣＳ Ｂｉｎブロック６１０内のコール制御（ＣＣ）ブロック６２０は、音声同期化コントローラ６１５を有するインターフェース６２５を介して音声チャネルを管理する。コール制御（ＣＣ）ブロック６２０はまた、ＬＭＰ（Ｌｉｎｋ Ｍａｎａｇｅｒ Ｐｒｏｔｏｃｏｌ）ブロック６３５を有するインターフェース６３０を介して音声チャネルも管理する。例えば、コール制御ブロック６２０は、インターフェース６２５を介して、音声同期化コントローラ６１５に信号を送ることにより内部の音声経路を接続し、かつ／または接続解除することができる。コール制御ブロック６２０はまた、インターフェース６３０を介して、リンク・マネジャ・プロトコル・ブロック６３５に信号を提供することにより音声同期化制御リンクを確立し、かつ／または解放することもできる。

インターフェース６２５、６３０により、音声同期化コントローラ６１５は、電話アプリケーション６０５から、実時間のパケット対応スタック６３７およびベースバンド６４５中の同期コントローラ６４０への音声経路を直接制御できるようになる。したがって、コードレス電話スタック６００によって送信された音声パケットに対して、電話アプリケーション６０５は、保証された品質および／または保証された遅延を得ることになる。電話アプリケーション６０５によって提供された音声パケットはまた、より時間に依存しない他のデータ・パケットよりも高い優先順位で処理され得る。したがって、その技法によると、電話アプリケーション６０５からの音声パケットは、ベースバンド６４５中の非同期コントローラ６５０によって処理されたデータ・パケットなどのデータ・トラフィック・ストリームと共に、同種のものとして処理され得る。したがって、実時間のパケット対応スタック６３７を含むコードレス電話プロファイル６００は、将来の第４世代（４Ｇ）システムで採用するのに特によく適している可能性がある。

上記で開示された特定の諸実施形態は例示的なものに過ぎないが、本明細書の教示の利益を受ける当業者にとって明らかな、異なるが等価な方法で、本発明を変更し実施することが可能である。さらに、以下の特許請求の範囲に記載のもの以外には、本明細書に示した構成または設計の詳細に対して限定することを意図していない。したがって、上記で開示された特定の諸実施形態を改変または変更することが可能であり、そのような変形形態がすべて、本発明の範囲および趣旨に含まれると見なされることは明らかである。したがって、本明細書で求められている保護は、以下の特許請求の範囲に記載されている。

従来のブルートゥース・スタックを概念的に示す図である。 シリアル・ポート・プロファイルおよびコードレス電話プロファイルを含む汎用アクセス・ブルートゥース・プロファイルを概念的に示す図である。 図２に示すコードレス電話プロファイルとして使用できるＫ３コードレス電話プロファイルを概念的に示す図である。 本発明による、定義された組に属する複数の装置が互いにその中で通信するネットワークを概念的に示す図である。 本発明による、図４に示すネットワークで使用できる実時間のパケット対応スタックを含むブルートゥース・スタックを概念的に示す図である。 本発明による、図５に示すブルートゥース・スタック中で使用できるコードレス電話プロファイル・スタックの例示的な実施形態を概念的に示す図である。

Claims (10)

1. 定義された組に属する複数の装置がその中で互いに通信するネットワークを介して、時間依存型のパケット・データを送信するための方法であって、
   前記定義された組からの第１の装置において実施され、
   音声データを含む少なくとも１つの第１のパケットを前記第１の装置において実装された第１のプロトコル・スタックで受信する工程と、
   実時間のパケット対応スタックを用いて、少なくとも１つの第２のパケットを形成するように前記少なくとも１つの第１のパケットを処理し、前記実時間のパケット対応スタックが、前記第１のプロトコル・スタックにおいて実装されている工程と、
   前記ネットワークを介して送信するために、前記第１のプロトコル・スタックにおいて前記少なくとも１つの第２のパケットを同期コントローラに送る工程と
   を含む方法。
2. 前記少なくとも１つの第１のパケットを受信する前記工程が、電話アプリケーションから前記少なくとも１つの第１のパケットを受信する工程を含む、請求項１に記載の方法。
3. 前記実時間のパケット対応スタックを用いて、前記少なくとも１つの第１のパケットを処理する前記工程が、ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）スタック、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）スタック、ＩＰ（インターネット・プロトコル）スタック、およびＰＰＰ（ポイント・ツー・ポイント・プロトコル）スタックを用いて、前記少なくとも１つの第１のパケットを処理する工程を含む、請求項１に記載の方法。
4. 前記少なくとも１つの第２のパケットを前記同期コントローラに送る前記工程が、前記少なくとも１つの第２のパケットを、ベースバンド・スタック中の同期コントローラに送る工程を含む、請求項１に記載の方法。
5. 前記同期コントローラに送られた前記少なくとも１つの第２のパケットに基づく信号を、無線ネットワークを介して送信する工程を含む、請求項１に記載の方法。
6. 定義された組に属する複数の装置がその中で互いに通信する第１のネットワークから、時間依存型のパケット・データを受信するための方法であって、
   前記定義された組からの第１の装置において実施され、
   前記第１のネットワークから音声データを含む少なくとも１つのパケットを前記第１の装置内の第１のプロトコル・スタックの一部であるベースバンド・スタックで受信する工程と、
   前記第１のプロトコル・スタックにおいて前記少なくとも１つのパケットを同期コントローラに送る工程と、
   前記少なくとも１つのパケットを前記第１のプロトコル・スタックにおいて実装されている実時間のパケット対応スタックを用いて処理する工程と
   を含む方法。
7. 前記第１のネットワークから前記少なくとも１つのパケットを受信する前記工程が、第１の無線ネットワークから前記少なくとも１つのパケットを受信する工程を含む、請求項６に記載の方法。
8. 前記第１の無線ネットワークを介して前記少なくとも１つのパケットを受信する前記工程が、前記少なくとも１つのパケットをブルートゥース・ラジオを用いてブルートゥース・ネットワークから受信する工程を含む、請求項７に記載の方法。
9. 前記少なくとも１つのパケットを前記同期コントローラに送る前記工程が、前記少なくとも１つのパケットをブルートゥース・スタック中の前記同期コントローラに送る工程を含む、請求項６に記載の方法。
10. 前記少なくとも１つのパケットを第２のネットワークに中継する工程を含む、請求項６に記載の方法。

Images