JP5028784B2 - 無線ｌａｎ電話システム、無線ｌａｎ電話システム親機、無線ｌａｎ電話システム子機、無線ｌａｎ電話通信方法、無線ｌａｎ電話通信プログラム、および、記録媒体 - Google Patents

Description

本発明は無線ＬＡＮを利用したコードレス電話システムに関するものであり、特に親機−子機間で音声を音声パケット化して送受信する無線ＬＡＮ電話システムに関するものである。

近年、ＶｏＩＰ技術を利用したＩＰ電話が普及している。ＩＰ電話では音声をパケット化して、インターネットや専用のネットワークを通して音声を送受信するため、通話コストが安く、また、大手プロバイダがさまざまな地域でサービスを提供しているため、最近では、企業だけでなく、多くの家庭でも利用されるようになった。さらに、最近では、ＩＰ電話機をコードレス化する動きも出てきた。例えば、親機でＩＰ電話のプロトコルを終端し、親機から子機は従来のコードレス電話機の方式で音声を子機とやりとりする製品も発表されている。そして、さらに、ＩＰ電話のプロトコルを親機で終端するのではなく、子機で終端できるようにし、その子機をホットスポットなどのような公共の無線アクセスポイントに持ち出して、安価に通話できるような無線ＬＡＮによるコードレス電話機も提案されている（例えば、特許文献１参照）。
特開２００２−２４７６４７号公報

このような構成のＩＰ電話システムでは、音声パケットの遅延が通話の品質を大きく関わることが知られている。特に遅延量が大きい場合には、話者の声が相手に届く前に、相手が発話してしまうという現象が発生してしまう。一般的に、片道の遅延が１５０ｍｓを超えると、このような現象が発生し、会話がちぐはぐになったり、利用者が不快に感じたりする。

多くの場合、無線ＬＡＮは、音声通話だけでなくデータ通信にも用いられる。そのため、データ通信中であっても通話が途切れたり、音声が必要以上に遅延したり、しないように配慮する必要がある。そこで、無線ＬＡＮにおける音声データの送受信では、各端末の音声通話用通信帯域を確保するために、しばしば、ＴＤＭ方式が用いられる。例えば、ＩＥＥＥ８０２．１１ｅで提案されているＨＣＣＡなどがそのひとつである。この方式では、アクセスポイントに収容される端末毎にタイムスロットが割り当てられ、各端末は自分に割り当てられたタイムスロット内で音声データの送受信を行う。このように音声はＴＤＭを利用して優先して送受信を行うことで、データ通信が行われても音が途切れたり、遅延が増大したりしないようにされている。

しかしながら、この方式では、予め決められたタイムスロットで送信を行うため、音声データが発生しても、次のタイムスロットが来るまでは送信待ちになる。しかも、このタイムスロットの間隔（以下、送信間隔と呼ぶ。通常、１０．２４ｍｓもしくは２０．４８ｍｓが用いられる。）と音声データの発生周期（以下、コーデック間隔と呼ぶ。通常、１０ｍｓ、２０ｍｓ、３０ｍｓが用いられる）を完全に一致させることは技術的に難しいため、最も悪い条件では、音声データが発生してから送信間隔に等しい時間だけ、「送信待ち」となって音声データを遅延させてしまうこととなる。無線ＬＡＮ電話では、コーデック間隔を小さくとり、送信間隔も同様に小さくとることで、遅延を許容範囲内に収めることができる。

以上のことから、無線ＬＡＮ上で音声通信とデータ通信が同時に行われた場合でも、音声の遅延が許容範囲内に収まるように通信を行うためには、音声を１０ｍｓ単位で音声パケット化した上で、無線ＬＡＮのタイムスロット間隔を１０．２４ｍｓで通信することが望ましい。

ところが、一方で、音声パケットはデータ量がすくないため、パケットを無線フレーム化するときに、無駄なオーバーヘッドが発生してしまうことが知られている。例えば、コーデック間隔が１０ｍｓの無線ＬＡＮコードレス電話システムでは、８ｂｉｔ・８ｋＨｚサンプリング、無圧縮では１パケット当り８０バイトとなり、ＩＥＥＥ８０２．１１ｂで提案されているフレーム・フォーマットを採用すると、音声のデータはフレームの約２５％を占めるに過ぎない。残りの約７５％はプリアンブルや各レイヤのプロトコルのヘッダであり、データ量の小さな音声パケットを無線フレーム化して送信すると非常に無駄が多いことがわかる（図１７参照）。このような状況下では、データ通信は音声データに圧迫され、トラフィックが著しく制限されてしまい、音声通話中はデータ通信に時間を要したり、また、アクセスポイント１つ当りの同時通話数が厳しく制限されたりする。

このようなことから、現在、無線ＬＡＮを利用するコードレス電話システムにおいては、遅延を許容範囲内に押さえ、なおかつ、必要以上に通信帯域を消費しないものが強く要望されている。

本発明は上述のような従来の技術の問題点に鑑みてなされたものであって、無線フレーム化の際のオーバーヘッドを削減して音声の遅延を少なくすることができ、さらに１アクセスポイントあたりの同時通話数を大きくすることができ、さらには、通話中にデータ通信を行う場合に、データ通信が使用できる帯域幅を大きく取ることができる無線ＬＡＮ電話システム、無線ＬＡＮ電話システム親機、無線ＬＡＮ電話システム子機、無線ＬＡＮ電話通信方法、無線ＬＡＮ電話通信プログラム、および、記録媒体を提供することを目的とする。

上記課題を解決するために、本発明の無線ＬＡＮ電話通信方法は、送信側では、音声の遅延許容時間から、音声のコーデック周期、音声のコーデック遅延×２、コーデック待ち時間、送信待ち時間、及び、予め指定されたネットワークの遅延量を差し引いた値である送信待ち許容時間を計算して、該送信待ち許容時間の範囲内で複数の音声パケットを、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰの少なくとも１つの送信上位プロトコルヘッダを解析し、該解析結果に基づいて共通部分が省略された１つのフレームに、まとめて送信するとともに、受信側では、１つのフレームにまとめられた複数の音声パケットを元通りに分割する。

また、本発明の無線ＬＡＮ電話システム子機は、音声の遅延許容時間から、音声のコーデック周期、音声のコーデック遅延×２、コーデック待ち時間、送信待ち時間、および、予め指定されたネットワークの遅延量を差し引いた値である送信待ち許容時間を算出する送信待ち許容時間算出部と、送信待ち時間内に入力された音声パケットをひとつのフレームにまとめて送信データを生成するペイロード統合部と、音声パケットのＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰの少なくとも１つの上位プロトコルヘッダを解析する上位プロトコル解析部と、受信データを元来ひとつの音声パケットであったか否か判断し、複数の音声パケットが統合されている場合に、前記受信データを複数の音声パケットに分解するペイロード分割部とを有し、前記上位プロトコル解析部は、音声パケットの上位プロトコルヘッダを解析し、前記ペイロード統合部は、前記上位プロトコル解析部による解析結果に基づいて、共通部分を省略した１つのフレームにまとめる。

また、本発明の無線ＬＡＮ電話システム親機は、無線フレーム−有線フレーム間で乗せかえを行うためのヘッダの付替えを行う有線−無線ブリッジ部を有する。

本発明によれば、無線フレーム化の際のオーバーヘッドを削減して音声の遅延を少なくすることができ、さらに１アクセスポイントあたりの同時通話数を大きくすることができ、さらには、通話中にデータ通信を行う場合に、データ通信が使用できる帯域幅を大きく取ることができる。

本発明の第１の発明の無線ＬＡＮ電話通信方法は、無線ＬＡＮを利用した電話システムにおいて、送信側では、音声の遅延許容時間から、音声のコーデック周期、音声のコーデック遅延×２、コーデック待ち時間、送信待ち時間、及び、予め指定されたネットワークの遅延量を差し引いた値である送信待ち許容時間を計算して、この送信待ち許容時間の範囲内で複数の音声パケットを、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰの少なくとも１つの送信上位プロトコルヘッダを解析し、該解析結果に基づいて共通部分が省略された１つのフレームに、まとめて送信するとともに、受信側では、１つのフレームにまとめられた複数の音声パケットを元通りに分割する。この構成により、無線フレーム化の際のオーバーヘッドが軽減され、かつ、音声の遅延が縮小されるという作用を有する。

本発明の第２の発明の無線ＬＡＮ電話通信方法は、第１の発明の無線ＬＡＮ電話通信方法において、送信側と受信側にて、通信を行う際に、ＱｏＳを確保しＴＤＭ方式で音声のやり取りを行う。この構成により、無線フレーム化の際のオーバーヘッドが軽減され、かつ、音声の遅延が縮小され、さらに、１アクセスポイントあたりの同時通話数が増大し、また、通話中にデータ通信を行う際にデータ通信が使用できる帯域幅が大きく取られるという作用を有する。

本発明の第３の発明の無線ＬＡＮ電話通信方法は、第１または第２のいずれかの発明の無線ＬＡＮ電話通信方法において、送信側では、無線通信のエラーレートが所定の閾値より以下の場合に、複数の音声パケットを１つにまとめて送信し、無線通信のエラーレートが所定の閾値を超える場合に、１つのフレームにまとめずに送信する。この構成により、エラーレートが高いときは無線フレームをひとつにまとめることがないため、無線フレームが長くならずに、短く分割されたままとなり、無線フレームの長さが短いためエラー発生率が下がり、エラー発生時に、短く分割された無線フレームの再送が行われるため、長い無線フレームを再送するより効率がよくなるという作用を有する。

本発明の第４の発明の無線ＬＡＮ電話通信プログラムは、第１から第３のいずれかの発明の無線ＬＡＮ電話通信方法の手順を記載している。この構成により、例えば、パソコン等の汎用のコンピュータにて、第１から第３のいずれかの発明の無線ＬＡＮ電話通信方法が実現されるという作用を有する。

本発明の第５の発明の記憶媒体は、第４の発明の無線ＬＡＮ電話通信プログラムが記録されている。この構成により、パソコン等の汎用のコンピュータに、第４の発明の無線ＬＡＮ電話通信プログラムが移植可能となる作用を有する。

本発明の第６の発明の無線ＬＡＮ電話システム子機は、無線ＬＡＮを利用して音声をパケット化して送受信する無線ＬＡＮ電話システムの子機であって、音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延×２、コーデック待ち時間、送信待ち時間、および、予め指定されたネットワークの遅延量に基づいて、送信待ち許容時間を算出する送信待ち許容時間算出部と、送信待ち時間内に入力された音声パケットをひとつのフレームにまとめて送信データを生成するペイロード統合部と、音声パケットのＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰの少なくとも１つの上位プロトコルヘッダを解析する上位プロトコル解析部と、受信データを元来ひとつの音声パケットであったか否か判断し、複数の音声パケットが統合されている場合に、受信データを複数の音声パケットに分解するペイロード分割部とを有し、前記上位プロトコル解析部は、音声パケットの上位プロトコルヘッダを解析し、前記ペイロード統合部は、前記上位プロトコル解析部による解析結果に基づいて、共通部分を省略した１つのフレームにまとめる。この構成により、親機との通信において、無線フレーム化の際のオーバーヘッドが軽減され、かつ、音声の遅延が縮小されるという作用を有する。

本発明の第７の発明の無線ＬＡＮ電話システム子機は、第６の発明の無線ＬＡＮ電話システム子機において、タイムスロットの管理を行うタイムスロット管理部をさらに有し、親機との無線通信をＴＤＭで行う。この構成により、無線フレーム化の際のオーバーヘッドが軽減され、かつ、音声の遅延が縮小され、さらに、１アクセスポイントあたりの同時通話数が増大し、また、通話中にデータ通信を行う際にデータ通信が使用できる帯域幅が大きく取られるという作用を有する。

以下、本発明の実施の形態について、図１から図３３を用いて説明する。

（実施の形態１）
図１は本発明に係る実施の形態１による無線ＬＡＮ電話システムの子機を示す機能ブロック図である。図１において、子機３００は、１０１から１２０にて示す機能構成を有している。１０１は、発呼先の指定、着呼時に通話の指示および終話の指示をするための操作部である。１０２は、音声を入力するための音声入力部である。１０３は、音声を出力するための音声出力部である。１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファである。１０５は、無線送信するデータを蓄積する無線送信用の送信バッファである。１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部である。１０８は、時間の経過を測定するためのＲＴＣである。１０９は、音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、予め指定されたネットワークの遅延量を記憶するパラメータ記憶部である。

また、１１０は、音声入力部１０２から入力した音声をＡ／Ｄ変換し、所定のアルゴリズムを用いて音声パケットに変換（エンコード）する、また、音声データを所定のアルゴリズムを用いてデコードした上で、Ｄ／Ａ変換し、音声出力部１０３に出力するコーデック部である。１１１は、コーデック部１１０がエンコードした音声パケットをエンコードが完了した時刻、すなわち、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキューである。１１２は、送信待ち時間内に送信パケットキュー１１１に入力された音声パケットをひとつのフレームにまとめて前記送信バッファに書き込むペイロード統合部である。１１３は、無線フレームとして受け取ったデータを音声パケットに分解してＦＩＦＯ方式で記憶する、受信パケットキューである。

また、１１４は、受信バッファ１０４に記憶された内容をもともとひとつの音声パケットであったかどうか判断し、複数の音声パケットが統合されている場合は、これを複数の音声パケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。１１５は、パラメータ記憶部１０９に記憶された音声の遅延許容時間、無線フレームのサービス周期、音声のコーデック周期、音声のコーデック遅延、および、予め指定されたネットワークの遅延量を参照し、ＲＴＣ１０８の値を送信要求受付時刻と比較し、送信待ちの許容時間を算出する、送信待ち許容時間算出部である。１１６は、発呼、着呼、呼の接続・切断の制御、および、各呼の状態に応じたダイヤルトーン、ビジートーン、リンガー、リング・バック・トーンを音声出力部１０３に出力する呼制御部である。

さらに、１１７は、呼の設定や解除、通話時の音声パケットの送受信、を指定されたプロトコルに従って処理するプロトコル処理部である。１１８は、上位プロトコルを解析する、上位プロトコル解析部である。１１９は、無線通信におけるエラー率を算出し、予め指定されたエラー率よりも低いかどうかを判定する、エラー率判定部である。１２０は、親機から指定されたＴＤＭのタイムスロットを管理するＴＳ簡易（タイムスロット）管理部である。１３０は、全体を制御する制御部である。

また、図２は本発明に係る実施の形態１による無線ＬＡＮ電話システム子機の構成を示す装置ブロック図である。図２において、子機３００は、以下の２０１から２１２にて示すハード構成を有している。２０１は、中央処理装置（以下、ＣＰＵと略す）、２０２は、ＲＯＭ、２０３は、ＲＡＭ、２０４は、ＲＴＣ、２０５は、ベースバンド部、２０６は、ＲＦ、２０７は、Ａ／Ｄ、２０８は、マイク、２０９は、Ｄ／Ａ、２１０は、スピーカ、２１１は、キーボード、２１２は、コーデックである。

図１の機能構成との関係を述べる。１０１の操作部は、２１１のキーボードによって構成されている。１０２の音声入力部は、２０８のマイクによって構成されている。１０３の音声出力部は、２１０のスピーカによって構成されている。

また、１０４の受信バッファ、１０５の送信バッファ、１０９のパラメータ記憶部、１１１の送信パケットキュー、１１３の受信パケットキューは、２０３のＲＡＭによって構成されている。１０７の無線通信部は、２０５のベースバンド部と２０６のＲＦによって構成されている。１０８のＲＴＣは、２０４のＲＴＣによって構成されている。１１０のコーデック部は、２１２のコーデック、２０７のＡ／Ｄ、２０９のＤ／Ａによって構成されている。

また、１１２のペイロード統合部、１１４のペイロード分割部、１１５の送信待ち許容時間算出部、１１６の呼制御部、１１７のプロトコル処理部、１１８の上位プロトコル解析部、１１９のエラー率判定部、１２０のＴＳ管理部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって構成されている。

また、図３は本発明に係る実施の形態１による無線ＬＡＮ電話システム親機の構成を示す機能ブロック図である。図３において、親機４００は、１０４から１２２にて示す機能構成を有している。１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファである。１０５は、無線送信用のデータを蓄積する送信バッファである。１０６は、有線のネットワークと接続するためのＬＡＮ通信部である。１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部である。１０８は、時間の経過を測定するためのＲＴＣである。

また、１１１は、後述する有線−無線ブリッジ部１２１が、中継が必要と判断したＬＡＮ側からのフレームを無線フレーム化して送信するために、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキューである。１１２は、送信待ち時間内に送信パケットキュー１１１に入力された音声パケットをひとつのフレームにまとめて前記送信バッファに書き込むペイロード統合部である。１１３は、無線フレームとして受け取ったデータを音声パケットに分解してＦＩＦＯ方式で記憶する、受信パケットキューである。１１４は、受信バッファ１０４に記憶された内容をもともとひとつの音声パケットであったかどうか判断し、複数の音声パケットが統合されている場合は、これを複数の音声パケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。

さらに、１１８は、上位プロトコルを解析する、上位プロトコル解析部である。１１９は、無線通信におけるエラー率を算出し、予め指定されたエラー率よりも低いかどうかを判定する、エラー率判定部である。１２１は、有線と無線の間のフレームを必要があれば中継し、さもなければ破棄する、有線−無線ブリッジ部である。１２２は、子機ごとにＴＤＭのタイムスロットを割り当てる、ＱｏＳ管理部である。１３０は、全体を制御する制御部である。

また、図４は、本発明に係る実施の形態１による無線ＬＡＮ電話システム親機の構成を示す装置ブロック図である。図４において、親機４００は、以下の２０１から２１３にて示すハード構成を有している。２０１は、ＣＰＵ、２０２は、ＲＯＭ、２０３は、ＲＡＭ、２０５は、ベースバンド部、２０６は、ＲＦ、２１３は、ネットワークＩ／Ｆである。

図３の機能構成との関係を述べる。１０４の受信バッファ、１０５の送信バッファ、１１１の送信パケットキュー、１１３の受信パケットキューは、２０３のＲＡＭによって構成されている。１０７の無線通信部は、２０５のベースバンド部と２０６のＲＦによって構成されている。１０８のＲＴＣは、２０４のＲＴＣによって構成されている。１０６のＬＡＮ通信部は、２１３のネットワークＩ／Ｆによって構成されている。

また、１１２のペイロード統合部、１１４のペイロード分割部、１１８の上位プロトコル解析部、１１９のエラー率判定部、１２１の有線−無線ブリッジ部、１２２のＱｏＳ管理部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって構成されている。

次に、本実施の形態の無線ＬＡＮ電話システムの全体構成について説明する。図５は本発明に係る実施の形態１による無線ＬＡＮ電話システムの全体構成を示す図である。図に示すように子機Ａ３００は親機Ａ４００の管理下にあり、同様に、子機Ｂ３００は親機Ｂ４００の管理下にある。親機Ａ４００、親機Ｂ４００はそれぞれインターネットに接続されている。親機Ａ４００、親機Ｂ４００にはブリッジの機能が搭載されていて、子機からの無線フレームを、ＬＡＮ通信部（有線）を使用してインターネット側にイーサネット（登録商標）フレームとして中継したり、インターネット側からのイーサネット（登録商標）フレームを子機に無線フレームとして中継したりする。

このように構成された無線ＬＡＮ電話システムの親機と子機の動作を図６の本発明に係る実施の形態１による無線ＬＡＮ電話システムの動作概要を示すシーケンスチャートに沿って説明する。以下に説明する動作は、近年ＶｏＩＰでしばしば利用されているＳＩＰというプロトコルを参考にしている。但し、説明を必要以上に複雑にしないため、多少、処理を簡略化して説明している。また、ここでは、親機、子機の連携に重点を置いて説明をすることにする。子機の「エンコード」「デコード」、親機の「ブリッジ処理」、親機−子機の「無線送信」「無線受信」は、後に詳細を説明する。なお、本説明では、子機３００は最初、待ち受け状態にあるものとする。
［ステップＥ０１］
まず、子機Ａ３００のユーザは、子機Ａ３００の操作部１０１を利用して発呼先を指定する。ここでは、ユーザが操作部１０１より、発呼先の番号として、０５０−１００１−１２３４を入力し、発呼を指示したものとする。
［ステップＭ０２］
制御部１３０は、操作部１０１より入力された発呼先番号を受け取り、呼制御部１１６に対して、指定された発呼先番号に呼を設定するよう要求する。呼制御部１１６は、「呼の接続要求」を子機Ｂ３００に知らせるため、「ＩＮＶＩＴＥ」メッセージを作成して、プロトコル処理部１１７に子機Ｂ３００まで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を通して親機Ａ４００に「ＩＮＶＩＴＥ」を意味するデータを送信する（詳細は「子機送信処理」として後述する）。親機Ａ４００は受け取った無線フレームを有線のイーサネット（登録商標）フレームに変換してインターネットへ送信する（詳細は「親機ブリッジ処理」として後述する）。親機Ａ４００から送信されたイーサネット（登録商標）フレームはインターネット（図では省略している）を通って、親機Ｂ４００に到着する。親機Ｂ４００では、受け取ったイーサネット（登録商標）フレームを中継し、無線フレームに変換して、子機Ｂ３００に送信する（詳細は「親機ブリッジ処理」として後述する）。子機Ｂ３００では、親機Ｂ４００が送信した無線フレームを受け取り、無線通信部１０７、プロトコル処理部１１７を経由して呼制御部１１６に「ＩＮＶＩＴＥ」メッセージが通知される（詳細は「子機受信処理」として後述する）。これにより子機Ｂ３００は着呼したことになる。
［ステップＥ０３］
子機Ｂ３００では、呼制御部１１６がコーデック部１１０にリンガー（着信音）を流すよう要求する。これにより、コーデック部１１０は、音声出力部１０３に着信音として記憶している音声を出力する。
［ステップＭ０４］
子機Ｂ３００では、呼制御部１１６は「着呼を受け入れた」旨を子機Ａ３００に知らせるため、「ＲＩＮＧＩＮＧ」メッセージを作成し、プロトコル処理部１１７に子機Ａ３００まで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＲＩＮＧＩＮＧ」意味するデータを親機Ｂ４００へ送信する。このデータは親機Ｂ４００によって無線フレームからイーサネット（登録商標）フレームに変換され、インターネットを通り、親機Ａ４００に届く。さらに、親機Ａ４００は受け取ったイーサネット（登録商標）フレームを中継し、無線フレームとして子機Ａ３００に送信する。
［ステップＥ０５］
子機Ａ３００では、無線通信部１０７、プロトコル処理部１１７を経由して、呼制御部１１６が「ＲＩＮＧＩＮＧ」メッセージを受け取り、発呼先が着呼を受け入れた旨を知る。呼制御部１１６は、コーデック部１１０にリング・バック・トーン（呼び出し音、以降ＲＢＴと略記する）を出力するよう要求する。これにより、コーデック部１１０は、音声出力部１０３にＲＢＴを出力する。
［ステップＥ０６］
子機Ｂ３００において、ユーザがリンガーを聞いて着信していることに気がつくと、操作部１０１を操作して、通話を指示する。これにより、子機Ｂ３００では、制御部１３０が操作部１０１から「通話を指示された」旨を受け取り、呼制御部１１６に「呼を接続する」よう要求する。
［ステップＭ０７］
子機Ｂ３００において、呼制御部１１６はＱｏＳを確保するようＴＳ管理部１２０に要求する。ＴＳ管理部１２０は、プロトコル処理部１１７、無線通信部１０７を経由して親機Ｂ４００に「ＱｏＳ要求」を送信する。これにより、親機Ｂ４００では、ＱｏＳ管理部１２２が、無線通信部１０７、プロトコル処理部１１７を経由して「ＱｏＳ要求」を受け取り、子機Ｂ３００に対してＴＤＭのタイムスロット（具体的には、サービス開始時刻とサービス周期）を決定し、プロトコル処理部１１７、無線通信部１０７を経由して、子機Ｂ３００に送信する。子機Ｂ３００では、無線通信部１０７が「タイムスロットの指定」を受け取り、プロトコル処理部１１７を経由してこれをＴＳ管理部１２０に通知する。これにより、ＴＳ管理部１２０はＴＤＭサービス周期と開始時刻を記憶し、以降の通信を親機Ｂ４００によって指定されたタイムスロットで行うようになる。ＴＳ管理部１２０はＱｏＳ確保完了を呼制御部１１６に通知する。

さらに、呼制御部１１６は、エンコードタスク（後述）とデコードタスク（後述）を起動する。以降、呼切断が指示されるまで、音声入力部１０２から受け取った音声をコーデック部１１０がエンコードし、結果を音声パケットとして子機Ａ３００へ送信するようプロトコル処理部１１７に要求する。すると音声パケットは前述と同様に、親機Ｂ４００、親機Ａ４００を経由して子機Ａ３００に届く。また、子機Ｂ３００において、コーデック部１１０が無線通信部１０７、プロトコル処理部１１７を経由して受け取った子機Ａ３００からの音声パケットは、デコードされ、結果が音声出力部１０３に出力されるようになる。
［ステップＭ０８］
子機Ｂ３００において、呼制御部１１６は、「着呼に対してユーザが応答した」旨を子機Ａ３００に知らせるため、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージ作成し、子機Ａ３００に送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＣＯＮＮＥＣＴ−ＯＫ」を意味するデータを親機Ｂ４００に送信する。これにより、親機Ｂ４００では子機Ｂ３００から受け取った無線フレームをイーサネット（登録商標）フレームに変換して中継し、イーサネット（登録商標）フレームはインターネットを通って親機Ａ４００に届く。親機Ａ４００では、届いたイーサネット（登録商標）フレームを無線フレームに変換して中継し、子機Ａ３００に送信する。子機Ａ３００では、無線通信部１０７、プロトコル処理部１１７を経由して、「ＣＯＮＮＥＣＴ−ＯＫ」を呼制御部１１６が受け取り、コーデック部１１０にＲＢＴを停止さるよう要求する。これにより、コーデック部はＲＢＴを停止する。
［ステップＭ０９］
子機Ａ３００において、Ｍ０７と同様の処理を行う。詳細はすでに説明したので割愛する。
［ステップＥ１０］
以降、全２重のＱｏＳが保証された通信路が確保され、通話が可能となる。ここでは、インターネットの通信帯域は十分広く、遅延も数１０ｍｓ程度であることを仮定している。つまり、子機Ａ３００と子機Ｂ３００の間での通信のボトルネックは子機−親機間であると仮定している。
［ステップＭ１１］
通話中、子機Ａ３００のユーザの音声は、子機Ａ３００の音声入力部１０２に入力され、前述のようにコーデック部１１０によってエンコードされ、音声パケットとしてプロトコル処理部１１７によって子機Ｂ３００まで送信される。このとき、子機Ａ３００から親機Ａ４００の間においては、音声パケットは、ＴＳ管理部１２０によって管理されているサービス周期によって送信される。子機Ｂ３００では、無線通信部１０７、プロトコル処理部１１７を経由してコーデック部１１０が音声パケットを受け取り、これをデコードし、結果を子機Ｂ３００の音声出力部１０３に出力する。子機Ｂ３００側でのユーザの音声が子機Ａ３００に届く処理は、前述の処理とちょうど対称の処理となるため、詳細は割愛する。
［ステップＥ１２］
子機Ｂ３００においてユーザが呼切断を操作部１０１から指示する。これにより、制御部１３０は操作部１０１から呼切断の指示を受け取って、呼制御部１１６に呼切断を要求する。呼制御部１１６はエンコードタスクとデコードタスクを停止する。これにより、コーデック部１１０はコーデックを停止する。以降、音声パケットを受け取っても破棄し、音声の入力に対してエンコードも行わない。
［ステップＭ１３］
子機Ｂ３００において、呼制御部１１６は、ＴＳ管理部１２０にＱｏＳの解放を要求する。ＴＳ管理部１２０は、プロトコル処理部１１７、無線通信部１０７を経由して、親機Ｂ４００に対して、ＱｏＳの開放を要求する。親機Ｂ４００において、無線通信部１０７が「ＱｏＳ開放」の要求を受け取り、ＱｏＳ管理部１２２に通知する。ＱｏＳ管理部１２２はこれまで子機Ｂ３００に割り当てていたＴＤＭのタイムスロットを開放し、他の子機から要求があれば割り当てられるように準備する。親機Ｂ４００の無線通信部１０７はＱｏＳの開放が終わると、子機Ｂ３００にその旨を通知する無線フレームを送信する。子機Ｂ３００では、この無線フレームを受け取ると、プロトコル処理部１１７を経由しＴＳ管理部１２０に通知する。ＴＳ管理部１２０はＱｏＳを解放し、呼制御部１１６にその旨を通知する。
［ステップＭ１４］
子機Ｂ３００において、呼制御部１１６は、「ＢＹＥ」メッセージを作成し、プロトコル処理部１１７に子機Ａ３００まで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＢＹＥ」を意味するデータを親機Ｂ４００に送信する。これまでと同様に、「ＢＹＥ」メッセージは、親機Ｂ４００、インターネット、親機Ａ４００を経由して子機Ａ３００に到着する。
［ステップＥ１５］
子機Ａ３００において、呼制御部１１６は、無線通信部１０７、プロトコル処理部１１７を経由して「ＢＹＥ」のメッセージを受け取る。呼制御部１１６はエンコードタスクとデコードタスクを停止する。これにより、コーデック部１１０はコーデックを停止する。以降、音声パケットを受け取っても破棄し、音声の入力に対してもエンコードを行わない。
［ステップＭ１６］
ステップＭ１３同様、子機Ａ３００は親機Ａ４００にＱｏＳの開放を要求する。詳細はすでに説明したので割愛する。
［ステップＭ１７］
子機Ａ３００において、呼制御部１１６は「ＢＹＥ−ＯＫ」メッセージを作成し、子機Ｂ３００まで送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＢＹＥ−ＯＫ」を意味するデータを親機Ａ４００に送信する。これまでと同様に、「ＢＹＥ−ＯＫ」のメッセージは親機Ａ４００、インターネット、親機Ｂ４００を経由して子機Ｂ３００に届く。
［ステップＥ１８］
子機Ｂにおいて、呼制御部１１６は、無線通信部１０７、プロトコル処理部１１７を経由して、「ＢＹＥ−ＯＫ」メッセージを受け取る。以降、子機Ｂ３００は「待ち受けモード」となる。

次に、本実施の形態の子機の動作の概要を説明する。図７は本発明に係る実施の形態１による無線ＬＡＮ電話システム子機のタスク構成を示す図を示している。本実施の形態では、子機３００は、音声をエンコードするエンコードタスク、プロトコルに従ってデータの送受信を制御するプロトコル処理タスク、音声をデコードするデコードタスク、呼設定・接続・切断などを行う呼制御タスク、音声パケットを無線フレームとして送信する無線送信タスク、無線フレームを受信して音声パケットにする無線受信タスクが並行して動作しているものとする。エンコードタスク、デコードタスク、呼制御タスクはプロトコル処理タスクに対して送信要求、受信要求を行う。受信要求を行ったあと、プロトコル処理タスクは要求があったデータを受信すると、その旨を、受信要求を行ったタスクに通知する。なお、図中の矢印はデータの流れを示している。

次に、本実施の形態の親機の動作の概要を説明する。図８は本発明に係る実施の形態１による無線ＬＡＮ電話システム親機のタスク構成を示す図を示している。親機４００では、子機と同様に無線送信タスク、無線受信タスクおよび、「無線受信タスクが受け取った無線フレームを吟味し、有線と無線の間でフレームを中継するかどうかを決定し、必要があれば、フレームの形式を変換した後、ＬＡＮ通信部１０６を介してイーサネット（登録商標）フレームを送信する、また、ＬＡＮ通信部１０６を通して受信したイーサネット（登録商標）フレームを吟味し、有線と無線の間でフレームを中継するかどうかを決定し、必要があれば、フレームの形式を変換した後、無線送信タスクに渡す」ブリッジタスクが並行して動作している。

以降、子機のそれぞれのタスクの動作についてフローチャートを使用して説明する。まず、エンコードタスクの処理について図９の本発明に係る実施の形態１による無線ＬＡＮ電話システム子機のエンコードタスクの動作を示すフローチャートに沿って説明する。エンコードタスクは呼制御タスクによって通話中に起動される。通話が終わると呼制御タスクによって停止させられる。以下の説明は通話中のエンコードタスクの動作である。
［ステップＳ０１］
コーデック部１１０は音声入力部１０２から音声の受け取り、サンプリング（Ａ／Ｄ変換）およびエンコードを行う。
［ステップＳ０２］
コーデック部１１０はパラメータ記憶部１０９に記憶されたコーデック間隔を参照し、ＲＴＣ１０８と比較しながらコーデック間隔で指定されている時間だけエンコードが行われたかどうかを判断する。指定された時間が経過していれば、ステップＳ０３へ進む。さもなければ、ステップＳ０１に戻る。
［ステップＳ０３］
コーデック部１１０はサンプリングしたデータをプロトコル処理部１１７に渡し、送信を要求する。ステップＳ０１に戻る。

次に、デコードタスクの処理について図１０の本発明に係る実施の形態１による無線ＬＡＮ電話システム子機のデコードタスクの動作を示すフローチャートに沿って説明する。デコードタスクは、呼制御タスクによって通話中に起動される。通話が終わると呼制御タスクによって停止させられる。以下の説明は通話中のデコードタスクの動作である。
［ステップＳ１０１］
コーデック部１１０は、プロトコル処理部１１７から受信通知を受け取っているかどうかを確認する。受信通知を受け取っていれば、ステップＳ１０２へ進む。さもなければ、ステップＳ１０１に戻る。
［ステップＳ１０２］
コーデック部１１０は、プロトコル処理部１１７から受信データを受け取る。
［ステップＳ１０３］
コーデック部１１０は受け取ったデータをデコードし、結果をＤ／Ａ変換し、その出力を音声出力部１０３に出力する。ステップＳ１０１に戻る。

次に、呼制御タスクの動作について図１１の本発明に係る実施の形態１、２による無線ＬＡＮ電話システム子機の呼制御タスクの動作を示すステートチャートに沿って説明する。

まず、子機Ａ３００の電源がＯＮされて、子機Ａ３００のユーザが発呼、通話、切断を行う一連の処理について呼制御タスクの動作を子機Ａ３００の側から説明する。
［ステップＥ１０１］
子機３００の電源ＯＮが操作部１０１から指示されると、制御部１３０は呼制御タスク、プロトコル処理タスク、無線送信タスク、無線受信タスクを起動する。呼制御タスクは起動されると、待ち受け状態に遷移する。これにより、以降、発着呼が可能になる。
［ステップＥ１０２］
子機Ａ３００でユーザが操作部１０１を操作して子機Ｂ３００に発呼を行う。子機Ａ３００の制御部１３０は、操作部１０１からの「発呼」の通知を受け、発呼先番号を受け取り、呼制御部１１６に相手先番号を指定して「呼接続」要求する。呼制御部１１６は、「ＩＮＶＩＴＥ」メッセージを子機Ｂ３００まで送信するようプロトコル処理部１１７に要求する。子機Ｂ３００は、「ＩＮＶＩＴＥ」メッセージを受け付けて、着呼中となり、「ＲＩＮＧＩＮＧ」メッセージを子機Ａ３００に送り返してくる。子機Ａ３００の呼制御部１１６はプロトコル処理部１１７経由で子機Ｂ３００からの「ＲＩＮＧＩＮＧ」メッセージを受信し、発呼中状態に遷移する。呼制御部１１６はＲＢＴを音声出力部１０３に出力し、ユーザに「呼び出し中」であることを知らせる。
［ステップＥ１０３］
子機Ｂ３００では、リンガー（着信音）が鳴っており、ユーザは着信音に気づいて着信を受け入れる。これにより、子機Ｂ３００では親機Ｂ４００との間でＱｏＳの確保が行われ、エンコードタスク、デコードタスクが起動された後、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａ３００に送信してくる。子機Ａ３００では、呼制御部１１６が、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを、プロトコル処理部１１７を経由して受け取り、ＴＳ管理部１２０にＱｏＳの確保を要求する。ＴＳ管理部１２０は親機Ａ４００にＱｏＳの確保要求を行い、親機Ａ４００によってＱｏＳの確保が行われた後、親機Ａ４００によって指定されたＴＳ（タイムスロット）を受け取る。ＴＳ管理部１２０は呼制御部１１６にＱｏＳの確保が完了したことを通知する。

これにより、呼制御部１１６は前述のエンコードタスクとデコードタスクを起動し、コーデック部１１０は、以降の音声入力部１０２からの音声をＡ／Ｄ変換およびエンコードし、音声パケットとしてプロトコル処理部１１７に渡す。また、コーデック部１１０はプロトコル処理部１１７が受け取った音声パケットをデコードおよびＤ／Ａ変換し、音声出力部１０３に出力する。通話中に遷移する。
［ステップＥ１０９］
子機Ａ３００のユーザが通話を終えた場合、子機Ａ３００の操作部１０１を操作して、呼を切断する。制御部１３０は操作部１０１からの切断操作の通知を受け、呼制御部１１６に「呼切断」を要求する。呼制御部１１６はエンコードタスクとデコードタスクを停止させ、ＴＳ管理部１２０に「ＱｏＳ解放」を要求する。ＴＳ管理部１２０は、プロトコル処理部１１７、無線処理部１０７を経由して、親機Ａ４００に「ＱｏＳ解放」要求し、親機Ａ４００でＱｏＳの解放が行われた後、親機Ａ４００が送信した「ＱｏＳ解放完了」を無線処理部１０７、プロトコル処理部１１７を経由して受け取り、呼制御部１１６に通知する。これにより、呼制御部１１６は「ＢＹＥ」メッセージを子機Ｂ３００へ送るようプロトコル処理部１１７に要求する。プロトコル処理部１１７は無線処理部１０７を経由して「ＢＹＥ」メッセージを意味するデータを親機Ａ４００に送信し、インターネット、親機Ｂ４００、を経由して子機Ｂ３００に到着する。子機Ｂ３００は「ＢＹＥ」メッセージを受け取ると、「ＢＹＥ−ＯＫ」を子機Ａ３００に返送する。子機Ａ３００では、無線通信部１０７、プロトコル処理部１１７を経由して、呼制御部１１６が「ＢＹＥ−ＯＫ」メッセージを受け取る。これにより、待ち受け状態に遷移する。
［ステップＥ１０７］
また、ユーザが発呼中に発呼を取りやめる場合は、操作部１０１から発呼取りやめの指示を行い、制御部１３０が操作部１０１から発呼取りやめの指示を受け取り、呼制御部１１６に発呼取りやめを要求する。呼制御部１１６はプロトコル処理部１１７に「ＣＡＮＣＥＬ」のメッセージを子機Ｂ３００へ送信するよう要求する。子機Ｂ３００はリンガーを停止、「ＣＡＮＣＥＬ−ＯＫ」メッセージを子機Ａ３００に送信する。子機Ａ３００では、子機Ｂ３００からの「ＣＡＮＣＥＬ−ＯＫ」をプロトコル処理部１１７が受け取り呼制御部１１６に通知すると、呼制御部１１６は待ち受け状態に遷移する。

次に、子機Ｂ３００側からみた、呼制御タスクの動作について説明する。
［ステップＥ１０４］
プロトコル処理部１１７は、子機Ａ３００から「ＩＮＶＩＴＥ」メッセージを受け取り、呼制御部１１６に通知する。呼制御部１１６はプロトコル処理部１１７に「ＲＩＮＧＩＮＧ」メッセージを子機Ａ３００に返送するよう要求する。呼制御部１１６はリンガーを音声出力部１０３に出力し、ユーザに着信が発生していることを知らせる。呼制御部１１６は着呼中状態に遷移する。
［ステップＥ１０５］
ユーザは、リンガーによって着呼していることを知り、操作部１０１を操作して、着信に応答する。制御部１３０は操作部１０１から着信応答を受け取り、呼制御部１１６に応答を要求する。呼制御部１１６はＴＳ管理部１２０に「ＱｏＳ確保」を要求する。ＴＳ管理部１２０は親機Ｂ４００に「ＱｏＳ確保要求」を送信する。親機Ｂ４００は、これを受け取って、ＱｏＳを確保し、「ＱｏＳ確保完了」を子機Ｂ３００に送信する。プロトコル処理部１１７は「ＱｏＳ確保完了」を受け取り、ＴＳ管理部１２０にＴＳ（タイムスロット）を通知する。ＴＳ管理部１２０はＱｏＳ確保完了を呼制御部１１６に通知する。

これにより、呼制御部１１６は「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａ３００に送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａ３００に送信する。さらに呼制御部１１６は、音声出力部１０３へのリンガーの出力を停止し、エンコードタスクとデコードタスクを起動して、以降の音声入力部１０２からの音声がＡ／Ｄ変換・エンコードされ、音声パケットとして子機Ａ３００へ送信されるようにし、また、子機Ａ３００からの音声パケットがデコード・Ｄ／Ａ変換され、音声出力部１０３から出力されるようにする。
［ステップＥ１０９］
プロトコル処理部１１７は、子機Ａ３００から「ＢＹＥ」メッセージを受信し、呼制御部１１６に通知する。呼制御部１１６は、ＴＳ管理部１２０に「ＱｏＳ解放」を要求し、ＴＳ管理部１２０は親機Ｂ４００に「ＱｏＳ解放要求」を送信する。親機Ｂ４００はこれ受け取って、ＱｏＳを解放し、「ＱｏＳ解放完了」を子機Ｂ３００に返送する。プロトコル処理部１１７はこれを受け取ってＴＳ管理部１２０に通知する。ＴＳ管理部１２０は、ＱｏＳを解放し、呼制御部１１６にＱｏＳ解放完了を通知する。呼制御部１１６は、エンコードタスクとデコードタスクを停止し、待ち受け状態に遷移する。

また、子機Ａ３００のユーザが発呼中に発呼を取りやめた場合は、ステップＥ１０８に遷移する。
［ステップＥ１０８］
プロトコル処理部１１７は「ＣＡＮＣＥＬ」メッセージを受信し、呼制御部１１６に通知する。呼制御部１１６はリンガーを停止し、子機Ａ３００に「ＣＡＮＣＥＬ−ＯＫ」メッセージを送信するようプロトコル処理部１１７に要求し、待ち受け状態に遷移する。

次に、プロトコル処理タスクの動作について図１２のフ本発明に係る実施の形態１、２による無線ＬＡＮ電話システム子機のプロトコル処理タスクの動作を示すフローチャートに沿って説明する。
［ステップＳ２０１］
プロトコル処理部１１７は、エンコードタスク、デコードタスク、呼制御タスクから、送信要求があるかどうかを調べる。あれば、ステップＳ２０２へ、なければ、ステップＳ２０３へ進む。
［ステップＳ２０２］
プロトコル処理部１１７は、送信要求を受け付けて、各プロトコルにしたがってヘッダを付加し、送信パケットキュー１１１に入れる。送信パケットキュー１１１はあて先ごとに用意されている。ここであて先とは、ＩＥＥＥ８０２．１１で規定されている送信先ＭＡＣアドレスである。このとき、この送信要求を受け付けた時刻を、ＲＴＣ１０８を参照して、送信要求と対応付けて書き込む。ステップＳ２０１に進む。

ここでは、音声パケットをエンコードタスクから受け取ったとして、説明する。プロトコル処理部１１７は、音声パケットにＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダ、ＬＬＣヘッダを付加し、あて先のＭＡＣアドレスを決定する（通常、あて先はＩＰアドレスで与えられており、プロトコル処理部１１７はこれをＭＡＣアドレスに変換する。詳細は、ＴＣＰ／ＩＰの通信処理と同様なので割愛する。）。プロトコル処理部１１７は、ＭＡＣアドレスごとに用意された送信パケットキュー１１１の中から音声パケットのあて先のＭＡＣアドレスを持った送信パケットキューを選択し、音声パケットを送信パケットキュー１１１に入れる。このとき、ＲＴＣ１０８を参照し、送信要求受付時刻として、送信パケットキューに書き込む。ステップＳ２０１へ進む。
［ステップＳ２０３］
プロトコル処理部１１７は、受信パケットキュー１１３にデータが届いているかどうか確認する。届いていればステップＳ２０４へ、さもなければ、ステップＳ２０１へ進む。
［ステップＳ２０４］
プロトコル処理部１１７は、受信パケットキュー１１３から受信データを取り出す。
［ステップＳ２０５］
データのあて先を確認する。あて先がデコードタスクであれば、デコードタスクへ、呼制御タスクであれば、呼制御タスクへ通知する。ステップＳ２０１へ進む。

次に、子機３００の無線送信タスクの動作を図１３の本発明に係る実施の形態１による無線ＬＡＮ電話システム子機の無線送信タスクの動作を示すフローチャートに沿って説明する。送信パケットキュー１１１は、あて先のＭＡＣアドレスごとに存在し、無線送信タスクは、以下の処理を送信パケットキュー１１１ごとに行う。但し、以下の説明では、ひとつの送信パケットキュー１１１に注目してその動作を説明する。
［ステップＳ３０１］
制御部１３０は、ＲＴＣ１０８とパラメータ記憶部１０９に設定された「次の送信時刻」とを比較し、現在の時刻が「次の送信時刻」に等しいか、過ぎていれば、ステップＳ３０２へ進む。さもなければ、ステップＳ３０１へ進む。ここでは、ＲＴＣ１０８の値が１２：３３ ２２．０１３ ９９４であり、「次の送信時刻」が１２：３３ ２２．０１３ ９９４であったとする。
［ステップＳ３０２］
制御部１３０は、ＴＳ管理部１２０に「サービス周期」を問い合わせ、ＲＴＣ１０８を参照して、次の送信時刻を計算し、「次の送信時刻」を更新する。ここでは、サービス周期は１０．２４ｍｓであり、ＲＴＣ１０８の値が１２：３３ ２２．０１３ ９９４であるため、したがって、次の送信時刻は１２：３３ ２２．０２４ ２３４ となる。
［ステップＳ３０３］
制御部１３０は、送信パケットキュー１１１を参照して、キューが空かどうかを判断する。空ならば、ステップＳ３０１へ、さもなければステップＳ３０４へ進む。
［ステップＳ３０４］
制御部１３０は送信パケットキュー１１１の最初のエントリに注目する。
［ステップＳ３０５］
制御部１３０は、エラー率判定部１１９にエラー率が予め設定された閾値よりエラー率が低いかどうかを問い合わせる。エラー率判定部１１９は、制御部１３０に判定結果を渡す。受け取った判定結果から、エラー率が低い場合はステップＳ３０６へ、さもなければステップＳ３１５へ進む。ここでは、エラー率が低いものとして説明を続ける。
［ステップＳ３０６］
制御部１３０は、送信待ち許容時間算出部１１５に、送信待ち許容時間を算出するよう要求する。これにより、送信待ち許容時間算出部１１５はパラメータ記憶部１０９とＲＴＣ１０８とエントリと対応付けて記録された送信要求受付時刻とを参照し、遅延許容時間を算出する。まず、ＲＴＣ１０８と送信要求受付時刻から送信待ち時間を求める。ここでは（数１）に示す以下の値であるとする。

また（数２）がパラメータ記憶部１０９に予め、記憶されているものとする。

なお、コーデック遅延とは、音声が入力されてからＡ／Ｄ変換されて、指定されたアルゴリズムによって（ここではμ則ＰＣＭ ８ｋＨｚ ８ビットサンプリングが指定されているものとする）エンコードされたデータが出てくるまでの時間であり、このデータをコーデック周期に相当する分だけ集めてはじめて音声フレームとすることができる。また、音声フレームをデコードしてＤ／Ａ変換して、音声として出力されるまでの遅延時間も同じ値としている。コーデックのアルゴリズムによってはこの遅延時間は非対称となることもあるが、ここでは対称であるとして説明を続ける。さらに、コーデック待ち時間とは受信側でジッターバッファを設けて、デコード待ちの音声パケットを一時的に貯めておき、音声パケットの到着が変動しても、音声が途切れないようにするための、時間である。（数３）によって次式によって送信待ち許容時間を計算する。

図１４は上式を分かりやすく図示した、本発明に係る実施の形態１、２による無線ＬＡＮ電話システムの音声の遅延量の内訳を示す図である。

上記より注目しているエントリの送信待ち許容時間は１３ｍｓとなる。
［ステップＳ３０７］
制御部１３０は、次回の送信で間に合うかどうかを判断する。間に合うと判断した場合はステップＳ３０９へ、さもなければステップＳ３０８へ進む。ここで、現在の時刻が１２：３３ ２２．０１３ ９９４である。この場合、送信待ち許容時間が１３ｍｓであるため、最悪、１２：３３ ２２．０２６ ９９４までに送信すればよいことがわかる。次の送信時刻は１２：３３ ２２．０２４ ２３４なので、次の送信で間に合うと判断する。
［ステップＳ３０８］
制御部１３０は、今回の送信のタイミングで送信すべきデータがすでに送信バッファ１０５に存在しているかどうかを判断する。つまり、次の送信でも間に合うとステップＳ３０７で判断されても、すでに、送信バッファ１０５に送信すべきデータが存在していれば、まとめて送信するほうが、送信効率がよい。すなわち、存在している場合は、ステップＳ３０９へ、さもなければ、ステップＳ３０１へ進む。ここでは、送信バッファ１０５にデータが存在していなかったこととして説明を続ける。この場合、ステップＳ３０１に進む。

以降、時間が経過し、時刻が１２：３３ ２２．０２４ ２３４になったとする。ここでは、ステップＳ３０１からステップＳ３０６を実行する。ここで図１５に示すように送信パケットキュー１１１に２つの音声パケットがエンキューされているものとする。
送信待ち時間は、（数４）となる。

したがって、送信待ち許容時間＝３ｍｓ である。次回の送信時刻は１２：３３．２２ ０３４ ４７４であるため、ステップＳ３０７では、エントリ１は次回の送信では間に合わない、と判断され、ステップＳ３０９へ進む。
［ステップＳ３０９］
制御部１３０は、送信パケットキュー１１１から注目中のエントリのデータを取り出す。
［ステップＳ３１０］
制御部１３０は、データをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
［ステップＳ３１１］
制御部１３０は、送信パケットキュー１１１を参照して、まだ、エントリがあるかどうかを判断する。あれば、ステップＳ３１２へ、なければ、ステップＳ３１３へ進む。ここでは、図１５に本発明に係る実施の形態１による無線ＬＡＮ電話システム子機の送信パケットキュー１１１の内容を示す図を示すようにエントリがもうひとつエンキューされているのでステップ１２へ進む。
［ステップＳ３１２］
制御部１３０は、次のエントリに注目する。ステップＳ３０５へ進む。ここで、制御部１３０はエントリ２に注目し、さらに、ステップＳ３０７でエントリ２が次の送信で間に合うかどうかを判断する。ここでは間に合うと判断されるため、ステップＳ３０８へ進む。次にステップＳ３０８では、先ほどエントリ１が送信バッファ１０５に書き込まれているため、ステップＳ３０９へ進む。ステップＳ３０９では、送信パケットキュー１１１からデータを取り出し、ステップＳ３１０で、送信データをマージする。マージ処理の詳細は後述する。このようにして、１度に送れると判断できた音声パケットはひとつの無線フレームにまとめられる。次にステップＳ３１１で送信パケットキュー１１１のエントリがすべて評価されたことが判断され、ステップＳ３１３へ進む。
［ステップＳ３１３］
ここでは無線フレームはＩＥＥＥ８０２．１１ｉで規定された暗号化方式によって暗号化されるものとする。制御部１３０は、無線通信部１０７にＣＣＭＰヘッダとＭＩＣキーを付加するよう指示する。これにより、無線通信部１０７は、暗号化アルゴリズムにしたがってＣＣＭＰヘッダとＭＩＣキーを計算し、送信バッファ１０５のＩＥＥＥ８０２．１１ｉで規定されたペイロードの位置に追加する。
［ステップＳ３１４］
制御部１３０は、無線通信部１０７に送信バッファ１０５の内容を送信するよう指示する。これにより、無線通信部１０７は指示された内容を無線フレームとして空中に放出する。ステップＳ３０１へ進む。ここで、ＩＥＥＥ ８０２．１１で規定されているプリアンブルやＦＣＳは無線通信部１０７で付加されるものとする。

一方、ステップＳ３０５でエラー率が高いと判断された場合は、ステップＳ３１５に遷移する。
［ステップＳ３１５］
ステップＳ３０９と同様の処理を行う。
［ステップＳ３１６］
ステップＳ３１０と同様の処理を行う。
［ステップＳ３１７］
ステップＳ３１３と同様の処理を行う。
［ステップＳ３１８］
ステップＳ３１４と同様の処理を行う。
［ステップＳ３１９］
制御部１３０は、送信パケットキュー１１１を参照して、まだ、未評価のエントリがあるかどうかを判断する。あれば、ステップＳ３１２へ、なければ、ステップＳ３０１へ進む。この場合は、従来の無線ＬＡＮと同様、音声パケットをそのままひとつの無線フレームとして送信する処理となる。

次に、マージ処理の詳細を図１６の本発明に係る実施の形態１による無線ＬＡＮ電話システムの送信マージ処理を示すフローチャートに沿って説明する。ここでは、制御部１３０によって送信パケットキュー１１１から取り出されたエントリの内容がペイロード統合部１１２に渡されているものとして説明する。
［ステップＳ４０１］
ペイロード統合部１１２は、送信バッファ１０５にデータが書き込まれているかどうかを判断する。書き込まれていればステップＳ４０７へ、さもなければ、ステップＳ４０２へ進む。
［ステップＳ４０２］
ペイロード統合部１１２は送信バッファ１０５にＭＡＣヘッダを書き込む。
［ステップＳ４０３］
ペイロード統合部１１２は上位プロトコル解析部１１８にエントリの内容を渡す。これにより、上位プロトコル解析部１１８は、パケット内の上位プロトコル（ここでは、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰ）のプロトコルヘッダを認識し、各レイヤのヘッダを記憶する。
［ステップＳ４０４］
ペイロード統合部１１２は、受け取った音声パケットの合計バイト数を算出する。ここでは、ＬＬＣヘッダ（８バイト）＋ＩＰｖ６ヘッダ（４０バイト）＋ＵＤＰヘッダ（８バイト）＋ＲＴＰヘッダ（１２バイト）＋音声（８０バイト）＝１４８バイトとなる。
［ステップＳ４０５］
ペイロード統合部１１２はステップＳ４０４で得られた合計バイト数をペイロードデリミタ１として送信バッファ１０５に書き込む。ここでは１４８を書き込む。
［ステップＳ４０６］
ペイロード統合部１１２は音声パケットとして受け取ったデータを送信バッファ１０５に書き込む。マージ処理を終了する。
［ステップＳ４０７］
ペイロード統合部１１２は上位プロトコル解析部１１８にエントリの内容を渡す。これにより、上位プロトコル解析部１１８は、パケット内の上位プロトコル（ここでは、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰ）のプロトコルヘッダを認識し、ステップＳ４０３で記憶していた内容と比較する。上位プロトコル解析部１１８はヘッダを解析した結果をペイロード統合部１１２に渡す。ここでは、ＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダが冗長であることをペイロード統合部１１２に知らせる。
［ステップＳ４０８］
ペイロード統合部１１２は、冗長なヘッダを省略すると送信すべきデータの合計バイト数がいくらになるかを計算する。ここでは、冗長なヘッダがどれかを示すフラグ１バイトと省略できないＲＴＰヘッダ１２バイトと音声データ８０バイトの合計９３を算出する。
［ステップＳ４０９］
ペイロード統合部１１２は、ステップＳ４０８で算出した値をペイロードデリミタとして送信バッファ１０５に書き込む。ここでは９３が書き込まれる。
［ステップＳ４１０］
次に、ペイロード統合部１１２は冗長なヘッダがどれかを示すフラグ１バイトを送信バッファ１０５に書き込む。ここではフラグは、ＯＳＩのレイヤモデルにしたがって、第２層、第３層、第４層、第５から７層をおのおの２ビットで表現しており、００は「もともと対応するヘッダがなかった」、０１は「ヘッダがあったが冗長なので省略した」、１０「省略できなかった」を表すものとする。ここでは、ＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダは省略可能で、ＲＴＰヘッダは省略できないため、フラグの値は０１０１０１１０となる。
［ステップＳ４１１］
ペイロード統合部１１２は、省略できなかったヘッダと音声データを送信バッファ１０５に書き込む。マージ処理を終了する。

ここでは、続いてＲＴＰヘッダ１２バイトと音声データ８０バイトを送信バッファ１０５に書き込む。図１７はＩＥＥＥ８０２．１１による無線フレームのフォーマットを示す図を示している。また、図１８は本発明に係る実施の形態１によって２つの音声パケットが１つの無線フレームにまとめられたときのフレーム・フォーマットを示す図を示している。まず、無線通信部１０７に内蔵された暗号化エンジンによってＣＣＭＰヘッダが書き込まれ、ＭＩＣキーが付加された後、ＰＬＣＰプリアンブル、ＰＬＣＰヘッダおよびＦＣＳを無線通信部１０７が無線フレームを生成するときに付加する。図１７、図１８の比較より、本来２つの音声パケットを２つの無線フレームで送信せずに、１つの無線フレームにまとめると、フレーム長は２５％大きくなるだけなので、伝送効率が大幅に向上することが分かる。

次に、無線受信タスクの動作を図１９の本発明に係る実施の形態１による無線ＬＡＮ電話システムの受信タスクの動作を示すフローチャートに沿って説明する。ここで、自局宛の無線フレームは無線通信部１０７によって受信され、暗号が解除された状態で受信バッファ１０４にフレームの内容がデータとして書き込まれているものとする。すなわち、ＣＣＭＰヘッダとＭＩＣキーは取り除かれているものとする。また、ここでは、自局宛の無線フレーム以外は無線通信部によって無視されているものとする。すなわち、受信バッファに書き込まれるデータは自局宛のものに限るものとする。
［ステップＳ５０１］
ペイロード分割部１１４は、受信バッファ１０４を参照してデータを受信しているかどうかを判断する。受信していれば、ステップＳ５０２へ、さもなければ、ステップＳ５０１へ進む。
［ステップＳ５０２］
ペイロード分割部１１４は、受信バッファ１０４からデータを取り出す。
［ステップＳ５０３］
ペイロード分割部１１４は、ＭＡＣヘッダを取り出す。
［ステップＳ５０４］
ペイロード分割部１１４は、最初のペイロードに注目する。
［ステップＳ５０５］
ペイロード分割部１１４は、次の１バイトをデリミタと解釈し、値を読み出し、ペイロードが何バイトかを得て、そのバイト数分だけペイロードとして切り出す。
［ステップＳ５０６］
ペイロード分割部１１４は、ステップＳ５０５で得たペイロードを上位プロトコル解析部１１８に渡す。これにより、上位プロトコル解析部１１８は、第２層、第３層、第４層、第５から７層でのヘッダを解釈し、ペイロード分割部１１４に通知する。ここではＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダと解釈できたとする。上位プロトコル解析部１１８はそれぞれのレイヤごとにヘッダを記憶する。
［ステップＳ５０７］
ペイロード分割部１１４は、得られたペイロードを受信パケットキュー１１３に入れる。
［ステップＳ５０８］
ペイロード分割部１１４は、受信バッファ１０４を参照して、すべてのペイロードを切り出したかどうか判断する。すべてのペイロードの切り出しが終わっていれば、ステップＳ５０１へ、さもなければ、ステップＳ５０９へ進む。
［ステップＳ５０９］
ペイロード分割部１１４は、受信バッファ１０４を参照して、次のペイロードに注目する。
［ステップＳ５１０］
ペイロード分割部１１４は、受信バッファ１０４中の次の１バイトをデリミタと解釈し、値を読み出し、注目中のペイロードが何バイトかを得て、そのバイト数分だけペイロードとして切り出す。
［ステップＳ５１１］
ペイロード分割部１１４は、次の１バイトを省略フラグと解釈し、どのレイヤのヘッダが省略されているかを判断する。さらに、省略されているヘッダに対しては、ステップＳ５０６で記憶しているヘッダの内容からヘッダを復元するよう上位プロトコル解析部１１８に指示する。これにより、上位プロトコル解析部１１８は、ペイロードとステップＳ５０６で記憶した内容を比較し、各レイヤのヘッダを復元する。ここでは、ＩＰヘッダとＵＤＰヘッダにはチェックサムが含まれるため、ペイロードの内容からチェックサムを計算し、ヘッダとして復元する。以上で、ヘッダが省略される前の音声パケット全体が復元されたことになる。ステップＳ５０７へ進む。

ここでは、フラグの値が０１０１０１１０であったとすると、フラグは、ＯＳＩのレイヤモデルにしたがって、第２層、第３層、第４層、第５から７層をおのおの２ビットで表現しており、００は「もともと対応するヘッダがなかった」、０１は「ヘッダがあったが冗長なので省略した」、１０「省略できなかった」を表すので、それぞれ、ＬＬＣヘッダは省略、ＩＰヘッダ省略、ＵＤＰヘッダ省略、ＲＴＰヘッダ省略なし、と解釈できる。したがって、今注目しているフラグから後ろはＲＴＰヘッダとして解釈し、省略されているヘッダに関してはステップＳ５０６で記憶した内容に基づき復元する。さらに、ＩＰヘッダとＵＤＰヘッダに関してチェックサムを再計算し、ヘッダを復元する。

以上の処理によって、もともと複数の音声パケットがひとつの無線フレームにまとめられていても、正しくもとの音声パケットに分割され、プロトコル処理部１１７に渡される。デコードタスクは、規定された遅延時間内にデコード処理を完了し、音声として再生する。

次に、親機４００のタスクについて説明する。但し、無線受信タスクは子機３００と同一なので説明を省略する。ブリッジタスクの処理について図２０の本発明に係る実施の形態１による無線ＬＡＮ電話システム親機のブリッジタスクの動作を示すフローチャートに沿って説明する。
［ステップＳ６０１］
有線−無線ブリッジ部１２１は、受信パケットキュー１１３にエントリがあるかどうかを判断する。エントリがあればステップＳ６０２へ、さもなければ、ステップＳ６０５へ進む。
［ステップＳ６０２］
有線−無線ブリッジ部１２１は、受信パケットキュー１１３からエントリを取り出す。
［ステップＳ６０３］
有線−無線ブリッジ部１２１は、ステップＳ６０２で取り出したエントリの内容を参照して、ＬＡＮ側（有線）に中継する必要があるかどうかを判断する。この判断においては第２層のあて先を利用する。本実施の形態では、第２層はＩＥＥＥ８０２．１１で規定されているＭＡＣアドレスによって判断する。この判断のためのアドレスの学習方法などは、本発明の主旨と関係ないので割愛する。中継が必要な場合はステップＳ６０４へ、さもなければ、ステップＳ６０１へ進む。
［ステップＳ６０４］
有線−無線ブリッジ部１２１は、ＩＥＥＥ８０２．１１のＭＡＣヘッダ形式をＩＥＥＥ８０２．３のＭＡＣヘッダの形式に変換し、ＬＡＮ通信部１０６よりエントリの内容を送信する。ステップＳ６０１へ進む。
［ステップＳ６０５］
有線−無線ブリッジ部１２１はＬＡＮ通信部１０６に有線ＬＡＮからデータを受信しているかどうかを問い合わせる。受信していれば、ステップＳ６０６へ、さもなければ、ステップＳ６０１へ進む。
［ステップＳ６０６］
有線−無線ブリッジ部１２１はＬＡＮ通信部１０６から受信データを受け取る。
［ステップＳ６０７］
有線−無線ブリッジ部１２１は、ステップＳ６０６で取り出した受信データを無線ＬＡＮ側に中継する必要があるかどうかを判断する。中継するかどうかの判断の方法は従来のブリッジ処理と同様なので割愛する。中継する必要がある場合は、ステップＳ６０８へ、さもなければ、ステップＳ６０１へ進む。
［ステップＳ６０８］
有線−無線ブリッジ部１２１は、ステップＳ６０６で取り出した受信データをＩＥＥＥ８０２．３のＭＡＣヘッダの形式からＩＥＥＥ８０２．１１のＭＡＣヘッダの形式に変換し、送信パケットキュー１１１に入れる。

次に、親機４００の無線送信タスクについて図２１の本発明に係る実施の形態１による無線ＬＡＮ電話システム親機のブリッジタスクの動作を示すフローチャートに沿って説明する。親機４００の無線送信タスクは、子機３００の無線送信タスクとほぼ同様であるが、親機４００では、送信待ち許容時間を計算しない部分が子機３００の無線送信タスクと異なっている。以下、子機３００の無線送信タスクと異なる部分を説明する。親機４００では同時に複数の子機３００に対する処理を行っている。ここでは、子機Ａ３００に対する親機Ａ４００の処理に注目して説明する。
［ステップＳ７０１］
図１３のステップＳ３０１と同様である。
［ステップＳ７０２］
制御部１３０は、ＱｏＳ管理部１２２に子機Ａ３００に対する「サービス周期」を問い合わせ、ＲＴＣ１０８を参照して、次の送信時刻を計算し、「次の送信時刻」を更新する。ここでは、サービス周期は１０．２４ｍｓであり、ＲＴＣ１０８の値が１２：３３ ２２．０１３ ９９４であるため、したがって、次の送信時刻は１２：３３ ２２．０２４ ２３４ となる。
［ステップＳ７０３からＳ７０４］
図１３のステップＳ３０３からＳ３０４と同様である。
［ステップＳ７０５］
制御部１３０は、エラー率判定部１１９にエラー率が予め設定された閾値よりエラー率が低いかどうかを問い合わせる。エラー率判定部１１９は、制御部１３０に判定結果を渡す。受け取った判定結果から、エラー率が低い場合はステップＳ７０９へ、さもなければステップＳ７１５へ進む。
［ステップＳ７０９からＳ７１９］
図１３のステップＳ３０９からＳ３１９と同様である。

以上のように、親機４００では、送信時刻までに送信パケットキュー１１１に届いたパケットを無条件にひとつの無線フレームにまとめている（子機では、次の送信時刻でも間に合うかどうかを判断し、なるべく、送信すべき音声パケットを貯めてからまとめて送信する処理になっている）。

図２２は従来のＴＤＭ方式における音声のエンコードと無線フレームの送信のタイミングを示した図を示したものである。図で示したようにＣ０のタイミングで発生した音声パケットは、本来Ｔ０の間で送信されれば、遅延許容時間内に相手に届くが、従来の送信方法ではＳ０のタイミングで送信している。つまり、従来の送信方法では「いつまでに送信すれば遅延許容時間内に届くか」をまったく考慮せず、送信要求が発生した時点からもっとも早い送信タイミングで送信している。これに対して、図２３は、本発明に係る実施の形態１による音声のエンコードと無線フレームの送信タイミングを示した図を示したものである。Ｃ１とＣ２で発生した音声パケットはＳ１のタイミングでまとめて送信される。このように、本発明による方法では、送信の許容タイミング内で複数の送信パケットをひとつのフレームにまとめて送信するため、通信帯域の消費量を少なくすることができる。図２２、図２３を比較すると、送信の許容タイミングがコーデックの周期以上あり、かつ、送信タイミングの周期とコーデックの周期がほぼ同一の場合（無線ＬＡＮ電話システムでは、しばしば、このような状況でシステムが運用される）、本発明による送信方法が通信帯域を有効に利用できることがわかる。

これにより、ユーザは、音声通話時に不快な遅延を感じることなく、また、同時にデータ通信を行われていても、ストレス無く、データ通信を行うことができる。

以上のように本実施の形態の無線ＬＡＮ電話システムの子機３００は、発呼先の指定、着呼時に通話の指示および終話の指示をするための操作部１０１と、音声を入力するための音声入力部１０２と、音声を出力するための音声出力部１０３と、受信した無線フレームを蓄積する受信バッファ１０４と、送信用のデータを蓄積する送信バッファ１０５と、この送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部１０７と、時間の経過を測定するためのＲＴＣ１０８と、音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量を記憶するパラメータ記憶部１０９とを有している。

そして、無線ＬＡＮ電話システムの子機３００は、さらに、音声入力部１０２から入力した音声をＡ／Ｄ変換し、所定のアルゴリズムを用いて音声パケットに変換（エンコード）する、また、音声データを所定のアルゴリズムを用いてデコードした上で、Ｄ／Ａ変換し、音声出力部１０３に出力するコーデック部１１０と、このコーデック部１１０が出力した音声パケットをＦＩＦＯ方式で記憶する送信パケットキュー１１１と、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつのフレームにまとめて送信バッファ１０５に書き込むペイロード統合部１１２と、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキュー１０３と、受信バッファ１０５に記憶された内容から、元来ひとつの音声パケットであったかどうか判断し、複数の音声パケットが統合されている場合は、これを複数の音声パケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部１１４と、パラメータ記憶部１０９に記憶された音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量と、無線送信周期もしくは送信待ち時間の予測値とＲＴＣの値を比較・参照し、送信待ちの許容時間を算出する、送信待ち許容時間算出部１１５と、発呼、着呼、呼の接続・切断の制御、および、呼の各状態に応じたシグナル（ダイヤルトーン、ビジートーン、リンガー、リング・バック・トーン）を前記音声出力部に出力する呼制御部１１６と、呼の設定や解除、通話時の音声パケットの送受信を処理するプロトコル処理部１１７と、装置の全体を制御する制御部１３０とを有している。

これにより、親機４００との通信において、無線フレーム化の際のオーバーヘッドが軽減され、かつ、音声の遅延を縮小することができる。

また、本実施の形態の無線ＬＡＮ電話システムの子機３００は、タイムスロットの管理を行うＴＳ管理部１２０をさらに有し、親機４００との無線通信をＴＤＭで行う。これにより、無線フレーム化の際のオーバーヘッドが軽減され、かつ、音声の遅延が縮小され、さらに、１アクセスポイントあたりの同時通話数が増大し、また、通話中にデータ通信を行う際にデータ通信が使用できる帯域幅を大きく取ることができる。

さらに、本実施の形態の無線ＬＡＮ電話システムの親機４００は、有線・無線ブリッジ部１２１を有している。親機４００は、この有線−無線ブリッジ部１２１の機能を使って異なるフレーム間で中継を行う。つまり、子機３００からの無線フレームを、ＬＡＮ通信部（有線）を使用してインターネット側にイーサネット（登録商標）フレームとして中継したり、インターネット側からのイーサネット（登録商標）フレームを子機３００に無線フレームとして中継したりする。例えば、ＩＥＥＥ８０２．１１のＭＡＣヘッダ形式をＩＥＥＥ８０２．３のＭＡＣヘッダの形式に変換し、ＬＡＮ通信部１０６よりエントリの内容を送信したり、受信データをＩＥＥＥ８０２．３のＭＡＣヘッダの形式からＩＥＥＥ８０２．１１のＭＡＣヘッダの形式に変換し、送信パケットキュー１１１に入れたりすることにより、有線と無線の間で通信するフレームを中継する。

（実施の形態２）
図２４は本発明に係る実施の形態２による無線ＬＡＮ電話システム子機の構成を示す機能ブロック図である。図２４において、子機３１０は、１０１から１２３にて示す機能構成を有している。なお、子機３１０のハード構成は、実施の形態１のもの（図２）と同様である。

図２４において、１０１は、発呼先の指定、着呼時に通話の指示および終話の指示をするための操作部である。１０２は、音声を入力するための音声入力部である。１０３は、音声を出力するための音声出力部である。１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファである。１０５は、無線送信用のデータを蓄積する送信バッファである。１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部である。１０８は、時間の経過を測定するためのＲＴＣである。１０９は、音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、予め指定されたネットワークの遅延量を記憶するパラメータ記憶部である。

また、１１０は、音声入力部１０２から入力した音声をＡ／Ｄ変換し、所定のアルゴリズムを用いて音声パケットに変換（エンコード）する、また、音声データを所定のアルゴリズムを用いてデコードした上で、Ｄ／Ａ変換し、音声出力部１０３に出力するコーデック部である。１１１は、コーデック部１１０がエンコードした音声パケットをエンコードが完了した時刻、すなわち、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキューである。１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつのフレームにまとめて送信バッファに書き込むペイロード統合部である。１１３は、無線フレームとして受け取ったデータを音声パケットに分解してＦＩＦＯ方式で記憶する、受信パケットキューである。

また、１１４は、受信バッファ１０４に記憶された内容をもともとひとつの音声パケットであったかどうか判断し、複数の音声パケットが統合されている場合は、これを複数の音声パケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。１１５は、パラメータ記憶部１０９に記憶された音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、予め指定されたネットワークの遅延量を参照し、ＲＴＣ１０８の値を送信要求受付時刻と比較し、送信待ちの許容時間を算出する、送信待ち許容時間算出部である。１１６は、発呼、着呼、呼の接続・切断の制御、および、各呼の状態に応じたダイヤルトーン、ビジートーン、リンガー、リング・バック・トーンを音声出力部１０３に出力する呼制御部である。１１７は、呼の設定や解除、通話時の音声パケットの送受信、を指定されたプロトコルに従って処理するプロトコル処理部である。１２３は、ネットワークの遅延を測定する、ネットワーク遅延測定部である。１３０は、全体を制御する制御部である。

図２のハード構成との関係を説明する。１０１の操作部は、２１１のキーボードによって構成されている。１０２の音声入力部は、２０８のマイクによって構成されている。１０３の音声出力部は、２１０のスピーカによって構成されている。１０４の受信バッファ、１０５の送信バッファ、１０９のパラメータ記憶部、１１１の送信パケットキュー、１１３の受信パケットキューは、２０３のＲＡＭによって構成されている。１０７の無線通信部は、２０５のベースバンド部と２０６のＲＦによって構成されている。１０８のＲＴＣは、２０４のＲＴＣによって構成されている。

また、１１０のコーデック部は、２１２のコーデック、２０７のＡ／Ｄ、２０９のＤ／Ａによって構成されている。１１２のペイロード統合部、１１４のペイロード分割部、１１５の送信待ち許容時間算出部、１２３のネットワーク遅延測定部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって構成されている。

図２５は本発明に係る実施の形態２による無線ＬＡＮ電話システム親機の構成を示す機能ブロック図である。図２５において、親機４１０は、１０４から１２１にて示す機能構成を有している。なお、親機４１０のハード構成は、実施の形態１のもの（図４）と同様である。

図２５において、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファである。１０５は、無線送信用のデータを蓄積する送信バッファである。１０６は、有線のネットワークと接続するためのＬＡＮ通信部である。１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部である。１０８は、時間の経過を測定するためのＲＴＣである。１１１は、後述する有線−無線ブリッジ部１２１が、中継が必要と判断したＬＡＮ側からのフレームを無線フレーム化して送信するために、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキューである。１１２は、送信待ち時間内に送信パケットキュー１１１に入力された音声パケットをひとつのフレームにまとめて送信バッファに書き込むペイロード統合部である。１１３は、無線フレームとして受け取ったデータを音声パケットに分解してＦＩＦＯ方式で記憶する、受信パケットキューである。１１４は、受信バッファ１０４に記憶された内容をもともとひとつの音声パケットであったかどうか判断し、複数の音声パケットが統合されている場合は、これを複数の音声パケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。１２１は、有線と無線の間のフレームを必要があれば中継し、さもなければ破棄する、有線−無線ブリッジ部、１３０は、全体を制御する制御部である。

図４のハード構成との関係を説明する。１０４の受信バッファ、１０５の送信バッファ、１１１の送信パケットキュー、１１３の受信パケットキューは、２０３のＲＡＭによって構成されている。１０７の無線通信部は、２０５のベースバンド部と２０６のＲＦによって構成されている。１０８のＲＴＣは、２０４のＲＴＣによって構成されている。１０６のＬＡＮ通信部は、２１３のネットワークＩ／Ｆによって構成されている。

１１２のペイロード統合部、１１４のペイロード分割部、１２１の有線−無線ブリッジ部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって構成されている。

本実施の形態の無線ＬＡＮ電話システム全体の構成は実施の形態１と同様なので説明を省略する。図２６の本発明に係る実施の形態２による無線ＬＡＮ電話システムの動作概要を示すシーケンスチャートは、本実施の形態の親機４１０と子機３１０の動作概要を示している。なお、実施の形態１における図６とほぼ同様であるが、ＱｏＳの確保と解放の処理がない点が異なる。なお、本説明では、子機３１０は最初、待ち受け状態にあるものとする。
［ステップＥ２０１からＥ２０５］
実施の形態１における図６のステップＥ０１からＥ０５と同様である。
［ステップＥ２０６］
子機Ｂ３００において、ユーザが着信音を聞いて着信していることに気がつくと、操作部１０１を操作して、通話を指示する。これにより、子機Ｂ３００では、制御部１３０が操作部１０１から「通話を指示された」旨を受け取り、呼制御部１１６に「呼を接続する」よう要求する。そしてさらに、呼制御部１１６は、エンコードタスクとデコードタスクを起動する。以降、呼切断が指示されるまで、音声入力部１０２から受け取った音声をコーデック部１１０がエンコードし、結果を音声パケットとして子機Ａ３００へ送信するようプロトコル処理部１１７に要求する。すると音声パケットは前述と同様に、親機Ｂ４００、親機Ａ４００を経由して子機Ａ３００に届く。また、子機Ｂ３００において、コーデック部１１０が無線通信部１０７、プロトコル処理部１１７を経由して受け取った子機Ａ３００からの音声パケットは、デコードされ、結果が音声出力部１０３に出力されるようになる。ステップＭ２０８へ進む。
［ステップＭ２０８］
実施の形態１の図６のステップＭ０８と同様である。ステップＥ２１０へ進む。
［ステップＥ２１０］
以降、全２重の通信路が確保され、通話が可能となる。ここでは、インターネットの通信帯域は十分広く、遅延も数１０ｍｓ程度であることを仮定している。つまり、子機Ａ３００と子機Ｂ３００の間での通信のボトルネックは子機−親機間であると仮定している。
［ステップＭ２１１］
通話中、子機Ａ３００のユーザの音声は子機Ａ３００の音声入力部１０２に入力され、前述のようにコーデック部１１０によってエンコードされ、音声パケットとしてプロトコル処理部１１７によって子機Ｂ３００まで送信される。子機Ｂ３００では、無線通信部１０７、プロトコル処理部１１７を経由してコーデック部１１０が音声パケットを受け取り、これをデコードし、結果を子機Ｂ３００の音声出力部１０３に出力する。子機Ｂ３００側でのユーザの音声が子機Ａ３００に届く処理は、前述の処理とちょうど対称の処理となるため、詳細は割愛する。
［ステップＥ２１２］
実施の形態１の図６のステップＥ１２と同様である。ステップＭ２１４へ進む。
［ステップＭ２１４］
実施の形態１の図６のステップＭ１４と同様である。
［ステップＥ２１５］
実施の形態１の図６のステップＥ１５と同様である。ステップＭ２１７へ進む。
［ステップＭ２１７からＥ２１８］
実施の形態１の図６のステップＭ１７からＥ１８と同様である。

次に子機３１０の動作について説明する。図２７は本発明に係る実施の形態２による無線ＬＡＮ電話システム子機のタスク構成を示す図を示している。実施の形態１のもの（図７）と比較して、測定タスクが追加されている。一方、親機４１０のタスク構成は実施の形態１のもの（図８）と同様である。まず、子機３１０のタスクについてその動作を説明する。なお、子機３１０のタスクのうち、エンコードタスク、デコードタスク、プロトコル処理タスクは、実施の形態１のものと同一なので説明を省略する。

図１１のステートチャートに沿って本実施の形態における子機３１０の呼制御タスクについて説明する。まず、子機Ａ３００の電源がＯＮされて、子機Ａ３００のユーザが発呼、通話、切断を行う一連の処理について呼制御タスクの動作を子機Ａ３００の側から説明する。
［ステップＥ１０１］
子機の電源ＯＮが操作部１０１から指示されると、制御部１３０は呼制御タスク、プロトコル処理タスク、無線送信タスク、無線受信タスクを起動する。呼制御タスクは起動されると、待ち受け状態に遷移する。これにより、以降、発着呼が可能になる。
［ステップＥ１０２］
子機Ａ３００でユーザが操作部１０１を操作して子機Ｂ３００に発呼を行う。子機Ａ３００の制御部１３０は操作部１０１からの「発呼」の通知を受け、発呼先番号を受け取り、呼制御部１１６に相手先番号を指定して「呼接続」要求する。呼制御部１１６は、「ＩＮＶＩＴＥ」メッセージを子機Ｂ３００まで送信するようプロトコル処理部１１７に要求する。子機Ｂ３００は、「ＩＮＶＩＴＥ」メッセージを受け付けて、着呼中となり、「ＲＩＮＧＩＮＧ」メッセージを子機Ａ３００に送り返してくる。子機Ａ３００の呼制御部１１６はプロトコル処理部１１７経由で子機Ｂ３００からの「ＲＩＮＧＩＮＧ」メッセージを受信し、発呼中状態に遷移する。呼制御部１１６はＲＢＴを音声出力部１０３に出力し、ユーザに「呼び出し中」であることを知らせる。
［ステップＥ１０３］
子機Ｂ３００では、リンガー（着信音）が鳴っており、ユーザは着信音に気づいて着信を受け入れる。これにより、エンコードタスク、デコードタスクが起動された後、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａ３００に送信してくる。子機Ａ３００では、呼制御部１１６が、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを、プロトコル処理部１１７を経由して受け取る。

これにより、呼制御部１１６は前述のエンコードタスクとデコードタスクを起動し、コーデック部１１０は、以降の音声入力部１０２からの音声をＡ／Ｄ変換およびエンコードし、音声パケットとしてプロトコル処理部１１７に渡す。また、コーデック部１１０はプロトコル処理部１１７が受け取った音声パケットをデコードおよびＤ／Ａ変換し、音声出力部１０３に出力する。通話中に遷移する。
［ステップＥ１０９］
子機Ａ３００のユーザが通話を終えた場合、子機Ａ３００の操作部１０１を操作して、呼を切断する。制御部１３０は操作部１０１からの切断操作の通知を受け、呼制御部１１６に「呼切断」を要求する。呼制御部１１６はエンコードタスクとデコードタスクを停止さる。これにより、呼制御部１１６は「ＢＹＥ」メッセージを子機Ｂ３００へ送るようプロトコル処理部１１７に要求する。プロトコル処理部１１７は無線処理部１０７を経由して「ＢＹＥ」メッセージを意味するデータを親機Ａ４００に送信し、インターネット、親機Ｂ４００、を経由して子機Ｂ３００に到着する。子機Ｂ３００は「ＢＹＥ」メッセージを受け取ると、「ＢＹＥ−ＯＫ」を子機Ａ３００に返送する。子機Ａ３００では、無線通信部１０７、プロトコル処理部１１７を経由して、呼制御部１１６が「ＢＹＥ−ＯＫ」メッセージを受け取る。これにより、待ち受け状態に遷移する。
［ステップＥ１０７］
また、ユーザが発呼中に発呼を取りやめる場合は、操作部１０１から発呼取りやめの指示を行い、制御部１３０が操作部１０１から発呼取りやめの指示を受け取り、呼制御部１１６に発呼取りやめを要求する。呼制御部１１６はプロトコル処理部１１７に「ＣＡＮＣＥＬ」のメッセージを子機Ｂ３００へ送信するよう要求する。子機Ｂ３００はリンガーを停止、「ＣＡＮＣＥＬ−ＯＫ」メッセージを子機Ａ３００に送信する。子機Ａ３００では、子機Ｂ３００からの「ＣＡＮＣＥＬ−ＯＫ」をプロトコル処理部１１７が受け取り呼制御部１１６に通知すると、呼制御部１１６は待ち受け状態に遷移する。

次に、子機Ｂ３００側からみた、呼制御タスクの動作について説明する。
［ステップＥ１０４］
プロトコル処理部１１７は子機Ａ３００から「ＩＮＶＩＴＥ」メッセージを受け取り、呼制御部１１６に通知する。呼制御部１１６はプロトコル処理部１１７に「ＲＩＮＧＩＮＧ」メッセージを子機Ａ３００に返送するよう要求する。呼制御部１１６はリンガーを音声出力部１０３に出力し、ユーザに着信が発生していることを知らせる。呼制御部１１６は着呼中状態に遷移する。
［ステップＥ１０５］
ユーザはリンガーによって着呼していることを知り、操作部１０１を操作して、着信に応答する。制御部１３０は操作部１０１から着信応答を受け取り、呼制御部１１６に応答を要求する。

これにより、呼制御部１１６は「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａ３００に送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａ３００に送信する。さらに呼制御部１１６は、音声出力部１０３へのリンガーの出力を停止し、エンコードタスクとデコードタスクを起動して、以降の音声入力部１０２からの音声がＡ／Ｄ変換・エンコードされ、音声パケットとして子機Ａ３００へ送信されるようにし、また、子機Ａ３００からの音声パケットがデコード・Ｄ／Ａ変換され、音声出力部１０３から出力されるようにする。
［ステップＥ１０９］
プロトコル処理部１１７は子機Ａ３００から「ＢＹＥ」メッセージを受信し、呼制御部１１６に通知する。呼制御部１１６はエンコードタスクとデコードタスクを停止し、待ち受け状態に遷移する。また、子機Ａ３００のユーザが発呼中に発呼を取りやめた場合は、
［ステップＥ１０８］
プロトコル処理部１１７は「ＣＡＮＣＥＬ」メッセージを受信し、呼制御部１１６に通知する。呼制御部１１６はリンガーを停止し、子機Ａ３００に「ＣＡＮＣＥＬ−ＯＫ」メッセージを送信するようプロトコル処理部１１７に要求し、待ち受け状態に遷移する。

次に、図２８の本発明に係る実施の形態２による無線ＬＡＮ電話システム子機の測定タスクの動作を示すフローチャートに沿って測定タスクについて説明する。本実施の形態では、通話を行う子機３１０同士が予め別の方法でお互いのＲＴＣ１０８をあわせていることを前提にしている。お互いの時計を合わせる方法としてはＧＰＳを用いる方法や、ＮＴＰと呼ばれるプロトコルを用いる方法が一般的であるが、ここでは詳細を記述しない。
［ステップＳ８０１］
ネットワーク遅延測定部１２３は、受信パケットキュー１１３を参照して、測定パケットが届いているかどうかを判断する。届いていればステップＳ８０２へ、さもなければ、Ｓ８０３へ進む。
［ステップＳ８０２］
ネットワーク遅延測定部１２３は、受信パケットキュー１１３から、パケットを取り出す。
［ステップＳ８０３］
ネットワーク遅延測定部１２３は、取り出したパケットの中身を参照して、そのパケットがいつ送信されたかを読み取り、ＲＴＣ１０８を参照して、現在の時刻と比較する。その結果をネットワークの遅延量としてパラメータ記憶部１０９に書き込む。ステップＳ８０１へ進む。ここでは、パケットに書かれた時刻が１２：３３ １２．６５４ ２２３だったとする。ＲＴＣ１０８が１２：３３ １２．７３４ ２２３を示しているとすると時間差は８０ｍｓとなり、これをパラメータ記憶部１０９にネットワーク遅延量として書き込む。
［ステップＳ８０４］
ネットワーク遅延測定部１２３は、ＲＴＣ１０８を参照して送信予定時刻になったかどうかを判断する。予定時刻になっていれば、次の送信予定時刻を設定して、ステップＳ８０４へ、さもなければ、ステップＳ８０１へ進む。ここでは、測定パケットの送信は５秒に一度とする。したがって、送信予定時刻は、５秒後となる。
［ステップＳ８０５］
ネットワーク遅延測定部１２３は、ＲＴＣ１０８を参照して、現在の時刻を読み取り、これをパケットの内容として送信パケットキュー１１１に入れる。ステップＳ８０１へ進む。

このように、子機３１０がお互いに、測定パケットを交換することによって、ネットワークの遅延量を測定し、これを基に無線送信タスクで送信待ち許容時間を算出する。これにより、ネットワークのトラフィックに変動が起こってネットワーク遅延量が変化しても、この変化を打ち消すように送信待ち許容時間を算出することができるので、安定した通話を確保できる。

図２９は本発明に係る実施の形態２による無線ＬＡＮ電話システム子機の無線送信タスクの動作を示すフローチャートである。実施の形態１のものと比較すると、エラー率によって複数の音声パケットをひとつのフレームにまとめるかどうかの判断を行わない。つまり、本実施の形態では、常に複数の音声パケットをひとつのフレームにまとめる処理を行う。
［ステップＳ９０１］
実施の形態１における図１３のステップＳ３０１と同様である。
［ステップＳ９０２］
制御部１３０は、送信予定時刻を予想する。本実施の形態ではＣＳＭＡ／ＣＡ方式で通信が行われているものとする。ＣＳＭＡ／ＣＡ方式では、送信の要求が発生した時点で、送信できるかどうかの判断を行い、送信を行うので、次に、確実に送信要求が発生する時刻を予想すればよい。したがって、次のコーデックが終了したとき、送信要求が発生する。さらに、ＣＤＭＡ／ＣＡ方式では、実際に送信要求が発生してから、バックオフアルゴリズムによって、ランダムな時間待ってから送信するため、平均的な待ち時間としてここでは、１ｍｓを採用する。ＲＴＣ１０８より現在の時刻は１２：３３ ２２．０１３ ９９４なので、制御部１３０は、パラメータ記憶部１０９を参照して、コーデック周期から次の送信時刻を１０ｍｓ、平均的な送信待ち時間を１ｍｓとして、１１ｍｓ後の１２：３３ ３２．０２４ ９９４と予想する。
［ステップＳ９０３］
実施の形態１における図１３のステップＳ３０３と同様である。
［ステップＳ９０４］
制御部１３０は、送信パケットキュー１１１の最初のエントリに注目する。ステップＳ９０６へ進む。
［ステップＳ９０６］
制御部１３０は、送信待ち許容時間算出部１１５に、注目しているエントリの送信要求受付時刻を渡して、送信待ち許容時間を算出するよう要求する。これにより、遅延許容時間算出部はパラメータ記憶部１０９とＲＴＣ１０８とエントリと対応付けて記録された送信要求受付時刻とを参照し、遅延許容時間を算出する。まず、ＲＴＣ１０８と送信要求受付時刻から送信待ち時間を求める。ここでは（数５）に示す以下の値であるとする。

また（数６）がパラメータ記憶部１０９に予め、記憶されているものとする。

これらの値については実施の形態１で説明したものと同様なので説明を省略する。

以上の値によって（数７）によって送信待ち許容時間を計算する。

図１４は上式を分かりやすく図示したものである。上記より注目しているエントリの送信待ち許容時間は１３ｍｓとなる。
［ステップＳ９０７］
制御部１３０は、次回の送信で間に合うかどうかを判断する。間に合うと判断した場合はステップＳ９０９へ、さもなければステップＳ９０８へ進む。ここで、現在の時刻が１２：３３ ２２．０１３ ９９４である。この場合、送信待ち許容時間が１３ｍｓであるため、最悪、１２：３３ ２２．０２６ ９９４までに送信すればよいことがわかる。次の送信時刻は１２：３３ ３２．０２４ ９９４なので、次の送信で間に合うと判断する。
［ステップＳ９０８］
制御部１３０は、今回の送信のタイミングで送信すべきデータがすでに送信バッファ１０５に存在しているかどうかを判断する。つまり、次の送信でも間に合うとステップＳ９０７で判断されても、すでに、送信バッファ１０５に送信すべきデータが存在していれば、まとめて送信するほうが、送信効率がよい。すなわち、存在している場合は、ステップＳ９０９へ、さもなければ、ステップＳ９０１へ進む。ここでは、送信バッファ１０５にデータが存在していなかったこととして説明を続ける。この場合、ステップＳ９０１に進む。以降、時間が経過し、時刻が１２：３３ ３２．０２４ ９９４になったとする。このとき次回の送信時刻は１２：３３ ３２．０３５ ９９４であるとする。ここでは、ステップＳ９０１からステップＳ９０４およびステップＳ９０６を実行する。ここで図１５に示すように送信パケットキュー１１１に２つの音声パケットがエンキューされているものとする。ステップＳ９０７では、エントリ１は次回の送信では間に合わない、と判断されるため、ステップＳ９０９へ進む。
［ステップＳ９０９からＳ９１１］
実施の形態１における図１３のステップＳ３０９からＳ３１１と同様である。
［ステップＳ９１２］
制御部１３０は、次のエントリに注目する。ステップＳ９０６へ進む。
［ステップＳ９１３からＳ９１４］
実施の形態１における図１３のステップＳ３１３からＳ３１４と同様である。

上の例では、ステップＳ９０７、ステップＳ９０９、ステップＳ９１０、と実行され、ステップＳ９１１では、送信パケットキュー１１１にもうひとつエントリがあるのでステップＳ９１２へ進み、ステップＳ９０６、ステップＳ９０７へ進む。ステップＳ９０７では、エントリ２に関して、次の送信時刻でも間に合う、と判断され、ステップＳ９０８に進む。ステップＳ９０８では、すでに送信バッファ１０５にエントリ１に対応するデータが書き込まれているためステップＳ９０９へ進む。ステップＳ９１０でデータがマージされたあと、ステップＳ９１１で、未処理のエントリが無い、と判断されて、ステップＳ９１３、ステップＳ９１４と処理を進める。

次に、データのマージ処理について図３０の本発明に係る実施の形態２による無線ＬＡＮ電話システムの送信マージ処理を示すフローチャートに沿って説明する。実施の形態１のものと比較すると、上位プロトコル解析処理を行わないで、単純にペイロードをひとつのフレームにまとめている。
［ステップＳ１００１］
ペイロード統合部１１２は、送信バッファ１０５にデータが書き込まれているかどうかを判断する。書き込まれていればステップＳ１００４へ、さもなければ、ステップＳ１００２へ進む。
［ステップＳ１００２］
ペイロード統合部１１２は、送信バッファ１０５にＭＡＣヘッダを書き込む。ステップＳ１００４へ進む。
［ステップＳ１００４からＳ１００６］
実施の形態１における図１６のステップＳ４０４からＳ４０６と同様である。

以上のようにして、書き込まれた送信バッファ１０５の様子を、図３１の本発明に係る実施の形態２による無線ＬＡＮ電話システムによって複数の音声パケットがひとつの無線フレームにまとめられたときのフレーム・フォーマットを示す図に示す。

次に、無線受信タスクの動作について図３２の本発明に係る実施の形態２による無線ＬＡＮ電話システムの無線受信タスクの動作を示すフローチャートに沿って説明する。なお、本実施の形態では無線受信タスクは、子機３１０、親機４１０ともに同一の処理を行う。ここで、自局宛の無線フレームは無線通信部１０７によって受信され、受信バッファ１０４にフレームの内容をデータとして書き込んでいるものとする。
［ステップＳ１１０１からＳ１１０４］
実施の形態１における図１９のステップＳ５０１からＳ５０４と同様である。
［ステップＳ１１０５］
ペイロード分割部１１４は先頭の１バイトをデリミタと解釈し、値を読み出し、ペイロードが何バイトかを得て、以降のペイロードを取り出す。ステップＳ１１０７へ進む。
［ステップＳ１１０７からＳ１１１０］
実施の形態１における図１９のステップＳ５０７からＳ５１０と同様である。

以上の処理によって、もともと複数の音声パケットがひとつの無線フレームにまとめられていても、正しくもとの音声パケットに分割され、プロトコル処理部１１７に渡される。デコードタスクは、規定された遅延時間内にデコード処理を完了し、音声として再生する。

次に、親機４１０についてであるが、親機４１０のタスク構成は実施の形態１と同様であり、ブリッジタスクは、実施の形態１のものと同様である。無線受信タスクについては実施の形態２の子機と同様であるため、説明を省略し、ここでは親機４１０の無線送信タスクのみを説明する。本実施の形態における親機４１０の無線送信タスクについて図３３の本発明に係る実施の形態２による無線ＬＡＮ電話システム親機の無線送信タスクの動作を示すフローチャートに沿って説明する。
［ステップＳ１２０１からＳ１２０３］
実施の形態１における図２１のステップＳ７０１からＳ７０３と同様である。
［ステップＳ１２０４］
制御部１３０は、送信パケットキュー１１１の最初のエントリに注目する。ステップＳ１２０９へ進む。
［ステップＳ１２０９からＳ１２１１］
実施の形態１における図２１のステップＳ７０９からＳ７１１と同様である。
［ステップＳ１２１２］
制御部１３０は、次のエントリに注目する。ステップＳ１２０９へ進む。
［ステップＳ１２１３からＳ１２１４］
実施の形態１における図２１のステップＳ７１３からＳ７１４と同様である。

これまで説明してきたように、本実施の形態で示した子機３１０と親機４１０を組み合わせて利用すれば、無線の通信帯域を有効に利用でき、しかも、通話中の音声の遅延を実用的な範囲内に抑えることが可能になる。

以上のように本実施の形態の発明の無線ＬＡＮ電話システムの子機３１０は、ネットワークの遅延量を測定するネットワーク遅延測定部１２３を有するので、親機４１０との通信において、ネットワークの遅延量が変動しても、音声の遅延が許容範囲内で一定となり、ネットワークの遅延が大きくなっても音声が途切れたり、遅延が大きくなって会話がちぐはぐになったりすることがない。

以上のように本発明にかかる無線ＬＡＮ電話通信方法および無線ＬＡＮ電話システムは、通信帯域を必要以上に消費せず、また、音声遅延の許容範囲内で、音声データの送受信ができるので、同時に多くの通話が発生しても話者に不快な遅延を感じさない通話環境を提供できる。これにより、親機一台あたりに収容できる子機の数を大幅に増加させることができる。また、同じ無線の通信帯域を利用してデータ通信を行っているユーザに対しても、音声通話がデータ通信の帯域を圧迫しないので、ストレスの少ない通信環境を提供できる。

本発明に係る実施の形態１による無線ＬＡＮ電話システム子機の構成を示す 機能ブロック図 本発明に係る実施の形態１による無線ＬＡＮ電話システム子機の構成を示す 装置ブロック図 本発明に係る実施の形態１による無線ＬＡＮ電話システム親機の構成を示す 機能ブロック図 本発明に係る実施の形態１による無線ＬＡＮ電話システム親機の構成を示す 装置ブロック図 本発明に係る実施の形態１による無線ＬＡＮ電話システムの全体構成を示す 図 本発明に係る実施の形態１による無線ＬＡＮ電話システムの動作概要を示す シーケンスチャート 本発明に係る実施の形態１による無線ＬＡＮ電話システム子機のタスク構成 を示す図 本発明に係る実施の形態１による無線ＬＡＮ電話システム親機のタスク構成 を示す図 本発明に係る実施の形態１による無線ＬＡＮ電話システム子機のエンコード タスクの動作を示すフローチャート 本発明に係る実施の形態１による無線ＬＡＮ電話システム子機のデコード タスクの動作を示すフローチャート 本発明に係る実施の形態１、２による無線ＬＡＮ電話システム子機の呼制 御タスクの動作を示すステートチャート 本発明に係る実施の形態１、２による無線ＬＡＮ電話システム子機のプロ トコル処理タスクの動作を示すフローチャート 本発明に係る実施の形態１による無線ＬＡＮ電話システム子機の無線送信 タスクの動作を示すフローチャート 本発明に係る実施の形態１、２による無線ＬＡＮ電話システムの音声の遅 延量の内訳を示す図 本発明に係る実施の形態１による無線ＬＡＮ電話システム子機の送信パケ ットキュー１１１の内容を示す図 本発明に係る実施の形態１による無線ＬＡＮ電話システムの送信マージ処 理を示すフローチャート ＩＥＥＥ８０２．１１による無線フレームのフォーマットを示す図 本発明に係る実施の形態１によって２つの音声パケットが１つの無線フレ ームにまとめられたときのフレーム・フォーマットを示す図 本発明に係る実施の形態１による無線ＬＡＮ電話システムの受信タスクの 動作を示すフローチャート 本発明に係る実施の形態１による無線ＬＡＮ電話システム親機のブリッジ タスクの動作を示すフローチャート 本発明に係る実施の形態１による無線ＬＡＮ電話システム親機の無線送信 タスクの動作を示すフローチャート 従来のＴＤＭ方式における音声のエンコードと無線フレームの送信のタイ ミングを示した図 本発明に係る実施の形態１による音声のエンコードと無線フレームの送信 タイミングを示した図 本発明に係る実施の形態２による無線ＬＡＮ電話システム子機の構成を示 す機能ブロック図 本発明に係る実施の形態２による無線ＬＡＮ電話システム親機の構成を示 す機能ブロック図 本発明に係る実施の形態２による無線ＬＡＮ電話システムの動作概要を示 すシーケンスチャート 本発明に係る実施の形態２による無線ＬＡＮ電話システム子機のタスク構 成を示す図 本発明に係る実施の形態２による無線ＬＡＮ電話システム子機の測定タス クの動作を示すフローチャート 本発明に係る実施の形態２による無線ＬＡＮ電話システム子機の無線送信 タスクの動作を示すフローチャート 本発明に係る実施の形態２による無線ＬＡＮ電話システムの送信マージ処 理を示すフローチャート 本発明に係る実施の形態２による無線ＬＡＮ電話システムによって複数の 音声パケットがひとつの無線フレームにまとめられたときのフレーム・フォーマット を示す図 本発明に係る実施の形態２による無線ＬＡＮ電話システムの無線受信タス クの動作を示すフローチャート 本発明に係る実施の形態２による無線ＬＡＮ電話システム親機の無線送信 タスクの動作を示すフローチャート

符号の説明

１０１ 操作部
１０２ 音声入力部
１０３ 音声出力部
１０４ 受信バッファ
１０５ 送信バッファ
１０６ ＬＡＮ通信部
１０７ 無線通信部
１０８ ＲＴＣ
１０９ パラメータ記憶部
１１０ コーデック部
１１１ 送信パケットキュー
１１２ ペイロード統合部
１１３ 受信パケットキュー
１１４ ペイロード分割部
１１５ 送信待ち許容時間算出部
１１６ 呼制御部
１１７ プロトコル処理部
１１８ 上位プロトコル解析部
１１９ エラー率判定部
１２０ ＴＳ管理部
１２１ 有線−無線ブリッジ部
１２２ ＱｏＳ管理部
１２３ ネットワーク遅延測定部
１３０ 制御部
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ ＲＴＣ
２０５ ベースバンド部
２０６ ＲＦ
２０７ Ａ／Ｄ
２０８ マイク
２０９ Ｄ／Ａ
２１０ スピーカ
２１１ キーボード
２１２ コーデック
２１３ ネットワークＩ／Ｆ

Claims (7)

1. 無線ＬＡＮを利用した電話システムにおいて、
   送信側では、音声の遅延許容時間から、音声のコーデック周期、音声のコーデック遅延×２、コーデック待ち時間、送信待ち時間、及び、予め指定されたネットワークの遅延量を差し引いた値である送信待ち許容時間を計算して、該送信待ち許容時間の範囲内で複数の音声パケットを、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰの少なくとも１つの送信上位プロトコルヘッダを解析し、該解析結果に基づいて共通部分が省略された１つのフレームに、まとめて送信するとともに、
   受信側では、１つのフレームにまとめられた複数の音声パケットを元通りに分割することを特徴とする無線ＬＡＮ電話通信方法。
2. 請求項１に記載の無線ＬＡＮ電話通信方法において、
   前記送信側と受信側にて、通信を行う際に、ＱｏＳを確保しＴＤＭ方式で音声のやり取りを行うことを特徴とする無線ＬＡＮ電話通信方法。
3. 請求項１または２のいずれか１項に記載の無線ＬＡＮ電話通信方法において、
   前記送信側では無線通信のエラーレートが所定の閾値より以下の場合に、前記複数の音声パケットを１つにまとめて送信し、無線通信のエラーレートが所定の閾値を超える場合に、１つのフレームにまとめずに送信することを特徴とする無線ＬＡＮ電話通信方法。
4. 請求項１から３のいずれか１項に記載の無線ＬＡＮ電話通信方法の手順を記載したことを特徴とする無線ＬＡＮ電話通信プログラム。
5. 請求項４に記載の無線ＬＡＮ電話通信プログラムが記録されていることを特徴とする記録媒体。
6. 無線ＬＡＮを利用して音声をパケット化して送受信する無線ＬＡＮ電話システムの子機であって、
   音声の遅延許容時間から、音声のコーデック周期、音声のコーデック遅延×２、コーデック待ち時間、送信待ち時間、および、予め指定されたネットワークの遅延量を差し引いた値である送信待ち許容時間を算出する送信待ち許容時間算出部と、
   送信待ち時間内に入力された音声パケットをひとつのフレームにまとめて送信データを生成するペイロード統合部と、
   音声パケットのＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰの少なくとも１つの上位プロトコルヘッダを解析する上位プロトコル解析部と、
   受信データを元来ひとつの音声パケットであったか否か判断し、複数の音声パケットが統合されている場合に、前記受信データを複数の音声パケットに分解するペイロード分割部とを有し、
   前記上位プロトコル解析部は、音声パケットの上位プロトコルヘッダを解析し、前記ペイロード統合部は、前記上位プロトコル解析部による解析結果に基づいて、共通部分を省略した１つのフレームにまとめることを特徴とする無線ＬＡＮ電話システム子機。
7. 請求項６に記載の無線ＬＡＮ電話システム子機において、
   タイムスロットの管理を行うタイムスロット管理部をさらに有し、親機との無線通信をＴＤＭで行うことを特徴とする無線ＬＡＮ電話システム子機。

Images