JP5044380B2 - 配信装置及びコーデック変換装置、通信システム - Google Patents

Description

本発明は、複数の移動端末が半2重多対多通信を行う通信システムと、そのような通信システムにおける配信装置及びコーデック変換装置に係り、特に、自営無線システムのように、１通話に参加する複数の移動端末のコーデックが複数種類の場合の通信システムと、コーデック変換装置及び配信装置に関するものである。

公共分野等の自営無線システムは、Ｐｒｅｓｓ−Ｔａｌｋ通信と呼ぶ半2重多対多の通話（グループ通信）を提供する。以下にグループ通信の概要を説明する。
ある移動端末が、グループ番号で識別されるあるグループに発呼すると、配信装置がグループのメンバである複数の移動端末に呼接続する。ひとつの呼に参加する複数の移動端末は、自分以外のグループメンバが送信した音声をすべて聞くことができる。ただし、音声を送信するには、移動端末の使用者が移動端末に付いているボタンを押して音声送信権を配信装置に要求し、認可される必要がある。配信装置は、送信権を持つ移動端末が、グループ内で同時にひとつだけになるよう、送信権の排他制御をする。送信権を要求した使用者は、ブザーやランプ点灯で送信権が認可されたことを知り、送話する。送信された音声を配信装置が他のグループメンバに配信する。送話が終わった使用者は押していたボタンを離し、送信権を解放する。送信権解放通知は配信装置に届き、配信装置は次の送信権要求を待つ。発呼者が呼切断を要求した場合、呼が終了する。

一般に、移動端末のコーデックはシステム毎に統一されている。そのため移動端末同士の通信ではコーデック変換が必要ない。しかし、指令台など、配信装置に有線で接続する端末は、移動端末のコーデックとは異なるＩＴＵ−Ｔ Ｇ．７１１コーデックを使用する。そのため移動端末−有線端末の通信では、コーデック変換が必要である。また、移動端末−移動端末間であっても、システムが異なり、使用されるコーデックが異なる場合、コーデック変換が必要である。

ちなみに、移動端末と有線端末とのコーデックが異なる理由は、前者は狭い無線帯域でも音声情報が伝送できるよう低ビットレートのコーデックを使用するのに対し、有線端末は複数のグループ呼の音声をミキシングして同時に出力する機能が求められ、その場合、ミキシング後の音声信号であるＰＣＭ（Ｐｕｌｓｅ−Ｃｏｄｅ Ｍｏｄｕｌａｔｉｏｎ）を音質劣化なく再生できるよう、ＰＣＭ系のコーデックを使用するからである。

移動端末−有線端末間の通信で必要となるコーデック変換は、配信装置に収納する基地局回線インタフェースカード上で行う。基地局回線インタフェースカードには、基地局回線で通信している移動端末対応にコーデック回路が存在する。移動端末からの音声は、移動端末に対応したコーデック回路でコーデック変換され、有線端末に伝送される。また有線端末からの音声は、コーデック回路でコーデック変換され、対応するチャネルを通って基地局を介し移動端末に伝送される。

別の類似技術としては、第3世代携帯電話のＰｏＣ（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ）がある。ＰｏＣは同一のコーデックを使用する携帯電話端末同士のグループ通信をＩＰで実現する。通常、コーデックの異なる端末同士ではグループ通信できないし、また、その必要がない。その理由は、第3世代携帯電話の標準化団体３ＧＰＰ（Ｔｈｅ ３rｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）、３ＧＰＰ２が端末のコーデックをそれぞれ統一しており、かつＰｏＣは通信事業者に閉じたサービスであること、自営無線システムの有線端末のようなミキシングサービスが必要ないことによる。

別の類似技術としては、ＩＰ電話の会議通話用メディアサーバがある。電話の会議通話は全２重多対多通話である。ひとつの会議通話呼が発生すると、メディアサーバは呼に参加する全ての端末からの音声パケットを同時に受信し、端末ごとのジッタ吸収バッファ（以下ジッタバッファと呼ぶ）に音声パケットを分類する。そして、ジッタバッファ毎に割り当てたコーデック回路でそれぞれの端末の音声をＰＣＭに変換し、ミキシングする。ミキシングした音声を、再度端末のコーデックに変換し、端末に送信する。ジッタバッファに割り当てるコーデック回路は呼毎に決定する。
「ＰｕｓｈＴａｌｋサービスのシステム開発」ＮＴＴＤｏＣｏＭｏテクニカル・ジャーナル Ｖｏｌ．１３ Ｎｏ．４

システム毎にコーデックが異なる従来の自営無線システム向けの移動端末を、コーデックの違いに関係なく共通の配信装置に収容してグループ通信を可能にする場合に、配信装置が必要とするコーデック回路を少なくしたいという課題がある。

ここで従来の自営無線システムと同様、基地局で通信している端末数分のコーデック回路を設ける方法では、コーデックの異なる端末が混在するグループ呼が少ない場合、コーデック回路が数の割りに使用されず効率的でない。これは従来の自営無線システムにもいえることである。

一方、ＩＰ電話の会議通話用メディアサーバと同様、グループ呼に参加する端末数分のコーデック回路を設ける方法では、基地局で通信している端末数に関係なく、同時に存在するグループ呼でかつコーデック変換が必要なグループ呼の参加端末数の総数だけコーデック回路を設ければよい。しかし、ひとつのグループ呼の中では、送信権を有する端末に対応するジッタバッファにくくりつけられたコーデック回路しか実際には使用しておらず、他の端末に対応するジッタバッファのコーデック回路は無音データを処理している。

本発明は、以上の点に鑑み、自営無線システム、プッシュトーク、プレストーク等と呼ばれる半２重多対多の通信（グループ通信）において、ひとつの通話内（通話セッション内）で、送信権を取得しているひとつの無線端末が変わるまで、コーデック変換装置の切換えをする必要がない通信システム及びその通信システムにおける配信装置及びコーデック変換装置を提供することを目的とする。

本発明では、ひとつのグループ呼の中で、コーデックが同じ複数の端末でひとつのコーデック回路を共用する。そのために、本発明では、コーデック変換装置に、受信した複数の音声情報の送信端末が同一か否かを識別し、音声情報を連続して符号化変換する対象として、１通話内で同時に１送信端末だけ選択し、選択した送信端末の音声情報の符号化方式を識別するし、識別した符号化方式の符号化変換を行う符号化変換手段（コーデック）を選択し、符号化方式が異なる複数の前記符号化変換手段とを設けること、を主要な特徴の一つとする。

コーデック変換装置は、
受信した複数の音声情報の送信端末が同一か否かを識別し、
音声情報を連続して符号化変換する対象として、１通話内で同時に１送信端末だけ選択し、
選択した送信端末の音声情報の符号化方式を識別し、
識別した符号化方式の符号化変換を行う符号化変換手段を選択し、
符号化方式が異なる複数の前記符号化変換手段とを備え、
１通話内で、同一の符号化方式の複数の無線端末からの音声情報の符号化変換を、ひとつの符号化変換手段で行うことができる。

前記配信装置が、無線端末からの音声情報を前記コーデック変換装置に転送する場合に、前記配信装置が１通話内で連続したシーケンス番号を付与し、
前記コーデック変換装置は、
選択した送信端末の識別子と、１通話内で受信した音声情報の最新の前記シーケンス番号とを記憶し、
新しく受信した音声情報の前記シーケンス番号が、記憶している前記最新のシーケンス番号よりも大きく、かつ音声情報に付属する送信端末の識別子が、記憶している前記送信端末の識別子と異なっている場合に、
音声情報を連続して符号化変換する対象として、前記新しく受信した音声情報の送信端末を選択することができる。

本発明の第１の解決手段によると、
送信権を要求した無線端末である送信端末が送信した音声情報を、配信装置がコーデック変換装置を介して又は介さないで、ゲートウエイ及び基地局を経て他の複数の無線端末に配信することで、複数の無線端末による半２重多対多の通話を実現する通信システムにおける配信装置であって、
前記配信装置は、
パケットを受信すると、グループ呼の識別子である通話グループ識別情報と、通話グループの呼で受信しうるパケットのソケット情報を示す受信パケット情報と、符号化方式と、現在送信権を取得している無線端末の音声情報を運ぶパケットのソケット情報を示す送信パケット情報とを対応づけて記憶した配信テーブルを検索し、受信したパケットのソケット情報と一致するエントリが前記受信パケット情報に存在するかチェックし、
エントリが存在する場合、前記受信パケットの送信元アドレスがゲートウエイのアドレスか、コーデック変換装置のアドレスかを判定し、
前記受信パケットがゲートウエイからのパケットである場合、通話グループ識別情報に対して、パケットのソケット情報と、現在送信権を取得している無線端末を識別するための送信権要求識別子とを対応つけて記憶した送信権テーブルを参照し、
前記受信パケットのソケット情報および前記受信パケットに含まれる送信権要求識別子が、前記送信権テーブルのエントリと一致する場合は、前記受信パケットは他のグループメンバに配信すべきパケットであると判断し、
前記配信テーブルを参照し、前記受信パケットの前記受信パケット情報に対応して登録されている送信パケット情報に従い、また、前記送信パケット情報のソケット情報が複数の場合は前記受信パケットを複製して、該当するゲートウエイ宛及び／又は前記コーデック変換装置宛の送信パケットを生成し、
さらに、生成した送信パケットが前記コーデック変換装置宛の場合には、通話グループ識別情報に対応して、コーデック変換装置に転送する場合にパケットに付加するシーケンス番号を記憶したシーケンス番号テーブルを参照し、前記シーケンス番号を前記送信パケットに挿入し、前記シーケンス番号テーブルのシーケンス番号をインクリメントし、
完成した送信パケットを送信する
前記配信装置が提供される。

本発明の第２の解決手段によると、
送信権を要求した無線端末である送信端末が送信した音声情報を、配信装置がコーデック変換装置を介して又は介さないで、ゲートウエイ及び基地局を経て他の複数の無線端末に配信することで、複数の無線端末による半２重多対多の通話を実現する通信システムにおけるコーデック変換装置であって、
前記コーデック変換装置は、
前記配信装置から受信したパケットに基づき、通話グループ識別情報に対して、配信装置のポート番号と、受信シーケンス番号と、現時点で送信権を有していると予想される無線端末を識別するための送信権要求識別子とを記憶したジッタバッファを参照し、

（ａ）前記ジッタバッファの配信装置のポート番号及び送信権要求識別子と、受信パケットの配信装置のポート番号及び送信権要求識別子が一致しなかった場合は、
ｉ) 前記ジッタバッファの受信シーケンス番号の方が前記受信パケットのシーケンス番号よりも新しい場合、送信権を獲得した無線端末が切り替わった後、切替前の古いパケットが到着したものと判定して、パケットを廃棄し、
一方、
ｉｉ） 前記ジッタバッファの受信シーケンス番号が０又は空白の場合、グループ呼設定後初めてのパケットであると判断し、または、前記受信パケットのシーケンス番号の方が前記ジッタバッファの受信シーケンス番号と比べ新しい場合、前記受信パケットは送信権を獲得した無線端末が切り替わった最初のパケットと判定して、前記受信パケットのシーケンス番号の値を前記ジッタバッファの受信シーケンス番号にコピーし、前記受信パケットの送信権要求識別子を前記ジッタバッファの送信権要求識別子にコピーすることで前記ジッタバッファのバッファを新しく構築し、

（ｂ） 前記ジッタバッファの配信装置のポート番号及び送信権要求識別子と、前記受信パケットの配信装置のポート番号及び送信権要求識別子が一致した場合は、前記受信パケットのシーケンス番号と前記ジッタバッファの受信シーケンス番号を比較し、前記受信パケットのシーケンス番号の方が大きければ、その値を前記ジッタバッファの受信シーケンス番号に設定し、前記受信パケットを、符号化変換手段への入力バッファの入力待ちキューに、キューの先頭からタイムスタンプが小さい順に並ぶように挿入し、前記符号化変換手段により、第１の符号化方式から第２の符号化方式に前記受信パケットを変換する
前記コーデック変換装置が提供される。

本発明の第３の解決手段によると、
送信権を要求した無線端末である送信端末が送信した音声情報を、配信装置がコーデック変換装置を介して又は介さないで、ゲートウエイ及び基地局を経て他の複数の無線端末に配信することで、複数の無線端末による半２重多対多の通話を実現する通信システムであって、

前記配信装置は、
パケットを受信すると、グループ呼の識別子である通話グループ識別情報と、通話グループの呼で受信しうるパケットのソケット情報を示す受信パケット情報と、符号化方式と、現在送信権を取得している無線端末の音声情報を運ぶパケットのソケット情報を示す送信パケット情報とを対応づけて記憶した配信テーブルを検索し、受信したパケットのソケット情報と一致するエントリが前記受信パケット情報に存在するかチェックし、
エントリが存在する場合、前記受信パケットの送信元アドレスがゲートウエイのアドレスか、コーデック変換装置のアドレスかを判定し、
前記受信パケットがゲートウエイからのパケットである場合、通話グループ識別情報に対して、パケットのソケット情報と、現在送信権を取得している無線端末を識別するための送信権要求識別子とを対応つけて記憶した送信権テーブルを参照し、
前記受信パケットのソケット情報および前記受信パケットに含まれる送信権要求識別子が、前記送信権テーブルのエントリと一致する場合は、前記受信パケットは他のグループメンバに配信すべきパケットであると判断し、
前記配信テーブルを参照し、前記受信パケットの前記受信パケット情報に対応して登録されている送信パケット情報に従い、また、前記送信パケット情報のソケット情報が複数の場合は前記受信パケットを複製して、該当するゲートウエイ宛及び／又は前記コーデック変換装置宛の送信パケットを生成し、
さらに、生成した送信パケットが前記コーデック変換装置宛の場合には、通話グループ識別情報に対応して、コーデック変換装置に転送する場合にパケットに付加するシーケンス番号を記憶したシーケンス番号テーブルを参照し、前記シーケンス番号を前記送信パケットに挿入し、前記シーケンス番号テーブルのシーケンス番号をインクリメントし、
完成した送信パケットを送信し、

及び、

前記コーデック変換装置は、
前記配信装置から受信したパケットに基づき、通話グループ識別情報に対して、配信装置のポート番号と、受信シーケンス番号と、現時点で送信権を有していると予想される無線端末を識別するための送信権要求識別子とを記憶したジッタバッファを参照し、

（ａ）前記ジッタバッファの配信装置のポート番号及び送信権要求識別子と、受信パケットの配信装置のポート番号及び送信権要求識別子が一致しなかった場合は、
ｉ) 前記ジッタバッファの受信シーケンス番号の方が前記受信パケットのシーケンス番号よりも新しい場合、送信権を獲得した無線端末が切り替わった後、切替前の古いパケットが到着したものと判定して、パケットを廃棄し、
一方、
ｉｉ） 前記ジッタバッファの受信シーケンス番号が０又は空白の場合、グループ呼設定後初めてのパケットであると判断し、または、前記受信パケットのシーケンス番号の方が前記ジッタバッファの受信シーケンス番号と比べ新しい場合、前記受信パケットは送信権を獲得した無線端末が切り替わった最初のパケットと判定して、前記受信パケットのシーケンス番号の値を前記ジッタバッファの受信シーケンス番号にコピーし、前記受信パケットの送信権要求識別子を前記ジッタバッファの送信権要求識別子にコピーすることで前記ジッタバッファのバッファを新しく構築し、

（ｂ） 前記ジッタバッファの配信装置のポート番号及び送信権要求識別子と、前記受信パケットの配信装置のポート番号及び送信権要求識別子が一致した場合は、前記受信パケットのシーケンス番号と前記ジッタバッファの受信シーケンス番号を比較し、前記受信パケットのシーケンス番号の方が大きければ、その値を前記ジッタバッファの受信シーケンス番号に設定し、前記受信パケットを、符号化変換手段への入力バッファの入力待ちキューに、キューの先頭からタイムスタンプが小さい順に並ぶように挿入し、前記符号化変換手段により、第１の符号化方式から第２の符号化方式に前記受信パケットを変換する
前記通信システムが提供される。

本発明によれば、ひとつのグループ呼の中で、コーデックが同じ複数の端末でひとつのコーデック回路を共用するので、ひとつのグループ呼で使用するコーデック回路数が、使用するコーデックの種類の数だけになり、コーデック回路を従来より大幅に減らすことが可能になる。

本発明によると、自営無線システム、プッシュトーク、プレストーク等と呼ばれる半２重多対多の通信（グループ通信）において、ひとつの通話内（通話セッション内）で、送信権を取得しているひとつの無線端末が変わるまで、コーデック変換装置の切換えをする必要がない通信システム及びその通信システムにおける配信装置及びコーデック変換装置を提供することができる。

最初に、ネットワーク構成、装置構成、メッセージシーケンスを説明する。次に音声パケットのコーデック変換処理をフローチャートとテーブルを用いて説明する。最後に、前記テーブルの初期化処理（主に呼設定時に実施）をフローチャートとテーブルを用いて説明する。

１．システム構成
図１は、本実施の形態が対象とする自営無線システムのネットワーク構成図を示す。
移動端末１００ａは無線方式１を使用し、基地局１０１ａと通信する。同様に移動端末１００ｂ、１００ｃは無線方式２を使用して基地局１０１ｂと通信する。基地局１０１ａ、１０１ｂ、１０１ｃはアクセス網１０２に接続する。アクセス網１０２はゲートウエイ１０４ａ、１０４ｂに接続する。ゲートウエイ１０４ａ、１０４ｂは有線通信網１０３のゲートウエイ装置である。ゲートウエイ１０４ａ、１０４ｂはアクセス網で使用するＩＳＤＮプロトコル（ただし下位レイヤにＩＰを使用）を、有線通信網１０３で使用するＳＩＰプロトコルに変換する。したがって、ゲートウエイ１０４ａ、１０４ｂは配下の移動端末のそれぞれに対応する仮想的なＳＩＰ端末機能を有する。有線通信網１０３には、呼制御装置１０５、配信装置１０６、コーデック変換装置１０７が存在する。呼制御装置１０５は、ゲートウエイ１０４ａ、１０４ｂ、配信装置１０６の間のSIPメッセージをルーティングする。配信装置１０６は、グループ通信の呼設定、呼解放、送信権制御、音声フローの複製配信を行う。コーデック変換装置１０７は、配信装置１０６から受信した音声フローをコーデック変換し、再び配信装置１０６に送信する。配信装置１０６とコーデック変換装置１０７が、本実施の形態の主要部分である。基地局１０１ａは論理的にゲートウエイ１０４ａ配下にあるものとする。つまり、基地局１０１ａはゲートウエイ１０４ａと通信するが、ゲートウエイ１０４ｂとは通信しない。一方、基地局１０１ｂ、１０１ｃは論理的にゲートウエイ１０４ｂ配下にあるものとする。

図２に、配信装置１０６の構成図を示す。
配信装置１０６は、ＣＰＵ２００、メモリ２０１、ハードディスク２０２、通信インタフェース２０３を備える。ＣＰＵ２００はメモリ２０１内のプログラムを実行する中央演算装置である。メモリ２０１はプログラム領域２０４とデータ領域２０７を有する。配信制御モジュール２０５、呼接続プロトコルモジュール２０６は、ＣＰＵ２００にロードされ、適宜実行される。データ領域２０７の各テーブルは、ＣＰＵ２００によりアクセスされ、データの読出し及び／又は書込みが適宜行われる。

ハードディスク２０２は、装置の電源ＯＮ／ＯＦＦにかかわらず保持したいデータを有する。通信インタフェース２０３は、ゲートウエイ１０４ａ、１０４ｂ、呼制御装置１０５、コーデック変換装置１０７と通信するためのインタフェース回路である。

プログラム領域２０４には配信制御モジュール２０５と呼接続プロトコルモジュール２０６を有する。配信制御モジュール２０５は、グループ通信の呼設定、呼解放、送信権制御、音声フローの複製配信を行う。呼接続プロトコルモジュール２０６は、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）プロトコルの制御を行う。データ領域２０７には、コーデックテーブル２０８、ＲＴＣＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）フローテーブル２０９、送信権テーブル２１０、配信テーブル２１１、シーケンス番号テーブル２１２を有する。

図３に、コーデックテーブル２０８を示す。
コーデックテーブル２０８は、コーデック変換装置１０７がサポートするコーデックの種類を登録したものである（図３参照）。コーデックテーブル２０８には、コーデック変換装置３００毎に、コーデック種別３０１、及び、ＲＴＰクロックレート３０２を、予め記憶する。コーデック変換装置３００はコーデック変換装置１０７のアドレスを格納する。コーデック種別３０１はコーデック変換装置１０７がサポートするコーデック種別を格納する。ＲＴＰクロックレート３０２は、コーデック種別毎の、音声パケットに設定するタイムスタンプの１秒当たりの増加量（８０００Ｈｚなら８０００）を格納する。本テーブルは保守者が自営無線システム構築時に配信装置１０６に設定する。

図４（上図）は、ＲＴＣＰフローテーブルの図である。
ＲＴＣＰフローテーブル２０９は、配信装置１０６とゲートウエイ１０４ａ、１０４ｂとの間に設定する、音声のＲＴＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）フロー４０１と送信権制御のＲＴＣＰフロー４０６とを対応付ける。ＲＴＣＰフローテーブル２０９は、通話グループ４００に対して、ＲＴＰ４０１について、ゲートウエイのＩＰアドレス４０２及びＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ポート４０３、配信装置のＩＰアドレス４０４及びＵＤＰポート４０５が記憶され、また、ＲＴＣＰ４０６について、ゲートウエイのＩＰアドレス４０７及びＵＤＰポート４０８、配信装置のＩＰアドレス４０９及びＵＤＰポート４１０が記憶される。ＲＴＣＰフローテーブル２０９は、例えば、グループ通信開始要求の処理の際に記憶することができる。

図４（下図）は、送信権テーブルの図である。
送信権テーブル２１０は、送信権を与えた端末のＲＴＰフローを管理する。送信権テーブル２１０には、通話グループ４２０に対して、ソケット情報（送信元ＩＰアドレス４２１、送信元ＵＤＰポート４２２、宛先ＩＰアドレス４２３、宛先ＵＤＰポート４２４）と、送信権の要求名を識別するための識別情報であるＳＳＲＣ（送信権要求識別子）（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｏｕｒｃｅ）４２５が記憶される。ＳＳＲＣの選択方法としては乱数を使用したり、端末アドレスから算出したりする方法がある。なお、本実施の形態では、必ずしもＳＳＲＣのみから端末アドレスを特定できる必要はなく、グループメンバが互いに異なるＳＳＲＣを使ってさえすれば良い。送信権テーブル２１０は、例えば、送信権要求の処理の際に記憶することができる。

通話グループ４２０はグループ呼の識別子である。送信元ＩＰアドレス４２１、送信元ＵＤＰポート４２２、宛先ＩＰアドレス４２３、宛先ＵＤＰポート４２４は、現在送信権を取得している移動端末の音声情報を運ぶＲＴＰパケットのソケット情報を示す。ＳＳＲＣ４２５は、現在送信権を取得している移動端末のＳＳＲＣである。

図５（上図）は、配信テーブルの図である。
配信テーブル２１１は、ゲートウエイ１０４ａ、１０４ｂ、コーデック変換装置１０７から受信したＲＴＰフローを、どこへ配信するかを管理する（図５参照）。配信テーブル２１１には、通話グループ５００に対して、受信パケット情報５０２、コーデック５０６、ＭＳ数５０７、送信パケット情報５０９が記憶される。なお、ＭＳ数は、例えば、発信端末の台数である。配信テーブル２１１は、例えば、グループ通信開始要求処理の際に設定される。

通話グループ５００はグループ呼の識別子である。受信パケット情報５０２は、通話グループ５００の呼で受信しうる全てのＲＴＰパケットのソケット情報を示す。すなわち、受信パケット情報５０２には、送信元ＩＰアドレス５０１、送信元ＵＤＰポート５０３、宛先ＩＰアドレス５０４、宛先ＵＤＰポート５０５の組が登録されている。送信パケット情報５０９は、通話グループ５００の各受信パケット情報の呼に対して送信すべき全てのＲＴＰパケットのソケット情報を示す。すなわち、送信パケット情報５０９には、送信元ＩＰアドレス５０８、送信元ＵＤＰポート５１０、宛先ＩＰアドレス５１１、宛先ＵＤＰポート５１２の組が登録されている。

図５（下図）は、シーケンス番号テーブルの図である。
シーケンス番号テーブル２１２は、配信装置１０６がコーデック変換装置１０７にＲＴＰパケットを転送する際、同一グループ通信内で連続したシーケンス番号を付与するために使用する。シーケンス番号テーブル２１２は、通話グループ５２０に対するシーケンス番号５２１が記憶される。図５において、シーケンス番号テーブル２１２の通話グループ５２０はグループ呼の識別子である。シーケンス番号５２１は、通話グループ５２０のＲＴＰパケットをコーデック変換装置１０７に転送する場合に、パケットに付加するシーケンス番号を表す。

次に、図６に、コーデック変換装置１０７の構成図を示す。
コーデック変換装置１０７は、ＣＰＵ６００、メモリ６０１、通信インタフェース６０２、デコーダ６０３、エンコーダ６０４を備える。ＣＰＵ６００はメモリ６０１内のプログラムを実行する中央演算装置である。通信インタフェース６０２は、配信装置１０６と通信するためのインタフェース回路である。

デコーダ６０３は、配信装置１０６から受信した音声データを、ＰＣＭに変換する回路である。本図においてデコーダＡ００１とデコーダＡ００２はコーデック種別がＡのデコーダであることを示す。同様にデコーダＢ００１、デコーダＢ００２はコーデック種別がＢのデコーダであることを示す。エンコーダ６０４は、デコーダ６０３でＰＣＭ化した音声データを、移動端末用のコーデックにエンコードするための回路である。本図においてエンコーダＡ１０１とＡ１０２はコーデック種別がＡのエンコーダであることを示す。同様にエンコーダＢ１０１、Ｂ１０２はコーデック種別がＢのエンコーダであることを示す。本図からも判るように、コーデック変換装置１０７はコーデック種別毎に複数のデコーダ及びエンコーダを有する。そのため、コーデック変換制御モジュール７０２はグループ呼が発生した場合に、使用するデコーダ、エンコーダを動的に割り当て、呼の終了と共に解放する。デコーダ、エンコーダ各回路毎の割り当て済みあるいは空きの状態を表すのが、コーデック使用中マップ７０６である。例えば、コーデックＡの移動端末１０台とコーデックＢの移動端末５台が参加するグループ呼が発生した場合、デコーダＡから１回路、エンコーダＡから１回路、デコーダＢから１回路、エンコーダＢから１回路を割り当てるというのが、本実施の形態の主要部分のひとつである。（デコーダＡ、エンコーダＡを１０回路ずつ、デコーダＢ、エンコーダＢを５回路ずつ割り当てる、ということはしない。）

図７は、コーデック変換装置のメモリ内の構成を示す図である。
メモリ６０１はプログラム領域７０１とデータ領域７０４を有する。コーデック変換制御モジュール７０２、呼接続プロトコルモジュール７０３は、ＣＰＵ６００にロードされ、適宜実行される。データ領域７０４の各テーブル及びバッファは、ＣＰＵ６００によりアクセスされ、データの読出し／書込みが適宜行われる。

プログラム領域７０１には、コーデック変換制御モジュール７０２と呼接続プロトコルモジュール７０３を有する。コーデック変換制御モジュール７０２は、グループ通信の呼設定に伴うコーデック変換パターンの設定、コーデック回路の割当、ジッタバッファ制御を行う。呼接続プロトコルモジュール７０３は、ＳＩＰプロトコルの制御を行う。データ領域７０４には、コーデックリソース管理テーブル７０５、コーデック使用中マップ７０６、ＲＴＰフローテーブル７０７、コーデック変換テーブル７０８、ＲＴＰジッタバッファ７０９、デコードデータジッタバッファ７１０を有する。

図８（上図）は、コーデックリソース管理テーブルの図である。
コーデックリソース管理テーブル７０５は、コーデック変換装置１０７が有するコーデック回路の回路数、コーデック種別を管理する。コーデックリソース管理テーブル７０５には、コーデック種別８００に対して、フレームレート８０８、ＲＴＰクロックレート８０１、リソース量８０３（エンコーダ８０２、デコーダ８０３）、使用量８０５（エンコーダ８０６、デコーダ８０７）が記憶される。

図８（下図）は、コーデック使用中マップの図である。
コーデック使用中マップ７０６は、コーデック回路毎の使用中あるいは未使用を表すビットマップである。コーデック使用中マップ７０６には、デコーダＡ００１、Ａ００２、・・・、及び、デコーダＢ００１、Ｂ００２、・・・、の使用状況（例、ＯＮ又はＯＦＦ、１又は０等）が記憶される。

図９（上図）は、ＲＴＰフローテーブルの図である。
ＲＴＰフローテーブル７０７は、コーデック変換装置１０７と配信装置１０６との間に設定したＲＴＰフローのコーデック種別を管理する。ＲＴＰフローテーブル７０７には、通話グループ９００に対して、コーデック変換装置９０２についてＩＰアドレス９０１及びＵＤＰポート９０３、配信装置９０４についてＩＰアドレス９０５及びＵＤＰポート９０６、コーデック９０７が記憶される。通話グループ９００はグループ呼の識別子である。コーデック変換装置９０２と配信装置９０４には、コーデック９０７毎に設定したＲＴＰフローのソケット情報が設定されている。すなわちＩＰアドレス９０１とＵＤＰポート９０３にはコーデック変換装置１０７の使用するＩＰアドレスとＵＤＰポート番号が、ＩＰアドレス９０５とＵＤＰポート９０６には配信装置１０６の使用するＩＰアドレスとＵＤＰポート番号が設定されている。

図９（下図）は、コーデック変換テーブルの図である。
コーデック変換テーブル７０８は、配信装置１０６から受信したＲＴＰフローをどのコーデック回路に入力し、出力をどのＵＤＰポートから配信装置１０６に返送したらよいかを管理する。コーデック変換テーブル７０８には、通話グループ９１０に対して、配信装置ＵＤＰポート９１１、デコーダＩＤ９１２、エンコーダＩＤ９１３、コーデック変換装置ＵＤＰポート９１４が記憶される。

通話グループ９１０はグループ呼の識別子である。配信装置ＵＤＰポート９１１はＲＴＰフローテーブル７０７のＵＤＰポート９０６と同じである。デコーダＩＤ９１２は、配信装置ＵＤＰポート９１１の受信ＲＴＰフローを入力すべきデコーダを示す。エンコーダＩＤ９１３は、デコーダＩＤ９１２が示すデコーダが出力したＰＣＭの音声情報を入力すべきエンコーダを示す。コーデック変換装置ＵＤＰポート９１４は、エンコーダＩＤ９１３が示すエンコーダが出力した音声情報を送出すべきＲＴＰフローを示す。

図１０（上図）は、ＲＴＰジッタバッファの図である。
ＲＴＰジッタバッファ７０９は、送信権を有する端末からの音声パケットをある時間格納し、ジッタの吸収およびパケット順序の並べ替えを行う。ＲＴＰジッタバッファ７０９は、通話グループ１０００に対して、配信装置ＵＤＰポート１００１、受信シーケンス番号１００２、ＳＳＲＣ１００３、次回入力時刻１００４、次回入力タイムスタンプ１００５、先頭ポインタ１００６、末尾ポインタ１００７が記憶される。通話グループ１０００はグループ呼の識別子である。配信装置ＵＤＰポート１００１はＲＴＰフローテーブル７０７のＵＤＰポート９０６と同じである。

図１０（下図）は、デコードデータジッタバッファの図である。
デコードデータジッタバッファ７１０は、コーデック変換の前半処理であるデコード処理が終わったデータをある時間格納し、デコード処理のジッタの吸収を行う。デコードデータジッタバッファ７１０には、エンコーダＩＤ１０１０に対して、次回入力時刻１０１１、先頭ポインタ１０１２、末尾ポインタ１０１３が記憶される。

エンコーダＩＤ１０１０は、ＰＣＭ音声情報を入力すべきエンコーダを示す。次回入力時刻１０１１は、エンコーダに音声情報を次回入力すべき時刻を示す。先頭ポインタ１０１２は、エンコーダＩＤ１０１０が示すエンコーダに入力すべきＰＣＭ音声情報をデコーダ出力順に並べたキューの先頭へのポインタである。末尾ポインタ１０１３は、キューの最後尾の音声情報へのポインタである。

図１１に、呼制御装置が有する端末コーデックテーブルの図を示す。
端末コーデックテーブル１１００は、端末アドレス１１１１に対して、コーデック種別１１１２、ＲＴＰクロックレート１１１３を含む。コーデック種別１１１２は端末が使用するコーデックの種類を表す。ＲＴＰクロックレート１１１３は、音声パケットに設定するタイムスタンプの１秒当たりの増加量（８０００Ｈｚなら８０００）を表す。端末コーデックテーブル１１００は、端末の位置登録の処理等の際に、または、予め設定することができる。

２．シーケンス図
２−１．位置登録
次にメッセージシーケンスを説明する。
図１２に、移動端末がグループ通信を行う前に必要な、位置登録のシーケンス図を示す。
移動端末１００ａの電源がＯＮになると（ステップ１２００）、端末番号を含む位置登録要求メッセージ１２０１を基地局１０１ａに送信する。基地局１０１ａは位置登録要求メッセージ１２０２をゲートウエイ１０４ａに送信する。ゲートウエイ１０４ａは、移動端末１００ａの端末番号と基地局１０１ａを対応付けて記憶する（ステップ１２０３）。そして端末番号に対応した仮想ＳＩＰ端末機能を起動し、端末番号から端末アドレスを作成し、端末アドレスを含むＲＥＧＩＳＴＥＲメッセージ１２０４を呼制御装置１０５に送信する。端末アドレスとして、例えば“端末番号＠ドメイン名”を使う。呼制御装置１０５は、ＲＥＧＩＳＴＥＲメッセージ１２０４の送信元であるゲートウエイ１０４ａと端末アドレスを対応付けて記憶する（ステップ１２０５）。さらに端末アドレスから端末固有情報を検索する（ステップ１２０６）。ここで、端末のコーデックに関しては、端末コーデックテーブル１１００（図１１参照）を検索する。

図１１において、移動端末１００ａはｍｓ１＠ｎｅｔＡとすると、コーデックＡを使用し、ＲＴＰクロックレートが８０００Ｈｚであることがわかる。このコーデック種別１１１２及びＲＴＰクロックレート１１１３を含む情報を、呼制御装置１０５はＰＵＢＬＩＳＨメッセージ１２０７に設定してゲートウエイ１０４ａに送信する。

ゲートウエイ１０４ａはステップ１２０８において、呼制御装置１０５が有する端末コーデックテーブル１１００と同様のテーブルを有し、そのテーブルを移動端末１００ａについて作成する。そしてＰＵＢＬＩＳＨメッセージ１２０７に対するＯＫ応答１２０９を呼制御装置１０５に送信する。呼制御装置１０５はＲＥＧＩＳＴＥＲメッセージ１２０４に対するＯＫ応答１２１０をゲートウエイ１０４ａに送信する。さらに、ＮＯＴＩＦＹメッセージ１２１３を配信装置１０６に送信し、移動端末１００ａがゲートウエイ１０４ａ配下で位置登録したことを通知する。配信装置１０６は移動端末１００ａの端末アドレスとゲートウエイ１０４ａを、所定のテーブルに対応付けて記憶する（ステップ１２１４）。そしてＮＯＴＩＦＹメッセージ１２１３に対するＯＫ応答１２１５を呼制御装置１０５に送信する。一方、ＯＫ応答１２１０を受信したゲートウエイ１０４ａは、基地局１０１ａに位置登録受付メッセージ１２１１を送信する。基地局１０１ａは移動端末１００ａに位置登録受付メッセージ１２１２を送信する。以上で位置登録処理が完了する。

２−２．開始要求
図１３（ａ）および（ｂ）に、移動端末がグループ通信を開始する場合の前半のシーケンス図、後半のシーケンス図を示す。
まず、基地局１０１ａが移動端末１００ａから、グループ番号を含むグループ通信の開始要求を受信する（ステップ１３００）と、グループ番号を含むグループ呼要求メッセージ１３０１をゲートウエイ１０４ａに送信する。ゲートウエイ１０４ａはグループ呼要求メッセージ１３０１に含まれる呼び出すべきグループ番号をＩＮＶＩＴＥメッセージ１３０２に設定して、次のような情報を含むＩＮＶＩＴＥメッセージを作成し、呼制御装置１０５に送信する。

図１７に、ＩＮＶＩＴＥメッセージ１３０２のメッセージフォーマットを示す。ＩＮＶＩＴＥ１７００はメッセージ種別を示す。Ｆｒｏｍヘッダ１７０１は発信端末のアドレスを設定する。Ｔｏヘッダ１７０２は呼び出すべきグループ番号を含む宛先アドレスを設定する。ここで“０００３”は移動端末１０１ａが呼び出しを要求したグループの番号、“ｐｔｓｅｒｖｅｒ．ｎｅｔＡ”は、配信装置１０６のアドレスである。セッション情報１７０３は、移動端末１００ａのコーデック種別（本図ではコーデックＡ）、およびＲＴＰクロックレート（本図では８０００Ｈｚ）、移動端末１００ａからの／への音声フローをゲートウエイ１０４ａと配信装置１０６が送受信する際に使用するゲートウエイ１０４ａのＵＤＰポート（本図では１００００）、そして送信権制御メッセージ（ＲＴＣＰパケット）をゲートウエイ１０４ａと配信装置１０６が送受信する際に使用するゲートウエイ１０４ａのＵＤＰポート（本図では１００１０）を含む。コーデック種別とＲＴＰクロックレートは、移動端末１００ａが位置登録したときにゲートウエイ１０４ａが作成した端末コーデックテーブル（図１１）を参照して値を設定する。ＵＤＰポートはその時点で空いている番号を割り当てる。

次に、呼制御装置１０５はＩＮＶＩＴＥメッセージ１３０２のＴｏヘッダ１７０２のドメイン名が“ｐｔｓｅｒｖｅｒ．ｎｅｔＡ”であることから、ＩＮＶＩＴＥメッセージを配信装置１０６にルーティングする。配信装置１０６は、次のような情報を含むＳｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ１３０４を作成し、呼制御装置１０５に送信する。

図１７に、Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ１３０４のメッセージフォーマットを示す。Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ１７１０はメッセージ種別である。Ｆｒｏｍヘッダ１７１１およびＴｏヘッダ１７１２は、ＩＮＶＩＴＥメッセージ１３０２と同じ値を設定する。セッション情報１７１３は、移動端末１００ａのコーデック種別（本図ではコーデックＡ）、およびＲＴＰクロックレート（本図では８０００Ｈｚ）、移動端末１００ａからの／への音声フローをゲートウエイ１０４ａと配信装置１０６が送受信する際に使用する配信装置１０６のＵＤＰポート（本図では３０００１）、そして送信権制御メッセージ（ＲＴＣＰパケット）をゲートウエイ１０４ａと配信装置１０６が送受信する際に使用する配信装置１０６のＵＤＰポート（本図では３００１１）を含む。ＵＤＰポートはその時点で空いている番号を割り当てる。

次に、呼制御装置１０５は発信元のゲートウエイ１０４ａにＳｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージをルーティングする。ゲートウエイ１０４ａがＳｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ１３０５を受信すると、移動端末１００ａが送受信するコーデックＡの音声フローに関し、ゲートウエイ１０４ａと配信装置１０６の間のＲＴＰセッションのネゴシエーションが完了する。

ゲートウエイ１０４ａは発信元移動端末の基地局を特定して（ステップ１３０６）、グループ呼設定メッセージ１３０７を送信する。基地局１０１ａは通話用無線チャネルを設定する（ステップ１３０８）。そしてグループ呼設定メッセージ１３０７に対する呼設定受付メッセージ１３０９をゲートウエイ１０４ａに送信する。ゲートウエイ１０４ａは、Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ１３０５を受信したことを意味するＰＲＡＣＫ（Ｐｒｅ−ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージ１３１０を呼制御装置１０５に送信する。呼制御装置１０５はＰＲＡＣＫメッセージを配信装置１０６にルーティングする。配信装置１０６は、グループメンバの呼び出しを開始する（ステップ１３１２）。ここで、グループメンバは移動端末１００ｂ（ｍｓ２＠ｎｅｔＡ）および移動端末１００ｃ（ｍｓ３＠ｎｅｔＡ）とする。

図１３（ｂ）に進む。配信装置１０６は、移動端末１００ｂ、１００ｃの位置登録時に受信したＮＯＴＩＦＹメッセージで、どちらの端末もゲートウエイ１０４ｂの配下にいることを知っている。そこで、配信装置１０６は、ＩＮＶＩＴＥメッセージ１３２０に移動端末１００ｂ、１００ｃの両方に着信するための情報を設定して、次のような情報を含むＩＮＶＩＴＥメッセージ１３２０を作成し、呼制御装置１０５に送信する。

図１８にＩＮＶＩＴＥメッセージ１３２０のフォーマットを示す。ＩＮＶＩＴＥ１８００はメッセージ種別である。Ｆｒｏｍヘッダ１８０１は呼び出し対象のグループ番号を設定する。Ｔｏヘッダ１８０２は、着信対象の移動端末のひとつである移動端末１００ｂの端末アドレスを設定する。セッション情報１８０３ａ、１８０３ｂ、１８０３ｃ、１８０３ｄは、コーデック変換装置１０７がサポートする全てのコーデック種別毎にひとつずつ設定する。コーデック種別とＲＴＰクロックレートは、図３に示すコーデックテーブル２０８を参照して設定する。セッション情報１８０３ａ、１８０３ｂ、１８０３ｃ、１８０３ｄのＵＤＰポートは、移動端末１００ｂまたは１００ｃからの／への音声フローをゲートウエイ１０４ａと配信装置１０６が送受信する場合に使用する配信装置１０６のＵＤＰポートである。またＲＴＣＰは送信権制御メッセージをゲートウエイ１０４ａと配信装置１０６が送受信する際に使用する配信装置１０６のＵＤＰポートである。これらのポートはその時点で空いている番号を割り当てる。宛先アドレスリスト１８０４は、Ｔｏヘッダ１８０２に設定した移動端末と同じゲートウエイに位置する、呼び出し対象の全ての端末のアドレスを設定する。

図１３（ｂ）に戻る。ＩＮＶＩＴＥメッセージ１３２０を受信した呼制御装置１０５は、メッセージ中のＴｏヘッダ１８０２のｍｓ２＠ｎｅｔＡがゲートウエイ１０４ｂ配下にいることを知っているので、ゲートウエイ１０４ｂにＩＮＶＩＴＥメッセージ１３２１を送信する。ゲートウエイ１０４ｂは移動端末１００ｂおよび１００ｃが位置する基地局１０１ｂを特定する（ステップ１３２２）。ステップ１３２３において、基地局１０１ｂへのグループ呼をまだ設定していないことから、基地局１０１ｂにグループ呼設定メッセージ１３２４を送信する。基地局１０１ｂは無線チャネルを設定し（ステップ１３２５）、呼設定受付メッセージ１３２６をゲートウエイ１０４ｂに送信する。ゲートウエイ１０４ｂは、ＩＮＶＩＴＥメッセージ１３２１に対するＯＫ応答１３２７を作成し、呼制御装置１０５に送信する。

図１８に、ＯＫ応答１３２７のフォーマットを示す。ＯＫ応答１８１０はメッセージ種別である。Ｆｒｏｍヘッダ１８１１とＴｏヘッダ１８１２は、ＩＮＶＩＴＥメッセージ１３２０のＦｒｏｍヘッダ１８０１、Ｔｏヘッダ１８０２と同じである。セッション情報１８１３ａ、１８１３ｂは、ＩＮＶＩＴＥメッセージ１３２０に設定されていたセッション情報１８０３ａ、１８０３ｂ、１８０３ｃ、１８０３ｄのうち、移動端末１００ｂ、１００ｃが使用するコーデック種別についてのみ設定する。具体的には、ゲートウエイ１０４ｂは、図１１の端末コーデックテーブルとして移動端末１００ｂ（ｍｓ２＠ｎｅｔＡ）と移動端末１００ｃ（ｍｓ３＠ｎｅｔＡ）のレコードを有している。これを参照し、コーデックＡ用のセッション情報１８１３ａとコーデックＢ用のセッション情報１８１３ｂを設定する。セッション情報中のＵＤＰポートは、それぞれのコーデックのＲＴＰフローに使用するゲートウエイ１０４ｂのＵＤＰポートを表す。またＲＴＣＰは送信権制御メッセージをゲートウエイ１０４ａと配信装置１０６が送受信する際に使用するゲートウエイ１０４ａのＵＤＰポートを表す。これらＵＤＰポートはその時点で空いている番号を割り当てる。宛先アドレスリスト１８１４は、コーデック種別毎に移動端末を分類したものを設定する。

図１３（ｂ）に戻る。ＯＫ応答１３２７を呼制御装置１０５が受信すると、それをＩＮＶＩＴＥメッセージ１３２０の送信元である配信装置１０６にルーティングする。配信装置１０６がＯＫ応答１３２８を受信すると、移動端末１００ｃが送受信するコーデックＡの音声フローと移動端末１００ｂが送受信するコーデックＢの音声フローに関し、ゲートウエイ１０４ｂと配信装置１０６の間のＲＴＰセッションのネゴシエーションが完了する。
配信装置１０６は、グループ呼で使用するコーデックがＡとＢの２つであることを認識して、コーデック変換装置１０７にコーデック変換の設定のためのＩＮＶＩＴＥメッセージ１３２９を送信する。

図１９に、ＩＮＶＩＴＥメッセージ１３２９のフォーマットを示す。ＩＮＶＩＴＥ１９００はメッセージ種別を表す。Ｆｒｏｍヘッダ１９０１は、グループ番号（本図では０００３）と配信装置１０６のアドレス（本図ではｐｔｓｅｒｖｅｒ．ｎｅｔＡ）を設定する。Ｔｏヘッダにはグループ番号とコーデック変換装置のアドレス（本図ではｔｒａｎｓｃｏｄｅｒ．ｎｅｔＡ）を設定する。セッション情報１９０３ａ、１９０３ｂは、グループ呼が使用するコーデックの種類ごとに設定する。グループ呼が使用するコーデック種別、ＲＴＰクロックレート、および配信装置１０６がＲＴＰパケットをコーデック変換装置１０７と送受信する場合に使用するＵＤＰポートを設定する。
図１３（ｂ）に戻る。コーデック変換装置１０７は、コーデック回路の設定をした後、ＯＫ応答１３３０を配信装置１０６に送信する。

図１９に、ＯＫ応答１３３０のフォーマットを示す。ＯＫ応答１９１０はメッセージ種別である。Ｆｒｏｍヘッダ１９１１、Ｔｏヘッダ１９１２はＩＮＶＩＴＥメッセージ１３２９のＦｒｏｍヘッダ１９０１、Ｔｏヘッダ１９０２と同じである。セッション情報１９１３ａ、１９１３ｂは、ＩＮＶＩＴＥメッセージ１３２９のセッション情報１９０３ａ、１９０３ｂに対応して（すなわちコーデックの種類毎に）ひとつずつ設定する。グループ呼が使用するコーデック種別、ＲＴＰクロックレート、およびコーデック変換装置１０７がＲＴＰパケットを配信装置１０６と送受信する場合に使用するＵＤＰポートを設定する。
ＯＫ応答１３３０を配信装置１０６が受信すると、コーデックＡの音声フローとコーデックＢの音声フローに関し、配信装置１０６とコーデック変換装置１０７の間のネゴシエーションが完了する。

配信装置１０６はグループ呼設定開始時のＩＮＶＩＴＥメッセージ１３０３に対するＯＫ応答１３３１を呼制御装置１０５に送信する。呼制御装置１０５はゲートウエイ１０４ａに送信する。ゲートウエイ１０４ａはグループ呼要求メッセージ１３０１に対する呼設定完了メッセージ１３３３を基地局１０１ａに送信する。基地局１０１ａは移動端末１００ａに呼設定完了を通知する（ステップ１３３４）。以上で移動端末１００ａ、１００ｂ、１００ｃによるグループ通話が可能になる。

２−３．終了要求
図１４は、グループ通信の呼解放のシーケンス図である。
次に図１４を用いてグループ通信を終了する場合のシーケンスを説明する。
基地局１０１ａがグループ通信の開始端末である移動端末１００ａからグループ通信の終了要求を受信すると（ステップ１４００）、解放完了メッセージ１４０１をゲートウエイ１０４ａに送信する。さらに無線チャネルを解放する（ステップ１４０２）。解放完了メッセージ１４０１を受信したゲートウエイ１０４ａは、ＢＹＥメッセージ１４０３を呼制御装置１０５に送信する。呼制御装置１０５はＢＹＥメッセージ１４０４を配信装置１０６に送信する。配信装置１０６はＢＹＥメッセージ１４０４に対するＯＫ応答１４０５を呼制御装置１０５に送信する。呼制御装置１０５はＯＫ応答１４０６をゲートウエイ１０４ａに送信する。一方、配信装置１０６は、コーデック変換装置１０７にもＢＹＥメッセージ１４０７を送信する。コーデック変換装置１０７は、コーデック回路の解放を行い、ＯＫ応答１４０８を配信装置１０６に送信する。配信装置１０６は移動端末１００ｂ、１００ｃへの呼解放を開始する（ステップ１４０９）。配信装置１０６はＢＹＥメッセージ１４１０を呼制御装置１０５に送信する。呼制御装置１０５はＢＹＥメッセージ１４１１をゲートウエイ１０４ｂに送信する。ゲートウエイ１０４ｂは移動端末１００ｂ、１００ｃの位置する基地局１０１ｂを特定し(ステップ１４１２)、基地局１０１ｂに対してグループ呼の解放を行っていないことを判定して（ステップ１４１３）、基地局１０１ｂに解放完了メッセージ１４１４を送信する。解放完了メッセージ１４１４を受信した基地局１０１ｂは、無線チャネルを解放する（ステップ１４１５）。ゲートウエイ１０４ｂはさらにＢＹＥメッセージ１４１１に対するＯＫ応答１４１６を呼制御装置１０５に送信する。呼制御装置１０５はＯＫ応答を配信装置１０６にルーティングする。以上でグループ通話が終了する。

２−４．送信権要求
図１５は、移動端末１００ａが送信権を獲得し、音声情報を送信するシーケンス図を示す。
次に、グループ通話が可能な状態、すなわち図１３（ａ）（ｂ）のシーケンスが完了した状態で、音声を送信する手順を図１５を用いて説明する。なお、以下で登場するＴａｌｋ Ｂｕｒｓｔ Ｒｅｑｕｅｓｔメッセージ、Ｔａｌｋ Ｂｕｒｓｔ Ｔａｋｅｎメッセージ、Ｔａｌｋ Ｂｕｒｓｔ Ｇｒａｎｔｅｄメッセージ、Ｔａｌｋ Ｂｕｒｓｔ Ｒｅｌｅａｓｅメッセージ、Ｔａｌｋ Ｂｕｒｓｔ Ｉｌｄｅメッセージは、例えばＰｏＣ規格と同じフォーマットを使用し、ＲＴＣＰパケットで送受信する。これらのパケットと音声情報を運ぶＲＴＰパケットは、呼制御装置１０５を通らない（スルーする）。

基地局１０１ａが移動端末からの送信権要求を受信する（ステップ１５００）。基地局１０１ａは送信権要求メッセージ１５０１をゲートウエイ１０４ａに送信する。ゲートウエイ１０４ａは、Ｔａｌｋ Ｂｕｒｓｔ Ｒｅｑｕｅｓｔメッセージ１５０２を配信装置１０６に送信する。本メッセージには送信権の要求者の識別子としてＲＴＰプロトコルで規定されるＳＳＲＣ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｓｏｕｒｃｅ）を含む。ＳＳＲＣの選択方法としては乱数を使用したり、端末アドレスから算出したりする方法がある。なお、本実施の形態では、必ずしもＳＳＲＣのみから端末アドレスを特定できる必要はなく、グループメンバが互いに異なるＳＳＲＣを使ってさえすれば良い。Ｔａｌｋ Ｂｕｒｓｔ Ｒｅｑｕｅｓｔメッセージ１５０２を受信した配信装置１０６は、送信権をグループ内のメンバの誰にも与えていないことを確認する（ステップ１５０３）。そして移動端末１００ｂ、１００ｃに、移動端末１００ａが送信権を獲得したことを通知するため、Ｔａｌｋ Ｂｕｒｓｔ Ｔａｋｅｎメッセージ１５０４をゲートウエイ１０４ｂに送信する。ゲートウエイ１０４ｂは移動端末１００ｂ、１００ｃの位置する基地局１０１ｂに送信権使用中メッセージ１５０５を送信する。基地局１０１ｂは送信権が使用中であることを移動端末１００ｂ、１００ｃに報知する（ステップ１５０６）。一方、配信装置１０６はＴａｌｋ Ｂｕｒｓｔ Ｇｒａｎｔｅｄメッセージ１５０７をゲートウエイ１０４ａに送信する。ゲートウエイ１０４ａは送信権承認メッセージ１５０８を基地局１０１ａに送信する。基地局１０１ａは移動端末１００ａに送信権承認を通知する（ステップ１５０９）。すると、移動端末１００ａは基地局１０１ａを介してコーデックＡでエンコードした音声情報１５１０をゲートウエイ１０４ａに送信する。ゲートウエイ１０４ａは、グループ呼設定時に配信装置１０６とネゴシエーションしたコーデックＡ用のＵＤＰポートで音声情報１５１０を配信装置１０６に送信する。配信装置１０６は、コーデックＢでエンコードした音声情報を生成するため、ゲートウエイ１０４ａから受信した音声情報１５１０をコーデック変換装置１０７に送信する。

図２７に、このときの音声情報１５１１のＩＰパケットフォーマットを示す。
音声情報１５１１のＩＰパケット２７００は、ＩＰヘッダ２７０１、ＵＤＰヘッダ２７０２、シーケンス番号２７０３、ＲＴＰパケット２７０４を含む。ＩＰヘッダ２７０１には、送信元アドレスとして配信装置１０６のＩＰアドレスを設定し、宛先アドレスとしてコーデック変換装置１０７のＩＰアドレスを設定する。ＵＤＰヘッダ２７０２には、グループ呼設定時に配信装置１０６とコーデック変換装置１０７との間でネゴシエーションした、コーデックＡのフロー用のＵＤＰポート番号を設定する。シーケンス番号２７０３は、ひとつのグループ呼の中で配信装置１０６がコーデック変換装置１０７に送信した音声情報のＩＰパケット２７００にシーケンシャルに設定する番号である。シーケンス番号２７０３の使用目的は後述する。ＲＴＰパケット２７０４は、配信装置１０６がゲートウエイ１０４ａから受信したＲＴＰパケットであり、この中にはゲートウエイ１０４ａがＴａｌｋ Ｂｕｒｓｔ Ｒｅｑｕｅｓｔメッセージ１５０２に設定したＳＳＲＣが含まれている。

図１５に戻る。配信装置１０６は、コーデックＡの音声情報１５１１をコーデック変換装置１０７に送信すると同時に、同じ情報をゲートウエイ１０４ｂに送信する。これは、コーデックＡを使用する移動端末１００ｃ用の音声情報であり、コーデックＡ用のＵＤＰポートで送受信される。ゲートウエイ１０４ｂは、受信したコーデックＡの音声情報１５１２を基地局１０１ｂに送信する。基地局１０１ｂは移動端末１００ｃに送信する。一方、コーデック変換装置１０７はコーデックＡの音声情報１５１１を受信すると、コーデックＢに変換して、コーデックＢの音声情報１５１３を配信装置１０６に返送する。このとき使用するＵＤＰポートは、グループ呼設定時に配信装置１０６とコーデック変換装置１０７との間でネゴシエーションした、コーデックＢのフロー用のＵＤＰポートである。配信装置１０６は、コーデックＢの音声情報１５１４をゲートウエイ１０４ｂに送信する。これは、コーデックＢを使用する移動端末１００ｂ用の音声情報であり、コーデックＢ用のＵＤＰポートで送受信される。ゲートウエイ１０４ｂは、受信したコーデックＢの音声情報１５１４を基地局１０１ｂに送信する。基地局１０１ｂは移動端末１００ｂに送信する。

２−５．解放要求
図１６は、送信権解放のシーケンス図である。
次に、音声情報を送信していた移動端末が送信権を解放するシーケンスを図１６を用いて説明する。本図では移動端末１００ａが送信権を解放する。基地局１０１ａが移動端末１００ａから送信権解放要求を受信する（ステップ１６００）。基地局１０１ａは送信権解放要求メッセージ１６０１をゲートウエイ１０４ａに送信する。ゲートウエイ１０４ａはＴａｌｋ Ｂｕｒｓｔ Ｒｅｌｅａｓｅメッセージ１６０２を配信装置１０６に送信する。配信装置１０６は送信権の移動端末１００ａへの割当を解除し（ステップ１６０３）、Ｔａｌｋ Ｂｕｒｓｔ Ｉｌｄｅメッセージ１６０４をゲートウエイ１０４ｂに送信する。ゲートウエイ１０４ｂは送信権解放通知メッセージ１６０５を基地局１０１ｂに送信し、基地局１０１ｂは移動端末１００ｂ、１００ｃに送信権解放を報知する（ステップ１６０６）。さらに、配信装置１０６はゲートウエイ１０４ａにもＴａｌｋ Ｂｕｒｓｔ Ｉｄｌｅメッセージ１６０７を送信する。ゲートウエイ１０４ａは送信権解放通知メッセージ１６０８を基地局１０１ａに送信し、基地局１０１ａは移動端末１００ａに送信権解放を通知する（ステップ１６０９）。

３．詳細フローチャート
３−１．送信権要求
次に、フローチャートとテーブルによる詳細な処理内容を説明する。
まずは、グループ呼設定完了後、送信権を獲得した移動端末１００ａからの音声パケットがどのように転送され、コーデック変換されるかを説明する。

（１）配信装置
図２３は、配信装置１０６がゲートウエイ１０４ａ、１０４ｂ、コーデック変換装置１０７からＲＴＰパケットを受信した場合のフローチャートである。図１５のシーケンスでは、ゲートウエイ１０４ａからコーデックＡの音声情報１５１０を受信した場合、またはコーデック変換装置１０７からコーデックＢの音声情報１５１３を受信した場合にあたる。

以下ではまずゲートウエイ１０４ａからＲＴＰパケットを受信した場合を説明する。
図２３において、配信装置１０６がＲＴＰパケットを受信すると、ステップ２３０１にて図５に示す配信テーブル２１１を検索する。

図５の配信テーブル２１１において、ステップ２３０１では、受信したＲＴＰパケットのソケットと一致する組が受信パケット情報５０２に存在するかチェックする。全ての通話グループ５００に関し、一致する受信パケット情報５０２がなければ、不正パケットとしてパケットを廃棄し（ステップ２３０７）、終了する。

ステップ２３０１に戻り、受信パケットが移動端末１００ａが送信した音声情報を運ぶＲＴＰパケットの場合、図５の配信テーブル２１１の１段目の情報に一致する。そこでステップ２３０２に移行する。ステップ２３０２では、送信元ＩＰアドレス５０１がゲートウエイ１０４ａまたは１０４ｂのＩＰアドレスか、コーデック変換装置１０７のＩＰアドレスかを判定する。受信パケットはゲートウエイ１０４ａ、すなわちゲートウエイａからのパケットであるのでステップ２３０３に移行する。ステップ２３０３では、図４に示す送信権テーブル２１０に登録されている、所定の通話グループについて、送信権獲得端末に関する情報と、受信パケットが一致しているか判定する。

図４の送信権テーブル２１０において、受信パケットのソケット情報およびＳＳＲＣが、送信権テーブル２１０の各エントリと一致する場合は、受信パケットは他のグループメンバに配信すべきパケットである。したがって、ステップ２３０４に移行し送信パケットを作成する。ステップ２３０３にて受信パケットが送信権テーブル２１０の内容と一致しない場合は、パケットを廃棄する（ステップ２３０７）。

ステップ２３０４では、配信テーブル２１１の送信パケット情報５０９で送信パケットのＩＰヘッダとＵＤＰヘッダを生成する。受信ＲＴＰパケットの受信パケット情報５０２に対応して登録されている送信パケット情報５０９が、生成すべき送信パケットのソケット情報である。受信ＲＴＰパケットの受信パケット情報５０２は１段目であったので、そのパケットを送信する場合のソケット情報は、（送信元ＩＰアドレス、送信元ＵＤＰポート、宛先ＩＰアドレス、宛先ＵＤＰポート）＝（配信装置、３０００１、ゲートウエイｂ、４０００１）、（配信装置、３３００１、コーデック変換装置、４４００１）の２つである。つまり、受信したＲＴＰパケットを複製して、ゲートウエイ１０４ｂ宛とコーデック変換装置１０７宛のパケットを生成する。次にステップ２３０５にて、生成した送信パケットがコーデック変換装置１０７宛の場合には、シーケンス番号テーブル２１２（図５参照）に格納しているシーケンス番号５２１を、ＵＤＰヘッダとＲＴＰパケットの間に挿入し、シーケンス番号テーブル２１２のシーケンス番号５２１をインクリメントする。図２７のＩＰパケット２７００が、完成したコーデック変換装置宛パケットのフォーマットである。

図２３のステップ２３０５で完成したパケットは、ステップ２３０６で装置外に送信する。以上が図１５のシーケンスにおける、音声情報１５１０の受信から音声情報１５１１および１５１２の送信までの処理である。

次に、図２３のフローチャートで、コーデック変換装置からＲＴＰパケットを受信した場合を説明する。図１５のシーケンスでは、コーデックＢの音声情報１５１３を受信した場合にあたる。

図２３のステップ２３０１で、受信ＲＴＰパケットのソケット情報が配信テーブル２１１の受信パケット情報５０２の最下段に一致したとする。ステップ２３０２の判定では、受信ＲＴＰパケットの送信元ＩＰアドレス５０１がコーデック変換装置なので、ステップ２３０８でパケットを作成する。作成手順はステップ２３０４と同じであり、受信パケット情報５０２に対応して登録されている送信パケット情報５０９が、生成すべき送信パケットのソケット情報である。つまり（送信元ＩＰアドレス、送信元ＵＤＰポート、宛先ＩＰアドレス、宛先ＵＤＰポート）＝（配信装置、３０００２、ゲートウエイｂ、４０００２）のパケットを生成する。そしてパケットを送信する（ステップ２３０６）。
なお、配信テーブル２１１において、コーデック５０６とＭＳ数５０７は使用しなかったが、これは、グループ呼設定時に配信テーブル２１１を設定する段階で使用するものであり、詳細は後述する。

（２）コーデック変換装置
次に、コーデック変換装置１０７での音声情報の処理を説明する。図１５のシーケンスでは、配信装置１０６からコーデックＡの音声情報１５１１を受信してから、コーデックＢの音声情報１５１３を送信するまでに相当する。音声情報１５１１のＩＰパケットは図２７のＩＰパケット２７００の形をしている。

図２４は、コーデック変換装置１０７が配信装置１０６から音声情報１５１１を受信した場合のフローチャートである。まず、装置外部からＵＤＰパケットを受信すると、ステップ２４０１にて図９に示すＲＴＰフローテーブル７０７を検索する。

今、配信装置１０６から受信したコーデックＡのＲＴＰパケットのソケット情報は、前述のとおり（送信元ＩＰアドレス、送信元ＵＤＰポート、宛先ＩＰアドレス、宛先ＵＤＰポート）＝（配信装置、３３００１、コーデック変換装置、４４００１）であるので、図９のＲＴＰフローテーブル７０７における通話グループ９００の１段目に一致する。したがって図２４のステップ２４０２に移行するが、もし全ての通話グループ９００に関し一致するものがなければ、パケットを廃棄し（ステップ２４０９）、終了する。

ステップ２４０２では、図１０に示すＲＴＰジッタバッファ７０９に、通話グループ、配信装置ＵＤＰポート及びＳＳＲＣに基づき、受信ＲＴＰパケットに対応するバッファがあるかを調べる。

今、受信したＲＴＰパケットの配信装置のＵＤＰ番号は３３００１であるので、ＲＴＰジッタバッファ７０９において、１段目に注目する。ＳＳＲＣ１００３は、現時点で送信権を有していると予想される移動端末のＳＳＲＣを表す。

もし、グループ呼設定後の初めてのＲＴＰパケットだった場合、ＳＳＲＣ１００３はＮＵＬＬであり、その場合、ステップ２４０２の判定で“Ｎｏ”となる。また、もし送信権を別の端末が獲得した後の初めてのＲＴＰパケットだった場合、ＳＳＲＣ１００３はＮＵＬＬではないが、受信ＲＴＰパケットのＳＳＲＣと一致せず、その場合もステップ２４０２の判定で“Ｎｏ”となる。“Ｎｏ”となった場合、ステップ２４０３にて、受信シーケンス番号１００２と受信パケットのシーケンス番号２７０３をチェックする。まず、受信シーケンス番号１００２がＮＵＬＬの場合、グループ呼設定後初めてのＲＴＰパケットであるので、バッファを新しく構築する対象としてステップ２４０４に進む。また、受信シーケンス番号１００２がＮＵＬＬではない場合、受信パケットのシーケンス番号２７０３とどちらが最新か比較し、受信パケットのシーケンス番号２７０３の方が最新だった場合、送信権獲得端末が切り替わった最初のＲＴＰパケットとして、バッファを新しく構築する対象としてステップ２４０４に進む。一方、受信シーケンス番号１００２の方が受信パケットのシーケンス番号２７０３よりも最新だった場合、送信権獲得端末が切り替わった後、切替前の古いＲＴＰパケットが到着したものと判定し、ステップ２４０９にてパケットを廃棄する。

ステップ２４０４では、受信パケットのシーケンス番号２７０３の値を受信シーケンス番号１００２にコピーする。ステップ２４０５では、先頭ポインタ１００６がＮＵＬＬでない場合、送信権獲得端末が切り替わる前の古いＲＴＰパケットがキューを構成しているので、これを全て解放（廃棄）する。先頭ポインタ１００６は、デコーダに次に入力すべき音声情報のＵＤＰパケットに付随した後方ポインタ２７１１のメモリアドレスを格納している（図２７参照）。後方ポインタ２７１１は、その次にデコーダに入力すべき音声情報のＵＤＰパケットに付随した後方ポインタのメモリアドレスを格納している。この繰り返しで、ＳＳＲＣが同一のＲＴＰパケットがデコーダへの入力順にキューを構成しており、最後のパケットに付随する後方ポインタにはＮＵＬＬが設定されている。従って、これらを解放する場合は、先頭ポインタ１００６から順にパケットを手繰ってはメモリ解放する手続きを、後方ポインタ２７１１がＮＵＬＬになるまで続ければよい。解放完了したあと、先頭ポインタはＮＵＬＬに初期化する。
ステップ２４０６では、受信ＲＴＰパケットのＳＳＲＣをＳＳＲＣ１００３にコピーする。さらに次回入力時刻１００４、次回入力タイムスタンプをＮＵＬＬに初期化する。

ステップ２４０７では、受信ＲＴＰパケットに含まれるタイムスタンプに基いて、先頭ポインタ１００６から始まるキューにパケットを挿入する。ここで、次回入力タイムスタンプ１００５がＮＵＬＬの場合は、送信権獲得端末から受信した最初のパケットであるので、キューの先頭に設定する。すなわち、ＩＰパケット２７００に追加した後方ポインタ２７１１のアドレスを先頭ポインタ１００６に設定する。また、前方ポインタ２７１０、後方ポインタ２７１１の値をＮＵＬＬに設定する。末尾ポインタ１００７に前方ポインタ２７１０のアドレスを設定する。また、次回入力タイムスタンプ１００５に、受信ＲＴＰパケットに含まれるタイムスタンプ値を設定する。さらに、次回入力時刻１００４に、受信ＲＴＰパケットの音声情報をデコーダに入力する時刻を設定する。例えば現在時刻に、パケット到着のジッタ量を加味した値を使用する。

なお、ステップ２４０２にて、ＲＴＰジッタバッファ７０９を参照して、通話グループ１０００及び配信装置ＵＤＰポート１００１が、受信ＩＰパケットのそれらと一致するバッファにおいて、ＳＳＲＣ１００３と受信ＲＴＰパケットのＳＳＲＣが一致した場合は、ステップ２４０８でＳＳＲＣ削除タイマを停止する。ＳＳＲＣ削除タイマとは、配信装置１０６からＲＴＰパケットを全く受信せず、デコーダ入力待ちの音声情報がなくなった時点で開始するタイマである。ＳＳＲＣ削除タイマがタイムアウトした場合にはＳＳＲＣ１００３、次回入力時刻１００４、次回入力タイムスタンプ１００５をＮＵＬＬに初期化する。

ステップ２４１０に移行し、受信パケットのシーケンス番号２７０３と受信シーケンス番号１００２を比較し、シーケンス番号２７０３の方が大きければ、その値を受信シーケンス番号１００２に設定する。

ステップ２４０７に移行して、受信パケットをデコーダへの入力待ちキューに挿入する。まず、次回入力タイムスタンプ１００５と受信ＲＴＰパケットに含まれるタイムスタンプを比較する。受信ＲＴＰパケットの方が小さければ、キューの先頭に挿入し、受信ＲＴＰパケットのタイムスタンプを次回入力タイムスタンプ１００５にコピーする。受信ＲＴＰパケットの方が大きければ、先頭ポインタ１００６を辿って、先頭のＲＴＰパケットのタイムスタンプと比較する。受信ＲＴＰパケットの方が小さければ、キューの先頭に挿入する。受信ＲＴＰパケットの方が大きければ、２番目のパケットのタイムスタンプと比較し、受信ＲＴＰパケットの方が小さければ、２番目のパケットの前に受信ＲＴＰパケットを挿入する。このようにキューの先頭からタイムスタンプが小さい順に並ぶよう、受信ＲＴＰパケットを挿入する。キューの最後尾に挿入することになった場合は、末尾ポインタ１００７を更新する。

図２５は、コーデック変換装置のデコード処理フローを示す図である。
次に、ＲＴＰジッタバッファ７０９から音声情報をデコーダに入力する処理を図２５を用いて説明する。これもコーデック変換制御モジュール７０２で実行する。デコーダ入力処理２５００は周期的に起動する。まず、ＲＴＰジッタバッファ７０９の次回入力時刻１００４を現在時刻と比較し（ステップ２５０１）、まだである場合、および次回入力時刻１００４がＮＵＬＬの場合、処理を終了する。現在時刻が次回入力時刻１００４を過ぎていた場合は、先頭ポインタ１００６を参照し、先頭パケットのタイムスタンプと次回入力タイムスタンプ１００５を比較する（ステップ２５０２）。先頭パケットのタイムスタンプの方が大きければ、先頭パケットの入力時刻ではまだないので、本来入力すべきＲＴＰパケットの代わりにダミーデータをデコーダに入力する（ステップ２５０７）。これは、配信装置１０６とコーデック変換装置１０７の間でパケットロスが生じた場合に起こる。

ステップ２５０２において、先頭パケットのタイムスタンプが次回入力タイムスタンプ１００５以下であれば、先頭パケットをキューから取り出し、音声情報をデコーダに入力する（ステップ２５０３）。入力先のデコーダは、図９に示すコーデック変換テーブル７０８を用いて決定する。

図９のコーデック変換テーブル７０８において、テーブルの１段目を見ると、該当する通話グループの配信装置ＵＤＰポート９１１が３３００１のＲＴＰフロー（ＲＴＰフローテーブル７０７からコーデックＡのフローであることがわかる）は、コーデックＡのデコーダであるＡ００１でデコードした後、コーデックＢのエンコーダであるＢ１０３でエンコードし、コーデック変換装置ＵＤＰポート９１４が４４００２のＲＴＰフローとして配信装置１０６に送信することがわかる（ＲＴＰフローテーブル７０７からコーデックＢのフローであることがわかる）。

図２５のステップ２５０４に移行し、バッファが空になったか、すなわちデコーダへの入力まちパケットがなくなったかを判定する。パケットがなくなった場合は、ＳＳＲＣ削除タイマを起動する（ステップ２５０５）。そしてステップ２５０６において、次回入力時刻１００４、次回入力タイムスタンプ１００５を更新する。次回入力時刻１００４は、図８のコーデックリソース管理テーブル７０５の、コーデック種別８００に対応したフレームレート８０８を参照し、１フレームあたりの時間（本図では４０ｍｓ）を加算した時刻に更新する。次回入力タイムスタンプ１００５は、コーデックリソース管理テーブル７０５の、コーデック種別８００に対応したＲＴＰクロックレート８０１を参照し、１フレームあたりのクロック数（本図では８０００×０．０４ｓ＝３２０）を加算した値に更新する。

次にデコーダが出力したＰＣＭ音声情報をデコードデータジッタバッファ７１０にキューイングする処理を説明する。図２５のデコーダ出力処理２５１０において、コーデック変換制御モジュール７０２がデコーダからの出力を検出すると、コーデック変換テーブル７０８のデコーダＩＤ９１２を検索する（ステップ２５１１）。出力元のデコーダＩＤが見つからなかった場合は出力データを廃棄する（ステップ２５１５）。見つかった場合は、ステップ２５１２に移行する。ステップ２５１２では、デコーダＩＤ９１２に対応する配信装置ＵＤＰポート９１１を求め、ＲＴＰジッタバッファ１０００の配信装置ＵＤＰポート１００１からＳＳＲＣ１００３を参照する。ＳＳＲＣ１００３がＮＵＬＬの場合は、デコーダからの出力は不要になったと判断し、廃棄する（ステップ２５１５）。ＳＳＲＣ１００３がＮＵＬＬでなかった場合は、ステップ２５１３にて、コーデック変換テーブル７０８のデコーダＩＤ９１２に対応するエンコーダＩＤ９１３を求め、ＰＣＭ音声情報を入力すべきエンコーダを特定する。ステップ２５１４にて、デコードデータジッタバッファ７１０（図１０参照）の、エンコーダＩＤ１０１０に対応する入力待ちキューにＰＣＭ音声情報をキューイングする。

送信権を獲得した移動端末が初めて送信した音声情報の場合は、次回入力時刻１０１１がＮＵＬＬになっているので、これを現在時刻＋αの値に設定する。αは、例えばデコーダからのＰＣＭ音声情報の出力ジッタを加味した値を使う。

図２６は、コーデック変換装置のエンコード処理フローを示す図である。
次に、デコードデータジッタバッファ７１０から音声情報をエンコーダに入力する処理を図２６を用いて説明する。これもコーデック変換制御モジュール７０２で実行する。エンコーダ入力処理２６００は周期的に起動する。まず、デコードデータジッタバッファ７１０の次回入力時刻１０１１を現在時刻と比較し、まだである場合、および次回入力時刻１０１１がＮＵＬＬの場合、処理を終了する（ステップ２６０１）。現在時刻が次回入力時刻１０１１を過ぎていた場合は、先頭ポインタ１０１２を参照し、先頭のＰＣＭ音声情報をキューから取り出し、エンコーダＩＤ１０１０が示すエンコーダに入力する（ステップ２６０２）。ステップ２６０３にて、次回入力時刻１０１１を更新する。図８のコーデックリソース管理テーブル７０５の、コーデック種別８００に対応したＲＴＰクロックレート８０１の逆数（すなわち１クロックあたりの時間）を現在時刻に加算し、設定する。ただし、エンコーダの独自仕様として入力頻度を下げてもよく、この場合はＲＴＰクロックレート８０１とは無関係の固有パラメータで加算値を記憶しておく。一方、エンコーダへの入力待ち音声情報がなくなった場合は、次回入力時刻１０１１にＮＵＬＬを設定する。

次に、エンコーダから出力された音声情報を配信装置１０６に送信する処理を説明する。図２６のエンコーダ出力処理２６１０において、コーデック変換制御モジュール７０２がエンコーダからの出力を検出すると、コーデック変換テーブル７０８のエンコーダＩＤ９１３を検索する（ステップ２６１１）。出力元のエンコーダＩＤが見つからなかった場合は出力データを廃棄する（ステップ２６１６）。見つかった場合は、ステップ２６１２に移行する。ステップ２６１２では、エンコーダＩＤ９１３に対応する配信装置ＵＤＰポート９１１を求め、ＲＴＰジッタバッファ１０００の配信装置ＵＤＰポート１００１からＳＳＲＣ１００３を求める。ＳＳＲＣ１００３がＮＵＬＬの場合は、エンコーダからの出力は不要になったと判断し、廃棄する（ステップ２６１６）。ＳＳＲＣ１００３がＮＵＬＬでなかった場合は、ステップ２６１３にて、コーデック変換テーブル７０８のエンコーダＩＤ９１３に対応するコーデック変換装置ＵＤＰポート９１４を求め、ＲＴＰフローテーブル７０７のＵＤＰポート９０３を参照して、エンコード結果を送出すべきＲＴＰフローを特定する。ステップ２６１４でＲＴＰ／ＵＤＰ／ＩＰパケットを生成し、ステップ２６１５でＩＰネットワークに送出する。

以上で、グループ呼設定後、送信権を獲得した移動端末１００ａからの音声パケットがどのように転送され、コーデック変換されるかの説明を終わる。

３−２．開始要求
次に、グループ呼設定および送信権獲得のシグナリング処理において、前述した音声パケット処理に必要な各種テーブルを初期化する手順について、フローチャートを用いて説明する。

（１）配信装置
図２０は、配信装置１０６が、呼制御装置１０５からグループ通信の発呼を受けた場合の配信制御モジュール２０５のフローチャートを示す。ＩＮＶＩＴＥ受信処理２０００は、図１３（ａ）のシーケンスにおいて、配信装置１０６がＩＮＶＩＴＥメッセージ１３０３を受信した場合に行う。

ステップ２００１では、図１７のメッセージ内容に基いて、図５に示す配信テーブル２１１の受信パケット情報５０２に発信端末用のＲＴＰフロー情報を設定する。まず、通話グループ５００に、ＩＮＶＩＴＥメッセージ１３０２のＴｏヘッダ１７０２の内容をコピーする。送信元ＩＰアドレス５０１に、ＩＮＶＩＴＥメッセージ１３０２のＦｒｏｍヘッダ１７０１が示すアドレス（ｍｓ１＠ｎｅｔＡ）のＩＰアドレスを設定する。ｍｓ１＠ｎｅｔＡは、ゲートウエイ１０４ａ上の仮想ＳＩＰ端末であるので、ゲートウエイ１０４ａのアドレスを設定する。送信元ＵＤＰポート５０３には、セッション情報１７０３のＵＤＰポート“１００００”を設定する。宛先ＩＰアドレス５０４には配信装置１０６のＩＰアドレスを設定する。宛先ＵＤＰポート５０５には、配信装置１０６の未使用ＵＤＰポート番号を設定する。さらに、コーデック５０６には、セッション情報１７０３のコーデック“Ａ”を設定する。ＭＳ数５０７には１を設定する。これは、上記ＲＴＰフローはコーデックＡでエンコードされており、また、それを使用するＭＳは１台（＝発信端末）であることを意味している。

ステップ２００２では、図４に示すＲＴＣＰフローテーブル２０９を設定する。通話グループ４００にはＩＮＶＩＴＥメッセージ１３０２のＴｏヘッダ１７０２の内容をコピーする。ＲＴＰ４０１には、ステップ２００１で設定した受信パケット情報を設定する。すなわちＩＰアドレス４０２、ＵＤＰポート４０３、ＩＰアドレス４０４、ＵＤＰポート４０５には、それぞれ送信元ＩＰアドレス５０１、送信元ＵＤＰポート５０３、宛先ＩＰアドレス５０４、宛先ＵＤＰポート５０５を設定する。ＲＴＣＰ４０６には、ＲＴＰ４０１に対する送信権制御用のフロー情報を設定する。すなわち、ＩＰアドレス４０７、ＩＰアドレス４０９には、それぞれＩＰアドレス４０２、ＩＰアドレス４０４の値をコピーする。ＵＤＰポート４０８は、ＩＮＶＩＴＥメッセージ１３０２のセッション情報１７０３が示すＲＴＣＰのＵＤＰポート番号“１００１０”を設定する。ＵＤＰポート番号４１０には、配信装置１０６の未使用ＵＤＰポート番号を設定する。

ステップ２００３では、呼接続装置１０５に対しＳｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ１３０４を送信する。メッセージ中のセッション情報１７１３には、配信装置１０６がＲＴＰフローに割り当てたＵＤＰポート番号として、ＵＤＰポート４０５の値（本例では３０００１）を、ＲＴＣＰフローに割り当てたＵＤＰポート番号として、ＵＤＰポート４１０の値（本例では３００１１）を設定する。

ステップ２００４では、グループメンバを呼び出すためのＩＮＶＩＴＥメッセージ１３２０に、図３に示すコーデックテーブル２０８に登録されている全てのコーデックそれぞれのセッション情報を設定する。このうち、セッション情報１８０３ａは、発信端末も使用するコーデックに関する情報なので、ステップ２００１、ステップ２００２で確保したＵＤＰポート番号（本例では、ＲＴＰフロー用に３０００１、ＲＴＣＰフロー用に３００１１）を設定する。その他のセッション情報１８０３ｂ、１８０３ｃ、１８０３ｄについては、ＲＴＰフロー用とＲＴＣＰフロー用のＵＤＰポート番号を新規に確保して、ＩＮＶＩＴＥメッセージ１３２０に設定する。

ステップ２００５では、同一ゲートウエイ配下に位置するグループメンバの宛先アドレスリスト１８０４をＩＮＶＩＴＥメッセージの最後に追加し、リスト中の先頭のメンバを、Ｔｏヘッダ１８０２にコピーする。本例では、グループ番号０００３のグループメンバは移動端末１００ａ（ｍｓ１＠ｎｅｔＡに対応）、移動端末１００ｂ（ｍｓ２＠ｎｅｔＡに対応）、移動端末１００ｃ（ｍｓ３＠ｎｅｔＡに対応）であり、移動端末１００ｂ、移動端末１００ｃはともにゲートウエイ１０４ｂ配下に位置するので、ゲートウエイ１０４ｂにのみ、グループメンバ宛のＩＮＶＩＴＥメッセージを送信する（ステップ２００６）。

次に呼制御装置１０５から、図１３（ｂ）において、ＩＮＶＩＴＥメッセージ１３２０に対するＯＫ応答１３２８を受信した場合の処理を、ＩＮＶＩＴＥ ＯＫ受信処理２０１０を用いて説明する。ステップ２０１１で、Ｔｏヘッダ１８１２を判定し、送信済みのＩＮＶＩＴＥメッセージ１３２０のＴｏヘッダ１８０２と同じなのでステップ２０１２に移行する。ステップ２０１２では、図５に示す配信テーブル２１１の受信パケット情報５０２に、ＯＫ応答１３２８のセッション情報１８１３ａを設定する。すなわち、送信元ＩＰアドレス５０１に、ＯＫ応答１３２７のＴｏヘッダ１８１２が示すアドレス（ｍｓ２＠ｎｅｔＡ）のＩＰアドレスを設定する。ｍｓ２＠ｎｅｔＡは、ゲートウエイ１０４ｂ上の仮想ＳＩＰ端末であるので、ゲートウエイ１０４ｂのアドレスを設定する。送信元ＵＤＰポート５０３には、セッション情報１８１３ａのＵＤＰポート“４０００１”を設定する。宛先ＩＰアドレス５０４には配信装置１０６のＩＰアドレスを設定する。宛先ＵＤＰポート５０５には、ＩＮＶＩＴＥメッセージ１３２０に設定したコーデックＡに関するセッション情報１８０３ａのＵＤＰポート“３０００１”を設定する。さらに、コーデック５０６には、セッション情報１８１３ａのコーデック“Ａ”を設定する。ＭＳ数５０７の設定には、宛先アドレスリスト１８１４を参照する。ここに、ゲートウエイ１０４ｂに関し、コーデックの種類毎に移動端末が分類されている。コーデックＡに関してはｍｓ３のみであることがわかるので、ＭＳ数５０７に１を設定する。セッション情報１８１３ａに関する設定は以上である。セッション情報１８１３ｂについても同様の手順で配信テーブル２１１の受信パケット情報５０２、コーデック５０６、ＭＳ数５０７を設定する。

ステップ２０１３では、セッション情報１８１３ａ、１８１３ｂに基いて図４に示すＲＴＣＰフローテーブル２０９を設定する。まずセッション情報１８１３ａについて説明する。ＲＴＰ４０１のＩＰアドレス４０２、ＵＤＰポート４０３、ＩＰアドレス４０４、ＵＤＰポート４０５は、上記で設定した配信テーブル２１１の送信元ＩＰアドレス５０１、送信元ＵＤＰポート５０３、宛先ＩＰアドレス５０４、宛先ＵＤＰポート５０５の値をそれぞれ設定する。ＲＴＣＰ４０６のＩＰアドレス４０７、ＩＰアドレス４０９は、それぞれＩＰアドレス４０２、ＩＰアドレス４０４の値をコピーする。ＵＤＰポート４０８は、セッション情報１８１３ａのＲＴＣＰのＵＤＰポート番号（本図では４００１１）を設定する。ＵＤＰポート４１０は、ＩＮＶＩＴＥメッセージ１３２０に設定したコーデックＡに関するセッション情報１８０３ａに設定したＲＴＣＰのＵＤＰ番号（本図では３００１１）を設定する。セッション情報１８１３ａに関する設定は以上である。セッション情報１８１３ｂについても同様の手順でＲＴＣＰフローテーブル２０９を設定する。

ステップ２０１４では、グループ通信で使用するコーデックが複数あるので、コーデック変換装置１０７にＩＮＶＩＴＥメッセージ１３２９を送信する。コーデックの種類ごとに配信装置１０６がコーデック変換装置１０７と送受信するＲＴＰフローのＵＤＰ番号を確保して、ＩＮＶＩＴＥメッセージ１３２９のセッション情報１９０３ａ、１９０３ｂを設定する。
以上が、配信装置１０６が呼制御装置１０５からのＯＫ応答１３２８を受信した場合の処理である。

次に、図１３（ｂ）において、配信装置１０６がコーデック変換装置１０７からのＯＫ応答１３３０を受信した場合の処理をＩＮＶＩＴＥ ＯＫ受信処理２０１０を用いて説明する。ステップ２０１１において、Ｔｏヘッダ１９１２がコーデック変換装置１０７のアドレスであるのでステップ２０１５に移行する。ステップ２０１５では、図５に示す配信テーブル２１１の受信パケット情報５０２に、ＯＫ応答１３３０のセッション情報１９１３ａ、１９１３ｂを設定する。まずセッション情報１９１３ａについて説明する。送信元ＩＰアドレス５０１に、ＯＫ応答１３３０のＴｏヘッダ１９１２が示すアドレス（ｔｒａｎｓｃｏｄｅｒ．ｎｅｔＡ）のＩＰアドレスを設定する。送信元ＵＤＰポート５０３には、セッション情報１９１３ａのＵＤＰポート“４４００１”を設定する。宛先ＩＰアドレス５０４には配信装置１０６のＩＰアドレスを設定する。宛先ＵＤＰポート５０５には、ＩＮＶＩＴＥメッセージ１３２９に設定したコーデックＡに関するセッション情報１９０３ａのＵＤＰポート“３３００１”を設定する。さらに、コーデック５０６には、セッション情報１９１３ａのコーデック“Ａ”を設定する。ＭＳ数５０７には、便宜上常に１を設定する。以上がセッション情報１９１３ａに関する設定である。セッション情報１９１３ｂについても同様の手順で設定する。

ステップ２０１６では、図５の配信テーブル２１１の受信パケット情報５０２に対応して、送信パケット情報５０９を設定する。まず、受信パケット情報５０２が（送信元ＩＰアドレス、送信元ＵＤＰポート、宛先ＩＰアドレス、宛先ＵＤＰポート）＝（ゲートウエイａ、１００００、配信装置、３０００１）について、送信パケット情報５０９を設定する。具体的には、このＲＴＰフローのコーデック５０６は“Ａ”であるので、コーデック５０６がＡである受信パケット情報５０２を全て送信パケット情報５０９にコピーする。本図では、コーデックＡのＲＴＰフローが対象となるので、受信パケット情報５０２が（送信元ＩＰアドレス、送信元ＵＤＰポート、宛先ＩＰアドレス、宛先ＵＤＰポート）＝（ゲートウエイｂ、４０００１、配信装置、３０００１）、（コーデック変換装置、４４００１、配信装置、３３００１）の２つを送信パケット情報５０９に設定する。ここで、自分自身（送信元ＩＰアドレス、送信元ＵＤＰポート、宛先ＩＰアドレス、宛先ＵＤＰポート）＝（ゲートウエイａ、１００００、配信装置、３０００１）については、もし、ゲートウエイａ配下にコーデックＡを使用する端末が複数いた場合は、コーデックＡのＲＴＰフローを送信した端末以外に同じフローを配信する必要があるが、本図ではＭＳ数５０７が１であるので、自分自身を送信パケット情報５０９に設定する必要はない。もし、ＭＳ数５０７が２以上の場合は、（送信元ＩＰアドレス、送信元ＵＤＰポート、宛先ＩＰアドレス、宛先ＵＤＰポート）＝（ゲートウエイａ、１００００、配信装置、３０００１）も送信パケット情報５０９に設定する。以上で、受信パケット情報５０２が（送信元ＩＰアドレス、送信元ＵＤＰポート、宛先ＩＰアドレス、宛先ＵＤＰポート）＝（ゲートウエイａ、１００００、配信装置、３０００１）の場合の送信パケット情報５０９の設定が完了する。同様の手順で、全ての受信パケット情報５０２についての送信パケット情報５０９を設定する。

ステップ２０１７では、図４に示す送信権テーブル２１０を初期化する。通話グループ４２０には、ＩＮＶＩＴＥメッセージ１３０２のＴｏヘッダ１７０２の内容を設定する。送信元ＩＰアドレス４２１、送信元ＵＤＰポート４２２、宛先ＩＰアドレス４２３、宛先ＵＤＰポート４２４、ＳＳＲＣ４２５をＮＵＬＬに設定する。

ステップ２０１８では、シーケンス番号テーブル２１２を初期化する。通話グループ５２０にはＩＮＶＩＴＥメッセージ１３０２のＴｏヘッダ１７０２の内容を設定する。シーケンス番号５２１には、例えば乱数で生成した値を設定する。

ステップ２０１９では、ＩＮＶＩＴＥメッセージ１３０３に対応したＯＫ応答１３３１を呼制御装置１０５に送信する。以上が、配信装置１０６がコーデック変換装置１０７からのＯＫ応答１３３０を受信した場合の処理である。

（２）コーデック変換装置
図２１は、コーデック変換装置の呼設定処理フローを示す図である。
次に、図１３（ｂ）において、コーデック変換装置１０７が配信装置１０６からＩＮＶＩＴＥメッセージ１３２９を受信した場合のコーデック変換制御モジュール７０２の処理を図２１を用いて説明する。

ステップ２１０１では、ＩＮＶＩＴＥメッセージ１３２９（図１３（ｂ）参照）に含まれるセッション情報１９０３ａ、１９０３ｂに基いて図９に示すＲＴＰフローテーブル７０７を設定する。通話グループ９００には、ＩＮＶＩＴＥメッセージ１３２９のＦｒｏｍヘッダ１９０１の内容を設定する。次にセッション情報毎の設定として、セッション情報１９０３ａに関する情報を設定する。ＩＰアドレス９０５には配信装置１０６のＩＰアドレスを、ＵＤＰポート９０６にはセッション情報１９０３ａのＵＤＰポートの番号（本例では３３００１）を、コーデック９０７にはセッション情報１９０３ａのコーデック（本例ではＡ）を設定する。ＩＰアドレス９０１にはコーデック変換装置１０７のＩＰアドレスを、ＵＤＰポート９０３には、コーデック変換装置１０７で空いているＵＤＰポート番号を設定する（本例では４４００１）。以上でセッション情報１９０３ａの設定が終わる。セッション情報１９０３ｂについても同様の手順で設定する。

ステップ２１０２では、必要なコーデック回路を全て確保可能か判定する。図９に示すＲＴＰフローテーブル７０７のコーデック９０７にある全てのコーデック（本例ではＡとＢ）が対象である。まず、コーデックＡに関し、図８に示すコーデックリソース管理テーブル７０５のコーデック種別８００でコーデックＡを検索し、コーデックＡのエンコーダ、デコーダそれぞれについて使用量８０５がリソース量８０３に達していないか調べる。一方でも達していた場合は、コーデック変換に必要な空きリソースがないことになり、ステップ２１１０に移行する。ステップ２１１０では、ＲＴＰフローテーブル７０７を解放し、ＩＮＶＩＴＥメッセージ１３２９に対しＮＧの応答を配信装置１０６に送信する。ステップ２１０２では、コーデックＢについても同様に調べ、Ａ、Ｂともに、エンコーダ、デコーダに空きがあった場合のみステップ２１０３に移行する。２１０３では、コーデックＡ、Ｂそれぞれについて、使用量８０５のエンコーダ８０６及びデコーダ８０７をインクリメントする。ステップ２１０４では、コーデック使用中マップ７０６を検索し、コーデックＡのデコーダ、エンコーダ、コーデックＢのデコーダ、エンコーダで空いている回路をひとつずつ選択し、使用中ビットを立てる。ステップ２１０５では、図９に示すコーデック変換テーブル７０８に、確保したデコーダを登録する。通話グループ９１０には、図９に示すＲＴＰフローテーブル７０７の通話グループ９００をコピーする。配信装置ＵＤＰポート９１１にはＲＴＰフローテーブル７０７のＵＤＰポート９０６をコピーする。本例では、ＵＤＰポート９０６は、３３００１と３３００２である。ＵＤＰポート３３００１はコーデックＡのＲＴＰフローなので、コーデックＡのデコーダをデコーダＩＤ９１２に設定する（本例ではＡ００１）。同様に、ＵＤＰポート３３００２はコーデックＢのＲＴＰフローなので、コーデックＢのデコーダをデコーダＩＤ９１２に設定する（本例ではＢ００３）。ステップ２１０６ではエンコーダＩＤ９１３を設定する。まず配信装置ＵＤＰポート９１１が３３００１のＲＴＰフローについての設定を説明する。ＲＴＰフローテーブル７０７のＵＤＰポート９０６が３３００１のＲＴＰフローは、コーデック９０７がＡである。そのため、コーデック変換装置１０７は同じ通話グループ９００の中で、コーデックがＡ以外のコーデックに、音声情報を変換してやる必要がある。本例では、コーデックＡ以外にはＢしかないことがコーデック９０７を参照するとわかる。そこで、エンコーダＩＤ９１３には、ステップ２１０４で確保したコーデックＢのエンコーダの識別子を設定する。かりに、同一のグループでコーデックＡ、コーデックＢ、コーデックＣを使用していた場合は、コーデックＡのフローである３３００１に対し、コーデックＢのエンコーダとコーデックＣのエンコーダの２つをエンコーダＩＤ９１３に設定することになる。
配信装置ＵＤＰポート９１１が３３００２のＲＴＰフローについても、同様の手順で、コーデックＡのエンコーダを設定する。

ステップ２１０７では、ステップ２１０６で設定した個々のエンコーダＩＤ９１３について、コーデックの種類に対応したコーデック変換装置１０７のＵＤＰポート番号を設定する。例えば、エンコーダＩＤ９１３がＢ１０３のフローについては、Ｂ１０３がコーデックＢであるので、ＲＴＰフローテーブル７０７のコーデック９０７がＢのＲＴＰフローを検索し、コーデック変換装置９０２のＵＤＰポート９０３をコーデック変換装置ＵＤＰポート９１４に設定する。同様に、エンコーダＩＤ９１３に登録した個々のエンコーダについて、エンコード結果を送出すべきＲＴＰフローのＵＤＰ番号を全て登録する。

ステップ２１０８では、図１０に示すＲＴＰジッタバッファ７０９を初期化する。通話グループ１０００、配信装置ＵＤＰポート１００１は、図９に示すコーデック変換テーブル７０８の通話グループ９１０、配信装置ＵＤＰポート９１１をコピーする。受信シーケンス番号１００２、ＳＳＲＣ１００３、次回入力時刻１００４、次回入力タイムスタンプ１００５、先頭ポインタ１００６、末尾ポインタ１００７はＮＵＬＬに設定する。

ステップ２１０９では、図１０に示すデコードデータジッタバッファ７１０を初期化する。エンコーダＩＤ１０１０は、図９に示すコーデック変換テーブル７０８のエンコーダＩＤ９１３に登録されている全てのエンコーダについて、ここでは重複なく設定する。次回入力時刻１０１１、先頭ポインタ１０１２、末尾ポインタ１０１３はＮＵＬＬに設定する。

ステップ２１１２では、ＩＮＶＩＴＥメッセージ１３２９に対するＯＫ応答１３３０を送信する。セッション情報１９１３ａ、１９１３ｂには、コーデックの種類ごとにＲＴＰフローテーブル７０７のＵＤＰポート９０３と、コーデックリソース管理テーブル７０５のＲＴＰクロックレート８０１を設定する。
以上が、コーデック変換装置１０７が配信装置１０６からＩＮＶＩＴＥメッセージ１３２９を受信した場合の処理である。

３−３．送信権要求
図２２は、配信装置の送信権制御フローを示す図である。
最後に、図１５に示されるように、グループ呼設定完了後、配信装置１０６がゲートウエイ１０４ａからＴａｌｋ Ｂｕｒｓｔ Ｒｅｑｕｅｓｔメッセージ１５０２を受信した場合の処理を図２２を用いて説明する。

まず、ステップ２２０１にて、受信したＴａｌｋ Ｂｕｒｓｔ Ｒｅｑｕｅｓｔメッセージ１５０２の送信元ＩＰアドレス、送信元ＵＤＰポート番号、宛先ＩＰアドレス、宛先ＵＤＰポート番号の組が、図４に示すＲＴＣＰフローテーブル２０９のＲＴＣＰ４０６に登録されているか調べる。未登録の場合は処理を終了する。登録済みの場合は、ステップ２２０２で、図４に示す送信権テーブル２１０のＳＳＲＣ４２５がＮＵＬＬか判定する。ＮＵＬＬでなければ移動端末のどれかが送信権を持っている状態であるので、承認不可メッセージを要求元に送信する（ステップ２２０３）。送信権テーブル２１０のＳＳＲＣ４２５がＮＵＬＬであれば、まだ誰も送信権を要求していないということなので、ステップ２２０４に移行する。ステップ２２０４では、ＲＴＣＰフローテーブル２０９のＲＴＣＰ４０６がＴａｌｋ Ｂｕｒｓｔ Ｒｅｑｕｅｓｔメッセージ１５０２に一致するフローの、ＲＴＰ４０１を送信権テーブル２１０にコピーする。つまり、ＩＰアドレス４０２、ＵＤＰポート４０３、ＩＰアドレス４０４、ＵＤＰポート４０５を送信元ＩＰアドレス４２１、送信元ＵＤＰポート４２２、宛先ＩＰアドレス４２３、宛先ＵＤＰポート４２４にそれぞれコピーする。さらに受信したＴａｌｋ Ｂｕｒｓｔ Ｒｅｑｕｅｓｔメッセージ１５０２に含まれるＳＳＲＣをＳＳＲＣ４２５に設定する。

ステップ２２０５では、Ｔａｌｋ Ｂｕｒｓｔ Ｔａｋｅｎメッセージ１５０４を送信権要求元以外に送信し、ステップ２２０６ではＴａｌｋ Ｂｕｒｓｔ Ｇｒａｎｔｅｄメッセージ１５０７を送信権要求元に送信する。以上が、配信装置１０６がゲートウエイ１０４ａからＴａｌｋ Ｂｕｒｓｔ Ｒｅｑｕｅｓｔメッセージ１５０２を受信した場合の処理である。

このようにして、シグナリング時のメッセージ処理において、各種テーブルの設定を行うことで、端末が音声情報を送信したとき、適切にコーデック変換することが可能になる。

本発明は、移動端末に限らず、様々な無線端末に適用することができる。また、コーデック変換装置について説明したが、これに限らず、プロトコル変換装置やメディア変換装置等の各種変換装置に適用することができる。

自営無線システムのネットワーク構成を示す図である。 配信装置の構成を示す図である。 コーデックテーブルの図である。 ＲＴＣＰフローテーブルと送信権テーブルの図である。 配信テーブルとシーケンス番号テーブルの図である。 コーデック変換装置のハード構成を示す図である。 コーデック変換装置のメモリ内の構成を示す図である。 コーデックリソース管理テーブルとコーデック使用中マップの図である。 ＲＴＰフローテーブルとコーデック変換テーブルの図である。 ＲＴＰジッタバッファとデコードデータジッタバッファの図である。 呼制御装置が有する端末コーデックテーブルの図である。 位置登録のシーケンス図である。 グループ通信の呼接続の前半のシーケンス図である。 グループ通信の呼接続の後半のシーケンス図である。 グループ通信の呼解放のシーケンス図である。 送信権獲得のシーケンス図である。 送信権解放のシーケンス図である。 ゲートウエイと配信装置が送受信する発信メッセージと応答メッセージのフォーマットを示す図である。 配信装置とゲートウエイが送受信する着信メッセージと応答メッセージのフォーマットを示す図である。 配信装置とコーデック変換装置が送受信する呼接続メッセージのフォーマットを示す図である。 配信装置の呼設定処理フローを示す図である。 コーデック変換装置の呼設定処理フローを示す図である。 配信装置の送信権制御フローを示す図である。 配信装置の音声パケットの転送処理フローを示す図である。 コーデック変換装置の音声パケット受信処理フローを示す図である。 コーデック変換装置のデコード処理フローを示す図である。 コーデック変換装置のエンコード処理フローを示す図である。 コーデック変換装置が配信装置から受信する音声パケットのフォーマットとジッタバッファでのキュー構成を示す図である。

符号の説明

１００ａ、ｂ、ｃ 移動端末
１０１ａ、ｂ 基地局
１０４ａ、ｂ ゲートウエイ
１０６ 配信装置
１０７ コーデック変換装置
２０５ 配信制御モジュール
２０８ コーデックテーブル
２０９ ＲＴＣＰフローテーブル
２１０ 送信権テーブル
２１１ 配信テーブル
２１２ シーケンス番号テーブル
４２５ ＳＳＲＣ
５２１ シーケンス番号
６０３ デコード回路
６０４ エンコード回路
７０２ コーデック変換制御モジュール
７０５ コーデックリソース管理テーブル
７０６ コーデック使用中マップ
７０７ ＲＴＰフローテーブル
７０８ コーデック変換テーブル
７０９ ＲＴＰジッタバッファ
７１０ デコードデータジッタバッファ
１００２ 受信シーケンス番号
１００３ ＳＳＲＣ
１３２７ 着信ＩＮＶＩＴＥメッセージに対するＯＫ応答
１３２９ コーデック変換設定ＩＮＶＩＴＥメッセージ
１３３０ コーデック変換設定ＩＮＶＩＴＥメッセージに対するＯＫ応答
１８１４ 宛先アドレスリスト
２７０３ シーケンス番号

Claims (17)

1. 送信権を要求した無線端末である送信端末が送信した音声情報を、配信装置がコーデック変換装置を介して又は介さないで、ゲートウエイ及び基地局を経て他の複数の無線端末に配信することで、複数の無線端末による半２重多対多の通話を実現する通信システムにおける配信装置であって、
   前記配信装置は、
   パケットを受信すると、グループ呼の識別子である通話グループ識別情報と、通話グループの呼で受信しうるパケットのソケット情報を示す受信パケット情報と、符号化方式と、現在送信権を取得している無線端末の音声情報を運ぶパケットのソケット情報を示す送信パケット情報とを対応づけて記憶した配信テーブルを検索し、受信したパケットのソケット情報と一致するエントリが前記受信パケット情報に存在するかチェックし、
   エントリが存在する場合、前記受信パケットの送信元アドレスがゲートウエイのアドレスか、コーデック変換装置のアドレスかを判定し、
   前記受信パケットがゲートウエイからのパケットである場合、通話グループ識別情報に対して、パケットのソケット情報と、現在送信権を取得している無線端末を識別するための送信権要求識別子とを対応つけて記憶した送信権テーブルを参照し、
   前記受信パケットのソケット情報および前記受信パケットに含まれる送信権要求識別子が、前記送信権テーブルのエントリと一致する場合は、前記受信パケットは他のグループメンバに配信すべきパケットであると判断し、
   前記配信テーブルを参照し、前記受信パケットの前記受信パケット情報に対応して登録されている送信パケット情報に従い、また、前記送信パケット情報のソケット情報が複数の場合は前記受信パケットを複製して、該当するゲートウエイ宛及び／又は前記コーデック変換装置宛の送信パケットを生成し、
   さらに、生成した送信パケットが前記コーデック変換装置宛の場合には、通話グループ識別情報に対応して、コーデック変換装置に転送する場合にパケットに付加するシーケンス番号を記憶したシーケンス番号テーブルを参照し、前記シーケンス番号を前記送信パケットに挿入し、前記シーケンス番号テーブルのシーケンス番号をインクリメントし、
   完成した送信パケットを送信する
   前記配信装置。
2. 請求項１に記載の配信装置において、
   前記受信パケットの送信元アドレスがゲートウエイのアドレスか、コーデック変換装置のアドレスかを判定した結果、前記受信パケットの送信元アドレスがコーデック変換装置である場合、
   前記配信テーブルを参照し、受信パケット情報に対応して登録されている送信パケット情報に従い、パケットを生成し、該当するゲートウエイへパケットを送信するようにした配信装置。
3. 請求項１に記載の配信装置であって、
   前記コーデック変換装置が有する符号化変換手段の全ての符号化方式を、無線端末への着信メッセージに記述することを特徴とする配信装置。
4. 送信権を要求した無線端末である送信端末が送信した音声情報を、配信装置がコーデック変換装置を介して又は介さないで、ゲートウエイ及び基地局を経て他の複数の無線端末に配信することで、複数の無線端末による半２重多対多の通話を実現する通信システムにおけるコーデック変換装置であって、
   前記コーデック変換装置は、
   前記配信装置から受信したパケットに基づき、通話グループ識別情報に対して、配信装置のポート番号と、受信シーケンス番号と、現時点で送信権を有していると予想される無線端末を識別するための送信権要求識別子とを記憶したジッタバッファを参照し、
   
   （ａ）前記ジッタバッファの配信装置のポート番号及び送信権要求識別子と、受信パケットの配信装置のポート番号及び送信権要求識別子が一致しなかった場合は、
   ｉ) 前記ジッタバッファの受信シーケンス番号の方が前記受信パケットのシーケンス番号よりも新しい場合、送信権を獲得した無線端末が切り替わった後、切替前の古いパケットが到着したものと判定して、パケットを廃棄し、
   一方、
   ｉｉ） 前記ジッタバッファの受信シーケンス番号が０又は空白の場合、グループ呼設定後初めてのパケットであると判断し、または、前記受信パケットのシーケンス番号の方が前記ジッタバッファの受信シーケンス番号と比べ新しい場合、前記受信パケットは送信権を獲得した無線端末が切り替わった最初のパケットと判定して、前記受信パケットのシーケンス番号の値を前記ジッタバッファの受信シーケンス番号にコピーし、前記受信パケットの送信権要求識別子を前記ジッタバッファの送信権要求識別子にコピーすることで前記ジッタバッファのバッファを新しく構築し、
   
   （ｂ） 前記ジッタバッファの配信装置のポート番号及び送信権要求識別子と、前記受信パケットの配信装置のポート番号及び送信権要求識別子が一致した場合は、前記受信パケットのシーケンス番号と前記ジッタバッファの受信シーケンス番号を比較し、前記受信パケットのシーケンス番号の方が大きければ、その値を前記ジッタバッファの受信シーケンス番号に設定し、前記受信パケットを、符号化変換手段への入力バッファの入力待ちキューに、キューの先頭からタイムスタンプが小さい順に並ぶように挿入し、前記符号化変換手段により、第１の符号化方式から第２の符号化方式に前記受信パケットを変換する
   前記コーデック変換装置。
5. 請求項４に記載のコーデック変換装置において、
   前記配信装置からパケットを受信すると、通話グループ識別情報に対して、前記コーデック変換装置の使用するアドレスとポート番号と、前記配信装置の使用するアドレスと、符号化方式とが記憶されたフローテーブルを検索し、
   前記配信装置から受信した第１の符号化方式のパケットのポート番号のエントリが前記フローテーブルにあるか否か判断し、エントリが前記フローテーブルにない場合、前記受信パケットを廃棄すること
   を特徴とするコーデック変換装置。
6. 請求項４に記載のコーデック変換装置において、
   通話グループ識別情報に対して、配信装置ポート番号、前記配信装置ＵＤＰポート番号が示す配信装置の受信フローを入力すべきデコーダを示すデコーダＩＤ、前記デコーダＩＤが示すデコーダが出力した音声情報を入力すべきエンコーダを示すエンコーダＩＤ、前記エンコーダＩＤが示すエンコーダが出力した音声情報を送出すべきフローを示すコーデック変換装置ポート番号を記憶したにコーデック変換テーブルを参照して、前記通話グループ識別情報及び配信装置ポート番号に基づき、前記入力バッファからの前記受信パケットを前記デコーダＩＤのデコーダでデコードし、さらに前記エンコーダＩＤのエンコーダでエンコードして、送信パケットを生成し、ネットワークに送出すること
   を特徴とするコーデック変換装置。
7. 請求項４に記載のコーデック変換装置であって、
   送信権を承認された前記無線端末が他の無線端末に切り替わった場合は、切替前の前記無線端末の音声情報を廃棄することを特徴とするコーデック変換装置。
8. 請求項４に記載のコーデック変換装置であって、
   音声情報を前記符号化変換手段で変換した後、現時点で選択した送信端末の音声情報の符号化方式を識別し、
   前記符号化方式が前記符号化変換手段の符号化方式と異なる場合は、変換済みの音声情報を廃棄することを特徴とするコーデック変換装置。
9. 請求項４に記載のコーデック変換装置であって、
   無線端末からの音声情報が受信できず、以後、前記符号化変換手段に入力する音声情報がない場合に、前記符号化変換手段にダミーデータを入力することを特徴とする、コーデック変換装置。
10. 送信権を要求した無線端末である送信端末が送信した音声情報を、配信装置がコーデック変換装置を介して又は介さないで、ゲートウエイ及び基地局を経て他の複数の無線端末に配信することで、複数の無線端末による半２重多対多の通話を実現する通信システムであって、
    
    前記配信装置は、
    パケットを受信すると、グループ呼の識別子である通話グループ識別情報と、通話グループの呼で受信しうるパケットのソケット情報を示す受信パケット情報と、符号化方式と、現在送信権を取得している無線端末の音声情報を運ぶパケットのソケット情報を示す送信パケット情報とを対応づけて記憶した配信テーブルを検索し、受信したパケットのソケット情報と一致するエントリが前記受信パケット情報に存在するかチェックし、
    エントリが存在する場合、前記受信パケットの送信元アドレスがゲートウエイのアドレスか、コーデック変換装置のアドレスかを判定し、
    前記受信パケットがゲートウエイからのパケットである場合、通話グループ識別情報に対して、パケットのソケット情報と、現在送信権を取得している無線端末を識別するための送信権要求識別子とを対応つけて記憶した送信権テーブルを参照し、
    前記受信パケットのソケット情報および前記受信パケットに含まれる送信権要求識別子が、前記送信権テーブルのエントリと一致する場合は、前記受信パケットは他のグループメンバに配信すべきパケットであると判断し、
    前記配信テーブルを参照し、前記受信パケットの前記受信パケット情報に対応して登録されている送信パケット情報に従い、また、前記送信パケット情報のソケット情報が複数の場合は前記受信パケットを複製して、該当するゲートウエイ宛及び／又は前記コーデック変換装置宛の送信パケットを生成し、
    さらに、生成した送信パケットが前記コーデック変換装置宛の場合には、通話グループ識別情報に対応して、コーデック変換装置に転送する場合にパケットに付加するシーケンス番号を記憶したシーケンス番号テーブルを参照し、前記シーケンス番号を前記送信パケットに挿入し、前記シーケンス番号テーブルのシーケンス番号をインクリメントし、
    完成した送信パケットを送信し、
    
    及び、
    
    前記コーデック変換装置は、
    前記配信装置から受信したパケットに基づき、通話グループ識別情報に対して、配信装置のポート番号と、受信シーケンス番号と、現時点で送信権を有していると予想される無線端末を識別するための送信権要求識別子とを記憶したジッタバッファを参照し、
    
    （ａ）前記ジッタバッファの配信装置のポート番号及び送信権要求識別子と、受信パケットの配信装置のポート番号及び送信権要求識別子が一致しなかった場合は、
    ｉ) 前記ジッタバッファの受信シーケンス番号の方が前記受信パケットのシーケンス番号よりも新しい場合、送信権を獲得した無線端末が切り替わった後、切替前の古いパケットが到着したものと判定して、パケットを廃棄し、
    一方、
    ｉｉ） 前記ジッタバッファの受信シーケンス番号が０又は空白の場合、グループ呼設定後初めてのパケットであると判断し、または、前記受信パケットのシーケンス番号の方が前記ジッタバッファの受信シーケンス番号と比べ新しい場合、前記受信パケットは送信権を獲得した無線端末が切り替わった最初のパケットと判定して、前記受信パケットのシーケンス番号の値を前記ジッタバッファの受信シーケンス番号にコピーし、前記受信パケットの送信権要求識別子を前記ジッタバッファの送信権要求識別子にコピーすることで前記ジッタバッファのバッファを新しく構築し、
    
    （ｂ） 前記ジッタバッファの配信装置のポート番号及び送信権要求識別子と、前記受信パケットの配信装置のポート番号及び送信権要求識別子が一致した場合は、前記受信パケットのシーケンス番号と前記ジッタバッファの受信シーケンス番号を比較し、前記受信パケットのシーケンス番号の方が大きければ、その値を前記ジッタバッファの受信シーケンス番号に設定し、前記受信パケットを、符号化変換手段への入力バッファの入力待ちキューに、キューの先頭からタイムスタンプが小さい順に並ぶように挿入し、前記符号化変換手段により、第１の符号化方式から第２の符号化方式に前記受信パケットを変換する
    前記通信システム。
11. 請求項１０に記載の通信システムにおいて、
    前記配信装置は、
    前記受信パケットの送信元アドレスがゲートウエイのアドレスか、コーデック変換装置のアドレスかを判定した結果、前記受信パケットの送信元アドレスがコーデック変換装置である場合、
    前記配信テーブルを参照し、受信パケット情報に対応して登録されている送信パケット情報に従い、パケットを生成し、該当するゲートウエイへパケットを送信するようにした通信システム。
12. 請求項１０に記載の通信システムであって、
    前記配信装置は、
    前記コーデック変換装置が有する符号化変換手段の全ての符号化方式を、無線端末への着信メッセージに記述することを特徴とする通信システム。
13. 請求項１０に記載の通信システムにおいて、
    前記コーデック変換装置は、
    前記配信装置からパケットを受信すると、通話グループ識別情報に対して、前記コーデック変換装置の使用するアドレスとポート番号と、前記配信装置の使用するアドレスと、符号化方式とが記憶されたフローテーブルを検索し、
    前記配信装置から受信した第１の符号化方式のパケットのポート番号のエントリが前記フローテーブルにあるか否か判断し、エントリが前記フローテーブルにない場合、前記受信パケットを廃棄すること
    を特徴とする通信システム。
14. 請求項１０に記載の通信システムにおいて、
    前記コーデック変換装置は、
    通話グループ識別情報に対して、配信装置ポート番号、前記配信装置ＵＤＰポート番号が示す配信装置の受信フローを入力すべきデコーダを示すデコーダＩＤ、前記デコーダＩＤが示すデコーダが出力した音声情報を入力すべきエンコーダを示すエンコーダＩＤ、前記エンコーダＩＤが示すエンコーダが出力した音声情報を送出すべきフローを示すコーデック変換装置ポート番号を記憶したにコーデック変換テーブルを参照して、前記通話グループ識別情報及び配信装置ポート番号に基づき、前記入力バッファからの前記受信パケットを前記デコーダＩＤのデコーダでデコードし、さらに前記エンコーダＩＤのエンコーダでエンコードして、送信パケットを生成し、ネットワークに送出すること
    を特徴とする通信システム。
15. 請求項１０に記載の通信システムであって、
    前記コーデック変換装置は、
    送信権を承認された前記無線端末が他の無線端末に切り替わった場合は、切替前の前記無線端末の音声情報を廃棄することを特徴とする通信システム。
16. 請求項１０に記載の通信システムであって、
    前記コーデック変換装置は、
    音声情報を前記符号化変換手段で変換した後、現時点で選択した送信端末の音声情報の符号化方式を識別し、
    前記符号化方式が前記符号化変換手段の符号化方式と異なる場合は、変換済みの音声情報を廃棄することを特徴とする通信システム。
17. 請求項１０に記載の通信システムであって、
    前記コーデック変換装置は、
    無線端末からの音声情報が受信できず、以後、前記符号化変換手段に入力する音声情報がない場合に、前記符号化変換手段にダミーデータを入力することを特徴とする通信システム。

Images