(57)【特許請求の範囲】
【請求項１】
SDPオファーまたはSDPアンサーを含むIMSシグナリングを用いて、相手端末との通信に利用するコーデックを通信開始時に折衝するコーデック折衝部と、
前記折衝されたコーデックは複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を１つのセッションの中で変更可能なコーデックであって、
ネットワークノードから通知される、前記コーデックの入力信号の帯域幅の制限を指示するシグナリングに基づいて、前記相手端末との通信中に、前記コーデックの入力信号の帯域幅を制限する帯域幅決定部と、
を備える通信端末装置。
【請求項２】
通信開始時の折衝の際、前記折衝されるコーデックに対して入力信号の帯域幅(band width)が指定されない、
請求項１に記載の通信端末装置。
【請求項３】
前記コーデックの入力信号の帯域幅を制限するシグナリングは、RTCP（Real-time Transport Control Protocol）に含まれる、
請求項１に記載の通信端末装置。
【請求項４】
前記コーデックの入力信号の帯域幅を制限するシグナリングは、RTPペイロード（Real-time Transport Protocol）のヘッダに含まれる、
請求項１に記載の通信端末装置。
【請求項５】
SDPオファーまたはSDPアンサーを含むIMSシグナリングを用いて、相手端末との通信に利用するコーデックを通信開始時に折衝し、
前記折衝されたコーデックは複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を１つのセッションの中で変更可能なコーデックであって、
ネットワークノードから通知される、前記コーデックの入力信号の帯域幅の制限を指示するシグナリングに基づいて、前記相手端末との通信中に、前記コーデックの入力信号の帯域幅を制限する、
通信方法。
【請求項６】
通信開始時の折衝の際、前記折衝されるコーデックに対して入力信号の帯域幅(band width)が指定されない、
請求項５に記載の通信方法。
【請求項７】
前記コーデックの入力信号の帯域幅を制限するシグナリングは、RTCP（Real-time Transport Control Protocol）に含まれる、
請求項５に記載の通信方法。
【請求項８】
前記コーデックの入力信号の帯域幅を制限するシグナリングは、RTPペイロード（Real-time Transport Protocol）のヘッダに含まれる、
請求項５に記載の通信方法。
【請求項９】
異なるコーデックを使用する第１の通信端末装置と第２の通信端末装置との間の通信に対してトランスコーディングを行うネットワークノードであって、
前記第１の通信端末装置と前記第２の通信端末装置がそれぞれ使用するコーデックを検出する検出部と、
前記検出された前記第１の通信端末装置で使用される第１のコーデックは、複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を１つのセッションの中で変更可能なコーデックであって、
前記検出部での検出結果に基づいて、前記第２の通信端末装置が使用するコーデックの変更を検出した場合、前記第１の通信端末装置の前記第１のコーデック、及び、前記第２の通信端末装置の変更後の第２のコーデックを用いて、前記第１のコーデックの帯域幅の制限を行うか否かを判断する判断部と、
前記２つの端末の通信中に、前記第１のコーデックの帯域幅を制限すると判断した場合、前記帯域幅を制限させるためのシグナリングを、前記第１の通信端末装置へ送信する送信部と、
を備えるネットワークノード。
【請求項１０】
異なるコーデックを使用する第１の通信端末装置と第２の通信端末装置との間の通信に対してトランスコーディングを行うネットワークノードの通信方法であって、
前記第１の通信端末装置と前記第２の通信端末装置がそれぞれ使用するコーデックを検出し、
前記検出された前記第１の通信端末装置で使用される第１のコーデックは、複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を１つのセッションの中で変更可能なコーデックであり、
前記検出結果に基づいて、前記第２の通信端末装置が使用するコーデックの変更を検出した場合、前記第１の通信端末装置の前記第１のコーデック、及び、前記第２の通信端末装置の変更後の第２のコーデックを用いて、前記第１のコーデックの帯域幅の制限を行うか否かを判断し、
前記２つの端末の通信中に、前記第１のコーデックの帯域幅を制限すると判断した場合、前記帯域幅を制限させるためのシグナリングを、前記第１の通信端末装置へ送信する、
通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信方式で用いられるコーデック変更を行う通信端末装置、ネットワークノード及び通信方法に関する。
【背景技術】
【０００２】
従来、３ＧＰＰ（Third Generation Partnership Project）の移動通信方式における音声通話は、３ＧＰＰの回線交換（ＣＳ：Circuit Switching）網を用いて行われていた。近年では、３ＧＰＰのパケット交換（ＰＳ：Packet Switching）網を用いた音声通話であるＶｏＬＴＥ（Voice over Long Term Evolution）サービスが行われつつある。【０００３】
しかし、ＶｏＬＴＥサービスが受けられるエリアは当面の間限られる。このため、ＶｏＬＴＥによる音声通話（以下、ＶｏＬＴＥ通話という）中にＶｏＬＴＥサービスエリアの外に出た場合、従来の回線交換方式を用いた通話に切り替える必要がある。この切替を可能にする技術として、非特許文献１に記載のＳＲＶＣＣ（Single Radio Voice Call Continuity）がある。以下、図１及び図２を用いて、ＳＲＶＣＣによるハンドオーバの動作について説明する。【０００４】
図１は３ＧＰＰの移動通信ネットワーク構成の一部を示す。図１に示す移動通信ネットワークは、ｅ−ＵＴＲＡＮ（evolved Universal Terrestrial Radio Access Network）、ｅ−ＵＴＲＡＮの基地局（ｅ−ｎｏｄｅＢ）、ＰＳ網、ＣＳ網、ＣＳ網の基地局サブシステム、及びＩＭＳ（IP Multimedia Subsystem）から構成される。【０００５】
具体的には、図１において、ｅ−ＵＴＲＡＮは、ＶｏＬＴＥサービスを提供可能な無線アクセス網である。ＰＳ網は、ＶｏＬＴＥサービスを提供し、Ｐ−ＧＷ（Packet Data Network Gateway）、Ｓ−ＧＷ（Serving Gateway）及びＭＭＥ（Mobility Management Entity）から構成される。ＣＳ網は、ＭＳＣ（Mobile Switching Center）、ＭＧＷ（Media Gateway）から構成される。ＣＳ網の基地局サブシステムは、ＲＮＣ（Radio Network Controller）及びｎｏｄｅＢから構成される。ＩＭＳは、呼制御等を行い、ＣＳＣＦ（Call Session Control Function）及びＳＣＣ  ＡＳ（Service Centralization and Continuity Application Server）から構成される。【０００６】
図１において、移動通信端末（ＵＥ：User Equipment）であるＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。つまり、ＵＥ１００とＵＥ１０２とでＶｏＬＴＥ通話が行われているとする。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。【０００７】
図１の実線で示されたＰａｔｈ  Ａ、Ｐａｔｈ  Ｂ及びＰａｔｈ  Ｃは、通話データが通る経路を示す。また、図１の破線で示された２００、２０２、２０４及び２０６は、ＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。【０００８】
図２は、ＳＲＶＣＣハンドオーバ処理の動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ−ＵＴＲＡＮ）にそれぞれ接続されており、ＵＥ１００とＵＥ１０２との間の通話データはＰａｔｈ  Ａを通って送受信されている。ＵＥ１００がｅ−ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ−ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図１に示すシグナリング２００。図２に示すステップ（以下、「ＳＴ」という）２００）。ＳＴ２００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷとの間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ−ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令が出される。【０００９】
ＳＴ２００の処理と同時に、ＭＳＣ／ＭＧＷは、ＣＳＣＦ／ＳＣＣ  ＡＳ経由でＵＥ１０２とシグナリングをやり取りする（図１に示すシグナリング２０２。図２に示すＳＴ２０２）。これにより、ＵＥ１０２の通話データの送受信先を、ＵＥ１００からＭＳＣ／ＭＧＷに切り替えるよう命令が出され、Ｐａｔｈ  Ｂが確立される。【００１０】
ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷとシグナリングをやり取りする（図１に示すシグナリング２０４。図２に示すＳＴ２０４）。これにより、Ｐａｔｈ  Ｃが確立される。【００１１】
Ｐａｔｈ  Ｃ確立後、ＭＳＣ／ＭＧＷは、ＭＭＥ経由でＰ−ＧＷ／Ｓ−ＧＷとシグナリングをやり取りする（図１に示すシグナリング２０６。図２に示すＳＴ２０６）。これにより、Ｐａｔｈ  Ａは削除される。【００１２】
以上、ＳＲＶＣＣハンドオーバの動作について説明した。【００１３】
また、ＳＲＶＣＣを改良し、データ経路切替にかかる時間を短縮する方式として、非特許文献３に記載の、ＡＴＣＦ（Access Transfer Control Function）エンハンスメントを用いたＳＲＶＣＣ方式（ｅＳＲＶＣＣ：enhanced-SRVCC）がある。このｅＳＲＶＣＣの動作の一例について、以下、図３及び図４を用いて説明する。【００１４】
図３は、ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワーク構成の一部を示す。図３に示す移動通信ネットワークは、図１と同様、ｅ−ＵＴＲＡＮ、ｅ−ｎｏｄｅＢ、ＰＳ網、ＣＳ網、ＣＳ網の基地局サブシステム、及びＩＭＳから構成される。ここでＩＭＳには、ＣＳＣＦ及びＳＣＣ  ＡＳの他、ＡＴＣＦ（Access Transfer Control Function）及びＡＴＧＷ（Access Transfer GateWay）が存在する。なお、図３及び図４では、ＡＴＣＦとＡＴＧＷとを一つのノード（ＡＴＣＦ／ＡＴＧＷ１１２０）として表しているが、これらは別々のノードとして表してもよい。【００１５】
図３において、ＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。つまり、ＵＥ１００とＵＥ１０２とでＶｏＬＴＥ通話が行われているとする。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。【００１６】
図３の実線で示されたＰａｔｈ  Ａ、Ｐａｔｈ  Ｂ、Ｐａｔｈ  Ｃ及びＰａｔｈ  Ｄは、通話データが通る経路を示す。また、図３の破線で示された１１００、１１０２、１１０４及び１１０６は、ｅＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。【００１７】
図４は、ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ−ＵＴＲＡＮ）にそれぞれ接続されている。ｅＳＲＶＣＣハンドオーバを実現するシステムでは、ＡＴＣＦ／ＡＴＧＷ１１２０において、ＡＴＣＦはＩＭＳのシグナリング（ＩＭＳシグナリング）をアンカーし、ＡＴＧＷは通話データをアンカーする。つまり、ＵＥ１００とＵＥ１０２との間の通話開始時において、通話開始のＩＭＳシグナリングはＡＴＣＦで中継され、ＡＴＣＦがＡＴＧＷでの通話データのアンカーが必要と判断した場合、通話データのアンカーポイントとしてＡＴＧＷが割り当てられる。これにより、ＵＥ１００とＵＥ１０２との間の通話データは、Ｐａｔｈ  Ａ及びＰａｔｈ  Ｂを通って送受信される。【００１８】
ＵＥ１００がｅ−ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ−ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図３に示すシグナリング１１００。図４に示すＳＴ１１００）。ＳＴ１１００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷとの間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ−ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令が出される。【００１９】
ＳＴ１１００の処理と同時に、ＭＳＣ／ＭＧＷは、ＡＴＣＦにシグナリングを送る。これによりＡＴＣＦからＡＴＧＷに経路切替の指示が出され、ＡＴＧＷの通話データ送受信先がＵＥ１００からＭＳＣ／ＭＧＷに切り替わる（図３に示すシグナリング１１０２。図４に示すＳＴ１１０２）。すなわち、Ｐａｔｈ  Ｃが確立される。また、ＡＴＧＷへの経路切替処理が完了すると、ＡＴＣＦは、ＳＣＣ−ＡＳに通知シグナリングを送信する（図３に示すシグナリング１１０２。図４に示すＳＴ１１０２）。【００２０】
ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷとシグナリングをやり取りする（図３に示すシグナリング１１０４。図４に示すＳＴ１１０４）。これにより、Ｐａｔｈ  Ｄが確立される。【００２１】
Ｐａｔｈ  Ｄ確立後、ＭＳＣ／ＭＧＷは、ＭＭＥ経由でＰ−ＧＷ／Ｓ−ＧＷとシグナリングをやり取りする（図３に示すシグナリング１１０６。図４に示すＳＴ１１０６）。これにより、Ｐａｔｈ  Ｂは削除される。【００２２】
以上、ｅＳＲＶＣＣハンドーバの動作について説明した。【００２３】
ＣＳ網で利用される音声コーデックとして、狭帯域（ＮＢ：Narrowband）コーデックであるＡＭＲ（Adaptive Multi-Rate）コーデック及び広帯域（ＷＢ：Wideband）コーデックであるＡＭＲ−ＷＢコーデック等が広く用いられている。ＡＭＲ及びＡＭＲ−ＷＢは、パケット交換方式で利用可能であるため、ＰＳ網（ＶｏＬＴＥ）での利用も考えられている。【００２４】
ＡＭＲ及びＡＭＲ−ＷＢは、サポートしているビットレートがそれぞれ異なる。更に、ＡＭＲ及びＡＭＲ−ＷＢがＰＳ網で用いられる場合には、非特許文献２に記載の通り、ＲＴＰ（Real-time Transport Protocol）ペイロードフォーマットで用いられる、ビットレートに対する番号付け（Frame Type Index）が双方でオーバラップしている。このため、ＣＳ網での利用においてもＰＳ網での利用においても、セッション開始時にＡＭＲ若しくはＡＭＲ−ＷＢのどちらを用いるかを決める必要がある。つまり、セッションの再折衝無しでＡＭＲとＡＭＲ−ＷＢとを切り替えることは不可能である。
【００２５】
尚、従来技術において、狭帯域コーデックとは、一般的に３００Ｈｚ〜３．４ｋＨｚの帯域幅で、８ｋＨｚでサンプリングされるコーデックである。また、広帯域コーデックとは、一般的に５０Ｈｚ〜７ｋＨｚの帯域幅で、１６ｋＨｚでサンプリングされるコーデックである。また、超広帯域（ＳＷＢ：Super Wideband）コーデックとは、一般的に５０Ｈｚ〜１４ｋＨｚの帯域幅で、３２ｋＨｚでサンプリングされるコーデックである。
【先行技術文献】
【非特許文献】
【００２６】
【非特許文献１】3GPP TS23.216 v9.6.0 “Single Radio Voice Call Continuity (SRVCC)”
【非特許文献２】IETF RFC 4867、 “RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs”
【非特許文献３】3GPP TS23.237 v11.0.0 “IP Multimedia Subsystem (IMS) Service Continuity”
【非特許文献４】Takashi Koshimizu and Katsutoshi Noshida, “Audio Viedo Callof Single Radio Voice Call Continuity”, 2011年電子情報通信学会総合大会，B-6-77
【非特許文献５】西田克利，輿水敬，「音声呼のＩＭＳ−回線交換間ハンドオーバ方式の改善提案移動機能力に基づく在圏アンカー型ＳＲＶＣＣ方式」，信学技報 NS2010-178，pp85-90
【発明の概要】
【発明が解決しようとする課題】
【００２７】
図１または図３において、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバした際、ＰＳ網で使用していたコーデックがＣＳ網でサポートされていない場合には、ＵＥ１００で使用されるコーデックは、ＣＳ網でサポートされているコーデックに変更される。ＵＥ１００のコーデックに変更が生じた場合、ＵＥ１００とＵＥ１０２との通話継続を可能にするためには、次の２つの方法が考えられる。１つ目の方法は、ＵＥ１０２で使用されるコーデックをＵＥ１００の変更後のコーデックと同じものに変更する方法である。２つ目の方法は、ＭＳＣ／ＭＧＷにおいてトランスコーディングを行う方法である。【００２８】
前者の方法では、ＵＥ１０２のコーデックを変更するためのシグナリングに時間がかかり、通話が途切れる時間が長くなるので好ましくない。更に、ｅＳＲＶＣＣハンドオーバでは、ＵＥ１００のハンドオーバの際の経路切替のためのシグナリングがＡＴＣＦで終端するため、ＵＥ１０２のコーデックを変更するためのシグナリングを送ることすらできない。すなわち、ｅＳＲＶＣＣハンドオーバでは、既存のシグナリングを使ってＵＥ１０２のコーデックを変更することができない。【００２９】
よって、後者のトランスコーディングの方法が比較的好ましいと考えられる。しかしながら、トランスコーディングを行った場合、特にコーデックの帯域幅（コーデックの入出力となる信号の帯域幅）が異なる場合には、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする際、通話品質の劣化が生じてしまう。【００３０】
本発明の目的は、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる通信端末装置、ネットワークノード及び通信方法を提供することである。
【課題を解決するための手段】
【００３１】
本発明の一態様に係るネットワークノードは、異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行うネットワークノードであって、前記２つの端末がそれぞれ使用するコーデックを検出する検出手段と、前記検出手段での検出結果に基づいて、前記２つの端末のうちいずれか一方の端末が使用するコーデックの変更を検出した場合、前記一方の端末以外の他方の端末の第１のコーデック、及び、前記一方の端末の変更後の第２のコーデックを用いて、前記第１のコーデックの第１の帯域幅の制限を行うか否かを判断する判断手段と、前記判断手段において前記第１の帯域幅を制限すると判断された場合、前記第１の帯域幅を制限させるためのシグナリングを、前記他方の端末へ送信する送信手段と、を具備する構成を採る。【００３２】
本発明の一態様に係る端末は、異なるコーデックを使用する端末間の通信に対して、端末間に位置するネットワークノードでトランスコーディングが行われる通信システムで用いられる端末であって、前記端末と、前記端末の通信相手である相手端末との間の通信に使用する第１のコーデックを折衝する折衝手段と、折衝された前記第１のコーデックに対して、前記端末においてエンコードされる入力信号の第１の帯域幅を決定する決定手段と、前記ネットワークノードから通知される、前記第１の帯域幅を制限させるためのシグナリングに従って、前記決定手段で決定された前記第１の帯域幅の変更を制御する変更手段と、を具備する構成を採る。【００３３】
本発明の一態様に係る帯域幅変更判断方法は、異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行うネットワークノードにおける帯域幅変更判断方法であって、前記２つの端末がそれぞれ使用するコーデックを検出し、検出結果に基づいて、前記２つの端末のうちいずれか一方の端末が使用するコーデックの変更を検出した場合、前記一方の端末以外の他方の端末の第１のコーデック、及び、前記一方の端末の変更後の第２のコーデックを用いて、前記第１のコーデックの第１の帯域幅の制限を行うか否かを判断し、前記第１の帯域幅を制限すると判断された場合、前記第１の帯域幅を制限させるためのシグナリングを、前記他方の端末へ送信する。【００３４】
本発明の一態様に係る帯域幅変更方法は、異なるコーデックを使用する端末間の通信に対して、端末間に位置するネットワークノードでトランスコーディングが行われる通信システムで用いられる端末における帯域幅変更方法であって、前記端末と、前記端末の通信相手である相手端末との間の通信に使用する第１のコーデックを折衝し、折衝された前記第１のコーデックに対して、前記端末においてエンコードされる入力信号の第１の帯域幅を選択し、前記ネットワークノードから通知される、前記第１の帯域幅を制限させるためのシグナリングに従って、前記第１の帯域幅の変更を制御し、前記第１の帯域幅の変更の制御に従って、前記第１の帯域幅を決定する。
【発明の効果】
【００３５】
本発明によれば、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる。
【図面の簡単な説明】
【００３６】
【図１】３ＧＰＰの移動通信ネットワークの一部を示す構成図
【図２】ＳＲＶＣＣハンドオーバの動作を示すシーケンスチャート
【図３】ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワークの一部を示す構成図
【図４】ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャート
【図５】本発明の実施の形態１に係る移動通信ネットワークの一部を示す構成図
【図６】本発明の実施の形態１に係るネットワークノード（ＭＳＣ／ＭＧＷ）の構成を示すブロック図
【図７】本発明の実施の形態１に係るＭＳＣ／ＭＧＷの変更判断部における判断方法の一例を示すフローチャート
【図８】本発明の実施の形態１に係る端末（ＵＥ）の構成を示すブロック図
【図９】本発明の実施の形態１に係るコーデック折衝に用いるＳＤＰの一例を示す図
【図１０】本発明の実施の形態１に係る動作を示すシーケンスチャート
【図１１】本発明の実施の形態１に係る帯域制限依頼メッセージの一例を示す図
【図１２】本発明の実施の形態２に係る端末（ＵＥ）の構成を示すブロック図
【図１３】本発明の実施の形態３に係る移動通信ネットワークの一部を示す構成図
【図１４】本発明の実施の形態３に係るネットワークノード（ＭＳＣ／ＭＧＷ）の構成を示すブロック図
【図１５】本発明の実施の形態３に係る動作を示すシーケンスチャート
【図１６】本発明の実施の形態３に係るＭＳＣ／ＭＧＷのコーデック選択部におけるコーデックの選択方法の一例を示すフローチャート
【図１７】本発明の実施の形態３のバリエーションに係る動作を示すシーケンスチャート
【図１８】本発明の実施の形態４に係る移動通信ネットワークの一部を示す構成図
【図１９】本発明の実施の形態４に係るネットワークノード（ＡＴＣＦ／ＡＴＧＷ、ＭＳＣ／ＭＧＷ）の構成を示すブロック図
【図２０】本発明の実施の形態４に係る端末（ＵＥ）の構成を示すブロック図
【図２１】本発明の実施の形態４に係る動作を示すシーケンスチャート
【発明を実施するための形態】
【００３７】
以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
【００３８】
以下の説明では、「帯域幅」とはコーデックの入出力となる信号の帯域幅のことを指す。
【００３９】
また、以下の説明では、「帯域幅の指定が必ずしも必要の無いコーデック」とは、エンコードされる入力信号の帯域幅を、セッションの再折衝無しで切り替えることが可能なコーデックを意味する。例えば、ＥＶＳ（Enhanced Voice Services）コーデックの非互換(non interoperable)モードは、ＰＳ網のみで利用される上、サポートされるビットレートは、どの帯域幅においても共通である（「3GPP TSG SA WG4 S4-110539 “EVS Permanent Document #4 (EVS-4): EVS design constraints”」参照）。このため、ＥＶＳコーデックの非互換モードでは、ナイキスト周波数（Nyquist frequency：サンプリング周波数の１／２）以下の帯域幅であれば、セッション途中でも、エンコードされる入力信号の帯域幅を自由に変更できるよう設計することが可能である。よって、セッションの開始から終了までにおける帯域幅の指定が必ずしも必要ではない。この場合、エンコーダは、例えば入力信号の特性（例えば入力信号の周波数特性及び入力信号を分析して得られるパラメータ等）、又は、エンコーディングビットレートに応じて、エンコードされる入力信号の帯域幅を設定又は変更する。
【００４０】
（実施の形態１）
図５は、本発明の実施の形態１に係る移動通信ネットワークの一部を示す構成である。なお、図５において、図１と同一構成である部分には同一の符号を付してその説明を省略する。図５では、図１と比較して、ＵＥ１００、１０２及びＭＳＣ／ＭＧＷ３００の動作が異なる。
【００４１】
まず、図５に示すＭＳＣ／ＭＧＷ３００について説明する。ＭＳＣ／ＭＧＷ３００は、異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行う。
【００４２】
図６は、本実施の形態に係るＭＳＣ／ＭＧＷ３００（ネットワークノード）の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図６では、本発明と密接に関連する帯域制限（帯域変更）処理に関わる主な構成部（例えば、図５に示すＳＴ４０２〜４０６（後述する）に関わる構成部）を示す。
【００４３】
図６に示すＭＳＣ／ＭＧＷ３００において、受信部６００は、通話データ（以下、通信データとする）、シグナリング等を受信する。例えば、受信部６００は、ＵＥ１００及びＵＥ１０２からそれぞれ送信されるシグナリング（例えば、図１に示すシグナリング２０２，２０４）を受信すると、受信したシグナリングを、コーデック検出部６０４及びコーデック帯域幅検出部６０６に出力する。
【００４４】
送信部６０２は、通信データ、シグナリング等を送信する。例えば、送信部６０２は、シグナリング生成部６１０から出力されるシグナリングをＵＥ１０２へ通知する。
【００４５】
コーデック検出部６０４は、受信部６００から入力されるＵＥ１００及びＵＥ１０２からのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックを検出する。そして、コーデック検出部６０４は、検出したコーデックを示す情報（検出結果）を変更判断部６０８に出力する。
【００４６】
コーデック帯域幅検出部６０６は、受信部６００から入力されるＵＥ１００及びＵＥ１０２からのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックの帯域幅を検出する。そして、コーデック帯域幅検出部６０６は、検出したコーデックの帯域幅を示す情報（検出結果）を、変更判断部６０８に出力する。
【００４７】
変更判断部６０８は、コーデック検出部６０４から入力される情報に示されるコーデック、及び、コーデック帯域幅検出部６０６から入力される情報に示されるコーデックの帯域幅に基づいて、ＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であるか、及び、帯域幅制限が必要であるかを判断する。例えば、変更判断部６０８は、コーデック検出部６０４での検出結果に基づいて、２つの端末（ＵＥ１００及びＵＥ１０２）のうち一方のＵＥ１００が使用するコーデックの変更を検出した場合、他方のＵＥ１０２のコーデック、及び、ＵＥ１００の変更後のコーデックを用いて、ＵＥ１０２のコーデックの帯域幅の制限を行うか否かを判断する。変更判断部６０８は、判断結果をシグナリング生成部６１０に出力する。なお、変更判断部６０８における帯域幅の変更判断処理の詳細については後述する。
【００４８】
シグナリング生成部６１０は、変更判断部６０８でＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であり、かつ、帯域幅制限が必要であると判断された場合、ＵＥ１０２でエンコードされる入力信号の帯域幅の制限を、ＵＥ１０２に対して依頼するシグナリングを生成する。帯域幅制限を依頼するシグナリングには、例えば、ＵＥ１００の変更後の帯域幅を示す情報を含めてもよい。シグナリング生成部６１０は、生成したシグナリングを、送信部６０２を介して、ＵＥ１０２へ送信する。このようにして、変更判断部６０８においてＵＥ１０２のコーデックの帯域幅を制限すると判断された場合、帯域幅を制限させるためのシグナリングが、送信部６０２を介して、ＵＥ１０２へ送信される。
【００４９】
トランスコーディング部６１２は、ＵＥ１００及びＵＥ１０２がそれぞれ異なるコーデックを使用する場合、ＵＥ１００からＵＥ１０２への通信データ、及び、ＵＥ１０２からＵＥ１００への通信データに対してトランスコーディングを行う。
【００５０】
次いで、図７を用いて、ＭＳＣ／ＭＧＷ３００の変更判断部６０８における帯域幅の変更判断処理の詳細について説明する。
【００５１】
図７に示すＳＴ８００において、変更判断部６０８は、コーデック検出部６０４での検出結果（検出されるコーデック）に基づいて、ＵＥ１００のコーデックが変更されたか否かを判断する。
【００５２】
ＵＥ１００のコーデックが変更された場合（ＳＴ８００：Ｙｅｓ）、ＳＴ８０２において、変更判断部６０８は、コーデック検出部６０４での検出結果に基づいて、ＵＥ１０２で使用されているコーデックが、コーデックＡのように、帯域幅の指定不要なコーデックであるか否かを判断する。
【００５３】
ＵＥ１０２で使われているコーデックが帯域幅の指定不要なコーデックである場合（ＳＴ８０２：Ｙｅｓ）、ＳＴ８０４において、変更判断部６０８は、コーデック帯域幅検出部６０６での検出結果に基づいて、ＵＥ１００の変更後のコーデックの帯域幅が、ＵＥ１０２が現在使用しているコーデックの最大帯域幅よりも狭いか否かを判断する。
【００５４】
ＵＥ１００の変更後のコーデックの帯域幅が、ＵＥ１０２が現在使用しているコーデックの最大帯域幅よりも狭い場合（ＳＴ８０４：Ｙｅｓ）、ＳＴ８０６において、変更判断部６０８は、ＵＥ１０２へのエンコードされる入力信号の帯域幅の制限が可能かつ必要であると判断する。例えば、変更判断部６０８は、ＵＥ１０２のコーデックの帯域幅を、ＵＥ１００の変更後のコーデックの帯域幅に制限（変更）すると判断する。
【００５５】
一方、ＵＥ１００のコーデックが変更されていない場合（ＳＴ８００：Ｎｏ）、ＵＥ１０２で使われているコーデックが、帯域幅の指定不要なコーデックではない場合（ＳＴ８０２：Ｎｏ）、又は、ＵＥ１００の変更後のコーデックの帯域幅が、ＵＥ１０２が現在使用しているコーデックの最大帯域幅以上の場合（ＳＴ８０４：Ｎｏ）、ＳＴ８０８において、変更判断部６０８は、ＵＥ１０２への帯域制限は行わないと判断する。
【００５６】
このようにして、具体的には、ＭＳＣ／ＭＧＷ３００は、一方のＵＥのコーデックの変更が検出された場合、他方のＵＥのコーデックが帯域幅の指定不要なコーデックであるか否かを判断することで、他方のＵＥのコーデックの帯域幅を制限（変更）することが可能か否かを判断する。また、ＭＳＣ／ＭＧＷ３００は、一方のＵＥの変更後のコーデックの帯域幅が、他方のＵＥのコーデックの最大帯域幅よりも狭いか否かを判断することで、他方のＵＥのコーデックの帯域幅の制限（変更）が必要であるか否かを判断する。
【００５７】
次に、図５に示すＵＥ１００，１０２について説明する。
【００５８】
図８は、本実施の形態に係るＵＥ１００，１０２（端末）の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図８では、本発明と密接に関連する帯域制限処理に関わる主な構成部（例えば、図５に示すＳＴ４００〜４０６（後述する）に関わる構成部）を示す。
【００５９】
図８に示すＵＥ１００，１０２において、受信部７００は、通信データ及びシグナリング等を受信する。例えば、受信部７００は、ＭＳＣ／ＭＧＷ３００から送信されるシグナリング（例えば、図１に示すシグナリング２０２又は２０４）を受信すると、受信したシグナリングを、コーデック折衝部７０４及びシグナリング解析部７１０に出力する。
【００６０】
送信部７０２は、通信データ及びシグナリング（例えば、図１に示すシグナリング２０２又は２０４）等を送信する。
【００６１】
コーデック折衝部７０４は、端末（ここではＵＥ１００とＵＥ１０２）間の通信に使用するコーデックを折衝する。具体的には、コーデック折衝部７０４は、ＳＤＰ（Session Description Protocol）オファー又はＳＤＰアンサーを作成し、コーデック折衝を行う。また、ＵＥ（図５ではＵＥ１００）がＣＳ網に移動した場合には、当該ＵＥのコーデック折衝部７０４は、ＣＳ網での折衝方法に基づき、コーデック折衝を行う。コーデック折衝部７０４は、コーディング折衝の結果をコーデック選択部７０６に出力する。
【００６２】
図９は、本発明の実施の形態におけるコーデック折衝に用いるＳＤＰの一例を示す。発呼側ＵＥは、帯域幅の指定が必ずしも必要の無いコーデック（以下、コーデックＡという）をサポートしている場合、コーデックＡに対し、サンプリング周波数のみ指定し、帯域幅の指定はせずにＳＤＰオファーを生成する。例えば、図９では、発呼側ＵＥが生成するＳＤＰオファー（SDP offer）には、従来のＷＢコーデックであるＡＭＲ−ＷＢコーデック（例えば、帯域幅：５０Ｈｚ〜７ｋＨｚ、サンプリング周波数：16000）、従来のＮＢコーデックであるＡＭＲコーデック（例えば、帯域幅：３００Ｈｚ〜３．４ｋＨｚ、サンプリング周波数：8000）、及び、帯域幅の指定不要なコーデックＡ（サンプリング周波数:32000）が記載されている。
【００６３】
また、着呼側ＵＥは、自らがコーデックＡをサポートしている場合、帯域幅の指定が無く、コーデックＡのサンプリング周波数のみ指定された条件を受け入れ（図９に示すコーデックＡを選択し）、ＳＤＰアンサー（SDP answer）を生成する。なお、コーデックＡは前述のＥＶＳコーデックの非互換モードであってもよい。ここで、コーデックＡのサンプリング周波数32000がサポートしている最大の帯域幅は、ＳＷＢ（Super Wideband）相当であり、エンコーダはこの帯域幅内においては、セッション途中でも、入力信号の特性又はエンコーディングビットレートに応じて、帯域幅を自由に変更することが可能であるとする。
【００６４】
コーデック選択部７０６は、コーデック折衝部７０４により折衝されたコーデックを選択し、選択したコーデックを示す情報を帯域幅決定部７０８に出力する。
【００６５】
帯域幅決定部７０８は、コーデック選択部７０６で選択されたコーデックに対して、自端末においてエンコードされる入力信号の帯域幅を決定する。例えば、帯域幅決定部７０８は、コーデック選択部７０６により選択されたコーデックの帯域幅が一定である場合、当該帯域幅を選択する。一方、帯域幅決定部７０８は、コーデック選択部７０６により選択されたコーデックの帯域幅がコーデックＡのように帯域幅を１セッションの中で変更できる場合には、エンコードされる入力信号の帯域幅をフレーム毎に決定する。帯域幅決定部７０８は、例えば、エンコーディングビットレート、入力信号特性、又は、外部シグナリングによる帯域幅制限の依頼等に応じて、エンコードされる入力信号の帯域幅をフレーム毎に決定する。より詳細には、帯域幅決定部７０８は、例えば、コーデックモード変更部７１２からコーデックの帯域幅の制限（変更）を依頼されていることが通知されると、エンコードされる入力信号の帯域幅を、依頼されている帯域幅に制限（変更）する。
【００６６】
シグナリング解析部７１０は、受信部７００から入力されるシグナリングを解析する。シグナリングには、例えば、ＭＳＣ／ＭＧＷ３００からの帯域幅の制限を依頼するシグナリング（帯域幅を制限させるためのシグナリング）が含まれる。シグナリング解析部７１０は、シグナリング解析の結果を、コーデックモード変更部７１２に通知する。
【００６７】
コーデックモード変更部７１２は、シグナリング解析部７１０から入力されるシグナリング解析結果が、コーデックの帯域幅の制限（変更）を依頼するシグナリングの場合、エンコードされる入力信号の帯域幅を制限（変更）することを決定し、その旨を帯域幅決定部７０８に通知する。すなわち、コーデックモード変更部７１２は、ＭＳＣ／ＭＧＷ３００から通知される、コーデックの帯域幅を制限させるためのシグナリングに従って、帯域幅決定部７０８で決定された帯域幅の変更を制御する。
【００６８】
なお、シグナリング解析部７１０は、他の外部シグナリングを解析し、その解析結果をコーデックモード変更部７１２に通知してもよい。例えばシグナリング解析部７１０は、上述したＲＴＣＰ−ＡＰＰを解析し、その解析結果（例えばエンコーディングビットレートの変更依頼）を、コーデックモード変更部７１２に通知してもよい。この場合、コーデックモード変更部７１２は、エンコーディングビットレートを決定すると、決定したエンコーディングビットレートを、帯域幅決定部７０８に通知する。そして、帯域幅決定部７０８は、決定されたエンコーディングビットレートに応じて、帯域幅を決定する。
【００６９】
次に、本実施の形態におけるＵＥ１００，１０２、及び、ＭＳＣ／ＭＧＷ３００の動作の一例について説明する。
【００７０】
図１０は、図５に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。なお、図１０において、図２と同一動作である部分には同一の符号を付してその説明を省略する。
【００７１】
以下の説明では、図５において、現在、ＵＥ１００及びＵＥ１０２の双方ともにｅ−ＵＴＲＡＮ等のＶｏＬＴＥ通話サービスを可能とする無線アクセス網に接続しているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局、ＰＳ網は図示せず）。つまり、図５に示すＵＥ１００とＵＥ１０２との間でＶｏＬＴＥ通話を開始する。
【００７２】
通話開始の際、ＵＥ１００とＵＥ１０２との間で使用するコーデックの折衝が行われる（例えば、「3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS);Multimedia Telephony; Media Handling and interaction”」参照）。例えば、ＵＥ１００及びＵＥ１０２（コーデック折衝部７０４）は、帯域幅の指定が必ずしも必要の無いコーデックに対して、当該コーデックの折衝を帯域幅指定無しで行う（図５及び図１０に示すＳＴ４００）。
【００７３】
次いで、図５に示すように、ＵＥ１００がＳＲＶＣＣによるハンドオーバを行い、ＵＴＲＡＮに移動したとする。つまり、ＵＥ１００がＰＳ網からＣＳ網に移動したとする。
【００７４】
この場合、図１０のＳＴ２０４のプロセスの中で、ＵＥ１００（コーデック折衝部７０４）とＭＳＣ／ＭＧＷ３００との間においてＣＳ網で使用するコーデックが再折衝される。ここでは、例えば、ＵＥ１００に対してＡＭＲコーデックを利用するよう折衝され、ＵＥ１００が使用するコーデックの帯域幅がＮＢに制限されたと仮定する（図５及び図１０に示すＳＴ４０２）。
【００７５】
また、ＭＳＣ／ＭＧＷ３００（コーデック検出部６０４及びコーデック帯域幅検出部６０６）は、図１０のＳＴ２０２のプロセスにより、ＵＥ１０２が使用しているコーデックがコーデックＡであり、最大帯域幅がＳＷＢであることを検出する。
【００７６】
また、ＭＳＣ／ＭＧＷ３００（コーデック検出部６０４及びコーデック帯域幅検出部６０６）は、図１０のＳＴ２０４のプロセスにより、ＵＥ１００で使用されるコーデックがＡＭＲになり、帯域幅がＮＢに制限されたことを検出する。
【００７７】
ＭＳＣ／ＭＧＷ３００（変更判断部６０８）は、ＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であるか、及び、帯域幅制限が必要であるかを判断する。ここでは、ＵＥ１００のコーデックが変更され（図７に示すＳＴ８００：Ｙｅｓ）、ＵＥ１０２のコーデックがコーデックＡであり（図７に示すＳＴ８０２：Ｙｅｓ）、かつ、ＵＥ１００のＡＭＲコーデックの帯域幅（ＮＢ）がＵＥ１０２のコーデックＡの最大帯域幅（ＳＷＢ）よりも狭い（図７に示すＳＴ８０４：Ｙｅｓ）。そこで、ＭＳＣ／ＭＧＷ３００（変更判断部６０８）は、ＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能かつ必要であると判断する（図７に示すＳＴ８０６）。
【００７８】
そこで、ＭＳＣ／ＭＧＷ３００（シグナリング生成部６１０）は、ＵＥ１０２に対し、コーデックＡのエンコードされる入力信号の帯域幅を、ＮＢ（ＵＥ１００の変更後のコーデックの帯域幅）に制限するよう依頼するシグナリングを送る（図５及び図１０に示すＳＴ４０４）。このシグナリングは、例えばＳＴ２０２の一連のシグナリング（即ち、ＩＭＳシグナリング）に含まれてもよく、ＲＴＣＰ（Real-time Transport Control Protocol）−ＡＰＰ（Application-defined）（例えば、「3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS);Multimedia Telephony; Media Handling and interaction”」参照）のような別のシグナリングで送られてもよい。図１１Ａは、帯域制限を通知するシグナリングがＩＭＳシグナリングに含まれる場合の一例を示す。また、図１１Ｂは、帯域制限を通知するシグナリングがＲＴＣＰ−ＡＰＰに含まれる場合の一例を示す。
【００７９】
ＵＥ１０２（シグナリング解析部７１０）は、ＭＳＣ／ＭＧＷ３００からのシグナリングを解析する。そして、ＵＥ１０２（コーデックモード変更部７１２）は、コーデックＡの帯域幅の制限を依頼されていることを特定する。そこで、ＵＥ１０２（帯域幅決定部７０８）は、ＵＥ１０２のエンコードされる入力信号の帯域幅を、依頼された帯域幅（ここではＮＢ）に制限する。そして、ＵＥ１０２は、制限した帯域幅で通信データをエンコードする（図１０に示すＳＴ４０６）。
【００８０】
このようにして、ＵＥ１００は、変更後のコーデックの帯域幅（ＮＢ）を使用し、ＵＥ１０２は、コーデックＡの帯域制限した帯域幅（ＮＢ）を使用する。これにより、ＵＥ１００及びＵＥ１０２の双方ともコーデック帯域幅として同一のＮＢを使用する。よって、ＭＳＣ／ＭＧＷ３００（トランスコーディング部６１２）では、ＵＥ１０２側からＵＥ１００側へのトランスコーディング（コーデックＡ（超広帯域）からＡＭＲコーデック（狭帯域）へのトランスコーディング）を行う場合でも、通話品質の劣化を抑えることができる。
【００８１】
このように、本実施の形態では、ＭＳＣ／ＭＧＷ３００（ネットワークノード）は、通信中のＵＥの一部のＵＥ１００にコーデックの変更が生じた場合でも、他のＵＥ１０２に対して、ＵＥ１００の変更後のコーデックの帯域幅に合わせるように、コーデックの帯域幅の制限を要求する。また、ＵＥ１０２は、ＶｏＬＴＥ通話中の通信相手であるＵＥ１００のコーデックが変更（狭帯域幅に変更）された場合でも、ＵＥ１０２のエンコードされる入力信号の帯域幅をＵＥ１００に合わせて制限する。すなわち、ＵＥ１０２は、通信相手であるＵＥ１００のネットワーク状況に応じて、ＵＥ１００との通信を途切れさせることなく、エンコードされる入力信号の帯域幅を変更する。
【００８２】
これにより、一方のＵＥのネットワーク状況が変わった場合でも、ＵＥ間のコーデックの帯域幅を同等に維持することができる。よって、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする場合に生じる通話品質の劣化を抑えることができる。すなわち、ＭＳＣ／ＭＧＷ３００は、通信品質の劣化を抑えてトランスコーディングを行うことができる。
【００８３】
更に、ＵＥ１０２では、コーデックを変更せずに、エンコードされる入力信号の帯域幅のみを制限するので、コーデックを変更するためのシグナリングが不要となり、通話が途切れる時間が長くなることを防ぐことができる。
【００８４】
よって、本実施の形態によれば、ＶｏＬＴＥ通話中のＵＥ１００がＣＳ網にハンドオーバし、ハンドオーバ先ＣＳ網でコーデックが変更された場合でも、通話を途切れさせることなくＵＥ１０２のエンコードされる入力信号の帯域幅を制限することができる。これにより、ＵＥ１０２側からＵＥ１００側へのトランスコーディングによる通話品質の劣化を抑えることができる。つまり、本実施の形態によれば、ＶｏＬＴＥ通話中の端末（ＵＥ）の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる。
【００８５】
なお、上記実施の形態（例えば、図５参照）において、ＵＥ１００がｒＳＲＶＣＣ（reverse SRVCC。例えば、「3GPP TR23.885 v1.2.0 “Feasibility Study of Single Radio Voice Call Continuity (SRVCC) from UTRAN/GERAN to E-UTRAN/HSPA”」参照）に対応している場合、ＰＳ網からＣＳ網にハンドオーバした後、再びＰＳ網にハンドオーバする可能性もある。この場合、ＭＳＣ／ＭＧＷ３００は、ＵＥ１００のＣＳ網からＰＳ網へのハンドオーバ処理に関するシグナリングを受け取った時点で、ＵＥ１０２に対して、コーデックの帯域幅制限を解除するシグナリングを送信してもよい。又は、ＭＳＣ／ＭＧＷ３００は、ＵＥ１００がＰＳ網へのハンドオーバ完了後に、ＵＥ１０２に対して、コーデックの帯域幅制限を解除するシグナリングを送信してもよい。
【００８６】
また、上記実施の形態（例えば、図５参照）では、ＵＥ１００が通話開始の際、ＰＳ網に接続している場合について説明した。しかし、ＵＥ１００が通話開始時に、ＣＳ網に接続している場合もあり得る。この場合、例えば、「3GPP TS23.292 v10.3.0 “IP Multimedia Subsystem (IMS) centralized services”」に記載の方法で、ＵＥ１００は、ＰＳ網に接続しているＵＥ１０２との間で通話を開始する。ここで、ＵＥ１００がｒＳＲＶＣＣに対応している場合（即ち、ＵＥ１００がＰＳ網にハンドオーバし得る場合）、ＭＳＣ／ＭＧＷ３００は、ＵＥ１０２との間で、コーデックの折衝を行う際、ＵＥ１０２に対し、ＵＥ１００が使用するコーデックの帯域幅を最大帯域幅としてエンコードするように、予め折衝してもよい。又は、ＭＳＣ／ＭＧＷ３００は、ＵＥ１０２との折衝後に別のシグナリングで、ＵＥ１０２にエンコードされる入力信号の帯域幅の制限を依頼してもよい。
【００８７】
また、本実施の形態では、ＳＲＶＣＣ方式を用いて説明したが、ｅＳＲＶＣＣ方式においても本実施の形態を適用することができる。
【００８８】
ＳＲＶＣＣ方式では、通信中のＵＥが使用するコーデックが異なる場合、ＭＧＷ（ＭＳＣ／ＭＧＷ３００）においてトランスコーディングが行われる。一方、非特許文献３によると、ｅＳＲＶＣＣ方式では、ＭＧＷがトランスコーディングを行う代わりに、ＡＴＧＷがトランスコーディングを行ってもよいことになっている。
【００８９】
ここで、ｅＳＲＶＣＣ方式において、ＭＧＷではなくＡＴＧＷでトランスコーディングを行う場合、ＳＲＶＣＣ方式について、本実施の形態に係るＭＳＣ／ＭＧＷ３００（図５参照）へ追加された機能は、ＡＴＣＦ／ＡＴＧＷ１１２０（図３参照）に追加される。すなわち、ｅＳＲＶＣＣ方式では、ＡＴＣＦ／ＡＴＧＷ１１２０が、図６に示す受信部６００、送信部６０２、コーデック検出部６０４、コーデック帯域幅検出部６０６、変更判断部６０８、シグナリング生成部６１０及びトランスコーディング部６１２を具備する構成を採る。ここで、ｅＳＲＶＣＣ方式においてＡＴＣＦ／ＡＴＧＷ１１２０が有する、送信部６０２、コーデック検出部６０４、変更判断部６０８、シグナリング生成部６１０及びトランスコーディング部６１２に関しては、ＳＲＶＣＣ方式においてＭＳＣ／ＭＧＷ３００が有する各構成部と同一の機能を持つ。
【００９０】
ｅＳＲＶＣＣ方式におけるＡＴＣＦ／ＡＴＧＷ１１２０の受信部６００（図６）は、通信データ、シグナリング等を受信する。例えば、受信部６００は、ＵＥ１００、ＵＥ１０２、ＡＴＣＦ、及びＭＳＣ／ＭＧＷからそれぞれ送信されるシグナリング（例えば、図３に示すシグナリング１１０２）を受信すると、受信したシグナリングを、コーデック検出部６０４及びコーデック帯域幅検出部６０６に出力する。
【００９１】
コーデック検出部６０４は、受信部６００から入力されるＵＥ１００、ＵＥ１０２、ＡＴＣＦ、及びＭＳＣ／ＭＧＷからのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックを検出する。そして、コーデック検出部６０４は、検出したコーデックを示す情報（検出結果）を変更判断部６０８に出力する。
【００９２】
コーデック帯域幅検出部６０６は、受信部６００から入力されるＵＥ１００、ＵＥ１０２、及びＭＳＣ／ＭＧＷからのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックの帯域幅を検出する。そして、コーデック帯域幅検出部６０６は、検出したコーデックの帯域幅を示す情報（検出結果）を、変更判断部６０８に出力する。
【００９３】
なお、ここでは、ＡＴＣＦ／ＡＴＧＷ１１２０を一つのノードとして説明したが、別々のノードでもよい。よって、上述したＡＴＣＦ／ＡＴＧＷ１１２０が有する機能を、ＡＴＣＦ又はＡＴＧＷの何れか一方若しくは両方が有していてもよい。また、ＡＴＣＦとＡＴＧＷとの間で必要な情報をやり取りしてもよい。
【００９４】
また、上記実施の形態において、各ＵＥは、コーディング折衝の際、図９のようにＳＤＰで帯域幅を固定して指定しない代わりに、ＳＤＰで最大帯域幅を指定してもよい。
【００９５】
また、上記実施の形態では、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷがＵＥ１０２に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する場合について説明した。しかし、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷは、帯域幅の制限を依頼するシグナリングの代わりに、エンコーディングビットレートの制限を依頼するシグナリングを送信してもよい。ここで、各ＵＥは入力信号のエンコーディングビットレートに基づいて、エンコードされる入力信号の帯域幅を設定する。よって、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷがエンコーディングビットレートの制限を依頼するシグナリングをＵＥに送信することで、当該ＵＥは、制限されたエンコーディングビットレートを設定し、かつ、制限されたエンコーディングビットレートに基づいて、エンコードされる入力信号の帯域幅を制限することが可能となる。または、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷは、帯域幅及びエンコーディングビットレートの双方の制限を依頼するシグナリングを送信してもよい。
【００９６】
また、上記実施の形態では、ＭＳＣ／ＭＧＷ３００（図６）を１つのノードとして説明した。しかし、ＭＳＣ／ＭＧＷ３００は、互いにインタフェースによって接続される２つ以上のノードで構成されてもよく、上述したＭＳＣ／ＭＧＷ３００の各機能をこれらの複数のノードに分散させてもよい。
【００９７】
（実施の形態２）
実施の形態１では、ＭＳＣ／ＭＧＷ３００又はＡＴＧＷ（ＡＴＣＦ／ＡＴＧＷ１１２０）がＵＥ１０２に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する場合について説明した。これに対して、本実施の形態では、ＭＳＣ／ＭＧＷ３００又はＡＴＧＷ（ＡＴＣＦ／ＡＴＧＷ１１２０）が帯域幅の制限を依頼するシグナリングを送信する代わりに、ＵＥ１０２が通信データを受け取ることにより、ＵＥ１００のコーデックの帯域幅が制限されたことを検知し、ＵＥ１０２のエンコードされる入力信号の帯域幅を制限する場合について説明する。
【００９８】
図１２を用いて、本実施の形態に係るＵＥについて説明する。
【００９９】
図１２に示すＵＥ１００，１０２において、受信部７００、送信部７０２、コーデック折衝部７０４、コーデック選択部７０６、及び帯域幅決定部７０８は、図８と同一動作を行う構成部であり、その説明を省略する。
【０１００】
データ解析部１２００は、受信部７００から入力される通信データを解析する。データ解析部１２００は、或る時刻から一定時間における通信データのコーデックの帯域幅の上限値が、その直前までのコーデック帯域幅の上限値、又は、通話開始時に折衝したコーデックの帯域幅の上限値と比較して異なる場合、通信相手先端末（ＵＥ）の通信データのコーデックの帯域幅が制限（変更）されたと解析する。データ解析部１２００は、解析結果を、コーデックモード変更部１２０２に通知する。
【０１０１】
コーデックモード変更部１２０２は、データ解析部１２００からの解析結果に基づき、エンコードされる入力信号の帯域幅を制限（変更）することを決定し、その旨を帯域幅決定部７０８に通知する。これにより、帯域幅決定部７０８は、コーデックモード変更部１２０２において決定された帯域幅の変更を制御する。
【０１０２】
このように、本実施の形態では、ＵＥ１００、１０２は、受け取った通信データのコーデックの帯域幅の上限値が変更されたか否かに応じて、通信相手端末のコーデックが変更されたか否かを判断する。そして、ＵＥ１００、１０２は、通信相手端末のコーデックが変更されたと判断した場合、自装置のコーデックの帯域幅の変更を制御する。これにより、実施の形態１と同様、一方のＵＥのネットワーク状況が変わった場合でも、ＵＥ間のコーデックの帯域幅を同等に維持することができる。よって、実施の形態１と同様、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする場合に生じる通話品質の劣化を抑えることができる。
【０１０３】
（実施の形態３）
図１３は、本発明の実施の形態３に係る移動通信ネットワークの一部を示す構成である。なお、図１３に示す各ノードの動作は前述（例えば図５）した通りである。
【０１０４】
図１３において、ＵＥ１００は、最初ＳＲＶＣＣにてＣＳ網にハンドオーバ（以下、ＳＲＶＣＣハンドオーバと呼ぶこともある）を行い、ＰＳ網に存在するＵＥ１０２と、ＭＳＣ／ＭＧＷ１３００を経由して、通信データを送受信している（図１３に示すＰａｔｈ  Ａ及びＰａｔｈ  Ｂ）。この際、ＵＥ１００はＣＳ網で利用するコーデックとしてＡＭＲ−ＷＢを用い、ＵＥ１０２はＰＳ網で利用するコーデックとして、例えば上述したコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）を用い、ＭＳＣ／ＭＧＷ１３００でトランスコーディングが行われていたとする。
【０１０５】
次に、ＵＥ１０２もＳＲＶＣＣによりＣＳ網にハンドオーバを行ったとする。
【０１０６】
この際、非特許文献１のハンドオーバ手順に従えば、ＵＥ１０２の移動先ＣＳ網での通信はＭＳＣ／ＭＧＷ１３０２で終端され、ＭＳＣ／ＭＧＷ１３００の通信相手先は、ＵＥ１０２からＭＳＣ／ＭＧＷ１３０２に変更される。すなわち、ＵＥ１００とＵＥ１０２との間の通信データの経路は、Ｐａｔｈ  Ｄ、Ｐａｔｈ  Ｃ及びＰａｔｈ  Ｂを通る経路に変更される。
【０１０７】
更に、ＵＥ１０２がＣＳ網で使用するコーデックがＡＭＲ−ＷＢに変更になったとする。この場合、ＵＥ１０２からＭＳＣ／ＭＧＷ１３０２までは、ＵＥ１０２からＵＥ１００へ送信される通信データは、Ｐａｔｈ  Ｄを通り、かつ、ＡＭＲ−ＷＢを用いて送信される。次いで、ＭＳＣ／ＭＧＷ１３０２は、ＵＥ１０２がＣＳ網で使用するＡＭＲ−ＷＢからＰＳ網で使用していたコーデックＡにトランスコーディングを行う。よって、ＭＳＣ／ＭＧＷ１３０２からＭＳＣ／ＭＧＷ１３００までは、ＵＥ１０２からＵＥ１００へ送信される通信データは、Ｐａｔｈ  Ｃを通り、かつ、コーデックＡを用いて送信される。次いで、ＭＳＣ／ＭＧＷ１３００は、コーデックＡからＡＭＲ−ＷＢにトランスコーディングを行う。よって、ＭＳＣ／ＭＧＷ１３００からＵＥ１００までは、ＵＥ１０２からＵＥ１００へ送信される通信データは、Ｐａｔｈ  Ｂを通り、かつ、ＡＭＲ−ＷＢを用いて送信される。ＵＥ１００からＵＥ１０２へ送信される通信データについても同様である。
【０１０８】
本実施の形態では、通信中のＵＥ１００及びＵＥ１０２の双方がＳＲＶＣＣハンドオーバを行った場合でも、ＭＳＣ／ＭＧＷ１３００，１３０２におけるトランスコーディングを最小限に抑える方法について説明する。
【０１０９】
まず、図１３に示すＭＳＣ／ＭＧＷ１３００、１３０２について説明する。
【０１１０】
図１４は、本実施の形態に係るＭＳＣ／ＭＧＷ１３００、１３０２構成を示すブロック図である。なお、図１４に示すＭＳＣ／ＭＧＷ１３００、１３０２は、図示される機能ブロックの他に、図８に示される機能ブロック又はその他の機能ブロックを具備していてもよい。
【０１１１】
図１４に示すＭＳＣ／ＭＧＷ１３００、１３０２において、受信部１５００は、通信データ、シグナリング等を受信する。
【０１１２】
送信部１５０２は、通信データ、シグナリング等を送信する。
【０１１３】
シグナリング解析部１５０４は、ＳＲＶＣＣ処理のためのシグナリング、又は、ＩＭＳのシグナリング（ＩＭＳシグナリング）等を解析する。シグナリング解析部１５０４は、シグナリング解析の結果を、シグナリング生成部１５０６、端末位置判断部１５０８及びコーデック選択部１５１０に通知する。
【０１１４】
シグナリング生成部１５０６は、シグナリング解析部１５０４のシグナリング解析結果等に基づいて、シグナリングを生成する。
【０１１５】
端末位置判断部１５０８は、シグナリング解析部１５０４のシグナリング解析結果に基づいて、通信中の双方の端末（ＵＥ１００、１０２）がＰＳ網に存在するのか、ＣＳ網に存在するのかを判断する。端末位置判断部１５０８は、判断結果をコーデック選択部１５１０及び経路選択部１５１２に出力する。
【０１１６】
コーデック選択部１５１０は、シグナリング解析部１５０４のシグナリング解析結果及び端末位置判断部１５０８の判断結果に基づいて、利用するコーデック、又はコーデック候補を選択する。
【０１１７】
経路選択部１５１２は、端末位置判断部１５０８の判断結果に基づいて、通信データが通る経路を選択する。
【０１１８】
次に、本実施の形態におけるＭＳＣ／ＭＧＷ１３００，１３０２の動作の一例について説明する。
【０１１９】
図１５は、図１３に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。なお、図１３において、ＳＣＣ  ＡＳ及びＣＳＣＦは図示していないが、ＩＭＳの一部として存在しているものとする。
【０１２０】
現在、ＵＥ１００とＵＥ１０２は、双方ともｅ−ＵＴＲＡＮに接続し、ＶｏＬＴＥ通信を行っているとする。つまり、現在、ＵＥ１００及びＵＥ１０２では、音声コーデックとして、前述のコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）が使用されているものとする（図１５に示すＳＴ１４００）。
【０１２１】
次いで、ＵＥ１００はＣＳ網にハンドオーバ（ＳＲＶＣＣハンドオーバ）する（図１０に示すＳＴ２００の処理（ＳＲＶＣＣ処理）と同等の処理）。また、ＵＥ１００はＣＳ網にハンドオーバし、ＣＳ網との間にコネクションを確立する（図１０に示すＳＴ２０４の処理（コネクション確立処理）と同等の処理）。
【０１２２】
ＳＴ２００の処理及びＳＴ２０４の処理と同時に、ＭＳＣ／ＭＧＷ１３００のシグナリング生成部１５０６は、ＵＥ１０２に送信するＩＭＳシグナリングを生成して、送信部１５０２を介して送信する（図１５に示すＳＴ１４０２）。このとき、シグナリング生成部１５０６は、当該ＩＭＳシグナリングの中に、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報を含める。例えば、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報は、非特許文献３に記載のＳＴＮ−ＳＲ（Session Transfer Number for SRVCC）等であってもよい。
【０１２３】
また、ＭＳＣ／ＭＧＷ１３００のシグナリング生成部１５０６は、ＵＥ１００がＰＳ網で使用していたコーデック（コーデックＡ）の他に、自網側のＣＳ網（ＭＳＣ／ＭＧＷ１３００が属するＣＳ網）でサポートしているコーデックのリストをＩＭＳシグナリングの中に含める（図１５に示すＳＴ１４０２）。この際、シグナリング解析部１５０４が、ＳＴ２０４のコネクション確立処理を待って、コネクション確立に関するシグナリングを解析し、ＵＥ１００がＣＳ網で使うコーデック情報を得て、その後、シグナリング生成部１５０６が、このコーデック情報をＩＭＳシグナリングの中に明示的に含めてもよい。
【０１２４】
これにより、ＵＥ１００〜ＭＳＣ／ＭＧＷ１３００ではＣＳ網を使った通信が行われ、ＭＳＣ／ＭＧＷ１３００〜ＵＥ１０２ではＰＳ網を使った通信が行われる（図１５に示すＳＴ１４０４）。
【０１２５】
次いで、ＵＥ１０２はＣＳ網にハンドオーバ（ＳＲＶＣＣハンドオーバ）する（図１０に示すＳＴ２００（ＳＲＶＣＣ処理）と同等の処理）。また、ＵＥ１０２はＣＳ網にハンドオーバし、ＣＳ網との間にコネクションを確立する（図１０に示すＳＴ２０４の処理（コネクション確立処理）と同等の処理）。
【０１２６】
ＳＴ２００の処理及びＳＴ２０４の処理と同時に、ＭＳＣ／ＭＧＷ１３０２のシグナリング生成部１５０６は、ＭＳＣ／ＭＧＷ１３００に送信するＩＭＳシグナリングを生成して、送信部１５０２を介して送信する（図１５に示すＳＴ１４０６）。このとき、シグナリング生成部１５０６は、当該ＩＭＳシグナリングの中に、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報を含める。例えば、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報は、非特許文献３に記載のＳＴＮ−ＳＲ（Session Transfer Number for SRVCC）等であってもよい。
【０１２７】
また、ＭＳＣ／ＭＧＷ１３０２のシグナリング生成部１５０６は、ＵＥ１０２がＰＳ網で使用していたコーデック（コーデックＡ）の他に、自網側のＣＳ網（ＭＳＣ／ＭＧＷ１３０２が属するＣＳ網）でサポートしているコーデックのリストをＩＭＳシグナリングの中に含める（図１５に示すＳＴ１４０６）。この際、シグナリング解析部１５０４が、ＳＴ２０４のコネクション確立処理を待って、コネクション確立に関するシグナリングを解析し、ＵＥ１０２がＣＳ網で使うコーデック情報を得て、その後、シグナリング生成部１５０６が、このコーデック情報をＩＭＳシグナリングの中に明示的に含めてもよい。
【０１２８】
ＭＳＣ／ＭＧＷ１３００の受信部１５００は、ＭＳＣ／ＭＧＷ１３０２からのＩＭＳシグナリングを受け取り、シグナリング解析部１５０４に出力する。シグナリング解析部１５０４は、このＩＭＳシグナリングを解析することにより、ＵＥ１０２がＳＲＶＣＣハンドオーバを行ったことを特定し、ＵＥ１０２がＳＲＶＣＣハンドオーバを行ったことを示す情報を端末位置判断部１５０８に出力する。また、シグナリング解析部１５０４は、このＩＭＳシグナリング（ＳＤＰオファー）に含まれるコーデックのリスト（ＭＳＣ／ＭＧＷ１３０２が属するＣＳ網でサポートしているコーデックのリスト）を、コーデック選択部１５１０に出力する。端末位置判断部１５０８は、ＵＥ１０２がＳＲＶＣＣハンドオーバを行ったことにより、ＵＥ１００及び１０２の双方ともＣＳ網に存在すると判断する。コーデック選択部１５１０は、端末位置判断部１５０８の判断結果、及び、シグナリング解析部１５０４から入力される、ＭＳＣ／ＭＧＷ１３０２が属するＣＳ網でサポートされているコーデック情報（コーデックのリスト）を用いて、利用するコーデックを選択する（図１５に示すＳＴ１４０６）。
【０１２９】
また、経路選択部１５１２は、端末位置判断部１５０８の判断結果に基づいて、通信データが通る経路を選択する（図１５に示すＳＴ１４０６）。これにより、ＵＥ１００とＵＥ１０２との通信は、選択された経路を通って行われる（図１５に示すＳＴ１４０８）。
【０１３０】
次に、図１３及び図１５に示すＭＳＣ／ＭＧＷ１３００のコーデック選択部１５１０におけるコーデックの選択方法の一例を図１６に示す。
【０１３１】
図１６に示すＳＴ１６００において、コーデック選択部１５１０は、端末位置判断部１５０８の判断結果に基づいて、通信中の双方の端末（ＵＥ１００，１０２）がＣＳ網に移動（存在）しているか否かを判断する。
【０１３２】
通信中の双方の端末がＣＳ網に移動している場合（ＳＴ１６００：ＹＥＳ）、ＳＴ１６０２において、コーデック選択部１５１０は、受信部１５００で受け取ったＩＭＳシグナリングに、通信相手端末（ＵＥ１０２）がＣＳ網で使用するコーデック情報（コーデックのリスト）が含まれるか否かを判断する。
【０１３３】
ＩＭＳシグナリングに通信相手端末がＣＳ網で使用するコーデック情報が含まれる場合（ＳＴ１６０２：ＹＥＳ）、ＳＴ１６０４において、コーデック選択部１５１０は、通信相手端末（ＵＥ１０２）がＣＳ網で使用するコーデック情報が、自網側の端末（ＵＥ１００）が使用中のコーデックと一致するか否かを判断する。上記コーデック情報が自網側の端末（ＵＥ１００）が使用中のコーデックと一致する場合、ＳＴ１６１４の処理に進む。
【０１３４】
通信中の双方の端末がＣＳ網に移動していない場合（ＳＴ１６００：ＮＯ）、ＳＴ１６０６において、コーデック選択部１５１０は、自装置（ＭＳＣ／ＭＧＷ１３００）が、ＰＳ網で使用されているコーデックに対応するか否かを判断する。自装置（ＭＳＣ／ＭＧＷ１３００）が、ＰＳ網で使われているコーデックに対応しない場合（ＳＴ１６０６：ＮＯ）、ＳＴ１６１２の処理に進む。
【０１３５】
ＩＭＳシグナリングに通信相手端末がＣＳ網で使用するコーデック情報が含まれない場合（ＳＴ１６０２：ＮＯ）、又は、自装置（ＭＳＣ／ＭＧＷ１３００）が、ＰＳ網で使われているコーデックに対応する場合、ＳＴ１６０８において、コーデック選択部１５１０は、ＩＭＳシグナリング（ＳＤＰオファー）によってオファーされているコーデック情報（コーデックリスト）の中に、現在自網側のＵＥ（ＵＥ１００）が使用中のコーデックが含まれるか否かを判断する。オファーされているコーデックリストの中に、現在自網側のＵＥ（ＵＥ１００）が使用中のコーデックが含まれる場合（ＳＴ１６０８：ＹＥＳ）、ＳＴ１６１４の処理に進む。
【０１３６】
オファーされているコーデックリストの中に、現在自網側のＵＥ（ＵＥ１００）が使用中のコーデックが含まれない場合（ＳＴ１６０８：ＮＯ）、ＳＴ１６１０において、コーデック選択部１５１０は、ＩＭＳシグナリング（ＳＤＰオファー）によってオファーされているコーデックリストの中に、自装置（ＭＳＣ／ＭＧＷ１３００）がサポートしているコーデックが含まれるか否かを判断する。オファーされているコーデックリストの中に、自装置がサポートしているコーデックが含まれる場合（ＳＴ１６１０：ＹＥＳ）、ＳＴ１６１６の処理に進む。オファーされているコーデックリストの中に、自装置がサポートしているコーデックが含まれない場合（ＳＴ１６１０：ＮＯ）、ＳＴ１６１８の処理に進む。
【０１３７】
ＳＴ１６１２では、コーデック選択部１５１０は、ＰＳ網で使用されているコーデックを選択する。
【０１３８】
ＳＴ１６１４では、コーデック選択部１５１０は、自網側の端末（ＵＥ１００）が使用中のコーデックを、使用するコーデックとして選択する。
【０１３９】
ＳＴ１６１６では、コーデック選択部１５１０は、オファーされているコーデックリストのうち、自装置（ＭＳＣ／ＭＧＷ１３００）がサポートしているコーデックの中から、使用するコーデックを選択する。
【０１４０】
ＳＴ１６１８では、コーデック選択部１５１０は、エラーを選択する。
【０１４１】
このようにして、ＭＳＣ／ＭＧＷ１３００，１３０２は、ハンドオーバにより発生したＩＭＳシグナリングの中に、自網側のＣＳ網でサポートしているコーデックのリストを含める。また、上記ＩＭＳシグナリングを受け取ると、ＭＳＣ／ＭＧＷ１３００（ＭＳＣ／ＭＧＷ１３０２）は、まず、通信中の双方の端末がＣＳ網に存在すると判断する。更に、ＭＳＣ／ＭＧＷ１３００（ＭＳＣ／ＭＧＷ１３０２）は、ＩＭＳシグナリングの送信先のＭＳＣ／ＭＧＷが属するＣＳ網でサポートされているコーデック情報を用いて、利用するコーデックを選択する。具体的には、ＭＳＣ／ＭＧＷ１３００，１３０２は、通信中の双方の端末（ＵＥ１００，１０２）が同一のコーデックを使用可能な場合には、双方の端末で当該同一のコーデックが使用されるように、利用するコーデックを選択する。
【０１４２】
すなわち、一方の端末（ＵＥ１００）がＣＳ網にハンドオーバし、他方の端末（ＵＥ１０２）がＣＳ網にハンドオーバした場合において、例えば、ＵＥ１００側のＣＳ網に属するＭＳＣ／ＭＧＷ１３００は、ＵＥ１０２側のＣＳ網に属するＭＳＣ／ＭＧＷ１３０２から、ＵＥ１０２側のＣＳ網でサポートしているコーデックリスト（コーデック群）を含むメッセージを受信し、上記コーデックリスト、及び、ＵＥ１００が使用するコーデック（変更後のコーデック）を用いて、ＵＥ１０２が使用するコーデックを選択する。例えば、ＭＳＣ／ＭＧＷ１３００は、受信したコーデックリストに、ＵＥ１００が使用するコーデック（変更後のコーデック）が含まれる場合、ＵＥ１０２が使用するコーデックとして、ＵＥ１００が使用するコーデックを選択する。
【０１４３】
これにより、双方の端末（ＵＥ１００，１０２）では、可能であれば同一コーデックが使用されるので、ＭＳＣ／ＭＧＷ１３００，１３０２では、トランスコーディングが行われない。よって、本実施の形態によれば、通信中のＵＥ１００及びＵＥ１０２の双方がＳＲＶＣＣハンドオーバを行った場合でも、ＭＳＣ／ＭＧＷ１３００，１３０２における、トランスコーディングを最小限に抑えることができる。
【０１４４】
また、実施の形態１では、ＭＳＣ／ＭＧＷ３００がコーデック帯域幅の変更を検出し、ＵＥ１０２に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する方法について説明した。これに対して、本実施の形態では、ＭＳＣ／ＭＧＷ１３００，１３０２は、自網側の端末がＣＳ網で使うコーデック情報を得た後、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングに代えて、当該コーデック情報をＩＭＳシグナリングの中に明示的に含めて通信相手側端末に送信する。この場合でも、実施の形態１と同様、一方又は双方のＵＥのネットワーク状況が変わった場合でも、ＵＥ間のコーデックの帯域幅を同等に維持することができる。
【０１４５】
なお、端末位置判断部１５０８により、ＵＥ１００、１０２の双方ともＣＳ網に存在すると判断された場合、経路選択部１５１２は、ネットワーク側の経路を全てＣＳ網用の経路に切り替えてもよい。端末位置判断部１５０８は、この判断方法として、例えば両方の端末がｒＳＲＶＣＣに対応しているか否かで判断してもよい。すなわち、両方の端末（ＵＥ１００，１０２）がｒＳＲＶＣＣに対応していない場合、経路選択部１５１２は、ネットワーク側の経路をＣＳ網用の経路に切り替えてもよい。なお、両方の端末がｒＳＲＶＣＣに対応しているかどうかに関しては、非特許文献３に記載の、ＳＲＶＣＣサポートの登録又はＳＲＶＣＣサポートしているか否かの入手方法と同等の方法で実現できる。
【０１４６】
また、端末（例えば図１７に示すＵＥ１０２）は、エンコードされる入力信号の帯域幅の制限を依頼するシグナリング等の受信により、通信相手側端末（例えば図１７に示すＵＥ１００）がＳＲＶＣＣによるハンドオーバを行ったことを判断した場合、自装置がＳＲＶＣＣによるハンドオーバを行う際のシグナリング（図１５に示すＳＴ２００又はＳＴ２０４）によって、自網側ＭＳＣ／ＭＧＷ（例えば、図１７に示すＭＳＣ／ＭＧＷ１３１０）に対し、通信相手側端末（ＵＥ１００）が既にＳＲＶＣＣによるハンドオーバを行っていることを通知してもよい。これにより、ＭＳＣ／ＭＧＷ１３１０の端末位置判断部１５０８は、双方の端末（ＵＥ１００，１０２）がＣＳ網にハンドオーバしたと判断し、ＩＭＳシグナリング（ＳＤＰオファー）のコーデックリストの中に、ＰＳ網のみでサポートしているコーデックを含めることを回避できる。つまり、ＭＳＣ／ＭＧＷ１３１０は、ＣＳ網でサポートしているコーデックのみをＳＤＰオファーに含めることができる（図１７参照）。この際、ＭＳＣ／ＭＧＷ１３１０は、自装置がＭＧＷであることを明示的に伝えてもよい（例えば図１７参照）。また、上記通知を受け取ったＭＳＣ／ＭＧＷ１３００は、ＣＳ網同士で通信することを決定してもよい（例えば図１７参照）。また、上記通知は、例えば、ＵＥ１０２がＣＳ網にハンドオーバした際にＵＥ１０２から送信される既存のシグナリングに含まれてもよいし、新しいシグナリングでもよい。また、上記通知は、ＵＥ１０２がＣＳ網にハンドオーバする以前に、ＭＭＥ（図示せず）に対して送信されるシグナリングに含まれてもよい（例えば、非特許文献４参照）。
【０１４７】
（実施の形態４）
本実施の形態では、通信を行う双方のＵＥがｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へのハンドオーバを行う場合、又は、一方のＵＥがｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行い、他方のＵＥがＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行う場合について説明する。本実施の形態では、ｅＳＲＶＣＣ方式において、通信データはＡＴＧＷでアンカーされ、ＡＴＧＷにおいてトランスコーディングが行われると仮定する。
【０１４８】
図１８は、本発明の実施の形態４に係る移動通信ネットワークの一部を示す構成である。なお、図１８に示す各ノードの動作は前述（例えば図３及び図５）した通りである。
【０１４９】
図１８において、ＵＥ１００及びＵＥ１０２の双方は、最初ｅ−ＵＴＲＡＮに存在し、ＰＳ網でＶｏＬＴＥ通信を行っている。この際、上述したコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）が使用されていると仮定する。図１８では、ＵＥ１００側のネットワーク、及び、ＵＥ１０２側のネットワークの双方ともｅＳＲＶＣＣに対応していると仮定する。これより、ＵＥ１００とＵＥ１０２との間の現在の通信経路は、ＡＴＣＦ／ＡＴＧＷ１７００及びＡＴＣＦ／ＡＴＧＷ１７０２を経由した、Ｐａｔｈ  Ａ、Ｐａｔｈ  Ｂ及びＰａｔｈ  Ｃとなる。
【０１５０】
なお、図１８では、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２を一つのノードとして表しているが、別々のノードでもよい。また、図１８において、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＵＥ１００とＵＥ１０２との間の通信経路としてＡＴＣＦ／ＡＴＧＷ１７００及びＰａｔｈ  Ｂは存在しないので、Ｐａｔｈ  Ａは、ＵＥ１００とＡＴＣＦ／ＡＴＧＷ１７０２との間に確立される。同様に、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合には、通信経路としてＡＴＣＦ／ＡＴＧＷ１７０２及びＰａｔｈ  Ｂは存在しないので、Ｐａｔｈ  Ｃは、ＵＥ１０２とＡＴＣＦ／ＡＴＧＷ１７００との間に確立される。
【０１５１】
次に、ＵＥ１００、ＵＥ１０２のそれぞれがｅＳＲＶＣＣによりハンドオーバを行ったとする。この場合、非特許文献３によると、ハンドオーバ後のＵＥ１００とＵＥ１０２との間の通信経路は、ＭＳＣ／ＭＧＷ１７０４、ＡＴＣＦ／ＡＴＧＷ１７００、ＡＴＣＦ／ＡＴＧＷ１７０２及びＭＳＣ／ＭＧＷ１７０６を経由した、Ｐａｔｈ  Ｄ、Ｐａｔｈ  Ｅ、Ｐａｔｈ  Ｂ、Ｐａｔｈ  Ｇ、及びＰａｔｈ  Ｆとなる。
【０１５２】
なお、図１８において、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＵＥ１００とＵＥ１０２との間の通信路としてＡＴＣＦ／ＡＴＧＷ１７００及びＰａｔｈ  Ｂは存在しないので、Ｐａｔｈ  ＥはＭＳＣ／ＭＧＷ１７０４とＡＴＣＦ／ＡＴＧＷ１７０２との間に確立される。同様に、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＵＥ１００とＵＥ１０２との間の通信経路としてＡＴＣＦ／ＡＴＧＷ１７０２及びＰａｔｈ  Ｂは存在しないので、Ｐａｔｈ  Ｇは、ＭＳＣ／ＭＧＷ１７０６とＡＴＣＦ／ＡＴＧＷ１７００との間に確立される。
【０１５３】
ここで、例えばＵＥ１００，１０２がＣＳ網にハンドオーバした際に使用するコーデックを双方ともＡＭＲ−ＷＢであるとする。この場合、ＵＥ１００からＡＴＣＦ／ＡＴＧＷ１７００までの通信データはＡＭＲ−ＷＢでエンコードされる。次いで、ＡＴＧＷ１７００はＡＭＲ−ＷＢからコーデックＡにトランスコーディングを行う。よって、ＡＴＧＷ１７００からＡＴＧＷ１７０２までの間の通信データはコーデックＡでエンコードされる。次いで、ＡＴＧＷ１７０２は再びコーデックＡからＡＭＲ−ＷＢにトランスコーディングを行う。よって、ＡＴＧＷ１７０２からＵＥ１０２までの間の通信データはＡＭＲ−ＷＢでエンコードされる。
【０１５４】
なお、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＡＴＧＥ１７００の代わりにＭＳＣ／ＭＧＷ１７０４でトランスコーディングが行われる。同様に、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＡＴＧＥ１７０２の代わりにＭＳＣ／ＭＧＷ１７０６でトランスコーディングが行われる。
【０１５５】
本実施の形態では、通信中のＵＥ１００及びＵＥ１０２の双方がｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へのハンドオーバを行う場合、又は、一方のＵＥがｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行い、他方のＵＥがＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行う場合について、実施の形態３と同様、トランスコーディングを最小限に抑える方法について説明する。
【０１５６】
まず、図１８に示すＡＴＣＦ／ＡＴＧＷ１７００、１７０２、及び、ＵＥ１００、１０２について説明する。
【０１５７】
図１９は、本実施の形態に係るＡＴＣＦ／ＡＴＧＷ１７００、１７０２の構成を示すブロック図である。なお、図１９に示すＡＴＣＦ／ＡＴＧＷ１７００、１７０２は、図示される機能ブロックの他に、図８に示される機能ブロック又はその他機能ブロックを具備していてもよい。
【０１５８】
図１９に示すＡＴＣＦ／ＡＴＧＷ１７００、１７０２において、受信部１９００は、通信データ、シグナリング等を受信する。
【０１５９】
送信部１９０２は、通信データ、シグナリング等を送信する。
【０１６０】
シグナリング解析部１９０４は、ＳＲＶＣＣ処理又はｅＳＲＶＣＣ処理のためのシグナリング、又は、ＩＭＳのシグナリング（ＩＭＳシグナリング）等を解析する。シグナリング解析部１９０４は、シグナリング解析の結果を、シグナリング生成部１９０６、端末位置判断部１９０８及びコーデック選択部１９１０に通知する。
【０１６１】
シグナリング生成部１９０６は、シグナリング解析部１９０４のシグナリング解析結果等に基づいて、シグナリングを生成する。
【０１６２】
端末位置判断部１９０８は、シグナリング解析部１９０４のシグナリング解析結果に基づいて、通信中の双方の端末（ＵＥ１００、１０２）がＰＳ網に存在するのか、ＣＳ網に存在するのかを判断する。端末位置判断部１９０８は、判断結果をコーデック選択部１９１０及び経路選択部１９１２に出力する。
【０１６３】
コーデック選択部１９１０は、シグナリング解析部１９０４のシグナリング解析結果及び端末位置判断部１９０８の判断結果に基づいて、利用するコーデック、又はコーデック候補を選択する。
【０１６４】
経路選択部１９１２は、端末位置判断部１９０８の判断結果に基づいて、通信データが通る経路を選択する。
【０１６５】
図２０は、本実施の形態に係るＵＥ１００、１０２の構成を示すブロック図である。ＵＥ１００、１０２は、図示される機能ブロックの他に、図１２に示される機能ブロック又はその他機能ブロックを具備していてもよい。なお、図２０に示すＵＥ１００，１０２において、受信部７００及び送信部７０２は、図１２と同一動作を行う構成部であり、その説明を省略する。
【０１６６】
図２０に示すＵＥ１００、１０２において、通信相手コーデック変更検出部２０００は、通信相手が使用しているコーデックが変更になったことを検出する。通信相手が使用しているコーデックが変更される理由には、例えば、ＰＳ網からＣＳ網に移動したことが挙げられる。また、通信相手コーデック変更検出部２０００におけるコーデック変更の検出方法は、例えば、実施の形態１で示したような、帯域制限通知等のシグナリングをネットワークから受け取る方法、及び、実施の形態２で示したような、通信相手が使用しているコーデックの帯域が制限されたことを検出する方法等が挙げられる。
【０１６７】
シグナリング生成部２００２は、通信相手コーデック変更検出部２０００で通信相手のコーデックが変更になったことが検出された場合、通信相手のコーデックが変更されたことをネットワークに通知するためのシグナリングを生成する。
【０１６８】
次に、本実施の形態におけるＵＥ１００，１０２、及び、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２の動作の一例について説明する。ここでは、ＵＥ１００側のネットワーク、及び、ＵＥ１０２側のネットワークの双方がｅＳＲＶＣＣに対応していると仮定する。
【０１６９】
図２１は、図１８に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。
【０１７０】
ＵＥ１００及びＵＥ１０２は、ｅ−ＵＴＲＡＮに接続処理を行い、ＩＭＳに対してＶｏＬＴＥに関する登録をする際、例えば、ＡＴＣＦ（ＡＴＣＦ／ＡＴＧＷ１７００，１７０２）に関する情報をＳＣＣ  ＡＳ、ＨＳＳ（図示せず）又はＭＭＥ（図示せず）に送信し、送信先で当該情報が保持される（例えば、非特許文献５参照）。更に、発呼の際（本実施の形態では、ＵＥ１００からＵＥ１０２への発呼と仮定する。ＵＥ１０２からＵＥ１００への発呼の場合も同様である。）には、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２において、ＡＴＣＦは、ＡＴＧＷでセッションをアンカーするかどうかを判断する（例えば、非特許文献３又は非特許文献５を参照）。
【０１７１】
その後、ＵＥ１００及びＵＥ１０２は、共にｅ−ＵＴＲＡＮに接続し、ＶｏＬＴＥ通信を行っている。この時、音声コーデックとして、前述のコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）が使用されているものとする（図２１に示すＳＴ１８００）。
【０１７２】
次いで、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバする。このとき、図１０に示すＳＴ２００の処理（ＳＲＶＣＣ処理）及びＳＴ２０４の処理（コネクション確立処理）と同等の処理が行われる。また、ＳＴ２００の処理及びＳＴ２０４の処理と同時に、図４に示すＳＴ１１０２の処理と同等の処理が行われる。これにより、ＵＥ１００とＵＥ１０２との間のデータ通信経路がＭＳＣ／ＭＧＷ１７０４経由に切り替わる（図２１に示すＳＴ１８０２）。
【０１７３】
この際、ＡＴＣＦ／ＡＴＧＷ１７００のシグナリング生成部１９０６は、ＵＥ１００がＣＳ網で使用するコーデック（例えばＡＭＲ）を含むメッセージを生成し、当該メッセージを送信部１９０２を介して、ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８に通知する（図２１に示すＳＴ１８０２’）。この通知は非特許文献３に記載のAccess Transfer Updateメッセージと共に通知されてもよい。この後、実施の形態１で示したように、ＡＴＣＦ／ＡＴＧＷ１７００は、ＵＥ１０２に対して帯域制限通知を送信してもよい。
【０１７４】
ＵＥ１０２の通信相手コーデック変更検出部２０００は、ＵＥ１００のコーデックがコーデックＡから変更になったことを検出する（図２１に示すＳＴ１８０４）。
【０１７５】
次に、ＵＥ１０２もＰＳ網からＣＳ網にハンドオーバする。このとき、ＵＥ１０２のシグナリング生成部２００２は、通信相手であるＵＥ１００のコーデックが変更になっていることをネットワークに通知するためのシグナリングを生成する。このシグナリングは、例えば、ＵＥ１０２がＣＳ網にハンドオーバした際に、ＵＥ１０２から送信される既存のシグナリングに含まれてもよく、新しいシグナリングに含まれてもよい（図２１に示すＳＴ１８０６）。また、上記通知は、ＵＥ１０２がＣＳ網にハンドオーバする以前に、ＭＭＥ（図示せず）に対し送信されるシグナリングに含まれ、ＭＭＥからＭＳＣ／ＭＧＷ１７０６に通知されてもよい（例えば、非特許文献４参照）。
【０１７６】
ＵＥ１０２からのシグナリングを受け取ったＭＳＣ／ＭＧＷ１７０６は、ＵＥ１０２の通信相手であるＵＥ１００のコーデックが変更になっていることを検知し、ＵＥ１００のコーデックが変更になっていることを示す情報を、ＡＴＣＦ／ＡＴＧＷ１７０２に送信するＩＮＶＩＴＥメッセージに含める。
【０１７７】
このＩＮＶＩＴＥメッセージを受け取ったＡＴＣＦ／ＡＴＧＷ１７０２のシグナリング解析部１９０４は、ＵＥ１０２の通信相手であるＵＥ１００のコーデックが変更になっていることを検出する。そこで、ＡＴＣＦ／ＡＴＧＷ１７０２のシグナリング生成部１９０６は、ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８に対して、ＵＥ１００のコーデック問い合わせのためのシグナリングを生成し、当該シグナリングを送信部１９０２を介して送信する（図２１に示すＳＴ１８０８）。
【０１７８】
ＡＴＣＦ／ＡＴＧＷ１７０２の受信部１９００は、ＳＴ１８０８で送信したシグナリングに対する返信シグナリングをＳＣＣ  ＡＳ／ＣＳＣＦ１７０８から受け取る。そして、ＡＴＣＦ／ＡＴＧＷ１７０２のシグナリング解析部１９０４は、この返信シグナリングを解析し、解析結果（ＵＥ１００のコーデックに関する情報）に基づいて、ＡＴＣＦ／ＡＴＧＷ１７００との間でコーデック折衝を行い（図２１に示すＳＴ１８１０）、コーデックを選択する（図２１に示すＳＴ１８１２）。なお、コーデック折衝は、ＡＴＣＦ／ＡＴＧＷ１７０２とＳＣＣ  ＡＳ／ＣＳＣＦ１７０８との間、及び、ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８とＡＴＣＦ／ＡＴＧＷ１７００との間で行われてもよい（すなわち、ＳＣＣ  ＡＳでアンカーしてもよい）。なお、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８を介さずに、コーデック折衝を行ってもよい。この場合、図２１に示すＳＴ１８０２の処理及びＳＴ１８０８の処理は不要となる。
【０１７９】
このようにして、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、端末（ＵＥ１００，１０２）がハンドオーバした場合、ハンドオーバした端末がＣＳ網で使用するコーデックを含むメッセージを生成し、当該メッセージをＳＣＣ  ＡＳ／ＣＳＣＦ１７０８に通知する。この場合、ハンドオーバした端末と通信している通信相手端末は、ハンドオーバした端末のコーデックが変更されたことを検出している。また、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、ハンドオーバした端末のコーデックが変更されたことを検出している通信相手端末もハンドオーバした場合、当該通信相手端末からの通知によって、最初にハンドオーバした端末のコーデックが変更になっていることを検出すると、ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８に対して、当該通信相手のコーデック問い合わせを行う。そして、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、問い合わせにより得たコーデック（最初にハンドオーバした端末のコーデック）に関する情報に基づいて、コーデック折衝を行い、コーデックを選択する。例えば、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、通信中の双方の端末（ＵＥ１００，１０２）が同一のコーデックを使用可能な場合には、双方の端末で当該同一のコーデックが使用されるように、利用するコーデックを選択する。
【０１８０】
すなわち、一方の端末（ＵＥ１００）がＣＳ網にハンドオーバした後に、他方の端末（ＵＥ１０２）がＣＳ網にハンドオーバした場合において、ＡＴＣＦ／ＡＴＧＷ１７０２は、ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８への問い合わせにより、ＵＥ１００が使用するコーデック（変更後のコーデック）を含むメッセージを受信し、ＵＥ１０２側のＭＳＣ／ＭＧＷ１７０６から、ＵＥ１００がＣＳ網にハンドオーバしたことを示す情報を含むメッセージを受信し、ＵＥ１００がＣＳ網にハンドオーバしたことを示す情報を受信した場合、上記ＵＥ１００が使用するコーデックに基づいて、ＵＥ１０２が使用するコーデックを選択する。
【０１８１】
これにより、双方の端末（ＵＥ１００，１０２）では、実施の形態３と同様、可能であれば同一コーデックが使用されるので、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２では、トランスコーディングが行われない。よって、本実施の形態によれば、通信中のＵＥ１００及びＵＥ１０２の双方がｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へのンドオーバを行う場合、実施の形態３と同様、トランスコーディングを最小限に抑えることができる。
【０１８２】
なお、端末位置判断部１９０８により、ＵＥ１００、１０２の双方ともＣＳ網に存在すると判断された場合、経路選択部１９１２は、ネットワーク側の経路を全てＣＳ網用の経路に切り替えてもよい。端末位置判断部１９０８は、この判断方法として、例えば両方の端末がｒＳＲＶＣＣに対応しているか否かで判断してもよい。すなわち、両方の端末（ＵＥ１００，１０２）がｒＳＲＶＣＣに対応していない場合、経路選択部１９１２は、ネットワーク側の経路をＣＳ網用の経路に切り替えてもよい。なお、両方の端末がｒＳＲＶＣＣに対応しているかどうかに関しては、非特許文献３に記載の、ＳＲＶＣＣサポートの登録又はＳＲＶＣＣサポートしているか否かの入手方法と同等の方法で実現できる。
【０１８３】
また、端末（例えば図２１に示すＵＥ１０２）は、エンコードされる入力信号の帯域幅の制限を依頼するシグナリング等の受信により、通信相手側端末（例えば図２１に示すＵＥ１００）がＳＲＶＣＣ又はｅＳＲＶＣＣによるハンドオーバを行ったことを判断した場合、自装置がｅＳＲＶＣＣによるハンドオーバを行う際のシグナリング（図２１に示すＳＴ２００／ＳＴ２０４）によって、自網側ＭＳＣ／ＭＧＷ（例えば、図２１に示すＭＳＣ／ＭＧＷ１７０６）に対し、通信相手側端末（ＵＥ１００）が既にＳＲＶＣＣ又はｅＳＲＶＣＣによるハンドオーバを行っていることを通知してもよい。これにより、ＭＳＣ／ＭＧＷ１７０６の端末位置判断部１９０８は、双方の端末（ＵＥ１００，１０２）がＣＳ網にハンドオーバしたと判断し、ＩＭＳシグナリング（ＳＤＰオファー）のコーデックリストの中に、ＰＳ網のみでサポートしているコーデックを含めることを回避できる。この通知は、例えば、ＵＥ１０２がＣＳ網にハンドオーバした際にＵＥ１０２から送られる既存のシグナリングに含まれてもよいし、新しいシグナリングでもよい（図２１に示すＳＴ１８０６）。また、上記通知は、ＵＥ１０２がＣＳ網にハンドオーバする以前に、ＭＭＥ（図示せず）に対し送信されるシグナリングに含まれてもよい（例えば、非特許文献４参照）。
【０１８４】
また、図１９に示すように、ＭＳＣ／ＭＧＷ１７０４，１７０６は、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２と同等の機能を具備してもよい。図１８において、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合、ＭＳＣ／ＭＧＷ１７０４のシグナリング解析部１９０４は、ＵＥ１００がＣＳ網にハンドオーバした際、ＣＳ網で使用するコ−デックを含むシグナリングを解析し、ＵＥ１００がＣＳ網で使用するコーデックの情報を得る。次いで、ＭＳＣ／ＭＧＷ１７０４のシグナリング生成部１９０６は、ＵＥ１００がＣＳ網で使用するコーデックの情報を生成し、ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８に通知する。この通知は、ＩＮＶＩＴＥメッセージに含まれてもよい。また、図１８において、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合、ＭＳＣ／ＭＧＷ１７０６のシグナリング解析部１９０４は、ＵＥ１０２から、通信相手であるＵＥ１００のコーデックが変更になっていることを通知する内容を含むシグナリングを受け取った際、ＵＥ１０２の通信相手であるＵＥ１００のコーデックが変更になっていることを検知する。次いで、ＭＳＣ／ＭＧＷ１７０６のシグナリング生成部１９０６は、ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８に対してＵＥ１００のコーデックを問い合わせるシグナリングを生成し、ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８に送信する。ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８より返信シグナリングを受け取ると、ＭＳＣ／ＭＧＷ１７０６のシグナリング解析部１９０４は、この返信シグナリングを解析し、解析結果に基づいて、ＵＥ１００側でトランスコーディングを行うノード（ＭＳＣ／ＭＧＷ１７０４又はＡＴＣＦ／ＡＴＧＷ１７００）との間でコーデック折衝を行い、コーデックを選択する。なお、コーデック折衝は、ＭＳＣ／ＭＧＷ１７０６とＳＣＣ  ＡＳ／ＣＳＣＦ１７０８との間、及び、ＳＣＣ  ＡＳ／ＣＳＣＦ１７０８とＵＥ１００側でトランスコーディングを行うノードとの間で行われてもよい（すなわち、ＳＣＣ  ＡＳでアンカーしてもよい）。これにより、一方のＵＥがｅＳＲＶＣＣ方式により、他方のＵＥがＳＲＶＣＣ方式によって、ＰＳ網からＣＳ網へハンドオーバを行う場合でも、実施の形態３と同様、トランスコーディングを最小限に抑えることができる。
【０１８５】
（実施の形態５）
実施の形態１、３及び４では、ＭＳＣ／ＭＧＷ又はＡＴＣＦ／ＡＴＧＷが、セッション途中における片方のＵＥの通信データの帯域幅の変更を検出した場合、もう片方のＵＥに対し帯域制限通知を行う方法を説明した。これに対して、本実施の形態では、帯域制限通知を送る代わりに、又は帯域制限通知を送る事に加え、ＭＳＣ／ＭＧＷ又はＡＴＣＦ／ＡＴＧＷが送る通信データ、又は通信データのＲＴＰペイロードのヘッダ部に帯域情報を明示的に含める方法を説明する。
【０１８６】
例えば、実施の形態１において、ＭＳＣ／ＭＧＷ３００のコーデック帯域幅検出部６０６でＵＥ１００の帯域幅変更を検出し、変更判断部６０８でＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であり、かつ、帯域幅制限が必要であると判断された場合、ＭＳＣ／ＭＧＷ３００からＵＥ１０２へ送られる通信データの帯域幅も制限する。この際、ＭＳＣ／ＭＧＷ３００が送る通信データそのもの、又は通信データが格納されるＲＴＰのペイロードヘッダ部に、明示的に変更後の帯域幅情報を含める。
【０１８７】
ＲＴＰペイロードヘッダ部に変更後の帯域情報を含める場合、帯域情報を含めるパケットは、帯域変更後のある一定期間（例えば２００ｍｓｅｃ）に送られるパケット、又はある一定個数のパケット（例えば１０パケット）に限る。
【０１８８】
受信側（ＵＥ１０２）では、ある一定期間以上（例えば１５０ｍｓｅｃ以上）又はある特定個数（例えば５パケット以上）のＲＴＰのペイロードヘッダに帯域情報が付加されている事を検出すると、その後送られてくるＲＴＰペイロードヘッダに帯域情報が付加されていなかった場合においても、格納されている通信データの帯域幅が制限され続けると判断する。
【０１８９】
帯域制限通知を受け取ったＵＥ１０２が、帯域を制限した通信データをＭＧＷ３００に送信する場合においても同様に、ある一定期間（例えば２００ｍｓｅｃ）に送られるパケット、又はある一定個数のパケット（例えば１０パケット）のＲＴＰペイロードヘッダ部に帯域情報を付加する。受信側（ＭＧＷ３００）では、ある一定期間以上（例えば１５０ｍｓｅｃ以上）又はある特定個数（例えば５パケット以上）のＲＴＰのペイロードヘッダに帯域情報が付加されている事を検出すると、その後送られてくるＲＴＰペイロードヘッダに帯域情報が付加されていなかった場合においても、格納されている通信データの帯域幅が制限され続けると判断する。
【０１９０】
また、実施の形態２において、帯域制限通知を受け取る代わりに、ＵＥ１０２のデータ解析部１２００において、データそのものの帯域幅が一定時間以上制限されている事を検出し、送信するデータの帯域を制限する方法を説明した。これに代えて、本実施の形態の上述の方法（ある一定期間以上（例えば１５０ｍｓｅｃ以上）又はある特定個数（例えば５パケット以上）のＲＴＰのペイロードヘッダに帯域情報が付加されている事）を用いて、コーデックモード変更部１２０２において、帯域の変更を決定してもよい。
【０１９１】
また、実施の形態１、３及び４において、帯域制限通知そのものを、ＲＴＰペイロードヘッダに含めてもよい。帯域制限通知をＲＴＰペイロードヘッダに含める場合においても、帯域制限通知を含めるパケットは、帯域変更通知が必要であると判定された後のある一定期間（例えば１００ｍｓｅｃ）に送られるパケット、又はある一定個数のパケット（例えば５パケット）に限る。受信側（ＵＥ１０２）では、ある一定期間以上（例えば２０ｍｓｅｃ以上）又はある特定個数（例えば１パケット以上）のＲＴＰのペイロードヘッダに帯域制限通知が付加されている事を検出すると、その後送られてくるＲＴＰペイロードヘッダに帯域制限通知が付加されていなかった場合においても、帯域幅の制限（変更）を依頼されていることが通知されたと判断する。尚、帯域制限通知をＲＴＰペイロードヘッダに含める場合には、帯域制限通知と共に上述の帯域情報を含めてもよい。
【０１９２】
これにより、送信データの帯域幅の変更を、セッション途中でも明示的に通信相手に通知する事ができる。
【０１９３】
以上、本発明の各実施の形態について説明した。
【０１９４】
なお、上記各実施の形態では、ＡＴＣＦ／ＡＴＧＷ、ＭＳＣ／ＭＧＷ、ＳＣＣ  ＡＳ／ＣＳＣＦをそれぞれ一つのノードとして説明したが、別々のノードでもよい。すなわち、ＡＴＣＦとＡＴＧＷとの間、ＭＳＣとＭＧＷとの間、及び、ＳＣＣ  ＡＳとＣＳＣＦとの間のそれぞれにおいて、上述した機能をいずれか一方若しくは両方が具備していればよい。また、ＡＴＣＦとＡＴＧＷとの間、ＭＳＣとＭＧＷとの間、及び、ＳＣＣ  ＡＳとＣＳＣＦとの間のそれぞれで必要な情報をやり取りしてもよい。
【０１９５】
また、上記各実施の形態において、ＵＥ１００及びＵＥ１０２の双方ともＣＳ網へのハンドオーバ（ＳＲＶＣＣ、ｅＳＲＶＣＣ等によるハンドオーバ）をサポートしている場合には、ＰＳ網上でのセッション折衝の際、ＣＳ網でサポートされているコーデック若しくはＣＳ網でサポートされているコーデックと互換性のあるコーデックが初めから選択されてもよい。
【０１９６】
また、上記各実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、これに限らず、音楽、音響、画像等に関しても、本発明は適用可能である。
【０１９７】
また、本発明は、上記各実施の形態に限定されず、種々変更して実施することが可能である。
【０１９８】
また、上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。
【０１９９】
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０２００】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）または、ＬＳＩ内部の回路セルの接続若しくは設定を再構成可能なリコンフィギュラブル／プロセッサを利用してもよい。
【０２０１】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【０２０２】
２０１１年６月９日出願の特願２０１１−１２９４２２、２０１１年１１月１１日出願の特願２０１１−２４７３３０および２０１２年２月１５日出願の特願２０１２−０３０４１９の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【０２０３】
本発明は、通信中の通信端末の一方が利用するコーデックが変更になった場合、通信相手の利用するコーデックのエンコードされる入力信号の帯域幅又はエンコーディングビットレートを調整する機能を有するため、トランスコーディングによる品質劣化を抑える事に有用である。
【符号の説明】
【０２０４】
１００，１０２  ＵＥ
２００，２０２，２０４，２０６，１１００，１１０２，１１０４，１１０６  シグナリング
３００，１３００，１３０２，１３１０，１７０４，１７０６  ＭＳＣ／ＭＧＷ
１１２０，１７００，１７０２  ＡＴＣＦ／ＡＴＧＷ
６００，７００，１５００，１９００  受信部
６０２，７０２，１５０２，１９０２  送信部
６０４  コーデック検出部
６０６  コーデック帯域幅検出部
６０８  変更判断部
６１０，１５０６，１９０６，２００２  シグナリング生成部
６１２  トランスコーディング部
７０４  コーデック折衝部
７０６，１５１０，１９１０  コーデック選択部
７０８  帯域幅決定部
７１０，１５０４，１９０４  シグナリング解析部
７１２，１２０２  コーデックモード変更部
１２００  データ解析部
１５０８，１９０８  端末位置判断部
１５１２，１９１２  経路選択部
１７０８  ＳＣＣ  ＡＳ／ＣＳＣＦ
２０００  通信相手コーデック変更検出部
【図１】
0005947294.tif 000002
【図２】
0005947294.tif 000003
【図３】
0005947294.tif 000004
【図４】
0005947294.tif 000005
【図５】
0005947294.tif 000006
【図６】
0005947294.tif 000007
【図７】
0005947294.tif 000008
【図８】
0005947294.tif 000009
【図９】
0005947294.tif 000010
【図１０】
0005947294.tif 000011
【図１１】
0005947294.tif 000012
【図１２】
0005947294.tif 000013
【図１３】
0005947294.tif 000014
【図１４】
0005947294.tif 000015
【図１５】
0005947294.tif 000016
【図１６】
0005947294.tif 000017
【図１７】
0005947294.tif 000018
【図１８】
0005947294.tif 000019
【図１９】
0005947294.tif 000020
【図２０】
0005947294.tif 000021
【図２１】
0005947294.tif 000022