(57)【要約】ＩＭＳノード３１０は、第１の網において通信を行う２つの端末のうち一方の端末が第１の網と異なる第２の網にハンドオーバした際に、２つの端末で使用されるコーデック及びコーデックモードを判断する通信ノードに関する。判断部５０６は、第１の網における通信で使用しているコーデック及びコーデックモードを示す情報と、一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、第２の網がサポートしているコーデック及びコーデックモードを示す情報と、の共通部分を２つの端末で使用されるコーデック及びコーデックモードに設定し、シグナリング生成部５１０は、設定された２つの端末で使用されるコーデック及びコーデックモードへの変更を２つの端末へ要求するためのシグナリングを生成する。
2016185649.tif 000002
【特許請求の範囲】
【請求項１】
第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末で使用されるコーデック及びコーデックモードを判断する通信ノードであって、
前記第１の網における通信で使用しているコーデック及びコーデックモードを示す情報と、
前記一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、
前記第２の網がサポートしているコーデック及びコーデックモードを示す情報と、
の共通部分を前記２つの端末で使用されるコーデック及びコーデックモードに設定する判断部と、
設定された前記２つの端末で使用されるコーデック及びコーデックモードへの変更を前記２つの端末へ要求するためのシグナリングを生成する生成部と、
を具備する通信ノード。
【請求項２】
前記判断部は、前記共通部分が存在しない場合に、
前記第１の網における通信で使用しているコーデックに、別のコーデックとの互換モードが存在し、かつ、前記一方の端末がサポートしているコーデック及び前記第２の網がサポートしているコーデックに、前記別のコーデックが含まれる場合、前記別のコーデック又は前記別のコーデックとの互換モードを、前記２つの端末で使用されるコーデック及びコーデックモードに設定する、
請求項１に記載の通信ノード。
【請求項３】
前記判断部は、サービスオペレータのポリシが存在する場合には前記ポリシに従って前記２つの端末で使用されるコーデック及びコーデックモードを設定し、前記ポリシが存在しない場合には前記共通部分を前記２つの端末で使用されるコーデック及びコーデックモードに設定する、
請求項１又は２に記載の通信ノード。
【請求項４】
第１の網において通信を行う２つの端末のうち、前記第１の網と異なる網にハンドオーバする端末であって、
ハンドオーバによる接続先網を検出する接続先検出部と、
前記接続先網で使用するコーデックを検出するコーデック検出部と、
前記検出された接続先網と、前記検出されたコーデックとに基づいて、前記２つの端末で使用されるコーデックで用いるエンコード方式の制限が必要であるか否かを判断する判断部と、
前記エンコード方式の制限が必要であると判断された場合、前記エンコード方式を制限するための内部コマンドをエンコーダに送信するコマンド送信部と、
を具備する端末。
【請求項５】
前記第１の網がパケット交換網であり、前記接続先網が回線交換網であり、
前記判断部は、前記検出されたコーデックがビット誤り耐性を有さないエンコード方式を用いるコーデックである場合に、前記エンコード方式の制限が必要であると判断する、
請求項４に記載の端末。
【請求項６】
前記エンコード方式の制限が必要であると判断された場合、前記接続先網にハンドオーバしたこと、又は、前記エンコード方式の制限が必要であることを通信相手端末に通知するためのシグナリングを生成する生成部と、
前記シグナリングを前記通信相手端末に送信する送信部と、を更に具備する、
請求項４に記載の端末。
【請求項７】
前記エンコード方式の制限が必要であると判断された場合、
前記端末が前記接続先網にハンドオーバしたこと、又は、前記エンコード方式の制限が必要であることを通知するためのシグナリングは、前記２つの端末のデータ経路上に存在する通信ノードで生成され、前記端末の通信相手端末に送信される、
請求項４に記載の端末。
【請求項８】
前記シグナリングを受け取った前記通信相手端末は、前記エンコード方式を制限するための内部コマンドを、前記通信相手端末内のエンコーダに送信する、
請求項６又は７に記載の端末。
【請求項９】
前記シグナリングは、ＲＴＰ（Real-time Transport Protocol）ペイロードヘッダに含まれる、
請求項６から８の何れかに記載の端末。
【請求項１０】
前記シグナリングは、ＲＴＣＰ（Real-time Transport Protocol Control 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）することを仮定する。【０００７】
図１の実線で示されたＰａｔｈ  Ａ、Ｐａｔｈ  Ｂ及びＰａｔｈ  Ｃは、通話データが通る経路を示す。また、図１の破線で示された２００、２０２、２０４及び２０６は、ＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。【０００８】
図２は、ＳＲＶＣＣハンドオーバ処理の動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ−ＵＴＲＡＮ）にそれぞれ接続されており、ＵＥ１００とＵＥ１０２との間の通話データはＰａｔｈ  Ａを通って送受信されている。ＵＥ１００がｅ−ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ−ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ１１０経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図１に示すシグナリング２００。図２に示すステップ（以下、「ＳＴ」という）２００）。ＳＴ２００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷ１１０との間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ−ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令（HO Command）が出される。【０００９】
ＳＴ２００の処理と同時に、ＭＳＣ／ＭＧＷ１１０は、ＣＳＣＦ／ＳＣＣ  ＡＳ経由でＵＥ１０２とシグナリングをやり取りする（図１に示すシグナリング２０２。図２に示すＳＴ２０２）。これにより、ＵＥ１０２の通話データの送受信先を、ＵＥ１００からＭＳＣ／ＭＧＷ１１０に切り替えるよう命令が出され、Ｐａｔｈ  Ｂが確立される。【００１０】
ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷ１１０とシグナリングをやり取りする（図１に示すシグナリング２０４。図２に示すＳＴ２０４）。これにより、Ｐａｔｈ  Ｃが確立される。【００１１】
Ｐａｔｈ  Ｃ確立後、ＭＳＣ／ＭＧＷ１１０は、ＭＭＥ経由でＰ−ＧＷ／Ｓ−ＧＷとシグナリングをやり取りする（図１に示すシグナリング２０６。図２に示すＳＴ２０６）。これにより、Ｐａｔｈ  Ａは削除される。【００１２】
以上、ＳＲＶＣＣハンドオーバの動作について説明した。【００１３】
また、ＳＲＶＣＣを改良し、データ経路切替にかかる時間を短縮する方式として、非特許文献２に記載の、ＡＴＣＦ（Access Transfer Control Function）エンハンスメントを用いたＳＲＶＣＣ方式（ｅＳＲＶＣＣ：enhanced-SRVCC）がある。このｅＳＲＶＣＣの動作の一例について、以下、図３及び図４を用いて説明する。【００１４】
図３は、ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワーク構成の一部を示す。図３に示す移動通信ネットワークは、図１と同様、ｅ−ＵＴＲＡＮ、ｅ−ｎｏｄｅＢ、ＰＳ網、ＣＳ網、ＣＳ網の基地局サブシステム、及びＩＭＳから構成される。ここでＩＭＳには、ＣＳＣＦ及びＳＣＣ  ＡＳの他、ＡＴＣＦ（Access Transfer Control Function）及びＡＴＧＷ（Access Transfer GateWay）が存在する。なお、図３及び図４では、ＡＴＣＦとＡＴＧＷとを一つのノード（ＡＴＣＦ／ＡＴＧＷ３２０）として表しているが、これらは別々のノードとして表してもよい。また、図３では、ＩＭＳの各ノードをまとめてＩＭＳノード３１０として表すこともある。【００１５】
図３において、ＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。つまり、ＵＥ１００とＵＥ１０２とでＶｏＬＴＥ通話が行われているとする。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。【００１６】
図３の実線で示されたＰａｔｈ  Ａ、Ｐａｔｈ  Ｂ、Ｐａｔｈ  Ｃ及びＰａｔｈ  Ｄは、通話データが通る経路を示す。また、図３の破線で示された３００、３０２、３０４及び３０６は、ｅＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。【００１７】
図４は、ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ−ＵＴＲＡＮ）にそれぞれ接続されている。ｅＳＲＶＣＣハンドオーバを実現するシステムでは、ＡＴＣＦ／ＡＴＧＷ３２０において、ＡＴＣＦはＩＭＳのシグナリング（ＩＭＳシグナリング）をアンカーし、ＡＴＧＷは通話データをアンカーする。つまり、ＵＥ１００とＵＥ１０２との間の通話開始時において、通話開始のＩＭＳシグナリングはＡＴＣＦで中継され、ＡＴＣＦがＡＴＧＷでの通話データのアンカーが必要と判断した場合、通話データのアンカーポイントとしてＡＴＧＷが割り当てられる。これにより、ＵＥ１００とＵＥ１０２との間の通話データは、Ｐａｔｈ  Ａ及びＰａｔｈ  Ｂを通って送受信される。【００１８】
ＵＥ１００がｅ−ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ−ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ１１０経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図３に示すシグナリング３００。図４に示すＳＴ３００）。ＳＴ３００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷ１１０との間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ−ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令（HO Command）が出される。【００１９】
ＳＴ３００の処理と同時に、ＭＳＣ／ＭＧＷ１１０は、ＡＴＣＦにシグナリングを送る。これによりＡＴＣＦからＡＴＧＷに経路切替の指示が出され、ＡＴＧＷの通話データ送受信先がＵＥ１００からＭＳＣ／ＭＧＷ１１０に切り替わる（図３に示すシグナリング３０２。図４に示すＳＴ３０２）。すなわち、Ｐａｔｈ  Ｃが確立される。また、ＡＴＧＷへの経路切替処理が完了すると、ＡＴＣＦは、ＳＣＣ−ＡＳに通知シグナリングを送信する（図３に示すシグナリング３０２。図４に示すＳＴ３０２）。【００２０】
ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷ１１０とシグナリングをやり取りする（図３に示すシグナリング３０４。図４に示すＳＴ３０４）。これにより、Ｐａｔｈ  Ｄが確立される。【００２１】
Ｐａｔｈ  Ｄ確立後、ＭＳＣ／ＭＧＷ１１０は、ＭＭＥ経由でＰ−ＧＷ／Ｓ−ＧＷとシグナリングをやり取りする（図３に示すシグナリング３０６。図４に示すＳＴ３０６）。これにより、Ｐａｔｈ  Ｂは削除される。【００２２】
以上、ｅＳＲＶＣＣハンドオーバの動作について説明した。【００２３】
次に３ＧＰＰの音声通話に使用される音声コーデックについて説明する。【００２４】
３ＧＰＰ標準規格のコーデックとして、非特許文献３に記載の狭帯域（ＮＢ：Narrowband）のマルチレート（Multi-Rate）コーデックであるＡＭＲ（Adaptive Multi-Rate）コーデック、及び、非特許文献４に記載の広帯域（ＷＢ：Wideband）のマルチレートコーデックであるＡＭＲ−ＷＢ（Adaptive Multi-Rate Wideband）コーデックがある。ＡＭＲコーデック及びＡＭＲ−ＷＢコーデックは、ＣＥＬＰ（Code-Exited Linear Predictive）方式を用いている。また、ＡＭＲコーデック及びＡＭＲ−ＷＢコーデックは、ＣＳ網などの伝送路で起こりうるビット誤りにも、ＰＳ網で起こりうるパケットロスにも耐性があるため、ＣＳ網でもＰＳ網でも利用が可能である。【００２５】
また、３ＧＰＰ標準規格の別のコーデックとして、非特許文献５に記載のＥＶＳ（Enhanced Voice Service）コーデックがある。ＥＶＳコーデックは、狭帯域、広帯域に加え、超広帯域（ＳＷＢ：Super Wideband）及びフル帯域（ＦＢ：Fullband）をサポートしたマルチレートコーデックであり、ビットレートも5.9kbpsから128kbpsまでをサポートしている。ＥＶＳコーデックでは、上述のＥＶＳオリジナルのコーデックモード（ＥＶＳプライマリモード）の他、ＡＭＲ−ＷＢ互換モード（ＥＶＳ ＡＭＲ−ＷＢ互換モード）もサポートしている。ＥＶＳコーデックのＥＶＳプライマリモードでは、ＰＳ網での利用のみを想定し、ビット誤りを想定していないため、ＣＥＬＰ方式に加え、符号化効率を優先した算術符号を用いた方式が一部に組み込まれた、ＭＤＣＴ（Modified Discrete Cosine Transform）方式が用いられている。ただし、ＥＶＳコーデックのＣＳ網でのサポートも２０１４年９月頃より議論されている（例えば、非特許文献６を参照）。【００２６】
なお、狭帯域（ＮＢ：Narrowband）コーデックとは、８ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。狭帯域コーデックでは、一般的に３００Ｈｚ〜３．４ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０〜４ｋＨｚの範囲内であればよい。【００２７】
また、広帯域（ＷＢ：Wideband）コーデックとは、１６ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。広帯域コーデックでは、一般的に５０Ｈｚ〜７ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０〜８ｋＨｚの範囲内であればよい。【００２８】
また、超広帯域（ＳＷＢ：Super Wideband）コーデックとは、３２ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。超広帯域コーデックでは、一般的に５０Ｈｚ〜１４ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０〜１６ｋＨｚの範囲内であればこれに限定されない。【００２９】
また、フル帯域（ＦＢ：Fullband）コーデックとは、４８ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。超広帯域コーデックでは、一般的に２０Ｈｚ〜２０ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０〜２４ｋＨｚの範囲内であればこれに限定されない。【００３０】
また、マルチレートコーデックとは、複数のビットレートをサポートするコーデックである。【００３１】
また、ここでは、「帯域（又は帯域幅）」とはコーデックの入出力となる信号の帯域のことを指す。【００３２】
また、コーデックモードとは、ビットレート又は帯域、ＥＶＳコーデックにおけるＥＶＳプライマリモードとＥＶＳ ＡＭＲ−ＷＢ互換モードなど、コーデックを構成する要素の部分集合（subset）を意味する。
【先行技術文献】
【特許文献】
【００３３】
【特許文献１】国際公開第２０１３／１５６０６３号
【非特許文献】
【００３４】
【非特許文献１】3GPP TS23.216 v12.2.0 “Single Radio Voice Call Continuity (SRVCC)”
【非特許文献２】3GPP TS23.237 v12.8.0 “IP Multimedia Subsystem (IMS) Service Continuity”
【非特許文献３】3GPP TS26.071 v12.0.0 “Mandatory speech CODEC speech processing functions; AMR speech Codec; General description”
【非特許文献４】3GPP TS26.171 v12.0.0 “Speech codec speech processing functions; Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; General description”
【非特許文献５】3GPP TS 26.441 v12.1.0 “Codec for Enhanced Voice Services (EVS); General overview”
【非特許文献６】SP-140485, 3GPP Work Item Description, “Support of EVS in 3G Circuit-Switched Networks”
【非特許文献７】3GPP TS26.201 v12.0.0 “Speech codec speech processing functions; Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; Frame structure”
【非特許文献８】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 TS26.445 v12.2.0 “Codec for Enhanced Voice Services (EVS); Detailed algorithmic description”
【非特許文献１０】3GPP TS26.114 v12.9.0 “IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction”
【非特許文献１１】3GPP TS26.103 v12.0.0 “Speech codec list for GSM and UMTS”
【発明の概要】
【００３５】
図１又は図３において、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバした際、ＵＥ１００が使用するコーデックはＣＳ網でサポートされているコーデックに再設定される。このときに再設定されるコーデックは、ＵＥ１００がＰＳ網で使用していたコーデックと異なること、又は、同一であってもＣＳ網でサポートされるモード（ビットレート又はオーディオ帯域など）がＰＳ網と異なることが考えられる。
【００３６】
しかしながら、ＵＥがＰＳ網からＣＳ網にハンドオーバした際に再設定されるコーデック又はコーデックモードがＰＳ網で使用していたコーデック又はコーデックモードと異なる場合の動作については未だ十分な検討がなされていない。
【００３７】
本開示の一態様は、通信中の端末の一方が使用していたコーデックが再設定される場合でも、通話品質の劣化を抑えて通信を継続することができる通信ノード、端末及び通信制御方法を提供する。
【００３８】
本開示の一態様に係る通信ノードは、第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末で使用されるコーデック及びコーデックモードを判断する通信ノードに関する。第１の網における通信で使用しているコーデック及びコーデックモードを示す情報と、一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、第２の網がサポートしているコーデック及びコーデックモードを示す情報と、の共通部分を２つの端末で使用されるコーデック及びコーデックモードに設定する判断部と、設定された２つの端末で使用されるコーデック及びコーデックモードへの変更を２つの端末へ要求するためのシグナリングを生成する生成部と、を具備する構成を採る。
【００３９】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【００４０】
本開示の一態様によれば、通信中の端末の一方が使用していたコーデックが再設定される場合でも、通話品質の劣化を抑えて通信を継続することができる。
【００４１】
本開示の一態様における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
【図面の簡単な説明】
【００４２】
【図１】３ＧＰＰの移動通信ネットワークの一部を示す構成図
【図２】ＳＲＶＣＣハンドオーバの動作を示すシーケンスチャート
【図３】ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワークの一部を示す構成図
【図４】ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャート
【図５】実施の形態１に係るＩＭＳノードの構成を示すブロック図
【図６】実施の形態１に係る動作の一例を示すシーケンスチャート
【図７】実施の形態１に係るＳＤＰオファー・アンサーの一例を示す図
【図８】実施の形態１に係るＭＳＣ／ＭＧＷ１１０におけるＵＥ１００がサポートするコーデックとＣＳ網がサポートするコーデック及びコーデックモードとの比較結果の一例を示す図
【図９】実施の形態１に係る判断部における判断の一例を示すフローチャート
【図１０】実施の形態２に係るＭＳＣ／ＭＧＷノードの構成を示すブロック図
【図１１】実施の形態２に係る動作の一例を示すシーケンスチャート
【図１２】実施の形態３に係る端末（ＵＥ）の構成を示すブロック図
【発明を実施するための形態】
【００４３】
［本開示の一態様に至った経緯］
図１又は図３において、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバした際、ＵＥ１００とＵＥ１０２との通話継続を可能にするためには、次の２つの方法が考えられる。１つ目の方法は、ＭＳＣ／ＭＧＷ１１０又はＡＴＣＦ／ＡＴＧＷにおいてトランスコーディングを行う方法である。２つ目の方法は、ＵＥ１０２で使用されるコーデックをＵＥ１００の変更後のコーデックと同じものに変更する方法である。
【００４４】
前者のトランスコーディングを行う方法では、トランスコーディングによる通話品質の劣化が生じてしまう。
【００４５】
一方、後者のコーデックを変更する方法では、トランスコーディングを行う方法のような通話品質の劣化は生じないものの、ＵＥ１０２のコーデックを変更するためのシグナリングに時間がかかり、通話が途切れる時間が長くなるので好ましくない。更に、ｅＳＲＶＣＣハンドオーバでは、ＵＥ１００のハンドオーバの際の経路切替のためのシグナリングがＡＴＣＦで終端するため、ＵＥ１０２のコーデックを変更するためのシグナリングを送ることすらできない。すなわち、ｅＳＲＶＣＣハンドオーバでは、既存のシグナリングを使ってＵＥ１０２のコーデックを変更することができない。
【００４６】
特許文献１には、ＳＲＶＣＣハンドオーバ又はｅＳＲＶＣＣのハンドオーバ過程において、ＭＧＷ／ＭＳＣがＭＭＥよりPS->CS reqメッセージ（図２又は図４を参照）を受け取った際、このメッセージの中に含まれる情報に基づいて、ＵＥがＣＳ網で使用するコーデックを予め決定する方法が開示されている。メッセージの中に含まれる情報とは、例えば、ハンドオーバするＵＥがサポートするコーデックを示す情報、及び、ＩＭＳ側（ＳＣＣ  ＡＳ又はＡＴＣＦ／ＡＴＧＷ）から受け取った、ＵＥがＰＳ網における通信で使用していたコーデックを示すである。
【００４７】
この方法を用いれば、ＭＧＷ／ＭＳＣは、ＵＥがＣＳ網で使用するコーデックを決定する前に、ＵＥがＰＳで使用していたコーデックを知ることができる。このため、ＰＳ網で使用されているコーデック及びコーデックモードがＣＳ網でもサポート可能な場合には、ＣＳ網においてコーデック及びコーデックモードをＰＳ網側と統一することができるので、この方法は有用である。
【００４８】
しかしながら、非特許文献１には、ＰＳ網で使用されているコーデック及びコーデックモードがＣＳ網でサポート可能ではない場合の解決方法に関しては何ら開示されていない。よって、ＰＳ網で使用されているコーデック及びコーデックモードがＣＳ網でサポート可能ではない場合には、ＣＳ網において、ＰＳ網でのセッション開始時に折衝したコーデック及びコーデックモードの品質が担保できないという課題が生じる。
【００４９】
また、第二の課題として、ＣＳ網でＥＶＳコーデックを利用した場合、エンコード方式によっては、伝送路で発生するビット誤りにより復号が正しく行われず、品質劣化が生じてしまう。
【００５０】
非特許文献７には、ＡＭＲ−ＷＢコーデックをＣＳ網にて用いる際、誤り耐性が無いビットに対してＣＲＣ（Cyclic Redundancy Check）を付加し、誤りを検出する方法が開示されている。また非特許文献８には、ＡＭＲコーデック又はＡＭＲ−ＷＢコーデックを用いた際にＣＳ網で誤りが生じた場合、この誤りを含むフレームをＰＳ網に送る際、Ｑビット又はＳＰＥＥＣＨ  ＬＯＳＴなどを用いて、当該フレームに誤りが生じていることをＰＳ網の端末に通知する方法が開示されている。
【００５１】
これらの方法を用いることにより、ＰＳ網の端末は誤りが生じたフレームを復号せずに破棄することが可能である。しかしながら、ＥＶＳコーデックの一部で使用されている、符号化効率を優先した算術符号を用いた方式の場合には、符号化されたビットの大半に誤り耐性が無いため、上述したＣＲＣを用いた方式の有効性は低くなる。
【００５２】
そこで、本開示の一態様では、ＰＳ網で使用されているコーデック及びコーデックモードがＣＳ網でサポート可能でない場合でも、ＣＳ網において、ＰＳ網でのセッション開始時に折衝されたコーデック／コーデックモードの品質（つまり、通話品質）を担保する。また、ビット誤り耐性を有さない方式（アルゴリズム）を用いるコーデック（a codec utilizing the algorithm which is not robust against bit errors）が、ビット誤りを生じる可能性のある網（例えば、ＣＳ網）で使用される場合においても、品質の劣化を抑えて通信を継続することができる。
【００５３】
以下、本開示の各実施の形態について、図面を参照して詳細に説明する。
【００５４】
（実施の形態１）
図５は、本実施の形態に係るＩＭＳノード３１０の構成を示すブロック図である。「ＩＭＳノード」とは、例えば、ＳＣＣ  ＡＳ又はＡＴＣＦ／ＡＴＧＷを指す。
【００５５】
ＩＭＳノード３１０は、受信部５００、送信部５０２、記憶部５０４、判断部５０６、ポリシ参照部５０８及びシグナリング生成部５１０を有して構成される。なお、ＩＭＳノード３１０は、図５に示す構成部の他に、ＩＭＳノードが標準で有する機能も具備する。
【００５６】
受信部５００は、シグナリングを受信する。受信部５００が受信するシグナリングには、例えば、ＰＳ網での通信開始時の呼制御（セッションセットアップ）におけるＳＤＰ（Session Description Protocol）オファー及びＳＤＰアンサー又はその一部を示す情報（すなわち、ＰＳ網における通信で端末が使用しているコーデック及びコーデックモードを示す情報）、ＣＳ網にハンドオーバする端末がサポートしているコーデック及びコーデックモードを示す情報、又は、ＣＳ網がサポートしているコーデック及びコーデックモードを示す情報等が挙げられる。
【００５７】
なお、受信部５００は、ＣＳ網にハンドオーバする端末がサポートしているコーデック及びコーデックモードを示す情報、及び、ＣＳ網がサポートしているコーデック及びコーデックモードを示す情報の代わりに、ＣＳ網にハンドオーバする端末がサポートしているコーデック及びコーデックモードを示す情報と、ＣＳ網がサポートしているコーデック及びコーデックモードを示す情報との間で合致するコーデック及びそのコーデックモードを示す情報（コーデック／コーデックモード情報）をＣＳ網（例えば、ＭＧＷ／ＭＳＣ１１０）から受信してもよい。
【００５８】
送信部５０２は、シグナリングを送信する。送信部５０２が送信するシグナリングには、例えば、コーデックモードの変更を要求するコーデックモード変更要求（モード変更リクエスト）が挙げられる。
【００５９】
記憶部５０４は、受信部５００から出力されるＳＤＰオファー及びＳＤＰアンサーの内容（つまり、ＰＳ網で使用しているコーデック／コーデックモードの情報）を記憶する。
【００６０】
判断部５０６は、ＳＲＶＣＣハンドオーバ又はｅＳＲＶＣＣハンドオーバが発生した場合に、ハンドオーバする端末（図１又は図３ではＵＥ１００）がＰＳ網における通信で使用しているコーデック及びコーデックモードと、当該端末がサポートしているコーデック及びコーデックモードと、ハンドオーバ先のＣＳ網がサポートしているコーデック及びコーデックモードとを比較する。そして、判断部５０６は、コーデック／コーデックモードの比較結果、及び、後述するポリシ参照部５０８で参照されたポリシに基づいて、コーデック及びコーデックモードの変更が必要か否かを判断する。
【００６１】
ポリシ参照部５０８は、サービスオペレータが有するポリシを参照する。
【００６２】
シグナリング生成部５１０は、判断部５０６においてコーデックモードの変更が必要と判断された場合、コーデックモード変更要求を含むシグナリングを生成する。シグナリング生成部５１０は、生成したシグナリングを送信部５０２に出力する。
【００６３】
図６は、本実施の形態に係る動作の一例を示すシーケンスチャートである。
【００６４】
図６では、ＵＥ１００は、最初ＰＳ網（ＬＴＥ網）に在圏しており、同じくＰＳ網（ＬＴＥ網）に在圏しているＵＥ１０２と、ＩＭＳノード３１０を介して、セッションセットアップを行い（例えば、非特許文献２を参照）、ＳＤＰオファー／ＳＤＰアンサーにより、音声通信で使用するコーデック及びコーデックモードを決定する（ＳＴ６０１）。
【００６５】
この際、ＩＭＳノード３１０（記憶部５０４）は、セッションセットアップにおいて端末間でやり取りされるＳＤＰオファー及びＳＤＰアンサーの情報又はその一部（例えば、ＳＤＰアンサーの内容のみ）を記憶する（ＳＴ６０２）。
【００６６】
図７は、セッションセットアップにおいて端末間でやり取りされるＳＤＰオファー及びＳＤＰアンサーの一例を示す。図７に示す例では、コーデック折衝において、ＳＤＰオファーを受け取ったＵＥは、ＥＶＳコーデックの超広帯域（ＳＷＢ）（bw=swb）であり、ビットレート9.6kbps〜24.4kbpsの範囲（br=9.6-24.4）を選択し、選択したコーデックモードをＳＤＰアンサーに記述している。ＩＭＳノード３１０の記憶部５０４は、少なくともこのＳＤＰアンサーの内容を記憶している。
【００６７】
ＵＥ１００は、ＵＥ１０２とＰＳ網（ＬＴＥ網）で音声通話を行っている際に（ＳＴ６０３）、ＰＳ網からＣＳ網へのＳＲＶＣＣハンドオーバ又はｅＳＲＶＣＣハンドオーバを行う。
【００６８】
具体的には、ＳＲＶＣＣハンドオーバ又はｅＳＲＶＣＣのハンドオーバ過程において、ＵＥ１００がｅ−ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ−ｎｏｄｅＢは、これを検知し、ＭＭＥに対してHO Requiredメッセージを送信し（ＳＴ６０４）、ＭＭＥは、ＭＳＣ／ＭＧＷ１１０に対してPS->CS reqメッセージを送信する（ＳＴ６０５）。なお、図６において、HO Requiredメッセージ及びPS->CS reqメッセージは、非特許文献１に記載の通りである。例えば、PS->CS reqメッセージには、ＵＥ１００がサポートしているコーデック（UE supported codec）を示すリスト（Supported Codec List）が含まれる。
【００６９】
ＭＧＷ／ＭＳＣ１１０は、PS->CS reqメッセージを受け取とると、PS->CS reqメッセージに含まれるＵＥ１００がサポートしているコーデックのリストと、自網（ＣＳ網）でサポートしているコーデック及びコーデックモードを照合（比較）する（ＳＴ６０６）。ＭＧＷ／ＭＳＣ１１０は、照合の結果、合致するコーデック及びそのコーデックモードを示すコーデック／コーデックモード情報をＩＭＳノード３１０に送信する（ＳＴ６０７）。なお、コーデック／コーデックモード情報の送信方法は、例えばＩＭＳでＳＤＰを使用して送信してもよく、別の方法でもよい。
【００７０】
図８は、ＭＳＣ／ＭＧＷ１１０における、ＵＥ１００がサポートするコーデックと、ＣＳ網がサポートするコーデック及びコーデックモードとの照合（比較）結果の一例を示す。すなわち、図８に示す情報は、ＣＳ網にハンドオーバするＵＥ１００がサポートしているコーデック及びコーデックモードを示す情報と、ＣＳ網がサポートしているコーデック及びコーデックモードを示す情報との間で合致するコーデック及びそのコーデックモードを示す情報である。
【００７１】
ＩＭＳノード３１０の判断部５０６は、ＭＧＷ／ＭＳＣ１１０から受け取ったコーデック／コーデックモード情報と、記憶部５０４に記憶されているＳＤＰオファー／ＳＤＰアンサーの内容（又はその一部）と、ポリシ参照部５０８が参照するサービスオペレータが有するポリシとに基づいて、ＣＳ網で使用するコーデック／コーデックモード（つまり、ＵＥ１００が使用するコーデック／コーデックモード）、及び、ＰＳ網で使用するコーデック／コーデックモード（つまり、ＵＥ１０２が使用するコーデック／コーデックモード）を判断する（ＳＴ６０８）。なお、判断部５０６における判断処理の詳細については後述する。
【００７２】
そして、ＩＭＳノード３１０は、判断したコーデック／コーデックモードをＭＳＣ／ＭＧＷ１１０に指示する（ＳＴ６０９）。また、ＭＳＣ／ＭＧＷ１１０は、ＣＳ網側（ＲＮＣ／ｎｏｄｅＢ）にHO Reqメッセージを送る際、ＩＭＳノード３１０から指示されたコーデック及びコーデックモードを選択することを通知する（ＳＴ６１０）。
【００７３】
ｎｏｄｅＢとＭＳＣ／ＭＧＷ１１０との間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ−ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令（HO Command）が出される（ＳＴ６１１）。
【００７４】
ＭＧＷ／ＭＳＣ１１０とＩＭＳノード３１０との間でＩＭＳのセッショントランスファー（initiation of session transfer）が行われる（ＳＴ６１２）。
【００７５】
ＵＥ１００は、ＵＴＲＡＮ（ＣＳ網）にハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷ１１０とシグナリングをやり取りする（ＳＴ６１３）。これにより、ＵＥ１００とＭＳＣ／ＭＧＷ１１０との間の通信経路が切り替えられる。
【００７６】
また、ＵＥ１０２の通話データの通信経路をＵＥ１００からＭＳＣ／ＭＧＷ１１０に切り替えるよう命令が出され、当該通信経路が切り替えられる（ＳＴ６１４）。
【００７７】
また、ＩＭＳノード３１０は、ＰＳ網のＵＥ１０２に、ＳＴ６０８で判断したコーデックモードへの変更を要求するモード変更リクエストを通知する（ＳＴ６１５）。
【００７８】
なお、ＰＳ網に対するモード変更リクエストの通知（ＳＴ６１５）は、図６に示すように、データの通信経路の変更（Speech Data path switched）が行われた直後に行われてもよく、データの通信経路の変更前に行われてもよい。
【００７９】
また、モード変更リクエストは、ＲＴＰ（Real-time Transport Protocol）ペイロードヘッダに含まれてもよく、ＲＴＣＰ（RTP Control Protocol）に含まれてもよい。例えば、モード変更リクエストは、非特許文献９に記載されたＲＴＰペイロードフォーマットヘッダのＣＭＲ（Codec Mode Request）バイトを用いて通知されてもよく、非特許文献１０に記載のＲＴＣＰ（RTP Control Protocol）−ＡＰＰのＣＭＲを用いて通知されてもよく、他の方法を用いて通知されてもよい。
【００８０】
また、図６において、モード変更リクエストは、データ経路上に存在するノードがＩＭＳノード３１０から指示を受けてＵＥ１０２に送信すればよい。例えば、このデータ経路上のノードは、ＡＴＧＷでもよく、ＭＧＷでもよい。例えば、ＡＴＧＷがＲＴＰペイロードフォーマットヘッダのＣＭＲバイトを用いてモード変更リクエストを通知する場合には、ＡＴＧＷは、ＭＧＷから送信されたデータに対して、モード変更リクエストを含んだＣＭＲバイトを追加する。
【００８１】
次に、ＩＭＳノード３１０の判断部５０６における判断について詳細に説明する。図９は、判断部５０６における判断の一例を示すフローチャートである。
【００８２】
判断部５０６は、まず、ポリシ参照部５０８により参照されたサービスオペレータのポリシ（ローカルポリシ）が存在するか否かを判断する（ＳＴ９００）。サービスオペレータのポリシが存在する場合（ＳＴ９００：ＹＥＳ）、判断部５０６は、このポリシに従ったコーデック及びコーデックモードを使用することを判断する（ＳＴ９０２）。ＩＭＳノード３１０は、必要に応じてＣＳ網側又はＰＳ網側、又はその両方にコーデック／コーデックモードを示すシグナリングメッセージを送信する。
【００８３】
例えば、サービスオペレータのポリシの一例として、「ＰＳ網で使用されていたコーデックがＣＳ網でもサポートされているのであれば、ＰＳ網でのセッションセットアップ時に折衝されたコーデックモードはＣＳ網側のコーデックモードで上書きされてもよい」という内容が挙げられる。例えば、図７に示すＳＤＰアンサーと図８に示す照合結果とを比較した場合、図７に示すＳＤＰアンサーに記述された、セッションセットアップ時に折衝されたＥＶＳのビットレートは9.8kbpsから24.4kbpsであるのに対して、図８に示すＣＳ網でサポートされているＥＶＳのビットレートは5.9kbpsから13.2kbpsである。この場合、上記ポリシに従う場合には、ＩＭＳノード３１０は、ＭＳＣ／ＭＧＷ１１０に対してＥＶＳのビットレートとして5.9kbpsから13.2kbpsを選択することを指示し、ＭＳＣ／ＭＧＷ１１０は、ＣＳ網側にHO Reqを送信する際、ＥＶＳのビットレートとして5.9kbpsから13.2kbpsを選択することを通知する（ＳＴ６１０）。また、ＩＭＳノード３１０は、ＰＳ網側には、ビットレートの上限を13.2kbpsに設定することを通知する（ＳＴ６１５）。
【００８４】
一方、サービスオペレータのポリシが存在しない場合（ＳＴ９００：ＮＯ）、判断部５０６は、ＭＳＣ／ＭＧＷ１１０から通知されたコーデック／コーデックモード情報（ＳＴ６０７）に示されるコーデック及びコーデックモードと、ＰＳ網で使用されているコーデック及びコーデックモードとに共通部分があるか否かを判断する（ＳＴ９０４）。
【００８５】
共通部分がある場合（ＳＴ９０４：ＹＥＳ）、判断部５０６は、共通部分であるコーデック及びコーデックモードを使用することを判断する（ＳＴ９０６）。ＩＭＳノード３１０は、ＣＳ網側又はＰＳ網側、又はその両方に共通部分のコーデック／コーデックモードの使用を促すシグナリングメッセージを送信する。
【００８６】
例えば、例えば図７に示すＳＤＰアンサーと図８に示す照合結果とを比較した場合、ＥＶＳのビットレートの共通部分は9.8kbps及び13.2kbpsである。そこで、ＩＭＳノード３１０は、ＭＳＣ／ＭＧＷ１１０に対してＥＶＳのビットレートとして9.8kbps及び13.2kbpsのみを使用することを指示し、ＭＳＣ／ＭＧＷ１１０は、ＣＳ網側にHO Reqを送信する際、ＥＶＳのビットレートとして9.8kbps及び13.2kbpsのみを選択することを通知する（ＳＴ６１０）。また、ＩＭＳノード３１０は、ＰＳ網側には、ビットレートを9.8kbps及び13.2kbpsに設定することを通知する（ＳＴ６１５）。
【００８７】
なお、図９に示すＳＴ９０６の処理は、ＳＴ９００の判断において存在が確認されたポリシが「ＰＳ網側で使用されていたコーデックがＣＳ網側でもサポートされているなら、コーデックモードとして共通部分を使用する」という内容である場合にＳＴ９０２で行われる処理と等価である。
【００８８】
また、共通部分とは、完全に一致する部分ではなく、共通の上限値であってもよい。例えば、図７に示すＳＤＰアンサーと図８に示す照合結果とを比較した場合、ＥＶＳのビットレートの上限は13.2kbpsであるので、ＰＳ網側にはビットレートの上限を13.2kbpsにする通知が送られる。また、ＣＳ網側で使われるビットレートの組み合わせは、非特許文献１１に記載の通り、予め数通り決められている場合がある。例えば、ＥＶＳの場合であっても、図８に示される組み合わせ、すなわち{5.9kbps，7.2kbps，8.0kbps，9.6kbps，13.2kbps}の他に、例えば{8.0kbps，9.6kbps，13.2kbps}の組み合わせがサポートされているとする。この場合、ビットレートの下限値として、ＰＳ網で折衝されたビットレートの下限値に近い後者の組み合わせ、すなわち{8.0kbps，9.6kbps，13.2kbps}が選択されてもよい。
【００８９】
一方、ＰＳ網及びＣＳ網で使用される同一コーデックのコーデックモードに共通部分が無い場合（ＳＴ９０４：ＮＯ）、判断部５０６は、ＰＳ網で使用されていたコーデックに別のコーデックとの互換モードが存在する場合、コーデック／コーデックモード情報に示されるコーデック／コーデックモードの中に、互換性のあるコーデックが存在するか否かを判断する（ＳＴ９０８）。つまり、判断部５０６は、ＰＳ網で使用されたコーデックに互換モードが存在する場合に、ＣＳ網において当該互換モードに変更可能であるか否かを判断する。
【００９０】
ＣＳ網において当該互換モードに変更可能である場合（ＳＴ９０８：ＹＥＳ）、判断部５０６は、互換モードのコーデックを使用することを判断する（ＳＴ９１０）。ＩＭＳノード３１０は、ＣＳ網側又はＰＳ網側、又はその両方に、互換モードのコーデックの使用を促すシグナリングメッセージを送信する（ＳＴ６１０，ＳＴ６１５）。
【００９１】
上述したように、ＥＶＳコーデックは、ＡＭＲ−ＷＢ互換モードもサポートしている。そこで、ＩＭＳノード３１０は、ＳＴ９１０では、ＭＳＣ／ＭＧＷ１１０に対してＥＶＳのＡＭＲ−ＷＢ互換モードを使用することを指示し、ＭＳＣ／ＭＧＷ１１０は、ＣＳ網側にHO Reqを送信する際、ＥＶＳのＡＭＲ−ＷＢ互換モードに変更することを通知する（ＳＴ６１０）。また、ＩＭＳノード３１０は、ＰＳ網側には、ＥＶＳのＡＭＲ−ＷＢ互換モード、かつ、ビットレートの上限を12.65kbps（図８を参照）に設定することを通知する（ＳＴ６１５）。
【００９２】
なお、図９に示すＳＴ９１０の処理は、ＳＴ９００の判断において存在が確認されたポリシが「ＰＳ網側で使用されているコーデックに別のコーデックとの互換モードが存在する場合に、ＣＳ網において当該互換モードに変更する」という内容である場合にＳＴ９０２で行われる処理と等価である。
【００９３】
一方、ＰＳ網で使用されていたコーデックに別のコーデックとの互換モードが存在しない場合、又は、ＣＳ網において互換モードに変更可能ではない場合（ＳＴ９０８：ＮＯ）、判断部５０６は、ＣＳ網でサポートしているコーデックをＣＳ網で使用し、ＰＳ網とＣＳ網との間でトランスコーディングを行うと判断する（ＳＴ９１２）。
【００９４】
なお、図９に示すＳＴ９１２の処理は、ＳＴ９００の判断において存在が確認されたポリシが「トランスコーディングを行う」という内容である場合にＳＴ９０２で行われる処理と等価である。
【００９５】
また、ＳＴ９１２において、トランスコーディングの代わりに、セッションの再折衝を行い、再折衝の結果に従ってＵＥ１０２のコーデックをＣＳ網でサポート可能なコーデックに変更してもよい。
【００９６】
また、トランスコーディングは、データ経路上に存在するノードがＩＭＳノードからトランスコーディングをするよう指示を受けて行われればよい。例えば、トランスコーディングを行うノードは、ＡＴＧＷでもよく、ＭＧＷでもよい。
【００９７】
以上、ＩＭＳノード３１０の判断部５０６における判断について説明した。
【００９８】
このようにして、ＩＭＳノード３１０の判断部５０６は、ＰＳ網において通信を行う２つの端末のうち一方の端末がＣＳ網にハンドオーバした際、ＰＳ網における通信で使用しているコーデック及びコーデックモードを示す情報と、ハンドオーバした一方の端末（ＵＥ１００）がサポートしているコーデック及びコーデックモードを示す情報と、ＣＳ網がサポートしているコーデック及びコーデックモードを示す情報と、の共通部分を上記２つの端末で使用されるコーデック及びコーデックモードに設定する。そして、ＩＭＳノード３１０のシグナリング生成部５１０は、設定された上記２つの端末で使用されるコーデック及びコーデックモードへの変更を当該２つの端末へ要求するためのシグナリングを生成する。
【００９９】
このように、本実施の形態では、上記共通部分であるコーデック／コーデックモードを用いることにより、ＰＳ網で使用されているコーデック及びコーデックモードがＣＳ網でサポート可能でない場合でも、ＣＳ網において、ＰＳ網でのセッション開始時に折衝したコーデック及びコーデックモードの品質を担保することができる。
【０１００】
また、上記共通部分が存在しない場合、ＩＭＳノード３１０の判断部５０６は、ＰＳ網における通信で使用しているコーデックに、別のコーデックとの互換モードが存在し、かつ、ハンドオーバした一方の端末がサポートしているコーデック及びＣＳ網がサポートしているコーデックに、当該別のコーデックが含まれる場合、その別のコーデック又は別のコーデックとの互換モードを、上記２つの端末で使用されるコーデック及びコーデックモードに設定する。
【０１０１】
更に、本実施の形態では、サービスオペレータのポリシが存在する場合には、当該ポリシに従ってコーデック／コーデックモードが設定される。
【０１０２】
これにより、本実施の形態によれば、ＵＥのハンドオーバ先のＣＳ網でサポートしている、コーデック及びコーデックモードが、ＰＳ網での通信開始時のセッションセットアップ時に折衝されたコーデック及びコーデックモードと異なる場合でも、サービスオペレータのポリシ及びセッションセットアップ時に折衝された内容から外れる事なく、通信を継続することができる。
【０１０３】
よって、本実施の形態によれば、通信中の端末の一方が使用していたコーデックが再設定される場合でも、通話品質の劣化を抑えて通信を継続することができる。
【０１０４】
（実施の形態２）
実施の形態１ではＩＭＳノード３１０がＣＳ網への端末のハンドオーバ時に使用するコーデックの判断を行う場合について説明したのに対して、本実施の形態では、ＭＳＣ／ＭＧＷ１１０がＣＳ網への端末のハンドオーバ時に使用するコーデックの判断を行う場合について説明する。
【０１０５】
図１０は、本実施の形態に係るＭＳＣ／ＭＧＷ１１０の構成を示すブロック図である。
【０１０６】
ＭＳＣ／ＭＧＷ１１０は、受信部１０００、送信部１００２、記憶部１００４、判断部１００６、ポリシ参照部１００８及びシグナリング生成部１０１０を有して構成される。なお、ＭＳＣ／ＭＧＷ１１０は、図１０に示す構成部の他に、ＭＳＣ／ＭＧＷが標準で有する機能も具備する。
【０１０７】
受信部１０００は、シグナリングを受信する。受信部１０００が受信するシグナリングには、例えば、ＩＭＳノード３１０から受け取る、ＰＳ網での通信開始時の呼制御（セッションセットアップ）におけるＳＤＰオファー及びＳＤＰアンサーの内容又はその一部を示す情報（すなわち、ＰＳ網における通信で端末が使用しているコーデック及びコーデックモードを示す情報。本実施の形態ではコーデック／コーデックモード情報と呼ぶ）、ＭＭＥから受け取る、ＵＥ１００がサポートしているコーデックを示すリストを含むPS->CS reqメッセージ等が挙げられる。
【０１０８】
送信部１００２は、シグナリングを送信する。送信部１００２が送信するシグナリングには、例えば、コーデックモードの変更を要求するコーデックモード変更要求（モード変更リクエスト）、及び、ＩＭＳノード３１０に対してコーデック／コーデックモード情報を要求するクエリが挙げられる。
【０１０９】
記憶部１００４は、受信部１０００から出力される、ＳＤＰオファー及びＳＤＰアンサーの内容又はその一部、及び、ＣＳ網から送信されるＵＥ１００がサポートしているコーデック情報を記憶する。また、記憶部１００４は、ＣＳ網がサポートしているコーデック及びコーデックモードを示す情報を記憶してもよい。
【０１１０】
判断部１００６は、ＳＲＶＣＣハンドオーバ又はｅＳＲＶＣＣハンドオーバが発生した場合に、ハンドオーバする端末（図１又は図３ではＵＥ１００）がＰＳ網における通信で使用しているコーデック及びコーデックモードと、当該端末がサポートしているコーデック及びコーデックモードと、ＣＳ網がサポートしているコーデック及びコーデックモードとを比較する。そして、判断部１００６は、コーデック／コーデックモードの比較結果、及び、後述するポリシ参照部１００８で参照されたポリシに基づいて、コーデック及びコーデックモードの変更が必要か否かを判断する。
【０１１１】
ポリシ参照部１００８は、サービスオペレータが有するポリシを参照する。
【０１１２】
シグナリング生成部１０１０は、判断部１００６においてコーデックモードの変更が必要と判断された場合、コーデックモード変更要求を含むシグナリングを生成する。また、シグナリング生成部１０１０は、ＩＭＳノード３１０に対して、ＳＤＰオファー／ＳＤＰアンサーの内容又はその一部を受け取るためのシグナリング（クエリ）を生成する。シグナリング生成部１０１０は、生成したシグナリングを送信部５０２に出力する。
【０１１３】
図１１は、本実施の形態に係る動作の一例を示すシーケンスチャートである。なお、図１１において、実施の形態１（図６）と同様の処理については同一符号を付し、その説明を省略する。
【０１１４】
図１１では、実施の形態１と同様、ＵＥ１００は、最初ＰＳ網（ＬＴＥ網）に在圏しており、同じくＰＳ網（ＬＴＥ網）に在圏しているＵＥ１０２と、音声通話を行っている。
【０１１５】
ＭＳＣ／ＭＧＷ１１０の記憶部１００４は、ＳＴ６０５においてＭＭＥから受け取ったPS->CS reqメッセージに含まれる、ＵＥ１００がサポートしているコーデックを示す情報（Supported Codec List）を記憶する。
【０１１６】
ＭＧＷ／ＭＳＣ１１０のシグナリング生成部１０１０は、ＳＴ６０１においてＵＥ１００とＵＥ１０２との間でやり取りされたＳＤＰオファー／ＳＤＰアンサーの内容又はその一部を要求する、ＩＭＳノード３１０に対するクリエメッセージを生成する。生成されたクリエメッセージは、ＭＧＷ／ＭＳＣ１１０からＩＭＳノード３１０へ送信される（ＳＴ１１０１）。なお、このクリエメッセージは、ＩＭＳシグナリングでもよく、別の方法でもよい。
【０１１７】
ＩＭＳノード３１０は、ＳＴ１１０１においてクリエメッセージを受け取ると、保持しているＳＤＰオファー／ＳＤＰアンサーの内容又はその一部を含むコーデック／コーデックモード情報をＭＧＷ／ＭＳＣ１１０へ送信する（ＳＴ１１０２）。ＭＧＷ／ＭＳＣ１１０の記憶部１００４は、受け取ったコーデック／コーデックモード情報を記憶する。
【０１１８】
ＭＧＷ／ＭＳＣ１１０の判断部１００６は、ＩＭＳノード３１０から受け取ったコーデック／コーデックモード情報（ＰＳ網における通信で使用しているコーデック／コーデックモード）と、ＵＥ１００がサポートしているコーデックのリストと、自網（ＣＳ網）でサポートしているコーデック／コーデックモードと、ポリシ参照部５０８が参照するサービスオペレータが有するポリシと、に基づいて、ＣＳ網で使用するコーデック／コーデックモード（つまり、ＵＥ１００が使用するコーデック／コーデックモード）、及び、ＰＳ網で使用するコーデック／コーデックモード（つまり、ＵＥ１０２が使用するコーデック／コーデックモード）を判断する（ＳＴ１１０３）。
【０１１９】
なお、判断部１００６における判断処理は、実施の形態１（例えば、図９を参照）と同様であるのでここではその説明を省略する。
【０１２０】
そして、ＭＧＷ／ＭＳＣ１１０は、ＣＳ網側（ＲＮＣ／ｎｏｄｅＢ）にHO Reqメッセージを送る際、判断したコーデック／コーデックモードを含めて通知する（ＳＴ６１０）。また、ＭＧＷ／ＭＳＣ１１０は、判断したコーデック／コーデックモードのうち、ＰＳ網で使用するコーデック／コーデックモードを、ＩＭＳノード３１０に通知する（ＳＴ１１０４）。ＩＭＳノード３１０へのコーデック／コーデックモードの通知には、ＩＭＳシグナリングを用いてもよく、別の方法でもよい。
【０１２１】
また、ＭＧＷ／ＭＳＣ１１０は、ＰＳ網のＵＥ１０２に、ＳＴ１１０３で判断したコーデックモードへの変更を要求するモード変更リクエストを通知する（ＳＴ１１０５）。
【０１２２】
なお、ＰＳ網に対するモード変更リクエストの通知（ＳＴ１１０５）は、図１１に示すように、データの通信経路の変更（Speech Data path switched）が行われた直後に行われてもよく、データの通信経路の変更前に行われてもよい。
【０１２３】
また、モード変更リクエストは、ＲＴＰペイロードヘッダに含まれてもよく、ＲＴＣＰに含まれてもよい。例えば、モード変更リクエストは、非特許文献９に記載されたＲＴＰペイロードフォーマットヘッダのＣＭＲ（Codec Mode Request）バイトを用いて通知されてもよく、非特許文献１０に記載のＲＴＣＰ−ＡＰＰのＣＭＲを用いて通知されてもよく、他の方法を用いて通知されてもよい。
【０１２４】
また、図１１において、モード変更リクエストは、ＭＧＷ／ＭＳＣ１１０から送信されてもよく、ＡＴＧＷから送信されてもよい。例えば、ＡＴＧＷがＲＴＰペイロードフォーマットヘッダのＣＭＲバイトを用いてモード変更リクエストを通知する場合には、ＡＴＧＷは、ＭＧＷから送信されたデータに対して、モード変更リクエストを含んだＣＭＲバイトを追加する。
【０１２５】
また、例えば、サービスオペレータのポリシが「セッションの再折衝を行い、ＰＳ網側のコーデックを変更する」という内容の場合には、ＭＧＷ／ＭＳＣ１１０は、ＰＳ網で使用するコーデックを決定する前にＩＭＳノード３１０を通じてＵＥ１０２にＳＤＰオファーを送信し、ＵＥ１０２からＩＭＳノード３１０経由でＳＤＰアンサーを受け取った後に、ＣＳ側で使用するコーデック及びコーデックモードを含む、HO reqメッセージを送信してもよい。
【０１２６】
このようにして、ＭＧＷ／ＭＳＣ１１０の判断部１００６は、ＰＳ網において通信を行う２つの端末のうち一方の端末がＣＳ網にハンドオーバした際、ＰＳ網における通信で使用しているコーデック及びコーデックモードを示す情報と、ハンドオーバした一方の端末（ＵＥ１００）がサポートしているコーデック及びコーデックモードを示す情報と、ＣＳ網がサポートしているコーデック及びコーデックモードを示す情報と、の共通部分を上記２つの端末で使用されるコーデック及びコーデックモードに設定する。そして、ＭＧＷ／ＭＳＣ１１０のシグナリング生成部１０１０は、設定された上記２つの端末で使用されるコーデック及びコーデックモードへの変更を当該２つの端末へ要求するためのシグナリングを生成する。
【０１２７】
このように、本実施の形態では、実施の形態１と同様、上記共通部分であるコーデック／コーデックモードを用いることにより、ＰＳ網で使用されているコーデック及びコーデックモードがＣＳ網でサポート可能でない場合でも、ＣＳ網において、ＰＳ網でのセッション開始時に折衝したコーデック及びコーデックモードの品質を担保することができる。
【０１２８】
また、本実施の形態によれば、実施の形態１と同様、ＵＥのハンドオーバ先のＣＳ網でサポートしている、コーデック及びコーデックモードが、ＰＳ網での通信開始時のセッションセットアップ時に折衝されたコーデック及びコーデックモードと異なる場合でも、サービスオペレータのポリシ及びセッションセットアップ時に折衝された内容から外れる事なく、通信を継続することができる。
【０１２９】
よって、本実施の形態によれば、通信中の端末の一方が使用していたコーデックが再設定される場合でも、通話品質の劣化を抑えて通信を継続することができる。
【０１３０】
（実施の形態３）
本実施の形態では、ＵＥ１００に対するＳＲＶＣＣハンドオーバ又はｅＳＲＶＣＣハンドオーバが起きた際、ＵＥ１００がＣＳ網で使用するコーデックとして、ＥＶＳプライマリモードのように、ビット誤り耐性を有さない方式（アルゴリズム）を用いるコーデックが選択された場合に、ＣＳ網におけるビット誤りによる影響を抑える方法について説明する。
【０１３１】
図１２は、本実施の形態に係るＵＥ１００，１０２（端末）の構成を示すブロック図である。ＵＥ１００，１０２は、受信部１２００、送信部１２０２、接続先検出部１２０４、コーデック検出部１２０６、判断部１２０８、コマンド送信部１２１０、及び通知送受信部１２１２を有して構成される。なお、ＵＥ１００，１０２は、図１２に示す構成部の他に、端末が標準で有する機能も具備する。
【０１３２】
受信部１２００は、通信データ及びシグナリング等を受信する。受信部１２００が受信するシグナリングには、例えば、ＣＳ網にハンドオーバした通信相手端末（又は、データ経路上の通信ノード）から、通信相手端末がＣＳ網にハンドオーバしたこと、又は、コーデックのエンコード方式の制限が必要であることを通知するためのシグナリングが挙げられる。
【０１３３】
送信部１２０２は、通信データ及びシグナリング等を送信する。送信部１２０２が送信するシグナリングには、例えば、ＰＳ網に在圏の通信相手端末に対して、自機がＣＳ網にハンドオーバしたこと、又は、コーデックのエンコード方式の制限が必要であることを通知するためのシグナリングが挙げられる。
【０１３４】
接続先検出部１２０４は、ハンドオーバなどによる自機の接続先網（ＰＳ網又はＣＳ網）を検出する。
【０１３５】
コーデック検出部１２０６は、接続先検出部１２０４で検出された接続先網で使用されるコーデックを検出する。
【０１３６】
判断部１２０８は、接続先検出部１２０４で検出された接続先網及びコーデック検出部１２０６で検出されたコーデックに基づいて、自機及び通信相手端末で使用されるコーデックで用いるエンコード方式の制限が必要であるか否かを判断する。例えば、判断部１２０８は、自機がＰＳ網からＣＳ網へハンドオーバした際に、コーデック検出部１２０６で検出されたＣＳ網で使用されるコーデックがビット誤り耐性を有さないエンコード方式を用いるコーデックである場合に、エンコード方式の制限が必要であると判断する。
【０１３７】
コマンド送信部１２１０は、例えば、自機がＣＳ網にハンドオーバし、判断部１２０８においてエンコード方式の制限が必要であると判断された場合、又は、自機がＰＳ網に在圏し、後述する通知送受信部１２１２において通信相手端末（ＣＳ網に在圏）から接続先網の通知（又はエンコード方式の制限を通知するためのシグナリング）を受信した場合、接続先網で使用されるエンコード方式を制限するための内部コマンドを、エンコーダ（図示せず）に送信する。
【０１３８】
通知送受信部１２１２は、受信部１２００を介して通信相手端末から接続先網の通知（エンコード方式を制限するためのシグナリング）を受信する。また、通知送受信部１２１２は、例えば、自機がＣＳ網にハンドオーバし、判断部１２０８においてエンコード方式の制限が必要であると判断された場合、ＰＳ網に在圏の通信相手端末に対して、自機がＣＳ網にハンドオーバしたこと、又は、コーデックのエンコード方式の制限が必要であることを通知するためのシグナリングを生成する。このシグナリングは、送信部１２０２を介して通信相手端末に通知される。
【０１３９】
次に、本実施の形態に係るＵＥ１００の動作について説明する。
【０１４０】
例えば、図６及び図１１において、ＵＥ１００がｅＮＢからＣＳ網へのハンドオーバの命令（HO Command）を受け取り（ＳＴ６１１）、接続先をＲＮＣ／ｎｏｄｅＢに変更した場合（ＳＴ６１３）、ＵＥ１００の接続先検出部１２０４は、基地局情報などを用いて、接続先網がＣＳ網に変更されたことを検出する。
【０１４１】
また、図６及び図１１において、ＵＥ１００がＲＮＣ／ｎｏｄｅＢに接続する過程において（例えば、ＳＴ６１３）、ＵＥ１００のコーデック検出部１２０６は、ＣＳ網で使用するコーデックを検出する。ＵＥ１００がＣＳ網で使用するコーデックは、例えば、ＭＧＷ／ＭＳＣ１１０によってＲＮＣ／ｎｏｄｅＢに通知されている（例えば、ＳＴ６１０）。なお、ＵＥ１００がＣＳ網で使用するコーデックの設定方法は、実施の形態１、２で説明した方法でもよく、他の方法でもよい。
【０１４２】
例えば、ＵＥ１００に対してＣＳ網で使用されるコーデック及びコーデックモードが、ＥＶＳプライマリモードの9.6kbps及び13.2kbpsであるとする。上述したように、ＣＳ網は、伝送路でビット誤りが起こりうる網であり、ＥＶＳプライマリモードは、ビット誤りを想定していないコーデックモードである。よって、この場合、ＵＥ１００の判断部１２０８は、接続先検出部１２０４で検出されたＣＳ網の情報、及び、コーデック検出部１２０６で検出されたコーデックの情報に基づいて、ビット誤り耐性を有さない方式を用いるＥＶＳプライマリモードの9.6kbps及び13.2kbpsが、ビット誤りが起こりうるＣＳ網で使用されることを検出する。つまり、判断部１２０８は、ＣＳ網で使用するコーデックのエンコード方式の制限が必要であると判断する。
【０１４３】
そして、ＵＥ１００のコマンド送信部１２１０は、ＵＥ１００のエンコーダに対して、ビット誤り耐性を有する方式のみを用いてエンコードするように、エンコード方式を制限する内部コマンドを送信する。
【０１４４】
また、図６及び図１１において、ＭＧＷ／ＭＳＣ１１０とＩＭＳノード３１０との間でＩＭＳのセッショントランスファー（initiation of session transfer）が行われる（ＳＴ６１２）。ＭＧＷ／ＭＳＣ１１０又はＡＴＧＷ（ＩＭＳノード３１０）のシグナリング生成部５１０，１０１０（図５及び図１０を参照）は、ＵＥ１０２に対して、ＵＥ１００がＣＳ網に接続したことを通知するシグナリング、又は、使用しているコーデックのエンコード方式を制限すること（ビット誤り耐性を有する方式を用いてエンコードすること）を通知するシグナリングを生成し、送信する。
【０１４５】
つまり、ＵＥ１００においてエンコード方式の制限が必要であると判断された場合、ＵＥ１００がＣＳ網に接続したことを通知するシグナリング、又は、使用しているコーデックのエンコード方式を制限することを通知するためのシグナリングは、ＵＥ１００及びＵＥ１０２のデータ経路上に存在する通信ノードで生成され、ＵＥ１０２に送信される。
【０１４６】
このシグナリングは、ＲＴＰペイロードヘッダに含まれてもよく、ＲＴＣＰに含まれてもよい。例えば、シグナリングは、非特許文献９に記載されたＲＴＰペイロードフォーマットヘッダのＣＭＲ（Codec Mode Request）バイトのフィールド又はビットに、通信相手（図６及び図１１ではＵＥ１００）がＣＳ網に接続したこと、又は、エンコード方式を制限することを通知するための機能を追加して用いてもよい。又は、このシグナリングの通知には、非特許文献１０に記載のＲＴＣＰ−ＡＰＰのＣＭＲに、通信相手がＣＳ網に接続したこと、又は、エンコード方式を制限することを通知するための新たなフィールドを追加して用いてもよい。または、このシグナリングは、ＩＭＳシグナルリングなどの別の方法を用いて通知されてもよい。
【０１４７】
また、ＵＥ１００がＣＳ網に接続したこと、又は、エンコード方式を制限することを通知するシグナリングが送信されるタイミングは、図６及び図１１に示すモード変更リクエストの送信タイミングと同時でもよく、異なるタイミングでもよい。
【０１４８】
また、このシグナリングには、ＣＳ網でＥＶＳプライマリモードが使われていることが暗黙的又は明示的に含まれていてもよい。また、ＵＥ１００がＣＳ網に接続したこと、又は、エンコード方式を制限することを通知するシグナリングは、ＵＥ１００からＵＥ１０２に対して送信されてもよい。
【０１４９】
一方で、ＣＳ網にハンドオーバしたＵＥ１００の通信相手端末であるＵＥ１０２の通知送受信部１２１２は、ＵＥ１００がＣＳ網に接続したこと、又は、エンコード方式を制限することを通知するシグナリングを受け取ると、ＣＳ網に移動したＵＥ１００がＥＶＳプライマリモードを使用して通信することを検出する。そして、ＵＥ１０２の判断部１２０８は、エンコード方式の制限が必要であると判断し、コマンド送信部１２１０は、ＵＥ１０２のエンコーダ（図示せず）に対して、ビット誤り耐性を有する方式のみを用いてエンコードするように、エンコード方式を制限する内部コマンドを送信する。
【０１５０】
なお、上述したようにＣＳ網でＥＶＳプライマリモードを使用する際にビット誤り耐性を有する方式のみを用いてエンコードするように内部コマンドを送信する方式は、ＳＲＶＣＣハンドオーバ又はｅＳＲＶＣＣハンドオーバの時のみでなく、例えば、ＵＥ１００が最初からＣＳ網に接続している時に用いられていてもよい。また、ＵＥ１００がＣＳ網に接続していることをＰＳ網に接続している通信相手（例えばＵＥ１０２）に通知する方法は、ＳＲＶＣＣハンドオーバ又はｅＳＲＶＣＣハンドオーバの時のみでなく、例えば、ＵＥ１００がＣＳ網に接続し、ＵＥ１０２がＰＳ網に接続している際の通信の開始時から用いられてもよい。
【０１５１】
また、「ビット誤り耐性を有する方式」とは、ＥＶＳ  ＡＭＲ−ＷＢ互換モードであってもよい。この場合、ＵＥ１００において、接続先検出部１２０４がＵＥ１００のＣＳ網への接続を検出し、コーデック検出部１２０６がＣＳ網で使用するコーデックとしてＥＶＳを検出した場合、コマンド送信部１２１０は、エンコーダに対して、エンコード方式をＡＭＲ−ＷＢ互換モードに変更するように内部コマンドを送信する。また、この場合のＵＥ１０２への通知のためのシグナリングは、ＵＥ１００がＣＳ網にハンドオーバを行ったことを通知するものではなく、ＥＶＳプライマリモードをＡＭＲ−ＷＢ互換モードに切り替えるという切替要求でもよい。
【０１５２】
この切替要求の通知には、非特許文献９に記載のＲＴＰペイロードフォーマットヘッダのＣＭＲバイトを用いてもよく、非特許文献１０に記載のＲＴＣＰ−ＡＰＰのＣＭＲを用いてもよい。または、この切替要求は、ＩＭＳシグナリングなどの別の方法を用いて通知されてもよい。また、切替要求が送信されるタイミングは、図６及び図１１に示すモード変更リクエストの送信タイミングと同時でもよく、異なるタイミングでもよい。また、切替要求は、ＵＥ１００からＵＥ１０２に対して送信されてもよい。
【０１５３】
以上のように、本実施の形態では、ＵＥ１００，１０２は、ＣＳ網に接続されたＵＥがＣＳ網で使用するコーデックとして、ＥＶＳプライマリモードのように、ビット誤り耐性を有さない方式（アルゴリズム）を用いるコーデックが設定された場合に、ビット誤り耐性を有さない方式（アルゴリズム）を用いるようにエンコーダに指示する。
【０１５４】
このように、ＣＳ網で使用するコーデックで用いるエンコード方式を制限することにより、本実施の形態によれば、ＣＳ網に接続したＵＥがビット誤り耐性を有さない方式を用いるコーデックが設定された場合でも、ＣＳ網におけるビット誤りによる影響を抑えることができる。すなわち、ＣＳ網でＥＶＳコーデックを利用した場合でも、伝送路で発生するビット誤りに対応して正しく復号が行われ、品質劣化を防ぐことができる。
【０１５５】
よって、本実施の形態によれば、ビット誤りを生じる可能性のある網で使用される場合においても、品質の劣化を抑えて通信を継続させることができる。
【０１５６】
なお、通信開始時のＩＭＳによるセッションセットアップの際（例えば、図６及び図１１のＳＴ６０１）、サービスを提供するオペレータ間で、使用するペイロードフォーマットに対するポリシが異なる場合が考えられる。このポリシは、例えば、非特許文献９に記載のＥＶＳコーデックのＲＴＰペイロードフォーマットにおける、コンパクトフォーマットとヘッダフルフォーマットの両方を用いる方式か、又はヘッダフルフォーマットのみを用いる方式かを表すポリシ、または、非特許文献８に記載のＡＭＲ又はＡＭＲ−ＷＢコーデックのＲＴＰペイロードフォーマットにおける、Bandwidth-Efficientモードを用いる方式か、Octet-Aligned Modeモードを用いる方式かを表すポリシを意味する。このペイロードフォーマットに関するポリシが異なる場合、ＩＭＳノード３１０は、ポリシの違いを許可し、例えばＡＴＧＷなどのデータ経路上に存在するノードがペイロードフォーマットを変更（トランスフォーマット）してもよい。
【０１５７】
以上、本開示の各実施の形態について説明した。
【０１５８】
なお、上記各実施の形態では、ＡＴＣＦ／ＡＴＧＷ３２０、ＭＳＣ／ＭＧＷ１１０、ＳＣＣ  ＡＳ／ＣＳＣＦをそれぞれ一つのノードとして説明した。しかし、ＡＴＣＦ／ＡＴＧＷ３２０、ＭＳＣ／ＭＧＷ１１０、ＳＣＣ  ＡＳ／ＣＳＣＦは、互いにインタフェースによって接続される２つ以上の別々のノードで構成されてもよい。すなわち、ＡＴＣＦとＡＴＧＷとの間、ＭＳＣとＭＧＷとの間、及び、ＳＣＣ  ＡＳとＣＳＣＦとの間のそれぞれにおいて、上述した機能を複数のノードに分散させてもよい。
【０１５９】
また、上記各実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、これに限らず、音楽、音響、画像等に関しても、本開示の一態様は適用可能である。
【０１６０】
また、本開示の一態様は、上記各実施の形態に限定されず、種々変更して実施することが可能である。
【０１６１】
また、上記各実施の形態では、本開示の一態様をハードウェアで構成する場合を例にとって説明したが、本開示はハードウェアとの連携においてソフトウェアでも実現することも可能である。
【０１６２】
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。集積回路は、上記実施の形態の説明に用いた各機能ブロックを制御し、入力と出力を備えてもよい。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１６３】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）または、ＬＳＩ内部の回路セルの接続若しくは設定を再構成可能なリコンフィギュラブル／プロセッサを利用してもよい。
【０１６４】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【産業上の利用可能性】
【０１６５】
本開示の一態様は、ＵＥのハンドオーバ先であるＣＳ網でサポートしているコーデック／コーデックモードが、通信開始時のセッションセットアップにおいて折衝されたコーデック／コーデックモードと異なる場合でも、サービスオペレータのポリシ又はセッションセットアップにおいて折衝された内容から外れることなく、通信を継続することができる。また、ＣＳ網に接続したＵＥがビット誤り耐性を有さない方式を用いるコーデックを使用する場合でも、ＣＳ網におけるビット誤りによる影響を抑えた通信を行うことに有用である。
【符号の説明】
【０１６６】
１００，１０２  ＵＥ
２００，２０２，２０４，２０６，３００，３０２，３０４，３０６  シグナリング
１１０  ＭＳＣ／ＭＧＷ
３１０  ＩＭＳノード
３２０  ＡＴＣＦ／ＡＴＧＷ
５００，１０００，１２００  受信部
５０２，１００２，１２０２  送信部
５０４，１００４  記憶部
５０６，１００６，１２０８  判断部
５０８，１００８  ポシリ参照部
５１０，１０１０  シグナリング生成部
１２０４  接続先検出部
１２０６  コーデック検出部
１２１０  コマンド送信部
１２１２  通知送受信部
【図１】
2016185649.tif 000003
【図２】
2016185649.tif 000004
【図３】
2016185649.tif 000005
【図４】
2016185649.tif 000006
【図５】
2016185649.tif 000007
【図６】
2016185649.tif 000008
【図７】
2016185649.tif 000009
【図８】
2016185649.tif 000010
【図９】
2016185649.tif 000011
【図１０】
2016185649.tif 000012
【図１１】
2016185649.tif 000013
【図１２】
2016185649.tif 000014
【国際調査報告】
2016185649.tif 000015
2016185649.tif 000016
2016185649.tif 000017
2016185649.tif 000018
2016185649.tif 000019
2016185649.tif 000020
2016185649.tif 000021
2016185649.tif 000022