JP2008259094A - 無線ｌａｎ電話通信方法及びシステム - Google Patents
無線ｌａｎ電話通信方法及びシステム Download PDFInfo
- Publication number
- JP2008259094A JP2008259094A JP2007101534A JP2007101534A JP2008259094A JP 2008259094 A JP2008259094 A JP 2008259094A JP 2007101534 A JP2007101534 A JP 2007101534A JP 2007101534 A JP2007101534 A JP 2007101534A JP 2008259094 A JP2008259094 A JP 2008259094A
- Authority
- JP
- Japan
- Prior art keywords
- unit
- transmission
- voice
- packet
- wireless lan
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/08—Arrangements for detecting or preventing errors in the information received by repeating transmission, e.g. Verdan system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for error control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Small-Scale Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
【課題】通信帯域を有効に利用し、かつ、通話品質の高い無線ＬＡＮ電話通信方法及びシステムを提供すること。
【解決手段】発生した音声パケットを複製して１つ以上のコピーを保存しておき、送信時に、以前に発生した１つ以上の音声パケットのコピーと最近発生した音声パケットを１つの無線フレームにまとめて送信する手段と、受信した側で、もとのパケットに分割する手段を有する構成とし、無線ＬＡＮにおいてしばしば発生するバーストエラーが発生しても、音声パケットを冗長化して送信することになり、再送信を行う必要が無い。
【選択図】図１
【解決手段】発生した音声パケットを複製して１つ以上のコピーを保存しておき、送信時に、以前に発生した１つ以上の音声パケットのコピーと最近発生した音声パケットを１つの無線フレームにまとめて送信する手段と、受信した側で、もとのパケットに分割する手段を有する構成とし、無線ＬＡＮにおいてしばしば発生するバーストエラーが発生しても、音声パケットを冗長化して送信することになり、再送信を行う必要が無い。
【選択図】図１
Description
本発明は、本発明は無線ＬＡＮを利用した無線ＬＡＮ電話通信方法及びシステムに関するものである。
近年、ＶｏＩＰ技術を利用したＩＰ電話が普及している。ＩＰ電話では音声をパケット化して、インターネットや専用のネットワークを通して音声を送受信するため、通話コストが安く、また、大手プロバイダがさまざまな地域でサービスを提供しているため、最近では、企業だけでなく、多くの家庭でも利用されるようになった。さらに、最近では、ＩＰ電話機をコードレス化する動きも出てきた。例えば、親機でＩＰ電話のプロトコルを終端し、親機から子機は従来のコードレス電話機の方式で音声を子機とやりとりする製品も発表されている。そして、さらに、ＩＰ電話のプロトコルを親機で終端するのではなく、子機で終端できるようにし、その子機をホットスポットなどのような公共の無線アクセスポイントに持ち出して、安価に通話できるような無線ＬＡＮによるコードレス電話機も提案されている。
従来の無線ＬＡＮ電話について、図面を用いて説明する。
図３８は従来の無線ＬＡＮ電話の通話時における親機から子機への音声パケットの送信の様子を表した図である。従来の無線ＬＡＮ電話では、音声パケットは無線フレームと１対１に対応付けられており、エラーが発生した場合は、ＩＥＥＥ８０２．１１の規格により再送によってエラー回復を行うことが規定されているため、エラー発生時には、無線フレームの再送が行われる（例えば特許文献１参照）。
特開２００２−２４７６４７号公報
しかしながら上記の従来の構成では、有線に比べてエラーの発生率の高い無線通信において実際にエラーが発生した場合、再送を行わなければならないため、通信帯域を有効に利用できず、また、再送を行うと音声が遅延し、通話品質が劣化してしまう、という課題があった。
本発明は、通信帯域を有効に利用し、かつ、通話品質の高い無線ＬＡＮ電話通信方法及びシステムを提供することを目的とする。
本発明は、発生した音声パケットを複製して１つ以上のコピーを保存しておき、送信時に、以前に発生した１つ以上の音声パケットのコピーと最近発生した音声パケットを１つの無線フレームにまとめて送信する手段と、受信した側で、もとのパケットに分割する手段を設けたものである。
この構成によれば、無線ＬＡＮにおいてしばしば発生するバーストエラーが発生しても、音声パケットを冗長化して送信することになるので、再送信を行う必要が無く、音の途切れや遅延が無く、通話品質の高い無線ＬＡＮ電話通信方法及びシステムを提供することができる。
本発明によれば、無線ＬＡＮによる通信においてしばしば発生するバーストエラーが発生しても、音声パケットを冗長化して送信することになるので、再送信を行う必要が無く、音の途切れや遅延の無い、高い通話品質を実現できる。
本発明は、発生した音声パケットを複製して１つ以上のコピーを保存しておき、送信時に、以前に発生した１つ以上の音声パケットのコピーと最近発生した音声パケットを１つの無線フレームにまとめて送信する手段と、受信した側で、もとのパケットに分割する手段を設けている。
これにより、無線ＬＡＮにおいてしばしば発生するバーストエラーが発生しても、音声パケットを冗長化して送信することになるので、再送を行う必要が無く、音の途切れや遅延の無い、高い通話品質を提供することができる。
また、音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量とあらかじめ指定されたアルゴリズムによって決定される無線フレームの送信予定時刻、から送信待ち許容時間を計算して、その送信待ち時間の許容範囲内で、音声パケットを冗長化して複数の音声パケットをひとつの無線フレームにまとめて送信し、受信側で、元通り複数の冗長化された音声パケットに分解するように構成されてもよい。
これにより、音声の遅延許容時間内で最大限の冗長化を行うので、エラー率の高い通信環境でも音声の途切れや遅延のない、高い通話品質を提供できる。
また、音声の遅延許容時間内で音声パケットをキューに保管しておき、連続しない２つ以上の音声パケットをあらかじめ決められたアルゴリズムによって選択し、それらを１つの無線フレームにまとめて送信するように構成してもよい。
これにより、音声パケットがインターリーブされるので、バーストエラーに強い通話を提供できる。
また、ネットワークの遅延を測定して、ネットワークの遅延に適応するように構成してもよい。
これにより、ネットワークのトラフィックが変化して遅延量が変化しても送信側で許容できる送信待ち時間を調整できるので、ネットワークの変動にも影響を受けない高品質の通話を提供できる。
また、受信履歴バッファと重複パケット検索部を設けて、受信側で重複して受信した音声パケットを破棄するように構成してもよい。
これにより、不必要な音声パケット（重複した音声パケット）がネットワークに流れることを防ぐので、ネットワークのトラフィックを圧迫しない良好な通信環境を提供できる。
また、複数の音声パケットをひとつの無線フレームにまとめる際に、上位プロトコルヘッダを解析して、上位プロトコルの冗長なヘッダを縮退させるように構成してもよい。
これにより、冗長なデータが圧縮されるので、無線通信帯域を圧迫しない高品質な通信環境を提供できる。
また、通信エラー率をモニターして、エラー率に応じて音声パケットを冗長化して送信するか、どうかを選択するように構成してもよい。
これにより、エラー率が高い場合のみ冗長化を行うので、エラー率の少ない環境では無線通信帯域に余計な負荷をかけない良好な通信環境を提供できる。
以下、本発明の実施の形態について図面を用いて説明する。
（実施の形態１）
まず、無線ＬＡＮ電話装置子機について説明する。
まず、無線ＬＡＮ電話装置子機について説明する。
図１は、本発明による実施の形態１における無線ＬＡＮ電話装置子機を示す機能ブロック図である。
図１において、１０１は、発呼先の指定、着呼時に通話の指示および終話の指示をするための操作部、１０２は、音声を入力するための音声入力部、１０３は、音声を出力するための音声出力部、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファ、１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部、１０８は、時間の経過を測定するためのＲＴＣである。
１０９は、音声のコーデック周期を記憶するパラメータ記憶部、１１０は、音声入力部１０２から入力した音声をＡ／Ｄ変換し、所定のアルゴリズムを用いて音声パケットに変換（エンコード）する、また、音声データを所定のアルゴリズムを用いてデコードした上で、Ｄ／Ａ変換し、音声出力部１０３に出力するコーデック部、１１１は、コーデック部１１０がエンコードした音声パケットをエンコードが完了した時刻、すなわち、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキュー、１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部、１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキュー、１１４は、受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。
１１６は、発呼、着呼、呼の接続・切断の制御、および、各呼の状態に応じたダイヤルトーン、ビジートーン、リンガー、リング・バック・トーンを音声出力部１０３に出力する呼制御部、１１７は、呼の設定や解除、通話時の音声パケットの送受信、を指定されたプロトコルに従って処理するプロトコル処理部、１１８は、上位プロトコルを解析する、上位プロトコル解析部、１１９は、無線通信におけるエラー率を算出し、あらかじめ指定されたエラー率よりも低いかどうかを判定する、エラー率判定部、１３０は、全体を制御する制御部である。
図２は、本発明の実施の形態１における無線ＬＡＮ電話装置子機を示す装置ブロック図である。
図２において、２０１は、中央処理装置（以下、ＣＰＵと称する）、２０２は、ＲＯＭ、２０３は、ＲＡＭ、２０４は、ＲＴＣ、２０５は、ベースバンド、２０６は、ＲＦ、２０７は、Ａ／Ｄ、２０８は、マイク、２０９は、Ｄ／Ａ、２１０は、スピーカ、２１１は、キーボード、２１２は、コーデックである。
図１及び図２において、１０１の操作部は、２１１のキーボードによって、１０２の音声入力部は、２０８のマイクによって、１０３の音声出力部は、２１０のスピーカによって、それぞれ実現されている。
１０４の受信バッファ、１０５の送信バッファ、１０９のパラメータ記憶部、１１１の送信パケットキュー、１１３の受信パケットキューは、２０３のＲＡＭによって実現されている。
１０７の無線通信部は、２０５のベースバンドと２０６のＲＦによって実現されている。また、１０８のＲＴＣは、２０４のＲＴＣによって、また、１１０のコーデック部は、２１２のコーデック、２０７のＡ／Ｄ、２０９のＤ／Ａによって、それぞれ実現されている。
１１２のペイロード統合部、１１４のペイロード分割部、１１６の呼制御部、１１７のプロトコル処理部、１１８の上位プロトコル解析部、１１９のエラー率判定部、及び、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって実現されている。
続いて、無線ＬＡＮ電話装置親機について説明する。
図３は、本発明による実施の形態１における無線ＬＡＮ電話装置親機を示す機能ブロック図である。
図３において、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファ、１０６は、有線のネットワークと接続するためのＬＡＮ通信部、１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部、１０８は、時間の経過を測定するためのＲＴＣである。
１１１は、後述する有線−無線ブリッジ部１２０が、中継が必要と判断したＬＡＮ側からのイーサネット（登録商標）フレームを無線フレーム化して送信するために、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキュー、１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部、１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する受信パケットキュー、１１４は、受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込むペイロード分割部、１１８は、上位プロトコルを解析する、上位プロトコル解析部、１１９は、無線通信におけるエラー率を算出し、あらかじめ指定されたエラー率よりも低いかどうかを判定するエラー率判定部、１２０は、有線と無線の間のフレームを必要があれば中継し、さもなければ破棄する有線−無線ブリッジ部、１３０は、全体を制御する制御部である。
図４は、本発明の実施の形態１における無線ＬＡＮ電話装置親機を示す装置ブロック図である。
図４において、２０１は、ＣＰＵ、２０２は、ＲＯＭ、２０３は、ＲＡＭ、２０４は、ＲＴＣ、２０５は、ベースバンド、２０６は、ＲＦ、２１３は、ネットワークＩ／Ｆである。
図３及び図４において、受信バッファ１０４、送信バッファ１０５、送信パケットキュー１１１、受信パケットキュー１１３は、ＲＡＭ２０３によって実現される。
無線通信部１０７は、ベースバンド２０５とＲＦ２０６によって、ＲＴＣ１０８は、ＲＴＣ２０４によって、ＬＡＮ通信部１０６は、ネットワークＩ／Ｆ２１３によって、それぞれ実現される。
ペイロード統合部１１２、ペイロード分割部１１４、上位プロトコル解析部１１８、エラー率判定部１１９、有線−無線ブリッジ部１２０、制御部１３０は、ＣＰＵ２０１がＲＯＭ２０２の中に記憶しているプログラムを、ＲＯＭ２０２の中に記憶しているデータを参照したり、ＲＡＭ２０３に記憶しているデータを参照したり、変更したりしながら実行することによって実現される。
続いて、本発明の無線ＬＡＮ電話システムの全体構成について説明する。
図５は、本発明の実施の形態１における無線ＬＡＮ電話システムを示した図である。
図５に示すように、子機Ａは親機Ａの管理下にあり、同様に、子機Ｂは親機Ｂの管理下にある。親機Ａ、親機Ｂはそれぞれインターネットに接続されている。親機Ａ、親機Ｂにはブリッジの機能が搭載されていて、子機からの無線フレームを、ＬＡＮ通信部（有線）を使用してインターネット側にイーサネット（登録商標）フレームとして中継したり、インターネット側からのイーサネット（登録商標）フレームを子機に無線フレームとして中継したりする。
以上のように構成された無線ＬＡＮ電話システムについて、親機と子機の動作について、図６のシーケンスチャートにしたがって説明する。
以下説明する動作は、近年ＶｏＩＰでしばしば利用されているＳＩＰというプロトコルを参考にしている。ただし、説明を必要以上に複雑にしないため、多少、処理を簡略化して説明している。また、ここでは、親機、子機の連携に重点を置いて説明をすることにする。子機の「エンコード」「デコード」、親機の「ブリッジ処理」、親機・子機の「無線送信」「無線受信」は後に詳細を説明する。なお、本実施の形態では、子機は最初、待ち受け状態にあるものとする。
ステップＥ０１
まず、子機Ａのユーザは、子機Ａの操作部１０１を利用して発呼先を指定する（ステップＥ０１）。ここでは、ユーザが操作部１０１より、発呼先の番号０５０−１００１−１２３４を入力し、発呼を指示したものとする。
まず、子機Ａのユーザは、子機Ａの操作部１０１を利用して発呼先を指定する（ステップＥ０１）。ここでは、ユーザが操作部１０１より、発呼先の番号０５０−１００１−１２３４を入力し、発呼を指示したものとする。
ステップＭ０２
制御部１３０は操作部１０１より入力された発呼先番号を受け取り、呼制御部１１６対して、指定された発呼先番号に呼を設定するよう要求する。呼制御部１１６は、「呼の接続要求」を子機Ｂに知らせるため、「ＩＮＶＩＴＥ」メッセージを作成して、プロトコル処理部１１７に子機Ｂまで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を通して親機Ａに「ＩＮＶＩＴＥ」を意味するデータを送信する（詳細は「子機送信処理」として後述）。親機Ａは受け取った無線フレームを有線のイーサネット（登録商標）フレームに変換しインターネットへ送信する（詳細は「親機ブリッジ処理」として後述）。親機Ａから送信されたイーサネット（登録商標）フレームはインターネット（図では省略）を通って、親機Ｂに到着する。親機Ｂでは、受け取ったイーサネット（登録商標）フレームを中継し、無線フレームに変換して、子機Ｂに送信する（詳細は「親機ブリッジ処理」として後述）。子機Ｂでは、親機Ｂが送信した無線フレームを受け取り、無線通信部１０７、プロトコル処理部１１７を経由して呼制御部１１６に「ＩＮＶＩＴＥ」メッセージが通知される（詳細は「子機受信処理」として後述）。これにより子機Ｂは着呼したことになる。
制御部１３０は操作部１０１より入力された発呼先番号を受け取り、呼制御部１１６対して、指定された発呼先番号に呼を設定するよう要求する。呼制御部１１６は、「呼の接続要求」を子機Ｂに知らせるため、「ＩＮＶＩＴＥ」メッセージを作成して、プロトコル処理部１１７に子機Ｂまで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を通して親機Ａに「ＩＮＶＩＴＥ」を意味するデータを送信する（詳細は「子機送信処理」として後述）。親機Ａは受け取った無線フレームを有線のイーサネット（登録商標）フレームに変換しインターネットへ送信する（詳細は「親機ブリッジ処理」として後述）。親機Ａから送信されたイーサネット（登録商標）フレームはインターネット（図では省略）を通って、親機Ｂに到着する。親機Ｂでは、受け取ったイーサネット（登録商標）フレームを中継し、無線フレームに変換して、子機Ｂに送信する（詳細は「親機ブリッジ処理」として後述）。子機Ｂでは、親機Ｂが送信した無線フレームを受け取り、無線通信部１０７、プロトコル処理部１１７を経由して呼制御部１１６に「ＩＮＶＩＴＥ」メッセージが通知される（詳細は「子機受信処理」として後述）。これにより子機Ｂは着呼したことになる。
ステップＥ０３
子機Ｂでは、呼制御部１１６がコーデック部１１０にリンガー（着信音）を流すよう要求する。すると、コーデック部１１０は、音声出力部１０３に着信音として記憶している音声を出力する。
子機Ｂでは、呼制御部１１６がコーデック部１１０にリンガー（着信音）を流すよう要求する。すると、コーデック部１１０は、音声出力部１０３に着信音として記憶している音声を出力する。
ステップＭ０４
子機Ｂでは、呼制御部１１６は「着呼を受け入れた」旨を子機Ａに知らせるため、「ＲＩＮＧＩＮＧ」メッセージを作成し、プロトコル処理部１１７に子機Ａまで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＲＩＮＧＩＮＧ」意味するデータを親機Ｂへ送信する。このデータは親機Ｂによって無線フレームからイーサネット（登録商標）フレームに変換され、インターネットを通り、親機Ａに届く。さらに、親機Ａは受け取ったイーサネット（登録商標）フレームを中継し、無線フレームとして子機Ａに送信する。
子機Ｂでは、呼制御部１１６は「着呼を受け入れた」旨を子機Ａに知らせるため、「ＲＩＮＧＩＮＧ」メッセージを作成し、プロトコル処理部１１７に子機Ａまで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＲＩＮＧＩＮＧ」意味するデータを親機Ｂへ送信する。このデータは親機Ｂによって無線フレームからイーサネット（登録商標）フレームに変換され、インターネットを通り、親機Ａに届く。さらに、親機Ａは受け取ったイーサネット（登録商標）フレームを中継し、無線フレームとして子機Ａに送信する。
ステップＥ０５
子機Ａでは、無線通信部１０７、プロトコル処理部１１７を経由して、呼制御部１１６が「ＲＩＮＧＩＮＧ」メッセージを受け取り、発呼先が着呼を受け入れた旨を知る。呼制御部１１６は、コーデック部１１０にリング・バック・トーン（呼び出し音、以降ＲＢＴと略記する）を出力するよう要求する。すると、コーデック部１１０は、音声出力部１０３にＲＢＴを出力する。
子機Ａでは、無線通信部１０７、プロトコル処理部１１７を経由して、呼制御部１１６が「ＲＩＮＧＩＮＧ」メッセージを受け取り、発呼先が着呼を受け入れた旨を知る。呼制御部１１６は、コーデック部１１０にリング・バック・トーン（呼び出し音、以降ＲＢＴと略記する）を出力するよう要求する。すると、コーデック部１１０は、音声出力部１０３にＲＢＴを出力する。
ステップＥ０６
子機Ｂにおいて、ユーザがリンガーを聞いて着信していることに気がつくと、操作部１０１を操作して、通話を指示する。すると、子機Ｂでは、制御部１３０が操作部１０１から「通話を指示された」旨を受け取り、呼制御部１１６に「呼を接続する」よう要求する。
子機Ｂにおいて、ユーザがリンガーを聞いて着信していることに気がつくと、操作部１０１を操作して、通話を指示する。すると、子機Ｂでは、制御部１３０が操作部１０１から「通話を指示された」旨を受け取り、呼制御部１１６に「呼を接続する」よう要求する。
ステップＭ０７
子機Ｂにおいて、呼制御部１１６は、「着呼に対してユーザが応答した」旨を子機Ａに知らせるため、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージ作成し、子機Ａに送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＣＯＮＮＥＣＴ−ＯＫ」を意味するデータを親機Ｂに送信する。すると、親機Ｂでは子機Ｂから受け取った無線フレームをイーサネット（登録商標）フレームに変換して中継し、イーサネット（登録商標）フレームはインターネットを通って親機Ａに届く。親機Ａでは、届いたイーサネット（登録商標）フレームを無線フレームに変換して中継し、子機Ａに送信する。子機Ａでは、無線通信部１０７、プロトコル処理部１１７を経由して、「ＣＯＮＮＥＣＴ−ＯＫ」を呼制御部１１６が受け取り、コーデック部１１０にＲＢＴを停止さるよう要求する。すると、コーデック部はＲＢＴを停止する。
子機Ｂにおいて、呼制御部１１６は、「着呼に対してユーザが応答した」旨を子機Ａに知らせるため、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージ作成し、子機Ａに送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＣＯＮＮＥＣＴ−ＯＫ」を意味するデータを親機Ｂに送信する。すると、親機Ｂでは子機Ｂから受け取った無線フレームをイーサネット（登録商標）フレームに変換して中継し、イーサネット（登録商標）フレームはインターネットを通って親機Ａに届く。親機Ａでは、届いたイーサネット（登録商標）フレームを無線フレームに変換して中継し、子機Ａに送信する。子機Ａでは、無線通信部１０７、プロトコル処理部１１７を経由して、「ＣＯＮＮＥＣＴ−ＯＫ」を呼制御部１１６が受け取り、コーデック部１１０にＲＢＴを停止さるよう要求する。すると、コーデック部はＲＢＴを停止する。
ステップＥ０８
以降、全２重の通信路が確保され、通話が可能となる。ここでは、インターネットの通信帯域は十分広く、遅延も数１０ｍｓ程度であることを仮定している。つまり、子機Ａと子機Ｂの間での通信のボトルネックは子機−親機間であると仮定している。
以降、全２重の通信路が確保され、通話が可能となる。ここでは、インターネットの通信帯域は十分広く、遅延も数１０ｍｓ程度であることを仮定している。つまり、子機Ａと子機Ｂの間での通信のボトルネックは子機−親機間であると仮定している。
ステップＭ０９
通話中、子機Ａのユーザの音声は子機Ａの音声入力部１０２に入力され、コーデック部１１０によってエンコードされ、音声パケットとしてプロトコル処理部１１７によって子機Ｂまで送信される。子機Ｂでは、無線通信部１０７、プロトコル処理部１１７を経由してコーデック部１１０が音声パケットを受け取り、これをデコードし、結果を子機Ｂの音声出力部１０３に出力する。子機Ｂ側からのユーザの音声が子機Ａに届く処理は、前述の処理とちょうど対称の処理となるため、説明を省略する。
通話中、子機Ａのユーザの音声は子機Ａの音声入力部１０２に入力され、コーデック部１１０によってエンコードされ、音声パケットとしてプロトコル処理部１１７によって子機Ｂまで送信される。子機Ｂでは、無線通信部１０７、プロトコル処理部１１７を経由してコーデック部１１０が音声パケットを受け取り、これをデコードし、結果を子機Ｂの音声出力部１０３に出力する。子機Ｂ側からのユーザの音声が子機Ａに届く処理は、前述の処理とちょうど対称の処理となるため、説明を省略する。
ステップＥ１０
子機Ｂのユーザは通話を終了するため、呼切断を操作部１０１から指示する。すると、制御部１３０は操作部１０１から呼切断の指示を受け取って、呼制御部１１６に呼切断を要求する。呼制御部１１６はエンコードタスクとデコードタスクを停止する。すると、コーデック部１１０はコーデックを停止する。以降、音声パケットを受け取っても破棄し、音声の入力に対してエンコードも行わない。
子機Ｂのユーザは通話を終了するため、呼切断を操作部１０１から指示する。すると、制御部１３０は操作部１０１から呼切断の指示を受け取って、呼制御部１１６に呼切断を要求する。呼制御部１１６はエンコードタスクとデコードタスクを停止する。すると、コーデック部１１０はコーデックを停止する。以降、音声パケットを受け取っても破棄し、音声の入力に対してエンコードも行わない。
ステップＭ１１
子機Ｂにおいて、呼制御部１１６は、「ＢＹＥ」メッセージを作成し、プロトコル処理部１１７に子機Ａまで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＢＹＥ」を意味するデータを親機Ｂに送信する。これまでと同様に、「ＢＹＥ」メッセージは、親機Ｂ、インターネット、親機Ａを経由して子機Ａに到着する。
子機Ｂにおいて、呼制御部１１６は、「ＢＹＥ」メッセージを作成し、プロトコル処理部１１７に子機Ａまで送信するよう要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＢＹＥ」を意味するデータを親機Ｂに送信する。これまでと同様に、「ＢＹＥ」メッセージは、親機Ｂ、インターネット、親機Ａを経由して子機Ａに到着する。
ステップＥ１２
子機Ａにおいて、呼制御部１１６は、無線通信部１０７、プロトコル処理部１１７を経由して「ＢＹＥ」のメッセージを受け取る。呼制御部１１６はエンコードタスクとデコードタスクを停止する。すると、コーデック部１１０はコーデックを停止する。以降、音声パケットを受け取っても破棄し、音声の入力に対してもエンコードを行わない。
子機Ａにおいて、呼制御部１１６は、無線通信部１０７、プロトコル処理部１１７を経由して「ＢＹＥ」のメッセージを受け取る。呼制御部１１６はエンコードタスクとデコードタスクを停止する。すると、コーデック部１１０はコーデックを停止する。以降、音声パケットを受け取っても破棄し、音声の入力に対してもエンコードを行わない。
ステップＭ１３
子機Ａにおいて、呼制御部１１６は「ＢＹＥ−ＯＫ」メッセージを作成し、子機Ｂまで送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＢＹＥ−ＯＫ」を意味するデータを親機Ａに送信する。これまでと同様に、「ＢＹＥ−ＯＫ」のメッセージは親機Ａ、インターネット、親機Ｂを経由して子機Ｂに届く。
子機Ａにおいて、呼制御部１１６は「ＢＹＥ−ＯＫ」メッセージを作成し、子機Ｂまで送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は、無線通信部１０７を経由して、「ＢＹＥ−ＯＫ」を意味するデータを親機Ａに送信する。これまでと同様に、「ＢＹＥ−ＯＫ」のメッセージは親機Ａ、インターネット、親機Ｂを経由して子機Ｂに届く。
ステップＥ１４
子機Ｂにおいて、呼制御部１１６は、無線通信部１０７、プロトコル処理部１１７を経由して、「ＢＹＥ−ＯＫ」メッセージを受け取る。以降、子機Ｂは「待ち受けモード」となる。
子機Ｂにおいて、呼制御部１１６は、無線通信部１０７、プロトコル処理部１１７を経由して、「ＢＹＥ−ＯＫ」メッセージを受け取る。以降、子機Ｂは「待ち受けモード」となる。
次に、本実施の形態の子機の動作の概要を説明する。
図７は、本発明の実施の形態１における子機のタスク構成図を示している。
本実施の形態では、音声をエンコードするエンコードタスク、音声をデコードするデコードタスク、呼設定・接続・切断などを行う呼制御タスク、送信パケットキューに記憶された音声パケットを無線フレームとして送信する無線送信タスク、無線フレームを受信して音声パケットにし、受信パケットキューに書き込む無線受信タスクが並行して動作しているものとする。エンコードタスク、デコードタスク、呼制御タスクはプロトコル処理タスクに対して送信要求、受信要求を行う。受信要求を行ったあと、プロトコル処理タスクは要求があったデータを受信すると、その旨を、受信要求を行ったタスクに通知する。なお、図中の矢印はデータの流れを示している。
次に、本実施の形態における親機の動作の概要を説明する。
図８は、本発明の実施の形態１における親機のタスク構成図を示している。
親機では、子機と同様に無線送信タスク、無線受信タスクおよび、「無線受信タスクが受け取った無線フレームを吟味し、有線と無線の間でフレームを中継するかどうかを決定し、必要があれば、フレームの形式を変換した後、ＬＡＮ通信部１０６を介してイーサネット（登録商標）フレームを送信する、また、ＬＡＮ通信部１０６を通して受信したイーサネット（登録商標）フレームを吟味し、有線と無線の間でフレームを中継するかどうかを決定し、必要があれば、フレームの形式を変換した後、無線送信タスクに渡す」ブリッジタスクが並行して動作している。
以降、子機のそれぞれのタスク動作についてフローチャートを使用して説明する。
まず、エンコードタスクの処理について図９のフローチャートに従って説明する。
エンコードタスクは、呼制御タスクによって通話中に起動される。通話が終わると呼制御タスクによって停止させられる。以下の説明は通話中のエンコードタスクの動作である。
ステップＳ０１
コーデック部１１０は音声入力部１０２から音声の受け取り、サンプリング（Ａ／Ｄ変換）およびエンコードを行う。
コーデック部１１０は音声入力部１０２から音声の受け取り、サンプリング（Ａ／Ｄ変換）およびエンコードを行う。
ステップＳ０２
コーデック部１１０はパラメータ記憶部１０９に記憶されたコーデック間隔を参照し、ＲＴＣ１０８と比較しながらコーデック間隔で指定されている時間だけエンコードが行われたかどうかを判断する。指定された時間が経過していれば、ステップＳ０３へ進む。さもなければ、ステップＳ０１に戻る。
コーデック部１１０はパラメータ記憶部１０９に記憶されたコーデック間隔を参照し、ＲＴＣ１０８と比較しながらコーデック間隔で指定されている時間だけエンコードが行われたかどうかを判断する。指定された時間が経過していれば、ステップＳ０３へ進む。さもなければ、ステップＳ０１に戻る。
ステップＳ０３
コーデック部１１０はサンプリングしたデータをプロトコル処理部１１７に渡し、送信を要求する。ステップＳ０１に戻る。
コーデック部１１０はサンプリングしたデータをプロトコル処理部１１７に渡し、送信を要求する。ステップＳ０１に戻る。
次に、デコードタスクの処理について図１０のフローチャートに従って説明する。
デコードタスクは呼制御タスクによって通話中に起動される。通話が終わると呼制御タスクによって停止させられる。以下の説明は通話中のデコードタスクの動作である。
ステップＳ１０１
コーデック部１１０は、プロトコル処理部１１７から受信通知を受け取っているかどうかを確認する。受信通知を受け取っていれば、ステップＳ１０２へ進む。さもなければ、ステップＳ１０１に戻る。
コーデック部１１０は、プロトコル処理部１１７から受信通知を受け取っているかどうかを確認する。受信通知を受け取っていれば、ステップＳ１０２へ進む。さもなければ、ステップＳ１０１に戻る。
ステップＳ１０２
コーデック部１１０はプロトコル処理部１１７から受信データを受け取る。
コーデック部１１０はプロトコル処理部１１７から受信データを受け取る。
ステップＳ１０３
コーデック部１１０は受け取ったデータのＲＴＰヘッダを参照し、前回の受信データのタイムスタンプと一致するかどうかを判断する。一致する場合はステップＳ１０１へ、さもなければ、ステップＳ１０４へ進む。
コーデック部１１０は受け取ったデータのＲＴＰヘッダを参照し、前回の受信データのタイムスタンプと一致するかどうかを判断する。一致する場合はステップＳ１０１へ、さもなければ、ステップＳ１０４へ進む。
ステップＳ１０４
コーデック部１１０は受け取ったデータのＲＴＰヘッダに書かれているタイムスタンプを記憶する。
コーデック部１１０は受け取ったデータのＲＴＰヘッダに書かれているタイムスタンプを記憶する。
ステップＳ１０５
コーデック部１１０は受け取ったデータをデコードし、結果をＤ／Ａ変換し、その出力を音声出力部１０３に出力する。ステップＳ１０１に戻る。
コーデック部１１０は受け取ったデータをデコードし、結果をＤ／Ａ変換し、その出力を音声出力部１０３に出力する。ステップＳ１０１に戻る。
次に、呼制御タスクの動作について図１１のステートチャートに従って説明する。
まず、子機Ａの電源がＯＮされて、子機Ａのユーザが発呼、通話、切断を行う一連の処理について呼制御タスクの動作を子機Ａの側から説明する。
ステップＥ−１
子機の電源ＯＮが操作部１０１から指示されると、制御部１３０は呼制御タスク、プロトコル処理タスク、無線送信タスク、無線受信タスクを起動する。呼制御タスクは起動されると、待ち受け状態に遷移する。すると、以降、発着呼が可能になる。
子機の電源ＯＮが操作部１０１から指示されると、制御部１３０は呼制御タスク、プロトコル処理タスク、無線送信タスク、無線受信タスクを起動する。呼制御タスクは起動されると、待ち受け状態に遷移する。すると、以降、発着呼が可能になる。
ステップＥ−２
子機Ａでユーザが操作部１０１を操作して子機Ｂに発呼を行う。子機Ａの制御部１３０は操作部１０１からの「発呼」の通知を受け、発呼先番号を受け取り、呼制御部１１６に相手先番号を指定して「呼接続」要求する。呼制御部１１６は、「ＩＮＶＩＴＥ」メッセージを子機Ｂまで送信するようプロトコル処理部１１７に要求する。子機Ｂは、「ＩＮＶＩＴＥ」メッセージを受け付けて、着呼中となり、「ＲＩＮＧＩＮＧ」メッセージを子機Ａに送り返してくる。子機Ａの呼制御部１１６はプロトコル処理部１１７経由で子機Ｂからの「ＲＩＮＧＩＮＧ」メッセージを受信し、発呼中状態に遷移する。呼制御部１１６はＲＢＴを音声出力部１０３に出力し、ユーザに「呼び出し中」であることを知らせる。
子機Ａでユーザが操作部１０１を操作して子機Ｂに発呼を行う。子機Ａの制御部１３０は操作部１０１からの「発呼」の通知を受け、発呼先番号を受け取り、呼制御部１１６に相手先番号を指定して「呼接続」要求する。呼制御部１１６は、「ＩＮＶＩＴＥ」メッセージを子機Ｂまで送信するようプロトコル処理部１１７に要求する。子機Ｂは、「ＩＮＶＩＴＥ」メッセージを受け付けて、着呼中となり、「ＲＩＮＧＩＮＧ」メッセージを子機Ａに送り返してくる。子機Ａの呼制御部１１６はプロトコル処理部１１７経由で子機Ｂからの「ＲＩＮＧＩＮＧ」メッセージを受信し、発呼中状態に遷移する。呼制御部１１６はＲＢＴを音声出力部１０３に出力し、ユーザに「呼び出し中」であることを知らせる。
ステップＥ−３
子機Ｂでは、リンガー（着信音）が鳴っており、ユーザは着信音に気づいて着信を受け入れる。すると、エンコードタスク、デコードタスクが起動された後、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａに送信してくる。子機Ａでは、呼制御部１１６が、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを、プロトコル処理部１１７を経由して受け取る。すると、呼制御部１１６は前述のエンコードタスクとデコードタスクを起動し、コーデック部１１０は、以降の音声入力部１０２からの音声をＡ／Ｄ変換およびエンコードし、音声パケットとしてプロトコル処理部１１７に渡す。また、コーデック部１１０はプロトコル処理部１１７が受け取った音声パケットをデコードおよびＤ／Ａ変換し、音声出力部１０３に出力する。通話中に遷移する。
子機Ｂでは、リンガー（着信音）が鳴っており、ユーザは着信音に気づいて着信を受け入れる。すると、エンコードタスク、デコードタスクが起動された後、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａに送信してくる。子機Ａでは、呼制御部１１６が、「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを、プロトコル処理部１１７を経由して受け取る。すると、呼制御部１１６は前述のエンコードタスクとデコードタスクを起動し、コーデック部１１０は、以降の音声入力部１０２からの音声をＡ／Ｄ変換およびエンコードし、音声パケットとしてプロトコル処理部１１７に渡す。また、コーデック部１１０はプロトコル処理部１１７が受け取った音声パケットをデコードおよびＤ／Ａ変換し、音声出力部１０３に出力する。通話中に遷移する。
ステップＥ−９
子機Ａのユーザが通話を終えた場合、子機Ａの操作部１０１を操作して、呼を切断する。制御部１３０は操作部１０１からの切断操作の通知を受け、呼制御部１１６に「呼切断」を要求する。呼制御部１１６はエンコードタスクとデコードタスクを停止させる。すると、呼制御部１１６は「ＢＹＥ」メッセージを子機Ｂへ送るようプロトコル処理部１１７に要求する。プロトコル処理部１１７は無線処理部１０７を経由して「ＢＹＥ」メッセージを意味するデータを親機Ａに送信し、インターネット、親機Ｂ、を経由して子機Ｂに到着する。子機Ｂは「ＢＹＥ」メッセージを受け取ると、「ＢＹＥ−ＯＫ」を子機Ａに返送する。子機Ａでは、無線通信部１０７、プロトコル処理部１１７を経由して、呼制御部１１６が「ＢＹＥ−ＯＫ」メッセージを受け取る。すると、待ち受け状態に遷移する。
子機Ａのユーザが通話を終えた場合、子機Ａの操作部１０１を操作して、呼を切断する。制御部１３０は操作部１０１からの切断操作の通知を受け、呼制御部１１６に「呼切断」を要求する。呼制御部１１６はエンコードタスクとデコードタスクを停止させる。すると、呼制御部１１６は「ＢＹＥ」メッセージを子機Ｂへ送るようプロトコル処理部１１７に要求する。プロトコル処理部１１７は無線処理部１０７を経由して「ＢＹＥ」メッセージを意味するデータを親機Ａに送信し、インターネット、親機Ｂ、を経由して子機Ｂに到着する。子機Ｂは「ＢＹＥ」メッセージを受け取ると、「ＢＹＥ−ＯＫ」を子機Ａに返送する。子機Ａでは、無線通信部１０７、プロトコル処理部１１７を経由して、呼制御部１１６が「ＢＹＥ−ＯＫ」メッセージを受け取る。すると、待ち受け状態に遷移する。
ステップＥ−７
また、ユーザが発呼中に発呼を取りやめる場合は、操作部１０１から発呼取りやめの指示を行い、制御部１３０が操作部１０１から発呼取りやめの指示を受け取り、呼制御部１１６に発呼取りやめを要求する。呼制御部１１６はプロトコル処理部１１７に「ＣＡＮＣＥＬ」のメッセージを子機Ｂへ送信するよう要求する。子機Ｂはリンガーを停止、「ＣＡＮＣＥＬ−ＯＫ」メッセージを子機Ａに送信する。子機Ａでは、子機Ｂからの「ＣＡＮＣＥＬ−ＯＫ」をプロトコル処理部１１７が受け取り呼制御部１１６に通知すると、呼制御部１１６は待ち受け状態に遷移する。
また、ユーザが発呼中に発呼を取りやめる場合は、操作部１０１から発呼取りやめの指示を行い、制御部１３０が操作部１０１から発呼取りやめの指示を受け取り、呼制御部１１６に発呼取りやめを要求する。呼制御部１１６はプロトコル処理部１１７に「ＣＡＮＣＥＬ」のメッセージを子機Ｂへ送信するよう要求する。子機Ｂはリンガーを停止、「ＣＡＮＣＥＬ−ＯＫ」メッセージを子機Ａに送信する。子機Ａでは、子機Ｂからの「ＣＡＮＣＥＬ−ＯＫ」をプロトコル処理部１１７が受け取り呼制御部１１６に通知すると、呼制御部１１６は待ち受け状態に遷移する。
次に、子機Ｂ側からみた、呼制御タスクの動作について説明する。
ステップＥ−４
プロトコル処理部１１７は子機Ａから「ＩＮＶＩＴＥ」メッセージを受け取り、呼制御部１１６に通知する。呼制御部１１６はプロトコル処理部１１７に「ＲＩＮＧＩＮＧ」メッセージを子機Ａに返送するよう要求する。呼制御部１１６はリンガーを音声出力部１０３に出力し、ユーザに着信が発生していることを知らせる。呼制御部１１６は着呼中状態に遷移する。
プロトコル処理部１１７は子機Ａから「ＩＮＶＩＴＥ」メッセージを受け取り、呼制御部１１６に通知する。呼制御部１１６はプロトコル処理部１１７に「ＲＩＮＧＩＮＧ」メッセージを子機Ａに返送するよう要求する。呼制御部１１６はリンガーを音声出力部１０３に出力し、ユーザに着信が発生していることを知らせる。呼制御部１１６は着呼中状態に遷移する。
ステップＥ−５
ユーザはリンガーによって着呼していることを知り、操作部１０１を操作して、着信に応答する。制御部１３０は操作部１０１から着信応答を受け取り、呼制御部１１６に応答を要求する。すると、呼制御部１１６は「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａに送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａに送信する。さらに呼制御部１１６は、音声出力部１０３へのリンガーの出力を停止し、エンコードタスクとデコードタスクを起動して、以降の音声入力部１０２からの音声がＡ／Ｄ変換・エンコードされ、音声パケットとして子機Ａへ送信されるようにし、また、子機Ａからの音声パケットがデコード・Ｄ／Ａ変換され、音声出力部１０３から出力されるようにする。
ユーザはリンガーによって着呼していることを知り、操作部１０１を操作して、着信に応答する。制御部１３０は操作部１０１から着信応答を受け取り、呼制御部１１６に応答を要求する。すると、呼制御部１１６は「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａに送信するようプロトコル処理部１１７に要求する。プロトコル処理部１１７は「ＣＯＮＮＥＣＴ−ＯＫ」メッセージを子機Ａに送信する。さらに呼制御部１１６は、音声出力部１０３へのリンガーの出力を停止し、エンコードタスクとデコードタスクを起動して、以降の音声入力部１０２からの音声がＡ／Ｄ変換・エンコードされ、音声パケットとして子機Ａへ送信されるようにし、また、子機Ａからの音声パケットがデコード・Ｄ／Ａ変換され、音声出力部１０３から出力されるようにする。
ステップＥ−９
プロトコル処理部１１７は子機Ａから「ＢＹＥ」メッセージを受信し、呼制御部１１６に通知する。呼制御部１１６はエンコードタスクとデコードタスクを停止し、待ち受け状態に遷移する。
プロトコル処理部１１７は子機Ａから「ＢＹＥ」メッセージを受信し、呼制御部１１６に通知する。呼制御部１１６はエンコードタスクとデコードタスクを停止し、待ち受け状態に遷移する。
また、子機Ａのユーザが発呼中に発呼を取りやめた場合は、次のようになる。
ステップＥ−８
プロトコル処理部１１７は「ＣＡＮＣＥＬ」メッセージを受信し、呼制御部１１６に通知する。呼制御部１１６はリンガーを停止し、子機Ａに「ＣＡＮＣＥＬ−ＯＫ」メッセージを送信するようプロトコル処理部１１７に要求し、待ち受け状態に遷移する。
プロトコル処理部１１７は「ＣＡＮＣＥＬ」メッセージを受信し、呼制御部１１６に通知する。呼制御部１１６はリンガーを停止し、子機Ａに「ＣＡＮＣＥＬ−ＯＫ」メッセージを送信するようプロトコル処理部１１７に要求し、待ち受け状態に遷移する。
次に、プロトコル処理タスクの動作について図１２のフローチャートに従って説明する。
ステップＳ１２１
プロトコル処理部１１７は、エンコードタスク、デコードタスク、呼制御タスクから、送信要求があるかどうかを調べる。あれば、ステップＳ１２２へ、なければ、ステップＳ１２３へ進む。
プロトコル処理部１１７は、エンコードタスク、デコードタスク、呼制御タスクから、送信要求があるかどうかを調べる。あれば、ステップＳ１２２へ、なければ、ステップＳ１２３へ進む。
ステップＳ１２２
プロトコル処理部１１７は、送信要求を受け付けて、各プロトコルにしたがってヘッダを付加し、送信パケットキュー１１１に入れる。送信パケットキュー１１１はあて先ごとに用意されている。ここであて先とは、ＩＥＥＥ８０２．１１で規定されている送信先ＭＡＣアドレスである。このとき、この送信要求を受け付けた時刻を、ＲＴＣ１０８を参照して、送信要求と対応付けて書き込む。ステップＳ１２１に進む。
プロトコル処理部１１７は、送信要求を受け付けて、各プロトコルにしたがってヘッダを付加し、送信パケットキュー１１１に入れる。送信パケットキュー１１１はあて先ごとに用意されている。ここであて先とは、ＩＥＥＥ８０２．１１で規定されている送信先ＭＡＣアドレスである。このとき、この送信要求を受け付けた時刻を、ＲＴＣ１０８を参照して、送信要求と対応付けて書き込む。ステップＳ１２１に進む。
ここでは、音声パケットをエンコードタスクから受け取ったとして、説明する。プロトコル処理部１１７は、音声パケットにＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダ、ＬＬＣヘッダを付加し、あて先のＭＡＣアドレスを決定する（通常、あて先はＩＰアドレスで与えられており、プロトコル処理部１１７はこれをＭＡＣアドレスに変換する。詳細は、通常のＴＣＰ／ＩＰの通信処理と同様なので省略する。）。プロトコル処理部１１７は、ＭＡＣアドレスごとに用意された送信パケットキュー１１１の中から音声パケットのあて先のＭＡＣアドレスを持った送信パケットキューを選択し、音声パケットを送信パケットキュー１１１に入れる。このとき、ＲＴＣ１０８を参照し、送信要求受付時刻として、送信パケットキューに書き込む。ステップＳ１２１へ進む。
ステップＳ１２３
プロトコル処理部１１７は、受信パケットキュー１１３にデータが届いているかどうか確認する。届いていればステップＳ１２４へ、さもなければ、ステップＳ１２１へ進む。
プロトコル処理部１１７は、受信パケットキュー１１３にデータが届いているかどうか確認する。届いていればステップＳ１２４へ、さもなければ、ステップＳ１２１へ進む。
ステップＳ１２４
プロトコル処理部１１７は受信パケットキュー１１３から受信データを取り出す。
プロトコル処理部１１７は受信パケットキュー１１３から受信データを取り出す。
ステップＳ１２５
データのあて先を確認する。あて先がデコードタスクであれば、デコードタスクへ、呼制御タスクであれば、呼制御タスクへ通知する。ステップＳ１２１へ進む。
データのあて先を確認する。あて先がデコードタスクであれば、デコードタスクへ、呼制御タスクであれば、呼制御タスクへ通知する。ステップＳ１２１へ進む。
次に、無線送信タスクの動作を図１３のフローチャートに従って説明する。
なお、本実施の形態では無線送信タスクは、子機、親機ともに同一の処理を行う。送信パケットキュー１１１はあて先のＭＡＣアドレスごとに存在し、無線送信タスクは以下の処理を送信パケットキュー１１１ごとに行う。但し、以下の説明では、ひとつの送信パケットキュー１１１に注目してその動作を説明する。
ステップＳ１３１
制御部１３０は送信パケットキュー１１１を参照して、キューが空かどうかを判断する。空ならば、ステップＳ１３１へ、さもなければステップＳ１３２へ進む。
制御部１３０は送信パケットキュー１１１を参照して、キューが空かどうかを判断する。空ならば、ステップＳ１３１へ、さもなければステップＳ１３２へ進む。
ステップＳ１３２
制御部１３０は無線通信部１０７に送信可能かどうかを問い合わせる。具体的には、無線通信部１０７が、現在通信を行っている周波数の電波が存在するかどうかを判断し、さらに、あらかじめ決められた時間、電波が存在しないことを、ＲＴＣ１０８を参照しながら確認する。前述の時間を経過しても電波が検出されなかった場合は、送信可能と判断し、制御部１３０に送信可能であることを通知する。また、前述の時間内に電波が検出された場合は、送信不可能として制御部１３０に通知する。送信可能であれば、ステップＳ１３３へ、送信不可能であればステップＳ１３１へ進む。
制御部１３０は無線通信部１０７に送信可能かどうかを問い合わせる。具体的には、無線通信部１０７が、現在通信を行っている周波数の電波が存在するかどうかを判断し、さらに、あらかじめ決められた時間、電波が存在しないことを、ＲＴＣ１０８を参照しながら確認する。前述の時間を経過しても電波が検出されなかった場合は、送信可能と判断し、制御部１３０に送信可能であることを通知する。また、前述の時間内に電波が検出された場合は、送信不可能として制御部１３０に通知する。送信可能であれば、ステップＳ１３３へ、送信不可能であればステップＳ１３１へ進む。
ステップＳ１３３
制御部１３０は送信パケットキュー１１１の最初のエントリに注目する。
制御部１３０は送信パケットキュー１１１の最初のエントリに注目する。
ステップＳ１３４
制御部１３０は、エラー率判定部１１９にエラー率があらかじめ設定された閾値よりエラー率が低いかどうかを問い合わせる。エラー率判定部１１９は、制御部１３０に判定結果を渡す。受け取った判定結果から、エラー率が低い場合はステップＳ１４３へ、さもなければステップＳ１３５へ進む。
制御部１３０は、エラー率判定部１１９にエラー率があらかじめ設定された閾値よりエラー率が低いかどうかを問い合わせる。エラー率判定部１１９は、制御部１３０に判定結果を渡す。受け取った判定結果から、エラー率が低い場合はステップＳ１４３へ、さもなければステップＳ１３５へ進む。
ここでは、エラー率が高いものとして説明を続ける。
ステップＳ１３５
制御部１３０は送信パケットキュー１１１を参照して、エントリの数が１より大きいかどうかを判断する。１より大きい場合はステップＳ１３６へ、さもなければ、ステップＳ１３１へ進む。
制御部１３０は送信パケットキュー１１１を参照して、エントリの数が１より大きいかどうかを判断する。１より大きい場合はステップＳ１３６へ、さもなければ、ステップＳ１３１へ進む。
ステップＳ１３６
制御部１３０は、送信パケットキュー１１１から注目中のエントリのデータを取り出す。
制御部１３０は、送信パケットキュー１１１から注目中のエントリのデータを取り出す。
ステップＳ１３７
制御部１３０は、ステップＳ１３６で取り出されたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
制御部１３０は、ステップＳ１３６で取り出されたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
ステップＳ１３８
制御部１３０は、次のエントリに注目する。
制御部１３０は、次のエントリに注目する。
ステップＳ１３９
制御部１３０は、注目中のエントリのデータをコピーする。ここでは、送信パケットキュー１１１からエントリを取り出さずに、データのコピーのみを行う。
制御部１３０は、注目中のエントリのデータをコピーする。ここでは、送信パケットキュー１１１からエントリを取り出さずに、データのコピーのみを行う。
ステップＳ１４０
制御部１３０は、ステップＳ１３９でコピーしたデータ、あるいはステップＳ１４３で取り出されたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
制御部１３０は、ステップＳ１３９でコピーしたデータ、あるいはステップＳ１４３で取り出されたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
ステップＳ１４１
ここでは無線フレームはＩＥＥＥ８０２．１１ｉで規定された暗号化方式によって暗号化されるものとする。制御部１３０は、無線通信部１０７にＣＣＭＰヘッダとＭＩＣキーを付加するよう指示する。すると、無線通信部１０７は、暗号化アルゴリズムにしたがってＣＣＭＰヘッダとＭＩＣキーを計算し、送信バッファ１０５のＩＥＥＥ８０２．１１ｉで規定されたペイロードの位置に追加する。
ここでは無線フレームはＩＥＥＥ８０２．１１ｉで規定された暗号化方式によって暗号化されるものとする。制御部１３０は、無線通信部１０７にＣＣＭＰヘッダとＭＩＣキーを付加するよう指示する。すると、無線通信部１０７は、暗号化アルゴリズムにしたがってＣＣＭＰヘッダとＭＩＣキーを計算し、送信バッファ１０５のＩＥＥＥ８０２．１１ｉで規定されたペイロードの位置に追加する。
ステップＳ１４２
制御部１３０は、無線通信部１０７に送信バッファ１０５の内容を送信するよう指示する。すると、無線通信部１０７は指示された内容を無線フレームとして空中に放出する。ステップＳ１３１へ進む。
制御部１３０は、無線通信部１０７に送信バッファ１０５の内容を送信するよう指示する。すると、無線通信部１０７は指示された内容を無線フレームとして空中に放出する。ステップＳ１３１へ進む。
このようにして、２つの音声パケットパケットはひとつの無線フレームにまとめられる。また、ステップＳ１３４でエラー率が低いと判断された場合は、次のようになる。
ステップＳ１４３
ステップＳ１３６と同様の処理を行う。ステップＳ１４０へ進むという流れになる。この場合は、従来の無線ＬＡＮと同様、パケットをそのままひとつの無線フレームとして送信する処理となる。
ステップＳ１３６と同様の処理を行う。ステップＳ１４０へ進むという流れになる。この場合は、従来の無線ＬＡＮと同様、パケットをそのままひとつの無線フレームとして送信する処理となる。
次に、マージ処理の詳細を図１４のフローチャートに従って説明する。
ここでは、制御部１３０によって送信すべきデータがペイロード統合部１１２に渡されているものとして説明する。
ステップＳ１５１
ペイロード統合部１１２は、送信バッファ１０５にデータが書き込まれているかどうかを判断する。書き込まれていればステップＳ１５７へ、さもなければ、ステップＳ１５２へ進む。
ペイロード統合部１１２は、送信バッファ１０５にデータが書き込まれているかどうかを判断する。書き込まれていればステップＳ１５７へ、さもなければ、ステップＳ１５２へ進む。
ステップＳ１５２
ペイロード統合部１１２は送信バッファ１０５にＭＡＣヘッダを書き込む。
ペイロード統合部１１２は送信バッファ１０５にＭＡＣヘッダを書き込む。
ステップＳ１５３
ペイロード統合部１１２は上位プロトコル解析部１１８にエントリの内容を渡す。すると、上位プロトコル解析部１１８は、パケット内の上位プロトコル（ここでは、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰ）のプロトコルヘッダを認識し、各レイヤのヘッダを記憶する。もし、すでに、以前の上位プロトコルのヘッダを記憶していた場合は上書きする。
ペイロード統合部１１２は上位プロトコル解析部１１８にエントリの内容を渡す。すると、上位プロトコル解析部１１８は、パケット内の上位プロトコル（ここでは、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰ）のプロトコルヘッダを認識し、各レイヤのヘッダを記憶する。もし、すでに、以前の上位プロトコルのヘッダを記憶していた場合は上書きする。
ステップＳ１５４
ペイロード統合部１１２は、受け取った音声パケットの合計バイト数を算出する。ここでは、ＬＬＣヘッダ（８バイト）＋ＩＰｖ６ヘッダ（４０バイト）＋ＵＤＰヘッダ（８バイト）＋ＲＴＰヘッダ（１２バイト）＋音声（８０バイト）＝１４８バイトとなる。
ペイロード統合部１１２は、受け取った音声パケットの合計バイト数を算出する。ここでは、ＬＬＣヘッダ（８バイト）＋ＩＰｖ６ヘッダ（４０バイト）＋ＵＤＰヘッダ（８バイト）＋ＲＴＰヘッダ（１２バイト）＋音声（８０バイト）＝１４８バイトとなる。
ステップＳ１５５
ペイロード統合部１１２はステップＳ１５４で得られた合計バイト数をペイロードデリミタ１として送信バッファ１０５に書き込む。ここでは１４８を書き込む。
ペイロード統合部１１２はステップＳ１５４で得られた合計バイト数をペイロードデリミタ１として送信バッファ１０５に書き込む。ここでは１４８を書き込む。
ステップＳ１５６
ペイロード統合部１１２は音声パケットとして受け取ったデータを送信バッファ１０５に書き込む。マージ処理を終了する。
ペイロード統合部１１２は音声パケットとして受け取ったデータを送信バッファ１０５に書き込む。マージ処理を終了する。
ステップＳ１５７
ペイロード統合部１１２は上位プロトコル解析部１１８にエントリの内容を渡す。すると、上位プロトコル解析部１１８は、パケット内の上位プロトコル（ここでは、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰ）のプロトコルヘッダを認識し、ステップＳ１５３で記憶していた内容と比較する。上位プロトコル解析部１１８はヘッダを解析した結果をペイロード統合部１１２に渡す。ここでは、ＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダが冗長であることをペイロード統合部１１２に知らせる。
ペイロード統合部１１２は上位プロトコル解析部１１８にエントリの内容を渡す。すると、上位プロトコル解析部１１８は、パケット内の上位プロトコル（ここでは、ＬＬＣ、ＩＰ、ＵＤＰ、ＲＴＰ）のプロトコルヘッダを認識し、ステップＳ１５３で記憶していた内容と比較する。上位プロトコル解析部１１８はヘッダを解析した結果をペイロード統合部１１２に渡す。ここでは、ＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダが冗長であることをペイロード統合部１１２に知らせる。
ステップＳ１５８
ペイロード統合部１１２は、冗長なヘッダを省略すると送信すべきデータの合計バイト数がいくらになるかを計算する。ここでは、冗長なヘッダがどれかを示すフラグ１バイトと省略できないＲＴＰヘッダ１２バイトと音声データ８０バイトの合計９３を算出する。
ペイロード統合部１１２は、冗長なヘッダを省略すると送信すべきデータの合計バイト数がいくらになるかを計算する。ここでは、冗長なヘッダがどれかを示すフラグ１バイトと省略できないＲＴＰヘッダ１２バイトと音声データ８０バイトの合計９３を算出する。
ステップＳ１５９
ペイロード統合部１１２は、ステップＳ１５８で算出した値をペイロードデリミタとして送信バッファ１０５に書き込む。ここでは９３が書き込まれる。
ペイロード統合部１１２は、ステップＳ１５８で算出した値をペイロードデリミタとして送信バッファ１０５に書き込む。ここでは９３が書き込まれる。
ステップＳ１６０
次に、ペイロード統合部１１２は冗長なヘッダがどれかを示すフラグ１バイトを送信バッファ１０５に書き込む。ここではフラグは、ＯＳＩのレイヤモデルにしたがって、第２層、第３層、第４層、第５〜７層をおのおの２ビットで表現しており、００は「もともと対応するヘッダがなかった」、０１は「ヘッダがあったが冗長なので省略した」、１０「省略できなかった」を表すものとする。ここでは、ＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダは省略可能で、ＲＴＰヘッダは省略できないため、フラグの値は０１０１０１１０となる。
次に、ペイロード統合部１１２は冗長なヘッダがどれかを示すフラグ１バイトを送信バッファ１０５に書き込む。ここではフラグは、ＯＳＩのレイヤモデルにしたがって、第２層、第３層、第４層、第５〜７層をおのおの２ビットで表現しており、００は「もともと対応するヘッダがなかった」、０１は「ヘッダがあったが冗長なので省略した」、１０「省略できなかった」を表すものとする。ここでは、ＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダは省略可能で、ＲＴＰヘッダは省略できないため、フラグの値は０１０１０１１０となる。
ステップＳ１６１
ペイロード統合部１１２は、省略できなかったヘッダと音声データを送信バッファ１０５に書き込む。マージ処理を終了する。
ペイロード統合部１１２は、省略できなかったヘッダと音声データを送信バッファ１０５に書き込む。マージ処理を終了する。
ここでは、続いてＲＴＰヘッダ１２バイトと音声データ８０バイトを送信バッファ１０５に書き込む。
図１５は本実施の形態との比較として、ＩＥＥＥ ８０２．１１の無線フレーム・フォーマットを使って音声パケットをひとつだけ送信した場合を示している。また、図１６は本実施の形態によって２つの音声パケットがひとつの無線フレームにまとめられたときの無線フレームのフォーマットを示している。
まず、無線通信部１０７に内蔵された暗号化エンジンによってＣＣＭＰヘッダが書き込まれ、ＭＩＣキーが付加された後、ＰＬＣＰプリアンブル、ＰＬＣＰヘッダおよびＦＣＳを無線通信部１０７が無線フレームを生成するときに付加する。図１５、図１６の比較より、本来２つの音声パケットを２つの無線フレームで送信せずに、１つの無線フレームにまとめると、フレーム長は２５％大きくなるだけなので、伝送効率が大幅に下げることなく、冗長な音声パケットを送信することができることがわかる。これにより、途中の無線フレームの１つがエラーによって喪失しても、前後の無線フレームには喪失した音声パケットが含まれているので、音声を遅延させる再送を行わずに、音声パケットを受信側で復元することができる。
次に、無線受信タスクの動作を図１７のフローチャートに従って説明する。
ここで、自局宛の無線フレームは無線通信部１０７によって受信され、暗号が解除された状態で受信バッファ１０４にフレームの内容がデータとして書き込まれているものとする。すなわち、ＣＣＭＰヘッダとＭＩＣキーは取り除かれているものとする。また、ここでは、自局宛の無線フレーム以外は無線通信部によって無視されているものとする。すなわち、受信バッファに書き込まれるデータは自局宛のものに限るものとする。
ステップＳ１７１
ペイロード分割部１１４は受信バッファ１０４を参照してデータを受信しているかどうかを判断する。受信していればステップＳ１７２へ、さもなければ、ステップＳ１７１へ進む。
ペイロード分割部１１４は受信バッファ１０４を参照してデータを受信しているかどうかを判断する。受信していればステップＳ１７２へ、さもなければ、ステップＳ１７１へ進む。
ステップＳ１７２
ペイロード分割部１１４は受信バッファ１０４からデータをとりだす。
ペイロード分割部１１４は受信バッファ１０４からデータをとりだす。
ステップＳ１７３
ペイロード分割部１１４は、ＭＡＣヘッダを取り出す。
ペイロード分割部１１４は、ＭＡＣヘッダを取り出す。
ステップＳ１７４
ペイロード分割部１１４は最初のペイロードに注目する。
ペイロード分割部１１４は最初のペイロードに注目する。
ステップＳ１７５
ペイロード分割部１１４は次の１バイトをデリミタと解釈し、値を読み出し、ペイロードが何バイトかを得て、そのバイト数分だけペイロードとして切り出す。
ペイロード分割部１１４は次の１バイトをデリミタと解釈し、値を読み出し、ペイロードが何バイトかを得て、そのバイト数分だけペイロードとして切り出す。
ステップＳ１７６
ペイロード分割部１１４は、ステップＳ１７５で得たペイロードを上位プロトコル解析部１１８に渡す。すると、上位プロトコル解析部１１８は、第２層、第３層、第４層、第５〜７層でのヘッダを解釈し、ペイロード分割部１１４に通知する。ここではＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダと解釈できたとする。上位プロトコル解析部１１８はそれぞれのレイヤごとにヘッダを記憶する。
ペイロード分割部１１４は、ステップＳ１７５で得たペイロードを上位プロトコル解析部１１８に渡す。すると、上位プロトコル解析部１１８は、第２層、第３層、第４層、第５〜７層でのヘッダを解釈し、ペイロード分割部１１４に通知する。ここではＬＬＣヘッダ、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダと解釈できたとする。上位プロトコル解析部１１８はそれぞれのレイヤごとにヘッダを記憶する。
ステップＳ１７７
ペイロード分割部１１４は、得られたペイロードを受信パケットキュー１１３に入れる。
ペイロード分割部１１４は、得られたペイロードを受信パケットキュー１１３に入れる。
ステップＳ１７８
ペイロード分割部１１４は、受信バッファ１０４を参照して、すべてのペイロードを切り出したかどうか判断する。すべてのペイロードの切り出しが終わっていれば、ステップＳ１７１へ、さもなければ、ステップＳ１７９へ進む。
ペイロード分割部１１４は、受信バッファ１０４を参照して、すべてのペイロードを切り出したかどうか判断する。すべてのペイロードの切り出しが終わっていれば、ステップＳ１７１へ、さもなければ、ステップＳ１７９へ進む。
ステップＳ１７９
ペイロード分割部１１４は、受信バッファ１０４を参照して、次のペイロードに注目する。
ペイロード分割部１１４は、受信バッファ１０４を参照して、次のペイロードに注目する。
ステップＳ１８０
ペイロード分割部１１４は、受信バッファ１０４中の次の１バイトをデリミタと解釈し、値を読み出し、注目中のペイロードが何バイトかを得て、そのバイト数分だけペイロードとして切り出す。
ペイロード分割部１１４は、受信バッファ１０４中の次の１バイトをデリミタと解釈し、値を読み出し、注目中のペイロードが何バイトかを得て、そのバイト数分だけペイロードとして切り出す。
ステップＳ１８１
ペイロード分割部１１４は、次の１バイトを省略フラグと解釈し、どのレイヤのヘッダが省略されているかを判断する。さらに、省略されているヘッダに対しては、ステップＳ１７６で記憶しているヘッダの内容からヘッダを復元するよう上位プロトコル解析部１１８に指示する。すると、上位プロトコル解析部１１８は、ペイロードとステップＳ１７６で記憶した内容を比較し、各レイヤのヘッダを復元する。ここでは、ＩＰヘッダとＵＤＰヘッダにはチェックサムが含まれるため、ペイロードの内容からチェックサムを計算し、ヘッダとして復元する。以上で、ヘッダが省略される前の音声パケット全体が復元されたことになる。ステップＳ１７７へ進む。
ペイロード分割部１１４は、次の１バイトを省略フラグと解釈し、どのレイヤのヘッダが省略されているかを判断する。さらに、省略されているヘッダに対しては、ステップＳ１７６で記憶しているヘッダの内容からヘッダを復元するよう上位プロトコル解析部１１８に指示する。すると、上位プロトコル解析部１１８は、ペイロードとステップＳ１７６で記憶した内容を比較し、各レイヤのヘッダを復元する。ここでは、ＩＰヘッダとＵＤＰヘッダにはチェックサムが含まれるため、ペイロードの内容からチェックサムを計算し、ヘッダとして復元する。以上で、ヘッダが省略される前の音声パケット全体が復元されたことになる。ステップＳ１７７へ進む。
ここでは、フラグの値が０１０１０１１０であったとすると、フラグは、ＯＳＩのレイヤモデルにしたがって、第２層、第３層、第４層、第５〜７層をおのおの２ビットで表現しており、００は「もともと対応するヘッダがなかった」、０１は「ヘッダがあったが冗長なので省略した」、１０「省略できなかった」を表すので、それぞれ、ＬＬＣヘッダは省略、ＩＰヘッダ省略、ＵＤＰヘッダ省略、ＲＴＰヘッダ省略なし、と解釈できる。したがって、今注目しているフラグから後ろはＲＴＰヘッダとして解釈し、省略されているヘッダに関してはステップＳ１７６で記憶した内容に基づき復元する。さらに、ＩＰヘッダとＵＤＰヘッダに関してチェックサムを再計算し、ヘッダを復元する。
以上の処理によって、もともと２つの音声パケットがひとつの無線フレームにまとめられていても、正しくもとの音声パケットに分割され、プロトコル処理部１１７に渡される。
ここで、正常に通信が行われた場合、同じ音声パケットを２つ受信することになるが、ＲＴＰプロトコルでは、前述のデコードタスクの説明で示したとおり、デコードタスクが、ＲＴＰヘッダ内のタイムスタンプをチェックしながら、不要なパケットを破棄し、必要なパケットのみデコード処理し、音声として再生するので問題は無い。
次に、親機のタスクについて説明する。但し、無線受信タスクと無線送信タスクは子機と同一なので説明を省略する。
ブリッジタスクの処理について図１８のフローチャートに従って説明する。
ステップＳ１９１
有線−無線ブリッジ部１２０は、受信パケットキュー１１３にエントリがあるかどうかを判断する。エントリがあればステップＳ１９２へ、さもなければ、ステップＳ１９５へ進む。
有線−無線ブリッジ部１２０は、受信パケットキュー１１３にエントリがあるかどうかを判断する。エントリがあればステップＳ１９２へ、さもなければ、ステップＳ１９５へ進む。
ステップＳ１９２
有線−無線ブリッジ部１２０は、受信パケットキュー１１３からエントリを取り出す。
有線−無線ブリッジ部１２０は、受信パケットキュー１１３からエントリを取り出す。
ステップＳ１９３
有線−無線ブリッジ部１２０は、ステップＳ１９２で取り出したエントリの内容を参照して、ＬＡＮ側（有線）に中継する必要があるかどうかを判断する。この判断においてはＯＳＩ第２層のあて先を利用する。本実施例では、第２層はＩＥＥＥ８０２．１１で規定されているＭＡＣアドレスによって判断する。この判断のためのアドレスの学習方法などは、本発明の主旨と関係ないので割愛する。中継が必要な場合はステップＳ１９４へ、さもなければ、ステップＳ１９１へ進む。
有線−無線ブリッジ部１２０は、ステップＳ１９２で取り出したエントリの内容を参照して、ＬＡＮ側（有線）に中継する必要があるかどうかを判断する。この判断においてはＯＳＩ第２層のあて先を利用する。本実施例では、第２層はＩＥＥＥ８０２．１１で規定されているＭＡＣアドレスによって判断する。この判断のためのアドレスの学習方法などは、本発明の主旨と関係ないので割愛する。中継が必要な場合はステップＳ１９４へ、さもなければ、ステップＳ１９１へ進む。
ステップＳ１９４
有線−無線ブリッジ部１２０は、ＩＥＥＥ８０２．１１のＭＡＣヘッダ形式をＩＥＥＥ８０２．３のＭＡＣヘッダの形式に変換し、ＬＡＮ通信部１０６よりエントリの内容を送信する。ステップＳ１９１へ進む。
有線−無線ブリッジ部１２０は、ＩＥＥＥ８０２．１１のＭＡＣヘッダ形式をＩＥＥＥ８０２．３のＭＡＣヘッダの形式に変換し、ＬＡＮ通信部１０６よりエントリの内容を送信する。ステップＳ１９１へ進む。
ステップＳ１９５
有線−無線ブリッジ部１２０はＬＡＮ通信部１０６に有線ＬＡＮからデータを受信しているかどうかを問い合わせる。受信していれば、ステップＳ１９６へ、さもなければ、ステップＳ１９１へ進む。
有線−無線ブリッジ部１２０はＬＡＮ通信部１０６に有線ＬＡＮからデータを受信しているかどうかを問い合わせる。受信していれば、ステップＳ１９６へ、さもなければ、ステップＳ１９１へ進む。
ステップＳ１９６
有線−無線ブリッジ部１２０はＬＡＮ通信部１０６から受信データを受け取る。
有線−無線ブリッジ部１２０はＬＡＮ通信部１０６から受信データを受け取る。
ステップＳ１９７
有線−無線ブリッジ部１２０は、ステップＳ１９６で取り出した受信データを無線ＬＡＮ側に中継する必要があるかどうかを判断する。中継するかどうかの判断の方法は従来のブリッジ処理と同様なので割愛する。中継する必要がある場合は、ステップＳ１９８へ、さもなければ、ステップＳ１９１へ進む。
有線−無線ブリッジ部１２０は、ステップＳ１９６で取り出した受信データを無線ＬＡＮ側に中継する必要があるかどうかを判断する。中継するかどうかの判断の方法は従来のブリッジ処理と同様なので割愛する。中継する必要がある場合は、ステップＳ１９８へ、さもなければ、ステップＳ１９１へ進む。
ステップＳ１９８
有線−無線ブリッジ部１２０は、ステップＳ１９６で取り出した受信データをＩＥＥＥ８０２．３のＭＡＣヘッダの形式からＩＥＥＥ８０２．１１のＭＡＣヘッダの形式に変換し、送信パケットキュー１１１に入れる。ステップＳ１９１へ進む。
有線−無線ブリッジ部１２０は、ステップＳ１９６で取り出した受信データをＩＥＥＥ８０２．３のＭＡＣヘッダの形式からＩＥＥＥ８０２．１１のＭＡＣヘッダの形式に変換し、送信パケットキュー１１１に入れる。ステップＳ１９１へ進む。
図１９は、本実施の形態において音声パケットがどのように送信されるかを示している。
図１９では、無線フレームＡに音声パケット１と音声パケット２が、無線フレームＢに音声パケット２と音声パケット３が、無線フレームＣに音声パケット３と音声パケット４が、それぞれひとつにまとめられて送信されている。
図２０では、無線フレームＢが通信エラーとなり喪失した場合を示している。受信側は、無線フレームＡと無線フレームＣによって、音声パケット１、音声パケット２、音声パケット３、音声パケット４を受信することができる。したがって、無線フレームＢを再送する必要は無い。
以上のように、従来、エラーの発生によって、再送を余儀なくされ、その分、以降の音声の到着時刻が遅延して、さらに、この遅延が蓄積することによって、受信端末側がジッターバッファのオーバーフローを起こし、音声の途切れなどの品質低下が引き起こされていたが、本実施例１によれば、上記の構成により、音声パケットを冗長化して送信するので、エラーが発生しても、再送することなしに、もとの音声を復元することができる。
また、音声パケットをまとめてひとつの無線フレームとして送信するので、帯域を必要以上に圧迫しない。さらに、音声パケットを解析して、不要なヘッダを省略してひとつの無線フレームにまとめるため、１フレームあたりのデータ量を削減できる。このことにより、無線ＬＡＮ電話の利用者に対しては、品質のよい通話環境を提供し、また、同じ無線ＬＡＮ内でデータ通信を行っているユーザに対して、必要以上に帯域を圧迫せず、良好な通信環境を提供できる。
なお、本実施の形態では、エラーが発生した場合に再送を行わないことを前提にしているが、再送回数を従来よりも少なくしても、本発明の主旨になんら変わりなく、十分な効果が得られる。
（実施の形態２）
図２１は、本発明の実施の形態２における子機の機能ブロック図である。
図２１は、本発明の実施の形態２における子機の機能ブロック図である。
図２１において、１０１は、発呼先の指定、着呼時に通話の指示および終話の指示をするための操作部、１０２は、音声を入力するための音声入力部、１０３は、音声を出力するための音声出力部、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファである。
１０７は、前記送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を前記受信バッファ１０４に格納する無線通信部、１０８は、時間の経過を測定するためのＲＴＣ、１０９は、音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量を記憶するパラメータ記憶部である。
１１０は、前記音声入力部１０２から入力した音声をＡ／Ｄ変換し、所定のアルゴリズムを用いて音声パケットに変換（エンコード）する、また、音声データを所定のアルゴリズムを用いてデコードした上で、Ｄ／Ａ変換し、前記音声出力部１０３に出力するコーデック部、１１１は、前記コーデック部１１０がエンコードした音声パケットをエンコードが完了した時刻、すなわち、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキュー、１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部である。
１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキュー、１１４は、前記受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、前記受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。
１１５は、前記パラメータ記憶部１０９に記憶された音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量を参照し、ＲＴＣ１０８の値を送信要求受付時刻と比較し、送信待ちの許容時間を算出する、送信待ち許容時間算出部である。
１１６は、発呼、着呼、呼の接続・切断の制御、および、各呼の状態に応じたダイヤルトーン、ビジートーン、リンガー、リング・バック・トーンを前記音声出力部１０３に出力する呼制御部、１１７は、呼の設定や解除、通話時の音声パケットの送受信、を指定されたプロトコルに従って処理するプロトコル処理部、１２１は、ネットワークの遅延を測定する、ネットワーク遅延測定部、１３０は、全体を制御する制御部である。
上記図２１の構成と図２の構成との対応関係について説明する。
１０１の操作部は、２１１のキーボードによって、１０２の音声入力部は、２０８のマイクによって、１０３の音声出力部は、２１０のスピーカによって実現される。
１０４の受信バッファ、１０５の送信バッファ、１０９のパラメータ記憶部、１１１の送信パケットキュー、１１３の受信パケットキューは、２０３のＲＡＭによって、実現される。
１０７の無線通信部は、２０５のベースバンドと２０６のＲＦによって、１０８のＲＴＣは、２０４のＲＴＣによって、１１０のコーデック部は、２１２のコーデック、２０７のＡ／Ｄ、２０９のＤ／Ａによって、それぞれ実現される。
１１２のペイロード統合部、１１４のペイロード分割部、１１５の送信待ち許容時間算出部、１２１のネットワーク遅延測定部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって実現される。
図２２は、本発明の実施の形態２における親機の機能ブロック図である。
図２２において、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファ、１０６は、有線のネットワークと接続するためのＬＡＮ通信部、１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部である。
１０８は、時間の経過を測定するためのＲＴＣ、１１１は、後述する有線−無線ブリッジ部１２０が、中継が必要と判断したＬＡＮ側からのイーサネット（登録商標）フレームを無線フレーム化して送信するために、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキュー、１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部である。
１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキュー、１１４は、受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。
１２０は、有線と無線の間のフレームを必要があれば中継し、さもなければ破棄する、有線−無線ブリッジ部、１３０は、全体を制御する、制御部である。
上記図２２の構成と図４の構成との対応関係について説明する。
１０４の受信バッファ、１０５の送信バッファ、１１１の送信パケットキュー、１１３の受信パケットキューは、２０３のＲＡＭによって、実現される。
１０７の無線通信部は、２０５のベースバンドと２０６のＲＦによって、１０８のＲＴＣは、２０４のＲＴＣによって、１０６のＬＡＮ通信部は、２１３のネットワークＩ／Ｆによって、それぞれ実現される。
１１２のペイロード統合部、１１４のペイロード分割部、１２０の有線−無線ブリッジ部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって、実現される。
無線ＬＡＮ電話システム全体の構成および親機と子機の動作概要は実施の形態１と変わらないので説明を省略する。
まず、子機の動作について説明する。
図２３は、子機のタスク構成を示している。図７と比較して、測定タスクがあらたに追加されている。一方、親機については、タスク構成は実施の形態例１（図８）と同様である。
次に、子機のタスクについてその動作を説明する。なお、子機のタスクのうち、エンコードタスク、デコードタスク、呼制御タスクは実施の形態１と同一なので説明を省略する。
ここでは、実施の形態１との相違点となる測定タスクについて、図２４のフローチャートに従って、説明する。
ここでは、実施の形態１との相違点となる測定タスクについて、図２４のフローチャートに従って、説明する。
本実施の形態では、通話を行う子機同士があらかじめ別の方法でお互いのＲＴＣ１０８をあわせていることを前提にしている。お互いの時計を合わせる方法としてはＧＰＳを用いる方法や、ＮＴＰと呼ばれるプロトコルを用いる方法が一般的であるが、ここでは詳細を記述しない。
ステップＳ２１１
ネットワーク遅延測定部１２１は受信パケットキュー１１３を参照して、測定パケットが届いているかどうかを判断する。届いていればステップＳ２１２へ、さもなければ、Ｓ２１４へ進む。
ネットワーク遅延測定部１２１は受信パケットキュー１１３を参照して、測定パケットが届いているかどうかを判断する。届いていればステップＳ２１２へ、さもなければ、Ｓ２１４へ進む。
ステップＳ２１２
ネットワーク遅延測定部１２１は、受信パケットキュー１１３から、パケットを取り出す。
ネットワーク遅延測定部１２１は、受信パケットキュー１１３から、パケットを取り出す。
ステップＳ２１３
ネットワーク遅延測定部１２１は、取り出したパケットの中身を参照して、そのパケットがいつ送信されたかを読み取り、ＲＴＣ１０８を参照して、現在の時刻と比較する。その結果をネットワークの遅延量としてパラメータ記憶部１０９に書き込む。ステップＳ２１１へ進む。ここでは、パケットに書かれた時刻が１２：３３ １２．６５４ ２２３だったとする。現在、ＲＴＣ１０８が１２：３３ １２．７３４ ２２３を示しているとすると時間差は８０ｍｓとなり、これをパラメータ記憶部１０９にネットワーク遅延量として書き込む。ステップＳ２１１へ進む。
ネットワーク遅延測定部１２１は、取り出したパケットの中身を参照して、そのパケットがいつ送信されたかを読み取り、ＲＴＣ１０８を参照して、現在の時刻と比較する。その結果をネットワークの遅延量としてパラメータ記憶部１０９に書き込む。ステップＳ２１１へ進む。ここでは、パケットに書かれた時刻が１２：３３ １２．６５４ ２２３だったとする。現在、ＲＴＣ１０８が１２：３３ １２．７３４ ２２３を示しているとすると時間差は８０ｍｓとなり、これをパラメータ記憶部１０９にネットワーク遅延量として書き込む。ステップＳ２１１へ進む。
ステップＳ２１４
ネットワーク遅延測定部１２１は、ＲＴＣ１０８を参照して送信予定時刻になったかどうかを判断する。予定時刻になっていれば、次の送信予定時刻を設定して、ステップＳ２１５へ、さもなければ、ステップＳ２１１へ進む。ここでは、測定パケットの送信は５秒に一度とする。したがって、現在のＲＴＣ１０８の値が１２：３３ １７．２５５ １０９であるとすれば、送信予定時刻は、５秒後の１２：３３ ２２．２５５ １０９となる。
ネットワーク遅延測定部１２１は、ＲＴＣ１０８を参照して送信予定時刻になったかどうかを判断する。予定時刻になっていれば、次の送信予定時刻を設定して、ステップＳ２１５へ、さもなければ、ステップＳ２１１へ進む。ここでは、測定パケットの送信は５秒に一度とする。したがって、現在のＲＴＣ１０８の値が１２：３３ １７．２５５ １０９であるとすれば、送信予定時刻は、５秒後の１２：３３ ２２．２５５ １０９となる。
ステップＳ２１５
ネットワーク遅延測定部１２１は、ＲＴＣ１０８を参照して、現在の時刻１２：３３ １７．２５５ １０９を読み取り、これをパケットの内容として送信パケットキュー１１１に入れる。ステップＳ２１１へ進む。
ネットワーク遅延測定部１２１は、ＲＴＣ１０８を参照して、現在の時刻１２：３３ １７．２５５ １０９を読み取り、これをパケットの内容として送信パケットキュー１１１に入れる。ステップＳ２１１へ進む。
このように、子機がお互いに、測定パケットを交換することによって、ネットワークの遅延量を測定し、これを基に無線送信タスクで「いくつの音声パケットをひとつの無線フレームにまとめるか」を決定する（詳細は後述）。これにより、ネットワークのトラフィックに変動が起こってネットワーク遅延量が変化しても、音声の遅延許容時間の範囲内で音声パケットを冗長化することができるので、安定した通話を確保できる。
図２５は、本発明の実施の形態２における子機の無線送信タスクのフローチャートである。送信パケットキュー１１１はあて先のＭＡＣアドレスごとに存在し、無線送信タスクは以下の処理を送信パケットキュー１１１ごとに行う。但し、以下の説明では、ひとつの送信パケットキュー１１１に注目してその動作を説明する。
ステップＳ２２１〜Ｓ２２３
実施の形態１における図１３のステップＳ１３１〜Ｓ１３３と同一の処理を行う。
実施の形態１における図１３のステップＳ１３１〜Ｓ１３３と同一の処理を行う。
ステップＳ２２４
制御部１３０は、注目中のエントリに関して、送信待ち許容時間算出部１１５に、送信待ち許容時間を算出するよう要求する。すると、送信待ち許容時間算出部１１５はパラメータ記憶部１０９とＲＴＣ１０８とエントリと対応付けて記録された送信要求受付時刻とを参照し、遅延許容時間を算出する。まず、ＲＴＣ１０８と注目中のエントリの送信要求受付時刻から送信待ち時間（送信要求を受け付けてからどれくらい時間が経過しているか）を求める。ここでは以下の値であるとする。
制御部１３０は、注目中のエントリに関して、送信待ち許容時間算出部１１５に、送信待ち許容時間を算出するよう要求する。すると、送信待ち許容時間算出部１１５はパラメータ記憶部１０９とＲＴＣ１０８とエントリと対応付けて記録された送信要求受付時刻とを参照し、遅延許容時間を算出する。まず、ＲＴＣ１０８と注目中のエントリの送信要求受付時刻から送信待ち時間（送信要求を受け付けてからどれくらい時間が経過しているか）を求める。ここでは以下の値であるとする。
ＲＴＣ＝１２：３３ ２２．０４３ ９９４
送信要求受付時刻＝１２：３３ ２２．００８ ８７６
ゆえに、送信待ち時間＝ＲＴＣ−送信要求受付時刻＝３５ｍｓとなる。
さらに、以下の値、
コーデック周期＝１０ｍｓ
コーデック遅延＝１ｍｓ
ネットワーク遅延＝８０ｍｓ
コーデック待ち時間＝１０ｍｓ
全体遅延許容時間＝１２０ｍｓ
がパラメータ記憶部１０９にあらかじめ、記憶されているものとする。なお、コーデック遅延とは、音声が入力されてからＡ／Ｄ変換されて、指定されたアルゴリズムによって（ここではμ則ＰＣＭ ８ｋＨｚ ８ビットサンプリングが指定されているものとする）エンコードされたデータが出てくるまでの時間であり、このデータをコーデック周期に相当する分だけ集めてはじめて音声フレームとすることができる。また、音声フレームをデコードしてＤ／Ａ変換して、音声として出力されるまでの遅延時間も同じ値としている。コーデックのアルゴリズムによってはこの遅延時間は非対称となることもあるが、ここでは対称であるとして説明を続ける。さらに、コーデック待ち時間とは受信側でジッターバッファを設けて、デコード待ちの音声パケットを一時的に貯めておき、パケットの到着が変動しても、音声が途切れないようにするための、時間である。ネットワーク遅延は、前述の測定タスクによって定期的に更新されているものとする。以上の値と次式によって送信待ち許容時間を計算する。
送信要求受付時刻＝１２：３３ ２２．００８ ８７６
ゆえに、送信待ち時間＝ＲＴＣ−送信要求受付時刻＝３５ｍｓとなる。
さらに、以下の値、
コーデック周期＝１０ｍｓ
コーデック遅延＝１ｍｓ
ネットワーク遅延＝８０ｍｓ
コーデック待ち時間＝１０ｍｓ
全体遅延許容時間＝１２０ｍｓ
がパラメータ記憶部１０９にあらかじめ、記憶されているものとする。なお、コーデック遅延とは、音声が入力されてからＡ／Ｄ変換されて、指定されたアルゴリズムによって（ここではμ則ＰＣＭ ８ｋＨｚ ８ビットサンプリングが指定されているものとする）エンコードされたデータが出てくるまでの時間であり、このデータをコーデック周期に相当する分だけ集めてはじめて音声フレームとすることができる。また、音声フレームをデコードしてＤ／Ａ変換して、音声として出力されるまでの遅延時間も同じ値としている。コーデックのアルゴリズムによってはこの遅延時間は非対称となることもあるが、ここでは対称であるとして説明を続ける。さらに、コーデック待ち時間とは受信側でジッターバッファを設けて、デコード待ちの音声パケットを一時的に貯めておき、パケットの到着が変動しても、音声が途切れないようにするための、時間である。ネットワーク遅延は、前述の測定タスクによって定期的に更新されているものとする。以上の値と次式によって送信待ち許容時間を計算する。
送信待ち許容時間＝全体遅延許容時間−コーデック周期−コーデック遅延×２
−ネットワーク遅延−コーデック待ち時間−送信待ち時間
図２６は上式を分かりやすく図示したものである。
−ネットワーク遅延−コーデック待ち時間−送信待ち時間
図２６は上式を分かりやすく図示したものである。
上式より注目しているエントリの送信待ち許容時間は−１７ｍｓとなる。ここで値が負であるということは、今から送信しても許容時間内に音声が到着しないことを示している。
送信待ち許容時間算出部１１５は制御部１３０に「送信待ち許容時間が−１７ｍｓである」ことを通知する。
ステップＳ２２５
制御部１３０が送信待ち許容時間算出部１１５から受け取った送信待ち許容時間が負の値を示している場合、つまり、今から送信しても間に合わない場合は、ステップＳ２２６へ、さもなければステップＳ２２９へ進む。ここでは、負の値を示しているのでステップＳ２２６へ進む。
制御部１３０が送信待ち許容時間算出部１１５から受け取った送信待ち許容時間が負の値を示している場合、つまり、今から送信しても間に合わない場合は、ステップＳ２２６へ、さもなければステップＳ２２９へ進む。ここでは、負の値を示しているのでステップＳ２２６へ進む。
ステップＳ２２６
制御部１３０は、送信パケットキュー１１１から注目中のエントリのデータを取り出す。
制御部１３０は、送信パケットキュー１１１から注目中のエントリのデータを取り出す。
上の例では、注目中のエントリは今から送信しても間に合わない、と判断されて、破棄されることになる。
ステップＳ２２７
制御部１３０は、送信パケットキュー１１１を参照して、注目中のエントリの次にエントリが存在するかどうかを判断する。存在すればステップＳ２２７へ、さもなければ、ステップＳ２２１へ進む。ここでは、図２７に示すように、エントリが存在するものとして説明を続ける。
制御部１３０は、送信パケットキュー１１１を参照して、注目中のエントリの次にエントリが存在するかどうかを判断する。存在すればステップＳ２２７へ、さもなければ、ステップＳ２２１へ進む。ここでは、図２７に示すように、エントリが存在するものとして説明を続ける。
ステップＳ２２８
制御部１３０は、次のエントリに注目する。ステップＳ２２４へ進む。
制御部１３０は、次のエントリに注目する。ステップＳ２２４へ進む。
以上のように、ステップＳ２２４〜Ｓ２２８の処理を繰り返すことで、送信しても許容時間内に相手に到着しない音声パケットを破棄する。ここまでの例では、図２７におけるエントリ１と２が破棄される。
次に、ステップＳ２２５で、今から送信したら許容時間内に相手に到着すると判断された場合について説明する。エントリ３では、許容時間内に到着すると判断されるためステップＳ２２９へ進む。
ステップＳ２２９
制御部１３０は、注目中のエントリの内容をコピーする。ここでは、エントリ３の内容が一時的に制御部１３０によって記憶される。
制御部１３０は、注目中のエントリの内容をコピーする。ここでは、エントリ３の内容が一時的に制御部１３０によって記憶される。
ステップＳ２３０
制御部１３０は、ステップＳ２２９でコピーしたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
制御部１３０は、ステップＳ２２９でコピーしたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
ステップＳ２３１
制御部１３０は、送信パケットキュー１１１を参照して、注目中のエントリの次にエントリが存在するかどうかを判断する。存在すればステップＳ２３２へ、さもなければ、ステップＳ２３３へ進む。
制御部１３０は、送信パケットキュー１１１を参照して、注目中のエントリの次にエントリが存在するかどうかを判断する。存在すればステップＳ２３２へ、さもなければ、ステップＳ２３３へ進む。
ステップＳ２２９〜Ｓ２３２を繰り返すことで、エントリがなくなるまで送信パケットキューのエントリの内容がマージされていく。
ステップＳ２３２
制御部１３０は、次のエントリに注目する。ステップＳ２２９へ進む。
制御部１３０は、次のエントリに注目する。ステップＳ２２９へ進む。
ステップＳ２３３
エントリ５までのデータがマージされた後、パケット送信キュー１１には、もうマージすべきエントリが無いので、ステップＳ２３３が実行される。
エントリ５までのデータがマージされた後、パケット送信キュー１１には、もうマージすべきエントリが無いので、ステップＳ２３３が実行される。
ここでは無線フレームはＩＥＥＥ８０２．１１ｉで規定された暗号化方式によって暗号化されるものとする。制御部１３０は、無線通信部１０７にＣＣＭＰヘッダとＭＩＣキーを付加するよう指示する。すると、無線通信部１０７は、暗号化アルゴリズムにしたがってＣＣＭＰヘッダとＭＩＣキーを計算し、送信バッファ１０５のＩＥＥＥ８０２．１１ｉで規定されたペイロードの位置に追加する。
ステップＳ２３４
制御部１３０は、無線通信部１０７に送信バッファ１０５の内容を送信するよう指示する。すると、無線通信部１０７は指示された内容を無線フレームとして空中に放出する。ステップＳ２２１へ進む。
制御部１３０は、無線通信部１０７に送信バッファ１０５の内容を送信するよう指示する。すると、無線通信部１０７は指示された内容を無線フレームとして空中に放出する。ステップＳ２２１へ進む。
ここで、ＩＥＥＥ ８０２．１１で規定されているプリアンブルやＦＣＳは無線通信部１０７で付加されるものとする。
次に、データのマージ処理について図２８のフローチャートに従って説明する。実施例１と比較すると、本実施例では、上位プロトコル解析処理を行わないで、単純にペイロードをひとつの無線フレームにまとめている。
ステップＳ２４１
ペイロード統合部１１２は、送信バッファ１０５にデータが書き込まれているかどうかを判断する。書き込まれていればステップＳ２４４へ、さもなければ、ステップＳ２４２へ進む。
ペイロード統合部１１２は、送信バッファ１０５にデータが書き込まれているかどうかを判断する。書き込まれていればステップＳ２４４へ、さもなければ、ステップＳ２４２へ進む。
ステップＳ２４２
ペイロード統合部１１２は送信バッファ１０５にＭＡＣヘッダを書き込む。ステップＳ２４４へ進む。
ペイロード統合部１１２は送信バッファ１０５にＭＡＣヘッダを書き込む。ステップＳ２４４へ進む。
ステップＳ２４３
ペイロード統合部１１２は、受け取った音声パケットの合計バイト数を算出する。ここでは、ＬＬＣヘッダ（８バイト）＋ＩＰｖ６ヘッダ（４０バイト）＋ＵＤＰヘッダ（８バイト）＋ＲＴＰヘッダ（１２バイト）＋音声（８０バイト）＝１４８バイトとなる。
ペイロード統合部１１２は、受け取った音声パケットの合計バイト数を算出する。ここでは、ＬＬＣヘッダ（８バイト）＋ＩＰｖ６ヘッダ（４０バイト）＋ＵＤＰヘッダ（８バイト）＋ＲＴＰヘッダ（１２バイト）＋音声（８０バイト）＝１４８バイトとなる。
ステップＳ２４４
ペイロード統合部１１２はステップＳ２４３で得られた合計バイト数をペイロードデリミタとして送信バッファ１０５に書き込む。ここでは１４８を書き込む。
ペイロード統合部１１２はステップＳ２４３で得られた合計バイト数をペイロードデリミタとして送信バッファ１０５に書き込む。ここでは１４８を書き込む。
ステップＳ２４５
ペイロード統合部１１２は音声パケットとして受け取ったデータを送信バッファ１０５に書き込む。マージ処理を終了する。
ペイロード統合部１１２は音声パケットとして受け取ったデータを送信バッファ１０５に書き込む。マージ処理を終了する。
以上のようにして、書き込まれた送信バッファ１０５の様子を図２９に示す。これまでの例では図２７におけるエントリ３〜５がペイロード１〜３として書き込まれている。
次に、無線受信タスクの動作について図３０のフローチャートに従って説明する。
なお、本実施の形態では無線受信タスクは、子機、親機ともに同一の処理を行う。ここで、自局宛の無線フレームは無線通信部１０７によって受信され、受信バッファ１０４にフレームの内容をデータとして書き込んでいるものとする。
ステップＳ２５１〜Ｓ２５４
実施の形態１における図１７のステップＳ１７１〜Ｓ１７４と同一である。
実施の形態１における図１７のステップＳ１７１〜Ｓ１７４と同一である。
ステップＳ２５５
ペイロード分割部１１４は先頭の１バイトをデリミタと解釈し、値を読み出し、ペイロードが何バイトかを得て、以降のペイロードを取り出す。ステップＳ２５７へ進む。
ペイロード分割部１１４は先頭の１バイトをデリミタと解釈し、値を読み出し、ペイロードが何バイトかを得て、以降のペイロードを取り出す。ステップＳ２５７へ進む。
ステップＳ２５６〜Ｓ２５９
実施の形態１における図１７のステップＳ１７７〜Ｓ１８０と同一である。
実施の形態１における図１７のステップＳ１７７〜Ｓ１８０と同一である。
以上の処理によって、もともと複数の音声パケットがひとつの無線フレームにまとめられていても、正しくもとの音声パケットに分割され、プロトコル処理部１１７に渡される。デコードタスクは、規定された遅延時間内にデコード処理を完了し、音声として再生する。
次に、親機についてであるが、親機のタスク構成は実施の形態１と同様であり、ブリッジタスクは、実施の形態１と同様である。無線受信タスクについては実施の形態２の子機と同様であるため、説明を省略し、ここでは親機の無線送信タスクのみを説明する。
本実施の形態における親機の無線送信タスクについて図３１のフローチャートに従って説明する。
ステップＳ２６１〜Ｓ２６２
子機における図２５のステップＳ２２１〜Ｓ２２２と同一の処理を行う。
子機における図２５のステップＳ２２１〜Ｓ２２２と同一の処理を行う。
ステップＳ２６３
子機における図２５のステップＳ２２３と同一の処理を行う。ステップＳ２６４へ進む。
子機における図２５のステップＳ２２３と同一の処理を行う。ステップＳ２６４へ進む。
ステップＳ２６４
子機における図２５のステップＳ２２６と同一の処理を行う。ステップＳ２６５へ進む。
子機における図２５のステップＳ２２６と同一の処理を行う。ステップＳ２６５へ進む。
ステップＳ２６５〜Ｓ２６９
子機における図２５のステップＳ２３０〜Ｓ２３３と同一の処理を行う。
子機における図２５のステップＳ２３０〜Ｓ２３３と同一の処理を行う。
ステップＳ２６９
子機における図２５のステップＳ２３４と同一の処理を行う。ステップＳ２６１へ進む。
子機における図２５のステップＳ２３４と同一の処理を行う。ステップＳ２６１へ進む。
これまで説明してきたように、本実施の形態で示した子機と親機を組み合わせて利用すれば、通話中の音声の遅延を実用的な範囲内に抑えたまま、エラーが発生しても音が途切れない通話品質の高い通話品質を提供できる。
以上のように、従来、エラーの発生によって、再送が起き、その分、以降の音声の到着時刻が遅延して、さらに、この遅延が蓄積することによって、受信端末側がジッターバッファのオーバーフローを起こし、音声の途切れなどの品質低下が引き起こされていたが、本実施の形態によれば、上記の構成により、音声パケットを冗長化して送信するので、エラーが発生してももとの音声を復元することができる。
また、音声パケットをまとめてひとつの無線フレームとして送信するので、帯域を必要以上に圧迫しない。さらに、ネットワークのトラフィックが変動しても、ネットワークの遅延時間を測定し、これに送信のタイミングと１フレーム当りのパケットの重畳量を適応させることができる。このことにより、無線ＬＡＮ電話の利用者に対しては、品質のよい通話環境を提供し、また、同じ無線ＬＡＮ内でデータ通信を行っているユーザに対して、必要以上に帯域を圧迫せず、良好な通信環境を提供できる。
（実施の形態３）
図３２は、本発明の実施の形態３における子機の機能ブロック図である。
図３２は、本発明の実施の形態３における子機の機能ブロック図である。
図３２において、１０１は、発呼先の指定、着呼時に通話の指示および終話の指示をするための操作部、１０２は、音声を入力するための音声入力部、１０３は、音声を出力するための音声出力部、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファである。
１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部、１０８は、時間の経過を測定するためのＲＴＣ、１０９は、音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量を記憶するパラメータ記憶部である。
１１０は、音声入力部１０２から入力した音声をＡ／Ｄ変換し、所定のアルゴリズムを用いて音声パケットに変換（エンコード）する、また、音声データを所定のアルゴリズムを用いてデコードした上で、Ｄ／Ａ変換し、前記音声出力部１０３に出力するコーデック部、１１１は、前記コーデック部１１０がエンコードした音声パケットをエンコードが完了した時刻、すなわち、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキューである。
１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部、１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキューである。
１１４は、前記受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、前記受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部、
１１５は、前記パラメータ記憶部１０９に記憶された音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量を参照し、ＲＴＣ１０８の値を送信要求受付時刻と比較し、送信待ちの許容時間を算出する、送信待ち許容時間算出部である。
１１５は、前記パラメータ記憶部１０９に記憶された音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量を参照し、ＲＴＣ１０８の値を送信要求受付時刻と比較し、送信待ちの許容時間を算出する、送信待ち許容時間算出部である。
１１６は、発呼、着呼、呼の接続・切断の制御、および、各呼の状態に応じたダイヤルトーン、ビジートーン、リンガー、リング・バック・トーンを前記音声出力部１０３に出力する呼制御部、１１７は、呼の設定や解除、通話時の音声パケットの送受信、を指定されたプロトコルに従って処理するプロトコル処理部である。
１２２は、ＦＩＦＯ方式であらかじめ決められた数の音声パケットの内容または識別子を記憶する受信履歴バッファ、１２３は、前記受信履歴バッファ１２２を参照して、指定された音声パケットと同一音声パケットが記憶されているかどうか検索する、重複パケット検索部、１３０は、全体を制御する、制御部である。
ここで、図３２の構成と図２の構成との対応関係について説明する。
１０１の操作部は、２１１のキーボードによって、１０２の音声入力部は、２０８のマイクによって、１０３の音声出力部は、２１０のスピーカによって、それぞれ実現されている。
１０４の受信バッファ、１０５の送信バッファ、１０９のパラメータ記憶部、１１１の送信パケットキュー、１１３の受信パケットキュー、１２２の受信履歴バッファは、２０３のＲＡＭによって、実現されている。
１０７の無線通信部は、２０５のベースバンドと２０６のＲＦによって、１０８のＲＴＣは、２０４のＲＴＣによって、１１０のコーデック部は、２１２のコーデック、２０７のＡ／Ｄ、２０９のＤ／Ａによって実現されている。
１１２のペイロード統合部、１１４のペイロード分割部、１１５の送信待ち許容時間算出部、１２３の重複パケット検索部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって、実現されている。
図３３は、本発明の実施の形態３における親機の機能ブロック図である。
図３３において、１０４は、受信した無線フレームから取り出されたデータを蓄積する受信バッファ、１０５は、無線送信用のデータを蓄積する送信バッファ、１０６は、有線のネットワークと接続するためのＬＡＮ通信部である。
１０７は、送信バッファ１０５に蓄積したデータを無線フレーム化して送信、また、無線フレームを受信してフレームの内容を受信バッファ１０４に格納する無線通信部、１０８は、時間の経過を測定するためのＲＴＣ、１１１は、後述する有線−無線ブリッジ部１２０が、中継が必要と判断したＬＡＮ側からのイーサネット（登録商標）フレームを無線フレーム化して送信するために、送信要求受付時刻とともにＦＩＦＯ方式で記憶する送信パケットキューである。
１１２は、送信待ち時間内に送信パケットキュー１１１に入力されたパケットをひとつの無線フレームにまとめて前記送信バッファに書き込むペイロード統合部、１１３は、無線フレームとして受け取ったデータをパケットに分解してＦＩＦＯ方式で記憶する、受信パケットキュー、１１４は、受信バッファ１０４に記憶された内容をもともとひとつのパケットであったかどうか判断し、複数のパケットが統合されている場合は、これを複数のパケットに分解し、受信パケットキュー１１３にＦＩＦＯ方式で書き込む、ペイロード分割部である。
１２０は、有線と無線の間のフレームを必要があれば中継し、さもなければ破棄する、有線−無線ブリッジ部、１２２は、ＦＩＦＯ方式であらかじめ決められた数の音声パケットの内容または識別子を記憶する受信履歴バッファ、１２３は、前記受信履歴バッファ１２２を参照して、指定された音声パケットと同一音声パケットが記憶されているかどうか検索する、重複パケット検索部、１３０は、全体を制御する、制御部である。
ここで、図３３の構成と図４の構成との対応関係について説明する。
１０４の受信バッファ、１０５の送信バッファ、１１１の送信パケットキュー、１１３の受信パケットキュー、１２２の受信履歴バッファは、２０３のＲＡＭによって、実現されている。
１０７の無線通信部は、２０５のベースバンドと２０６のＲＦによって、１０８のＲＴＣは、２０４のＲＴＣによって、１０６のＬＡＮ通信部は、２１３のネットワークＩ／Ｆによって、それぞれ実現されている。
１１２のペイロード統合部、１１４のペイロード分割部、１２０の有線−無線ブリッジ部、１２３の重複パケット検索部、および、１３０の制御部は、２０１のＣＰＵが２０２のＲＯＭの中に記憶しているプログラムを、２０２のＲＯＭの中に記憶しているデータを参照したり、２０３のＲＡＭに記憶しているデータを参照したり、変更したりしながら実行することによって、実現されている。
本実施の形態では、無線ＬＡＮ電話システム全体の構成および親機と子機の動作概要は実施の形態１と変わらないので説明を省略する。また、同様に、親機と子機のタスク構成も実施の形態１と同一なので説明を省略する。
図３４は、本実施の形態における子機の無線送信タスクのフローチャートである。
送信パケットキュー１１１はあて先のＭＡＣアドレスごとに存在し、無線送信タスクは以下の処理を送信パケットキュー１１１ごとに行う。但し、以下の説明では、ひとつの送信パケットキュー１１１に注目してその動作を説明する。本実施例は実施例２とよく似ているが、実施例２では許容時間内に送信できるパケットをすべてマージして送信するのに対し、本実施例では許容時間内に送信できるパケットのもっとも古いものともっとも新しいもののみをマージする、という点で異なっている。以下、この点を留意しながら詳しく説明する。
ステップＳ３０１〜Ｓ３０８
実施の形態２における図２５のステップＳ２２１〜Ｓ２２８と同一の処理を行う。
実施の形態２における図２５のステップＳ２２１〜Ｓ２２８と同一の処理を行う。
ここまでの処理で今から送信しても許容時間内に到着しないパケットは送信パケットキュー１１１から削除されていることになる。
ステップＳ３０９
制御部１３０は、送信パケットキュー１１１を参照して、注目中のエントリの次にエントリが存在するかどうかを判断する。存在すればステップＳ３１４へ、さもなければ、ステップＳ３１０へ進む。ここでは、エントリが存在しないものとして説明を続ける。この場合、送信パケットキュー１１１に音声パケットがひとつしか残っていないことになる。
制御部１３０は、送信パケットキュー１１１を参照して、注目中のエントリの次にエントリが存在するかどうかを判断する。存在すればステップＳ３１４へ、さもなければ、ステップＳ３１０へ進む。ここでは、エントリが存在しないものとして説明を続ける。この場合、送信パケットキュー１１１に音声パケットがひとつしか残っていないことになる。
ステップＳ３１０
制御部１３０は、注目中のエントリの内容をコピーする。
制御部１３０は、注目中のエントリの内容をコピーする。
ステップＳ３１１
制御部１３０は、ステップＳ３１０でコピーしたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
制御部１３０は、ステップＳ３１０でコピーしたデータをマージするようペイロード統合部１１２に指示する。詳細は後述する。送信バッファ１０５に送信すべきデータが書き込まれる。
ステップＳ３１２
ここでは無線フレームはＩＥＥＥ８０２．１１ｉで規定された暗号化方式によって暗号化されるものとする。制御部１３０は、無線通信部１０７にＣＣＭＰヘッダとＭＩＣキーを付加するよう指示する。すると、無線通信部１０７は、暗号化アルゴリズムにしたがってＣＣＭＰヘッダとＭＩＣキーを計算し、送信バッファ１０５のＩＥＥＥ８０２．１１ｉで規定されたペイロードの位置に追加する。
ここでは無線フレームはＩＥＥＥ８０２．１１ｉで規定された暗号化方式によって暗号化されるものとする。制御部１３０は、無線通信部１０７にＣＣＭＰヘッダとＭＩＣキーを付加するよう指示する。すると、無線通信部１０７は、暗号化アルゴリズムにしたがってＣＣＭＰヘッダとＭＩＣキーを計算し、送信バッファ１０５のＩＥＥＥ８０２．１１ｉで規定されたペイロードの位置に追加する。
ステップＳ３１３
制御部１３０は、無線通信部１０７に送信バッファ１０５の内容を送信するよう指示する。すると、無線通信部１０７は指示された内容を無線フレームとして空中に放出する。ここで、ＩＥＥＥ ８０２．１１で規定されているプリアンブルやＦＣＳは無線通信部１０７で付加されるものとする。
制御部１３０は、無線通信部１０７に送信バッファ１０５の内容を送信するよう指示する。すると、無線通信部１０７は指示された内容を無線フレームとして空中に放出する。ここで、ＩＥＥＥ ８０２．１１で規定されているプリアンブルやＦＣＳは無線通信部１０７で付加されるものとする。
ステップＳ３０１へ進む。
次に、ステップＳ３０９で次のエントリが存在した場合について説明する。
図２７に示すように５つのエントリが送信パケットキュー１１１に登録されていたものとする。ステップＳ３０９までの処理でエントリ１、２は今から送信しても許容時間内に到着しないので破棄されている。つまり現在エントリ３に注目している。エントリ４が送信パケットキュー１１１に存在するため、ステップＳ３１４が実行される。
ステップＳ３１４
ステップＳ３１０と同一の処理を行う。
ステップＳ３１０と同一の処理を行う。
ステップＳ３１５
ステップＳ３１１と同一の処理を行う。
ステップＳ３１１と同一の処理を行う。
ステップＳ３１６
ステップＳ３０８と同一の処理を行う。
ステップＳ３０８と同一の処理を行う。
ステップＳ３１７
ステップＳ３０９と同一の処理を行う。次のエントリが存在する場合は、ステップＳ３１６へ、さもなければ、ステップＳ３１０へ進む。
ステップＳ３０９と同一の処理を行う。次のエントリが存在する場合は、ステップＳ３１６へ、さもなければ、ステップＳ３１０へ進む。
このように、ステップＳ３１４、Ｓ３１５の処理でもっとも古い音声パケットが送信データとしてマージされる。さらにステップＳ３１６、Ｓ３１７によって、送信パケットキュー１１１のなかでもっとも新しいパケットを見つける。
以降、ステップＳ３１０〜Ｓ３１３の処理によってもっとも古いパケットともっとも新しいパケットがマージされ、送信される。なお、本実施の形態では、実施の形態２と同一のマージ処理を行うものとする。
次に、無線受信タスクの動作について図３５のフローチャートに従って説明する。
なお、本実施例では無線受信タスクは、子機、親機ともに同一の処理を行う。ここで、自局宛の無線フレームは無線通信部１０７によって受信され、受信バッファ１０４にフレームの内容をデータとして書き込んでいるものとする。
ステップＳ３２１〜Ｓ３２５
実施の形態２における図３０のステップＳ２５１〜Ｓ２５５と同一の処理を行う。
実施の形態２における図３０のステップＳ２５１〜Ｓ２５５と同一の処理を行う。
ステップＳ３２６
ペイロード分割部１１４は、重複パケット検索部１２３に現在注目中のペイロードと等しい内容のパケットが受信履歴バッファ１２２にすでに登録されているかどうかを問い合わせる。
ペイロード分割部１１４は、重複パケット検索部１２３に現在注目中のペイロードと等しい内容のパケットが受信履歴バッファ１２２にすでに登録されているかどうかを問い合わせる。
ステップＳ３２７
重複パケット検索部１２３は、ステップＳ３２６の結果を制御部１３０に通知する。この処理の詳細は後述する。登録されていれば、ステップＳ３２８へ、さもなければ、ステップＳ３３１へ進む。
重複パケット検索部１２３は、ステップＳ３２６の結果を制御部１３０に通知する。この処理の詳細は後述する。登録されていれば、ステップＳ３２８へ、さもなければ、ステップＳ３３１へ進む。
ステップＳ３２８〜Ｓ３２９
実施の形態２における図３０のステップＳ２５７〜Ｓ２５８と同一の処理を行う。
実施の形態２における図３０のステップＳ２５７〜Ｓ２５８と同一の処理を行う。
ステップＳ３３０
実施の形態２における図３０のステップＳ２５９と同一の処理を行う。ステップＳ３２６へ進む。
実施の形態２における図３０のステップＳ２５９と同一の処理を行う。ステップＳ３２６へ進む。
ステップＳ３３１
ペイロード分割部１１４は、得られたペイロードを受信パケットキュー１１３に入れる。ステップＳ３２８へ進む。
ペイロード分割部１１４は、得られたペイロードを受信パケットキュー１１３に入れる。ステップＳ３２８へ進む。
以上の処理によって、もともと複数の音声パケットがひとつの無線フレームにまとめられていても、正しくもとの音声パケットに分割され、プロトコル処理部１１７に渡される。また、送信側によって同じ音声パケットがコピーされていて、異なる無線フレームで送信されても、本処理によって、同じ音声パケットは破棄される。これにより、親機では、同じ音声パケットをＬＡＮに流すことがなくなるので、ネットワークのトラフィックを不必要に増加させることはない。
次に、前述の重複パケット検索処理について詳細を説明する。
図３６は、本実施の形態における重複パケット検索処理を示したフローチャートである。
ここでは、音声パケットの伝送をＲＴＰプロトコルによって行うものとする。ＲＴＰプロトコルではヘッダ部にシーケンス番号が書き込まれており、音声パケットの重複や欠落、順序の入れ代わりなどを検出できるようになっている。ここでは、受信履歴バッファ１２２は、１０個のシーケンス番号をＦＩＦＯ方式で記憶するものとする。
ステップＳ３４１
重複パケット検索部１２３は、受信履歴バッファ１２２内にシーケンス番号が登録されているかどうかを判断する。ひとつも登録されていなければ、「重複なし」として処理を終了する。さもなければ、ステップＳ３４２へ進む。
重複パケット検索部１２３は、受信履歴バッファ１２２内にシーケンス番号が登録されているかどうかを判断する。ひとつも登録されていなければ、「重複なし」として処理を終了する。さもなければ、ステップＳ３４２へ進む。
ステップＳ３４２
重複パケット検索部１２３は、受信履歴バッファ１２２内のＦＩＦＯ方式で記憶されている最初のシーケンス番号に注目する。
重複パケット検索部１２３は、受信履歴バッファ１２２内のＦＩＦＯ方式で記憶されている最初のシーケンス番号に注目する。
ステップＳ３４３
重複パケット検索部１２３は、ペイロード分割部１１４によって指定されたペイロードに含まれるＲＴＰパケットのヘッダ部にあるシーケンス番号を参照して、現在注目しているシーケンス番号と一致するかどうかを照合する。一致する場合は、「重複あり」として処理を終了する。さもなければ、ステップＳ３４４へ進む。
重複パケット検索部１２３は、ペイロード分割部１１４によって指定されたペイロードに含まれるＲＴＰパケットのヘッダ部にあるシーケンス番号を参照して、現在注目しているシーケンス番号と一致するかどうかを照合する。一致する場合は、「重複あり」として処理を終了する。さもなければ、ステップＳ３４４へ進む。
ステップＳ３４４
重複パケット検索部１２３は、受信履歴バッファ１２２内にいま注目中のシーケンス番号の次にもシーケンス番号が記憶されているかどうかを判断する。記憶されている場合は、ステップＳ３４５へ、さもなければ、「重複なし」として処理を終了する。
重複パケット検索部１２３は、受信履歴バッファ１２２内にいま注目中のシーケンス番号の次にもシーケンス番号が記憶されているかどうかを判断する。記憶されている場合は、ステップＳ３４５へ、さもなければ、「重複なし」として処理を終了する。
ステップＳ３４５
重複パケット検索部１２３は、現在注目中のシーケンス番号を受信履歴バッファ１２２にＦＩＦＯ方式で記憶されている次のシーケンス番号に移動する。ステップＳ３４３へ進む。
重複パケット検索部１２３は、現在注目中のシーケンス番号を受信履歴バッファ１２２にＦＩＦＯ方式で記憶されている次のシーケンス番号に移動する。ステップＳ３４３へ進む。
以上の処理によって、本実施の形態では過去１０パケットにわたって、受信した音声パケットのＲＴＰヘッダのシーケンス番号を調べ、すでに受信したかどうかを判断する。これにより、すでに受信したものは「重複あり」として処理されるため、ペイロード統合部１１４の処理によって破棄されることになる。
次に、親機についてであるが、親機のタスク構成は実施の形態１と同様である。ここでは実施の形態１、２と異なる親機の無線送信タスクのみを説明する。
本実施の形態における親機の無線送信タスクについて図３７のフローチャートに従って説明する。
ステップＳ３５１〜Ｓ３５２
実施の形態１における図１３のステップＳ１３１〜Ｓ１３２と同一の処理を行う。
実施の形態１における図１３のステップＳ１３１〜Ｓ１３２と同一の処理を行う。
ステップＳ３５３
実施の形態１における図１３のステップＳ１３３と同一の処理を行う。ステップＳ３５４へ進む。
実施の形態１における図１３のステップＳ１３３と同一の処理を行う。ステップＳ３５４へ進む。
ステップＳ３５４
制御部１３０は送信パケットキュー１１１を参照して、エントリの数が１より大きいかどうかを判断する。１より大きい場合はステップＳ３５５へ、さもなければ、ステップＳ３５８へ進む。
制御部１３０は送信パケットキュー１１１を参照して、エントリの数が１より大きいかどうかを判断する。１より大きい場合はステップＳ３５５へ、さもなければ、ステップＳ３５８へ進む。
ステップＳ３５５〜Ｓ３６１
実施の形態１における図１３のステップＳ１３６〜Ｓ１４２と同一の処理を行う。ステップＳ３５１へ進む。
実施の形態１における図１３のステップＳ１３６〜Ｓ１４２と同一の処理を行う。ステップＳ３５１へ進む。
これまで説明してきたように、本実施の形態で示した子機と親機を組み合わせて利用すれば、無線ＬＡＮで発生しがちな、バーストエラーが発生して、連続した無線フレームが送信エラーとなっても、音声パケットのロスは発生しない。例えば、無線フレームＡに音声パケット１と３、無線フレームＢに音声パケット２と４、無線フレームＣに音声パケット３と５、無線フレームＤに音声パケット４と６、無線フレームＥに音声パケット５と７、無線フレームＦに音声パケット６と８がマージされて送信された場合、途中の無線フレームＣ，Ｄがバーストエラーによって連続して欠落しても、無線フレームＣと無線フレームＤに含まれる音声パケット３，５，４，６は、それぞれ無線フレームＡ、無線フレームＥ、無線フレームＢ，無線フレームＦに含まれるため、受信側はこれを利用して、もとの音声を復元することが可能となる。また、実施例２で示した方法とは異なり、１フレームにつき音声パケットを２つだけ乗せる形になるので必要以上に無線フレームの長さが長くなることも無く、同じｃｈを使って通信している他の端末への影響をより小さくすることができる。
以上のように、従来、エラーの発生によって、再送が起き、その分、以降の音声の到着時刻が遅延して、さらに、この遅延が蓄積することによって、受信端末側がジッターバッファのオーバーフローを起こし、音声の途切れなどの品質低下が引き起こされていたが、本実施例３によれば、上記の構成により、音声パケットを冗長化して送信するので、エラーが発生してももとの音声を復元することができる。また、音声パケットをまとめてひとつの無線フレームとして送信するので、帯域を必要以上に圧迫しない。さらに、バーストエラーによって連続して無線フレームの送受信に失敗しても、音声パケットをインターリーブすることによって、音声パケットが失われることを極力回避することができる。加えて、受信側で同一の音声パケットを破棄することにより、必要以上にネットワークに負荷をかける心配も無い。このことにより、無線ＬＡＮ電話の利用者に対しては、品質のよい通話環境を提供し、また、同じ無線ＬＡＮ内でデータ通信を行っているユーザに対して、必要以上に帯域を圧迫せず、良好な通信環境を提供できる。
なお、本実施の形態では、２つの音声パケットを１つの無線フレームとして送信しているが、３つ以上の音声パケットをあらかじめ決められたアルゴリズムによって選択し、それらをひとつの無線フレームにして送信するようにしても本発明の主旨とはなんらかわりない。
本発明に係る無線ＬＡＮ電話通信方法及びシステムは、無線通信におけるエラーの影響を回避し、高い通話品質を提供できるところから、例えば無線ＬＡＮを利用したコードレス電話などへの利用が可能である。
１０１ 操作部
１０２ 音声入力部
１０３ 音声出力部
１０４ 受信バッファ
１０５ 送信バッファ
１０６ ＬＡＮ通信部
１０７ 無線通信部
１０８ ＲＴＣ
１０９ パラメータ記憶部
１１０ コーデック部
１１１ 送信パケットキュー
１１２ ペイロード統合部
１１３ 受信パケットキュー
１１４ ペイロード分割部
１１５ 送信待ち許容時間算出部
１１６ 呼制御部
１１７ プロトコル処理部
１１８ 上位プロトコル解析部
１１９ エラー率判定部
１２０ 有線−無線ブリッジ部
１２１ ネットワーク遅延測定部
１２２ 受信履歴バッファ
１２３ 重複パケット検索部
１３０ 制御部
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ ＲＴＣ
２０５ ベースバンド
２０６ ＲＦ
２０７ Ａ／Ｄ
２０８ マイク
２０９ Ｄ／Ａ
２１０ スピーカ
２１１ キーボード
２１２ コーデック
２１３ ネットワークＩ／Ｆ
１０２ 音声入力部
１０３ 音声出力部
１０４ 受信バッファ
１０５ 送信バッファ
１０６ ＬＡＮ通信部
１０７ 無線通信部
１０８ ＲＴＣ
１０９ パラメータ記憶部
１１０ コーデック部
１１１ 送信パケットキュー
１１２ ペイロード統合部
１１３ 受信パケットキュー
１１４ ペイロード分割部
１１５ 送信待ち許容時間算出部
１１６ 呼制御部
１１７ プロトコル処理部
１１８ 上位プロトコル解析部
１１９ エラー率判定部
１２０ 有線−無線ブリッジ部
１２１ ネットワーク遅延測定部
１２２ 受信履歴バッファ
１２３ 重複パケット検索部
１３０ 制御部
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ ＲＴＣ
２０５ ベースバンド
２０６ ＲＦ
２０７ Ａ／Ｄ
２０８ マイク
２０９ Ｄ／Ａ
２１０ スピーカ
２１１ キーボード
２１２ コーデック
２１３ ネットワークＩ／Ｆ
Claims (11)
- 発生した音声パケットを複製して１つ以上のコピーを保存しておき、送信時に、以前に発生した１つ以上の音声パケットのコピーと最近発生した音声パケットを１つの無線フレームにまとめて送信し、受信した側で、もとのパケットに分割することを特徴とする無線ＬＡＮ電話通信方法。
- 音声の遅延許容時間、音声のコーデック周期、音声のコーデック遅延、および、あらかじめ指定されたネットワークの遅延量とあらかじめ指定されたアルゴリズムによって決定される無線フレームの送信予定時刻から送信待ち許容時間を計算して、その送信待ち時間の許容範囲内で、音声パケットを冗長化して複数の音声パケットをひとつの無線フレームにまとめて送信し、受信側で、元通り複数の冗長化された音声パケットに分解することを特徴とする無線ＬＡＮ電話通信方法。
- 遅延許容時間内で、インターリーブを行い、冗長化されたパケットのうち、連続しない２つ以上の音声パケットを１つの無線フレームにまとめて送信することを特徴とする無線ＬＡＮ電話通信方法。
- ネットワークの遅延量を測定するために、あらかじめ指定されたアルゴリズムで繰り返し得られる測定時刻にあらかじめ決められた手順を実施し、ネットワークの遅延量を測定し、送信待ち許容時間を更新することを特徴とする請求項２または３に記載の無線ＬＡＮ電話通信方法。
- 受信履歴バッファ内で重複した音声パケットを受信した場合に、これを破棄することを特徴とする請求項１から４のうち何れか１に記載の無線ＬＡＮ電話通信方法。
- 上位プロトコルヘッダを解析し、共通部分を省略してフレーム化することを特徴とする請求項１から５のうち何れか１に記載の無線ＬＡＮ電話通信方法。
- 無線通信のエラーレートが指定された閾値より高い場合、請求項１から６の通信方法を実施し、そうでない場合は、実施しないことを特徴とする請求項１から６のうち何れか１に記載の無線ＬＡＮ電話通信方法。
- 請求項１から７のうち何れか１に記載の無線ＬＡＮ電話の通信方法を実現したことを特徴とする無線ＬＡＮ電話子機。
- 請求項１から７のうち何れか１に記載の無線ＬＡＮ電話の通信方法を実現したことを特徴とする無線ＬＡＮ電話親機。
- 請求項１から７のうち何れか１に記載の無線ＬＡＮ電話の通信方法を実現したことを特徴とするプログラム。
- 請求項１から７のうち何れか１に記載の無線ＬＡＮ電話の通信方法を実現したことを特徴とする無線ＬＡＮ電話システム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007101534A JP2008259094A (ja) | 2007-04-09 | 2007-04-09 | 無線ｌａｎ電話通信方法及びシステム |
| US12/098,628 US20080247413A1 (en) | 2007-04-09 | 2008-04-07 | Communication apparatus and communication method |
| PCT/JP2008/057384 WO2008126936A2 (en) | 2007-04-09 | 2008-04-09 | Communication apparatus and communication method with redundant packet transmission |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007101534A JP2008259094A (ja) | 2007-04-09 | 2007-04-09 | 無線ｌａｎ電話通信方法及びシステム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2008259094A true JP2008259094A (ja) | 2008-10-23 |
Family
ID=39826840
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007101534A Pending JP2008259094A (ja) | 2007-04-09 | 2007-04-09 | 無線ｌａｎ電話通信方法及びシステム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20080247413A1 (ja) |
| JP (1) | JP2008259094A (ja) |
| WO (1) | WO2008126936A2 (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013135397A (ja) * | 2011-12-27 | 2013-07-08 | National Institute Of Information & Communication Technology | ラベルスイッチングネットワーク |
| JP2016502358A (ja) * | 2012-12-12 | 2016-01-21 | クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ | ショートｍａｃヘッダを使用するパケットのセキュリティ |
| JP2016503997A (ja) * | 2013-01-07 | 2016-02-08 | クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ | 暗黙の再キーイングメカニズム |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9172774B2 (en) * | 2011-04-13 | 2015-10-27 | Qualcomm Incorporated | Technique for managing communications at a router |
| JP5657771B1 (ja) * | 2013-12-10 | 2015-01-21 | パナソニックＩｐマネジメント株式会社 | 電話装置及び携帯電話連携方法 |
| US10855411B2 (en) * | 2018-09-07 | 2020-12-01 | Apple Inc. | Voice quality over bluetooth link by enhancing scheduler behavior for retransmission frames |
| GB2580068B (en) * | 2018-12-20 | 2021-02-24 | Advanced Risc Mach Ltd | Generating a vector predicate summary |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10118192A1 (de) * | 2001-04-11 | 2002-10-24 | Siemens Ag | Verfahren und Vorrichtung zur Übertragung von digitalen Signalen |
| JP4831890B2 (ja) * | 2001-07-06 | 2011-12-07 | パナソニック株式会社 | コンテンツ管理方法及びコンテンツ管理装置 |
| DE10133518B4 (de) * | 2001-07-10 | 2006-08-24 | Siemens Ag | Verfahren und Vorrichtung zur drahtlosen Übertragung von Sprachdaten |
| JP3898523B2 (ja) * | 2002-02-06 | 2007-03-28 | 株式会社日立国際電気 | 無線データ送信装置、及び無線データ受信装置 |
| JP3880497B2 (ja) * | 2002-09-27 | 2007-02-14 | Ｎｅｃインフロンティア株式会社 | Ｌａｎ通信システム |
| JP3643824B2 (ja) * | 2002-10-09 | 2005-04-27 | 株式会社バッファロー | 無線ｌａｎシステム、ネットワークサービス提供方法およびネットワークサービス提供プログラムを記録した媒体 |
| JP4100182B2 (ja) * | 2003-01-30 | 2008-06-11 | 松下電器産業株式会社 | 通信端末装置及びその制御方法 |
| JP2006074132A (ja) * | 2004-08-31 | 2006-03-16 | Matsushita Electric Ind Co Ltd | マルチキャスト通信方法及びゲートウェイ装置 |
| JP2007116673A (ja) * | 2005-09-22 | 2007-05-10 | Matsushita Electric Ind Co Ltd | 通信装置 |
| JP4728792B2 (ja) * | 2005-12-12 | 2011-07-20 | パナソニック株式会社 | Ｉｐ通信装置およびこれを備えたｉｐ通信システムならびにｉｐ通信装置のｉｐアドレス設定方法 |
| US20080026753A1 (en) * | 2006-07-28 | 2008-01-31 | Matsushita Electric Industrial Co., Ltd. | Mobile communication system and communication line switching method in the mobile communication system |
-
2007
- 2007-04-09 JP JP2007101534A patent/JP2008259094A/ja active Pending
-
2008
- 2008-04-07 US US12/098,628 patent/US20080247413A1/en not_active Abandoned
- 2008-04-09 WO PCT/JP2008/057384 patent/WO2008126936A2/en active Application Filing
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013135397A (ja) * | 2011-12-27 | 2013-07-08 | National Institute Of Information & Communication Technology | ラベルスイッチングネットワーク |
| JP2016502358A (ja) * | 2012-12-12 | 2016-01-21 | クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ | ショートｍａｃヘッダを使用するパケットのセキュリティ |
| US9906444B2 (en) | 2012-12-12 | 2018-02-27 | Qualcomm Incorporated | Security for packets using a short MAC header |
| US9998370B2 (en) | 2012-12-12 | 2018-06-12 | Qualcomm Incorporated | Security for packets using a short MAC header |
| JP2016503997A (ja) * | 2013-01-07 | 2016-02-08 | クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ | 暗黙の再キーイングメカニズム |
Also Published As
| Publication number | Publication date |
|---|---|
| US20080247413A1 (en) | 2008-10-09 |
| WO2008126936A3 (en) | 2009-01-08 |
| WO2008126936A2 (en) | 2008-10-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7301928B2 (en) | Wireless packet transfer apparatus and method | |
| EP1074125B1 (en) | Alternating speech and data transmission in digital communications systems | |
| JP5084842B2 (ja) | 無線通信ネットワークにおける改良されたヘッダ圧縮 | |
| AU2003248437B2 (en) | Packet Transmission System and Packet Reception System | |
| JP4676534B2 (ja) | 非アクティブユーザプレーン中のトラフィック生成 | |
| JP4842075B2 (ja) | 音声伝送装置 | |
| JP2008259094A (ja) | 無線ｌａｎ電話通信方法及びシステム | |
| US20020066012A1 (en) | Maintaining end-to-end synchronization on telecommunications connection | |
| JP2002026963A (ja) | パケット伝送方法、中継装置およびデータ端末 | |
| US7929571B2 (en) | System and method for implementing a preemptive retransmit for error recovery in a communications environment | |
| KR100793345B1 (ko) | 음성/데이터 통합 시스템의 패킷 처리 방법 및 그 장치 | |
| AU2004258114B2 (en) | Performing compression of user datagram protocol packets | |
| JP5028784B2 (ja) | 無線ｌａｎ電話システム、無線ｌａｎ電話システム親機、無線ｌａｎ電話システム子機、無線ｌａｎ電話通信方法、無線ｌａｎ電話通信プログラム、および、記録媒体 | |
| JP4856251B2 (ja) | 無線通信ネットワークにおけるヘッダの抑制 | |
| WO2008001580A1 (fr) | Dispositif de communication et procédé | |
| JP2005157045A (ja) | 音声伝送方法 | |
| JP4546114B2 (ja) | 音声パケット転送方法及びそれに用いる端末 | |
| MXPA01013115A (es) | Transmision de informacion comprimida con requisito de tiempo real en una red de informacion orientada en paquetes. | |
| JP4655870B2 (ja) | パケット送受信システムおよび経過時間測定方法 | |
| JP2007228081A (ja) | 無線通信装置、無線通信方法及び無線アクセス装置 | |
| JP2012049913A (ja) | 通信装置 | |
| JP2005229378A (ja) | 中継装置及びその制御方法 | |
| JP2005252429A (ja) | Ｉｐパケット化装置 | |
| Ali et al. | Real-time Voice over IP over Bluetooth | |
| JP2012049914A (ja) | 通信装置 |