(57)【要約】【課題】通信帯域を有効に利用し、かつ、通話品質の高い無線ＬＡＮ電話通信方法及びシステムを提供すること。【解決手段】発生した音声パケットを複製して１つ以上のコピーを保存しておき、送信時に、以前に発生した１つ以上の音声パケットのコピーと最近発生した音声パケットを１つの無線フレームにまとめて送信する手段と、受信した側で、もとのパケットに分割する手段を有する構成とし、無線ＬＡＮにおいてしばしば発生するバーストエラーが発生しても、音声パケットを冗長化して送信することになり、再送信を行う必要が無い。【選択図】図１
2008259094.tif 000002
【特許請求の範囲】
【請求項１】
発生した音声パケットを複製して１つ以上のコピーを保存しておき、送信時に、以前に発生した１つ以上の音声パケットのコピーと最近発生した音声パケットを１つの無線フレームにまとめて送信し、受信した側で、もとのパケットに分割することを特徴とする無線ＬＡＮ電話通信方法。
【請求項２】
音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量とあらかじめ指定されたアルゴリズムによって決定される無線フレームの送信予定時刻から送信待ち許容時間を計算して、その送信待ち時間の許容範囲内で、音声パケットを冗長化して複数の音声パケットをひとつの無線フレームにまとめて送信し、受信側で、元通り複数の冗長化された音声パケットに分解することを特徴とする無線ＬＡＮ電話通信方法。
【請求項３】
遅延許容時間内で、インターリーブを行い、冗長化されたパケットのうち、連続しない２つ以上の音声パケットを１つの無線フレームにまとめて送信することを特徴とする無線ＬＡＮ電話通信方法。
【請求項４】
ネットワークの遅延量を測定するために、あらかじめ指定されたアルゴリズムで繰り返し得られる測定時刻にあらかじめ決められた手順を実施し、ネットワークの遅延量を測定し、送信待ち許容時間を更新することを特徴とする請求項２または３に記載の無線ＬＡＮ電話通信方法。
【請求項５】
受信履歴バッファ内で重複した音声パケットを受信した場合に、これを破棄することを特徴とする請求項１から４のうち何れか１に記載の無線ＬＡＮ電話通信方法。
【請求項６】
上位プロトコルヘッダを解析し、共通部分を省略してフレーム化することを特徴とする請求項１から５のうち何れか１に記載の無線ＬＡＮ電話通信方法。
【請求項７】
無線通信のエラーレートが指定された閾値より高い場合、請求項１から６の通信方法を実施し、そうでない場合は、実施しないことを特徴とする請求項１から６のうち何れか１に記載の無線ＬＡＮ電話通信方法。
【請求項８】
請求項１から７のうち何れか１に記載の無線ＬＡＮ電話の通信方法を実現したことを特徴とする無線ＬＡＮ電話子機。
【請求項９】
請求項１から７のうち何れか１に記載の無線ＬＡＮ電話の通信方法を実現したことを特徴とする無線ＬＡＮ電話親機。
【請求項１０】
請求項１から７のうち何れか１に記載の無線ＬＡＮ電話の通信方法を実現したことを特徴とするプログラム。
【請求項１１】
請求項１から７のうち何れか１に記載の無線ＬＡＮ電話の通信方法を実現したことを特徴とする無線ＬＡＮ電話システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、本発明は無線ＬＡＮを利用した無線ＬＡＮ電話通信方法及びシステムに関するものである。
【背景技術】
【０００２】
近年、ＶｏＩＰ技術を利用したＩＰ電話が普及している。ＩＰ電話では音声をパケット化して、インターネットや専用のネットワークを通して音声を送受信するため、通話コストが安く、また、大手プロバイダがさまざまな地域でサービスを提供しているため、最近では、企業だけでなく、多くの家庭でも利用されるようになった。さらに、最近では、ＩＰ電話機をコードレス化する動きも出てきた。例えば、親機でＩＰ電話のプロトコルを終端し、親機から子機は従来のコードレス電話機の方式で音声を子機とやりとりする製品も発表されている。そして、さらに、ＩＰ電話のプロトコルを親機で終端するのではなく、子機で終端できるようにし、その子機をホットスポットなどのような公共の無線アクセスポイントに持ち出して、安価に通話できるような無線ＬＡＮによるコードレス電話機も提案されている。
【０００３】
従来の無線ＬＡＮ電話について、図面を用いて説明する。
【０００４】
図３８は従来の無線ＬＡＮ電話の通話時における親機から子機への音声パケットの送信の様子を表した図である。従来の無線ＬＡＮ電話では、音声パケットは無線フレームと１対１に対応付けられており、エラーが発生した場合は、ＩＥＥＥ８０２．１１の規格により再送によってエラー回復を行うことが規定されているため、エラー発生時には、無線フレームの再送が行われる（例えば特許文献１参照）。
【特許文献１】特開２００２−２４７６４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら上記の従来の構成では、有線に比べてエラーの発生率の高い無線通信において実際にエラーが発生した場合、再送を行わなければならないため、通信帯域を有効に利用できず、また、再送を行うと音声が遅延し、通話品質が劣化してしまう、という課題があった。
【０００６】
本発明は、通信帯域を有効に利用し、かつ、通話品質の高い無線ＬＡＮ電話通信方法及びシステムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、発生した音声パケットを複製して１つ以上のコピーを保存しておき、送信時に、以前に発生した１つ以上の音声パケットのコピーと最近発生した音声パケットを１つの無線フレームにまとめて送信する手段と、受信した側で、もとのパケットに分割する手段を設けたものである。
【０００８】
この構成によれば、無線ＬＡＮにおいてしばしば発生するバーストエラーが発生しても、音声パケットを冗長化して送信することになるので、再送信を行う必要が無く、音の途切れや遅延が無く、通話品質の高い無線ＬＡＮ電話通信方法及びシステムを提供することができる。
【発明の効果】
【０００９】
本発明によれば、無線ＬＡＮによる通信においてしばしば発生するバーストエラーが発生しても、音声パケットを冗長化して送信することになるので、再送信を行う必要が無く、音の途切れや遅延の無い、高い通話品質を実現できる。
【発明を実施するための最良の形態】
【００１０】
本発明は、発生した音声パケットを複製して１つ以上のコピーを保存しておき、送信時に、以前に発生した１つ以上の音声パケットのコピーと最近発生した音声パケットを１つの無線フレームにまとめて送信する手段と、受信した側で、もとのパケットに分割する手段を設けている。
【００１１】
これにより、無線ＬＡＮにおいてしばしば発生するバーストエラーが発生しても、音声パケットを冗長化して送信することになるので、再送を行う必要が無く、音の途切れや遅延の無い、高い通話品質を提供することができる。
【００１２】
また、音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量とあらかじめ指定されたアルゴリズムによって決定される無線フレームの送信予定時刻、から送信待ち許容時間を計算して、その送信待ち時間の許容範囲内で、音声パケットを冗長化して複数の音声パケットをひとつの無線フレームにまとめて送信し、受信側で、元通り複数の冗長化された音声パケットに分解するように構成されてもよい。
【００１３】
これにより、音声の遅延許容時間内で最大限の冗長化を行うので、エラー率の高い通信環境でも音声の途切れや遅延のない、高い通話品質を提供できる。
【００１４】
また、音声の遅延許容時間内で音声パケットをキューに保管しておき、連続しない２つ以上の音声パケットをあらかじめ決められたアルゴリズムによって選択し、それらを１つの無線フレームにまとめて送信するように構成してもよい。
【００１５】
これにより、音声パケットがインターリーブされるので、バーストエラーに強い通話を提供できる。
【００１６】
また、ネットワークの遅延を測定して、ネットワークの遅延に適応するように構成してもよい。
【００１７】
これにより、ネットワークのトラフィックが変化して遅延量が変化しても送信側で許容できる送信待ち時間を調整できるので、ネットワークの変動にも影響を受けない高品質の通話を提供できる。
【００１８】
また、受信履歴バッファと重複パケット検索部を設けて、受信側で重複して受信した音声パケットを破棄するように構成してもよい。
【００１９】
これにより、不必要な音声パケット（重複した音声パケット）がネットワークに流れることを防ぐので、ネットワークのトラフィックを圧迫しない良好な通信環境を提供できる。
【００２０】
また、複数の音声パケットをひとつの無線フレームにまとめる際に、上位プロトコルヘッダを解析して、上位プロトコルの冗長なヘッダを縮退させるように構成してもよい。
【００２１】
これにより、冗長なデータが圧縮されるので、無線通信帯域を圧迫しない高品質な通信環境を提供できる。
【００２２】
また、通信エラー率をモニターして、エラー率に応じて音声パケットを冗長化して送信するか、どうかを選択するように構成してもよい。
【００２３】
これにより、エラー率が高い場合のみ冗長化を行うので、エラー率の少ない環境では無線通信帯域に余計な負荷をかけない良好な通信環境を提供できる。
【００２４】
以下、本発明の実施の形態について図面を用いて説明する。
【００２５】
（実施の形態１）
まず、無線ＬＡＮ電話装置子機について説明する。
【００２６】
図１は、本発明による実施の形態１における無線ＬＡＮ電話装置子機を示す機能ブロック図である。
【００２７】
図１において、１０１は、発呼先の指定、着呼時に通話の指示および終話の指示をするための操作部、１０２は、音声を入力するための音声入力部、１０３は、音声を出力するための音声出力部、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファ、１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部、１０８は、時間の経過を測定するためのＲＴＣである。
【００２８】
１０９は、音声のコーデック周期を記憶するパラメータ記憶部、１１０は、音声入力部１０２から入力した音声をＡ／Ｄ変換し、所定のアルゴリズムを用いて音声パケットに変換（エンコード）する、また、音声データを所定のアルゴリズムを用いてデコードした上で、Ｄ／Ａ変換し、音声出力部１０３に出力するコーデック部、１１１は、コーデック部１１０がエンコードした音声パケットをエンコードが完了した時刻、すなわち、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキュー、１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部、１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキュー、１１４は、受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。
【００２９】
１１６は、発呼、着呼、呼の接続・切断の制御、および、各呼の状態に応じたダイヤルトーン、ビジートーン、リンガー、リング・バック・トーンを音声出力部１０３に出力する呼制御部、１１７は、呼の設定や解除、通話時の音声パケットの送受信、を指定されたプロトコルに従って処理するプロトコル処理部、１１８は、上位プロトコルを解析する、上位プロトコル解析部、１１９は、無線通信におけるエラー率を算出し、あらかじめ指定されたエラー率よりも低いかどうかを判定する、エラー率判定部、１３０は、全体を制御する制御部である。
【００３０】
図２は、本発明の実施の形態１における無線ＬＡＮ電話装置子機を示す装置ブロック図である。
【００３１】
図２において、２０１は、中央処理装置（以下、ＣＰＵと称する）、２０２は、ＲＯＭ、２０３は、ＲＡＭ、２０４は、ＲＴＣ、２０５は、ベースバンド、２０６は、ＲＦ、２０７は、Ａ／Ｄ、２０８は、マイク、２０９は、Ｄ／Ａ、２１０は、スピーカ、２１１は、キーボード、２１２は、コーデックである。
【００３２】
図１及び図２において、１０１の操作部は、２１１のキーボードによって、１０２の音声入力部は、２０８のマイクによって、１０３の音声出力部は、２１０のスピーカによって、それぞれ実現されている。
【００３３】
１０４の受信バッファ、１０５の送信バッファ、１０９のパラメータ記憶部、１１１の送信パケットキュー、１１３の受信パケットキューは、２０３のＲＡＭによって実現されている。
【００３４】
１０７の無線通信部は、２０５のベースバンドと２０６のＲＦによって実現されている。また、１０８のＲＴＣは、２０４のＲＴＣによって、また、１１０のコーデック部は、２１２のコーデック、２０７のＡ／Ｄ、２０９のＤ／Ａによって、それぞれ実現されている。
【００３５】
１１２のペイロード統合部、１１４のペイロード分割部、１１６の呼制御部、１１７のプロトコル処理部、１１８の上位プロトコル解析部、１１９のエラー率判定部、及び、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって実現されている。
【００３６】
続いて、無線ＬＡＮ電話装置親機について説明する。
【００３７】
図３は、本発明による実施の形態１における無線ＬＡＮ電話装置親機を示す機能ブロック図である。
【００３８】
図３において、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファ、１０６は、有線のネットワークと接続するためのＬＡＮ通信部、１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部、１０８は、時間の経過を測定するためのＲＴＣである。
【００３９】
１１１は、後述する有線−無線ブリッジ部１２０が、中継が必要と判断したＬＡＮ側からのイーサネット（登録商標）フレームを無線フレーム化して送信するために、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキュー、１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部、１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する受信パケットキュー、１１４は、受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込むペイロード分割部、１１８は、上位プロトコルを解析する、上位プロトコル解析部、１１９は、無線通信におけるエラー率を算出し、あらかじめ指定されたエラー率よりも低いかどうかを判定するエラー率判定部、１２０は、有線と無線の間のフレームを必要があれば中継し、さもなければ破棄する有線−無線ブリッジ部、１３０は、全体を制御する制御部である。
【００４０】
図４は、本発明の実施の形態１における無線ＬＡＮ電話装置親機を示す装置ブロック図である。
【００４１】
図４において、２０１は、ＣＰＵ、２０２は、ＲＯＭ、２０３は、ＲＡＭ、２０４は、ＲＴＣ、２０５は、ベースバンド、２０６は、ＲＦ、２１３は、ネットワークＩ／Ｆである。
【００４２】
図３及び図４において、受信バッファ１０４、送信バッファ１０５、送信パケットキュー１１１、受信パケットキュー１１３は、ＲＡＭ２０３によって実現される。
【００４３】
無線通信部１０７は、ベースバンド２０５とＲＦ２０６によって、ＲＴＣ１０８は、ＲＴＣ２０４によって、ＬＡＮ通信部１０６は、ネットワークＩ／Ｆ２１３によって、それぞれ実現される。
【００４４】
ペイロード統合部１１２、ペイロード分割部１１４、上位プロトコル解析部１１８、エラー率判定部１１９、有線−無線ブリッジ部１２０、制御部１３０は、ＣＰＵ２０１がＲＯＭ２０２の中に記憶しているプログラムを、ＲＯＭ２０２の中に記憶しているデータを参照したり、ＲＡＭ２０３に記憶しているデータを参照したり、変更したりしながら実行することによって実現される。
【００４５】
続いて、本発明の無線ＬＡＮ電話システムの全体構成について説明する。
【００４６】
図５は、本発明の実施の形態１における無線ＬＡＮ電話システムを示した図である。
【００４７】
図５に示すように、子機Ａは親機Ａの管理下にあり、同様に、子機Ｂは親機Ｂの管理下にある。親機Ａ、親機Ｂはそれぞれインターネットに接続されている。親機Ａ、親機Ｂにはブリッジの機能が搭載されていて、子機からの無線フレームを、ＬＡＮ通信部（有線）を使用してインターネット側にイーサネット（登録商標）フレームとして中継したり、インターネット側からのイーサネット（登録商標）フレームを子機に無線フレームとして中継したりする。
【００４８】
以上のように構成された無線ＬＡＮ電話システムについて、親機と子機の動作について、図６のシーケンスチャートにしたがって説明する。
【００４９】
以下説明する動作は、近年ＶｏＩＰでしばしば利用されているＳＩＰというプロトコルを参考にしている。ただし、説明を必要以上に複雑にしないため、多少、処理を簡略化して説明している。また、ここでは、親機、子機の連携に重点を置いて説明をすることにする。子機の「エンコード」「デコード」、親機の「ブリッジ処理」、親機・子機の「無線送信」「無線受信」は後に詳細を説明する。なお、本実施の形態では、子機は最初、待ち受け状態にあるものとする。
【００５０】
ステップＥ０１
まず、子機Ａのユーザは、子機Ａの操作部１０１を利用して発呼先を指定する（ステップＥ０１）。ここでは、ユーザが操作部１０１より、発呼先の番号０５０−１００１−１２３４を入力し、発呼を指示したものとする。
【００５１】
ステップＭ０２
制御部１３０は操作部１０１より入力された発呼先番号を受け取り、呼制御部１１６対して、指定された発呼先番号に呼を設定するよう要求する。呼制御部１１６は、「呼の接続要求」を子機Ｂに知らせるため、「ＩＮＶＩＴＥ」メッセージを作成して、プロトコル処理部１１７に子機Ｂまで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を通して親機Ａに「ＩＮＶＩＴＥ」を意味するデータを送信する（詳細は「子機送信処理」として後述）。親機Ａは受け取った無線フレームを有線のイーサネット（登録商標）フレームに変換しインターネットへ送信する（詳細は「親機ブリッジ処理」として後述）。親機Ａから送信されたイーサネット（登録商標）フレームはインターネット（図では省略）を通って、親機Ｂに到着する。親機Ｂでは、受け取ったイーサネット（登録商標）フレームを中継し、無線フレームに変換して、子機Ｂに送信する（詳細は「親機ブリッジ処理」として後述）。子機Ｂでは、親機Ｂが送信した無線フレームを受け取り、無線通信部１０７、プロトコル処理部１１７を経由して呼制御部１１６に「ＩＮＶＩＴＥ」メッセージが通知される（詳細は「子機受信処理」として後述）。これにより子機Ｂは着呼したことになる。
【００５２】
ステップＥ０３
子機Ｂでは、呼制御部１１６がコーデック部１１０にリンガー（着信音）を流すよう要求する。すると、コーデック部１１０は、音声出力部１０３に着信音として記憶している音声を出力する。
【００５３】
ステップＭ０４
子機Ｂでは、呼制御部１１６は「着呼を受け入れた」旨を子機Ａに知らせるため、「ＲＩＮＧＩＮＧ」メッセージを作成し、プロトコル処理部１１７に子機Ａまで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＲＩＮＧＩＮＧ」意味するデータを親機Ｂへ送信する。このデータは親機Ｂによって無線フレームからイーサネット（登録商標）フレームに変換され、インターネットを通り、親機Ａに届く。さらに、親機Ａは受け取ったイーサネット（登録商標）フレームを中継し、無線フレームとして子機Ａに送信する。
【００５４】
ステップＥ０５
子機Ａでは、無線通信部１０７、プロトコル処理部１１７を経由して、呼制御部１１６が「ＲＩＮＧＩＮＧ」メッセージを受け取り、発呼先が着呼を受け入れた旨を知る。呼制御部１１６は、コーデック部１１０にリング・バック・トーン（呼び出し音、以降ＲＢＴと略記する）を出力するよう要求する。すると、コーデック部１１０は、音声出力部１０３にＲＢＴを出力する。
【００５５】
ステップＥ０６
子機Ｂにおいて、ユーザがリンガーを聞いて着信していることに気がつくと、操作部１０１を操作して、通話を指示する。すると、子機Ｂでは、制御部１３０が操作部１０１から「通話を指示された」旨を受け取り、呼制御部１１６に「呼を接続する」よう要求する。
【００５６】
ステップＭ０７
子機Ｂにおいて、呼制御部１１６は、「着呼に対してユーザが応答した」旨を子機Ａに知らせるため、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージ作成し、子機Ａに送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＣＯＮＮＥＣＴ−ＯＫ」を意味するデータを親機Ｂに送信する。すると、親機Ｂでは子機Ｂから受け取った無線フレームをイーサネット（登録商標）フレームに変換して中継し、イーサネット（登録商標）フレームはインターネットを通って親機Ａに届く。親機Ａでは、届いたイーサネット（登録商標）フレームを無線フレームに変換して中継し、子機Ａに送信する。子機Ａでは、無線通信部１０７、プロトコル処理部１１７を経由して、「ＣＯＮＮＥＣＴ−ＯＫ」を呼制御部１１６が受け取り、コーデック部１１０にＲＢＴを停止さるよう要求する。すると、コーデック部はＲＢＴを停止する。
【００５７】
ステップＥ０８
以降、全２重の通信路が確保され、通話が可能となる。ここでは、インターネットの通信帯域は十分広く、遅延も数１０ｍｓ程度であることを仮定している。つまり、子機Ａと子機Ｂの間での通信のボトルネックは子機−親機間であると仮定している。
【００５８】
ステップＭ０９
通話中、子機Ａのユーザの音声は子機Ａの音声入力部１０２に入力され、コーデック部１１０によってエンコードされ、音声パケットとしてプロトコル処理部１１７によって子機Ｂまで送信される。子機Ｂでは、無線通信部１０７、プロトコル処理部１１７を経由してコーデック部１１０が音声パケットを受け取り、これをデコードし、結果を子機Ｂの音声出力部１０３に出力する。子機Ｂ側からのユーザの音声が子機Ａに届く処理は、前述の処理とちょうど対称の処理となるため、説明を省略する。
【００５９】
ステップＥ１０
子機Ｂのユーザは通話を終了するため、呼切断を操作部１０１から指示する。すると、制御部１３０は操作部１０１から呼切断の指示を受け取って、呼制御部１１６に呼切断を要求する。呼制御部１１６はエンコードタスクとデコードタスクを停止する。すると、コーデック部１１０はコーデックを停止する。以降、音声パケットを受け取っても破棄し、音声の入力に対してエンコードも行わない。
【００６０】
ステップＭ１１
子機Ｂにおいて、呼制御部１１６は、「ＢＹＥ」メッセージを作成し、プロトコル処理部１１７に子機Ａまで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＢＹＥ」を意味するデータを親機Ｂに送信する。これまでと同様に、「ＢＹＥ」メッセージは、親機Ｂ、インターネット、親機Ａを経由して子機Ａに到着する。
【００６１】
ステップＥ１２
子機Ａにおいて、呼制御部１１６は、無線通信部１０７、プロトコル処理部１１７を経由して「ＢＹＥ」のメッセージを受け取る。呼制御部１１６はエンコードタスクとデコードタスクを停止する。すると、コーデック部１１０はコーデックを停止する。以降、音声パケットを受け取っても破棄し、音声の入力に対してもエンコードを行わない。
【００６２】
ステップＭ１３
子機Ａにおいて、呼制御部１１６は「ＢＹＥ−ＯＫ」メッセージを作成し、子機Ｂまで送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＢＹＥ−ＯＫ」を意味するデータを親機Ａに送信する。これまでと同様に、「ＢＹＥ−ＯＫ」のメッセージは親機Ａ、インターネット、親機Ｂを経由して子機Ｂに届く。
【００６３】
ステップＥ１４
子機Ｂにおいて、呼制御部１１６は、無線通信部１０７、プロトコル処理部１１７を経由して、「ＢＹＥ−ＯＫ」メッセージを受け取る。以降、子機Ｂは「待ち受けモード」となる。
【００６４】
次に、本実施の形態の子機の動作の概要を説明する。
【００６５】
図７は、本発明の実施の形態１における子機のタスク構成図を示している。
【００６６】
本実施の形態では、音声をエンコードするエンコードタスク、音声をデコードするデコードタスク、呼設定・接続・切断などを行う呼制御タスク、送信パケットキューに記憶された音声パケットを無線フレームとして送信する無線送信タスク、無線フレームを受信して音声パケットにし、受信パケットキューに書き込む無線受信タスクが並行して動作しているものとする。エンコードタスク、デコードタスク、呼制御タスクはプロトコル処理タスクに対して送信要求、受信要求を行う。受信要求を行ったあと、プロトコル処理タスクは要求があったデータを受信すると、その旨を、受信要求を行ったタスクに通知する。なお、図中の矢印はデータの流れを示している。
【００６７】
次に、本実施の形態における親機の動作の概要を説明する。
【００６８】
図８は、本発明の実施の形態１における親機のタスク構成図を示している。
【００６９】
親機では、子機と同様に無線送信タスク、無線受信タスクおよび、「無線受信タスクが受け取った無線フレームを吟味し、有線と無線の間でフレームを中継するかどうかを決定し、必要があれば、フレームの形式を変換した後、ＬＡＮ通信部１０６を介してイーサネット（登録商標）フレームを送信する、また、ＬＡＮ通信部１０６を通して受信したイーサネット（登録商標）フレームを吟味し、有線と無線の間でフレームを中継するかどうかを決定し、必要があれば、フレームの形式を変換した後、無線送信タスクに渡す」ブリッジタスクが並行して動作している。
【００７０】
以降、子機のそれぞれのタスク動作についてフローチャートを使用して説明する。
【００７１】
まず、エンコードタスクの処理について図９のフローチャートに従って説明する。
【００７２】
エンコードタスクは、呼制御タスクによって通話中に起動される。通話が終わると呼制御タスクによって停止させられる。以下の説明は通話中のエンコードタスクの動作である。
【００７３】
ステップＳ０１
コーデック部１１０は音声入力部１０２から音声の受け取り、サンプリング（Ａ／Ｄ変換）およびエンコードを行う。
【００７４】
ステップＳ０２
コーデック部１１０はパラメータ記憶部１０９に記憶されたコーデック間隔を参照し、ＲＴＣ１０８と比較しながらコーデック間隔で指定されている時間だけエンコードが行われたかどうかを判断する。指定された時間が経過していれば、ステップＳ０３へ進む。さもなければ、ステップＳ０１に戻る。
【００７５】
ステップＳ０３
コーデック部１１０はサンプリングしたデータをプロトコル処理部１１７に渡し、送信を要求する。ステップＳ０１に戻る。
【００７６】
次に、デコードタスクの処理について図１０のフローチャートに従って説明する。
【００７７】
デコードタスクは呼制御タスクによって通話中に起動される。通話が終わると呼制御タスクによって停止させられる。以下の説明は通話中のデコードタスクの動作である。
【００７８】
ステップＳ１０１
コーデック部１１０は、プロトコル処理部１１７から受信通知を受け取っているかどうかを確認する。受信通知を受け取っていれば、ステップＳ１０２へ進む。さもなければ、ステップＳ１０１に戻る。
【００７９】
ステップＳ１０２
コーデック部１１０はプロトコル処理部１１７から受信データを受け取る。
【００８０】
ステップＳ１０３
コーデック部１１０は受け取ったデータのＲＴＰヘッダを参照し、前回の受信データのタイムスタンプと一致するかどうかを判断する。一致する場合はステップＳ１０１へ、さもなければ、ステップＳ１０４へ進む。
【００８１】
ステップＳ１０４
コーデック部１１０は受け取ったデータのＲＴＰヘッダに書かれているタイムスタンプを記憶する。
【００８２】
ステップＳ１０５
コーデック部１１０は受け取ったデータをデコードし、結果をＤ／Ａ変換し、その出力を音声出力部１０３に出力する。ステップＳ１０１に戻る。
【００８３】
次に、呼制御タスクの動作について図１１のステートチャートに従って説明する。
【００８４】
まず、子機Ａの電源がＯＮされて、子機Ａのユーザが発呼、通話、切断を行う一連の処理について呼制御タスクの動作を子機Ａの側から説明する。
【００８５】
ステップＥ−１
子機の電源ＯＮが操作部１０１から指示されると、制御部１３０は呼制御タスク、プロトコル処理タスク、無線送信タスク、無線受信タスクを起動する。呼制御タスクは起動されると、待ち受け状態に遷移する。すると、以降、発着呼が可能になる。
【００８６】
ステップＥ−２
子機Ａでユーザが操作部１０１を操作して子機Ｂに発呼を行う。子機Ａの制御部１３０は操作部１０１からの「発呼」の通知を受け、発呼先番号を受け取り、呼制御部１１６に相手先番号を指定して「呼接続」要求する。呼制御部１１６は、「ＩＮＶＩＴＥ」メッセージを子機Ｂまで送信するようプロトコル処理部１１７に要求する。子機Ｂは、「ＩＮＶＩＴＥ」メッセージを受け付けて、着呼中となり、「ＲＩＮＧＩＮＧ」メッセージを子機Ａに送り返してくる。子機Ａの呼制御部１１６はプロトコル処理部１１７経由で子機Ｂからの「ＲＩＮＧＩＮＧ」メッセージを受信し、発呼中状態に遷移する。呼制御部１１６はＲＢＴを音声出力部１０３に出力し、ユーザに「呼び出し中」であることを知らせる。
【００８７】
ステップＥ−３
子機Ｂでは、リンガー（着信音）が鳴っており、ユーザは着信音に気づいて着信を受け入れる。すると、エンコードタスク、デコードタスクが起動された後、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａに送信してくる。子機Ａでは、呼制御部１１６が、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを、プロトコル処理部１１７を経由して受け取る。すると、呼制御部１１６は前述のエンコードタスクとデコードタスクを起動し、コーデック部１１０は、以降の音声入力部１０２からの音声をＡ／Ｄ変換およびエンコードし、音声パケットとしてプロトコル処理部１１７に渡す。また、コーデック部１１０はプロトコル処理部１１７が受け取った音声パケットをデコードおよびＤ／Ａ変換し、音声出力部１０３に出力する。通話中に遷移する。
【００８８】
ステップＥ−９
子機Ａのユーザが通話を終えた場合、子機Ａの操作部１０１を操作して、呼を切断する。制御部１３０は操作部１０１からの切断操作の通知を受け、呼制御部１１６に「呼切断」を要求する。呼制御部１１６はエンコードタスクとデコードタスクを停止させる。すると、呼制御部１１６は「ＢＹＥ」メッセージを子機Ｂへ送るようプロトコル処理部１１７に要求する。プロトコル処理部１１７は無線処理部１０７を経由して「ＢＹＥ」メッセージを意味するデータを親機Ａに送信し、インターネット、親機Ｂ、を経由して子機Ｂに到着する。子機Ｂは「ＢＹＥ」メッセージを受け取ると、「ＢＹＥ−ＯＫ」を子機Ａに返送する。子機Ａでは、無線通信部１０７、プロトコル処理部１１７を経由して、呼制御部１１６が「ＢＹＥ−ＯＫ」メッセージを受け取る。すると、待ち受け状態に遷移する。
【００８９】
ステップＥ−７
また、ユーザが発呼中に発呼を取りやめる場合は、操作部１０１から発呼取りやめの指示を行い、制御部１３０が操作部１０１から発呼取りやめの指示を受け取り、呼制御部１１６に発呼取りやめを要求する。呼制御部１１６はプロトコル処理部１１７に「ＣＡＮＣＥＬ」のメッセージを子機Ｂへ送信するよう要求する。子機Ｂはリンガーを停止、「ＣＡＮＣＥＬ−ＯＫ」メッセージを子機Ａに送信する。子機Ａでは、子機Ｂからの「ＣＡＮＣＥＬ−ＯＫ」をプロトコル処理部１１７が受け取り呼制御部１１６に通知すると、呼制御部１１６は待ち受け状態に遷移する。
【００９０】
次に、子機Ｂ側からみた、呼制御タスクの動作について説明する。
【００９１】
ステップＥ−４
プロトコル処理部１１７は子機Ａから「ＩＮＶＩＴＥ」メッセージを受け取り、呼制御部１１６に通知する。呼制御部１１６はプロトコル処理部１１７に「ＲＩＮＧＩＮＧ」メッセージを子機Ａに返送するよう要求する。呼制御部１１６はリンガーを音声出力部１０３に出力し、ユーザに着信が発生していることを知らせる。呼制御部１１６は着呼中状態に遷移する。
【００９２】
ステップＥ−５
ユーザはリンガーによって着呼していることを知り、操作部１０１を操作して、着信に応答する。制御部１３０は操作部１０１から着信応答を受け取り、呼制御部１１６に応答を要求する。すると、呼制御部１１６は「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａに送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａに送信する。さらに呼制御部１１６は、音声出力部１０３へのリンガーの出力を停止し、エンコードタスクとデコードタスクを起動して、以降の音声入力部１０２からの音声がＡ／Ｄ変換・エンコードされ、音声パケットとして子機Ａへ送信されるようにし、また、子機Ａからの音声パケットがデコード・Ｄ／Ａ変換され、音声出力部１０３から出力されるようにする。
【００９３】
ステップＥ−９
プロトコル処理部１１７は子機Ａから「ＢＹＥ」メッセージを受信し、呼制御部１１６に通知する。呼制御部１１６はエンコードタスクとデコードタスクを停止し、待ち受け状態に遷移する。
【００９４】
また、子機Ａのユーザが発呼中に発呼を取りやめた場合は、次のようになる。
【００９５】
ステップＥ−８
プロトコル処理部１１７は「ＣＡＮＣＥＬ」メッセージを受信し、呼制御部１１６に通知する。呼制御部１１６はリンガーを停止し、子機Ａに「ＣＡＮＣＥＬ−ＯＫ」メッセージを送信するようプロトコル処理部１１７に要求し、待ち受け状態に遷移する。
【００９６】
次に、プロトコル処理タスクの動作について図１２のフローチャートに従って説明する。
【００９７】
ステップＳ１２１
プロトコル処理部１１７は、エンコードタスク、デコードタスク、呼制御タスクから、送信要求があるかどうかを調べる。あれば、ステップＳ１２２へ、なければ、ステップＳ１２３へ進む。
【００９８】
ステップＳ１２２
プロトコル処理部１１７は、送信要求を受け付けて、各プロトコルにしたがってヘッダを付加し、送信パケットキュー１１１に入れる。送信パケットキュー１１１はあて先ごとに用意されている。ここであて先とは、ＩＥＥＥ８０２．１１で規定されている送信先ＭＡＣアドレスである。このとき、この送信要求を受け付けた時刻を、ＲＴＣ１０８を参照して、送信要求と対応付けて書き込む。ステップＳ１２１に進む。
【００９９】
ここでは、音声パケットをエンコードタスクから受け取ったとして、説明する。プロトコル処理部１１７は、音声パケットにＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダ、ＬＬＣヘッダを付加し、あて先のＭＡＣアドレスを決定する（通常、あて先はＩＰアドレスで与えられており、プロトコル処理部１１７はこれをＭＡＣアドレスに変換する。詳細は、通常のＴＣＰ／ＩＰの通信処理と同様なので省略する。）。プロトコル処理部１１７は、ＭＡＣアドレスごとに用意された送信パケットキュー１１１の中から音声パケットのあて先のＭＡＣアドレスを持った送信パケットキューを選択し、音声パケットを送信パケットキュー１１１に入れる。このとき、ＲＴＣ１０８を参照し、送信要求受付時刻として、送信パケットキューに書き込む。ステップＳ１２１へ進む。
【０１００】
ステップＳ１２３
プロトコル処理部１１７は、受信パケットキュー１１３にデータが届いているかどうか確認する。届いていればステップＳ１２４へ、さもなければ、ステップＳ１２１へ進む。
【０１０１】
ステップＳ１２４
プロトコル処理部１１７は受信パケットキュー１１３から受信データを取り出す。
【０１０２】
ステップＳ１２５
データのあて先を確認する。あて先がデコードタスクであれば、デコードタスクへ、呼制御タスクであれば、呼制御タスクへ通知する。ステップＳ１２１へ進む。
【０１０３】
次に、無線送信タスクの動作を図１３のフローチャートに従って説明する。
【０１０４】
なお、本実施の形態では無線送信タスクは、子機、親機ともに同一の処理を行う。送信パケットキュー１１１はあて先のＭＡＣアドレスごとに存在し、無線送信タスクは以下の処理を送信パケットキュー１１１ごとに行う。但し、以下の説明では、ひとつの送信パケットキュー１１１に注目してその動作を説明する。
【０１０５】
ステップＳ１３１
制御部１３０は送信パケットキュー１１１を参照して、キューが空かどうかを判断する。空ならば、ステップＳ１３１へ、さもなければステップＳ１３２へ進む。
【０１０６】
ステップＳ１３２
制御部１３０は無線通信部１０７に送信可能かどうかを問い合わせる。具体的には、無線通信部１０７が、現在通信を行っている周波数の電波が存在するかどうかを判断し、さらに、あらかじめ決められた時間、電波が存在しないことを、ＲＴＣ１０８を参照しながら確認する。前述の時間を経過しても電波が検出されなかった場合は、送信可能と判断し、制御部１３０に送信可能であることを通知する。また、前述の時間内に電波が検出された場合は、送信不可能として制御部１３０に通知する。送信可能であれば、ステップＳ１３３へ、送信不可能であればステップＳ１３１へ進む。
【０１０７】
ステップＳ１３３
制御部１３０は送信パケットキュー１１１の最初のエントリに注目する。
【０１０８】
ステップＳ１３４
制御部１３０は、エラー率判定部１１９にエラー率があらかじめ設定された閾値よりエラー率が低いかどうかを問い合わせる。エラー率判定部１１９は、制御部１３０に判定結果を渡す。受け取った判定結果から、エラー率が低い場合はステップＳ１４３へ、さもなければステップＳ１３５へ進む。
【０１０９】
ここでは、エラー率が高いものとして説明を続ける。
【０１１０】
ステップＳ１３５
制御部１３０は送信パケットキュー１１１を参照して、エントリの数が１より大きいかどうかを判断する。１より大きい場合はステップＳ１３６へ、さもなければ、ステップＳ１３１へ進む。
【０１１１】
ステップＳ１３６
制御部１３０は、送信パケットキュー１１１から注目中のエントリのデータを取り出す。
【０１１２】
ステップＳ１３７
制御部１３０は、ステップＳ１３６で取り出されたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
【０１１３】
ステップＳ１３８
制御部１３０は、次のエントリに注目する。
【０１１４】
ステップＳ１３９
制御部１３０は、注目中のエントリのデータをコピーする。ここでは、送信パケットキュー１１１からエントリを取り出さずに、データのコピーのみを行う。
【０１１５】
ステップＳ１４０
制御部１３０は、ステップＳ１３９でコピーしたデータ、あるいはステップＳ１４３で取り出されたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
【０１１６】
ステップＳ１４１
ここでは無線フレームはＩＥＥＥ８０２．１１ｉで規定された暗号化方式によって暗号化されるものとする。制御部１３０は、無線通信部１０７にＣＣＭＰヘッダとＭＩＣキーを付加するよう指示する。すると、無線通信部１０７は、暗号化アルゴリズムにしたがってＣＣＭＰヘッダとＭＩＣキーを計算し、送信バッファ１０５のＩＥＥＥ８０２．１１ｉで規定されたペイロードの位置に追加する。
【０１１７】
ステップＳ１４２
制御部１３０は、無線通信部１０７に送信バッファ１０５の内容を送信するよう指示する。すると、無線通信部１０７は指示された内容を無線フレームとして空中に放出する。ステップＳ１３１へ進む。
【０１１８】
このようにして、２つの音声パケットパケットはひとつの無線フレームにまとめられる。また、ステップＳ１３４でエラー率が低いと判断された場合は、次のようになる。
【０１１９】
ステップＳ１４３
ステップＳ１３６と同様の処理を行う。ステップＳ１４０へ進むという流れになる。この場合は、従来の無線ＬＡＮと同様、パケットをそのままひとつの無線フレームとして送信する処理となる。
【０１２０】
次に、マージ処理の詳細を図１４のフローチャートに従って説明する。
【０１２１】
ここでは、制御部１３０によって送信すべきデータがペイロード統合部１１２に渡されているものとして説明する。
【０１２２】
ステップＳ１５１
ペイロード統合部１１２は、送信バッファ１０５にデータが書き込まれているかどうかを判断する。書き込まれていればステップＳ１５７へ、さもなければ、ステップＳ１５２へ進む。
【０１２３】
ステップＳ１５２
ペイロード統合部１１２は送信バッファ１０５にＭＡＣヘッダを書き込む。
【０１２４】
ステップＳ１５３
ペイロード統合部１１２は上位プロトコル解析部１１８にエントリの内容を渡す。すると、上位プロトコル解析部１１８は、パケット内の上位プロトコル（ここでは、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰ）のプロトコルヘッダを認識し、各レイヤのヘッダを記憶する。もし、すでに、以前の上位プロトコルのヘッダを記憶していた場合は上書きする。
【０１２５】
ステップＳ１５４
ペイロード統合部１１２は、受け取った音声パケットの合計バイト数を算出する。ここでは、ＬＬＣヘッダ（８バイト）＋ＩＰｖ６ヘッダ（４０バイト）＋ＵＤＰヘッダ（８バイト）＋ＲＴＰヘッダ（１２バイト）＋音声（８０バイト）＝１４８バイトとなる。
【０１２６】
ステップＳ１５５
ペイロード統合部１１２はステップＳ１５４で得られた合計バイト数をペイロードデリミタ１として送信バッファ１０５に書き込む。ここでは１４８を書き込む。
【０１２７】
ステップＳ１５６
ペイロード統合部１１２は音声パケットとして受け取ったデータを送信バッファ１０５に書き込む。マージ処理を終了する。
【０１２８】
ステップＳ１５７
ペイロード統合部１１２は上位プロトコル解析部１１８にエントリの内容を渡す。すると、上位プロトコル解析部１１８は、パケット内の上位プロトコル（ここでは、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰ）のプロトコルヘッダを認識し、ステップＳ１５３で記憶していた内容と比較する。上位プロトコル解析部１１８はヘッダを解析した結果をペイロード統合部１１２に渡す。ここでは、ＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダが冗長であることをペイロード統合部１１２に知らせる。
【０１２９】
ステップＳ１５８
ペイロード統合部１１２は、冗長なヘッダを省略すると送信すべきデータの合計バイト数がいくらになるかを計算する。ここでは、冗長なヘッダがどれかを示すフラグ１バイトと省略できないＲＴＰヘッダ１２バイトと音声データ８０バイトの合計９３を算出する。
【０１３０】
ステップＳ１５９
ペイロード統合部１１２は、ステップＳ１５８で算出した値をペイロードデリミタとして送信バッファ１０５に書き込む。ここでは９３が書き込まれる。
【０１３１】
ステップＳ１６０
次に、ペイロード統合部１１２は冗長なヘッダがどれかを示すフラグ１バイトを送信バッファ１０５に書き込む。ここではフラグは、ＯＳＩのレイヤモデルにしたがって、第２層、第３層、第４層、第５〜７層をおのおの２ビットで表現しており、００は「もともと対応するヘッダがなかった」、０１は「ヘッダがあったが冗長なので省略した」、１０「省略できなかった」を表すものとする。ここでは、ＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダは省略可能で、ＲＴＰヘッダは省略できないため、フラグの値は０１０１０１１０となる。
【０１３２】
ステップＳ１６１
ペイロード統合部１１２は、省略できなかったヘッダと音声データを送信バッファ１０５に書き込む。マージ処理を終了する。
【０１３３】
ここでは、続いてＲＴＰヘッダ１２バイトと音声データ８０バイトを送信バッファ１０５に書き込む。
【０１３４】
図１５は本実施の形態との比較として、ＩＥＥＥ  ８０２．１１の無線フレーム・フォーマットを使って音声パケットをひとつだけ送信した場合を示している。また、図１６は本実施の形態によって２つの音声パケットがひとつの無線フレームにまとめられたときの無線フレームのフォーマットを示している。
【０１３５】
まず、無線通信部１０７に内蔵された暗号化エンジンによってＣＣＭＰヘッダが書き込まれ、ＭＩＣキーが付加された後、ＰＬＣＰプリアンブル、ＰＬＣＰヘッダおよびＦＣＳを無線通信部１０７が無線フレームを生成するときに付加する。図１５、図１６の比較より、本来２つの音声パケットを２つの無線フレームで送信せずに、１つの無線フレームにまとめると、フレーム長は２５％大きくなるだけなので、伝送効率が大幅に下げることなく、冗長な音声パケットを送信することができることがわかる。これにより、途中の無線フレームの１つがエラーによって喪失しても、前後の無線フレームには喪失した音声パケットが含まれているので、音声を遅延させる再送を行わずに、音声パケットを受信側で復元することができる。
【０１３６】
次に、無線受信タスクの動作を図１７のフローチャートに従って説明する。
【０１３７】
ここで、自局宛の無線フレームは無線通信部１０７によって受信され、暗号が解除された状態で受信バッファ１０４にフレームの内容がデータとして書き込まれているものとする。すなわち、ＣＣＭＰヘッダとＭＩＣキーは取り除かれているものとする。また、ここでは、自局宛の無線フレーム以外は無線通信部によって無視されているものとする。すなわち、受信バッファに書き込まれるデータは自局宛のものに限るものとする。
【０１３８】
ステップＳ１７１
ペイロード分割部１１４は受信バッファ１０４を参照してデータを受信しているかどうかを判断する。受信していればステップＳ１７２へ、さもなければ、ステップＳ１７１へ進む。
【０１３９】
ステップＳ１７２
ペイロード分割部１１４は受信バッファ１０４からデータをとりだす。
【０１４０】
ステップＳ１７３
ペイロード分割部１１４は、ＭＡＣヘッダを取り出す。
【０１４１】
ステップＳ１７４
ペイロード分割部１１４は最初のペイロードに注目する。
【０１４２】
ステップＳ１７５
ペイロード分割部１１４は次の１バイトをデリミタと解釈し、値を読み出し、ペイロードが何バイトかを得て、そのバイト数分だけペイロードとして切り出す。
【０１４３】
ステップＳ１７６
ペイロード分割部１１４は、ステップＳ１７５で得たペイロードを上位プロトコル解析部１１８に渡す。すると、上位プロトコル解析部１１８は、第２層、第３層、第４層、第５〜７層でのヘッダを解釈し、ペイロード分割部１１４に通知する。ここではＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダと解釈できたとする。上位プロトコル解析部１１８はそれぞれのレイヤごとにヘッダを記憶する。
【０１４４】
ステップＳ１７７
ペイロード分割部１１４は、得られたペイロードを受信パケットキュー１１３に入れる。
【０１４５】
ステップＳ１７８
ペイロード分割部１１４は、受信バッファ１０４を参照して、すべてのペイロードを切り出したかどうか判断する。すべてのペイロードの切り出しが終わっていれば、ステップＳ１７１へ、さもなければ、ステップＳ１７９へ進む。
【０１４６】
ステップＳ１７９
ペイロード分割部１１４は、受信バッファ１０４を参照して、次のペイロードに注目する。
【０１４７】
ステップＳ１８０
ペイロード分割部１１４は、受信バッファ１０４中の次の１バイトをデリミタと解釈し、値を読み出し、注目中のペイロードが何バイトかを得て、そのバイト数分だけペイロードとして切り出す。
【０１４８】
ステップＳ１８１
ペイロード分割部１１４は、次の１バイトを省略フラグと解釈し、どのレイヤのヘッダが省略されているかを判断する。さらに、省略されているヘッダに対しては、ステップＳ１７６で記憶しているヘッダの内容からヘッダを復元するよう上位プロトコル解析部１１８に指示する。すると、上位プロトコル解析部１１８は、ペイロードとステップＳ１７６で記憶した内容を比較し、各レイヤのヘッダを復元する。ここでは、ＩＰヘッダとＵＤＰヘッダにはチェックサムが含まれるため、ペイロードの内容からチェックサムを計算し、ヘッダとして復元する。以上で、ヘッダが省略される前の音声パケット全体が復元されたことになる。ステップＳ１７７へ進む。
【０１４９】
ここでは、フラグの値が０１０１０１１０であったとすると、フラグは、ＯＳＩのレイヤモデルにしたがって、第２層、第３層、第４層、第５〜７層をおのおの２ビットで表現しており、００は「もともと対応するヘッダがなかった」、０１は「ヘッダがあったが冗長なので省略した」、１０「省略できなかった」を表すので、それぞれ、ＬＬＣヘッダは省略、ＩＰヘッダ省略、ＵＤＰヘッダ省略、ＲＴＰヘッダ省略なし、と解釈できる。したがって、今注目しているフラグから後ろはＲＴＰヘッダとして解釈し、省略されているヘッダに関してはステップＳ１７６で記憶した内容に基づき復元する。さらに、ＩＰヘッダとＵＤＰヘッダに関してチェックサムを再計算し、ヘッダを復元する。
【０１５０】
以上の処理によって、もともと２つの音声パケットがひとつの無線フレームにまとめられていても、正しくもとの音声パケットに分割され、プロトコル処理部１１７に渡される。
【０１５１】
ここで、正常に通信が行われた場合、同じ音声パケットを２つ受信することになるが、ＲＴＰプロトコルでは、前述のデコードタスクの説明で示したとおり、デコードタスクが、ＲＴＰヘッダ内のタイムスタンプをチェックしながら、不要なパケットを破棄し、必要なパケットのみデコード処理し、音声として再生するので問題は無い。
【０１５２】
次に、親機のタスクについて説明する。但し、無線受信タスクと無線送信タスクは子機と同一なので説明を省略する。
【０１５３】
ブリッジタスクの処理について図１８のフローチャートに従って説明する。
【０１５４】
ステップＳ１９１
有線−無線ブリッジ部１２０は、受信パケットキュー１１３にエントリがあるかどうかを判断する。エントリがあればステップＳ１９２へ、さもなければ、ステップＳ１９５へ進む。
【０１５５】
ステップＳ１９２
有線−無線ブリッジ部１２０は、受信パケットキュー１１３からエントリを取り出す。
【０１５６】
ステップＳ１９３
有線−無線ブリッジ部１２０は、ステップＳ１９２で取り出したエントリの内容を参照して、ＬＡＮ側（有線）に中継する必要があるかどうかを判断する。この判断においてはＯＳＩ第２層のあて先を利用する。本実施例では、第２層はＩＥＥＥ８０２．１１で規定されているＭＡＣアドレスによって判断する。この判断のためのアドレスの学習方法などは、本発明の主旨と関係ないので割愛する。中継が必要な場合はステップＳ１９４へ、さもなければ、ステップＳ１９１へ進む。
【０１５７】
ステップＳ１９４
有線−無線ブリッジ部１２０は、ＩＥＥＥ８０２．１１のＭＡＣヘッダ形式をＩＥＥＥ８０２．３のＭＡＣヘッダの形式に変換し、ＬＡＮ通信部１０６よりエントリの内容を送信する。ステップＳ１９１へ進む。
【０１５８】
ステップＳ１９５
有線−無線ブリッジ部１２０はＬＡＮ通信部１０６に有線ＬＡＮからデータを受信しているかどうかを問い合わせる。受信していれば、ステップＳ１９６へ、さもなければ、ステップＳ１９１へ進む。
【０１５９】
ステップＳ１９６
有線−無線ブリッジ部１２０はＬＡＮ通信部１０６から受信データを受け取る。
【０１６０】
ステップＳ１９７
有線−無線ブリッジ部１２０は、ステップＳ１９６で取り出した受信データを無線ＬＡＮ側に中継する必要があるかどうかを判断する。中継するかどうかの判断の方法は従来のブリッジ処理と同様なので割愛する。中継する必要がある場合は、ステップＳ１９８へ、さもなければ、ステップＳ１９１へ進む。
【０１６１】
ステップＳ１９８
有線−無線ブリッジ部１２０は、ステップＳ１９６で取り出した受信データをＩＥＥＥ８０２．３のＭＡＣヘッダの形式からＩＥＥＥ８０２．１１のＭＡＣヘッダの形式に変換し、送信パケットキュー１１１に入れる。ステップＳ１９１へ進む。
【０１６２】
図１９は、本実施の形態において音声パケットがどのように送信されるかを示している。
【０１６３】
図１９では、無線フレームＡに音声パケット１と音声パケット２が、無線フレームＢに音声パケット２と音声パケット３が、無線フレームＣに音声パケット３と音声パケット４が、それぞれひとつにまとめられて送信されている。
【０１６４】
図２０では、無線フレームＢが通信エラーとなり喪失した場合を示している。受信側は、無線フレームＡと無線フレームＣによって、音声パケット１、音声パケット２、音声パケット３、音声パケット４を受信することができる。したがって、無線フレームＢを再送する必要は無い。
【０１６５】
以上のように、従来、エラーの発生によって、再送を余儀なくされ、その分、以降の音声の到着時刻が遅延して、さらに、この遅延が蓄積することによって、受信端末側がジッターバッファのオーバーフローを起こし、音声の途切れなどの品質低下が引き起こされていたが、本実施例１によれば、上記の構成により、音声パケットを冗長化して送信するので、エラーが発生しても、再送することなしに、もとの音声を復元することができる。
【０１６６】
また、音声パケットをまとめてひとつの無線フレームとして送信するので、帯域を必要以上に圧迫しない。さらに、音声パケットを解析して、不要なヘッダを省略してひとつの無線フレームにまとめるため、１フレームあたりのデータ量を削減できる。このことにより、無線ＬＡＮ電話の利用者に対しては、品質のよい通話環境を提供し、また、同じ無線ＬＡＮ内でデータ通信を行っているユーザに対して、必要以上に帯域を圧迫せず、良好な通信環境を提供できる。
【０１６７】
なお、本実施の形態では、エラーが発生した場合に再送を行わないことを前提にしているが、再送回数を従来よりも少なくしても、本発明の主旨になんら変わりなく、十分な効果が得られる。
【０１６８】
（実施の形態２）
図２１は、本発明の実施の形態２における子機の機能ブロック図である。
【０１６９】
図２１において、１０１は、発呼先の指定、着呼時に通話の指示および終話の指示をするための操作部、１０２は、音声を入力するための音声入力部、１０３は、音声を出力するための音声出力部、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファである。
【０１７０】
１０７は、前記送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を前記受信バッファ１０４に格納する無線通信部、１０８は、時間の経過を測定するためのＲＴＣ、１０９は、音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量を記憶するパラメータ記憶部である。
【０１７１】
１１０は、前記音声入力部１０２から入力した音声をＡ／Ｄ変換し、所定のアルゴリズムを用いて音声パケットに変換（エンコード）する、また、音声データを所定のアルゴリズムを用いてデコードした上で、Ｄ／Ａ変換し、前記音声出力部１０３に出力するコーデック部、１１１は、前記コーデック部１１０がエンコードした音声パケットをエンコードが完了した時刻、すなわち、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキュー、１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部である。
【０１７２】
１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキュー、１１４は、前記受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、前記受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。
【０１７３】
１１５は、前記パラメータ記憶部１０９に記憶された音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量を参照し、ＲＴＣ１０８の値を送信要求受付時刻と比較し、送信待ちの許容時間を算出する、送信待ち許容時間算出部である。
【０１７４】
１１６は、発呼、着呼、呼の接続・切断の制御、および、各呼の状態に応じたダイヤルトーン、ビジートーン、リンガー、リング・バック・トーンを前記音声出力部１０３に出力する呼制御部、１１７は、呼の設定や解除、通話時の音声パケットの送受信、を指定されたプロトコルに従って処理するプロトコル処理部、１２１は、ネットワークの遅延を測定する、ネットワーク遅延測定部、１３０は、全体を制御する制御部である。
【０１７５】
上記図２１の構成と図２の構成との対応関係について説明する。
【０１７６】
１０１の操作部は、２１１のキーボードによって、１０２の音声入力部は、２０８のマイクによって、１０３の音声出力部は、２１０のスピーカによって実現される。
【０１７７】
１０４の受信バッファ、１０５の送信バッファ、１０９のパラメータ記憶部、１１１の送信パケットキュー、１１３の受信パケットキューは、２０３のＲＡＭによって、実現される。
【０１７８】
１０７の無線通信部は、２０５のベースバンドと２０６のＲＦによって、１０８のＲＴＣは、２０４のＲＴＣによって、１１０のコーデック部は、２１２のコーデック、２０７のＡ／Ｄ、２０９のＤ／Ａによって、それぞれ実現される。
【０１７９】
１１２のペイロード統合部、１１４のペイロード分割部、１１５の送信待ち許容時間算出部、１２１のネットワーク遅延測定部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって実現される。
【０１８０】
図２２は、本発明の実施の形態２における親機の機能ブロック図である。
【０１８１】
図２２において、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファ、１０６は、有線のネットワークと接続するためのＬＡＮ通信部、１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部である。
【０１８２】
１０８は、時間の経過を測定するためのＲＴＣ、１１１は、後述する有線−無線ブリッジ部１２０が、中継が必要と判断したＬＡＮ側からのイーサネット（登録商標）フレームを無線フレーム化して送信するために、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキュー、１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部である。
【０１８３】
１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキュー、１１４は、受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。
【０１８４】
１２０は、有線と無線の間のフレームを必要があれば中継し、さもなければ破棄する、有線−無線ブリッジ部、１３０は、全体を制御する、制御部である。
【０１８５】
上記図２２の構成と図４の構成との対応関係について説明する。
【０１８６】
１０４の受信バッファ、１０５の送信バッファ、１１１の送信パケットキュー、１１３の受信パケットキューは、２０３のＲＡＭによって、実現される。
【０１８７】
１０７の無線通信部は、２０５のベースバンドと２０６のＲＦによって、１０８のＲＴＣは、２０４のＲＴＣによって、１０６のＬＡＮ通信部は、２１３のネットワークＩ／Ｆによって、それぞれ実現される。
【０１８８】
１１２のペイロード統合部、１１４のペイロード分割部、１２０の有線−無線ブリッジ部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって、実現される。
【０１８９】
無線ＬＡＮ電話システム全体の構成および親機と子機の動作概要は実施の形態１と変わらないので説明を省略する。
【０１９０】
まず、子機の動作について説明する。
【０１９１】
図２３は、子機のタスク構成を示している。図７と比較して、測定タスクがあらたに追加されている。一方、親機については、タスク構成は実施の形態例１（図８）と同様である。
【０１９２】
次に、子機のタスクについてその動作を説明する。なお、子機のタスクのうち、エンコードタスク、デコードタスク、呼制御タスクは実施の形態１と同一なので説明を省略する。
ここでは、実施の形態１との相違点となる測定タスクについて、図２４のフローチャートに従って、説明する。
【０１９３】
本実施の形態では、通話を行う子機同士があらかじめ別の方法でお互いのＲＴＣ１０８をあわせていることを前提にしている。お互いの時計を合わせる方法としてはＧＰＳを用いる方法や、ＮＴＰと呼ばれるプロトコルを用いる方法が一般的であるが、ここでは詳細を記述しない。
【０１９４】
ステップＳ２１１
ネットワーク遅延測定部１２１は受信パケットキュー１１３を参照して、測定パケットが届いているかどうかを判断する。届いていればステップＳ２１２へ、さもなければ、Ｓ２１４へ進む。
【０１９５】
ステップＳ２１２
ネットワーク遅延測定部１２１は、受信パケットキュー１１３から、パケットを取り出す。
【０１９６】
ステップＳ２１３
ネットワーク遅延測定部１２１は、取り出したパケットの中身を参照して、そのパケットがいつ送信されたかを読み取り、ＲＴＣ１０８を参照して、現在の時刻と比較する。その結果をネットワークの遅延量としてパラメータ記憶部１０９に書き込む。ステップＳ２１１へ進む。ここでは、パケットに書かれた時刻が１２：３３  １２．６５４  ２２３だったとする。現在、ＲＴＣ１０８が１２：３３  １２．７３４  ２２３を示しているとすると時間差は８０ｍｓとなり、これをパラメータ記憶部１０９にネットワーク遅延量として書き込む。ステップＳ２１１へ進む。
【０１９７】
ステップＳ２１４
ネットワーク遅延測定部１２１は、ＲＴＣ１０８を参照して送信予定時刻になったかどうかを判断する。予定時刻になっていれば、次の送信予定時刻を設定して、ステップＳ２１５へ、さもなければ、ステップＳ２１１へ進む。ここでは、測定パケットの送信は５秒に一度とする。したがって、現在のＲＴＣ１０８の値が１２：３３  １７．２５５  １０９であるとすれば、送信予定時刻は、５秒後の１２：３３  ２２．２５５  １０９となる。
【０１９８】
ステップＳ２１５
ネットワーク遅延測定部１２１は、ＲＴＣ１０８を参照して、現在の時刻１２：３３  １７．２５５  １０９を読み取り、これをパケットの内容として送信パケットキュー１１１に入れる。ステップＳ２１１へ進む。
【０１９９】
このように、子機がお互いに、測定パケットを交換することによって、ネットワークの遅延量を測定し、これを基に無線送信タスクで「いくつの音声パケットをひとつの無線フレームにまとめるか」を決定する（詳細は後述）。これにより、ネットワークのトラフィックに変動が起こってネットワーク遅延量が変化しても、音声の遅延許容時間の範囲内で音声パケットを冗長化することができるので、安定した通話を確保できる。
【０２００】
図２５は、本発明の実施の形態２における子機の無線送信タスクのフローチャートである。送信パケットキュー１１１はあて先のＭＡＣアドレスごとに存在し、無線送信タスクは以下の処理を送信パケットキュー１１１ごとに行う。但し、以下の説明では、ひとつの送信パケットキュー１１１に注目してその動作を説明する。
【０２０１】
ステップＳ２２１〜Ｓ２２３
実施の形態１における図１３のステップＳ１３１〜Ｓ１３３と同一の処理を行う。
【０２０２】
ステップＳ２２４
制御部１３０は、注目中のエントリに関して、送信待ち許容時間算出部１１５に、送信待ち許容時間を算出するよう要求する。すると、送信待ち許容時間算出部１１５はパラメータ記憶部１０９とＲＴＣ１０８とエントリと対応付けて記録された送信要求受付時刻とを参照し、遅延許容時間を算出する。まず、ＲＴＣ１０８と注目中のエントリの送信要求受付時刻から送信待ち時間（送信要求を受け付けてからどれくらい時間が経過しているか）を求める。ここでは以下の値であるとする。
【０２０３】
ＲＴＣ＝１２：３３  ２２．０４３  ９９４
送信要求受付時刻＝１２：３３  ２２．００８  ８７６
ゆえに、送信待ち時間＝ＲＴＣ−送信要求受付時刻＝３５ｍｓとなる。
さらに、以下の値、
コーデック周期＝１０ｍｓ
コーデック遅延＝１ｍｓ
ネットワーク遅延＝８０ｍｓ
コーデック待ち時間＝１０ｍｓ
全体遅延許容時間＝１２０ｍｓ
がパラメータ記憶部１０９にあらかじめ、記憶されているものとする。なお、コーデック遅延とは、音声が入力されてからＡ／Ｄ変換されて、指定されたアルゴリズムによって（ここではμ則ＰＣＭ  ８ｋＨｚ  ８ビットサンプリングが指定されているものとする）エンコードされたデータが出てくるまでの時間であり、このデータをコーデック周期に相当する分だけ集めてはじめて音声フレームとすることができる。また、音声フレームをデコードしてＤ／Ａ変換して、音声として出力されるまでの遅延時間も同じ値としている。コーデックのアルゴリズムによってはこの遅延時間は非対称となることもあるが、ここでは対称であるとして説明を続ける。さらに、コーデック待ち時間とは受信側でジッターバッファを設けて、デコード待ちの音声パケットを一時的に貯めておき、パケットの到着が変動しても、音声が途切れないようにするための、時間である。ネットワーク遅延は、前述の測定タスクによって定期的に更新されているものとする。以上の値と次式によって送信待ち許容時間を計算する。
【０２０４】
送信待ち許容時間＝全体遅延許容時間−コーデック周期−コーデック遅延×２
−ネットワーク遅延−コーデック待ち時間−送信待ち時間
図２６は上式を分かりやすく図示したものである。
【０２０５】
上式より注目しているエントリの送信待ち許容時間は−１７ｍｓとなる。ここで値が負であるということは、今から送信しても許容時間内に音声が到着しないことを示している。
【０２０６】
送信待ち許容時間算出部１１５は制御部１３０に「送信待ち許容時間が−１７ｍｓである」ことを通知する。
【０２０７】
ステップＳ２２５
制御部１３０が送信待ち許容時間算出部１１５から受け取った送信待ち許容時間が負の値を示している場合、つまり、今から送信しても間に合わない場合は、ステップＳ２２６へ、さもなければステップＳ２２９へ進む。ここでは、負の値を示しているのでステップＳ２２６へ進む。
【０２０８】
ステップＳ２２６
制御部１３０は、送信パケットキュー１１１から注目中のエントリのデータを取り出す。
【０２０９】
上の例では、注目中のエントリは今から送信しても間に合わない、と判断されて、破棄されることになる。
【０２１０】
ステップＳ２２７
制御部１３０は、送信パケットキュー１１１を参照して、注目中のエントリの次にエントリが存在するかどうかを判断する。存在すればステップＳ２２７へ、さもなければ、ステップＳ２２１へ進む。ここでは、図２７に示すように、エントリが存在するものとして説明を続ける。
【０２１１】
ステップＳ２２８
制御部１３０は、次のエントリに注目する。ステップＳ２２４へ進む。
【０２１２】
以上のように、ステップＳ２２４〜Ｓ２２８の処理を繰り返すことで、送信しても許容時間内に相手に到着しない音声パケットを破棄する。ここまでの例では、図２７におけるエントリ１と２が破棄される。
【０２１３】
次に、ステップＳ２２５で、今から送信したら許容時間内に相手に到着すると判断された場合について説明する。エントリ３では、許容時間内に到着すると判断されるためステップＳ２２９へ進む。
【０２１４】
ステップＳ２２９
制御部１３０は、注目中のエントリの内容をコピーする。ここでは、エントリ３の内容が一時的に制御部１３０によって記憶される。
【０２１５】
ステップＳ２３０
制御部１３０は、ステップＳ２２９でコピーしたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
【０２１６】
ステップＳ２３１
制御部１３０は、送信パケットキュー１１１を参照して、注目中のエントリの次にエントリが存在するかどうかを判断する。存在すればステップＳ２３２へ、さもなければ、ステップＳ２３３へ進む。
【０２１７】
ステップＳ２２９〜Ｓ２３２を繰り返すことで、エントリがなくなるまで送信パケットキューのエントリの内容がマージされていく。
【０２１８】
ステップＳ２３２
制御部１３０は、次のエントリに注目する。ステップＳ２２９へ進む。
【０２１９】
ステップＳ２３３
エントリ５までのデータがマージされた後、パケット送信キュー１１には、もうマージすべきエントリが無いので、ステップＳ２３３が実行される。
【０２２０】
ここでは無線フレームはＩＥＥＥ８０２．１１ｉで規定された暗号化方式によって暗号化されるものとする。制御部１３０は、無線通信部１０７にＣＣＭＰヘッダとＭＩＣキーを付加するよう指示する。すると、無線通信部１０７は、暗号化アルゴリズムにしたがってＣＣＭＰヘッダとＭＩＣキーを計算し、送信バッファ１０５のＩＥＥＥ８０２．１１ｉで規定されたペイロードの位置に追加する。
【０２２１】
ステップＳ２３４
制御部１３０は、無線通信部１０７に送信バッファ１０５の内容を送信するよう指示する。すると、無線通信部１０７は指示された内容を無線フレームとして空中に放出する。ステップＳ２２１へ進む。
【０２２２】
ここで、ＩＥＥＥ  ８０２．１１で規定されているプリアンブルやＦＣＳは無線通信部１０７で付加されるものとする。
【０２２３】
次に、データのマージ処理について図２８のフローチャートに従って説明する。実施例１と比較すると、本実施例では、上位プロトコル解析処理を行わないで、単純にペイロードをひとつの無線フレームにまとめている。
【０２２４】
ステップＳ２４１
ペイロード統合部１１２は、送信バッファ１０５にデータが書き込まれているかどうかを判断する。書き込まれていればステップＳ２４４へ、さもなければ、ステップＳ２４２へ進む。
【０２２５】
ステップＳ２４２
ペイロード統合部１１２は送信バッファ１０５にＭＡＣヘッダを書き込む。ステップＳ２４４へ進む。
【０２２６】
ステップＳ２４３
ペイロード統合部１１２は、受け取った音声パケットの合計バイト数を算出する。ここでは、ＬＬＣヘッダ（８バイト）＋ＩＰｖ６ヘッダ（４０バイト）＋ＵＤＰヘッダ（８バイト）＋ＲＴＰヘッダ（１２バイト）＋音声（８０バイト）＝１４８バイトとなる。
【０２２７】
ステップＳ２４４
ペイロード統合部１１２はステップＳ２４３で得られた合計バイト数をペイロードデリミタとして送信バッファ１０５に書き込む。ここでは１４８を書き込む。
【０２２８】
ステップＳ２４５
ペイロード統合部１１２は音声パケットとして受け取ったデータを送信バッファ１０５に書き込む。マージ処理を終了する。
【０２２９】
以上のようにして、書き込まれた送信バッファ１０５の様子を図２９に示す。これまでの例では図２７におけるエントリ３〜５がペイロード１〜３として書き込まれている。
【０２３０】
次に、無線受信タスクの動作について図３０のフローチャートに従って説明する。
【０２３１】
なお、本実施の形態では無線受信タスクは、子機、親機ともに同一の処理を行う。ここで、自局宛の無線フレームは無線通信部１０７によって受信され、受信バッファ１０４にフレームの内容をデータとして書き込んでいるものとする。
【０２３２】
ステップＳ２５１〜Ｓ２５４
実施の形態１における図１７のステップＳ１７１〜Ｓ１７４と同一である。
【０２３３】
ステップＳ２５５
ペイロード分割部１１４は先頭の１バイトをデリミタと解釈し、値を読み出し、ペイロードが何バイトかを得て、以降のペイロードを取り出す。ステップＳ２５７へ進む。
【０２３４】
ステップＳ２５６〜Ｓ２５９
実施の形態１における図１７のステップＳ１７７〜Ｓ１８０と同一である。
【０２３５】
以上の処理によって、もともと複数の音声パケットがひとつの無線フレームにまとめられていても、正しくもとの音声パケットに分割され、プロトコル処理部１１７に渡される。デコードタスクは、規定された遅延時間内にデコード処理を完了し、音声として再生する。
【０２３６】
次に、親機についてであるが、親機のタスク構成は実施の形態１と同様であり、ブリッジタスクは、実施の形態１と同様である。無線受信タスクについては実施の形態２の子機と同様であるため、説明を省略し、ここでは親機の無線送信タスクのみを説明する。
【０２３７】
本実施の形態における親機の無線送信タスクについて図３１のフローチャートに従って説明する。
【０２３８】
ステップＳ２６１〜Ｓ２６２
子機における図２５のステップＳ２２１〜Ｓ２２２と同一の処理を行う。
【０２３９】
ステップＳ２６３
子機における図２５のステップＳ２２３と同一の処理を行う。ステップＳ２６４へ進む。
【０２４０】
ステップＳ２６４
子機における図２５のステップＳ２２６と同一の処理を行う。ステップＳ２６５へ進む。
【０２４１】
ステップＳ２６５〜Ｓ２６９
子機における図２５のステップＳ２３０〜Ｓ２３３と同一の処理を行う。
【０２４２】
ステップＳ２６９
子機における図２５のステップＳ２３４と同一の処理を行う。ステップＳ２６１へ進む。
【０２４３】
これまで説明してきたように、本実施の形態で示した子機と親機を組み合わせて利用すれば、通話中の音声の遅延を実用的な範囲内に抑えたまま、エラーが発生しても音が途切れない通話品質の高い通話品質を提供できる。
【０２４４】
以上のように、従来、エラーの発生によって、再送が起き、その分、以降の音声の到着時刻が遅延して、さらに、この遅延が蓄積することによって、受信端末側がジッターバッファのオーバーフローを起こし、音声の途切れなどの品質低下が引き起こされていたが、本実施の形態によれば、上記の構成により、音声パケットを冗長化して送信するので、エラーが発生してももとの音声を復元することができる。
【０２４５】
また、音声パケットをまとめてひとつの無線フレームとして送信するので、帯域を必要以上に圧迫しない。さらに、ネットワークのトラフィックが変動しても、ネットワークの遅延時間を測定し、これに送信のタイミングと１フレーム当りのパケットの重畳量を適応させることができる。このことにより、無線ＬＡＮ電話の利用者に対しては、品質のよい通話環境を提供し、また、同じ無線ＬＡＮ内でデータ通信を行っているユーザに対して、必要以上に帯域を圧迫せず、良好な通信環境を提供できる。
【０２４６】
（実施の形態３）
図３２は、本発明の実施の形態３における子機の機能ブロック図である。
【０２４７】
図３２において、１０１は、発呼先の指定、着呼時に通話の指示および終話の指示をするための操作部、１０２は、音声を入力するための音声入力部、１０３は、音声を出力するための音声出力部、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファである。
【０２４８】
１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部、１０８は、時間の経過を測定するためのＲＴＣ、１０９は、音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量を記憶するパラメータ記憶部である。
【０２４９】
１１０は、音声入力部１０２から入力した音声をＡ／Ｄ変換し、所定のアルゴリズムを用いて音声パケットに変換（エンコード）する、また、音声データを所定のアルゴリズムを用いてデコードした上で、Ｄ／Ａ変換し、前記音声出力部１０３に出力するコーデック部、１１１は、前記コーデック部１１０がエンコードした音声パケットをエンコードが完了した時刻、すなわち、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキューである。
【０２５０】
１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部、１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキューである。
【０２５１】
１１４は、前記受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、前記受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部、
１１５は、前記パラメータ記憶部１０９に記憶された音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量を参照し、ＲＴＣ１０８の値を送信要求受付時刻と比較し、送信待ちの許容時間を算出する、送信待ち許容時間算出部である。
【０２５２】
１１６は、発呼、着呼、呼の接続・切断の制御、および、各呼の状態に応じたダイヤルトーン、ビジートーン、リンガー、リング・バック・トーンを前記音声出力部１０３に出力する呼制御部、１１７は、呼の設定や解除、通話時の音声パケットの送受信、を指定されたプロトコルに従って処理するプロトコル処理部である。
【０２５３】
１２２は、ＦＩＦＯ方式であらかじめ決められた数の音声パケットの内容または識別子を記憶する受信履歴バッファ、１２３は、前記受信履歴バッファ１２２を参照して、指定された音声パケットと同一音声パケットが記憶されているかどうか検索する、重複パケット検索部、１３０は、全体を制御する、制御部である。
【０２５４】
ここで、図３２の構成と図２の構成との対応関係について説明する。
【０２５５】
１０１の操作部は、２１１のキーボードによって、１０２の音声入力部は、２０８のマイクによって、１０３の音声出力部は、２１０のスピーカによって、それぞれ実現されている。
【０２５６】
１０４の受信バッファ、１０５の送信バッファ、１０９のパラメータ記憶部、１１１の送信パケットキュー、１１３の受信パケットキュー、１２２の受信履歴バッファは、２０３のＲＡＭによって、実現されている。
【０２５７】
１０７の無線通信部は、２０５のベースバンドと２０６のＲＦによって、１０８のＲＴＣは、２０４のＲＴＣによって、１１０のコーデック部は、２１２のコーデック、２０７のＡ／Ｄ、２０９のＤ／Ａによって実現されている。
【０２５８】
１１２のペイロード統合部、１１４のペイロード分割部、１１５の送信待ち許容時間算出部、１２３の重複パケット検索部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって、実現されている。
【０２５９】
図３３は、本発明の実施の形態３における親機の機能ブロック図である。
【０２６０】
図３３において、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファ、１０６は、有線のネットワークと接続するためのＬＡＮ通信部である。
【０２６１】
１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部、１０８は、時間の経過を測定するためのＲＴＣ、１１１は、後述する有線−無線ブリッジ部１２０が、中継が必要と判断したＬＡＮ側からのイーサネット（登録商標）フレームを無線フレーム化して送信するために、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキューである。
【０２６２】
１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部、１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキュー、１１４は、受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。
【０２６３】
１２０は、有線と無線の間のフレームを必要があれば中継し、さもなければ破棄する、有線−無線ブリッジ部、１２２は、ＦＩＦＯ方式であらかじめ決められた数の音声パケットの内容または識別子を記憶する受信履歴バッファ、１２３は、前記受信履歴バッファ１２２を参照して、指定された音声パケットと同一音声パケットが記憶されているかどうか検索する、重複パケット検索部、１３０は、全体を制御する、制御部である。
【０２６４】
ここで、図３３の構成と図４の構成との対応関係について説明する。
【０２６５】
１０４の受信バッファ、１０５の送信バッファ、１１１の送信パケットキュー、１１３の受信パケットキュー、１２２の受信履歴バッファは、２０３のＲＡＭによって、実現されている。
【０２６６】
１０７の無線通信部は、２０５のベースバンドと２０６のＲＦによって、１０８のＲＴＣは、２０４のＲＴＣによって、１０６のＬＡＮ通信部は、２１３のネットワークＩ／Ｆによって、それぞれ実現されている。
【０２６７】
１１２のペイロード統合部、１１４のペイロード分割部、１２０の有線−無線ブリッジ部、１２３の重複パケット検索部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって、実現されている。
【０２６８】
本実施の形態では、無線ＬＡＮ電話システム全体の構成および親機と子機の動作概要は実施の形態１と変わらないので説明を省略する。また、同様に、親機と子機のタスク構成も実施の形態１と同一なので説明を省略する。
【０２６９】
図３４は、本実施の形態における子機の無線送信タスクのフローチャートである。
【０２７０】
送信パケットキュー１１１はあて先のＭＡＣアドレスごとに存在し、無線送信タスクは以下の処理を送信パケットキュー１１１ごとに行う。但し、以下の説明では、ひとつの送信パケットキュー１１１に注目してその動作を説明する。本実施例は実施例２とよく似ているが、実施例２では許容時間内に送信できるパケットをすべてマージして送信するのに対し、本実施例では許容時間内に送信できるパケットのもっとも古いものともっとも新しいもののみをマージする、という点で異なっている。以下、この点を留意しながら詳しく説明する。
【０２７１】
ステップＳ３０１〜Ｓ３０８
実施の形態２における図２５のステップＳ２２１〜Ｓ２２８と同一の処理を行う。
【０２７２】
ここまでの処理で今から送信しても許容時間内に到着しないパケットは送信パケットキュー１１１から削除されていることになる。
【０２７３】
ステップＳ３０９
制御部１３０は、送信パケットキュー１１１を参照して、注目中のエントリの次にエントリが存在するかどうかを判断する。存在すればステップＳ３１４へ、さもなければ、ステップＳ３１０へ進む。ここでは、エントリが存在しないものとして説明を続ける。この場合、送信パケットキュー１１１に音声パケットがひとつしか残っていないことになる。
【０２７４】
ステップＳ３１０
制御部１３０は、注目中のエントリの内容をコピーする。
【０２７５】
ステップＳ３１１
制御部１３０は、ステップＳ３１０でコピーしたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
【０２７６】
ステップＳ３１２
ここでは無線フレームはＩＥＥＥ８０２．１１ｉで規定された暗号化方式によって暗号化されるものとする。制御部１３０は、無線通信部１０７にＣＣＭＰヘッダとＭＩＣキーを付加するよう指示する。すると、無線通信部１０７は、暗号化アルゴリズムにしたがってＣＣＭＰヘッダとＭＩＣキーを計算し、送信バッファ１０５のＩＥＥＥ８０２．１１ｉで規定されたペイロードの位置に追加する。
【０２７７】
ステップＳ３１３
制御部１３０は、無線通信部１０７に送信バッファ１０５の内容を送信するよう指示する。すると、無線通信部１０７は指示された内容を無線フレームとして空中に放出する。ここで、ＩＥＥＥ  ８０２．１１で規定されているプリアンブルやＦＣＳは無線通信部１０７で付加されるものとする。
【０２７８】
ステップＳ３０１へ進む。
【０２７９】
次に、ステップＳ３０９で次のエントリが存在した場合について説明する。
【０２８０】
図２７に示すように５つのエントリが送信パケットキュー１１１に登録されていたものとする。ステップＳ３０９までの処理でエントリ１、２は今から送信しても許容時間内に到着しないので破棄されている。つまり現在エントリ３に注目している。エントリ４が送信パケットキュー１１１に存在するため、ステップＳ３１４が実行される。
【０２８１】
ステップＳ３１４
ステップＳ３１０と同一の処理を行う。
【０２８２】
ステップＳ３１５
ステップＳ３１１と同一の処理を行う。
【０２８３】
ステップＳ３１６
ステップＳ３０８と同一の処理を行う。
【０２８４】
ステップＳ３１７
ステップＳ３０９と同一の処理を行う。次のエントリが存在する場合は、ステップＳ３１６へ、さもなければ、ステップＳ３１０へ進む。
【０２８５】
このように、ステップＳ３１４、Ｓ３１５の処理でもっとも古い音声パケットが送信データとしてマージされる。さらにステップＳ３１６、Ｓ３１７によって、送信パケットキュー１１１のなかでもっとも新しいパケットを見つける。
【０２８６】
以降、ステップＳ３１０〜Ｓ３１３の処理によってもっとも古いパケットともっとも新しいパケットがマージされ、送信される。なお、本実施の形態では、実施の形態２と同一のマージ処理を行うものとする。
【０２８７】
次に、無線受信タスクの動作について図３５のフローチャートに従って説明する。
【０２８８】
なお、本実施例では無線受信タスクは、子機、親機ともに同一の処理を行う。ここで、自局宛の無線フレームは無線通信部１０７によって受信され、受信バッファ１０４にフレームの内容をデータとして書き込んでいるものとする。
【０２８９】
ステップＳ３２１〜Ｓ３２５
実施の形態２における図３０のステップＳ２５１〜Ｓ２５５と同一の処理を行う。
【０２９０】
ステップＳ３２６
ペイロード分割部１１４は、重複パケット検索部１２３に現在注目中のペイロードと等しい内容のパケットが受信履歴バッファ１２２にすでに登録されているかどうかを問い合わせる。
【０２９１】
ステップＳ３２７
重複パケット検索部１２３は、ステップＳ３２６の結果を制御部１３０に通知する。この処理の詳細は後述する。登録されていれば、ステップＳ３２８へ、さもなければ、ステップＳ３３１へ進む。
【０２９２】
ステップＳ３２８〜Ｓ３２９
実施の形態２における図３０のステップＳ２５７〜Ｓ２５８と同一の処理を行う。
【０２９３】
ステップＳ３３０
実施の形態２における図３０のステップＳ２５９と同一の処理を行う。ステップＳ３２６へ進む。
【０２９４】
ステップＳ３３１
ペイロード分割部１１４は、得られたペイロードを受信パケットキュー１１３に入れる。ステップＳ３２８へ進む。
【０２９５】
以上の処理によって、もともと複数の音声パケットがひとつの無線フレームにまとめられていても、正しくもとの音声パケットに分割され、プロトコル処理部１１７に渡される。また、送信側によって同じ音声パケットがコピーされていて、異なる無線フレームで送信されても、本処理によって、同じ音声パケットは破棄される。これにより、親機では、同じ音声パケットをＬＡＮに流すことがなくなるので、ネットワークのトラフィックを不必要に増加させることはない。
【０２９６】
次に、前述の重複パケット検索処理について詳細を説明する。
【０２９７】
図３６は、本実施の形態における重複パケット検索処理を示したフローチャートである。
【０２９８】
ここでは、音声パケットの伝送をＲＴＰプロトコルによって行うものとする。ＲＴＰプロトコルではヘッダ部にシーケンス番号が書き込まれており、音声パケットの重複や欠落、順序の入れ代わりなどを検出できるようになっている。ここでは、受信履歴バッファ１２２は、１０個のシーケンス番号をＦＩＦＯ方式で記憶するものとする。
【０２９９】
ステップＳ３４１
重複パケット検索部１２３は、受信履歴バッファ１２２内にシーケンス番号が登録されているかどうかを判断する。ひとつも登録されていなければ、「重複なし」として処理を終了する。さもなければ、ステップＳ３４２へ進む。
【０３００】
ステップＳ３４２
重複パケット検索部１２３は、受信履歴バッファ１２２内のＦＩＦＯ方式で記憶されている最初のシーケンス番号に注目する。
【０３０１】
ステップＳ３４３
重複パケット検索部１２３は、ペイロード分割部１１４によって指定されたペイロードに含まれるＲＴＰパケットのヘッダ部にあるシーケンス番号を参照して、現在注目しているシーケンス番号と一致するかどうかを照合する。一致する場合は、「重複あり」として処理を終了する。さもなければ、ステップＳ３４４へ進む。
【０３０２】
ステップＳ３４４
重複パケット検索部１２３は、受信履歴バッファ１２２内にいま注目中のシーケンス番号の次にもシーケンス番号が記憶されているかどうかを判断する。記憶されている場合は、ステップＳ３４５へ、さもなければ、「重複なし」として処理を終了する。
【０３０３】
ステップＳ３４５
重複パケット検索部１２３は、現在注目中のシーケンス番号を受信履歴バッファ１２２にＦＩＦＯ方式で記憶されている次のシーケンス番号に移動する。ステップＳ３４３へ進む。
【０３０４】
以上の処理によって、本実施の形態では過去１０パケットにわたって、受信した音声パケットのＲＴＰヘッダのシーケンス番号を調べ、すでに受信したかどうかを判断する。これにより、すでに受信したものは「重複あり」として処理されるため、ペイロード統合部１１４の処理によって破棄されることになる。
【０３０５】
次に、親機についてであるが、親機のタスク構成は実施の形態１と同様である。ここでは実施の形態１、２と異なる親機の無線送信タスクのみを説明する。
【０３０６】
本実施の形態における親機の無線送信タスクについて図３７のフローチャートに従って説明する。
【０３０７】
ステップＳ３５１〜Ｓ３５２
実施の形態１における図１３のステップＳ１３１〜Ｓ１３２と同一の処理を行う。
【０３０８】
ステップＳ３５３
実施の形態１における図１３のステップＳ１３３と同一の処理を行う。ステップＳ３５４へ進む。
【０３０９】
ステップＳ３５４
制御部１３０は送信パケットキュー１１１を参照して、エントリの数が１より大きいかどうかを判断する。１より大きい場合はステップＳ３５５へ、さもなければ、ステップＳ３５８へ進む。
【０３１０】
ステップＳ３５５〜Ｓ３６１
実施の形態１における図１３のステップＳ１３６〜Ｓ１４２と同一の処理を行う。ステップＳ３５１へ進む。
【０３１１】
これまで説明してきたように、本実施の形態で示した子機と親機を組み合わせて利用すれば、無線ＬＡＮで発生しがちな、バーストエラーが発生して、連続した無線フレームが送信エラーとなっても、音声パケットのロスは発生しない。例えば、無線フレームＡに音声パケット１と３、無線フレームＢに音声パケット２と４、無線フレームＣに音声パケット３と５、無線フレームＤに音声パケット４と６、無線フレームＥに音声パケット５と７、無線フレームＦに音声パケット６と８がマージされて送信された場合、途中の無線フレームＣ，Ｄがバーストエラーによって連続して欠落しても、無線フレームＣと無線フレームＤに含まれる音声パケット３，５，４，６は、それぞれ無線フレームＡ、無線フレームＥ、無線フレームＢ，無線フレームＦに含まれるため、受信側はこれを利用して、もとの音声を復元することが可能となる。また、実施例２で示した方法とは異なり、１フレームにつき音声パケットを２つだけ乗せる形になるので必要以上に無線フレームの長さが長くなることも無く、同じｃｈを使って通信している他の端末への影響をより小さくすることができる。
【０３１２】
以上のように、従来、エラーの発生によって、再送が起き、その分、以降の音声の到着時刻が遅延して、さらに、この遅延が蓄積することによって、受信端末側がジッターバッファのオーバーフローを起こし、音声の途切れなどの品質低下が引き起こされていたが、本実施例３によれば、上記の構成により、音声パケットを冗長化して送信するので、エラーが発生してももとの音声を復元することができる。また、音声パケットをまとめてひとつの無線フレームとして送信するので、帯域を必要以上に圧迫しない。さらに、バーストエラーによって連続して無線フレームの送受信に失敗しても、音声パケットをインターリーブすることによって、音声パケットが失われることを極力回避することができる。加えて、受信側で同一の音声パケットを破棄することにより、必要以上にネットワークに負荷をかける心配も無い。このことにより、無線ＬＡＮ電話の利用者に対しては、品質のよい通話環境を提供し、また、同じ無線ＬＡＮ内でデータ通信を行っているユーザに対して、必要以上に帯域を圧迫せず、良好な通信環境を提供できる。
【０３１３】
なお、本実施の形態では、２つの音声パケットを１つの無線フレームとして送信しているが、３つ以上の音声パケットをあらかじめ決められたアルゴリズムによって選択し、それらをひとつの無線フレームにして送信するようにしても本発明の主旨とはなんらかわりない。
【産業上の利用可能性】
【０３１４】
本発明に係る無線ＬＡＮ電話通信方法及びシステムは、無線通信におけるエラーの影響を回避し、高い通話品質を提供できるところから、例えば無線ＬＡＮを利用したコードレス電話などへの利用が可能である。
【図面の簡単な説明】
【０３１５】
【図１】本発明の実施の形態１における子機の機能ブロック図
【図２】本発明の実施の形態１における子機の回路ブロック図
【図３】本発明の実施の形態１における親機の機能ブロック図
【図４】本発明の実施の形態１における親機の回路ブロック図
【図５】本発明の実施の形態１におけるシステムの全体構成図
【図６】本発明の実施の形態１における全体的な処理の流れを示したシーケンス図
【図７】本発明の実施の形態１における子機のタスク構成図
【図８】本発明の実施の形態１における親機のタスク構成図
【図９】本発明の実施の形態１における子機のエンコードタスクのフローチャート
【図１０】本発明の実施の形態１における子機のデコードタスクのフローチャート
【図１１】本発明の実施の形態１における子機の呼制御タスクの状態遷移図
【図１２】本発明の実施の形態１における子機のプロトコル処理タスクのフローチャート
【図１３】本発明の実施の形態１における無線送信タスクのフローチャート
【図１４】本発明の実施の形態１におけるマージ処理のフローチャート
【図１５】無線ＬＡＮ電話における無線フレームの構成図
【図１６】本発明の実施の形態１における無線フレームの構成図
【図１７】本発明の実施の形態１における無線受信タスクのフローチャート
【図１８】本発明の実施の形態１における親機のブリッジタスクのフローチャート
【図１９】本発明の実施の形態１における音声パケットと無線フレームの関係を示す図
【図２０】本発明の実施の形態１におけるエラーと音声パケットの関係を示す図
【図２１】本発明の実施の形態２における子機の機能ブロック図
【図２２】本発明の実施の形態２における親機の機能ブロック図
【図２３】本発明の実施の形態２における子機のタスク構成図
【図２４】本発明の実施の形態２における子機の測定タスクのフローチャート
【図２５】本発明の実施の形態２における子機の送信タスクのフローチャート
【図２６】本発明の実施の形態２における全体遅延量と全体遅延許容時間の関係図
【図２７】本発明の実施の形態２における送信パケットキューの内容例を示す図
【図２８】本発明の実施の形態２における子機のマージ処理のフローチャート
【図２９】本発明の実施の形態２における無線フレームの構成図
【図３０】本発明の実施の形態２における受信タスクのフローチャート
【図３１】本発明の実施の形態２における親機の送信タスクのフローチャート
【図３２】本発明の実施の形態３における子機の機能ブロック図
【図３３】本発明の実施の形態３における親機の機能ブロック図
【図３４】本発明の実施の形態３における子機の送信タスクのフローチャート
【図３５】本発明の実施の形態３における受信タスクのフローチャート
【図３６】本発明の実施の形態３における重複パケット検索処理のフローチャート
【図３７】本発明の実施の形態３における親機の送信タスクのフローチャート
【図３８】従来の無線ＬＡＮ電話装置における無線フレームの送受信の様子を示す図
【符号の説明】
【０３１６】
１０１    操作部
１０２    音声入力部
１０３    音声出力部
１０４    受信バッファ
１０５    送信バッファ
１０６    ＬＡＮ通信部
１０７    無線通信部
１０８    ＲＴＣ
１０９    パラメータ記憶部
１１０    コーデック部
１１１    送信パケットキュー
１１２    ペイロード統合部
１１３    受信パケットキュー
１１４    ペイロード分割部
１１５    送信待ち許容時間算出部
１１６    呼制御部
１１７    プロトコル処理部
１１８    上位プロトコル解析部
１１９    エラー率判定部
１２０    有線−無線ブリッジ部
１２１    ネットワーク遅延測定部
１２２    受信履歴バッファ
１２３    重複パケット検索部
１３０    制御部
２０１    ＣＰＵ
２０２    ＲＯＭ
２０３    ＲＡＭ
２０４    ＲＴＣ
２０５    ベースバンド
２０６    ＲＦ
２０７    Ａ／Ｄ
２０８    マイク
２０９    Ｄ／Ａ
２１０    スピーカ
２１１    キーボード
２１２    コーデック
２１３    ネットワークＩ／Ｆ
【図１】
2008259094.tif 000003
【図２】
2008259094.tif 000004
【図３】
2008259094.tif 000005
【図４】
2008259094.tif 000006
【図５】
2008259094.tif 000007
【図６】
2008259094.tif 000008
【図７】
2008259094.tif 000009
【図８】
2008259094.tif 000010
【図９】
2008259094.tif 000011
【図１０】
2008259094.tif 000012
【図１１】
2008259094.tif 000013
【図１２】
2008259094.tif 000014
【図１３】
2008259094.tif 000015
【図１４】
2008259094.tif 000016
【図１５】
2008259094.tif 000017
【図１６】
2008259094.tif 000018
【図１７】
2008259094.tif 000019
【図１８】
2008259094.tif 000020
【図１９】
2008259094.tif 000021
【図２０】
2008259094.tif 000022
【図２１】
2008259094.tif 000023
【図２２】
2008259094.tif 000024
【図２３】
2008259094.tif 000025
【図２４】
2008259094.tif 000026
【図２５】
2008259094.tif 000027
【図２６】
2008259094.tif 000028
【図２７】
2008259094.tif 000029
【図２８】
2008259094.tif 000030
【図２９】
2008259094.tif 000031
【図３０】
2008259094.tif 000032
【図３１】
2008259094.tif 000033
【図３２】
2008259094.tif 000034
【図３３】
2008259094.tif 000035
【図３４】
2008259094.tif 000036
【図３５】
2008259094.tif 000037
【図３６】
2008259094.tif 000038
【図３７】
2008259094.tif 000039
【図３８】
2008259094.tif 000040