無線通信端末装置及び当該無線通信端末装置を用いたシステム
【課題】無線通信端末装置を用いて構築されるアドホックネットワークを介して音声通話を適切に行う。
【解決手段】本無線通信端末装置は、アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、取得されたホップ数に応じてジッタバッファのサイズを決定し、設定するジッタバッファサイズ設定手段とを有する。
【解決手段】本無線通信端末装置は、アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、取得されたホップ数に応じてジッタバッファのサイズを決定し、設定するジッタバッファサイズ設定手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、アドホックネットワークを介した音声通話のための技術に関する。
【背景技術】
【０００２】
従来のＩＰ（Internet Protocol）電話機で内線電話網を構成するためには主にＩＰ−ＰＢＸ（Private Branch eXchange）やＳＩＰ（Session Initiation Protocol）サーバに代表されるサーバ機が必要であり、このサーバ機が内線電話網における制御や公衆交換電話網（ＰＳＴＮ：Public Switched Telephone Network）への接続制御を行うクライアント・サーバ型の電話システムが主流である。このようなサーバ機を主体とした内線電話網においては、サーバ機の導入に伴う費用及び設置スペースが必要であり、中小規模の事業所にとっては大きな設備投資費用となる場合もある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−２３５４４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
近年無線通信技術の向上から、無線電話機が普及してきており、そのような無線電話機を活用してサーバ機を用いずに電話網を構築できれば好ましい。
【０００５】
従って、本技術の目的は、無線通信端末装置を用いて構築されるアドホックネットワークを介して音声通話を適切に行うための技術を提供することである。
【課題を解決するための手段】
【０００６】
本無線通信端末装置は、アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、取得されたホップ数に応じてジッタバッファのサイズを決定し、設定するジッタバッファサイズ設定手段とを有する。
【発明の効果】
【０００７】
無線通信端末装置を用いて構築されるアドホックネットワークを介して音声通話を適切に行うことができるようになる。
【図面の簡単な説明】
【０００８】
【図１】図１は、アドホックネットワークの一例を示す図である。
【図２】図２は、無線通信端末装置の機能ブロック図である。
【図３】図３は、アドホックネットワークの初期処理を示す図である。
【図４】図４は、管理者端末の通信管理ＤＢに格納されるデータの一例を示す図である。
【図５】図５は、管理者端末の通信管理ＤＢに格納されるデータの一例を示す図である。
【図６】図６は、管理者端末の通信管理ＤＢに格納されるデータの一例を示す図である。
【図７】図７は、非管理者端末の通信管理ＤＢに格納されるデータの一例を示す図である。
【図８】図８は、端末間の通話を開始する際の処理を示す図である。
【図９】図９は、ホップ数と受信遅延時間との関係を表す図である。
【図１０】図１０は、ホップ数とジッタバッファサイズの関係を表す図である。
【図１１】図１１は、ジッタバッファサイズの調整のための処理フローを示す図である。
【図１２】図１２は、ジッタバッファサイズ・テーブルの一例を示す図である。
【図１３】図１３は、ホップ数とパケットロス数の関係を表す図である。
【図１４】図１４は、データ補完について説明するための図である。
【図１５】図１５は、ホップ数と最大補完データサイズの関係を表す図である。
【図１６】図１６は、補完データサイズを変更した場合について説明するための図である。
【図１７】図１７は、補完データサイズの調整のための処理フローを示す図である。
【図１８】図１８は、補完データサイズ・テーブルの一例を示す図である。
【図１９】図１９は、従来の無線及び有線のＩＰ電話システムを示す図である。
【図２０】図２０は、通常のＩＰ電話システムからアドホックネットワークを用いた電話システムへの移行について説明するための図である。
【図２１】図２１は、アドホックネットワークを用いた電話システムと通常のＩＰ電話システムとの切り替えに伴う処理の処理フローを示す図である。
【図２２】図２２は、アドホックネットワークを一部採用した電話システムの一例を示す図である。
【発明を実施するための形態】
【０００９】
図１に、本技術の実施の形態において想定するアドホックネットワークの一例を示す。図１では、端末ａ−１と端末ｂ−１と端末ｃ−１と端末ｄ−１と端末ｅ−１とが管理者端末として予め定められているか、または管理者端末となるような特性（例えば電話番号）を有する。そして、管理者端末である端末ａ−１は、予め関連付けられている端末ａ−２乃至ａ−４の情報を管理すると共に、当該端末ａ−１が直接無線通信可能な範囲Ａ内の端末ｂ−１及びｃ−１の情報を管理する。予め関連付けられている端末ａ−２乃至ａ−４（図１では端末ａ−４が該当）については、端末ａ−１が直接無線通信可能な範囲Ａ内になくとも、アドホックネットワーク内の管理者端末を介して情報を取得する。さらに、管理者端末である端末ａ−１は、後に述べるが、直接無線通信可能な範囲Ａ内の他の管理者端末である端末ｂ−１及びｃ−１と管理情報を交換して保持するようになっている。なお、非管理者端末である端末ａ−２乃至ａ−４は、直接無線通信可能な範囲内の管理者端末の情報を保持している。
【００１０】
同様に、管理者端末である端末ｂ−１は、予め関連付けられている端末ｂ−２及びｂ−３の情報を管理すると共に、当該端末ｂ−１が直接無線通信可能な範囲Ｂ内の端末ａ−１及びｄ−１の情報を管理する。予め関連付けられている端末ｂ−２及びｂ−３については、端末ｂ−１が直接無線通信可能な範囲Ｂ内になくとも、アドホックネットワーク内の管理者端末を介して情報を取得する。さらに、管理者端末である端末ｂ−１は、直接無線通信可能な範囲Ｂ内の他の管理者端末である端末ａ−１及びｄ−１と管理情報を交換して保持するようになっている。なお、非管理者端末である端末ｂ−２及びｂ−３は、直接無線通信可能な範囲内の管理者端末の情報を保持している。
【００１１】
さらに、管理者端末である端末ｃ−１は、予め関連付けられている端末ｃ−２の情報を管理すると共に、当該端末ｃ−１が直接無線通信可能な範囲Ｃ内の端末ａ−１、端末ａ−３及びｄ−１の情報を管理する。予め関連付けられている端末ｃ−２については、端末ｃ−１が直接無線通信可能な範囲Ｃ内になくとも、アドホックネットワーク内の管理者端末を介して情報を取得する。さらに、管理者端末ｃ−１は、直接無線通信可能な範囲Ｃ内の他の管理者端末である端末ａ−１及びｄ−１と管理情報を交換して保持するようになっている。なお、非管理者端末である端末ｃ−２は、直接無線通信可能な範囲内の管理者端末の情報を保持している。
【００１２】
また、管理者端末である端末ｄ−１は、予め関連付けられている端末（図１では存在しない）の情報を管理すると共に、当該端末ｄ−１が直接無線通信可能な範囲Ｄ内の端末ｂ−１、ｂ−３、ｃ−１及びｅ−１の情報を管理する。さらに、管理者端末ｄ−１は、後に述べるが、直接無線通信可能な範囲Ｄ内の他の管理者端末である端末ｂ−１、ｃ−１及びｅ−１と管理情報を交換して保持するようになっている。
【００１３】
さらに、管理者端末である端末ｅ−１は、予め関連付けられている端末ｅ−２の情報を管理すると共に、当該端末ｅ−１が直接無線通信可能な範囲Ｅ内の端末ａ−４、ｂ−３及びｄ−１の情報を管理する。予め関連付けられている端末ｅ−２については、端末ｅ−１が直接無線通信可能な範囲Ｅ内になくとも、アドホックネットワーク内の管理者端末を介して情報を取得する。さらに、管理者端末である端末ｅ−１は、直接無線通信可能な範囲Ｅ内の他の管理者端末ｄ−１と管理情報を交換して保持するようになっている。なお、非管理者端末である端末ｅ−２については、直接無線通信可能な範囲内の管理者端末の情報を保持している。
【００１４】
アドホックネットワークであるから、図１は一時的な状態を示しているに過ぎず、端末は自由に移動して異なるネットワーク状態に遷移する。例えば端末ａ−２が移動して範囲Ｂと範囲Ｅが重なる領域に移動したとすると、管理者端末ｂ−１及びｅ−１は、端末ａ−２の情報を管理するようになる。また、管理者端末ａ−１は、端末ａ−２を範囲Ａの中で見つけ出すことができなくなるので、アドホックネットワーク内の他の管理者端末を介して情報を取得する。
【００１５】
このようなアドホックネットワークのノードを構成する無線通信端末装置は、例えば図２に示すような構成を有する。無線通信端末装置１０００は、通信部１００と、通信部１００で受信した音声データを格納するジッタバッファ１１０と、ジッタバッファ１１０に格納されている音声データに対して周知の音声出力処理を実施する音声出力処理部１２０と、音声出力処理部１２０からのアナログ音声信号に従って音声を出力するスピーカ１３０と、ジッタバッファサイズ及び紛失データを補完する補完処理を行う範囲を表す補完データサイズを決定する音声出力制御部１４０と、ジッタバッファサイズ及び最大補完データサイズの初期値を格納する初期値テーブル１５０と、マイク１６０と、マイク１６０から入力されたアナログ音声信号を周知の方法で音声ディジタルデータに変換する音声入力処理部１７０と、音声入力処理部１７０で生成された音声ディジタルデータを格納する送信データバッファ１８０とを有する。
【００１６】
また、通信部１００は、無線信号からパケットデータを抽出する受信部１０１と、送信データバッファ１８０に格納されている音声ディジタルデータをパケットにして無線信号で送出する送信部１０３と、受信部１０１及び送信部１０３を制御することによって他の無線通信端末装置との所定のプロトコルによる通信を可能にする通信制御部１０２と、通信制御部１０２によって用いられる、他の無線通信端末装置についての情報を格納する通信管理ＤＢ１０４とを有する。なお、受信部１０１は、受信バッファ１０１１を有しており、受信したパケットを一旦受信バッファ１０１１に格納すると共に、自無線通信端末装置宛のパケットについてはペイロード部分をジッタバッファ１１０に格納する。また、通信制御部１０２は音声出力制御部１４０と連携するようになっている。
【００１７】
また、音声出力処理部１２０は、音声出力制御部１４０による指示に従ってデータ補完処理（パケット補完処理とも呼ぶ）を実施するＰＬＣ（Packet Loss Concealment）部１２１を含む。
【００１８】
次に、図３乃至図７を用いてアドホックネットワークにおける通信方式について概略を説明する。図３では、図１に示した端末のうち一部の端末について初期設定を行う段階について説明している。まず、端末ａ−２の送信部１０３は、通信制御部１０２の指示に応じて、自端末が管理者端末になれるかを問い合わせる判定パケット（例えば電話番号を含む）をブロードキャスト又はマルチキャストする（ステップ（１））。端末ａ−１の受信部１０１は、判定パケットを端末ａ−２から受信すると、判定パケットのデータを通信制御部１０２に出力する。ここで、所定のルール（例えば電話番号やＩＰアドレスの大小関係）にて、端末ａ−２が管理者端末となるか否かを判断する。ここでは端末ａ−１には電話番号４０００が割り当てられており、端末ａ−２には電話番号４００１が割り当てられているとすると、電話番号４０００以上４１００番未満においてより小さい電話番号が割り当てられている端末ａ−１が管理者端末になるべきと判断し、端末ａ−１の通信制御部１０２は、拒否パケットを送信部１０３に、端末ａ−２へ送信させる（ステップ（２））。端末ａ−２の受信部１０１は、端末ａ−１から拒否パケットを受信し、通信制御部１０２に出力する。これにより、管理者端末になれないことが分かる。
【００１９】
また、端末ａ−１の送信部１０３は、通信制御部１０２の指示に応じて、自端末が管理者端末になれるかを問い合わせる判定パケットをマルチキャスト又はブロードキャストする（ステップ（３））。端末ａ−２の受信部１０１は、判定パケットを端末ａ−１から受信すると、判定パケットのデータを通信制御部１０２に出力する。上で述べたルールに従って、端末ａ−１の方が電話番号が小さいので、端末ａ−１からの要求は妥当であるとして、端末ａ−２の通信制御部１０２は、許可パケットを送信部１０３に、端末ａ−１へ送信させる（ステップ（４））。端末ａ−１の受信部１０１は、端末ａ−２から許可パケットを受信し、通信制御部１０２に出力する。
【００２０】
このようなやりとりに基づき、端末ａ−２については非管理者端末であって端末ａ−１に管理されるということが、端末ａ−２の通信制御部１０２により通信管理ＤＢ１０４に登録される。また、端末ａ−１については管理者端末であって端末ａ−２を管理するということが、端末ａ−１の通信制御部１０２により通信管理ＤＢ１０４に登録される。通信管理ＤＢ１０４に登録されるデータについては、後に説明する。
【００２１】
また、上ではその都度管理者端末であるか否かを判断するようになっているが、予め管理者端末である端末には管理者端末であることを設定しておき、非管理者端末である端末についてはステップ（１）及び（２）を実施するようにしても良い。
【００２２】
また、管理者端末である端末ａ−１の通信制御部１０２は、送信部１０３に判定パケットをマルチキャスト又はブロードキャストさせる（ステップ（５））。端末ｂ−１の受信部１０１は、端末ａ−１から判定パケットを受信すると、判定パケットのデータを通信制御部１０２に出力する。端末ｂ−１は、例えば電話番号４１００が割り当てられており、管理者端末になるので、端末ｂ−１の通信制御部１０２は、拒否パケットを送信部１０３に、端末ａ−１へ送信させる（ステップ（６））。端末ａ−１の受信部１０１は、端末ｂ−１から拒否パケットを受信し、通信制御部１０２に出力する。これにより端末ａ−１の通信制御部１０２は、端末ｂ−１が管理者端末であると判断する。
【００２３】
また、端末ｂ−２の送信部１０３は、通信制御部１０２の指示に応じて、判定パケットをマルチキャスト又はブロードキャストする（ステップ（７））。端末ｂ−１の受信部１０１は、判定パケットを端末ｂ−２から受信すると、判定パケットのデータを通信制御部１０２に出力する。ここでは端末ｂ−２には電話番号４１０１が割り当てられているとすると、電話番号４１００番台においてより小さい電話番号が割り当てられている端末ｂ−１が管理者端末になるべきと判断し、端末ｂ−１の通信制御部１０２は、拒否パケットを送信部１０３に、端末ｂ−２へ送信させる（ステップ（８））。端末ｂ−２の受信部１０１は、端末ｂ−１から拒否パケットを受信し、通信制御部１０２に出力する。これにより端末ｂ−２は、管理者端末になれないことを認識する。
【００２４】
さらに、端末ｂ−１の送信部１０３は、通信制御部１０２の指示に応じて、自端末が管理者端末になれるかを問い合わせる判定パケットをマルチキャスト又はブロードキャストする（ステップ（９））。端末ｂ−２の受信部１０１は、判定パケットを端末ｂ−１から受信すると、判定パケットのデータを通信制御部１０２に出力する。上で述べたルールに従って、端末ｂ−１の方が電話番号が小さいので、端末ｂ−１からの要求は妥当であるとして、端末ｂ−２の通信制御部１０２は、許可パケットを送信部１０３に、端末ｂ−１へ送信させる（ステップ（１０））。端末ｂ−１の受信部１０１は、端末ｂ−２から許可パケットを受信し、通信制御部１０２に出力する。
【００２５】
このようなやりとりに基づき、端末ｂ−２については非管理者端末であって端末ｂ−１に管理されるということが、端末ｂ−２の通信制御部１０２により通信管理ＤＢ１０４に登録される。また、端末ｂ−１については管理者端末であって端末ｂ−２を管理するということが、端末ｂ−１の通信制御部１０２により通信管理ＤＢ１０４に登録される。
【００２６】
さらに、管理者端末である端末ｂ−１の通信制御部１０２は、送信部１０３に判定パケットをマルチキャスト又はブロードキャストさせる（ステップ（１１））。端末ａ−１の受信部１０１は、端末ｂ−１から判定パケットを受信すると、判定パケットのデータを通信制御部１０２に出力する。端末ａ−１は、例えば電話番号４０００が割り当てられており、管理者端末であるので、端末ａ−１の通信制御部１０２は、拒否パケットを送信部１０３に、端末ｂ−１へ送信させる（ステップ（１２））。端末ｂ−１の受信部１０１は、端末ａ−１から拒否パケットを受信し、通信制御部１０２に出力する。これにより端末ｂ−１の通信制御部１０２は、端末ａ−１が管理者端末であると判断する。
【００２７】
なお、非管理者端末は、自己を管理している近隣の管理者端末とは定期的に生存確認を行う。具体的には、端末ａ−２の通信制御部１０２は、送信部１０３に生存確認パケット（KeepAliveパケット）を、自己を管理する近隣の管理者端末である端末ａ−１へ送信させる（ステップ（１３））。端末ａ−１の受信部１０１は、端末ａ−２から生存確認パケットを受信すると、通信制御部１０２に出力し、通信制御部１０２はこれによって通信管理ＤＢ１０４の更新が必要ないことを確認した上、送信部１０３にＡＣＫパケットを端末ａ−２へ送信させる（ステップ（１４））。端末ａ−２は、ＡＣＫパケットを受信して、管理者端末が生存しており通信管理ＤＢ１０４の更新が必要ないことを確認する。
【００２８】
同様に、端末ｂ−２の通信制御部１０２は、送信部１０３に生存確認パケット（KeepAliveパケット）を、自己を管理する近隣の管理者端末である端末ｂ−１へ送信させる（ステップ（１５））。端末ｂ−１の受信部１０１は、端末ｂ−２から生存確認パケットを受信すると、通信制御部１０２に出力し、通信制御部１０２はこれによって通信管理ＤＢ１０４の更新が必要ないことを確認した上、送信部１０３にＡＣＫパケットを端末ｂ−２へ送信させる（ステップ（１６））。端末ｂ−２は、ＡＣＫパケットを受信して、管理者端末が生存しており通信管理ＤＢ１０４の更新が必要ないことを確認する。
【００２９】
また、近隣の管理者端末同士は、例えば定期的に自身の有する管理情報を交換して、ルーティングなどに利用する。具体的には、端末ａ−１の通信制御部１０２は、通信管理ＤＢ１０４から自己の無線通信可能範囲に入っている端末の情報を読み出し、これを管理情報として含む管理情報通知パケットを送信部１０３に、近隣の管理者端末である端末ｂ−１へ送信させる（ステップ（１７））。端末ｂ−１の受信部１０１は、端末ａ−１から管理情報通知パケットを受信すると、通信制御部１０２に出力する。通信制御部１０２は、受信パケットの管理情報を通信管理ＤＢ１０４に登録すると共に、自己の無線通信可能範囲に入っている端末の情報を読み出し、これを管理情報として含む管理情報通知パケットを送信部１０３に、端末ａ−１へ送信させる（ステップ（１８））。端末ａ−１の受信部１０１は、端末ａ−１から管理情報通知パケットを受信すると、通信制御部１０２に出力する。通信制御部１０２は、受信パケットの管理情報を通信管理ＤＢ１０４に登録する
【００３０】
端末ａ−１の通信管理ＤＢ１０４には、例えば図４乃至図６に示すようなデータが格納される。図４は、端末ａ−１が必ず管理することになっている端末についての情報を示す。図１の説明でも述べたように、端末ａ−１には内線番号４０００が割り当てられており、内線番号４０００以上４１００未満の端末については無線通信可能な範囲にいない場合においても必ず情報を取得して通信管理ＤＢ１０４に登録する。図４に示すように、端末ａ−２乃至ａ−４は、端末ａ−１が必ず管理する端末として登録されている端末である。そして、これらの端末の各々について、管理者／非管理者の別と、電話番号（内線番号）、ＩＰアドレス、サブネットマスク、ゲートウェイ、及び端末ａ−１までのホップ数とが登録されるようになっている。なお、端末ａ−４については、端末ａ−１の無線通信可能範囲Ａには入っていないので、探索した結果又は端末ａ−４からの情報通知によってホップ数「４」離れたところに現在存在しているということが分かっている。
【００３１】
また、図１の説明でも述べたが、管理者端末である端末ｂ−１及びｃ−１についても端末ａ−１の無線通信可能範囲Ａに入っているので、これらの端末の情報についても通信管理ＤＢ１０４には管理情報として登録される。但し、これらは管理者端末であるので、それらが有する管理情報も取得して保持している。具体的には、図５に示すように、端末ｂ−１そのものの情報として、管理者／非管理者の別と、電話番号（内線番号）と、ＩＰアドレスと、サブネットマスクと、ゲートウェイと、端末ａ−１までのホップ数とが登録されており、さらに、端末ｂ−１の無線通信可能範囲Ｂ内の端末ａ−１、ｂ−２、ｂ−３及びｄ−１の管理情報も含まれる。各端末の管理情報自体は、端末ａ−１の管理情報と同じである。なお、ホップ数は、端末ｂ−１を基準にしたホップ数であるから、端末ａ−１からのホップ数であれば、端末ｂ−１までのホップ数「１」と端末ｂ−１からのホップ数「１」を加算して「２」と判断しなければならない。
【００３２】
同様に、端末ｃ−１の管理情報は図６に示すように、端末ｃ−１についての管理者／非管理者の別と、電話番号（内線番号）と、ＩＰアドレスと、サブネットマスクと、ゲートウェイと、ホップ数とが登録されている。さらに、端子ｃ−１の無線通信可能範囲Ｃ内の端末ａ−１、ａ−３、ｃ−２及びｄ−１の管理情報も含まれるようになっている。
【００３３】
さらに、非管理者端末である端末ａ−２には、例えば、図７に示すようなデータが、通信管理ＤＢ１０４に格納される。具体的には、端末ａ−２は非管理者端末であるので、予め定められた端末についての管理情報は存在せず、図７ではＮＵＬＬとなっている。また、管理者情報として、通信範囲内における管理者端末である端末ａ−１についての情報が登録されている。具体的には、管理者／非管理者の別と、電話番号（内線番号）と、ＩＰアドレスと、サブネットマスクと、ゲートウェイと、ホップ数とが登録されている。このように、近隣の管理者端末の情報を登録しておき、通話の際には管理者端末に通話先を指定したリクエストを送信し、通話先の端末にリクエストを転送してもらう。
【００３４】
本実施の形態では、このように予め管理しなければならないと設定されている端末以外は、最大ホップ数「２」の範囲の情報しか保持しないようになっているが、範囲を広げて管理者端末で管理情報の交換を重ねてアドホックネットワーク全体又は一部であってもより広い範囲についての管理情報を、通信管理ＤＢ１０４に保持するようにしても良い。
【００３５】
本実施の形態では、通信管理ＤＢ１０４に保持されている管理情報で探索できる範囲については、通信管理ＤＢ１０４を用いて最短経路を特定して端末間の通話を実施する。但し、端末間で直接無線通信できる場合には、管理者端末を経由せずに通話を行うように切り替えても良い。
【００３６】
さらに、無線通信端末装置の通信制御部１０２は、自無線通信端末装置宛でないパケット等を受信した場合には、受信部１０１の受信バッファ１０１１に格納されているパケットを読み出して送信部１０３に送出させる処理も実施する。
【００３７】
アドホックネットワークにおける初期段階の通信処理の概略は以上であり、次に、具体的に無線通信端末装置間で通話する際の処理について説明する。例えば、端末ａ−２が端末ｂ−２に通話を要求する際の処理について図８を用いて説明する。まず、端末ａ−２の通信制御部１０２は、例えばユーザからの電話番号４１０１の入力及び発信の指示に応じて、発信元端末の電話番号４００１（場合によってはＩＰアドレス）及び通話先の電話番号４１０１を含み且つホップ数（初期値＝０）をカウントするためのカウンタが付された発信要求パケットを送信部１０３に、通信管理ＤＢ１０４に登録されており近隣の管理者端末である端末ａ−１へ送信させる（ステップ（３１））。端末ａ−１の受信部１０１は、端末ａ−２から発信要求パケットを受信し、通信制御部１０２に発信要求パケットのデータを出力する。通信制御部１０２は、発信要求パケットに含まれる通話先端末の電話番号で通信管理ＤＢ１０４を検索して該当するデータが存在するか判断する。今回の場合には、端末ｂ−１の配下に電話番号４１０１の端末ｂ−２が存在していることが分かる。従って、通信制御部１０２は、ホップ数を１インクリメントして「１」にした発信要求パケットを、端末ｂ−１へ送信するように送信部１０３に指示する。送信部１０３は、指示に応じて発信要求パケットを端末ｂ−１に送信する（ステップ（３２））。
【００３８】
端末ｂ−１の受信部１０１は、端末ａ−１から電話番号４１０１宛の発信要求パケットを受信すると、通信制御部１０２に出力する。通信制御部１０２は、発信要求パケットに含まれる電話番号４１０１で通信管理ＤＢ１０４を検索すると、配下に該当する端末ｂ−２が存在するが分かる。従って、通信制御部１０２は、ホップ数をさらに１インクリメントして「２」にした発信要求パケットを、端末ｂ−２へ送信するように送信部１０３に指示する。送信部１０３は、指示に応じて発信要求パケットを端末ｂ−２に送信する（ステップ（３３））。
【００３９】
端末ｂ−２の受信部１０１は、端末ｂ−１から電話番号４１０１宛の発信要求パケットを受信すると、通信制御部１０２に出力する。通信制御部１０２は、発信要求パケットの宛先が自無線通信端末装置であることを認識し、他の端末と通話中でなければ例えば呼出中を表し、端末ａ−２の電話番号等を宛先として含み且つホップ数（初期値＝０）をカウントするためのカウンタが付されたレスポンス・パケットを、管理者端末である端末ｂ−１へ送信するように送信部１０３に指示する。送信部１０３は、指示に応じてレスポンス・パケットを端末ｂ−１に送信する（ステップ（３４））。なお、通信制御部１０２は、発信要求パケットに含まれる送信元の電話番号等と共にホップ数（ここでは「２」）を１インクリメントした値「３」を、音声出力制御部１４０に出力し、音声出力制御部１４０は、ワークメモリ領域などに格納しておく。
【００４０】
端末ｂ−１の受信部１０１は、端末ｂ−２から電話番号４００１宛のレスポンス・パケットを受信すると、通信制御部１０２に出力し、通信制御部１０２は通信管理ＤＢ１０４に基づき、端末ａ−１へホップ数を１インクリメントして「１」にしたレスポンス・パケットを送信部１０３に送信させる（ステップ（３５））。
【００４１】
端末ａ−１の受信部１０１は、端末ｂ−１から電話番号４００１宛のレスポンス・パケットを受信すると、通信制御部１０２に出力し、通信制御部１０２は通信管理ＤＢ１０４に基づき、端末ａ−２へホップ数を１インクリメントして「２」にしたレスポンス・パケットを送信部１０３に送信させる（ステップ（３６））。
【００４２】
端末ａ−２の受信部１０１は、端末ａ−１からレスポンス・パケットを受信すると、通信制御部１０２に出力し、通信制御部１０２は、自無線通信端末装置宛のレスポンス・パケットであると認識すると共に、通話可能である又は通話不可能であるか判別する。さらに、レスポンス・パケットに含まれるホップ数「２」を１インクリメントしたホップ数「３」を、例えばワークメモリ領域などに格納すると共に、音声出力制御部１４０に出力する。音声出力制御部１４０の処理については、以下で詳しく述べる。
【００４３】
この後については、例えば通話可能である場合には、通話先の端末ｂ−２のユーザの通話指示に応じて当該端末ｂ−２からＯＫレスポンス等を送信することによって接続を確立する。但し、端末ｂ−２のユーザからの通話指示に応じて、端末ｂ−２がレスポンス・パケットを送信するようにして、レスポンス・パケットを端末ａ−２が受信したところで接続を確立するようにしても良い。さらに、レスポンス・パケットに応じて、端末ａ−２がＡＣＫパケットなどを送信してＡＣＫパケットを端末ｂ−２が受信した時点で接続を確立するようにしても良い。また、端末ａ−２がＡＣＫパケットなどを送信する場合には、発信要求パケットにホップ数のカウンタを含めるのではなく、ＡＣＫパケットなどにホップ数のカウンタを設けるようにしても良い。さらに、ホップ数を、周知のＴＴＬ（Time to Live）を用いて算出するようにしても良い。すなわち、予め固定のＴＴＬを設定してパケットを送信し、この固定のＴＴＬと宛先でのＴＴＬとの差をホップ数として特定するようにしても良い。
【００４４】
なお、通信管理ＤＢ１０４に保持されている管理情報で探索できない範囲にいる端末に対する発信要求パケットを受信した場合には、他の管理者端末に通話先端末の存在について問い合わせをブロードキャスト又はマルチキャストして、その返信からどのような管理者の配下に存在しているかを経路と共に特定する。そして、最短経路を特定して発信要求パケットをその経路に従って送信する。その後は、基本的には上で述べたとおりの処理を行う。但し、経路データについては送信パケットに含めるようにしても良い。
【００４５】
次に、通話中の音声データの処理について説明する。基本的には、受信部１０１が受信し且つ音声データを含む自無線通信端末装置宛のパケットは、受信バッファ１０１１に格納される。例えば、到着順番が入れ替わっているような場合などは、この受信バッファ１０１１で入れ替える処理を行う。そして、パケットの音声データ部分（すなわちペイロード）をジッタバッファ１１０に格納する。ジッタバッファ１１０のサイズは、以下で述べるように音声出力制御部１４０によって制御される。ジッタバッファ１１０に格納されている音声データは、音声出力処理部１２０によって復号化されて音声アナログ信号に変換されて、スピーカ１３０から出力される。
【００４６】
よく知られているように、ジッタバッファ１１０は、パケットの受信タイミングの遅延やゆらぎを吸収するためのバッファであり、大きなサイズであるほど大きな遅延やゆらぎに対応できるが、再生遅延が大きくなるという問題がある。全体のメモリ量を削減するという観点を併せても、できる限り小さいサイズであることが好ましい。一方で、アドホックネットワークは不安定で環境の影響を受け易いため、図９に示すように、ホップ数が増加すると、それに応じてパケットの受信遅延時間（又は受信ゆらぎ時間）は増加する。従って、これに対応するため、音声出力制御部１４０は、図１０に示すように、ホップ数が多ければジッタバッファサイズを大きくし、ホップ数が少なければジッタバッファサイズを小さくするような制御を行うことが好ましい。
【００４７】
従って、図８に示したように通話開始直前にホップ数を発信元及び発信先の端末で把握して、そのホップ数に応じてジッタバッファサイズを設定する。さらに、アドホックネットワークでは、通話中にネットワーク構成が変化してホップ数が変化する可能性がある。従って、通話中もホップ数を定期的又は任意のタイミングでカウントして、変化があれば変化に応じてジッタバッファサイズを動的に変更する。このため、音声出力制御部１４０は、通信制御部１０２からホップ数のデータを受け取ると、例えばワークメモリ領域などにホップ数の履歴を格納する。
【００４８】
具体的な処理フローを図１１に示す。まず、通話を行う端末間の接続が完了する前に、通信制御部１０２は、ホップ数を受信パケットから取得して音声出力制御部１４０に出力する。また、管理者端末が発信元の場合であって、通信管理ＤＢ１０４に登録されている端末と通話を行う場合には、通信管理ＤＢ１０４にホップ数が予め登録されているので、通信制御部１０２は、通信管理ＤＢ１０４に登録されているホップ数から通話先端末までのホップ数を特定するようにしてもよい。直接通信できる範囲内の端末と通話を行う場合には、ホップ数は「１」であるが、他の管理者端末を経由する場合には、他の管理者端末までのホップ数「１」を加算しないと、通話先端末までのホップ数は得られない。いずれにせよ、特定されたホップ数を音声出力制御部１４０に出力する。
【００４９】
音声出力制御部１４０は、通信制御部１０２から通話先端末までのホップ数を取得し（ステップＳ１）、例えば初期値テーブル１５０に登録されているジッタバッファサイズ・テーブルから、取得されたホップ数に該当するバッファサイズを読み出して、ジッタバッファ１１０のサイズを設定する（ステップＳ３）。
【００５０】
ジッタバッファサイズ・テーブルの一例を図１２に示す。図１２の例では、ホップ数に対応して、測定結果等に基づき予め定められたジッタバッファサイズが格納されている。ここで、ｂ1＜ｂ2＜ｂ3＜ｂ4となっている。図１２の例のように、ホップ数の複数の数値に対して１のジッタバッファサイズが対応付けられる場合もあれば、ホップ数の各々に対して１のジッタバッファサイズが対応付けられるようになる場合もある。
【００５１】
このような設定を行うことによって、ホップ数が多い場合でもパケット受信の遅延やゆらぎに対処できるようになり、またホップ数が少ない場合であれば使用メモリ量を少なくして、再生遅延を抑えることができるようになる。また、場合によって使用していないメモリに対する電力供給を停止するなどして、消費電力を抑えることも可能な場合もある。
【００５２】
その後通話が始まって音声データを含むパケットのやりとりが行われる。全てのパケットでなくともよいが、通話中におけるアドホックネットワークの構成変化に備えて、定期的に又は任意のタイミングでホップ数をカウントするためのカウンタ付きのパケットを送信して、ホップ数に変化がないか確認する。上でも述べたが、ＴＴＬを用いてホップ数を特定しても良い。
【００５３】
すなわち、通信制御部１０２は、受信パケットからホップ数を抽出し、音声出力制御部１４０に出力し、音声出力制御部１４０は、通信制御部１０２からホップ数のデータを受け取るとワークメモリ領域などに格納に格納する（ステップＳ５）。そして、今回のホップ数は、ワークメモリ領域などに格納されている前回のホップ数と一致しているか判断する（ステップＳ７）。一致している場合にはステップＳ１５に移行する。
【００５４】
一方、一致していない場合には、音声出力制御部１４０は、今回のホップ数が前回のホップ数より増加しているか判断する（ステップＳ９）。増加していれば、ジッタバッファサイズを所定量増加するように設定する（ステップＳ１１）。例えば、測定結果などに基づき予め決定した量を所定量としてワークメモリ領域などに保持しておき、その所定量だけ増加させるようにしても良いし、例えば図１２に示したようなジッタバッファサイズ・テーブルに基づき新たなホップ数に対応するジッタバッファサイズを特定して、その値になるようにジッタバッファサイズを増加させても良い。そしてステップＳ１５に移行する。
【００５５】
一方、増加ではなく減少している場合には、音声出力制御部１４０は、ジッタバッファサイズを所定量減少させるように設定する（ステップＳ１３）。所定量は増加させる場合と同じであっても良いし、異なるようにしても良い。予めワークメモリ領域などに保持しておき、それに基づき設定するようにしてもよいし、ジッタバッファサイズ・テーブルに基づき新たなホップ数に対応するジッタバッファサイズを特定して、その値になるようにジッタバッファサイズを減少させるようにしても良い。そしてステップＳ１５に移行する。
【００５６】
ステップＳ１５では、通話終了であるかを通信制御部１０２が確認し、通話中であればステップＳ５に戻って処理を継続する。一方、通話終了であれば、処理は終了する。
【００５７】
このようにすれば、通話相手までの初期的なホップ数に応じてジッタバッファサイズを設定して、ホップ数に応じたパケット受信の遅延などに備えることができるようになる。さらに、動的に構成変化が予測されるアドホックネットワークにおいては、通話中でもホップ数を観測して、必要に応じて動的にジッタバッファサイズを増減させ、適応的且つ安定的に音声再生を行うようにする。
【００５８】
また、アドホックネットワークではパケット受信の遅延やゆらぎだけではなく、パケットロスも問題となる。すなわち、ホップ数が増加すると、通信距離が増加し、それに伴って通信経路上の他の機器の過負荷などによる通信バッファあふれや、受信バッファあふれ、ノイズ障害などによりパケットロスが発生しやすくなる。パケットロス数も、図１３に示すように、ホップ数が増加するとそれに応じて増加する。従って、このような問題にも対処する必要がある。
【００５９】
既に、パケットロスに対処するためパケットロス補完（ＰＬＣ）技術が存在している。例えば、図１４に示すような音声信号（縦軸：振幅、横軸：時間）を再生する場合に、パケットロスが発生すると、例えば点線部分の信号を再生できなくなる。このため、パケットロス補完技術によって、パケットロス部分を例えば前後のデータから推定して復元する。但し、当然ながら完全に補完できるわけではなく、補完精度が低ければ音声品質が低下してしまう。補完精度は、ロスしたパケット数が増加すれば低くなり、可能な限り補完データサイズについては少ない方が好ましい。
【００６０】
従って、本実施の形態では、図１５に示すように最大補完データサイズを、ホップ数が増加するのに応じて増加するように設定することによって、ホップ数に応じて音声のとぎれを防止するようにする。例えば、図１４が少ないホップ数の場合の例だとすると、ホップ数が多い場合には、図１６に示すように、補完データサイズを多くして、より長い時間の音声信号を補完によって生成する。
【００６１】
具体的には、図１７に示すような処理を実施する。まず、通話を行う端末間の接続が完了する前に、通信制御部１０２は、ホップ数を受信パケットから取得して音声出力制御部１４０に出力する。また、管理者端末が発信元の場合であって、通信管理ＤＢ１０４に登録されている端末と通話を行う場合には、通信管理ＤＢ１０４にホップ数が予め登録されているので、通信制御部１０２は、通信管理ＤＢ１０４に登録されているホップ数から通話先端末までのホップ数を特定するようにしてもよい。直接通信できる範囲内の端末と通話を行う場合には、ホップ数は「１」であるが、他の管理者端末を経由する場合には、他の管理者端末までのホップ数「１」を加算しないと、通話先端末までのホップ数は得られない。いずれにせよ、特定されたホップ数を音声出力制御部１４０に出力する。
【００６２】
音声出力制御部１４０は、通信制御部１０２から通話先端末までのホップ数を取得し（ステップＳ２１）、例えば初期値テーブル１５０に登録されている補完データサイズ・テーブルから、取得されたホップ数に該当する最大補完データサイズを読み出して、ＰＬＣ部１２１に設定する（ステップＳ２３）。
【００６３】
補完データサイズ・テーブルの一例を図１８に示す。図１８の例では、ホップ数に対応して、測定結果等に基づき予め定められた最大補完データサイズが格納されている。ここで、ｃ1＜ｃ2＜ｃ3＜ｃ4となっている。なお、ジッタバッファサイズと同様に、ホップ数の複数の数値に対して１の補完データサイズが対応付けられる場合もあれば、ホップ数の各々に対して１の補完データサイズが対応付けられるようになる場合もある。
【００６４】
このような設定を行うことによって、ホップ数が多い場合でも長いパケットロスに対処して音声のとぎれを抑えることができるようになり、またホップ数が少ない場合であれば補完データサイズを抑えて低品質の再生をあまり行わないようにする。
【００６５】
その後通話が始まって音声データを含むパケットのやりとりが行われる。全てのパケットでなくともよいが、通話中におけるアドホックネットワークの構成変化に備えて、定期的に又は任意のタイミングでホップ数をカウントするためのカウンタ付きのパケットを送信して、ホップ数に変化がないか確認する。ＴＴＬを用いてホップ数を特定しても良いのは前に述べたとおりである。
【００６６】
すなわち、通信制御部１０２は、受信パケットからホップ数を抽出し、音声出力制御部１４０に出力し、音声出力制御部１４０は、通信制御部１０２からホップ数のデータを受け取るとワークメモリ領域などに格納に格納する（ステップＳ２５）。そして、今回のホップ数は、ワークメモリ領域などに格納されている前回のホップ数と一致しているか判断する（ステップＳ２７）。一致している場合にはステップＳ３５に移行する。
【００６７】
一方、一致していない場合には、音声出力制御部１４０は、今回のホップ数が前回のホップ数より増加しているか判断する（ステップＳ２９）。増加していれば、最大補完データサイズを所定量増加するように設定する（ステップＳ３１）。例えば、測定結果などに基づき予め決定した量を所定量としてワークメモリ領域などに保持しておき、その所定量だけ増加させるようにしても良いし、例えば図１８に示したような補完データサイズ・テーブルに基づき新たなホップ数に対応する最大補完データサイズを特定して、その値になるように最大補完データサイズを増加させても良い。そしてステップＳ３５に移行する。
【００６８】
一方、増加ではなく減少している場合には、音声出力制御部１４０は、最大補完データサイズを所定量減少させるように設定する（ステップＳ３３）。所定量は増加させる場合と同じであっても良いし、異なるようにしても良い。予めワークメモリ領域などに保持しておき、それに基づき設定するようにしてもよいし、補完データサイズ・テーブルに基づき新たなホップ数に対応する最大補完データサイズを特定して、その値になるように最大補完データサイズを減少させるようにしても良い。そしてステップＳ３５に移行する。
【００６９】
ステップＳ３５では、通話終了であるかを通信制御部１０２が確認し、通話中であればステップＳ２５に戻って処理を継続する。一方、通話終了であれば、処理は終了する。
【００７０】
このようにすれば、通話相手までの初期的なホップ数に応じて最大補完データサイズを設定して、ホップ数に応じたパケットロスに備えることができるようになる。さらに、動的に構成変化が予測されるアドホックネットワークにおいては、通話中でもホップ数を観測して、必要に応じて動的に最大補完データサイズを増減させ、適応的且つ安定的に音声再生を行うようにする。
【００７１】
［他の実施の形態］
上で述べた実施の形態では、アドホックネットワークを最初から構築する場合について述べたが、例えば通常は従前から存在しているＳＩＰサーバなどを利用した無線のＩＰ電話として動作させて、ＳＩＰサーバ等やアクセスポイントの機器が故障した場合に、アドホックネットワークに移行するような構成にしてもよい。安定性などの観点からＳＩＰサーバ等を導入するが、非常時にはアドホックネットワークを即座に構築してＳＩＰサーバ等が復旧するまでの間においても内線通話を可能にするものである。
【００７２】
この場合のシステム構成を図１９に模式的に示す。有線ＬＡＮには、サーバｓ１、ＩＰ電話機ｆ−１乃至ｆ−３、無線アクセスポイントＡＰｘ−１などが接続されている。この状態であれば、従来と何ら変わらない。但し、ＩＰ電話機ｆ−１乃至ｆ−３については特に必要ないが、無線通信端末装置である端末ａ−１乃至ａ−３、端末ｂ−１及びｂ−２並びに端末ｃ−１及びｃ−２については、アクセスポイントＡＰｘ−１を介してサーバｓ１に生存確認パケットを例えば定期的に送信し、サーバｓ１からＡＣＫパケットを受信することによって、互いが通信可能な状態にあるかどうかを確認する必要がある。
【００７３】
具体的には図２０に示すような処理を実施する。なお、説明を簡単にするために無線通信端末装置は端末ａ−１及びａ−２、端末ｂ−１及びｂ−２についてのみ説明する。端末ａ−２の通信制御部１０２は、例えば定期的に、送信部１０３に、サーバｓ１宛に生存確認パケット（KeepAlive）を送信させる（ステップ（４１））。これに対して、サーバｓ１は、端末ａ−２から生存確認パケットを受信すると、ＡＣＫパケットを端末ａ−２に対して送信する（ステップ（４２））。端末ａ−２の受信部１０１は、ＡＣＫパケットを受信すると通信制御部１０２に出力し、通信制御部１０２はＡＣＫパケットを受け取ったことによってサーバｓ１と通信可能な状態にいることを確認する。
【００７４】
同様に、端末ｂ−２の通信制御部１０２は、例えば定期的に、送信部１０３に、サーバｓ１宛に生存確認パケット（KeepAlive）を送信させる（ステップ（４３））。これに対して、サーバｓ１は、端末ｂ−２から生存確認パケットを受信すると、ＡＣＫパケットを端末ｂ−２に対して送信する（ステップ（４４））。端末ｂ−２の受信部１０１は、ＡＣＫパケットを受信すると通信制御部１０２に出力し、通信制御部１０２はＡＣＫパケットを受け取ったことによってサーバｓ１と通信可能な状態にいることを確認する。
【００７５】
さらに、端末ａ−１の通信制御部１０２は、例えば定期的に、送信部１０３に、サーバｓ１宛に生存確認パケット（KeepAlive）を送信させる（ステップ（４５））。これに対して、サーバｓ１は、端末ａ−１から生存確認パケットを受信すると、ＡＣＫパケットを端末ａ−１に対して送信する（ステップ（４６））。端末ａ−１の受信部１０１は、ＡＣＫパケットを受信すると通信制御部１０２に出力し、通信制御部１０２はＡＣＫパケットを受け取ったことによってサーバｓ１と通信可能な状態にいることを確認する。
【００７６】
また、端末ｂ−１の通信制御部１０２は、例えば定期的に、送信部１０３に、サーバｓ１宛に生存確認パケット（KeepAlive）を送信させる（ステップ（４７））。これに対して、サーバｓ１は、端末ｂ−１から生存確認パケットを受信すると、ＡＣＫパケットを端末ｂ−１に対して送信する（ステップ（４８））。端末ｂ−１の受信部１０１は、ＡＣＫパケットを受信すると通信制御部１０２に出力し、通信制御部１０２はＡＣＫパケットを受け取ったことによってサーバｓ１と通信可能な状態にいることを確認する。
【００７７】
通話を行わない場合においても、例えば定期的に上で述べたような処理を繰り返して、サーバも無線通信端末装置も互いに通信可能なことを確認する。
【００７８】
その後、サーバｓ１がダウンしたものとする。そうすると、端末ａ−１及びａ−２並びに端末ｂ−１及びｂ−２が、生存確認パケットを送信してもＡＣＫパケットがサーバｓ１から返ってこなくなる（ステップ（４９）乃至（５２））。
【００７９】
そうすると、各端末の通信制御部１０２は、サーバダウンを認識して、アドホックネットワークを構築するモードに移行する。すなわち、図３の処理に移行する。このようにすれば、上で述べたようにサーバダウンに応じてアドホックネットワークを速やかに構築して、アドホックネットワークを介した通話を可能にする。そして、アドホックネットワークが構築されると、上で述べた実施の形態のように、ジッタバッファサイズの調整や、補完データサイズの調整も必要となる。
【００８０】
例えば、通信制御部１０２は、図２１のような処理を行って、図１１や図１７に示すような処理を行うか否かを判断する。具体的には、通信制御部１０２は、現在の通信モードはアドホックネットワークを介して通話を行うアドホック接続モードであるか判断する（ステップＳ５１）。アドホック接続モードでなくサーバを用いた通信モードである場合には、ジッタバッファサイズ等の固定モードを音声出力制御部１４０に設定する（ステップＳ５５）。そしてステップＳ５７に移行する。
【００８１】
一方、アドホック接続モードである場合には、通信制御部１０２は、ジッタバッファサイズ等の動的変更モードを音声出力制御部１４０に設定する（ステップＳ５３）。そしてステップＳ５７に移行する。このようなモードに移行した場合には、通話を開始する際及び通話中には図１１や図１７の処理を実施することになる。
【００８２】
ステップＳ５７に移行して、通信制御部１０２は、処理終了か判断し（ステップＳ５７）、ステップＳ５１に戻る。一方、処理終了であれば処理を終了する。
【００８３】
なお、生存確認パケットについては、例えば定期的にダウン中であってもサーバ宛に送信して、復旧したか否かを監視しておく。そして、サーバやアクセスポイントの機器が復旧した場合には、ＡＣＫパケットをサーバから受け取ることができるようになるので、ＡＣＫパケットを受信すれば、アドホックネットワークを解体して、通常のＩＰ電話システムに戻るようにする。すなわち、通信管理ＤＢ１０４の管理データを破棄する。
【００８４】
これによってモードを切り替えて、必要なときにジッタバッファサイズや補完データサイズを調整できるようになる。
【００８５】
さらに、無線アクセスポイントの無線通信可能範囲に入っている無線通信端末装置については、従来と同じようにサーバを用いて端末間での通話を行うが、無線アクセスポイントの無線通信可能範囲に入らない無線通信端末装置についてはアドホックネットワークを部分的に構築するような実施態様も可能である。
【００８６】
例えば図２２に示すように、無線アクセスポイントＡＰｘ−１の無線通信可能範囲Ｘ内の端末ａ−１及びａ−３、端末ｂ−１並びに端末ｃ−１については、サーバｓ２を用いて他の端末と通話を行う。一方、無線通信可能範囲Ｘに入らない端末ａ−２、端末ｂ−２及び端末ｃ−２については、直接サーバｓ２と通信することができないので、近隣の管理者端末が中継することになる。例えば、端末ｃ−２は、近隣の管理者端末である端末ｃ−１の無線通信可能範囲Ｃに入っているので、端末ｃ−１を介してサーバｓ２を利用することとする。また、端末ａ−２であれば管理者端末である端末ａ−１を介してサーバｓ２を利用し、端末ｂ−２であれば管理者端末である端末ｂ−１を介してサーバｓ２を利用する。
【００８７】
但し、この場合サーバｓ２が存在しているので、全体がアドホックネットワークとなっている場合とは多少処理は異なる。すなわちアクセスポイントＡＰｘ−１と直接通信を行うことができない無線通信端末装置（例えば端末ｃ−２）とそのような無線通信端末装置の近隣の管理者端末として機能する無線通信端末装置（例えば端末ｃ−１）は、図３などで述べたような処理を行って、通信管理ＤＢ１０４にデータを保持することになる。端末ｃ−１の無線通信可能範囲Ｃ内に他の管理者端末が存在していれば、そのような管理者端末と管理情報の交換を行っても良い。そして、このような無線通信端末装置の近隣の管理者端末である無線通信端末装置の通信管理ＤＢ１０４で管理されている端末範囲内において無線通信端末装置間で通話を行う場合には、アドホックネットワークについて述べたのと同様の処理を実施する。すなわち、ホップ数をカウントして図１１や図１７でジッタバッファサイズや補完データサイズを調整する。
【００８８】
また、管理者端末である無線通信端末装置が管理している非管理者端末の情報については、サーバｓ２に通知しておき、管理者端末経由で通信を行うように設定する。
【００８９】
そして、端末ｃ−１のような管理者端末の通信管理ＤＢ１０４に管理されている端末範囲内の端末ではない端末間（例えば端末ｃ−２と端末ａ−１）の通話の場合には、端末ｃ−１のような管理者端末は、中継装置として機能して端末ｃ−２からの発信要求パケットを、アクセスポイントＡＰｘ−１を介してサーバｓ２に送信するようにする。そうすると、サーバｓ２は、端末ａ−１に対して発信要求パケットを転送するような形で、通常の接続確立のための処理を実施する。なお、この場合、端末ｃ−２についてのホップ数は端末ｃ−２からアクセスポイントＡＰｘ−１までのホップ数となり、端末ｃ−２については、図１１や図１７でジッタバッファサイズや補完データサイズの調整を実施する。
【００９０】
以上のように、アドホックネットワークを一部でも用いる場合には、ジッタバッファや補完データサイズの調整を行って、音声品質の向上を図るものである。
【００９１】
以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。すなわち、上で述べたネットワークを介して通信を行うプロトコルについては様々なバリエーションが可能であり、通話先の端末を正しく特定し、パケットを転送できれば、どのようなものであってもよい。
【００９２】
さらに、初期値テーブル１５０ではなく、適切なジッタバッファサイズや補完データサイズを出力する関数を用意するようにしても良い。
【００９３】
以上本実施の形態をまとめると以下のようになる。
【００９４】
第１の態様に係る無線通信端末装置は、アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、取得されたホップ数に応じてジッタバッファのサイズを決定し、設定するジッタバッファサイズ設定手段とを有する。
【００９５】
アドホックネットワークを介して他の無線通信端末装置と通話を行う場合には、ホップ数に応じてパケット受信の遅延やゆらぎなどが起こりやすくなって、出力される音声の品質を保つのが難しくなる。従って、通話先の無線通信端末からのホップ数に応じたジッタバッファサイズを設定することによって、ホップ数が多い場合にはサイズを大きくしてパケット遅延の増大等に備え、ホップ数が少ない場合にはサイズを小さくして再生遅延を少なくする。
【００９６】
また、上で述べたホップ数取得手段は、通話先の無線通信端末装置との通話途中にも、通話先の無線通信端末装置から受信したパケットからホップ数を取得するようにしてもよい。また、上で述べたジッタバッファサイズ設定手段は、ホップ数取得手段により取得された、通話途中のホップ数に応じてジッタバッファのサイズを動的に変更して設定するようにしてもよい。
【００９７】
アドホックネットワークでは、無線通信端末装置が通話中でも移動する可能性があり、通話端末間のネットワーク構成が変動する可能性がある。従って、このように初期的にジッタバッファサイズをホップ数に応じて設定するだけではなく、通話中でもホップ数の変動に応じて動的にジッタバッファサイズを変更することで、ネットワーク構成の変動に応じて適切なジッタバッファサイズで通話を実施することができるようになる。
【００９８】
さらに、第１の態様に係る無線通信端末装置は、取得されたホップ数に応じて、紛失音声データの最大補完データサイズを決定し、紛失音声データの補完を行う補完処理部に当該最大補完データサイズを設定する補完データサイズ設定手段をさらに有するようにしても良い。ホップ数が多い場合には紛失パケットの数も多くなる可能性が高いので、紛失データの補完を行う補完処理部が補完を行うデータサイズも大きくすることによって、再生音声品質の向上を図るものである。なお、補完を行うデータサイズを大きくすると精度は下がるので可能な限り小さくすべきであり、ホップ数が少ない場合には補完を行うデータサイズを小さく設定する。
【００９９】
また、上で述べたホップ数取得手段は、通話先の無線通信端末装置との通話途中にも、通話先の無線通信端末装置から受信したパケットからホップ数を取得するようにしてもよい。その場合には 補完データサイズ設定手段は、ホップ数取得手段により取得された、通話途中のホップ数に応じて紛失音声データの最大補完データサイズを動的に変更して設定するようにしてもよい。ジッタバッファサイズの場合と同じで、アドホックネットワークの特質に合わせて、ホップ数に応じて最大補完データサイズをも動的に変動させるものである。
【０１００】
第１の態様に係る無線通信端末装置は、自無線通信端末装置が管理者端末として動作する場合には、非管理者端末である他の無線通信端末装置と通信を行い、当該無線通信端末装置の識別情報と当該無線通信端末装置から自装置までのホップ数とを含む管理情報を収集して管理テーブルに登録すると共に、管理者端末として動作する他の無線通信端末装置から当該管理者端末として動作する他の無線通信端末装置が保持する管理テーブルのデータを受信し、自らが保持する管理テーブルに統合する通信管理手段と、管理テーブルに基づき、パケットの送信先の無線通信端末装置を決定する手段とをさらに有するようにしても良い。このような管理テーブルを保持することによって、通話先の端末への経路を容易に特定することができるようになる。なお、管理テーブルに載っていない無線通信端末装置については、問い合わせを他の管理者端末に送信して転送してもらい、どの管理者端末の配下に存在しているかを特定する。また、予め設定されている管理者端末に関連付けられている非管理者端末については、他の管理者端末の配下に存在する場合においても追跡するようにしても良い。
【０１０１】
第２の態様に係る無線通信端末装置は、ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、取得されたホップ数に応じて、紛失音声データの最大補完データサイズを決定し、補完処理部に設定する補完データサイズ設定手段とを有する。
【０１０２】
上で述べたように、ホップ数が多い場合には紛失パケットの数も多くなる可能性が高いので、紛失データの補完を行う補完処理部が補完を行うデータサイズも大きくすることによって、再生音声品質の向上を図るものである。
【０１０３】
なお、上で述べたような処理を無線通信端末装置に実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
【０１０４】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１０５】
（付記１）
アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、
ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、前記通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、
取得された前記ホップ数に応じてジッタバッファのサイズを決定し、設定するジッタバッファサイズ設定手段と、
を有する無線通信端末装置。
【０１０６】
（付記２）
前記ホップ数取得手段は、前記通話先の無線通信端末装置との通話途中にも、前記通話先の無線通信端末装置から受信したパケットからホップ数を取得し、
前記ジッタバッファサイズ設定手段は、前記ホップ数取得手段により取得された、前記通話途中のホップ数に応じて前記ジッタバッファのサイズを動的に変更して設定する
付記１記載の無線通信端末装置。
【０１０７】
（付記３）
取得された前記ホップ数に応じて、紛失音声データの最大補完データサイズを決定し、紛失音声データの補完を行う補完処理部に当該最大補完データサイズを設定する補完データサイズ設定手段
をさらに有する付記１又は２記載の無線通信端末装置。
【０１０８】
（付記４）
前記ホップ数取得手段は、前記通話先の無線通信端末装置との通話途中にも、前記通話先の無線通信端末装置から受信したパケットからホップ数を取得し、
前記補完データサイズ設定手段は、前記ホップ数取得手段により取得された、前記通話途中のホップ数に応じて前記紛失音声データの最大補完データサイズを動的に変更して設定する
付記３記載の無線通信端末装置。
【０１０９】
（付記５）
前記自無線通信端末装置が管理者端末として動作する場合には、非管理者端末である他の無線通信端末装置と通信を行い、当該無線通信端末装置の識別情報と当該無線通信端末装置から自装置までのホップ数とを含む管理情報を収集して前記管理テーブルに登録すると共に、前記管理者端末として動作する他の無線通信端末装置から当該管理者端末として動作する他の無線通信端末装置が保持する管理テーブルのデータを受信し、自らが保持する前記管理テーブルに統合する通信管理手段と、
前記管理テーブルに基づき、パケットの送信先の無線通信端末装置を決定する手段と、
をさらに有する付記１乃至４のいずれか１つ記載の無線通信端末装置。
【０１１０】
（付記６）
アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、
ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、前記通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、
取得された前記ホップ数に応じて、紛失音声データの最大補完データサイズを決定し、補完処理部に設定する補完データサイズ設定手段と、
を有する無線通信端末装置。
【０１１１】
（付記７）
付記１乃至６のいずれか１つ記載の無線通信端末装置を複数含み、前記アドホックネットワークにおけるノードを構成するシステム。
【０１１２】
（付記８）
アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置によって実行されるプログラムであって、
ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、前記通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するステップと、
取得された前記ホップ数に応じてジッタバッファのサイズを決定し、設定するステップと、
を前記無線通信端末装置に実行させるプログラム。
【符号の説明】
【０１１３】
１００ 通信部 １１０ ジッタバッファ １２０ 音声出力処理部
１３０ スピーカ １４０ 音声出力制御部 １５０ 初期値テーブル
１６０ マイク １７０ 音声入力処理部
１８０ 送信データバッファ
１０１ 受信部 １０１１ 受信バッファ
１０２ 通信制御部 １０３ 送信部 １０４ 通信管理ＤＢ
１２１ ＰＬＣ部
【技術分野】
【０００１】
本技術は、アドホックネットワークを介した音声通話のための技術に関する。
【背景技術】
【０００２】
従来のＩＰ（Internet Protocol）電話機で内線電話網を構成するためには主にＩＰ−ＰＢＸ（Private Branch eXchange）やＳＩＰ（Session Initiation Protocol）サーバに代表されるサーバ機が必要であり、このサーバ機が内線電話網における制御や公衆交換電話網（ＰＳＴＮ：Public Switched Telephone Network）への接続制御を行うクライアント・サーバ型の電話システムが主流である。このようなサーバ機を主体とした内線電話網においては、サーバ機の導入に伴う費用及び設置スペースが必要であり、中小規模の事業所にとっては大きな設備投資費用となる場合もある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−２３５４４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
近年無線通信技術の向上から、無線電話機が普及してきており、そのような無線電話機を活用してサーバ機を用いずに電話網を構築できれば好ましい。
【０００５】
従って、本技術の目的は、無線通信端末装置を用いて構築されるアドホックネットワークを介して音声通話を適切に行うための技術を提供することである。
【課題を解決するための手段】
【０００６】
本無線通信端末装置は、アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、取得されたホップ数に応じてジッタバッファのサイズを決定し、設定するジッタバッファサイズ設定手段とを有する。
【発明の効果】
【０００７】
無線通信端末装置を用いて構築されるアドホックネットワークを介して音声通話を適切に行うことができるようになる。
【図面の簡単な説明】
【０００８】
【図１】図１は、アドホックネットワークの一例を示す図である。
【図２】図２は、無線通信端末装置の機能ブロック図である。
【図３】図３は、アドホックネットワークの初期処理を示す図である。
【図４】図４は、管理者端末の通信管理ＤＢに格納されるデータの一例を示す図である。
【図５】図５は、管理者端末の通信管理ＤＢに格納されるデータの一例を示す図である。
【図６】図６は、管理者端末の通信管理ＤＢに格納されるデータの一例を示す図である。
【図７】図７は、非管理者端末の通信管理ＤＢに格納されるデータの一例を示す図である。
【図８】図８は、端末間の通話を開始する際の処理を示す図である。
【図９】図９は、ホップ数と受信遅延時間との関係を表す図である。
【図１０】図１０は、ホップ数とジッタバッファサイズの関係を表す図である。
【図１１】図１１は、ジッタバッファサイズの調整のための処理フローを示す図である。
【図１２】図１２は、ジッタバッファサイズ・テーブルの一例を示す図である。
【図１３】図１３は、ホップ数とパケットロス数の関係を表す図である。
【図１４】図１４は、データ補完について説明するための図である。
【図１５】図１５は、ホップ数と最大補完データサイズの関係を表す図である。
【図１６】図１６は、補完データサイズを変更した場合について説明するための図である。
【図１７】図１７は、補完データサイズの調整のための処理フローを示す図である。
【図１８】図１８は、補完データサイズ・テーブルの一例を示す図である。
【図１９】図１９は、従来の無線及び有線のＩＰ電話システムを示す図である。
【図２０】図２０は、通常のＩＰ電話システムからアドホックネットワークを用いた電話システムへの移行について説明するための図である。
【図２１】図２１は、アドホックネットワークを用いた電話システムと通常のＩＰ電話システムとの切り替えに伴う処理の処理フローを示す図である。
【図２２】図２２は、アドホックネットワークを一部採用した電話システムの一例を示す図である。
【発明を実施するための形態】
【０００９】
図１に、本技術の実施の形態において想定するアドホックネットワークの一例を示す。図１では、端末ａ−１と端末ｂ−１と端末ｃ−１と端末ｄ−１と端末ｅ−１とが管理者端末として予め定められているか、または管理者端末となるような特性（例えば電話番号）を有する。そして、管理者端末である端末ａ−１は、予め関連付けられている端末ａ−２乃至ａ−４の情報を管理すると共に、当該端末ａ−１が直接無線通信可能な範囲Ａ内の端末ｂ−１及びｃ−１の情報を管理する。予め関連付けられている端末ａ−２乃至ａ−４（図１では端末ａ−４が該当）については、端末ａ−１が直接無線通信可能な範囲Ａ内になくとも、アドホックネットワーク内の管理者端末を介して情報を取得する。さらに、管理者端末である端末ａ−１は、後に述べるが、直接無線通信可能な範囲Ａ内の他の管理者端末である端末ｂ−１及びｃ−１と管理情報を交換して保持するようになっている。なお、非管理者端末である端末ａ−２乃至ａ−４は、直接無線通信可能な範囲内の管理者端末の情報を保持している。
【００１０】
同様に、管理者端末である端末ｂ−１は、予め関連付けられている端末ｂ−２及びｂ−３の情報を管理すると共に、当該端末ｂ−１が直接無線通信可能な範囲Ｂ内の端末ａ−１及びｄ−１の情報を管理する。予め関連付けられている端末ｂ−２及びｂ−３については、端末ｂ−１が直接無線通信可能な範囲Ｂ内になくとも、アドホックネットワーク内の管理者端末を介して情報を取得する。さらに、管理者端末である端末ｂ−１は、直接無線通信可能な範囲Ｂ内の他の管理者端末である端末ａ−１及びｄ−１と管理情報を交換して保持するようになっている。なお、非管理者端末である端末ｂ−２及びｂ−３は、直接無線通信可能な範囲内の管理者端末の情報を保持している。
【００１１】
さらに、管理者端末である端末ｃ−１は、予め関連付けられている端末ｃ−２の情報を管理すると共に、当該端末ｃ−１が直接無線通信可能な範囲Ｃ内の端末ａ−１、端末ａ−３及びｄ−１の情報を管理する。予め関連付けられている端末ｃ−２については、端末ｃ−１が直接無線通信可能な範囲Ｃ内になくとも、アドホックネットワーク内の管理者端末を介して情報を取得する。さらに、管理者端末ｃ−１は、直接無線通信可能な範囲Ｃ内の他の管理者端末である端末ａ−１及びｄ−１と管理情報を交換して保持するようになっている。なお、非管理者端末である端末ｃ−２は、直接無線通信可能な範囲内の管理者端末の情報を保持している。
【００１２】
また、管理者端末である端末ｄ−１は、予め関連付けられている端末（図１では存在しない）の情報を管理すると共に、当該端末ｄ−１が直接無線通信可能な範囲Ｄ内の端末ｂ−１、ｂ−３、ｃ−１及びｅ−１の情報を管理する。さらに、管理者端末ｄ−１は、後に述べるが、直接無線通信可能な範囲Ｄ内の他の管理者端末である端末ｂ−１、ｃ−１及びｅ−１と管理情報を交換して保持するようになっている。
【００１３】
さらに、管理者端末である端末ｅ−１は、予め関連付けられている端末ｅ−２の情報を管理すると共に、当該端末ｅ−１が直接無線通信可能な範囲Ｅ内の端末ａ−４、ｂ−３及びｄ−１の情報を管理する。予め関連付けられている端末ｅ−２については、端末ｅ−１が直接無線通信可能な範囲Ｅ内になくとも、アドホックネットワーク内の管理者端末を介して情報を取得する。さらに、管理者端末である端末ｅ−１は、直接無線通信可能な範囲Ｅ内の他の管理者端末ｄ−１と管理情報を交換して保持するようになっている。なお、非管理者端末である端末ｅ−２については、直接無線通信可能な範囲内の管理者端末の情報を保持している。
【００１４】
アドホックネットワークであるから、図１は一時的な状態を示しているに過ぎず、端末は自由に移動して異なるネットワーク状態に遷移する。例えば端末ａ−２が移動して範囲Ｂと範囲Ｅが重なる領域に移動したとすると、管理者端末ｂ−１及びｅ−１は、端末ａ−２の情報を管理するようになる。また、管理者端末ａ−１は、端末ａ−２を範囲Ａの中で見つけ出すことができなくなるので、アドホックネットワーク内の他の管理者端末を介して情報を取得する。
【００１５】
このようなアドホックネットワークのノードを構成する無線通信端末装置は、例えば図２に示すような構成を有する。無線通信端末装置１０００は、通信部１００と、通信部１００で受信した音声データを格納するジッタバッファ１１０と、ジッタバッファ１１０に格納されている音声データに対して周知の音声出力処理を実施する音声出力処理部１２０と、音声出力処理部１２０からのアナログ音声信号に従って音声を出力するスピーカ１３０と、ジッタバッファサイズ及び紛失データを補完する補完処理を行う範囲を表す補完データサイズを決定する音声出力制御部１４０と、ジッタバッファサイズ及び最大補完データサイズの初期値を格納する初期値テーブル１５０と、マイク１６０と、マイク１６０から入力されたアナログ音声信号を周知の方法で音声ディジタルデータに変換する音声入力処理部１７０と、音声入力処理部１７０で生成された音声ディジタルデータを格納する送信データバッファ１８０とを有する。
【００１６】
また、通信部１００は、無線信号からパケットデータを抽出する受信部１０１と、送信データバッファ１８０に格納されている音声ディジタルデータをパケットにして無線信号で送出する送信部１０３と、受信部１０１及び送信部１０３を制御することによって他の無線通信端末装置との所定のプロトコルによる通信を可能にする通信制御部１０２と、通信制御部１０２によって用いられる、他の無線通信端末装置についての情報を格納する通信管理ＤＢ１０４とを有する。なお、受信部１０１は、受信バッファ１０１１を有しており、受信したパケットを一旦受信バッファ１０１１に格納すると共に、自無線通信端末装置宛のパケットについてはペイロード部分をジッタバッファ１１０に格納する。また、通信制御部１０２は音声出力制御部１４０と連携するようになっている。
【００１７】
また、音声出力処理部１２０は、音声出力制御部１４０による指示に従ってデータ補完処理（パケット補完処理とも呼ぶ）を実施するＰＬＣ（Packet Loss Concealment）部１２１を含む。
【００１８】
次に、図３乃至図７を用いてアドホックネットワークにおける通信方式について概略を説明する。図３では、図１に示した端末のうち一部の端末について初期設定を行う段階について説明している。まず、端末ａ−２の送信部１０３は、通信制御部１０２の指示に応じて、自端末が管理者端末になれるかを問い合わせる判定パケット（例えば電話番号を含む）をブロードキャスト又はマルチキャストする（ステップ（１））。端末ａ−１の受信部１０１は、判定パケットを端末ａ−２から受信すると、判定パケットのデータを通信制御部１０２に出力する。ここで、所定のルール（例えば電話番号やＩＰアドレスの大小関係）にて、端末ａ−２が管理者端末となるか否かを判断する。ここでは端末ａ−１には電話番号４０００が割り当てられており、端末ａ−２には電話番号４００１が割り当てられているとすると、電話番号４０００以上４１００番未満においてより小さい電話番号が割り当てられている端末ａ−１が管理者端末になるべきと判断し、端末ａ−１の通信制御部１０２は、拒否パケットを送信部１０３に、端末ａ−２へ送信させる（ステップ（２））。端末ａ−２の受信部１０１は、端末ａ−１から拒否パケットを受信し、通信制御部１０２に出力する。これにより、管理者端末になれないことが分かる。
【００１９】
また、端末ａ−１の送信部１０３は、通信制御部１０２の指示に応じて、自端末が管理者端末になれるかを問い合わせる判定パケットをマルチキャスト又はブロードキャストする（ステップ（３））。端末ａ−２の受信部１０１は、判定パケットを端末ａ−１から受信すると、判定パケットのデータを通信制御部１０２に出力する。上で述べたルールに従って、端末ａ−１の方が電話番号が小さいので、端末ａ−１からの要求は妥当であるとして、端末ａ−２の通信制御部１０２は、許可パケットを送信部１０３に、端末ａ−１へ送信させる（ステップ（４））。端末ａ−１の受信部１０１は、端末ａ−２から許可パケットを受信し、通信制御部１０２に出力する。
【００２０】
このようなやりとりに基づき、端末ａ−２については非管理者端末であって端末ａ−１に管理されるということが、端末ａ−２の通信制御部１０２により通信管理ＤＢ１０４に登録される。また、端末ａ−１については管理者端末であって端末ａ−２を管理するということが、端末ａ−１の通信制御部１０２により通信管理ＤＢ１０４に登録される。通信管理ＤＢ１０４に登録されるデータについては、後に説明する。
【００２１】
また、上ではその都度管理者端末であるか否かを判断するようになっているが、予め管理者端末である端末には管理者端末であることを設定しておき、非管理者端末である端末についてはステップ（１）及び（２）を実施するようにしても良い。
【００２２】
また、管理者端末である端末ａ−１の通信制御部１０２は、送信部１０３に判定パケットをマルチキャスト又はブロードキャストさせる（ステップ（５））。端末ｂ−１の受信部１０１は、端末ａ−１から判定パケットを受信すると、判定パケットのデータを通信制御部１０２に出力する。端末ｂ−１は、例えば電話番号４１００が割り当てられており、管理者端末になるので、端末ｂ−１の通信制御部１０２は、拒否パケットを送信部１０３に、端末ａ−１へ送信させる（ステップ（６））。端末ａ−１の受信部１０１は、端末ｂ−１から拒否パケットを受信し、通信制御部１０２に出力する。これにより端末ａ−１の通信制御部１０２は、端末ｂ−１が管理者端末であると判断する。
【００２３】
また、端末ｂ−２の送信部１０３は、通信制御部１０２の指示に応じて、判定パケットをマルチキャスト又はブロードキャストする（ステップ（７））。端末ｂ−１の受信部１０１は、判定パケットを端末ｂ−２から受信すると、判定パケットのデータを通信制御部１０２に出力する。ここでは端末ｂ−２には電話番号４１０１が割り当てられているとすると、電話番号４１００番台においてより小さい電話番号が割り当てられている端末ｂ−１が管理者端末になるべきと判断し、端末ｂ−１の通信制御部１０２は、拒否パケットを送信部１０３に、端末ｂ−２へ送信させる（ステップ（８））。端末ｂ−２の受信部１０１は、端末ｂ−１から拒否パケットを受信し、通信制御部１０２に出力する。これにより端末ｂ−２は、管理者端末になれないことを認識する。
【００２４】
さらに、端末ｂ−１の送信部１０３は、通信制御部１０２の指示に応じて、自端末が管理者端末になれるかを問い合わせる判定パケットをマルチキャスト又はブロードキャストする（ステップ（９））。端末ｂ−２の受信部１０１は、判定パケットを端末ｂ−１から受信すると、判定パケットのデータを通信制御部１０２に出力する。上で述べたルールに従って、端末ｂ−１の方が電話番号が小さいので、端末ｂ−１からの要求は妥当であるとして、端末ｂ−２の通信制御部１０２は、許可パケットを送信部１０３に、端末ｂ−１へ送信させる（ステップ（１０））。端末ｂ−１の受信部１０１は、端末ｂ−２から許可パケットを受信し、通信制御部１０２に出力する。
【００２５】
このようなやりとりに基づき、端末ｂ−２については非管理者端末であって端末ｂ−１に管理されるということが、端末ｂ−２の通信制御部１０２により通信管理ＤＢ１０４に登録される。また、端末ｂ−１については管理者端末であって端末ｂ−２を管理するということが、端末ｂ−１の通信制御部１０２により通信管理ＤＢ１０４に登録される。
【００２６】
さらに、管理者端末である端末ｂ−１の通信制御部１０２は、送信部１０３に判定パケットをマルチキャスト又はブロードキャストさせる（ステップ（１１））。端末ａ−１の受信部１０１は、端末ｂ−１から判定パケットを受信すると、判定パケットのデータを通信制御部１０２に出力する。端末ａ−１は、例えば電話番号４０００が割り当てられており、管理者端末であるので、端末ａ−１の通信制御部１０２は、拒否パケットを送信部１０３に、端末ｂ−１へ送信させる（ステップ（１２））。端末ｂ−１の受信部１０１は、端末ａ−１から拒否パケットを受信し、通信制御部１０２に出力する。これにより端末ｂ−１の通信制御部１０２は、端末ａ−１が管理者端末であると判断する。
【００２７】
なお、非管理者端末は、自己を管理している近隣の管理者端末とは定期的に生存確認を行う。具体的には、端末ａ−２の通信制御部１０２は、送信部１０３に生存確認パケット（KeepAliveパケット）を、自己を管理する近隣の管理者端末である端末ａ−１へ送信させる（ステップ（１３））。端末ａ−１の受信部１０１は、端末ａ−２から生存確認パケットを受信すると、通信制御部１０２に出力し、通信制御部１０２はこれによって通信管理ＤＢ１０４の更新が必要ないことを確認した上、送信部１０３にＡＣＫパケットを端末ａ−２へ送信させる（ステップ（１４））。端末ａ−２は、ＡＣＫパケットを受信して、管理者端末が生存しており通信管理ＤＢ１０４の更新が必要ないことを確認する。
【００２８】
同様に、端末ｂ−２の通信制御部１０２は、送信部１０３に生存確認パケット（KeepAliveパケット）を、自己を管理する近隣の管理者端末である端末ｂ−１へ送信させる（ステップ（１５））。端末ｂ−１の受信部１０１は、端末ｂ−２から生存確認パケットを受信すると、通信制御部１０２に出力し、通信制御部１０２はこれによって通信管理ＤＢ１０４の更新が必要ないことを確認した上、送信部１０３にＡＣＫパケットを端末ｂ−２へ送信させる（ステップ（１６））。端末ｂ−２は、ＡＣＫパケットを受信して、管理者端末が生存しており通信管理ＤＢ１０４の更新が必要ないことを確認する。
【００２９】
また、近隣の管理者端末同士は、例えば定期的に自身の有する管理情報を交換して、ルーティングなどに利用する。具体的には、端末ａ−１の通信制御部１０２は、通信管理ＤＢ１０４から自己の無線通信可能範囲に入っている端末の情報を読み出し、これを管理情報として含む管理情報通知パケットを送信部１０３に、近隣の管理者端末である端末ｂ−１へ送信させる（ステップ（１７））。端末ｂ−１の受信部１０１は、端末ａ−１から管理情報通知パケットを受信すると、通信制御部１０２に出力する。通信制御部１０２は、受信パケットの管理情報を通信管理ＤＢ１０４に登録すると共に、自己の無線通信可能範囲に入っている端末の情報を読み出し、これを管理情報として含む管理情報通知パケットを送信部１０３に、端末ａ−１へ送信させる（ステップ（１８））。端末ａ−１の受信部１０１は、端末ａ−１から管理情報通知パケットを受信すると、通信制御部１０２に出力する。通信制御部１０２は、受信パケットの管理情報を通信管理ＤＢ１０４に登録する
【００３０】
端末ａ−１の通信管理ＤＢ１０４には、例えば図４乃至図６に示すようなデータが格納される。図４は、端末ａ−１が必ず管理することになっている端末についての情報を示す。図１の説明でも述べたように、端末ａ−１には内線番号４０００が割り当てられており、内線番号４０００以上４１００未満の端末については無線通信可能な範囲にいない場合においても必ず情報を取得して通信管理ＤＢ１０４に登録する。図４に示すように、端末ａ−２乃至ａ−４は、端末ａ−１が必ず管理する端末として登録されている端末である。そして、これらの端末の各々について、管理者／非管理者の別と、電話番号（内線番号）、ＩＰアドレス、サブネットマスク、ゲートウェイ、及び端末ａ−１までのホップ数とが登録されるようになっている。なお、端末ａ−４については、端末ａ−１の無線通信可能範囲Ａには入っていないので、探索した結果又は端末ａ−４からの情報通知によってホップ数「４」離れたところに現在存在しているということが分かっている。
【００３１】
また、図１の説明でも述べたが、管理者端末である端末ｂ−１及びｃ−１についても端末ａ−１の無線通信可能範囲Ａに入っているので、これらの端末の情報についても通信管理ＤＢ１０４には管理情報として登録される。但し、これらは管理者端末であるので、それらが有する管理情報も取得して保持している。具体的には、図５に示すように、端末ｂ−１そのものの情報として、管理者／非管理者の別と、電話番号（内線番号）と、ＩＰアドレスと、サブネットマスクと、ゲートウェイと、端末ａ−１までのホップ数とが登録されており、さらに、端末ｂ−１の無線通信可能範囲Ｂ内の端末ａ−１、ｂ−２、ｂ−３及びｄ−１の管理情報も含まれる。各端末の管理情報自体は、端末ａ−１の管理情報と同じである。なお、ホップ数は、端末ｂ−１を基準にしたホップ数であるから、端末ａ−１からのホップ数であれば、端末ｂ−１までのホップ数「１」と端末ｂ−１からのホップ数「１」を加算して「２」と判断しなければならない。
【００３２】
同様に、端末ｃ−１の管理情報は図６に示すように、端末ｃ−１についての管理者／非管理者の別と、電話番号（内線番号）と、ＩＰアドレスと、サブネットマスクと、ゲートウェイと、ホップ数とが登録されている。さらに、端子ｃ−１の無線通信可能範囲Ｃ内の端末ａ−１、ａ−３、ｃ−２及びｄ−１の管理情報も含まれるようになっている。
【００３３】
さらに、非管理者端末である端末ａ−２には、例えば、図７に示すようなデータが、通信管理ＤＢ１０４に格納される。具体的には、端末ａ−２は非管理者端末であるので、予め定められた端末についての管理情報は存在せず、図７ではＮＵＬＬとなっている。また、管理者情報として、通信範囲内における管理者端末である端末ａ−１についての情報が登録されている。具体的には、管理者／非管理者の別と、電話番号（内線番号）と、ＩＰアドレスと、サブネットマスクと、ゲートウェイと、ホップ数とが登録されている。このように、近隣の管理者端末の情報を登録しておき、通話の際には管理者端末に通話先を指定したリクエストを送信し、通話先の端末にリクエストを転送してもらう。
【００３４】
本実施の形態では、このように予め管理しなければならないと設定されている端末以外は、最大ホップ数「２」の範囲の情報しか保持しないようになっているが、範囲を広げて管理者端末で管理情報の交換を重ねてアドホックネットワーク全体又は一部であってもより広い範囲についての管理情報を、通信管理ＤＢ１０４に保持するようにしても良い。
【００３５】
本実施の形態では、通信管理ＤＢ１０４に保持されている管理情報で探索できる範囲については、通信管理ＤＢ１０４を用いて最短経路を特定して端末間の通話を実施する。但し、端末間で直接無線通信できる場合には、管理者端末を経由せずに通話を行うように切り替えても良い。
【００３６】
さらに、無線通信端末装置の通信制御部１０２は、自無線通信端末装置宛でないパケット等を受信した場合には、受信部１０１の受信バッファ１０１１に格納されているパケットを読み出して送信部１０３に送出させる処理も実施する。
【００３７】
アドホックネットワークにおける初期段階の通信処理の概略は以上であり、次に、具体的に無線通信端末装置間で通話する際の処理について説明する。例えば、端末ａ−２が端末ｂ−２に通話を要求する際の処理について図８を用いて説明する。まず、端末ａ−２の通信制御部１０２は、例えばユーザからの電話番号４１０１の入力及び発信の指示に応じて、発信元端末の電話番号４００１（場合によってはＩＰアドレス）及び通話先の電話番号４１０１を含み且つホップ数（初期値＝０）をカウントするためのカウンタが付された発信要求パケットを送信部１０３に、通信管理ＤＢ１０４に登録されており近隣の管理者端末である端末ａ−１へ送信させる（ステップ（３１））。端末ａ−１の受信部１０１は、端末ａ−２から発信要求パケットを受信し、通信制御部１０２に発信要求パケットのデータを出力する。通信制御部１０２は、発信要求パケットに含まれる通話先端末の電話番号で通信管理ＤＢ１０４を検索して該当するデータが存在するか判断する。今回の場合には、端末ｂ−１の配下に電話番号４１０１の端末ｂ−２が存在していることが分かる。従って、通信制御部１０２は、ホップ数を１インクリメントして「１」にした発信要求パケットを、端末ｂ−１へ送信するように送信部１０３に指示する。送信部１０３は、指示に応じて発信要求パケットを端末ｂ−１に送信する（ステップ（３２））。
【００３８】
端末ｂ−１の受信部１０１は、端末ａ−１から電話番号４１０１宛の発信要求パケットを受信すると、通信制御部１０２に出力する。通信制御部１０２は、発信要求パケットに含まれる電話番号４１０１で通信管理ＤＢ１０４を検索すると、配下に該当する端末ｂ−２が存在するが分かる。従って、通信制御部１０２は、ホップ数をさらに１インクリメントして「２」にした発信要求パケットを、端末ｂ−２へ送信するように送信部１０３に指示する。送信部１０３は、指示に応じて発信要求パケットを端末ｂ−２に送信する（ステップ（３３））。
【００３９】
端末ｂ−２の受信部１０１は、端末ｂ−１から電話番号４１０１宛の発信要求パケットを受信すると、通信制御部１０２に出力する。通信制御部１０２は、発信要求パケットの宛先が自無線通信端末装置であることを認識し、他の端末と通話中でなければ例えば呼出中を表し、端末ａ−２の電話番号等を宛先として含み且つホップ数（初期値＝０）をカウントするためのカウンタが付されたレスポンス・パケットを、管理者端末である端末ｂ−１へ送信するように送信部１０３に指示する。送信部１０３は、指示に応じてレスポンス・パケットを端末ｂ−１に送信する（ステップ（３４））。なお、通信制御部１０２は、発信要求パケットに含まれる送信元の電話番号等と共にホップ数（ここでは「２」）を１インクリメントした値「３」を、音声出力制御部１４０に出力し、音声出力制御部１４０は、ワークメモリ領域などに格納しておく。
【００４０】
端末ｂ−１の受信部１０１は、端末ｂ−２から電話番号４００１宛のレスポンス・パケットを受信すると、通信制御部１０２に出力し、通信制御部１０２は通信管理ＤＢ１０４に基づき、端末ａ−１へホップ数を１インクリメントして「１」にしたレスポンス・パケットを送信部１０３に送信させる（ステップ（３５））。
【００４１】
端末ａ−１の受信部１０１は、端末ｂ−１から電話番号４００１宛のレスポンス・パケットを受信すると、通信制御部１０２に出力し、通信制御部１０２は通信管理ＤＢ１０４に基づき、端末ａ−２へホップ数を１インクリメントして「２」にしたレスポンス・パケットを送信部１０３に送信させる（ステップ（３６））。
【００４２】
端末ａ−２の受信部１０１は、端末ａ−１からレスポンス・パケットを受信すると、通信制御部１０２に出力し、通信制御部１０２は、自無線通信端末装置宛のレスポンス・パケットであると認識すると共に、通話可能である又は通話不可能であるか判別する。さらに、レスポンス・パケットに含まれるホップ数「２」を１インクリメントしたホップ数「３」を、例えばワークメモリ領域などに格納すると共に、音声出力制御部１４０に出力する。音声出力制御部１４０の処理については、以下で詳しく述べる。
【００４３】
この後については、例えば通話可能である場合には、通話先の端末ｂ−２のユーザの通話指示に応じて当該端末ｂ−２からＯＫレスポンス等を送信することによって接続を確立する。但し、端末ｂ−２のユーザからの通話指示に応じて、端末ｂ−２がレスポンス・パケットを送信するようにして、レスポンス・パケットを端末ａ−２が受信したところで接続を確立するようにしても良い。さらに、レスポンス・パケットに応じて、端末ａ−２がＡＣＫパケットなどを送信してＡＣＫパケットを端末ｂ−２が受信した時点で接続を確立するようにしても良い。また、端末ａ−２がＡＣＫパケットなどを送信する場合には、発信要求パケットにホップ数のカウンタを含めるのではなく、ＡＣＫパケットなどにホップ数のカウンタを設けるようにしても良い。さらに、ホップ数を、周知のＴＴＬ（Time to Live）を用いて算出するようにしても良い。すなわち、予め固定のＴＴＬを設定してパケットを送信し、この固定のＴＴＬと宛先でのＴＴＬとの差をホップ数として特定するようにしても良い。
【００４４】
なお、通信管理ＤＢ１０４に保持されている管理情報で探索できない範囲にいる端末に対する発信要求パケットを受信した場合には、他の管理者端末に通話先端末の存在について問い合わせをブロードキャスト又はマルチキャストして、その返信からどのような管理者の配下に存在しているかを経路と共に特定する。そして、最短経路を特定して発信要求パケットをその経路に従って送信する。その後は、基本的には上で述べたとおりの処理を行う。但し、経路データについては送信パケットに含めるようにしても良い。
【００４５】
次に、通話中の音声データの処理について説明する。基本的には、受信部１０１が受信し且つ音声データを含む自無線通信端末装置宛のパケットは、受信バッファ１０１１に格納される。例えば、到着順番が入れ替わっているような場合などは、この受信バッファ１０１１で入れ替える処理を行う。そして、パケットの音声データ部分（すなわちペイロード）をジッタバッファ１１０に格納する。ジッタバッファ１１０のサイズは、以下で述べるように音声出力制御部１４０によって制御される。ジッタバッファ１１０に格納されている音声データは、音声出力処理部１２０によって復号化されて音声アナログ信号に変換されて、スピーカ１３０から出力される。
【００４６】
よく知られているように、ジッタバッファ１１０は、パケットの受信タイミングの遅延やゆらぎを吸収するためのバッファであり、大きなサイズであるほど大きな遅延やゆらぎに対応できるが、再生遅延が大きくなるという問題がある。全体のメモリ量を削減するという観点を併せても、できる限り小さいサイズであることが好ましい。一方で、アドホックネットワークは不安定で環境の影響を受け易いため、図９に示すように、ホップ数が増加すると、それに応じてパケットの受信遅延時間（又は受信ゆらぎ時間）は増加する。従って、これに対応するため、音声出力制御部１４０は、図１０に示すように、ホップ数が多ければジッタバッファサイズを大きくし、ホップ数が少なければジッタバッファサイズを小さくするような制御を行うことが好ましい。
【００４７】
従って、図８に示したように通話開始直前にホップ数を発信元及び発信先の端末で把握して、そのホップ数に応じてジッタバッファサイズを設定する。さらに、アドホックネットワークでは、通話中にネットワーク構成が変化してホップ数が変化する可能性がある。従って、通話中もホップ数を定期的又は任意のタイミングでカウントして、変化があれば変化に応じてジッタバッファサイズを動的に変更する。このため、音声出力制御部１４０は、通信制御部１０２からホップ数のデータを受け取ると、例えばワークメモリ領域などにホップ数の履歴を格納する。
【００４８】
具体的な処理フローを図１１に示す。まず、通話を行う端末間の接続が完了する前に、通信制御部１０２は、ホップ数を受信パケットから取得して音声出力制御部１４０に出力する。また、管理者端末が発信元の場合であって、通信管理ＤＢ１０４に登録されている端末と通話を行う場合には、通信管理ＤＢ１０４にホップ数が予め登録されているので、通信制御部１０２は、通信管理ＤＢ１０４に登録されているホップ数から通話先端末までのホップ数を特定するようにしてもよい。直接通信できる範囲内の端末と通話を行う場合には、ホップ数は「１」であるが、他の管理者端末を経由する場合には、他の管理者端末までのホップ数「１」を加算しないと、通話先端末までのホップ数は得られない。いずれにせよ、特定されたホップ数を音声出力制御部１４０に出力する。
【００４９】
音声出力制御部１４０は、通信制御部１０２から通話先端末までのホップ数を取得し（ステップＳ１）、例えば初期値テーブル１５０に登録されているジッタバッファサイズ・テーブルから、取得されたホップ数に該当するバッファサイズを読み出して、ジッタバッファ１１０のサイズを設定する（ステップＳ３）。
【００５０】
ジッタバッファサイズ・テーブルの一例を図１２に示す。図１２の例では、ホップ数に対応して、測定結果等に基づき予め定められたジッタバッファサイズが格納されている。ここで、ｂ1＜ｂ2＜ｂ3＜ｂ4となっている。図１２の例のように、ホップ数の複数の数値に対して１のジッタバッファサイズが対応付けられる場合もあれば、ホップ数の各々に対して１のジッタバッファサイズが対応付けられるようになる場合もある。
【００５１】
このような設定を行うことによって、ホップ数が多い場合でもパケット受信の遅延やゆらぎに対処できるようになり、またホップ数が少ない場合であれば使用メモリ量を少なくして、再生遅延を抑えることができるようになる。また、場合によって使用していないメモリに対する電力供給を停止するなどして、消費電力を抑えることも可能な場合もある。
【００５２】
その後通話が始まって音声データを含むパケットのやりとりが行われる。全てのパケットでなくともよいが、通話中におけるアドホックネットワークの構成変化に備えて、定期的に又は任意のタイミングでホップ数をカウントするためのカウンタ付きのパケットを送信して、ホップ数に変化がないか確認する。上でも述べたが、ＴＴＬを用いてホップ数を特定しても良い。
【００５３】
すなわち、通信制御部１０２は、受信パケットからホップ数を抽出し、音声出力制御部１４０に出力し、音声出力制御部１４０は、通信制御部１０２からホップ数のデータを受け取るとワークメモリ領域などに格納に格納する（ステップＳ５）。そして、今回のホップ数は、ワークメモリ領域などに格納されている前回のホップ数と一致しているか判断する（ステップＳ７）。一致している場合にはステップＳ１５に移行する。
【００５４】
一方、一致していない場合には、音声出力制御部１４０は、今回のホップ数が前回のホップ数より増加しているか判断する（ステップＳ９）。増加していれば、ジッタバッファサイズを所定量増加するように設定する（ステップＳ１１）。例えば、測定結果などに基づき予め決定した量を所定量としてワークメモリ領域などに保持しておき、その所定量だけ増加させるようにしても良いし、例えば図１２に示したようなジッタバッファサイズ・テーブルに基づき新たなホップ数に対応するジッタバッファサイズを特定して、その値になるようにジッタバッファサイズを増加させても良い。そしてステップＳ１５に移行する。
【００５５】
一方、増加ではなく減少している場合には、音声出力制御部１４０は、ジッタバッファサイズを所定量減少させるように設定する（ステップＳ１３）。所定量は増加させる場合と同じであっても良いし、異なるようにしても良い。予めワークメモリ領域などに保持しておき、それに基づき設定するようにしてもよいし、ジッタバッファサイズ・テーブルに基づき新たなホップ数に対応するジッタバッファサイズを特定して、その値になるようにジッタバッファサイズを減少させるようにしても良い。そしてステップＳ１５に移行する。
【００５６】
ステップＳ１５では、通話終了であるかを通信制御部１０２が確認し、通話中であればステップＳ５に戻って処理を継続する。一方、通話終了であれば、処理は終了する。
【００５７】
このようにすれば、通話相手までの初期的なホップ数に応じてジッタバッファサイズを設定して、ホップ数に応じたパケット受信の遅延などに備えることができるようになる。さらに、動的に構成変化が予測されるアドホックネットワークにおいては、通話中でもホップ数を観測して、必要に応じて動的にジッタバッファサイズを増減させ、適応的且つ安定的に音声再生を行うようにする。
【００５８】
また、アドホックネットワークではパケット受信の遅延やゆらぎだけではなく、パケットロスも問題となる。すなわち、ホップ数が増加すると、通信距離が増加し、それに伴って通信経路上の他の機器の過負荷などによる通信バッファあふれや、受信バッファあふれ、ノイズ障害などによりパケットロスが発生しやすくなる。パケットロス数も、図１３に示すように、ホップ数が増加するとそれに応じて増加する。従って、このような問題にも対処する必要がある。
【００５９】
既に、パケットロスに対処するためパケットロス補完（ＰＬＣ）技術が存在している。例えば、図１４に示すような音声信号（縦軸：振幅、横軸：時間）を再生する場合に、パケットロスが発生すると、例えば点線部分の信号を再生できなくなる。このため、パケットロス補完技術によって、パケットロス部分を例えば前後のデータから推定して復元する。但し、当然ながら完全に補完できるわけではなく、補完精度が低ければ音声品質が低下してしまう。補完精度は、ロスしたパケット数が増加すれば低くなり、可能な限り補完データサイズについては少ない方が好ましい。
【００６０】
従って、本実施の形態では、図１５に示すように最大補完データサイズを、ホップ数が増加するのに応じて増加するように設定することによって、ホップ数に応じて音声のとぎれを防止するようにする。例えば、図１４が少ないホップ数の場合の例だとすると、ホップ数が多い場合には、図１６に示すように、補完データサイズを多くして、より長い時間の音声信号を補完によって生成する。
【００６１】
具体的には、図１７に示すような処理を実施する。まず、通話を行う端末間の接続が完了する前に、通信制御部１０２は、ホップ数を受信パケットから取得して音声出力制御部１４０に出力する。また、管理者端末が発信元の場合であって、通信管理ＤＢ１０４に登録されている端末と通話を行う場合には、通信管理ＤＢ１０４にホップ数が予め登録されているので、通信制御部１０２は、通信管理ＤＢ１０４に登録されているホップ数から通話先端末までのホップ数を特定するようにしてもよい。直接通信できる範囲内の端末と通話を行う場合には、ホップ数は「１」であるが、他の管理者端末を経由する場合には、他の管理者端末までのホップ数「１」を加算しないと、通話先端末までのホップ数は得られない。いずれにせよ、特定されたホップ数を音声出力制御部１４０に出力する。
【００６２】
音声出力制御部１４０は、通信制御部１０２から通話先端末までのホップ数を取得し（ステップＳ２１）、例えば初期値テーブル１５０に登録されている補完データサイズ・テーブルから、取得されたホップ数に該当する最大補完データサイズを読み出して、ＰＬＣ部１２１に設定する（ステップＳ２３）。
【００６３】
補完データサイズ・テーブルの一例を図１８に示す。図１８の例では、ホップ数に対応して、測定結果等に基づき予め定められた最大補完データサイズが格納されている。ここで、ｃ1＜ｃ2＜ｃ3＜ｃ4となっている。なお、ジッタバッファサイズと同様に、ホップ数の複数の数値に対して１の補完データサイズが対応付けられる場合もあれば、ホップ数の各々に対して１の補完データサイズが対応付けられるようになる場合もある。
【００６４】
このような設定を行うことによって、ホップ数が多い場合でも長いパケットロスに対処して音声のとぎれを抑えることができるようになり、またホップ数が少ない場合であれば補完データサイズを抑えて低品質の再生をあまり行わないようにする。
【００６５】
その後通話が始まって音声データを含むパケットのやりとりが行われる。全てのパケットでなくともよいが、通話中におけるアドホックネットワークの構成変化に備えて、定期的に又は任意のタイミングでホップ数をカウントするためのカウンタ付きのパケットを送信して、ホップ数に変化がないか確認する。ＴＴＬを用いてホップ数を特定しても良いのは前に述べたとおりである。
【００６６】
すなわち、通信制御部１０２は、受信パケットからホップ数を抽出し、音声出力制御部１４０に出力し、音声出力制御部１４０は、通信制御部１０２からホップ数のデータを受け取るとワークメモリ領域などに格納に格納する（ステップＳ２５）。そして、今回のホップ数は、ワークメモリ領域などに格納されている前回のホップ数と一致しているか判断する（ステップＳ２７）。一致している場合にはステップＳ３５に移行する。
【００６７】
一方、一致していない場合には、音声出力制御部１４０は、今回のホップ数が前回のホップ数より増加しているか判断する（ステップＳ２９）。増加していれば、最大補完データサイズを所定量増加するように設定する（ステップＳ３１）。例えば、測定結果などに基づき予め決定した量を所定量としてワークメモリ領域などに保持しておき、その所定量だけ増加させるようにしても良いし、例えば図１８に示したような補完データサイズ・テーブルに基づき新たなホップ数に対応する最大補完データサイズを特定して、その値になるように最大補完データサイズを増加させても良い。そしてステップＳ３５に移行する。
【００６８】
一方、増加ではなく減少している場合には、音声出力制御部１４０は、最大補完データサイズを所定量減少させるように設定する（ステップＳ３３）。所定量は増加させる場合と同じであっても良いし、異なるようにしても良い。予めワークメモリ領域などに保持しておき、それに基づき設定するようにしてもよいし、補完データサイズ・テーブルに基づき新たなホップ数に対応する最大補完データサイズを特定して、その値になるように最大補完データサイズを減少させるようにしても良い。そしてステップＳ３５に移行する。
【００６９】
ステップＳ３５では、通話終了であるかを通信制御部１０２が確認し、通話中であればステップＳ２５に戻って処理を継続する。一方、通話終了であれば、処理は終了する。
【００７０】
このようにすれば、通話相手までの初期的なホップ数に応じて最大補完データサイズを設定して、ホップ数に応じたパケットロスに備えることができるようになる。さらに、動的に構成変化が予測されるアドホックネットワークにおいては、通話中でもホップ数を観測して、必要に応じて動的に最大補完データサイズを増減させ、適応的且つ安定的に音声再生を行うようにする。
【００７１】
［他の実施の形態］
上で述べた実施の形態では、アドホックネットワークを最初から構築する場合について述べたが、例えば通常は従前から存在しているＳＩＰサーバなどを利用した無線のＩＰ電話として動作させて、ＳＩＰサーバ等やアクセスポイントの機器が故障した場合に、アドホックネットワークに移行するような構成にしてもよい。安定性などの観点からＳＩＰサーバ等を導入するが、非常時にはアドホックネットワークを即座に構築してＳＩＰサーバ等が復旧するまでの間においても内線通話を可能にするものである。
【００７２】
この場合のシステム構成を図１９に模式的に示す。有線ＬＡＮには、サーバｓ１、ＩＰ電話機ｆ−１乃至ｆ−３、無線アクセスポイントＡＰｘ−１などが接続されている。この状態であれば、従来と何ら変わらない。但し、ＩＰ電話機ｆ−１乃至ｆ−３については特に必要ないが、無線通信端末装置である端末ａ−１乃至ａ−３、端末ｂ−１及びｂ−２並びに端末ｃ−１及びｃ−２については、アクセスポイントＡＰｘ−１を介してサーバｓ１に生存確認パケットを例えば定期的に送信し、サーバｓ１からＡＣＫパケットを受信することによって、互いが通信可能な状態にあるかどうかを確認する必要がある。
【００７３】
具体的には図２０に示すような処理を実施する。なお、説明を簡単にするために無線通信端末装置は端末ａ−１及びａ−２、端末ｂ−１及びｂ−２についてのみ説明する。端末ａ−２の通信制御部１０２は、例えば定期的に、送信部１０３に、サーバｓ１宛に生存確認パケット（KeepAlive）を送信させる（ステップ（４１））。これに対して、サーバｓ１は、端末ａ−２から生存確認パケットを受信すると、ＡＣＫパケットを端末ａ−２に対して送信する（ステップ（４２））。端末ａ−２の受信部１０１は、ＡＣＫパケットを受信すると通信制御部１０２に出力し、通信制御部１０２はＡＣＫパケットを受け取ったことによってサーバｓ１と通信可能な状態にいることを確認する。
【００７４】
同様に、端末ｂ−２の通信制御部１０２は、例えば定期的に、送信部１０３に、サーバｓ１宛に生存確認パケット（KeepAlive）を送信させる（ステップ（４３））。これに対して、サーバｓ１は、端末ｂ−２から生存確認パケットを受信すると、ＡＣＫパケットを端末ｂ−２に対して送信する（ステップ（４４））。端末ｂ−２の受信部１０１は、ＡＣＫパケットを受信すると通信制御部１０２に出力し、通信制御部１０２はＡＣＫパケットを受け取ったことによってサーバｓ１と通信可能な状態にいることを確認する。
【００７５】
さらに、端末ａ−１の通信制御部１０２は、例えば定期的に、送信部１０３に、サーバｓ１宛に生存確認パケット（KeepAlive）を送信させる（ステップ（４５））。これに対して、サーバｓ１は、端末ａ−１から生存確認パケットを受信すると、ＡＣＫパケットを端末ａ−１に対して送信する（ステップ（４６））。端末ａ−１の受信部１０１は、ＡＣＫパケットを受信すると通信制御部１０２に出力し、通信制御部１０２はＡＣＫパケットを受け取ったことによってサーバｓ１と通信可能な状態にいることを確認する。
【００７６】
また、端末ｂ−１の通信制御部１０２は、例えば定期的に、送信部１０３に、サーバｓ１宛に生存確認パケット（KeepAlive）を送信させる（ステップ（４７））。これに対して、サーバｓ１は、端末ｂ−１から生存確認パケットを受信すると、ＡＣＫパケットを端末ｂ−１に対して送信する（ステップ（４８））。端末ｂ−１の受信部１０１は、ＡＣＫパケットを受信すると通信制御部１０２に出力し、通信制御部１０２はＡＣＫパケットを受け取ったことによってサーバｓ１と通信可能な状態にいることを確認する。
【００７７】
通話を行わない場合においても、例えば定期的に上で述べたような処理を繰り返して、サーバも無線通信端末装置も互いに通信可能なことを確認する。
【００７８】
その後、サーバｓ１がダウンしたものとする。そうすると、端末ａ−１及びａ−２並びに端末ｂ−１及びｂ−２が、生存確認パケットを送信してもＡＣＫパケットがサーバｓ１から返ってこなくなる（ステップ（４９）乃至（５２））。
【００７９】
そうすると、各端末の通信制御部１０２は、サーバダウンを認識して、アドホックネットワークを構築するモードに移行する。すなわち、図３の処理に移行する。このようにすれば、上で述べたようにサーバダウンに応じてアドホックネットワークを速やかに構築して、アドホックネットワークを介した通話を可能にする。そして、アドホックネットワークが構築されると、上で述べた実施の形態のように、ジッタバッファサイズの調整や、補完データサイズの調整も必要となる。
【００８０】
例えば、通信制御部１０２は、図２１のような処理を行って、図１１や図１７に示すような処理を行うか否かを判断する。具体的には、通信制御部１０２は、現在の通信モードはアドホックネットワークを介して通話を行うアドホック接続モードであるか判断する（ステップＳ５１）。アドホック接続モードでなくサーバを用いた通信モードである場合には、ジッタバッファサイズ等の固定モードを音声出力制御部１４０に設定する（ステップＳ５５）。そしてステップＳ５７に移行する。
【００８１】
一方、アドホック接続モードである場合には、通信制御部１０２は、ジッタバッファサイズ等の動的変更モードを音声出力制御部１４０に設定する（ステップＳ５３）。そしてステップＳ５７に移行する。このようなモードに移行した場合には、通話を開始する際及び通話中には図１１や図１７の処理を実施することになる。
【００８２】
ステップＳ５７に移行して、通信制御部１０２は、処理終了か判断し（ステップＳ５７）、ステップＳ５１に戻る。一方、処理終了であれば処理を終了する。
【００８３】
なお、生存確認パケットについては、例えば定期的にダウン中であってもサーバ宛に送信して、復旧したか否かを監視しておく。そして、サーバやアクセスポイントの機器が復旧した場合には、ＡＣＫパケットをサーバから受け取ることができるようになるので、ＡＣＫパケットを受信すれば、アドホックネットワークを解体して、通常のＩＰ電話システムに戻るようにする。すなわち、通信管理ＤＢ１０４の管理データを破棄する。
【００８４】
これによってモードを切り替えて、必要なときにジッタバッファサイズや補完データサイズを調整できるようになる。
【００８５】
さらに、無線アクセスポイントの無線通信可能範囲に入っている無線通信端末装置については、従来と同じようにサーバを用いて端末間での通話を行うが、無線アクセスポイントの無線通信可能範囲に入らない無線通信端末装置についてはアドホックネットワークを部分的に構築するような実施態様も可能である。
【００８６】
例えば図２２に示すように、無線アクセスポイントＡＰｘ−１の無線通信可能範囲Ｘ内の端末ａ−１及びａ−３、端末ｂ−１並びに端末ｃ−１については、サーバｓ２を用いて他の端末と通話を行う。一方、無線通信可能範囲Ｘに入らない端末ａ−２、端末ｂ−２及び端末ｃ−２については、直接サーバｓ２と通信することができないので、近隣の管理者端末が中継することになる。例えば、端末ｃ−２は、近隣の管理者端末である端末ｃ−１の無線通信可能範囲Ｃに入っているので、端末ｃ−１を介してサーバｓ２を利用することとする。また、端末ａ−２であれば管理者端末である端末ａ−１を介してサーバｓ２を利用し、端末ｂ−２であれば管理者端末である端末ｂ−１を介してサーバｓ２を利用する。
【００８７】
但し、この場合サーバｓ２が存在しているので、全体がアドホックネットワークとなっている場合とは多少処理は異なる。すなわちアクセスポイントＡＰｘ−１と直接通信を行うことができない無線通信端末装置（例えば端末ｃ−２）とそのような無線通信端末装置の近隣の管理者端末として機能する無線通信端末装置（例えば端末ｃ−１）は、図３などで述べたような処理を行って、通信管理ＤＢ１０４にデータを保持することになる。端末ｃ−１の無線通信可能範囲Ｃ内に他の管理者端末が存在していれば、そのような管理者端末と管理情報の交換を行っても良い。そして、このような無線通信端末装置の近隣の管理者端末である無線通信端末装置の通信管理ＤＢ１０４で管理されている端末範囲内において無線通信端末装置間で通話を行う場合には、アドホックネットワークについて述べたのと同様の処理を実施する。すなわち、ホップ数をカウントして図１１や図１７でジッタバッファサイズや補完データサイズを調整する。
【００８８】
また、管理者端末である無線通信端末装置が管理している非管理者端末の情報については、サーバｓ２に通知しておき、管理者端末経由で通信を行うように設定する。
【００８９】
そして、端末ｃ−１のような管理者端末の通信管理ＤＢ１０４に管理されている端末範囲内の端末ではない端末間（例えば端末ｃ−２と端末ａ−１）の通話の場合には、端末ｃ−１のような管理者端末は、中継装置として機能して端末ｃ−２からの発信要求パケットを、アクセスポイントＡＰｘ−１を介してサーバｓ２に送信するようにする。そうすると、サーバｓ２は、端末ａ−１に対して発信要求パケットを転送するような形で、通常の接続確立のための処理を実施する。なお、この場合、端末ｃ−２についてのホップ数は端末ｃ−２からアクセスポイントＡＰｘ−１までのホップ数となり、端末ｃ−２については、図１１や図１７でジッタバッファサイズや補完データサイズの調整を実施する。
【００９０】
以上のように、アドホックネットワークを一部でも用いる場合には、ジッタバッファや補完データサイズの調整を行って、音声品質の向上を図るものである。
【００９１】
以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。すなわち、上で述べたネットワークを介して通信を行うプロトコルについては様々なバリエーションが可能であり、通話先の端末を正しく特定し、パケットを転送できれば、どのようなものであってもよい。
【００９２】
さらに、初期値テーブル１５０ではなく、適切なジッタバッファサイズや補完データサイズを出力する関数を用意するようにしても良い。
【００９３】
以上本実施の形態をまとめると以下のようになる。
【００９４】
第１の態様に係る無線通信端末装置は、アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、取得されたホップ数に応じてジッタバッファのサイズを決定し、設定するジッタバッファサイズ設定手段とを有する。
【００９５】
アドホックネットワークを介して他の無線通信端末装置と通話を行う場合には、ホップ数に応じてパケット受信の遅延やゆらぎなどが起こりやすくなって、出力される音声の品質を保つのが難しくなる。従って、通話先の無線通信端末からのホップ数に応じたジッタバッファサイズを設定することによって、ホップ数が多い場合にはサイズを大きくしてパケット遅延の増大等に備え、ホップ数が少ない場合にはサイズを小さくして再生遅延を少なくする。
【００９６】
また、上で述べたホップ数取得手段は、通話先の無線通信端末装置との通話途中にも、通話先の無線通信端末装置から受信したパケットからホップ数を取得するようにしてもよい。また、上で述べたジッタバッファサイズ設定手段は、ホップ数取得手段により取得された、通話途中のホップ数に応じてジッタバッファのサイズを動的に変更して設定するようにしてもよい。
【００９７】
アドホックネットワークでは、無線通信端末装置が通話中でも移動する可能性があり、通話端末間のネットワーク構成が変動する可能性がある。従って、このように初期的にジッタバッファサイズをホップ数に応じて設定するだけではなく、通話中でもホップ数の変動に応じて動的にジッタバッファサイズを変更することで、ネットワーク構成の変動に応じて適切なジッタバッファサイズで通話を実施することができるようになる。
【００９８】
さらに、第１の態様に係る無線通信端末装置は、取得されたホップ数に応じて、紛失音声データの最大補完データサイズを決定し、紛失音声データの補完を行う補完処理部に当該最大補完データサイズを設定する補完データサイズ設定手段をさらに有するようにしても良い。ホップ数が多い場合には紛失パケットの数も多くなる可能性が高いので、紛失データの補完を行う補完処理部が補完を行うデータサイズも大きくすることによって、再生音声品質の向上を図るものである。なお、補完を行うデータサイズを大きくすると精度は下がるので可能な限り小さくすべきであり、ホップ数が少ない場合には補完を行うデータサイズを小さく設定する。
【００９９】
また、上で述べたホップ数取得手段は、通話先の無線通信端末装置との通話途中にも、通話先の無線通信端末装置から受信したパケットからホップ数を取得するようにしてもよい。その場合には 補完データサイズ設定手段は、ホップ数取得手段により取得された、通話途中のホップ数に応じて紛失音声データの最大補完データサイズを動的に変更して設定するようにしてもよい。ジッタバッファサイズの場合と同じで、アドホックネットワークの特質に合わせて、ホップ数に応じて最大補完データサイズをも動的に変動させるものである。
【０１００】
第１の態様に係る無線通信端末装置は、自無線通信端末装置が管理者端末として動作する場合には、非管理者端末である他の無線通信端末装置と通信を行い、当該無線通信端末装置の識別情報と当該無線通信端末装置から自装置までのホップ数とを含む管理情報を収集して管理テーブルに登録すると共に、管理者端末として動作する他の無線通信端末装置から当該管理者端末として動作する他の無線通信端末装置が保持する管理テーブルのデータを受信し、自らが保持する管理テーブルに統合する通信管理手段と、管理テーブルに基づき、パケットの送信先の無線通信端末装置を決定する手段とをさらに有するようにしても良い。このような管理テーブルを保持することによって、通話先の端末への経路を容易に特定することができるようになる。なお、管理テーブルに載っていない無線通信端末装置については、問い合わせを他の管理者端末に送信して転送してもらい、どの管理者端末の配下に存在しているかを特定する。また、予め設定されている管理者端末に関連付けられている非管理者端末については、他の管理者端末の配下に存在する場合においても追跡するようにしても良い。
【０１０１】
第２の態様に係る無線通信端末装置は、ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、取得されたホップ数に応じて、紛失音声データの最大補完データサイズを決定し、補完処理部に設定する補完データサイズ設定手段とを有する。
【０１０２】
上で述べたように、ホップ数が多い場合には紛失パケットの数も多くなる可能性が高いので、紛失データの補完を行う補完処理部が補完を行うデータサイズも大きくすることによって、再生音声品質の向上を図るものである。
【０１０３】
なお、上で述べたような処理を無線通信端末装置に実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
【０１０４】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１０５】
（付記１）
アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、
ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、前記通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、
取得された前記ホップ数に応じてジッタバッファのサイズを決定し、設定するジッタバッファサイズ設定手段と、
を有する無線通信端末装置。
【０１０６】
（付記２）
前記ホップ数取得手段は、前記通話先の無線通信端末装置との通話途中にも、前記通話先の無線通信端末装置から受信したパケットからホップ数を取得し、
前記ジッタバッファサイズ設定手段は、前記ホップ数取得手段により取得された、前記通話途中のホップ数に応じて前記ジッタバッファのサイズを動的に変更して設定する
付記１記載の無線通信端末装置。
【０１０７】
（付記３）
取得された前記ホップ数に応じて、紛失音声データの最大補完データサイズを決定し、紛失音声データの補完を行う補完処理部に当該最大補完データサイズを設定する補完データサイズ設定手段
をさらに有する付記１又は２記載の無線通信端末装置。
【０１０８】
（付記４）
前記ホップ数取得手段は、前記通話先の無線通信端末装置との通話途中にも、前記通話先の無線通信端末装置から受信したパケットからホップ数を取得し、
前記補完データサイズ設定手段は、前記ホップ数取得手段により取得された、前記通話途中のホップ数に応じて前記紛失音声データの最大補完データサイズを動的に変更して設定する
付記３記載の無線通信端末装置。
【０１０９】
（付記５）
前記自無線通信端末装置が管理者端末として動作する場合には、非管理者端末である他の無線通信端末装置と通信を行い、当該無線通信端末装置の識別情報と当該無線通信端末装置から自装置までのホップ数とを含む管理情報を収集して前記管理テーブルに登録すると共に、前記管理者端末として動作する他の無線通信端末装置から当該管理者端末として動作する他の無線通信端末装置が保持する管理テーブルのデータを受信し、自らが保持する前記管理テーブルに統合する通信管理手段と、
前記管理テーブルに基づき、パケットの送信先の無線通信端末装置を決定する手段と、
をさらに有する付記１乃至４のいずれか１つ記載の無線通信端末装置。
【０１１０】
（付記６）
アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、
ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、前記通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、
取得された前記ホップ数に応じて、紛失音声データの最大補完データサイズを決定し、補完処理部に設定する補完データサイズ設定手段と、
を有する無線通信端末装置。
【０１１１】
（付記７）
付記１乃至６のいずれか１つ記載の無線通信端末装置を複数含み、前記アドホックネットワークにおけるノードを構成するシステム。
【０１１２】
（付記８）
アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置によって実行されるプログラムであって、
ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、前記通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するステップと、
取得された前記ホップ数に応じてジッタバッファのサイズを決定し、設定するステップと、
を前記無線通信端末装置に実行させるプログラム。
【符号の説明】
【０１１３】
１００ 通信部 １１０ ジッタバッファ １２０ 音声出力処理部
１３０ スピーカ １４０ 音声出力制御部 １５０ 初期値テーブル
１６０ マイク １７０ 音声入力処理部
１８０ 送信データバッファ
１０１ 受信部 １０１１ 受信バッファ
１０２ 通信制御部 １０３ 送信部 １０４ 通信管理ＤＢ
１２１ ＰＬＣ部
【特許請求の範囲】
【請求項１】
アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、
ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、前記通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、
取得された前記ホップ数に応じてジッタバッファのサイズを決定し、設定するジッタバッファサイズ設定手段と、
を有する無線通信端末装置。
【請求項２】
前記ホップ数取得手段は、前記通話先の無線通信端末装置との通話途中にも、前記通話先の無線通信端末装置から受信したパケットからホップ数を取得し、
前記ジッタバッファサイズ設定手段は、前記ホップ数取得手段により取得された、前記通話途中のホップ数に応じて前記ジッタバッファのサイズを動的に変更して設定する
請求項１記載の無線通信端末装置。
【請求項３】
取得された前記ホップ数に応じて、紛失音声データの最大補完データサイズを決定し、紛失音声データの補完を行う補完処理部に当該最大補完データサイズを設定する補完データサイズ設定手段
をさらに有する請求項１又は２記載の無線通信端末装置。
【請求項４】
前記ホップ数取得手段は、前記通話先の無線通信端末装置との通話途中にも、前記通話先の無線通信端末装置から受信したパケットからホップ数を取得し、
前記補完データサイズ設定手段は、前記ホップ数取得手段により取得された、前記通話途中のホップ数に応じて前記紛失音声データの最大補完データサイズを動的に変更して設定する
請求項３記載の無線通信端末装置。
【請求項５】
前記自無線通信端末装置が管理者端末として動作する場合には、非管理者端末である他の無線通信端末装置と通信を行い、当該無線通信端末装置の識別情報と当該無線通信端末装置から自装置までのホップ数とを含む管理情報を収集して前記管理テーブルに登録すると共に、前記管理者端末として動作する他の無線通信端末装置から当該管理者端末として動作する他の無線通信端末装置が保持する管理テーブルのデータを受信し、自らが保持する前記管理テーブルに統合する通信管理手段と、
前記管理テーブルに基づき、パケットの送信先の無線通信端末装置を決定する手段と、
をさらに有する請求項１乃至４のいずれか１つ記載の無線通信端末装置。
【請求項６】
アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、
ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、前記通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、
取得された前記ホップ数に応じて、紛失音声データの最大補完データサイズを決定し、補完処理部に設定する補完データサイズ設定手段と、
を有する無線通信端末装置。
【請求項７】
請求項１乃至６のいずれか１つ記載の無線通信端末装置を複数含み、前記アドホックネットワークにおけるノードを構成するシステム。
【請求項１】
アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、
ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、前記通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、
取得された前記ホップ数に応じてジッタバッファのサイズを決定し、設定するジッタバッファサイズ設定手段と、
を有する無線通信端末装置。
【請求項２】
前記ホップ数取得手段は、前記通話先の無線通信端末装置との通話途中にも、前記通話先の無線通信端末装置から受信したパケットからホップ数を取得し、
前記ジッタバッファサイズ設定手段は、前記ホップ数取得手段により取得された、前記通話途中のホップ数に応じて前記ジッタバッファのサイズを動的に変更して設定する
請求項１記載の無線通信端末装置。
【請求項３】
取得された前記ホップ数に応じて、紛失音声データの最大補完データサイズを決定し、紛失音声データの補完を行う補完処理部に当該最大補完データサイズを設定する補完データサイズ設定手段
をさらに有する請求項１又は２記載の無線通信端末装置。
【請求項４】
前記ホップ数取得手段は、前記通話先の無線通信端末装置との通話途中にも、前記通話先の無線通信端末装置から受信したパケットからホップ数を取得し、
前記補完データサイズ設定手段は、前記ホップ数取得手段により取得された、前記通話途中のホップ数に応じて前記紛失音声データの最大補完データサイズを動的に変更して設定する
請求項３記載の無線通信端末装置。
【請求項５】
前記自無線通信端末装置が管理者端末として動作する場合には、非管理者端末である他の無線通信端末装置と通信を行い、当該無線通信端末装置の識別情報と当該無線通信端末装置から自装置までのホップ数とを含む管理情報を収集して前記管理テーブルに登録すると共に、前記管理者端末として動作する他の無線通信端末装置から当該管理者端末として動作する他の無線通信端末装置が保持する管理テーブルのデータを受信し、自らが保持する前記管理テーブルに統合する通信管理手段と、
前記管理テーブルに基づき、パケットの送信先の無線通信端末装置を決定する手段と、
をさらに有する請求項１乃至４のいずれか１つ記載の無線通信端末装置。
【請求項６】
アドホックネットワークを介して他の無線通信端末装置と通話のための通信を行う無線通信端末装置であって、
ユーザから指定される通話先の無線通信端末装置と自無線通信端末装置との間のホップ数を、前記通話先の無線通信端末装置から受信したパケット又は他の無線通信端末装置の識別情報と当該他の無線通信端末装置迄のホップ数とを格納する管理テーブルから取得するホップ数取得手段と、
取得された前記ホップ数に応じて、紛失音声データの最大補完データサイズを決定し、補完処理部に設定する補完データサイズ設定手段と、
を有する無線通信端末装置。
【請求項７】
請求項１乃至６のいずれか１つ記載の無線通信端末装置を複数含み、前記アドホックネットワークにおけるノードを構成するシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【公開番号】特開２０１０−２３９４８８（Ｐ２０１０−２３９４８８Ａ）
【公開日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願番号】特願２００９−８６６６５（Ｐ２００９−８６６６５）
【出願日】平成２１年３月３１日（２００９．３．３１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願日】平成２１年３月３１日（２００９．３．３１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]