特許 6231160 通信端末装置、ネットワークノード及び通信方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6231160

(24)【登録日】2017年10月27日

(45)【発行日】2017年11月15日

(54)【発明の名称】通信端末装置、ネットワークノード及び通信方法

(51)【国際特許分類】

   H04W 76/04 20090101AFI20171106BHJP

   H04W 88/18 20090101ALI20171106BHJP

   H04M 1/00 20060101ALI20171106BHJP

   H04M 11/00 20060101ALI20171106BHJP

【ＦＩ】

   H04W76/04

   H04W88/18 110

   H04M1/00 R

   H04M11/00 302

【請求項の数】10

【全頁数】36

(21)【出願番号】特願2016-110022(P2016-110022)

(22)【出願日】2016年6月1日

(62)【分割の表示】特願2013-519368(P2013-519368)の分割

【原出願日】2012年5月25日

(65)【公開番号】特開2016-181919(P2016-181919A)

(43)【公開日】2016年10月13日

【審査請求日】2016年6月1日

(31)【優先権主張番号】特願2011-129422(P2011-129422)

(32)【優先日】2011年6月9日

(33)【優先権主張国】JP

(31)【優先権主張番号】特願2011-247330(P2011-247330)

(32)【優先日】2011年11月11日

(33)【優先権主張国】JP

(31)【優先権主張番号】特願2012-30419(P2012-30419)

(32)【優先日】2012年2月15日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100105050

【弁理士】

【氏名又は名称】鷲田 公一

(72)【発明者】

【氏名】堀 貴子

(72)【発明者】

【氏名】江原 宏幸

【審査官】 松野 吉宏

(56)【参考文献】

【文献】 国際公開第２００８／０１４０４５（ＷＯ，Ａ２）

【文献】 特表２００６−５００８０８（ＪＰ，Ａ）

【文献】 特開２００６−１５５６０２（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００８／０１３０５１１（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

Ｈ０４Ｍ １／００

Ｈ０４Ｍ １１／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

SDPオファーまたはSDPアンサーを含むIMSシグナリングを用いて、相手端末との通信に利用するコーデックを通信開始時に折衝するコーデック折衝部と、
前記折衝されたコーデックは複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を１つのセッションの中で変更可能なコーデックであって、
ネットワークノードから通知される、前記コーデックの入力信号の帯域幅およびビットレートの制限を指示するシグナリングに基づいて、前記相手端末との通信中に、前記コーデックの入力信号の帯域幅およびビットレートを制限する帯域幅決定部と、
を備える通信端末装置。

【請求項2】

通信開始時の折衝の際、前記折衝されるコーデックに対して入力信号の帯域幅(band width)が指定されない、
請求項１に記載の通信端末装置。

【請求項3】

前記コーデックの入力信号の帯域幅およびビットレートの制限を指示するシグナリングは、RTCP（Real-time Transport Control Protocol）に含まれる、
請求項１に記載の通信端末装置。

【請求項4】

前記コーデックの入力信号の帯域幅およびビットレートの制限を指示するシグナリングは、RTPペイロード（Real-time Transport Protocol）のヘッダに含まれる、
請求項１に記載の通信端末装置。

【請求項5】

第１の通信端末がSDPオファーまたはSDPアンサーを含むIMSシグナリングを用いて、通信相手である第２の通信端末との通信に利用するコーデックを通信開始時に折衝し、
前記折衝されたコーデックは複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を１つのセッションの中で変更可能なコーデックであって、
ネットワークノードから通知される、前記コーデックの入力信号の帯域幅およびビットレートの制限を指示するシグナリングに基づいて、前記第２の通信端末との通信中に、前記第１の通信端末は前記コーデックの入力信号の帯域幅およびビットレートを制限する、
通信方法。

【請求項6】

前記第１の通信端末は、前記第２の通信端末と通信開始時に折衝する際、前記第１の通信端末と前記第２の通信端末との間で折衝されるコーデックの入力信号の帯域幅(band width)を指定しない、
請求項５に記載の通信方法。

【請求項7】

前記コーデックの入力信号の帯域幅およびビットレートの制限を指示するシグナリングは、RTCP（Real-time Transport Control Protocol）に含まれるシグナリングである、
請求項５に記載の通信方法。

【請求項8】

前記コーデックの入力信号の帯域幅およびビットレートの制限を指示するシグナリングは、RTPペイロード（Real-time Transport Protocol）のヘッダに含まれるシグナリングである、
請求項５に記載の通信方法。

【請求項9】

異なるコーデックを使用する第１の通信端末装置と第２の通信端末装置との間の通信に対してトランスコーディングを行うネットワークノードであって、
前記第１の通信端末装置と前記第２の通信端末装置がそれぞれ使用するコーデックを検出する検出部と、
前記検出された前記第１の通信端末装置で使用される第１のコーデックは、複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を１つのセッションの中で変更可能なコーデックであって、
前記検出部での検出結果に基づいて、前記第２の通信端末装置が使用するコーデックの変更を検出した場合、前記第１の通信端末装置の前記第１のコーデック、及び、前記第２の通信端末装置の変更後の第２のコーデックを用いて、前記第１のコーデックの帯域幅およびビットレートの制限を行うか否かを判断する判断部と、
前記第１の通信端末装置と前記第２の通信端末装置との間の通信中に、前記第１のコーデックの帯域幅を制限すると判断した場合、前記帯域幅およびビットレートを制限させるためのシグナリングを、前記第１の通信端末装置へ送信する送信部と、
を備えるネットワークノード。

【請求項10】

異なるコーデックを使用する第１の通信端末装置と第２の通信端末装置との間の通信に対してトランスコーディングを行うネットワークノードの通信方法であって、
前記第１の通信端末装置と前記第２の通信端末装置がそれぞれ使用するコーデックを検出し、
前記検出された前記第１の通信端末装置で使用される第１のコーデックは、複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を１つのセッションの中で変更可能なコーデックであり、
前記検出結果に基づいて、前記第２の通信端末装置が使用するコーデックの変更を検出した場合、前記第１の通信端末装置の前記第１のコーデック、及び、前記第２の通信端末装置の変更後の第２のコーデックを用いて、前記第１のコーデックの帯域幅およびビットレートの制限を行うか否かを判断し、
前記第１の通信端末装置と前記第２の通信端末装置との間の通信中に、前記第１のコーデックの帯域幅を制限すると判断した場合、前記帯域幅およびビットレートを制限させるためのシグナリングを、前記第１の通信端末装置へ送信する、
通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、移動通信方式で用いられるコーデック変更を行う通信端末装置、ネットワークノード及び通信方法に関する。

【背景技術】

【0002】

従来、３ＧＰＰ（Third Generation Partnership Project）の移動通信方式における音声通話は、３ＧＰＰの回線交換（ＣＳ：Circuit Switching）網を用いて行われていた。近年では、３ＧＰＰのパケット交換（ＰＳ：Packet Switching）網を用いた音声通話であるＶｏＬＴＥ（Voice over Long Term Evolution）サービスが行われつつある。

【0003】

しかし、ＶｏＬＴＥサービスが受けられるエリアは当面の間限られる。このため、ＶｏＬＴＥによる音声通話（以下、ＶｏＬＴＥ通話という）中にＶｏＬＴＥサービスエリアの外に出た場合、従来の回線交換方式を用いた通話に切り替える必要がある。この切替を可能にする技術として、非特許文献１に記載のＳＲＶＣＣ（Single Radio Voice Call Continuity）がある。以下、図１及び図２を用いて、ＳＲＶＣＣによるハンドオーバの動作について説明する。

【0004】

図１は３ＧＰＰの移動通信ネットワーク構成の一部を示す。図１に示す移動通信ネットワークは、ｅ−ＵＴＲＡＮ（evolved Universal Terrestrial Radio Access Network）、ｅ−ＵＴＲＡＮの基地局（ｅ−ｎｏｄｅＢ）、ＰＳ網、ＣＳ網、ＣＳ網の基地局サブシステム、及びＩＭＳ（IP Multimedia Subsystem）から構成される。

【0005】

具体的には、図１において、ｅ−ＵＴＲＡＮは、ＶｏＬＴＥサービスを提供可能な無線アクセス網である。ＰＳ網は、ＶｏＬＴＥサービスを提供し、Ｐ−ＧＷ（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）から構成される。

【0006】

図１において、移動通信端末（ＵＥ：User Equipment）であるＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。つまり、ＵＥ１００とＵＥ１０２とでＶｏＬＴＥ通話が行われているとする。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。

【0007】

図１の実線で示されたＰａｔｈ Ａ、Ｐａｔｈ Ｂ及びＰａｔｈ Ｃは、通話データが通る経路を示す。また、図１の破線で示された２００、２０２、２０４及び２０６は、ＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。

【0008】

図２は、ＳＲＶＣＣハンドオーバ処理の動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ−ＵＴＲＡＮ）にそれぞれ接続されており、ＵＥ１００とＵＥ１０２との間の通話データはＰａｔｈ Ａを通って送受信されている。ＵＥ１００がｅ−ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ−ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図１に示すシグナリング２００。図２に示すステップ（以下、「ＳＴ」という）２００）。ＳＴ２００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷとの間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ−ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令が出される。

【0009】

ＳＴ２００の処理と同時に、ＭＳＣ／ＭＧＷは、ＣＳＣＦ／ＳＣＣ ＡＳ経由でＵＥ１０２とシグナリングをやり取りする（図１に示すシグナリング２０２。図２に示すＳＴ２０２）。これにより、ＵＥ１０２の通話データの送受信先を、ＵＥ１００からＭＳＣ／ＭＧＷに切り替えるよう命令が出され、Ｐａｔｈ Ｂが確立される。

【0010】

ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷとシグナリングをやり取りする（図１に示すシグナリング２０４。図２に示すＳＴ２０４）。これにより、Ｐａｔｈ Ｃが確立される。

【0011】

Ｐａｔｈ Ｃ確立後、ＭＳＣ／ＭＧＷは、ＭＭＥ経由でＰ−ＧＷ／Ｓ−ＧＷとシグナリングをやり取りする（図１に示すシグナリング２０６。図２に示すＳＴ２０６）。これにより、Ｐａｔｈ Ａは削除される。

【0012】

以上、ＳＲＶＣＣハンドオーバの動作について説明した。

【0013】

また、ＳＲＶＣＣを改良し、データ経路切替にかかる時間を短縮する方式として、非特許文献３に記載の、ＡＴＣＦ（Access Transfer Control Function）エンハンスメントを用いたＳＲＶＣＣ方式（ｅＳＲＶＣＣ：enhanced-SRVCC）がある。このｅＳＲＶＣＣの動作の一例について、以下、図３及び図４を用いて説明する。

【0014】

図３は、ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワーク構成の一部を示す。図３に示す移動通信ネットワークは、図１と同様、ｅ−ＵＴＲＡＮ、ｅ−ｎｏｄｅＢ、ＰＳ網、ＣＳ網、ＣＳ網の基地局サブシステム、及びＩＭＳから構成される。ここでＩＭＳには、ＣＳＣＦ及びＳＣＣ ＡＳの他、ＡＴＣＦ（Access Transfer Control Function）及びＡＴＧＷ（Access Transfer GateWay）が存在する。なお、図３及び図４では、ＡＴＣＦとＡＴＧＷとを一つのノード（ＡＴＣＦ／ＡＴＧＷ１１２０）として表しているが、これらは別々のノードとして表してもよい。

【0015】

図３において、ＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。つまり、ＵＥ１００とＵＥ１０２とでＶｏＬＴＥ通話が行われているとする。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。

【0016】

図３の実線で示されたＰａｔｈ Ａ、Ｐａｔｈ Ｂ、Ｐａｔｈ Ｃ及びＰａｔｈ Ｄは、通話データが通る経路を示す。また、図３の破線で示された１１００、１１０２、１１０４及び１１０６は、ｅＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。

【0017】

図４は、ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ−ＵＴＲＡＮ）にそれぞれ接続されている。ｅＳＲＶＣＣハンドオーバを実現するシステムでは、ＡＴＣＦ／ＡＴＧＷ１１２０において、ＡＴＣＦはＩＭＳのシグナリング（ＩＭＳシグナリング）をアンカーし、ＡＴＧＷは通話データをアンカーする。つまり、ＵＥ１００とＵＥ１０２との間の通話開始時において、通話開始のＩＭＳシグナリングはＡＴＣＦで中継され、ＡＴＣＦがＡＴＧＷでの通話データのアンカーが必要と判断した場合、通話データのアンカーポイントとしてＡＴＧＷが割り当てられる。これにより、ＵＥ１００とＵＥ１０２との間の通話データは、Ｐａｔｈ Ａ及びＰａｔｈ Ｂを通って送受信される。

【0018】

ＵＥ１００がｅ−ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ−ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図３に示すシグナリング１１００。図４に示すＳＴ１１００）。ＳＴ１１００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷとの間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ−ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令が出される。

【0019】

ＳＴ１１００の処理と同時に、ＭＳＣ／ＭＧＷは、ＡＴＣＦにシグナリングを送る。これによりＡＴＣＦからＡＴＧＷに経路切替の指示が出され、ＡＴＧＷの通話データ送受信先がＵＥ１００からＭＳＣ／ＭＧＷに切り替わる（図３に示すシグナリング１１０２。図４に示すＳＴ１１０２）。すなわち、Ｐａｔｈ Ｃが確立される。また、ＡＴＧＷへの経路切替処理が完了すると、ＡＴＣＦは、ＳＣＣ−ＡＳに通知シグナリングを送信する（図３に示すシグナリング１１０２。図４に示すＳＴ１１０２）。

【0020】

ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷとシグナリングをやり取りする（図３に示すシグナリング１１０４。図４に示すＳＴ１１０４）。これにより、Ｐａｔｈ Ｄが確立される。

【0021】

Ｐａｔｈ Ｄ確立後、ＭＳＣ／ＭＧＷは、ＭＭＥ経由でＰ−ＧＷ／Ｓ−ＧＷとシグナリングをやり取りする（図３に示すシグナリング１１０６。図４に示すＳＴ１１０６）。これにより、Ｐａｔｈ Ｂは削除される。

【0022】

以上、ｅＳＲＶＣＣハンドーバの動作について説明した。

【0023】

ＣＳ網で利用される音声コーデックとして、狭帯域（ＮＢ：Narrowband）コーデックであるＡＭＲ（Adaptive Multi-Rate）コーデック及び広帯域（ＷＢ：Wideband）コーデックであるＡＭＲ−ＷＢコーデック等が広く用いられている。ＡＭＲ及びＡＭＲ−ＷＢは、パケット交換方式で利用可能であるため、ＰＳ網（ＶｏＬＴＥ）での利用も考えられている。

【0024】

ＡＭＲ及びＡＭＲ−ＷＢは、サポートしているビットレートがそれぞれ異なる。更に、ＡＭＲ及びＡＭＲ−ＷＢがＰＳ網で用いられる場合には、非特許文献２に記載の通り、ＲＴＰ（Real-time Transport Protocol）ペイロードフォーマットで用いられる、ビットレートに対する番号付け（Frame Type Index）が双方でオーバラップしている。このため、ＣＳ網での利用においてもＰＳ網での利用においても、セッション開始時にＡＭＲ若しくはＡＭＲ−ＷＢのどちらを用いるかを決める必要がある。つまり、セッションの再折衝無しでＡＭＲとＡＭＲ−ＷＢとを切り替えることは不可能である。

【0025】

尚、従来技術において、狭帯域コーデックとは、一般的に３００Ｈｚ〜３．４ｋＨｚの帯域幅で、８ｋＨｚでサンプリングされるコーデックである。また、広帯域コーデックとは、一般的に５０Ｈｚ〜７ｋＨｚの帯域幅で、１６ｋＨｚでサンプリングされるコーデックである。また、超広帯域（ＳＷＢ：Super Wideband）コーデックとは、一般的に５０Ｈｚ〜１４ｋＨｚの帯域幅で、３２ｋＨｚでサンプリングされるコーデックである。

【先行技術文献】

【非特許文献】

【0026】

【非特許文献1】3GPP TS23.216 v9.6.0 “Single Radio Voice Call Continuity (SRVCC)”

【非特許文献2】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”

【非特許文献3】3GPP TS23.237 v11.0.0 “IP Multimedia Subsystem (IMS) Service Continuity”

【非特許文献4】Takashi Koshimizu and Katsutoshi Noshida, “Audio Viedo Callof Single Radio Voice Call Continuity”, 2011年電子情報通信学会総合大会，B-6-77

【非特許文献5】西田克利，輿水敬，「音声呼のＩＭＳ−回線交換間ハンドオーバ方式の改善提案移動機能力に基づく在圏アンカー型ＳＲＶＣＣ方式」，信学技報 NS2010-178，pp85-90

【発明の概要】

【発明が解決しようとする課題】

【0027】

図１または図３において、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバした際、ＰＳ網で使用していたコーデックがＣＳ網でサポートされていない場合には、ＵＥ１００で使用されるコーデックは、ＣＳ網でサポートされているコーデックに変更される。ＵＥ１００のコーデックに変更が生じた場合、ＵＥ１００とＵＥ１０２との通話継続を可能にするためには、次の２つの方法が考えられる。１つ目の方法は、ＵＥ１０２で使用されるコーデックをＵＥ１００の変更後のコーデックと同じものに変更する方法である。２つ目の方法は、ＭＳＣ／ＭＧＷにおいてトランスコーディングを行う方法である。

【0028】

前者の方法では、ＵＥ１０２のコーデックを変更するためのシグナリングに時間がかかり、通話が途切れる時間が長くなるので好ましくない。更に、ｅＳＲＶＣＣハンドオーバでは、ＵＥ１００のハンドオーバの際の経路切替のためのシグナリングがＡＴＣＦで終端するため、ＵＥ１０２のコーデックを変更するためのシグナリングを送ることすらできない。すなわち、ｅＳＲＶＣＣハンドオーバでは、既存のシグナリングを使ってＵＥ１０２のコーデックを変更することができない。

【0029】

よって、後者のトランスコーディングの方法が比較的好ましいと考えられる。しかしながら、トランスコーディングを行った場合、特にコーデックの帯域幅（コーデックの入出力となる信号の帯域幅）が異なる場合には、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする際、通話品質の劣化が生じてしまう。

【0030】

本発明の目的は、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる通信端末装置、ネットワークノード及び通信方法を提供することである。

【課題を解決するための手段】

【0031】

本発明の一態様に係るネットワークノードは、異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行うネットワークノードであって、前記２つの端末がそれぞれ使用するコーデックを検出する検出手段と、前記検出手段での検出結果に基づいて、前記２つの端末のうちいずれか一方の端末が使用するコーデックの変更を検出した場合、前記一方の端末以外の他方の端末の第１のコーデック、及び、前記一方の端末の変更後の第２のコーデックを用いて、前記第１のコーデックの第１の帯域幅の制限を行うか否かを判断する判断手段と、前記判断手段において前記第１の帯域幅を制限すると判断された場合、前記第１の帯域幅を制限させるためのシグナリングを、前記他方の端末へ送信する送信手段と、を具備する構成を採る。

【0032】

本発明の一態様に係る端末は、異なるコーデックを使用する端末間の通信に対して、端末間に位置するネットワークノードでトランスコーディングが行われる通信システムで用いられる端末であって、前記端末と、前記端末の通信相手である相手端末との間の通信に使用する第１のコーデックを折衝する折衝手段と、折衝された前記第１のコーデックに対して、前記端末においてエンコードされる入力信号の第１の帯域幅を決定する決定手段と、前記ネットワークノードから通知される、前記第１の帯域幅を制限させるためのシグナリングに従って、前記決定手段で決定された前記第１の帯域幅の変更を制御する変更手段と、を具備する構成を採る。

【0033】

本発明の一態様に係る帯域幅変更判断方法は、異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行うネットワークノードにおける帯域幅変更判断方法であって、前記２つの端末がそれぞれ使用するコーデックを検出し、検出結果に基づいて、前記２つの端末のうちいずれか一方の端末が使用するコーデックの変更を検出した場合、前記一方の端末以外の他方の端末の第１のコーデック、及び、前記一方の端末の変更後の第２のコーデックを用いて、前記第１のコーデックの第１の帯域幅の制限を行うか否かを判断し、前記第１の帯域幅を制限すると判断された場合、前記第１の帯域幅を制限させるためのシグナリングを、前記他方の端末へ送信する。

【0034】

本発明の一態様に係る帯域幅変更方法は、異なるコーデックを使用する端末間の通信に対して、端末間に位置するネットワークノードでトランスコーディングが行われる通信システムで用いられる端末における帯域幅変更方法であって、前記端末と、前記端末の通信相手である相手端末との間の通信に使用する第１のコーデックを折衝し、折衝された前記第１のコーデックに対して、前記端末においてエンコードされる入力信号の第１の帯域幅を選択し、前記ネットワークノードから通知される、前記第１の帯域幅を制限させるためのシグナリングに従って、前記第１の帯域幅の変更を制御し、前記第１の帯域幅の変更の制御に従って、前記第１の帯域幅を決定する。

【発明の効果】

【0035】

本発明によれば、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる。

【図面の簡単な説明】

【0036】

【図1】３ＧＰＰの移動通信ネットワークの一部を示す構成図

【図2】ＳＲＶＣＣハンドオーバの動作を示すシーケンスチャート

【図3】ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワークの一部を示す構成図

【図4】ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャート

【図5】本発明の実施の形態１に係る移動通信ネットワークの一部を示す構成図

【図6】本発明の実施の形態１に係るネットワークノード（ＭＳＣ／ＭＧＷ）の構成を示すブロック図

【図7】本発明の実施の形態１に係るＭＳＣ／ＭＧＷの変更判断部における判断方法の一例を示すフローチャート

【図8】本発明の実施の形態１に係る端末（ＵＥ）の構成を示すブロック図

【図9】本発明の実施の形態１に係るコーデック折衝に用いるＳＤＰの一例を示す図

【図10】本発明の実施の形態１に係る動作を示すシーケンスチャート

【図11】本発明の実施の形態１に係る帯域制限依頼メッセージの一例を示す図

【図12】本発明の実施の形態２に係る端末（ＵＥ）の構成を示すブロック図

【図13】本発明の実施の形態３に係る移動通信ネットワークの一部を示す構成図

【図14】本発明の実施の形態３に係るネットワークノード（ＭＳＣ／ＭＧＷ）の構成を示すブロック図

【図15】本発明の実施の形態３に係る動作を示すシーケンスチャート

【図16】本発明の実施の形態３に係るＭＳＣ／ＭＧＷのコーデック選択部におけるコーデックの選択方法の一例を示すフローチャート

【図17】本発明の実施の形態３のバリエーションに係る動作を示すシーケンスチャート

【図18】本発明の実施の形態４に係る移動通信ネットワークの一部を示す構成図

【図19】本発明の実施の形態４に係るネットワークノード（ＡＴＣＦ／ＡＴＧＷ、ＭＳＣ／ＭＧＷ）の構成を示すブロック図

【図20】本発明の実施の形態４に係る端末（ＵＥ）の構成を示すブロック図

【図21】本発明の実施の形態４に係る動作を示すシーケンスチャート

【発明を実施するための形態】

【0037】

以下、本発明の各実施の形態について、図面を参照して詳細に説明する。

【0038】

以下の説明では、「帯域幅」とはコーデックの入出力となる信号の帯域幅のことを指す。

【0039】

また、以下の説明では、「帯域幅の指定が必ずしも必要の無いコーデック」とは、エンコードされる入力信号の帯域幅を、セッションの再折衝無しで切り替えることが可能なコーデックを意味する。例えば、ＥＶＳ（Enhanced Voice Services）コーデックの非互換(non interoperable)モードは、ＰＳ網のみで利用される上、サポートされるビットレートは、どの帯域幅においても共通である（「3GPP TSG SA WG4 S4-110539 “EVS Permanent Document #4 (EVS-4): EVS design constraints”」参照）。このため、ＥＶＳコーデックの非互換モードでは、ナイキスト周波数（Nyquist frequency：サンプリング周波数の１／２）以下の帯域幅であれば、セッション途中でも、エンコードされる入力信号の帯域幅を自由に変更できるよう設計することが可能である。よって、セッションの開始から終了までにおける帯域幅の指定が必ずしも必要ではない。この場合、エンコーダは、例えば入力信号の特性（例えば入力信号の周波数特性及び入力信号を分析して得られるパラメータ等）、又は、エンコーディングビットレートに応じて、エンコードされる入力信号の帯域幅を設定又は変更する。

【0040】

（実施の形態１）
図５は、本発明の実施の形態１に係る移動通信ネットワークの一部を示す構成である。なお、図５において、図１と同一構成である部分には同一の符号を付してその説明を省略する。図５では、図１と比較して、ＵＥ１００、１０２及びＭＳＣ／ＭＧＷ３００の動作が異なる。

【0041】

まず、図５に示すＭＳＣ／ＭＧＷ３００について説明する。ＭＳＣ／ＭＧＷ３００は、異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行う。

【0042】

図６は、本実施の形態に係るＭＳＣ／ＭＧＷ３００（ネットワークノード）の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図６では、本発明と密接に関連する帯域制限（帯域変更）処理に関わる主な構成部（例えば、図５に示すＳＴ４０２〜４０６（後述する）に関わる構成部）を示す。

【0043】

図６に示すＭＳＣ／ＭＧＷ３００において、受信部６００は、通話データ（以下、通信データとする）、シグナリング等を受信する。例えば、受信部６００は、ＵＥ１００及びＵＥ１０２からそれぞれ送信されるシグナリング（例えば、図１に示すシグナリング２０２，２０４）を受信すると、受信したシグナリングを、コーデック検出部６０４及びコーデック帯域幅検出部６０６に出力する。

【0044】

送信部６０２は、通信データ、シグナリング等を送信する。例えば、送信部６０２は、シグナリング生成部６１０から出力されるシグナリングをＵＥ１０２へ通知する。

【0045】

コーデック検出部６０４は、受信部６００から入力されるＵＥ１００及びＵＥ１０２からのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックを検出する。そして、コーデック検出部６０４は、検出したコーデックを示す情報（検出結果）を変更判断部６０８に出力する。

【0046】

コーデック帯域幅検出部６０６は、受信部６００から入力されるＵＥ１００及びＵＥ１０２からのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックの帯域幅を検出する。そして、コーデック帯域幅検出部６０６は、検出したコーデックの帯域幅を示す情報（検出結果）を、変更判断部６０８に出力する。

【0047】

変更判断部６０８は、コーデック検出部６０４から入力される情報に示されるコーデック、及び、コーデック帯域幅検出部６０６から入力される情報に示されるコーデックの帯域幅に基づいて、ＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であるか、及び、帯域幅制限が必要であるかを判断する。例えば、変更判断部６０８は、コーデック検出部６０４での検出結果に基づいて、２つの端末（ＵＥ１００及びＵＥ１０２）のうち一方のＵＥ１００が使用するコーデックの変更を検出した場合、他方のＵＥ１０２のコーデック、及び、ＵＥ１００の変更後のコーデックを用いて、ＵＥ１０２のコーデックの帯域幅の制限を行うか否かを判断する。変更判断部６０８は、判断結果をシグナリング生成部６１０に出力する。なお、変更判断部６０８における帯域幅の変更判断処理の詳細については後述する。

【0048】

シグナリング生成部６１０は、変更判断部６０８でＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であり、かつ、帯域幅制限が必要であると判断された場合、ＵＥ１０２でエンコードされる入力信号の帯域幅の制限を、ＵＥ１０２に対して依頼するシグナリングを生成する。帯域幅制限を依頼するシグナリングには、例えば、ＵＥ１００の変更後の帯域幅を示す情報を含めてもよい。シグナリング生成部６１０は、生成したシグナリングを、送信部６０２を介して、ＵＥ１０２へ送信する。このようにして、変更判断部６０８においてＵＥ１０２のコーデックの帯域幅を制限すると判断された場合、帯域幅を制限させるためのシグナリングが、送信部６０２を介して、ＵＥ１０２へ送信される。

【0049】

トランスコーディング部６１２は、ＵＥ１００及びＵＥ１０２がそれぞれ異なるコーデックを使用する場合、ＵＥ１００からＵＥ１０２への通信データ、及び、ＵＥ１０２からＵＥ１００への通信データに対してトランスコーディングを行う。

【0050】

次いで、図７を用いて、ＭＳＣ／ＭＧＷ３００の変更判断部６０８における帯域幅の変更判断処理の詳細について説明する。

【0051】

図７に示すＳＴ８００において、変更判断部６０８は、コーデック検出部６０４での検出結果（検出されるコーデック）に基づいて、ＵＥ１００のコーデックが変更されたか否かを判断する。

【0052】

ＵＥ１００のコーデックが変更された場合（ＳＴ８００：Ｙｅｓ）、ＳＴ８０２において、変更判断部６０８は、コーデック検出部６０４での検出結果に基づいて、ＵＥ１０２で使用されているコーデックが、コーデックＡのように、帯域幅の指定不要なコーデックであるか否かを判断する。

【0053】

ＵＥ１０２で使われているコーデックが帯域幅の指定不要なコーデックである場合（ＳＴ８０２：Ｙｅｓ）、ＳＴ８０４において、変更判断部６０８は、コーデック帯域幅検出部６０６での検出結果に基づいて、ＵＥ１００の変更後のコーデックの帯域幅が、ＵＥ１０２が現在使用しているコーデックの最大帯域幅よりも狭いか否かを判断する。

【0054】

ＵＥ１００の変更後のコーデックの帯域幅が、ＵＥ１０２が現在使用しているコーデックの最大帯域幅よりも狭い場合（ＳＴ８０４：Ｙｅｓ）、ＳＴ８０６において、変更判断部６０８は、ＵＥ１０２へのエンコードされる入力信号の帯域幅の制限が可能かつ必要であると判断する。例えば、変更判断部６０８は、ＵＥ１０２のコーデックの帯域幅を、ＵＥ１００の変更後のコーデックの帯域幅に制限（変更）すると判断する。

【0055】

一方、ＵＥ１００のコーデックが変更されていない場合（ＳＴ８００：Ｎｏ）、ＵＥ１０２で使われているコーデックが、帯域幅の指定不要なコーデックではない場合（ＳＴ８０２：Ｎｏ）、又は、ＵＥ１００の変更後のコーデックの帯域幅が、ＵＥ１０２が現在使用しているコーデックの最大帯域幅以上の場合（ＳＴ８０４：Ｎｏ）、ＳＴ８０８において、変更判断部６０８は、ＵＥ１０２への帯域制限は行わないと判断する。

【0056】

このようにして、具体的には、ＭＳＣ／ＭＧＷ３００は、一方のＵＥのコーデックの変更が検出された場合、他方のＵＥのコーデックが帯域幅の指定不要なコーデックであるか否かを判断することで、他方のＵＥのコーデックの帯域幅を制限（変更）することが可能か否かを判断する。また、ＭＳＣ／ＭＧＷ３００は、一方のＵＥの変更後のコーデックの帯域幅が、他方のＵＥのコーデックの最大帯域幅よりも狭いか否かを判断することで、他方のＵＥのコーデックの帯域幅の制限（変更）が必要であるか否かを判断する。

【0057】

次に、図５に示すＵＥ１００，１０２について説明する。

【0058】

図８は、本実施の形態に係るＵＥ１００，１０２（端末）の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図８では、本発明と密接に関連する帯域制限処理に関わる主な構成部（例えば、図５に示すＳＴ４００〜４０６（後述する）に関わる構成部）を示す。

【0059】

図８に示すＵＥ１００，１０２において、受信部７００は、通信データ及びシグナリング等を受信する。例えば、受信部７００は、ＭＳＣ／ＭＧＷ３００から送信されるシグナリング（例えば、図１に示すシグナリング２０２又は２０４）を受信すると、受信したシグナリングを、コーデック折衝部７０４及びシグナリング解析部７１０に出力する。

【0060】

送信部７０２は、通信データ及びシグナリング（例えば、図１に示すシグナリング２０２又は２０４）等を送信する。

【0061】

コーデック折衝部７０４は、端末（ここではＵＥ１００とＵＥ１０２）間の通信に使用するコーデックを折衝する。具体的には、コーデック折衝部７０４は、ＳＤＰ（Session Description Protocol）オファー又はＳＤＰアンサーを作成し、コーデック折衝を行う。また、ＵＥ（図５ではＵＥ１００）がＣＳ網に移動した場合には、当該ＵＥのコーデック折衝部７０４は、ＣＳ網での折衝方法に基づき、コーデック折衝を行う。コーデック折衝部７０４は、コーディング折衝の結果をコーデック選択部７０６に出力する。

【0062】

図９は、本発明の実施の形態におけるコーデック折衝に用いるＳＤＰの一例を示す。発呼側ＵＥは、帯域幅の指定が必ずしも必要の無いコーデック（以下、コーデックＡという）をサポートしている場合、コーデックＡに対し、サンプリング周波数のみ指定し、帯域幅の指定はせずにＳＤＰオファーを生成する。例えば、図９では、発呼側ＵＥが生成するＳＤＰオファー（SDP offer）には、従来のＷＢコーデックであるＡＭＲ−ＷＢコーデック（例えば、帯域幅：５０Ｈｚ〜７ｋＨｚ、サンプリング周波数：16000）、従来のＮＢコーデックであるＡＭＲコーデック（例えば、帯域幅：３００Ｈｚ〜３．４ｋＨｚ、サンプリング周波数：8000）、及び、帯域幅の指定不要なコーデックＡ（サンプリング周波数:32000）が記載されている。

【0063】

また、着呼側ＵＥは、自らがコーデックＡをサポートしている場合、帯域幅の指定が無く、コーデックＡのサンプリング周波数のみ指定された条件を受け入れ（図９に示すコーデックＡを選択し）、ＳＤＰアンサー（SDP answer）を生成する。なお、コーデックＡは前述のＥＶＳコーデックの非互換モードであってもよい。ここで、コーデックＡのサンプリング周波数32000がサポートしている最大の帯域幅は、ＳＷＢ（Super Wideband）相当であり、エンコーダはこの帯域幅内においては、セッション途中でも、入力信号の特性又はエンコーディングビットレートに応じて、帯域幅を自由に変更することが可能であるとする。

【0064】

コーデック選択部７０６は、コーデック折衝部７０４により折衝されたコーデックを選択し、選択したコーデックを示す情報を帯域幅決定部７０８に出力する。

【0065】

帯域幅決定部７０８は、コーデック選択部７０６で選択されたコーデックに対して、自端末においてエンコードされる入力信号の帯域幅を決定する。例えば、帯域幅決定部７０８は、コーデック選択部７０６により選択されたコーデックの帯域幅が一定である場合、当該帯域幅を選択する。一方、帯域幅決定部７０８は、コーデック選択部７０６により選択されたコーデックの帯域幅がコーデックＡのように帯域幅を１セッションの中で変更できる場合には、エンコードされる入力信号の帯域幅をフレーム毎に決定する。帯域幅決定部７０８は、例えば、エンコーディングビットレート、入力信号特性、又は、外部シグナリングによる帯域幅制限の依頼等に応じて、エンコードされる入力信号の帯域幅をフレーム毎に決定する。より詳細には、帯域幅決定部７０８は、例えば、コーデックモード変更部７１２からコーデックの帯域幅の制限（変更）を依頼されていることが通知されると、エンコードされる入力信号の帯域幅を、依頼されている帯域幅に制限（変更）する。

【0066】

シグナリング解析部７１０は、受信部７００から入力されるシグナリングを解析する。シグナリングには、例えば、ＭＳＣ／ＭＧＷ３００からの帯域幅の制限を依頼するシグナリング（帯域幅を制限させるためのシグナリング）が含まれる。シグナリング解析部７１０は、シグナリング解析の結果を、コーデックモード変更部７１２に通知する。

【0067】

コーデックモード変更部７１２は、シグナリング解析部７１０から入力されるシグナリング解析結果が、コーデックの帯域幅の制限（変更）を依頼するシグナリングの場合、エンコードされる入力信号の帯域幅を制限（変更）することを決定し、その旨を帯域幅決定部７０８に通知する。すなわち、コーデックモード変更部７１２は、ＭＳＣ／ＭＧＷ３００から通知される、コーデックの帯域幅を制限させるためのシグナリングに従って、帯域幅決定部７０８で決定された帯域幅の変更を制御する。

【0068】

なお、シグナリング解析部７１０は、他の外部シグナリングを解析し、その解析結果をコーデックモード変更部７１２に通知してもよい。例えばシグナリング解析部７１０は、上述したＲＴＣＰ−ＡＰＰを解析し、その解析結果（例えばエンコーディングビットレートの変更依頼）を、コーデックモード変更部７１２に通知してもよい。この場合、コーデックモード変更部７１２は、エンコーディングビットレートを決定すると、決定したエンコーディングビットレートを、帯域幅決定部７０８に通知する。そして、帯域幅決定部７０８は、決定されたエンコーディングビットレートに応じて、帯域幅を決定する。

【0069】

次に、本実施の形態におけるＵＥ１００，１０２、及び、ＭＳＣ／ＭＧＷ３００の動作の一例について説明する。

【0070】

図１０は、図５に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。なお、図１０において、図２と同一動作である部分には同一の符号を付してその説明を省略する。

【0071】

以下の説明では、図５において、現在、ＵＥ１００及びＵＥ１０２の双方ともにｅ−ＵＴＲＡＮ等のＶｏＬＴＥ通話サービスを可能とする無線アクセス網に接続しているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局、ＰＳ網は図示せず）。つまり、図５に示すＵＥ１００とＵＥ１０２との間でＶｏＬＴＥ通話を開始する。

【0072】

通話開始の際、ＵＥ１００とＵＥ１０２との間で使用するコーデックの折衝が行われる（例えば、「3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS);Multimedia Telephony; Media Handling and interaction”」参照）。例えば、ＵＥ１００及びＵＥ１０２（コーデック折衝部７０４）は、帯域幅の指定が必ずしも必要の無いコーデックに対して、当該コーデックの折衝を帯域幅指定無しで行う（図５及び図１０に示すＳＴ４００）。

【0073】

次いで、図５に示すように、ＵＥ１００がＳＲＶＣＣによるハンドオーバを行い、ＵＴＲＡＮに移動したとする。つまり、ＵＥ１００がＰＳ網からＣＳ網に移動したとする。

【0074】

この場合、図１０のＳＴ２０４のプロセスの中で、ＵＥ１００（コーデック折衝部７０４）とＭＳＣ／ＭＧＷ３００との間においてＣＳ網で使用するコーデックが再折衝される。ここでは、例えば、ＵＥ１００に対してＡＭＲコーデックを利用するよう折衝され、ＵＥ１００が使用するコーデックの帯域幅がＮＢに制限されたと仮定する（図５及び図１０に示すＳＴ４０２）。

【0075】

また、ＭＳＣ／ＭＧＷ３００（コーデック検出部６０４及びコーデック帯域幅検出部６０６）は、図１０のＳＴ２０２のプロセスにより、ＵＥ１０２が使用しているコーデックがコーデックＡであり、最大帯域幅がＳＷＢであることを検出する。

【0076】

また、ＭＳＣ／ＭＧＷ３００（コーデック検出部６０４及びコーデック帯域幅検出部６０６）は、図１０のＳＴ２０４のプロセスにより、ＵＥ１００で使用されるコーデックがＡＭＲになり、帯域幅がＮＢに制限されたことを検出する。

【0077】

ＭＳＣ／ＭＧＷ３００（変更判断部６０８）は、ＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であるか、及び、帯域幅制限が必要であるかを判断する。ここでは、ＵＥ１００のコーデックが変更され（図７に示すＳＴ８００：Ｙｅｓ）、ＵＥ１０２のコーデックがコーデックＡであり（図７に示すＳＴ８０２：Ｙｅｓ）、かつ、ＵＥ１００のＡＭＲコーデックの帯域幅（ＮＢ）がＵＥ１０２のコーデックＡの最大帯域幅（ＳＷＢ）よりも狭い（図７に示すＳＴ８０４：Ｙｅｓ）。そこで、ＭＳＣ／ＭＧＷ３００（変更判断部６０８）は、ＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能かつ必要であると判断する（図７に示すＳＴ８０６）。

【0078】

そこで、ＭＳＣ／ＭＧＷ３００（シグナリング生成部６１０）は、ＵＥ１０２に対し、コーデックＡのエンコードされる入力信号の帯域幅を、ＮＢ（ＵＥ１００の変更後のコーデックの帯域幅）に制限するよう依頼するシグナリングを送る（図５及び図１０に示すＳＴ４０４）。このシグナリングは、例えばＳＴ２０２の一連のシグナリング（即ち、ＩＭＳシグナリング）に含まれてもよく、ＲＴＣＰ（Real-time Transport Control Protocol）−ＡＰＰ（Application-defined）（例えば、「3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS);Multimedia Telephony; Media Handling and interaction”」参照）のような別のシグナリングで送られてもよい。図１１Ａは、帯域制限を通知するシグナリングがＩＭＳシグナリングに含まれる場合の一例を示す。また、図１１Ｂは、帯域制限を通知するシグナリングがＲＴＣＰ−ＡＰＰに含まれる場合の一例を示す。

【0079】

ＵＥ１０２（シグナリング解析部７１０）は、ＭＳＣ／ＭＧＷ３００からのシグナリングを解析する。そして、ＵＥ１０２（コーデックモード変更部７１２）は、コーデックＡの帯域幅の制限を依頼されていることを特定する。そこで、ＵＥ１０２（帯域幅決定部７０８）は、ＵＥ１０２のエンコードされる入力信号の帯域幅を、依頼された帯域幅（ここではＮＢ）に制限する。そして、ＵＥ１０２は、制限した帯域幅で通信データをエンコードする（図１０に示すＳＴ４０６）。

【0080】

このようにして、ＵＥ１００は、変更後のコーデックの帯域幅（ＮＢ）を使用し、ＵＥ１０２は、コーデックＡの帯域制限した帯域幅（ＮＢ）を使用する。これにより、ＵＥ１００及びＵＥ１０２の双方ともコーデック帯域幅として同一のＮＢを使用する。よって、ＭＳＣ／ＭＧＷ３００（トランスコーディング部６１２）では、ＵＥ１０２側からＵＥ１００側へのトランスコーディング（コーデックＡ（超広帯域）からＡＭＲコーデック（狭帯域）へのトランスコーディング）を行う場合でも、通話品質の劣化を抑えることができる。

【0081】

このように、本実施の形態では、ＭＳＣ／ＭＧＷ３００（ネットワークノード）は、通信中のＵＥの一部のＵＥ１００にコーデックの変更が生じた場合でも、他のＵＥ１０２に対して、ＵＥ１００の変更後のコーデックの帯域幅に合わせるように、コーデックの帯域幅の制限を要求する。また、ＵＥ１０２は、ＶｏＬＴＥ通話中の通信相手であるＵＥ１００のコーデックが変更（狭帯域幅に変更）された場合でも、ＵＥ１０２のエンコードされる入力信号の帯域幅をＵＥ１００に合わせて制限する。すなわち、ＵＥ１０２は、通信相手であるＵＥ１００のネットワーク状況に応じて、ＵＥ１００との通信を途切れさせることなく、エンコードされる入力信号の帯域幅を変更する。

【0082】

これにより、一方のＵＥのネットワーク状況が変わった場合でも、ＵＥ間のコーデックの帯域幅を同等に維持することができる。よって、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする場合に生じる通話品質の劣化を抑えることができる。すなわち、ＭＳＣ／ＭＧＷ３００は、通信品質の劣化を抑えてトランスコーディングを行うことができる。

【0083】

更に、ＵＥ１０２では、コーデックを変更せずに、エンコードされる入力信号の帯域幅のみを制限するので、コーデックを変更するためのシグナリングが不要となり、通話が途切れる時間が長くなることを防ぐことができる。

【0084】

よって、本実施の形態によれば、ＶｏＬＴＥ通話中のＵＥ１００がＣＳ網にハンドオーバし、ハンドオーバ先ＣＳ網でコーデックが変更された場合でも、通話を途切れさせることなくＵＥ１０２のエンコードされる入力信号の帯域幅を制限することができる。これにより、ＵＥ１０２側からＵＥ１００側へのトランスコーディングによる通話品質の劣化を抑えることができる。つまり、本実施の形態によれば、ＶｏＬＴＥ通話中の端末（ＵＥ）の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる。

【0085】

なお、上記実施の形態（例えば、図５参照）において、ＵＥ１００がｒＳＲＶＣＣ（reverse SRVCC。例えば、「3GPP TR23.885 v1.2.0 “Feasibility Study of Single Radio Voice Call Continuity (SRVCC) from UTRAN/GERAN to E-UTRAN/HSPA”」参照）に対応している場合、ＰＳ網からＣＳ網にハンドオーバした後、再びＰＳ網にハンドオーバする可能性もある。この場合、ＭＳＣ／ＭＧＷ３００は、ＵＥ１００のＣＳ網からＰＳ網へのハンドオーバ処理に関するシグナリングを受け取った時点で、ＵＥ１０２に対して、コーデックの帯域幅制限を解除するシグナリングを送信してもよい。又は、ＭＳＣ／ＭＧＷ３００は、ＵＥ１００がＰＳ網へのハンドオーバ完了後に、ＵＥ１０２に対して、コーデックの帯域幅制限を解除するシグナリングを送信してもよい。

【0086】

また、上記実施の形態（例えば、図５参照）では、ＵＥ１００が通話開始の際、ＰＳ網に接続している場合について説明した。しかし、ＵＥ１００が通話開始時に、ＣＳ網に接続している場合もあり得る。この場合、例えば、「3GPP TS23.292 v10.3.0 “IP Multimedia Subsystem (IMS) centralized services”」に記載の方法で、ＵＥ１００は、ＰＳ網に接続しているＵＥ１０２との間で通話を開始する。ここで、ＵＥ１００がｒＳＲＶＣＣに対応している場合（即ち、ＵＥ１００がＰＳ網にハンドオーバし得る場合）、ＭＳＣ／ＭＧＷ３００は、ＵＥ１０２との間で、コーデックの折衝を行う際、ＵＥ１０２に対し、ＵＥ１００が使用するコーデックの帯域幅を最大帯域幅としてエンコードするように、予め折衝してもよい。又は、ＭＳＣ／ＭＧＷ３００は、ＵＥ１０２との折衝後に別のシグナリングで、ＵＥ１０２にエンコードされる入力信号の帯域幅の制限を依頼してもよい。

【0087】

また、本実施の形態では、ＳＲＶＣＣ方式を用いて説明したが、ｅＳＲＶＣＣ方式においても本実施の形態を適用することができる。

【0088】

ＳＲＶＣＣ方式では、通信中のＵＥが使用するコーデックが異なる場合、ＭＧＷ（ＭＳＣ／ＭＧＷ３００）においてトランスコーディングが行われる。一方、非特許文献３によると、ｅＳＲＶＣＣ方式では、ＭＧＷがトランスコーディングを行う代わりに、ＡＴＧＷがトランスコーディングを行ってもよいことになっている。

【0089】

ここで、ｅＳＲＶＣＣ方式において、ＭＧＷではなくＡＴＧＷでトランスコーディングを行う場合、ＳＲＶＣＣ方式について、本実施の形態に係るＭＳＣ／ＭＧＷ３００（図５参照）へ追加された機能は、ＡＴＣＦ／ＡＴＧＷ１１２０（図３参照）に追加される。すなわち、ｅＳＲＶＣＣ方式では、ＡＴＣＦ／ＡＴＧＷ１１２０が、図６に示す受信部６００、送信部６０２、コーデック検出部６０４、コーデック帯域幅検出部６０６、変更判断部６０８、シグナリング生成部６１０及びトランスコーディング部６１２を具備する構成を採る。ここで、ｅＳＲＶＣＣ方式においてＡＴＣＦ／ＡＴＧＷ１１２０が有する、送信部６０２、コーデック検出部６０４、変更判断部６０８、シグナリング生成部６１０及びトランスコーディング部６１２に関しては、ＳＲＶＣＣ方式においてＭＳＣ／ＭＧＷ３００が有する各構成部と同一の機能を持つ。

【0090】

ｅＳＲＶＣＣ方式におけるＡＴＣＦ／ＡＴＧＷ１１２０の受信部６００（図６）は、通信データ、シグナリング等を受信する。例えば、受信部６００は、ＵＥ１００、ＵＥ１０２、ＡＴＣＦ、及びＭＳＣ／ＭＧＷからそれぞれ送信されるシグナリング（例えば、図３に示すシグナリング１１０２）を受信すると、受信したシグナリングを、コーデック検出部６０４及びコーデック帯域幅検出部６０６に出力する。

【0091】

コーデック検出部６０４は、受信部６００から入力されるＵＥ１００、ＵＥ１０２、ＡＴＣＦ、及びＭＳＣ／ＭＧＷからのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックを検出する。そして、コーデック検出部６０４は、検出したコーデックを示す情報（検出結果）を変更判断部６０８に出力する。

【0092】

コーデック帯域幅検出部６０６は、受信部６００から入力されるＵＥ１００、ＵＥ１０２、及びＭＳＣ／ＭＧＷからのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックの帯域幅を検出する。そして、コーデック帯域幅検出部６０６は、検出したコーデックの帯域幅を示す情報（検出結果）を、変更判断部６０８に出力する。

【0093】

なお、ここでは、ＡＴＣＦ／ＡＴＧＷ１１２０を一つのノードとして説明したが、別々のノードでもよい。よって、上述したＡＴＣＦ／ＡＴＧＷ１１２０が有する機能を、ＡＴＣＦ又はＡＴＧＷの何れか一方若しくは両方が有していてもよい。また、ＡＴＣＦとＡＴＧＷとの間で必要な情報をやり取りしてもよい。

【0094】

また、上記実施の形態において、各ＵＥは、コーディング折衝の際、図９のようにＳＤＰで帯域幅を固定して指定しない代わりに、ＳＤＰで最大帯域幅を指定してもよい。

【0095】

また、上記実施の形態では、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷがＵＥ１０２に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する場合について説明した。しかし、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷは、帯域幅の制限を依頼するシグナリングの代わりに、エンコーディングビットレートの制限を依頼するシグナリングを送信してもよい。ここで、各ＵＥは入力信号のエンコーディングビットレートに基づいて、エンコードされる入力信号の帯域幅を設定する。よって、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷがエンコーディングビットレートの制限を依頼するシグナリングをＵＥに送信することで、当該ＵＥは、制限されたエンコーディングビットレートを設定し、かつ、制限されたエンコーディングビットレートに基づいて、エンコードされる入力信号の帯域幅を制限することが可能となる。または、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷは、帯域幅及びエンコーディングビットレートの双方の制限を依頼するシグナリングを送信してもよい。

【0096】

また、上記実施の形態では、ＭＳＣ／ＭＧＷ３００（図６）を１つのノードとして説明した。しかし、ＭＳＣ／ＭＧＷ３００は、互いにインタフェースによって接続される２つ以上のノードで構成されてもよく、上述したＭＳＣ／ＭＧＷ３００の各機能をこれらの複数のノードに分散させてもよい。

【0097】

（実施の形態２）
実施の形態１では、ＭＳＣ／ＭＧＷ３００又はＡＴＧＷ（ＡＴＣＦ／ＡＴＧＷ１１２０）がＵＥ１０２に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する場合について説明した。これに対して、本実施の形態では、ＭＳＣ／ＭＧＷ３００又はＡＴＧＷ（ＡＴＣＦ／ＡＴＧＷ１１２０）が帯域幅の制限を依頼するシグナリングを送信する代わりに、ＵＥ１０２が通信データを受け取ることにより、ＵＥ１００のコーデックの帯域幅が制限されたことを検知し、ＵＥ１０２のエンコードされる入力信号の帯域幅を制限する場合について説明する。

【0098】

図１２を用いて、本実施の形態に係るＵＥについて説明する。

【0099】

図１２に示すＵＥ１００，１０２において、受信部７００、送信部７０２、コーデック折衝部７０４、コーデック選択部７０６、及び帯域幅決定部７０８は、図８と同一動作を行う構成部であり、その説明を省略する。

【0100】

データ解析部１２００は、受信部７００から入力される通信データを解析する。データ解析部１２００は、或る時刻から一定時間における通信データのコーデックの帯域幅の上限値が、その直前までのコーデック帯域幅の上限値、又は、通話開始時に折衝したコーデックの帯域幅の上限値と比較して異なる場合、通信相手先端末（ＵＥ）の通信データのコーデックの帯域幅が制限（変更）されたと解析する。データ解析部１２００は、解析結果を、コーデックモード変更部１２０２に通知する。

【0101】

コーデックモード変更部１２０２は、データ解析部１２００からの解析結果に基づき、エンコードされる入力信号の帯域幅を制限（変更）することを決定し、その旨を帯域幅決定部７０８に通知する。これにより、帯域幅決定部７０８は、コーデックモード変更部１２０２において決定された帯域幅の変更を制御する。

【0102】

このように、本実施の形態では、ＵＥ１００、１０２は、受け取った通信データのコーデックの帯域幅の上限値が変更されたか否かに応じて、通信相手端末のコーデックが変更されたか否かを判断する。そして、ＵＥ１００、１０２は、通信相手端末のコーデックが変更されたと判断した場合、自装置のコーデックの帯域幅の変更を制御する。これにより、実施の形態１と同様、一方のＵＥのネットワーク状況が変わった場合でも、ＵＥ間のコーデックの帯域幅を同等に維持することができる。よって、実施の形態１と同様、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする場合に生じる通話品質の劣化を抑えることができる。

【0103】

（実施の形態３）
図１３は、本発明の実施の形態３に係る移動通信ネットワークの一部を示す構成である。なお、図１３に示す各ノードの動作は前述（例えば図５）した通りである。

【0104】

図１３において、ＵＥ１００は、最初ＳＲＶＣＣにてＣＳ網にハンドオーバ（以下、ＳＲＶＣＣハンドオーバと呼ぶこともある）を行い、ＰＳ網に存在するＵＥ１０２と、ＭＳＣ／ＭＧＷ１３００を経由して、通信データを送受信している（図１３に示すＰａｔｈ Ａ及びＰａｔｈ Ｂ）。この際、ＵＥ１００はＣＳ網で利用するコーデックとしてＡＭＲ−ＷＢを用い、ＵＥ１０２はＰＳ網で利用するコーデックとして、例えば上述したコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）を用い、ＭＳＣ／ＭＧＷ１３００でトランスコーディングが行われていたとする。

【0105】

次に、ＵＥ１０２もＳＲＶＣＣによりＣＳ網にハンドオーバを行ったとする。

【0106】

この際、非特許文献１のハンドオーバ手順に従えば、ＵＥ１０２の移動先ＣＳ網での通信はＭＳＣ／ＭＧＷ１３０２で終端され、ＭＳＣ／ＭＧＷ１３００の通信相手先は、ＵＥ１０２からＭＳＣ／ＭＧＷ１３０２に変更される。すなわち、ＵＥ１００とＵＥ１０２との間の通信データの経路は、Ｐａｔｈ Ｄ、Ｐａｔｈ Ｃ及びＰａｔｈ Ｂを通る経路に変更される。

【0107】

更に、ＵＥ１０２がＣＳ網で使用するコーデックがＡＭＲ−ＷＢに変更になったとする。この場合、ＵＥ１０２からＭＳＣ／ＭＧＷ１３０２までは、ＵＥ１０２からＵＥ１００へ送信される通信データは、Ｐａｔｈ Ｄを通り、かつ、ＡＭＲ−ＷＢを用いて送信される。次いで、ＭＳＣ／ＭＧＷ１３０２は、ＵＥ１０２がＣＳ網で使用するＡＭＲ−ＷＢからＰＳ網で使用していたコーデックＡにトランスコーディングを行う。よって、ＭＳＣ／ＭＧＷ１３０２からＭＳＣ／ＭＧＷ１３００までは、ＵＥ１０２からＵＥ１００へ送信される通信データは、Ｐａｔｈ Ｃを通り、かつ、コーデックＡを用いて送信される。次いで、ＭＳＣ／ＭＧＷ１３００は、コーデックＡからＡＭＲ−ＷＢにトランスコーディングを行う。よって、ＭＳＣ／ＭＧＷ１３００からＵＥ１００までは、ＵＥ１０２からＵＥ１００へ送信される通信データは、Ｐａｔｈ Ｂを通り、かつ、ＡＭＲ−ＷＢを用いて送信される。ＵＥ１００からＵＥ１０２へ送信される通信データについても同様である。

【0108】

本実施の形態では、通信中のＵＥ１００及びＵＥ１０２の双方がＳＲＶＣＣハンドオーバを行った場合でも、ＭＳＣ／ＭＧＷ１３００，１３０２におけるトランスコーディングを最小限に抑える方法について説明する。

【0109】

まず、図１３に示すＭＳＣ／ＭＧＷ１３００、１３０２について説明する。

【0110】

図１４は、本実施の形態に係るＭＳＣ／ＭＧＷ１３００、１３０２構成を示すブロック図である。なお、図１４に示すＭＳＣ／ＭＧＷ１３００、１３０２は、図示される機能ブロックの他に、図８に示される機能ブロック又はその他の機能ブロックを具備していてもよい。

【0111】

図１４に示すＭＳＣ／ＭＧＷ１３００、１３０２において、受信部１５００は、通信データ、シグナリング等を受信する。

【0112】

送信部１５０２は、通信データ、シグナリング等を送信する。

【0113】

シグナリング解析部１５０４は、ＳＲＶＣＣ処理のためのシグナリング、又は、ＩＭＳのシグナリング（ＩＭＳシグナリング）等を解析する。シグナリング解析部１５０４は、シグナリング解析の結果を、シグナリング生成部１５０６、端末位置判断部１５０８及びコーデック選択部１５１０に通知する。

【0114】

シグナリング生成部１５０６は、シグナリング解析部１５０４のシグナリング解析結果等に基づいて、シグナリングを生成する。

【0115】

端末位置判断部１５０８は、シグナリング解析部１５０４のシグナリング解析結果に基づいて、通信中の双方の端末（ＵＥ１００、１０２）がＰＳ網に存在するのか、ＣＳ網に存在するのかを判断する。端末位置判断部１５０８は、判断結果をコーデック選択部１５１０及び経路選択部１５１２に出力する。

【0116】

コーデック選択部１５１０は、シグナリング解析部１５０４のシグナリング解析結果及び端末位置判断部１５０８の判断結果に基づいて、利用するコーデック、又はコーデック候補を選択する。

【0117】

経路選択部１５１２は、端末位置判断部１５０８の判断結果に基づいて、通信データが通る経路を選択する。

【0118】

次に、本実施の形態におけるＭＳＣ／ＭＧＷ１３００，１３０２の動作の一例について説明する。

【0119】

図１５は、図１３に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。なお、図１３において、ＳＣＣ ＡＳ及びＣＳＣＦは図示していないが、ＩＭＳの一部として存在しているものとする。

【0120】

現在、ＵＥ１００とＵＥ１０２は、双方ともｅ−ＵＴＲＡＮに接続し、ＶｏＬＴＥ通信を行っているとする。つまり、現在、ＵＥ１００及びＵＥ１０２では、音声コーデックとして、前述のコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）が使用されているものとする（図１５に示すＳＴ１４００）。

【0121】

次いで、ＵＥ１００はＣＳ網にハンドオーバ（ＳＲＶＣＣハンドオーバ）する（図１０に示すＳＴ２００の処理（ＳＲＶＣＣ処理）と同等の処理）。また、ＵＥ１００はＣＳ網にハンドオーバし、ＣＳ網との間にコネクションを確立する（図１０に示すＳＴ２０４の処理（コネクション確立処理）と同等の処理）。

【0122】

ＳＴ２００の処理及びＳＴ２０４の処理と同時に、ＭＳＣ／ＭＧＷ１３００のシグナリング生成部１５０６は、ＵＥ１０２に送信するＩＭＳシグナリングを生成して、送信部１５０２を介して送信する（図１５に示すＳＴ１４０２）。このとき、シグナリング生成部１５０６は、当該ＩＭＳシグナリングの中に、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報を含める。例えば、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報は、非特許文献３に記載のＳＴＮ−ＳＲ（Session Transfer Number for SRVCC）等であってもよい。

【0123】

また、ＭＳＣ／ＭＧＷ１３００のシグナリング生成部１５０６は、ＵＥ１００がＰＳ網で使用していたコーデック（コーデックＡ）の他に、自網側のＣＳ網（ＭＳＣ／ＭＧＷ１３００が属するＣＳ網）でサポートしているコーデックのリストをＩＭＳシグナリングの中に含める（図１５に示すＳＴ１４０２）。この際、シグナリング解析部１５０４が、ＳＴ２０４のコネクション確立処理を待って、コネクション確立に関するシグナリングを解析し、ＵＥ１００がＣＳ網で使うコーデック情報を得て、その後、シグナリング生成部１５０６が、このコーデック情報をＩＭＳシグナリングの中に明示的に含めてもよい。

【0124】

これにより、ＵＥ１００〜ＭＳＣ／ＭＧＷ１３００ではＣＳ網を使った通信が行われ、ＭＳＣ／ＭＧＷ１３００〜ＵＥ１０２ではＰＳ網を使った通信が行われる（図１５に示すＳＴ１４０４）。

【0125】

次いで、ＵＥ１０２はＣＳ網にハンドオーバ（ＳＲＶＣＣハンドオーバ）する（図１０に示すＳＴ２００（ＳＲＶＣＣ処理）と同等の処理）。また、ＵＥ１０２はＣＳ網にハンドオーバし、ＣＳ網との間にコネクションを確立する（図１０に示すＳＴ２０４の処理（コネクション確立処理）と同等の処理）。

【0126】

ＳＴ２００の処理及びＳＴ２０４の処理と同時に、ＭＳＣ／ＭＧＷ１３０２のシグナリング生成部１５０６は、ＭＳＣ／ＭＧＷ１３００に送信するＩＭＳシグナリングを生成して、送信部１５０２を介して送信する（図１５に示すＳＴ１４０６）。このとき、シグナリング生成部１５０６は、当該ＩＭＳシグナリングの中に、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報を含める。例えば、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報は、非特許文献３に記載のＳＴＮ−ＳＲ（Session Transfer Number for SRVCC）等であってもよい。

【0127】

また、ＭＳＣ／ＭＧＷ１３０２のシグナリング生成部１５０６は、ＵＥ１０２がＰＳ網で使用していたコーデック（コーデックＡ）の他に、自網側のＣＳ網（ＭＳＣ／ＭＧＷ１３０２が属するＣＳ網）でサポートしているコーデックのリストをＩＭＳシグナリングの中に含める（図１５に示すＳＴ１４０６）。この際、シグナリング解析部１５０４が、ＳＴ２０４のコネクション確立処理を待って、コネクション確立に関するシグナリングを解析し、ＵＥ１０２がＣＳ網で使うコーデック情報を得て、その後、シグナリング生成部１５０６が、このコーデック情報をＩＭＳシグナリングの中に明示的に含めてもよい。

【0128】

ＭＳＣ／ＭＧＷ１３００の受信部１５００は、ＭＳＣ／ＭＧＷ１３０２からのＩＭＳシグナリングを受け取り、シグナリング解析部１５０４に出力する。シグナリング解析部１５０４は、このＩＭＳシグナリングを解析することにより、ＵＥ１０２がＳＲＶＣＣハンドオーバを行ったことを特定し、ＵＥ１０２がＳＲＶＣＣハンドオーバを行ったことを示す情報を端末位置判断部１５０８に出力する。また、シグナリング解析部１５０４は、このＩＭＳシグナリング（ＳＤＰオファー）に含まれるコーデックのリスト（ＭＳＣ／ＭＧＷ１３０２が属するＣＳ網でサポートしているコーデックのリスト）を、コーデック選択部１５１０に出力する。端末位置判断部１５０８は、ＵＥ１０２がＳＲＶＣＣハンドオーバを行ったことにより、ＵＥ１００及び１０２の双方ともＣＳ網に存在すると判断する。コーデック選択部１５１０は、端末位置判断部１５０８の判断結果、及び、シグナリング解析部１５０４から入力される、ＭＳＣ／ＭＧＷ１３０２が属するＣＳ網でサポートされているコーデック情報（コーデックのリスト）を用いて、利用するコーデックを選択する（図１５に示すＳＴ１４０６）。

【0129】

また、経路選択部１５１２は、端末位置判断部１５０８の判断結果に基づいて、通信データが通る経路を選択する（図１５に示すＳＴ１４０６）。これにより、ＵＥ１００とＵＥ１０２との通信は、選択された経路を通って行われる（図１５に示すＳＴ１４０８）。

【0130】

次に、図１３及び図１５に示すＭＳＣ／ＭＧＷ１３００のコーデック選択部１５１０におけるコーデックの選択方法の一例を図１６に示す。

【0131】

図１６に示すＳＴ１６００において、コーデック選択部１５１０は、端末位置判断部１５０８の判断結果に基づいて、通信中の双方の端末（ＵＥ１００，１０２）がＣＳ網に移動（存在）しているか否かを判断する。

【0132】

通信中の双方の端末がＣＳ網に移動している場合（ＳＴ１６００：ＹＥＳ）、ＳＴ１６０２において、コーデック選択部１５１０は、受信部１５００で受け取ったＩＭＳシグナリングに、通信相手端末（ＵＥ１０２）がＣＳ網で使用するコーデック情報（コーデックのリスト）が含まれるか否かを判断する。

【0133】

ＩＭＳシグナリングに通信相手端末がＣＳ網で使用するコーデック情報が含まれる場合（ＳＴ１６０２：ＹＥＳ）、ＳＴ１６０４において、コーデック選択部１５１０は、通信相手端末（ＵＥ１０２）がＣＳ網で使用するコーデック情報が、自網側の端末（ＵＥ１００）が使用中のコーデックと一致するか否かを判断する。上記コーデック情報が自網側の端末（ＵＥ１００）が使用中のコーデックと一致する場合、ＳＴ１６１４の処理に進む。

【0134】

通信中の双方の端末がＣＳ網に移動していない場合（ＳＴ１６００：ＮＯ）、ＳＴ１６０６において、コーデック選択部１５１０は、自装置（ＭＳＣ／ＭＧＷ１３００）が、ＰＳ網で使用されているコーデックに対応するか否かを判断する。自装置（ＭＳＣ／ＭＧＷ１３００）が、ＰＳ網で使われているコーデックに対応しない場合（ＳＴ１６０６：ＮＯ）、ＳＴ１６１２の処理に進む。

【0135】

ＩＭＳシグナリングに通信相手端末がＣＳ網で使用するコーデック情報が含まれない場合（ＳＴ１６０２：ＮＯ）、又は、自装置（ＭＳＣ／ＭＧＷ１３００）が、ＰＳ網で使われているコーデックに対応する場合、ＳＴ１６０８において、コーデック選択部１５１０は、ＩＭＳシグナリング（ＳＤＰオファー）によってオファーされているコーデック情報（コーデックリスト）の中に、現在自網側のＵＥ（ＵＥ１００）が使用中のコーデックが含まれるか否かを判断する。オファーされているコーデックリストの中に、現在自網側のＵＥ（ＵＥ１００）が使用中のコーデックが含まれる場合（ＳＴ１６０８：ＹＥＳ）、ＳＴ１６１４の処理に進む。

【0136】

オファーされているコーデックリストの中に、現在自網側のＵＥ（ＵＥ１００）が使用中のコーデックが含まれない場合（ＳＴ１６０８：ＮＯ）、ＳＴ１６１０において、コーデック選択部１５１０は、ＩＭＳシグナリング（ＳＤＰオファー）によってオファーされているコーデックリストの中に、自装置（ＭＳＣ／ＭＧＷ１３００）がサポートしているコーデックが含まれるか否かを判断する。オファーされているコーデックリストの中に、自装置がサポートしているコーデックが含まれる場合（ＳＴ１６１０：ＹＥＳ）、ＳＴ１６１６の処理に進む。オファーされているコーデックリストの中に、自装置がサポートしているコーデックが含まれない場合（ＳＴ１６１０：ＮＯ）、ＳＴ１６１８の処理に進む。

【0137】

ＳＴ１６１２では、コーデック選択部１５１０は、ＰＳ網で使用されているコーデックを選択する。

【0138】

ＳＴ１６１４では、コーデック選択部１５１０は、自網側の端末（ＵＥ１００）が使用中のコーデックを、使用するコーデックとして選択する。

【0139】

ＳＴ１６１６では、コーデック選択部１５１０は、オファーされているコーデックリストのうち、自装置（ＭＳＣ／ＭＧＷ１３００）がサポートしているコーデックの中から、使用するコーデックを選択する。

【0140】

ＳＴ１６１８では、コーデック選択部１５１０は、エラーを選択する。

【0141】

このようにして、ＭＳＣ／ＭＧＷ１３００，１３０２は、ハンドオーバにより発生したＩＭＳシグナリングの中に、自網側のＣＳ網でサポートしているコーデックのリストを含める。また、上記ＩＭＳシグナリングを受け取ると、ＭＳＣ／ＭＧＷ１３００（ＭＳＣ／ＭＧＷ１３０２）は、まず、通信中の双方の端末がＣＳ網に存在すると判断する。更に、ＭＳＣ／ＭＧＷ１３００（ＭＳＣ／ＭＧＷ１３０２）は、ＩＭＳシグナリングの送信先のＭＳＣ／ＭＧＷが属するＣＳ網でサポートされているコーデック情報を用いて、利用するコーデックを選択する。具体的には、ＭＳＣ／ＭＧＷ１３００，１３０２は、通信中の双方の端末（ＵＥ１００，１０２）が同一のコーデックを使用可能な場合には、双方の端末で当該同一のコーデックが使用されるように、利用するコーデックを選択する。

【0142】

すなわち、一方の端末（ＵＥ１００）がＣＳ網にハンドオーバし、他方の端末（ＵＥ１０２）がＣＳ網にハンドオーバした場合において、例えば、ＵＥ１００側のＣＳ網に属するＭＳＣ／ＭＧＷ１３００は、ＵＥ１０２側のＣＳ網に属するＭＳＣ／ＭＧＷ１３０２から、ＵＥ１０２側のＣＳ網でサポートしているコーデックリスト（コーデック群）を含むメッセージを受信し、上記コーデックリスト、及び、ＵＥ１００が使用するコーデック（変更後のコーデック）を用いて、ＵＥ１０２が使用するコーデックを選択する。例えば、ＭＳＣ／ＭＧＷ１３００は、受信したコーデックリストに、ＵＥ１００が使用するコーデック（変更後のコーデック）が含まれる場合、ＵＥ１０２が使用するコーデックとして、ＵＥ１００が使用するコーデックを選択する。

【0143】

これにより、双方の端末（ＵＥ１００，１０２）では、可能であれば同一コーデックが使用されるので、ＭＳＣ／ＭＧＷ１３００，１３０２では、トランスコーディングが行われない。よって、本実施の形態によれば、通信中のＵＥ１００及びＵＥ１０２の双方がＳＲＶＣＣハンドオーバを行った場合でも、ＭＳＣ／ＭＧＷ１３００，１３０２における、トランスコーディングを最小限に抑えることができる。

【0144】

また、実施の形態１では、ＭＳＣ／ＭＧＷ３００がコーデック帯域幅の変更を検出し、ＵＥ１０２に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する方法について説明した。これに対して、本実施の形態では、ＭＳＣ／ＭＧＷ１３００，１３０２は、自網側の端末がＣＳ網で使うコーデック情報を得た後、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングに代えて、当該コーデック情報をＩＭＳシグナリングの中に明示的に含めて通信相手側端末に送信する。この場合でも、実施の形態１と同様、一方又は双方のＵＥのネットワーク状況が変わった場合でも、ＵＥ間のコーデックの帯域幅を同等に維持することができる。

【0145】

なお、端末位置判断部１５０８により、ＵＥ１００、１０２の双方ともＣＳ網に存在すると判断された場合、経路選択部１５１２は、ネットワーク側の経路を全てＣＳ網用の経路に切り替えてもよい。端末位置判断部１５０８は、この判断方法として、例えば両方の端末がｒＳＲＶＣＣに対応しているか否かで判断してもよい。すなわち、両方の端末（ＵＥ１００，１０２）がｒＳＲＶＣＣに対応していない場合、経路選択部１５１２は、ネットワーク側の経路をＣＳ網用の経路に切り替えてもよい。なお、両方の端末がｒＳＲＶＣＣに対応しているかどうかに関しては、非特許文献３に記載の、ＳＲＶＣＣサポートの登録又はＳＲＶＣＣサポートしているか否かの入手方法と同等の方法で実現できる。

【0146】

また、端末（例えば図１７に示すＵＥ１０２）は、エンコードされる入力信号の帯域幅の制限を依頼するシグナリング等の受信により、通信相手側端末（例えば図１７に示すＵＥ１００）がＳＲＶＣＣによるハンドオーバを行ったことを判断した場合、自装置がＳＲＶＣＣによるハンドオーバを行う際のシグナリング（図１５に示すＳＴ２００又はＳＴ２０４）によって、自網側ＭＳＣ／ＭＧＷ（例えば、図１７に示すＭＳＣ／ＭＧＷ１３１０）に対し、通信相手側端末（ＵＥ１００）が既にＳＲＶＣＣによるハンドオーバを行っていることを通知してもよい。これにより、ＭＳＣ／ＭＧＷ１３１０の端末位置判断部１５０８は、双方の端末（ＵＥ１００，１０２）がＣＳ網にハンドオーバしたと判断し、ＩＭＳシグナリング（ＳＤＰオファー）のコーデックリストの中に、ＰＳ網のみでサポートしているコーデックを含めることを回避できる。つまり、ＭＳＣ／ＭＧＷ１３１０は、ＣＳ網でサポートしているコーデックのみをＳＤＰオファーに含めることができる（図１７参照）。この際、ＭＳＣ／ＭＧＷ１３１０は、自装置がＭＧＷであることを明示的に伝えてもよい（例えば図１７参照）。また、上記通知を受け取ったＭＳＣ／ＭＧＷ１３００は、ＣＳ網同士で通信することを決定してもよい（例えば図１７参照）。また、上記通知は、例えば、ＵＥ１０２がＣＳ網にハンドオーバした際にＵＥ１０２から送信される既存のシグナリングに含まれてもよいし、新しいシグナリングでもよい。また、上記通知は、ＵＥ１０２がＣＳ網にハンドオーバする以前に、ＭＭＥ（図示せず）に対して送信されるシグナリングに含まれてもよい（例えば、非特許文献４参照）。

【0147】

（実施の形態４）
本実施の形態では、通信を行う双方のＵＥがｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へのハンドオーバを行う場合、又は、一方のＵＥがｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行い、他方のＵＥがＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行う場合について説明する。本実施の形態では、ｅＳＲＶＣＣ方式において、通信データはＡＴＧＷでアンカーされ、ＡＴＧＷにおいてトランスコーディングが行われると仮定する。

【0148】

図１８は、本発明の実施の形態４に係る移動通信ネットワークの一部を示す構成である。なお、図１８に示す各ノードの動作は前述（例えば図３及び図５）した通りである。

【0149】

図１８において、ＵＥ１００及びＵＥ１０２の双方は、最初ｅ−ＵＴＲＡＮに存在し、ＰＳ網でＶｏＬＴＥ通信を行っている。この際、上述したコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）が使用されていると仮定する。図１８では、ＵＥ１００側のネットワーク、及び、ＵＥ１０２側のネットワークの双方ともｅＳＲＶＣＣに対応していると仮定する。これより、ＵＥ１００とＵＥ１０２との間の現在の通信経路は、ＡＴＣＦ／ＡＴＧＷ１７００及びＡＴＣＦ／ＡＴＧＷ１７０２を経由した、Ｐａｔｈ Ａ、Ｐａｔｈ Ｂ及びＰａｔｈ Ｃとなる。

【0150】

なお、図１８では、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２を一つのノードとして表しているが、別々のノードでもよい。また、図１８において、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＵＥ１００とＵＥ１０２との間の通信経路としてＡＴＣＦ／ＡＴＧＷ１７００及びＰａｔｈ Ｂは存在しないので、Ｐａｔｈ Ａは、ＵＥ１００とＡＴＣＦ／ＡＴＧＷ１７０２との間に確立される。同様に、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合には、通信経路としてＡＴＣＦ／ＡＴＧＷ１７０２及びＰａｔｈ Ｂは存在しないので、Ｐａｔｈ Ｃは、ＵＥ１０２とＡＴＣＦ／ＡＴＧＷ１７００との間に確立される。

【0151】

次に、ＵＥ１００、ＵＥ１０２のそれぞれがｅＳＲＶＣＣによりハンドオーバを行ったとする。この場合、非特許文献３によると、ハンドオーバ後のＵＥ１００とＵＥ１０２との間の通信経路は、ＭＳＣ／ＭＧＷ１７０４、ＡＴＣＦ／ＡＴＧＷ１７００、ＡＴＣＦ／ＡＴＧＷ１７０２及びＭＳＣ／ＭＧＷ１７０６を経由した、Ｐａｔｈ Ｄ、Ｐａｔｈ Ｅ、Ｐａｔｈ Ｂ、Ｐａｔｈ Ｇ、及びＰａｔｈ Ｆとなる。

【0152】

なお、図１８において、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＵＥ１００とＵＥ１０２との間の通信路としてＡＴＣＦ／ＡＴＧＷ１７００及びＰａｔｈ Ｂは存在しないので、Ｐａｔｈ ＥはＭＳＣ／ＭＧＷ１７０４とＡＴＣＦ／ＡＴＧＷ１７０２との間に確立される。同様に、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＵＥ１００とＵＥ１０２との間の通信経路としてＡＴＣＦ／ＡＴＧＷ１７０２及びＰａｔｈ Ｂは存在しないので、Ｐａｔｈ Ｇは、ＭＳＣ／ＭＧＷ１７０６とＡＴＣＦ／ＡＴＧＷ１７００との間に確立される。

【0153】

ここで、例えばＵＥ１００，１０２がＣＳ網にハンドオーバした際に使用するコーデックを双方ともＡＭＲ−ＷＢであるとする。この場合、ＵＥ１００からＡＴＣＦ／ＡＴＧＷ１７００までの通信データはＡＭＲ−ＷＢでエンコードされる。次いで、ＡＴＧＷ１７００はＡＭＲ−ＷＢからコーデックＡにトランスコーディングを行う。よって、ＡＴＧＷ１７００からＡＴＧＷ１７０２までの間の通信データはコーデックＡでエンコードされる。次いで、ＡＴＧＷ１７０２は再びコーデックＡからＡＭＲ−ＷＢにトランスコーディングを行う。よって、ＡＴＧＷ１７０２からＵＥ１０２までの間の通信データはＡＭＲ−ＷＢでエンコードされる。

【0154】

なお、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＡＴＧＥ１７００の代わりにＭＳＣ／ＭＧＷ１７０４でトランスコーディングが行われる。同様に、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＡＴＧＥ１７０２の代わりにＭＳＣ／ＭＧＷ１７０６でトランスコーディングが行われる。

【0155】

本実施の形態では、通信中のＵＥ１００及びＵＥ１０２の双方がｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へのハンドオーバを行う場合、又は、一方のＵＥがｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行い、他方のＵＥがＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行う場合について、実施の形態３と同様、トランスコーディングを最小限に抑える方法について説明する。

【0156】

まず、図１８に示すＡＴＣＦ／ＡＴＧＷ１７００、１７０２、及び、ＵＥ１００、１０２について説明する。

【0157】

図１９は、本実施の形態に係るＡＴＣＦ／ＡＴＧＷ１７００、１７０２の構成を示すブロック図である。なお、図１９に示すＡＴＣＦ／ＡＴＧＷ１７００、１７０２は、図示される機能ブロックの他に、図８に示される機能ブロック又はその他機能ブロックを具備していてもよい。

【0158】

図１９に示すＡＴＣＦ／ＡＴＧＷ１７００、１７０２において、受信部１９００は、通信データ、シグナリング等を受信する。

【0159】

送信部１９０２は、通信データ、シグナリング等を送信する。

【0160】

シグナリング解析部１９０４は、ＳＲＶＣＣ処理又はｅＳＲＶＣＣ処理のためのシグナリング、又は、ＩＭＳのシグナリング（ＩＭＳシグナリング）等を解析する。シグナリング解析部１９０４は、シグナリング解析の結果を、シグナリング生成部１９０６、端末位置判断部１９０８及びコーデック選択部１９１０に通知する。

【0161】

シグナリング生成部１９０６は、シグナリング解析部１９０４のシグナリング解析結果等に基づいて、シグナリングを生成する。

【0162】

端末位置判断部１９０８は、シグナリング解析部１９０４のシグナリング解析結果に基づいて、通信中の双方の端末（ＵＥ１００、１０２）がＰＳ網に存在するのか、ＣＳ網に存在するのかを判断する。端末位置判断部１９０８は、判断結果をコーデック選択部１９１０及び経路選択部１９１２に出力する。

【0163】

コーデック選択部１９１０は、シグナリング解析部１９０４のシグナリング解析結果及び端末位置判断部１９０８の判断結果に基づいて、利用するコーデック、又はコーデック候補を選択する。

【0164】

経路選択部１９１２は、端末位置判断部１９０８の判断結果に基づいて、通信データが通る経路を選択する。

【0165】

図２０は、本実施の形態に係るＵＥ１００、１０２の構成を示すブロック図である。ＵＥ１００、１０２は、図示される機能ブロックの他に、図１２に示される機能ブロック又はその他機能ブロックを具備していてもよい。なお、図２０に示すＵＥ１００，１０２において、受信部７００及び送信部７０２は、図１２と同一動作を行う構成部であり、その説明を省略する。

【0166】

図２０に示すＵＥ１００、１０２において、通信相手コーデック変更検出部２０００は、通信相手が使用しているコーデックが変更になったことを検出する。通信相手が使用しているコーデックが変更される理由には、例えば、ＰＳ網からＣＳ網に移動したことが挙げられる。また、通信相手コーデック変更検出部２０００におけるコーデック変更の検出方法は、例えば、実施の形態１で示したような、帯域制限通知等のシグナリングをネットワークから受け取る方法、及び、実施の形態２で示したような、通信相手が使用しているコーデックの帯域が制限されたことを検出する方法等が挙げられる。

【0167】

シグナリング生成部２００２は、通信相手コーデック変更検出部２０００で通信相手のコーデックが変更になったことが検出された場合、通信相手のコーデックが変更されたことをネットワークに通知するためのシグナリングを生成する。

【0168】

次に、本実施の形態におけるＵＥ１００，１０２、及び、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２の動作の一例について説明する。ここでは、ＵＥ１００側のネットワーク、及び、ＵＥ１０２側のネットワークの双方がｅＳＲＶＣＣに対応していると仮定する。

【0169】

図２１は、図１８に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。

【0170】

ＵＥ１００及びＵＥ１０２は、ｅ−ＵＴＲＡＮに接続処理を行い、ＩＭＳに対してＶｏＬＴＥに関する登録をする際、例えば、ＡＴＣＦ（ＡＴＣＦ／ＡＴＧＷ１７００，１７０２）に関する情報をＳＣＣ ＡＳ、ＨＳＳ（図示せず）又はＭＭＥ（図示せず）に送信し、送信先で当該情報が保持される（例えば、非特許文献５参照）。更に、発呼の際（本実施の形態では、ＵＥ１００からＵＥ１０２への発呼と仮定する。ＵＥ１０２からＵＥ１００への発呼の場合も同様である。）には、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２において、ＡＴＣＦは、ＡＴＧＷでセッションをアンカーするかどうかを判断する（例えば、非特許文献３又は非特許文献５を参照）。

【0171】

その後、ＵＥ１００及びＵＥ１０２は、共にｅ−ＵＴＲＡＮに接続し、ＶｏＬＴＥ通信を行っている。この時、音声コーデックとして、前述のコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）が使用されているものとする（図２１に示すＳＴ１８００）。

【0172】

次いで、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバする。このとき、図１０に示すＳＴ２００の処理（ＳＲＶＣＣ処理）及びＳＴ２０４の処理（コネクション確立処理）と同等の処理が行われる。また、ＳＴ２００の処理及びＳＴ２０４の処理と同時に、図４に示すＳＴ１１０２の処理と同等の処理が行われる。これにより、ＵＥ１００とＵＥ１０２との間のデータ通信経路がＭＳＣ／ＭＧＷ１７０４経由に切り替わる（図２１に示すＳＴ１８０２）。

【0173】

この際、ＡＴＣＦ／ＡＴＧＷ１７００のシグナリング生成部１９０６は、ＵＥ１００がＣＳ網で使用するコーデック（例えばＡＭＲ）を含むメッセージを生成し、当該メッセージを送信部１９０２を介して、ＳＣＣ ＡＳ／ＣＳＣＦ１７０８に通知する（図２１に示すＳＴ１８０２’）。この通知は非特許文献３に記載のAccess Transfer Updateメッセージと共に通知されてもよい。この後、実施の形態１で示したように、ＡＴＣＦ／ＡＴＧＷ１７００は、ＵＥ１０２に対して帯域制限通知を送信してもよい。

【0174】

ＵＥ１０２の通信相手コーデック変更検出部２０００は、ＵＥ１００のコーデックがコーデックＡから変更になったことを検出する（図２１に示すＳＴ１８０４）。

【0175】

次に、ＵＥ１０２もＰＳ網からＣＳ網にハンドオーバする。このとき、ＵＥ１０２のシグナリング生成部２００２は、通信相手であるＵＥ１００のコーデックが変更になっていることをネットワークに通知するためのシグナリングを生成する。このシグナリングは、例えば、ＵＥ１０２がＣＳ網にハンドオーバした際に、ＵＥ１０２から送信される既存のシグナリングに含まれてもよく、新しいシグナリングに含まれてもよい（図２１に示すＳＴ１８０６）。また、上記通知は、ＵＥ１０２がＣＳ網にハンドオーバする以前に、ＭＭＥ（図示せず）に対し送信されるシグナリングに含まれ、ＭＭＥからＭＳＣ／ＭＧＷ１７０６に通知されてもよい（例えば、非特許文献４参照）。

【0176】

ＵＥ１０２からのシグナリングを受け取ったＭＳＣ／ＭＧＷ１７０６は、ＵＥ１０２の通信相手であるＵＥ１００のコーデックが変更になっていることを検知し、ＵＥ１００のコーデックが変更になっていることを示す情報を、ＡＴＣＦ／ＡＴＧＷ１７０２に送信するＩＮＶＩＴＥメッセージに含める。

【0177】

このＩＮＶＩＴＥメッセージを受け取ったＡＴＣＦ／ＡＴＧＷ１７０２のシグナリング解析部１９０４は、ＵＥ１０２の通信相手であるＵＥ１００のコーデックが変更になっていることを検出する。そこで、ＡＴＣＦ／ＡＴＧＷ１７０２のシグナリング生成部１９０６は、ＳＣＣ ＡＳ／ＣＳＣＦ１７０８に対して、ＵＥ１００のコーデック問い合わせのためのシグナリングを生成し、当該シグナリングを送信部１９０２を介して送信する（図２１に示すＳＴ１８０８）。

【0178】

ＡＴＣＦ／ＡＴＧＷ１７０２の受信部１９００は、ＳＴ１８０８で送信したシグナリングに対する返信シグナリングをＳＣＣ ＡＳ／ＣＳＣＦ１７０８から受け取る。そして、ＡＴＣＦ／ＡＴＧＷ１７０２のシグナリング解析部１９０４は、この返信シグナリングを解析し、解析結果（ＵＥ１００のコーデックに関する情報）に基づいて、ＡＴＣＦ／ＡＴＧＷ１７００との間でコーデック折衝を行い（図２１に示すＳＴ１８１０）、コーデックを選択する（図２１に示すＳＴ１８１２）。なお、コーデック折衝は、ＡＴＣＦ／ＡＴＧＷ１７０２とＳＣＣ ＡＳ／ＣＳＣＦ１７０８との間、及び、ＳＣＣ ＡＳ／ＣＳＣＦ１７０８とＡＴＣＦ／ＡＴＧＷ１７００との間で行われてもよい（すなわち、ＳＣＣ ＡＳでアンカーしてもよい）。なお、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、ＳＣＣ ＡＳ／ＣＳＣＦ１７０８を介さずに、コーデック折衝を行ってもよい。この場合、図２１に示すＳＴ１８０２の処理及びＳＴ１８０８の処理は不要となる。

【0179】

このようにして、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、端末（ＵＥ１００，１０２）がハンドオーバした場合、ハンドオーバした端末がＣＳ網で使用するコーデックを含むメッセージを生成し、当該メッセージをＳＣＣ ＡＳ／ＣＳＣＦ１７０８に通知する。この場合、ハンドオーバした端末と通信している通信相手端末は、ハンドオーバした端末のコーデックが変更されたことを検出している。また、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、ハンドオーバした端末のコーデックが変更されたことを検出している通信相手端末もハンドオーバした場合、当該通信相手端末からの通知によって、最初にハンドオーバした端末のコーデックが変更になっていることを検出すると、ＳＣＣ ＡＳ／ＣＳＣＦ１７０８に対して、当該通信相手のコーデック問い合わせを行う。そして、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、問い合わせにより得たコーデック（最初にハンドオーバした端末のコーデック）に関する情報に基づいて、コーデック折衝を行い、コーデックを選択する。例えば、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、通信中の双方の端末（ＵＥ１００，１０２）が同一のコーデックを使用可能な場合には、双方の端末で当該同一のコーデックが使用されるように、利用するコーデックを選択する。

【0180】

すなわち、一方の端末（ＵＥ１００）がＣＳ網にハンドオーバした後に、他方の端末（ＵＥ１０２）がＣＳ網にハンドオーバした場合において、ＡＴＣＦ／ＡＴＧＷ１７０２は、ＳＣＣ ＡＳ／ＣＳＣＦ１７０８への問い合わせにより、ＵＥ１００が使用するコーデック（変更後のコーデック）を含むメッセージを受信し、ＵＥ１０２側のＭＳＣ／ＭＧＷ１７０６から、ＵＥ１００がＣＳ網にハンドオーバしたことを示す情報を含むメッセージを受信し、ＵＥ１００がＣＳ網にハンドオーバしたことを示す情報を受信した場合、上記ＵＥ１００が使用するコーデックに基づいて、ＵＥ１０２が使用するコーデックを選択する。

【0181】

これにより、双方の端末（ＵＥ１００，１０２）では、実施の形態３と同様、可能であれば同一コーデックが使用されるので、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２では、トランスコーディングが行われない。よって、本実施の形態によれば、通信中のＵＥ１００及びＵＥ１０２の双方がｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へのンドオーバを行う場合、実施の形態３と同様、トランスコーディングを最小限に抑えることができる。

【0182】

なお、端末位置判断部１９０８により、ＵＥ１００、１０２の双方ともＣＳ網に存在すると判断された場合、経路選択部１９１２は、ネットワーク側の経路を全てＣＳ網用の経路に切り替えてもよい。端末位置判断部１９０８は、この判断方法として、例えば両方の端末がｒＳＲＶＣＣに対応しているか否かで判断してもよい。すなわち、両方の端末（ＵＥ１００，１０２）がｒＳＲＶＣＣに対応していない場合、経路選択部１９１２は、ネットワーク側の経路をＣＳ網用の経路に切り替えてもよい。なお、両方の端末がｒＳＲＶＣＣに対応しているかどうかに関しては、非特許文献３に記載の、ＳＲＶＣＣサポートの登録又はＳＲＶＣＣサポートしているか否かの入手方法と同等の方法で実現できる。

【0183】

また、端末（例えば図２１に示すＵＥ１０２）は、エンコードされる入力信号の帯域幅の制限を依頼するシグナリング等の受信により、通信相手側端末（例えば図２１に示すＵＥ１００）がＳＲＶＣＣ又はｅＳＲＶＣＣによるハンドオーバを行ったことを判断した場合、自装置がｅＳＲＶＣＣによるハンドオーバを行う際のシグナリング（図２１に示すＳＴ２００／ＳＴ２０４）によって、自網側ＭＳＣ／ＭＧＷ（例えば、図２１に示すＭＳＣ／ＭＧＷ１７０６）に対し、通信相手側端末（ＵＥ１００）が既にＳＲＶＣＣ又はｅＳＲＶＣＣによるハンドオーバを行っていることを通知してもよい。これにより、ＭＳＣ／ＭＧＷ１７０６の端末位置判断部１９０８は、双方の端末（ＵＥ１００，１０２）がＣＳ網にハンドオーバしたと判断し、ＩＭＳシグナリング（ＳＤＰオファー）のコーデックリストの中に、ＰＳ網のみでサポートしているコーデックを含めることを回避できる。この通知は、例えば、ＵＥ１０２がＣＳ網にハンドオーバした際にＵＥ１０２から送られる既存のシグナリングに含まれてもよいし、新しいシグナリングでもよい（図２１に示すＳＴ１８０６）。また、上記通知は、ＵＥ１０２がＣＳ網にハンドオーバする以前に、ＭＭＥ（図示せず）に対し送信されるシグナリングに含まれてもよい（例えば、非特許文献４参照）。

【0184】

また、図１９に示すように、ＭＳＣ／ＭＧＷ１７０４，１７０６は、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２と同等の機能を具備してもよい。図１８において、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合、ＭＳＣ／ＭＧＷ１７０４のシグナリング解析部１９０４は、ＵＥ１００がＣＳ網にハンドオーバした際、ＣＳ網で使用するコ−デックを含むシグナリングを解析し、ＵＥ１００がＣＳ網で使用するコーデックの情報を得る。次いで、ＭＳＣ／ＭＧＷ１７０４のシグナリング生成部１９０６は、ＵＥ１００がＣＳ網で使用するコーデックの情報を生成し、ＳＣＣ ＡＳ／ＣＳＣＦ１７０８に通知する。この通知は、ＩＮＶＩＴＥメッセージに含まれてもよい。また、図１８において、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合、ＭＳＣ／ＭＧＷ１７０６のシグナリング解析部１９０４は、ＵＥ１０２から、通信相手であるＵＥ１００のコーデックが変更になっていることを通知する内容を含むシグナリングを受け取った際、ＵＥ１０２の通信相手であるＵＥ１００のコーデックが変更になっていることを検知する。次いで、ＭＳＣ／ＭＧＷ１７０６のシグナリング生成部１９０６は、ＳＣＣ ＡＳ／ＣＳＣＦ１７０８に対してＵＥ１００のコーデックを問い合わせるシグナリングを生成し、ＳＣＣ ＡＳ／ＣＳＣＦ１７０８に送信する。ＳＣＣ ＡＳ／ＣＳＣＦ１７０８より返信シグナリングを受け取ると、ＭＳＣ／ＭＧＷ１７０６のシグナリング解析部１９０４は、この返信シグナリングを解析し、解析結果に基づいて、ＵＥ１００側でトランスコーディングを行うノード（ＭＳＣ／ＭＧＷ１７０４又はＡＴＣＦ／ＡＴＧＷ１７００）との間でコーデック折衝を行い、コーデックを選択する。なお、コーデック折衝は、ＭＳＣ／ＭＧＷ１７０６とＳＣＣ ＡＳ／ＣＳＣＦ１７０８との間、及び、ＳＣＣ ＡＳ／ＣＳＣＦ１７０８とＵＥ１００側でトランスコーディングを行うノードとの間で行われてもよい（すなわち、ＳＣＣ ＡＳでアンカーしてもよい）。これにより、一方のＵＥがｅＳＲＶＣＣ方式により、他方のＵＥがＳＲＶＣＣ方式によって、ＰＳ網からＣＳ網へハンドオーバを行う場合でも、実施の形態３と同様、トランスコーディングを最小限に抑えることができる。

【0185】

（実施の形態５）
実施の形態１、３及び４では、ＭＳＣ／ＭＧＷ又はＡＴＣＦ／ＡＴＧＷが、セッション途中における片方のＵＥの通信データの帯域幅の変更を検出した場合、もう片方のＵＥに対し帯域制限通知を行う方法を説明した。これに対して、本実施の形態では、帯域制限通知を送る代わりに、又は帯域制限通知を送る事に加え、ＭＳＣ／ＭＧＷ又はＡＴＣＦ／ＡＴＧＷが送る通信データ、又は通信データのＲＴＰペイロードのヘッダ部に帯域情報を明示的に含める方法を説明する。

【0186】

例えば、実施の形態１において、ＭＳＣ／ＭＧＷ３００のコーデック帯域幅検出部６０６でＵＥ１００の帯域幅変更を検出し、変更判断部６０８でＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であり、かつ、帯域幅制限が必要であると判断された場合、ＭＳＣ／ＭＧＷ３００からＵＥ１０２へ送られる通信データの帯域幅も制限する。この際、ＭＳＣ／ＭＧＷ３００が送る通信データそのもの、又は通信データが格納されるＲＴＰのペイロードヘッダ部に、明示的に変更後の帯域幅情報を含める。

【0187】

ＲＴＰペイロードヘッダ部に変更後の帯域情報を含める場合、帯域情報を含めるパケットは、帯域変更後のある一定期間（例えば２００ｍｓｅｃ）に送られるパケット、又はある一定個数のパケット（例えば１０パケット）に限る。

【0188】

受信側（ＵＥ１０２）では、ある一定期間以上（例えば１５０ｍｓｅｃ以上）又はある特定個数（例えば５パケット以上）のＲＴＰのペイロードヘッダに帯域情報が付加されている事を検出すると、その後送られてくるＲＴＰペイロードヘッダに帯域情報が付加されていなかった場合においても、格納されている通信データの帯域幅が制限され続けると判断する。

【0189】

帯域制限通知を受け取ったＵＥ１０２が、帯域を制限した通信データをＭＧＷ３００に送信する場合においても同様に、ある一定期間（例えば２００ｍｓｅｃ）に送られるパケット、又はある一定個数のパケット（例えば１０パケット）のＲＴＰペイロードヘッダ部に帯域情報を付加する。受信側（ＭＧＷ３００）では、ある一定期間以上（例えば１５０ｍｓｅｃ以上）又はある特定個数（例えば５パケット以上）のＲＴＰのペイロードヘッダに帯域情報が付加されている事を検出すると、その後送られてくるＲＴＰペイロードヘッダに帯域情報が付加されていなかった場合においても、格納されている通信データの帯域幅が制限され続けると判断する。

【0190】

また、実施の形態２において、帯域制限通知を受け取る代わりに、ＵＥ１０２のデータ解析部１２００において、データそのものの帯域幅が一定時間以上制限されている事を検出し、送信するデータの帯域を制限する方法を説明した。これに代えて、本実施の形態の上述の方法（ある一定期間以上（例えば１５０ｍｓｅｃ以上）又はある特定個数（例えば５パケット以上）のＲＴＰのペイロードヘッダに帯域情報が付加されている事）を用いて、コーデックモード変更部１２０２において、帯域の変更を決定してもよい。

【0191】

また、実施の形態１、３及び４において、帯域制限通知そのものを、ＲＴＰペイロードヘッダに含めてもよい。帯域制限通知をＲＴＰペイロードヘッダに含める場合においても、帯域制限通知を含めるパケットは、帯域変更通知が必要であると判定された後のある一定期間（例えば１００ｍｓｅｃ）に送られるパケット、又はある一定個数のパケット（例えば５パケット）に限る。受信側（ＵＥ１０２）では、ある一定期間以上（例えば２０ｍｓｅｃ以上）又はある特定個数（例えば１パケット以上）のＲＴＰのペイロードヘッダに帯域制限通知が付加されている事を検出すると、その後送られてくるＲＴＰペイロードヘッダに帯域制限通知が付加されていなかった場合においても、帯域幅の制限（変更）を依頼されていることが通知されたと判断する。尚、帯域制限通知をＲＴＰペイロードヘッダに含める場合には、帯域制限通知と共に上述の帯域情報を含めてもよい。

【0192】

これにより、送信データの帯域幅の変更を、セッション途中でも明示的に通信相手に通知する事ができる。

【0193】

以上、本発明の各実施の形態について説明した。

【0194】

なお、上記各実施の形態では、ＡＴＣＦ／ＡＴＧＷ、ＭＳＣ／ＭＧＷ、ＳＣＣ ＡＳ／ＣＳＣＦをそれぞれ一つのノードとして説明したが、別々のノードでもよい。すなわち、ＡＴＣＦとＡＴＧＷとの間、ＭＳＣとＭＧＷとの間、及び、ＳＣＣ ＡＳとＣＳＣＦとの間のそれぞれにおいて、上述した機能をいずれか一方若しくは両方が具備していればよい。また、ＡＴＣＦとＡＴＧＷとの間、ＭＳＣとＭＧＷとの間、及び、ＳＣＣ ＡＳとＣＳＣＦとの間のそれぞれで必要な情報をやり取りしてもよい。

【0195】

また、上記各実施の形態において、ＵＥ１００及びＵＥ１０２の双方ともＣＳ網へのハンドオーバ（ＳＲＶＣＣ、ｅＳＲＶＣＣ等によるハンドオーバ）をサポートしている場合には、ＰＳ網上でのセッション折衝の際、ＣＳ網でサポートされているコーデック若しくはＣＳ網でサポートされているコーデックと互換性のあるコーデックが初めから選択されてもよい。

【0196】

また、上記各実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、これに限らず、音楽、音響、画像等に関しても、本発明は適用可能である。

【0197】

また、本発明は、上記各実施の形態に限定されず、種々変更して実施することが可能である。

【0198】

また、上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。

【0199】

また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

【0200】

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）または、ＬＳＩ内部の回路セルの接続若しくは設定を再構成可能なリコンフィギュラブル／プロセッサを利用してもよい。

【0201】

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

【0202】

２０１１年６月９日出願の特願２０１１−１２９４２２、２０１１年１１月１１日出願の特願２０１１−２４７３３０および２０１２年２月１５日出願の特願２０１２−０３０４１９の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。

【産業上の利用可能性】

【0203】

本発明は、通信中の通信端末の一方が利用するコーデックが変更になった場合、通信相手の利用するコーデックのエンコードされる入力信号の帯域幅又はエンコーディングビットレートを調整する機能を有するため、トランスコーディングによる品質劣化を抑える事に有用である。

【符号の説明】

【0204】

１００，１０２ ＵＥ
２００，２０２，２０４，２０６，１１００，１１０２，１１０４，１１０６ シグナリング
３００，１３００，１３０２，１３１０，１７０４，１７０６ ＭＳＣ／ＭＧＷ
１１２０，１７００，１７０２ ＡＴＣＦ／ＡＴＧＷ
６００，７００，１５００，１９００ 受信部
６０２，７０２，１５０２，１９０２ 送信部
６０４ コーデック検出部
６０６ コーデック帯域幅検出部
６０８ 変更判断部
６１０，１５０６，１９０６，２００２ シグナリング生成部
６１２ トランスコーディング部
７０４ コーデック折衝部
７０６，１５１０，１９１０ コーデック選択部
７０８ 帯域幅決定部
７１０，１５０４，１９０４ シグナリング解析部
７１２，１２０２ コーデックモード変更部
１２００ データ解析部
１５０８，１９０８ 端末位置判断部
１５１２，１９１２ 経路選択部
１７０８ ＳＣＣ ＡＳ／ＣＳＣＦ
２０００ 通信相手コーデック変更検出部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】