特許 6012625 ネットワークノード及び通信方法

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

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

(11)【特許番号】6012625

(24)【登録日】2016年9月30日

(45)【発行日】2016年10月25日

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

(51)【国際特許分類】

   H04W 36/14 20090101AFI20161011BHJP

【ＦＩ】

   H04W36/14

【請求項の数】4

【全頁数】20

(21)【出願番号】特願2013-546973(P2013-546973)

(86)(22)【出願日】2012年11月16日

(86)【国際出願番号】JP2012007358

(87)【国際公開番号】WO2013080471

(87)【国際公開日】20130606

【審査請求日】2015年8月26日

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

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

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

(73)【特許権者】

【識別番号】514136668

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

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

(74)【代理人】

【識別番号】100105050

【弁理士】

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

(72)【発明者】

【氏名】堀 貴子

【審査官】 石田 昌敏

(56)【参考文献】

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

【文献】 特表２０１１−５１４７５５（ＪＰ，Ａ）

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

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

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

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

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

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

【請求項1】

第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末間のデータを転送するネットワークノードであって、
前記一方の端末が前記第１の網で使用していた第１のコーデック、及び、前記一方の端末が前記第２の網で使用する第２のコーデックを検出する検出手段と、
前記第１のコーデックが前記第２のコーデックとの間の互換モードを有するコーデックである場合、前記一方の端末から送信されるデータのコーデックを、前記第１のコーデックの前記互換モードに切り替えることにより、他方の端末向けのデータを生成する生成手段と、
前記他方の端末向けのデータを、前記他方の端末へ送信する送信手段と、
を具備するネットワークノード。

【請求項2】

前記送信手段は、前記第１のコーデックが前記第２のコーデックとの間の互換モードを有するコーデックである場合、前記一方の端末から送信されるデータを、前記第１のコーデックのフォーマットを用いて、前記互換モードで送信する、
請求項１記載のネットワークノード。

【請求項3】

前記送信手段は、前記生成手段において前記一方の端末から送信されるデータのコーデックが切り替えられた場合、前記他方の端末が送信するデータに対する前記互換モードへの切替要求を、前記他方の端末へ送信する、
請求項１記載のネットワークノード。

【請求項4】

第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末間のデータを転送する通信方法であって、
前記一方の端末が前記第１の網で使用していた第１のコーデック、及び、前記一方の端末が前記第２の網で使用する第２のコーデックを検出し、
前記第１のコーデックが前記第２のコーデックとの間の互換モードを有するコーデックである場合、前記一方の端末から送信されるデータのコーデックを、前記第１のコーデックの前記互換モードに切り替えることにより、他方の端末向けのデータを生成し、
前記他方の端末向けのデータを、前記他方の端末へ送信する、
通信方法。

【発明の詳細な説明】

【技術分野】

【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】

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

【0024】

また、例えば、非特許文献４に記載のＥＶＳ（Enhanced Voice Service）のように、ＰＳ網（ＶｏＬＴＥ）で利用される、ＡＭＲ−ＷＢ以外の他のコーデックとして、ＡＭＲ−ＷＢ互換モードをサポートするコーデックもある。ＡＭＲ−ＷＢ互換モードは、通常ＡＭＲ−ＷＢコーデックをサポートするレガシー端末との間でＡＭＲ−ＷＢコーデックとして使用されることを想定している。このため、ＰＳ網（ＶｏＬＴＥ）で当該コーデックが利用される際には、非特許文献２に記載のＡＭＲ−ＷＢコーデックのＲＴＰペイロードフォーマットが用いられることが考えられる。

【0025】

なお、従来技術において、狭帯域（ＮＢ：Narrowband）コーデックとは、８ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。なお、狭帯域コーデックでは、一般的に３００Ｈｚ〜３．４ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０〜４ｋＨｚの範囲内であればよい。また、広帯域コーデックとは、１６ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。なお、広帯域コーデックでは、一般的に５０Ｈｚ〜７ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０〜８ｋＨｚの範囲内であればよい。また、超広帯域（ＳＷＢ：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】3GPP TS22.813 v10.0.0 “Study of Use Cases and Requirements for Enhanced Voice Codecs for the Evolved Packet System (EPS)”

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

【非特許文献6】3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction”

【非特許文献7】G. Zorn (Ed), “RTP Payload Format for G.718 Speech/Audio,” November 15, 2011, work in progress

【非特許文献8】3GPP TR23.885 v11.0.0 “Feasibility Study of Single Radio Voice Call Continuity (SRVCC) from UTRAN/GERAN to E-UTRAN/HSPA”

【発明の概要】

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

【0027】

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

【0028】

前者のトランスコーディングを行う方法では、トランスコーディングによる通話品質の劣化が生じてしまう。

【0029】

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

【0030】

本発明の目的は、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができるネットワークノード及び通信方法を提供することである。

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

【0031】

本発明の一態様に係るネットワークノードは、第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末間のデータを転送するネットワークノードであって、前記一方の端末が前記第１の網で使用していた第１のコーデック、及び、前記一方の端末が前記第２の網で使用する第２のコーデックを検出する検出手段と、前記第１のコーデックが前記第２のコーデックとの間の互換モードを有するコーデックである場合、前記一方の端末から送信されるデータのコーデックを、前記第１のコーデックの前記互換モードに切り替えることにより、他方の端末向けのデータを生成する生成手段と、前記他方の端末向けのデータを、前記他方の端末へ送信する送信手段と、を具備する構成を採る。

【0032】

本発明の一態様に係る通信方法は、第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末間のデータを転送する通信方法であって、前記一方の端末が前記第１の網で使用していた第１のコーデック、及び、前記一方の端末が前記第２の網で使用する第２のコーデックを検出し、前記第１のコーデックが前記第２のコーデックとの間の互換モードを有するコーデックである場合、前記一方の端末から送信されるデータのコーデックを、前記第１のコーデックの前記互換モードに切り替えることにより、他方の端末向けのデータを生成し、前記他方の端末向けのデータを、前記他方の端末へ送信する。

【発明の効果】

【0033】

本発明によれば、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができる。

【図面の簡単な説明】

【0034】

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

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

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

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

【図5】本発明の実施の形態１に係るＲＴＰペイロードフォーマットの一例を示す図

【図6】本発明の実施の形態１に係るＳＤＰオファー及びＳＤＰアンサーの一例を示す図

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

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

【図9】本発明の実施の形態１に係るＭＳＣ／ＭＧＷにおけるコーデック切替処理の一例を示すフローチャート

【図10】本発明の実施の形態１に係るコーデック切替要求の通知例を示す図

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

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

【0035】

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

【0036】

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

【0037】

また、以下の説明では、ＰＳ網及びＣＳ網の双方において利用可能なコーデックを「コーデックＡ」と表す。コーデックＡは、専用のペイロードフォーマットを持つ。コーデックＡは、例えば、ＡＭＲ−ＷＢ又はＡＭＲ−ＮＢである。

【0038】

また、ＰＳ網において利用可能なコーデックを「コーデックＢ」と表す。コーデックＢは、コーデックＡに対する、非互換モード（コーデックＡ非互換モード）と互換モード（コーデックＡ互換モード）とを有する。ただし、コーデックＢはＣＳ網で利用されてもよい。コーデックＢは、例えば、ＥＶＳ又は非特許文献７に記載のＧ．７１８である。

【0039】

（実施の形態１）
図５は、コーデックＢのペイロードフォーマット（ＲＴＰペイロードフォーマット）の一例を示す。図５に示すように、ペイロードフォーマットは、データ部とヘッダ部とにより構成される。データ部にはエンコーダによりエンコードされたデータが含まれ、ヘッダ部にはデコーダがデータ部のデータをデコードするために必要な情報が含まれる。

【0040】

本実施の形態におけるコーデックＢのペイロードフォーマットは、データ部にコーデックＡ非互換モードのデータが含まれるのか、コーデックＡ互換モードのデータが含まれるのかをペイロード受信側で識別できる構成を持つ。例えば、図５に示すように、ヘッダ部には、「コーデックタイプ」フィールドと「ビットレート」フィールドが含まれる。「コーデックタイプ」には、コーデックＡ非互換モード又はコーデックＡ互換モードのいずれであるかを示す情報が含まれる。「ビットレート」には、コーデックＡ非互換モード、コーデックＡ互換モードのそれぞれでサポートしているビットレートのうち、どのビットレートでエンコードされたデータであるかを示す情報が含まれる。

【0041】

また、図５に示すように、上記フィールドの他に、ペイロード受信側である相手端末に対してコーデックタイプ又はビットレートの切替要求指示を行うフィールド（「コーデックタイプ・ビットレート切替要求」フィールド）を含んでもよい。なお、このフィールドは、フレーム毎に含まれる必要はなく、必要な時にだけ含まれてもよい。

【0042】

なお、図５に示すコーデックＢのペイロードフォーマットにおいて、データ部にコーデックＡ非互換モードのデータが含まれるのか、コーデックＡ互換モードのデータが含まれるのかをペイロード受信側で識別できる構成を取るためのフィールド（「コーデックタイプ」フィールド、「ビットレート」フィールド）、及び、相手端末に対して、コーデックタイプ又はビットレートの切替要求指示を行うフィールド（「コーデックタイプ・ビットレート切替要求」フィールド）を、ヘッダ部に明示的に含める方法を示した。しかし、必ずしも図５に示す方法でなくてもよい。また、図５に示すペイロードフォーマットの一例では、ペイロードフォーマットがヘッダ部とデータ部とから構成される例を示したが、ヘッダ部が無くてもペイロードを受け取った受信側の端末が正しくデータをデコードできる場合には、ペイロードフォーマットにおいてヘッダ部は無くてもよい。

【0043】

また、コーデックＢのペイロードフォーマットは図５に示す一例に限らず、例えば、非特許文献７に記載のＧ．７１８のペイロードフォーマットのように、各レイヤの組み合わせ（ビットレート相当）が、別々の値として記述されていてもよい。

【0044】

次に、図６は、通話開始時のセッション折衝において端末間でやり取りされる、ＳＤＰ（Session Description Protocol）オファー及びＳＤＰアンサーの一例を示す。

【0045】

ここでは、通話を行う双方のＵＥがコーデックＢをサポートしており、かつ、通話開始時に共にＰＳ網に接続していると仮定する。

【0046】

図６に示すように、コーデックＢをサポートするＵＥは、コーデックＡをサポートしていない場合においても、コーデックＡ及びコーデックＢをＳＤＰオファーに記述する。これは、相手端末が、コーデックＡをサポートしているがコーデックＢをサポートしていなかった場合、コーデック折衝においてコーデックＡを選択し、コーデックＢのコーデックＡ互換モードをコーデックＡのＲＴＰペイロードフォーマットを用いて使用する事を可能にするためである。図６では、ＳＤＰオファーを受け取ったＵＥは、コーデックＢを選択し、選択したコーデックＢをＳＤＰアンサーに記述する。

【0047】

なお、このＳＤＰオファー及びＳＤＰアンサーの中に、コーデックＢを選択した場合に優先されるモード（コーデックＡ非互換モード又はコーデックＡ互換モード、ビットレート、帯域幅等）が記述されていてもよい。優先されるモードは、通信サービスを行うオペレータによって予め決められ、ソフトウェアの形式等でＵＥに組み込まれていてもよい。本実施の形態では、コーデックＢが選択された場合、コーデックＡ非互換モードを優先モードとして使用すると仮定する。

【0048】

次に、本実施の形態に係る移動通信ネットワーク（図１）について説明する。

【0049】

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

【0050】

図７は、本実施の形態に係るＵＥ１００，１０２（端末）の構成を示すブロック図である。ＵＥ１００，１０２は、受信部７００、送信部７０２、コーデック折衝部７０４、ＲＴＰペイロード解析部７０６、ＲＴＰペイロード生成部７０８及びコーデック通知部７１０を有して構成される。

【0051】

図７に示すＵＥ１００，１０２において、受信部７００は、通信データ（ＲＴＰペイロードを含む）及びシグナリング等を受信する。例えば、受信部７００は、ＭＳＣ／ＭＧＷ１１０から送信されるＲＴＰペイロード（例えば図５参照）を受信すると、受信したＲＴＰペイロードをＲＴＰペイロード解析部７０６に出力する。

【0052】

送信部７０２は、通信データ（ＲＴＰペイロードを含む）及びシグナリング等を送信する。

【0053】

コーデック折衝部７０４は、端末（ＵＥ１００，ＵＥ１０２）間の通信に使用するコーデックを折衝する。具体的には、コーデック折衝部７０４は、ＳＤＰオファー又はＳＤＰアンサーを作成し（例えば図６参照）、コーデック折衝を行う。この際、コーデック折衝部７０４は、ＳＤＰオファーを作成する際、前述の通り、端末がコーデックＢをサポートするがコーデックＡをサポートしていない場合においても、図６のようにコーデックＡをＳＤＰオファーに含める。またコーデック折衝部７０４は、折衝においてコーデックＢが選択された場合、前述のようにＳＤＰオファー及びアンサーの中に記述された情報、又はあらかじめソフトウェア等に組み込まれた情報に従い、優先されるモード（コーデックＡ非互換モード又はコーデックＡ互換モード、ビットレート、帯域幅等）を選択し、ＲＴＰペイロード生成部７０８に出力する。

【0054】

ＲＴＰペイロード解析部７０６は、受信部７００から受け取ったＲＴＰペイロードのヘッダ部を解析して、ＲＴＰペイロードのデータ部に含まれるデータに関する情報（例えば、コーデックタイプ、ビットレート等）を特定する。ＲＴＰペイロード解析部７０６は、特定した情報及びデータ部に含まれるデータをデコーダ（図示せず）に出力する。また、ＲＴＰペイロード解析部７０６は、受信部７００から受け取ったＲＴＰペイロードに「コーデックタイプ・ビットレート切替要求」の指示が含まれる場合には、当該指示をエンコーダ（図示せず）及びＲＴＰペイロード生成部７０８に出力する。エンコーダは、ＲＴＰペイロード解析部７０６からの情報及び指示に基づいてデータをエンコードする。

【0055】

ＲＴＰペイロード生成部７０８は、エンコーダから受け取ったデータ及びコーデック折衝部７０４から受け取った当該データに関する情報（例えば、コーデックタイプ、ビットレート等）を含むＲＴＰペイロード（例えば、図５参照）を生成する。この際、ＲＴＰペイロード生成部７０８は、ＲＴＰペイロード解析部７０６から、「コーデックタイプ・ビットレート切替要求」の指示が入力される場合には、当該指示に基づいてＲＴＰペイロードを生成する。生成されたＲＴＰペイロードは、送信部７０２を介して送信される。

【0056】

コーデック通知部７１０は、自機がＰＳ網からＣＳ網へハンドオーバする際、自機がＰＳ網で使用しているコーデックをＰＳ網のネットワークノード（例えばＭＭＥ等）に通知する。通知されたコーデックは、ＰＳ網のネットワークノード（ＭＭＥ）を介して、ＭＳＣ／ＭＧＷ１１０に通知される。

【0057】

次いで、図１に示すＭＳＣ／ＭＧＷ１１０について説明する。図８は、本実施の形態に係るＭＳＣ／ＭＧＷ１１０（ネットワークノード）の構成を示すブロック図である。ＭＳＣ／ＭＧＷ１１０は、受信部８００、送信部８０２、コーデック検出部８０４、コーデック折衝部８０６、ＲＴＰペイロード生成部８０８及びＲＴＰペイロード解析部８１０を有して構成される。

【0058】

図８に示すＭＳＣ／ＭＧＷ１１０において、受信部８００は、通信データ（ＲＴＰペイロードを含む）、シグナリング等を受信する。例えば、受信部８００は、ＵＥ１０２から送信されるＲＴＰペイロード（例えば図５参照）を受信すると、受信したＲＴＰペイロードをＲＴＰペイロード解析部８１０に出力する。

【0059】

送信部８０２は、通信データ（ＲＴＰペイロードを含む）、シグナリング等を送信する。

【0060】

コーデック検出部８０４は、ＰＳ網からＣＳ網にハンドオーバした端末（図１ではＵＥ１００）がＣＳ網で使用するコーデックを検出する。また、コーデック検出部８０４は、ＰＳ網からＣＳ網にハンドオーバした端末（図１ではＵＥ１００）がＰＳ網で使用していたコーデックを検出する。端末（ＵＥ１００）がＰＳ網で使用していたコーデックを検出する方法としては、非特許文献５に開示されているように、ＵＥ１００（コーデック通知部７１０）がＣＳ網にハンドオーバする際にＰＳ網のネットワークノード（ＭＭＥなど）から通知される方法でもよい。または、端末（ＵＥ１００）がＰＳ網で使用していたコーデックを検出する方法としては、例えば、ＳＣＣ ＡＳ等の他のネットワークノードから取得する方法でもよい。また、端末（ＵＥ１００）がＣＳ網で使用しているコーデックを検出する方法としては、ＵＥ１００がＣＳ網にハンドオーバした際に、ＵＥ１００とＣＳ網内のネットワークノード（ＲＮＣ及びＭＳＣ／ＭＧＷ１１０）との間で送受信されるシグナリングにより折衝された情報を利用する方法がある。コーデック検出部８０４は、コーデックの検出結果をＲＴＰペイロード生成部８０８に出力する。

【0061】

コーデック折衝部８０６は、例えば、ＲＴＰペイロード生成部８０８からの指示に従って、ＵＥとの間で使用するコーデックを折衝する。例えば、コーデック折衝部８０６は、ＰＳ網からＣＳ網にハンドオーバした端末（図１ではＵＥ１００）の通信相手である端末（図１ではＵＥ１０２）との間で使用するコーデックを折衝（再折衝）する。

【0062】

ＲＴＰペイロード生成部８０８は、コーデック検出部８０４から入力されるコーデックの検出結果に基づいて、端末（図１ではＵＥ１００）から受け取ったデータを用いて、当該端末の通信相手（図１ではＵＥ１０２）向けのデータ（ＲＴＰペイロード）を生成する。例えば、ＲＴＰペイロード生成部８０８は、ＰＳ網からＣＳ網へハンドオーバした端末がＣＳ網で使用するコーデックがコーデックＡであり、当該端末がＰＳ網で使用していたコーデックがコーデックＢである場合、当該端末から受け取ったデータ（コーデックＡのデータ）のコーデックを、コーデックＢのコーデックＡ互換モードに切り替える。すなわち、ＭＳＣ／ＭＧＷ１１０は、当該端末から受け取ったコーデックＡのデータを、コーデックＢのＲＴＰペイロードフォーマット（図５参照）を用いて、コーデックＢのコーデックＡ互換モードとして、送信部８０２を介して送信する。

【0063】

また、コーデック検出部８０４から入力されるコーデックの検出結果が上記以外の場合には、ＲＴＰペイロード生成部８０８は、例えば、コーデック折衝部８０６に対して、受け取ったデータの送信先である通信相手（図１ではＵＥ１０２）との間のコーデックの折衝（再折衝）を指示する。そして、ＲＴＰペイロード生成部８０８は、ハンドオーバした端末から受け取った通信データを折衝結果に基づいて必要であればトランスコーディングし、折衝結果に基づくコーデックモードに切り替える。コーデック切替後のデータ（生成されたＲＴＰペイロード）は、送信部８０２を介して送信される。

【0064】

ＲＴＰペイロード解析部８１０は、端末（ＵＥ１０２）から送信されるＲＴＰペイロードのヘッダ部を解析して、ＲＴＰペイロードのデータ部に含まれるデータに関する情報（例えば、コーデックタイプ、ビットレート等）を特定する。ＲＴＰペイロード解析部８１０は、特定した情報をコーデック検出部８０４に出力する。

【0065】

次いで、図９を用いて、ＭＳＣ／ＭＧＷ１１０（図８）におけるコーデック処理の詳細について説明する。なお、ここでは、図１に示すように、ＵＥ１００とＵＥ１０２とが共にＰＳ網に接続されて通話を行っている途中に、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバした場合について説明する。すなわち、ＭＳＣ／ＭＧＷ１１０は、ＰＳ網において通信を行う２つの端末（ＵＥ１００，１０２）のうち一方のＵＥ１００がＣＳ網にハンドオーバした際に、２つの端末間のデータを転送するネットワークノードである。

【0066】

図９に示すＳＴ９００において、ＲＴＰペイロード生成部８０８は、コーデック検出部８０４での検出結果に基づいて、ＵＥ１００がＣＳ網で使用するコーデックがコーデックＡであるか否かを判断する。

【0067】

ＵＥ１００がＣＳ網で使用するコーデックがコーデックＡである場合（ＳＴ９００：ＹＥＳ）、ＳＴ９０２において、ＲＴＰペイロード生成部８０８は、コーデック検出部８０４での検出結果に基づいて、ＵＥ１００がＰＳ網で（ハンドオーバ前に）使用していたコーデックがコーデックＢであるか否かを判断する。

【0068】

ＵＥ１００がＰＳ網で使用していたコーデックがコーデックＢである場合（ＳＴ９０２：ＹＥＳ）、ＳＴ９０４において、ＲＴＰペイロード生成部８０８は、ＵＥ１００から送信されたデータ（コーデックＡ）のコーデックを、コーデックＢのコーデックＡ互換モードに切り替える。つまり、ＲＴＰペイロード生成部８０８は、ＵＥ１００から送信されたコーデックＡのデータを、コーデックＢのＲＴＰペイロードフォーマットを用いてコーデックＢのコーデックＡ互換モードとして、送信部８０２を介してＵＥ１０２へ送信する。

【0069】

これにより、コーデックＢを使用するＵＥ１０２は、ＭＳＣ／ＭＧＷ１１０からＵＥ１０２へ送信されるデータを、コーデックＢのデータ（コーデックＢのコーデックＡ互換モード）として扱うことが可能となる。

【0070】

一方、ＵＥ１００がＣＳ網で使用するコーデックがコーデックＡではない場合（ＳＴ９００：ＮＯ）、又は、ＵＥ１００がＰＳ網で使用していたコーデックがコーデックＢではない場合（ＳＴ９０２：ＮＯ）、ＳＴ９０６において、コーデック折衝部８０６は、ＵＥ１０２との間でセッション再折衝を行って、コーデックを決定する。そして、ＲＴＰペイロード生成部８０８は、決定されたコーデックのＲＴＰペイロードを生成する。

【0071】

または、ＳＴ９０６において、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００から送信されたデータに対してトランスコーディングを行い、トランスコーディング後のデータ（ＵＥ１０２向けのデータ）をＵＥ１０２に送信してもよい。

【0072】

このようにして、ＭＳＣ／ＭＧＷ１１０は、一方のＵＥのコーデックの変更が検出された場合、当該ＵＥの変更後のコーデックと、当該ＵＥの変更前のコーデックとに基づいて、他方のＵＥ向けデータのコーデックを切り替えることが可能であるか否かを判断する。

【0073】

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

【0074】

以下の説明では、図１及び図２において、ＵＥ１００及びＵＥ１０２の双方ともにＰＳ網に接続され、通話を開始する。ここでは、ＵＥ１００からＵＥ１０２へ発呼を行うと仮定する。

【0075】

通話開始の際、ＵＥ１００とＵＥ１０２との間で使用するコーデックの折衝が行われる。例えば、ＵＥ１００（コーデック折衝部７０４）は、ＳＤＰオファー（例えば図６参照）を生成し、ＵＥ１０２に送信する。これに対して、ＵＥ１０２（コーデック折衝部７０４）は、ＳＤＰアンサー（例えば、図６参照。図６ではコーデックＢを選択）を生成し、ＵＥ１００に送信する。この通話開始に伴う一例の動作が完了すると、ＵＥ１００，１０２は、コーデックＢのコーデックＡ非互換モード（コーデックＢを選択した場合に優先されるモード）を用いて通話を行う（図２：Speech Session over PS）。

【0076】

次いで、図１に示すように、ＵＥ１００がＰＳ網からＣＳ網へハンドオーバする（図２に示すＳＴ２００及びＳＴ２０４）。ここでは、ＵＥ１００がＣＳ網で使用するコーデックをコーデックＡとする。

【0077】

ＵＥ１００のハンドオーバ処理と同時に、ＭＳＣ／ＭＧＷ１１０（コーデック検出部８０４）は、ＵＥ１００がＣＳ網にハンドオーバした際に使用するコーデックを検出する。また、ＭＳＣ／ＭＧＷ１１０（コーデック検出部８０４）は、ＵＥ１００がＰＳ網で使用していたコーデックを検出する。上述したように、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００がＣＳ網で使用するコーデックがコーデックＡであり、ＵＥ１００がＰＳ網で使用していたコーデックがコーデックＢであることを検出する（つまり、図９に示すＳＴ９００：ＹＥＳかつＳＴ９０２：ＹＥＳ）。

【0078】

この場合、ＭＳＣ／ＭＧＷ１１０（ＲＴＰペイロード生成部８０８）は、ＵＥ１００から送信されたデータ（コーデックＡ）のコーデックを、コーデックＢのコーデックＡ互換モードに切り替えることにより、ＵＥ１０２向けのＲＴＰペイロードを生成する。つまり、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００から送信されたコーデックＡのデータを、コーデックＢのＲＴＰペイロードフォーマットを用いて、コーデックＢのコーデックＡ互換モードとしてＵＥ１０２へ送信する。

【0079】

また、この際、ＭＳＣ／ＭＧＷ１１０は、ＲＴＰペイロード生成部８０８においてＵＥ１００から送信されるデータのコーデックが切り替えられた場合、コーデックＡ非互換モードからコーデックＡ互換モードへの切替要求を、ＵＥ１００の通信相手であるＵＥ１０２へ送信してもよい。例えば、ＭＳＣ／ＭＧＷ１１０（ＲＴＰペイロード生成部８０８）は、コーデックＢのＲＴＰペイロードフォーマット（例えば図５参照）において、コーデックＡ非互換モードからコーデックＡ互換モードへの切替指示をヘッダ部（「コーデックタイプ・ビットレート切替要求」フィールド）に含めてもよい。

【0080】

一方、ＵＥ１０２（ＲＴＰペイロード解析部７０６）は、ＭＳＣ／ＭＧＷ１１０から受け取るデータに含まれる情報（ＲＴＰペイロードのヘッダ部の情報）から、ＲＴＰペイロードのデータ部に含まれるデータがコーデックＡ（コーデックＡ互換モードとして扱うことができるコーデック）であることを判断し、当該情報及びデータをデコーダに渡す。これにより、ＵＥ１０２のデコーダは、受け取ったデータのコーデックがコーデックＡ（コーデックＢのコーデックＡ互換モード）であると認識して、当該データをデコードする。

【0081】

また、ＵＥ１０２（例えば、ＲＴＰペイロード解析部７０６）は、受信したＲＴＰペイロードに、コーデックＡ非互換モードからコーデックＡ互換モードへの切替要求が含まれている場合、当該切替要求をエンコーダ（図示せず）及びＲＴＰペイロード生成部７０８に出力する。これにより、ＵＥ１０２は、自機から送信するデータに対してもコーデックＢのコーデックＡ互換モードを用いることを決定する。すなわち、ＵＥ１０２（ＲＴＰペイロード生成部７０８）は、エンコーダより受け取ったコーデックＡ互換モードのデータを、コーデックＢのペイロードフォーマットに格納して、ＭＳＣ/ＭＧＷ１１０へ送信する。

【0082】

このように、本実施の形態では、ＭＳＣ／ＭＧＷ１１０において、コーデック検出部８０４は、ＵＥ１００がＰＳ網で使用していたコーデック、及び、ＵＥ１００がＣＳ網で使用するコーデックを検出し、ＲＴＰペイロード生成部８０８は、ＵＥ１００がＰＳ網で使用していたコーデックが、ＵＥ１００がＣＳ網で使用するコーデックとの間の互換モードを有するコーデックである場合、ＵＥ１００から送信されるデータのコーデックを、ＵＥ１００がＰＳ網で使用していたコーデックの互換モードに切り替えることにより、ＵＥ１０２向けのデータを生成する。すなわち、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００がＰＳ網で使用していたコーデックが、ＵＥ１００がＣＳ網で使用するコーデックとの間の互換モードを有するコーデックである場合、ＵＥ１００から送信されるコーデックＡのデータを、コーデックＢのＲＴＰペイロードフォーマットを用いてコーデックＡ互換モードで送信する。これにより、コーデックＢを使用するＵＥ１０２は、自機のコーデックを変更することなく、ＵＥ１００からのデータを受け取ることができる。

【0083】

つまり、ＭＳＣ／ＭＧＷ１１０においてＵＥ１００からのハンドオーバ後のコーデックのデータをハンドオーバ前のコーデックの一部（ハンドオーバ前のコーデックのモードの一つ）に切り替えることで、ＵＥ１００及びＵＥ１０２との間では、コーデックを変更するためのシグナリングが不要となるので、通話が途切れる時間が長くなることを防ぐことができる。また、ＭＳＣ／ＭＧＷ１１０において、ＵＥ１００とＵＥ１０２との間のコーデックのデータの変更を行わず、コーデックのモードだけを切り替えることで、トランスコーディングのように通話品質の劣化が生じることを防ぐことができる。よって、本実施の形態によれば、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができる。

【0084】

また、本実施の形態では、ＭＳＣ／ＭＧＷ１１０は、一方の端末（ＵＥ１００）から送信されるデータのコーデックが切り替えられた場合、他方の端末（ＵＥ１０２）が送信するデータに対する互換モードへの切替要求を、当該他方の端末（ＵＥ１０２）へ送信する。そして、ＵＥ１０２は、ＭＳＣ／ＭＧＷ１１０からのコーデックＡ互換モードへの切替要求に従ってコーデックＡ互換モードのデータを送信する。これにより、ＭＳＣ／ＭＧＷ１１０及びＵＥ１００は、ＵＥ１０２から送信されるデータ（コーデックＢのコーデックＡ互換モード）をコーデックＡのデータとして扱うことができる。

【0085】

なお、ＵＥ１０２に対する、コーデックＡ非互換モードからコーデックＡ互換モードへの切替要求の通知は、必ずしもＭＳＣ／ＭＧＷ１１０からＵＥ１０２へのＲＴＰペイロードに含まれる必要はない。例えば、当該切替要求は、図２に示すＳＴ２０２において、ＭＳＣ／ＭＧＷ１１０から送信されるＩＮＶＩＴＥ ｗｉｔｈ ＳＤＰ−ＭＧＷのＳＤＰの中に、図１０に示すＳＤＰオファーとしてＵＥ１０２に通知されてもよい。また、非特許文献６に記載のＲＴＣＰ−ＡＰＰを用いてＭＳＣ／ＭＧＷ１１０からＵＥ１０２に上記切替要求を通知してもよい。

【0086】

また、ＵＥ１０２がコーデックＡのデータをコーデックＢのＲＴＰペイロードフォーマットで受け取った場合、ＵＥ１０２は、当該データの受信後、ＵＥ１０２からのデータ（送信データ）もコーデックＡ互換モードでエンコードすべきと判断してもよい。この場合、上記切替要求は不要となる。

【0087】

（実施の形態２）
図３及び図４用いて、本実施形態について説明する。なお、以下の説明では、実施の形態１と同様、ＵＥ１００及びＵＥ１０２は最初ＰＳ網でコーデックＢを用いて通話を行っており、ＵＥ１００のみがＰＳ網からＣＳ網にハンドオーバしたとする。また、ＵＥ１００がＣＳ網で使用するコーデックをコーデックＡとする。

【0088】

図３及び図４に示すＡＴＣＦ／ＡＴＧＷ３２０は、単なるデータのアンカーポイントである。よって、図３及び図４に示すＡＴＣＦ／ＡＴＧＷ３２０がＵＥ１００からＵＥ１０２へのデータ又はＵＥ１０２からＵＥ１００へのデータをフォワードしている場合において、ＭＳＣ／ＭＧＷ１１０（図８）及びＵＥ１００、ＵＥ１０２（図７）の機能は、実施の形態１（図５〜図９）と同一である。ただし、ＭＳＣ／ＭＧＷ１１０において、ＵＥ１０２へのコーデック切替要求（コーデックＡ非互換モードからコーデックＡ互換モードへの切替要求）の通知の際、図２に示すＳＴ２０２のＩＮＶＩＴＥ ｗｉｔｈ ＳＤＰを使うことができない点のみが実施の形態１と異なる。

【0089】

また、ＡＴＣＦ／ＡＴＧＷ３２０が、ＵＥ１００が図３に示すＰａｔｈ Ｂで使用するコーデック、及び、ＵＥ１０２が図３に示すＰａｔｈ Ａで使用するコーデックの情報を保有、若しくは、他のノードから当該情報を得る手段を具備していたとする。

【0090】

この場合、ＭＳＣ／ＭＧＷ１１０のコーデック検出部８０４が、ＵＥ１００がＰＳ網（図３に示すＰａｔｈ Ｂ）で使用していたコーデックの情報を予め保有していなかった場合でも、ＡＴＣＦ／ＡＴＧＷ３２０は、ＵＥ１００がＰＳ網で使用していたコーデックの情報を、図４に示すＳＴ３０２のＩＮＶＩＴＥ ｗｉｔｈ ＳＤＰ−ＭＧＷの返信メッセージとして、ＭＳＣ／ＭＧＷ１１０に通知することができる。

【0091】

これにより、ＭＳＣ／ＭＧＷ１１０（ＲＴＰペイロード生成部８０８）は、ＵＥ１００（ハンドオーバした端末）がＰＳ網で使用するコーデックを即座に特定することができる。すなわち、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００（ハンドオーバした端末）がＰＳ網で使用するコーデックに基づいて、ＵＥ１００から送信されるデータを、コーデックＢのＲＴＰペイロードフォーマットを用いて、コーデックＡ互換モードとして、ＵＥ１０２に即座に送信することができる。同様に、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１０２への切替要求を、ＵＥ１０２に即座に送信することができる。

【0092】

よって、本実施の形態によれば、ｅＳＲＶＣＣ方式の場合でも、実施の形態１と同様、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができる。

【0093】

（実施の形態３）
本実施の形態では、ＰＳ網からＣＳ網にハンドオーバした端末（図１ではＵＥ１００）がＰＳ網に再び戻ってきた場合について説明する。

【0094】

図１１は、本実施の形態に係るＵＥ１００，１０２（端末）の構成を示すブロック図である。なお、図１１において、実施の形態１（図７）と同一の構成部には同一の符号を付し、説明を省略する。

【0095】

図１１に示すＵＥ１００，１０２において、端末位置特定部１１００は、自機が接続している網（ＰＳ網又はＣＳ網）、つまり、自機の位置を特定する。これにより、自機のハンドオーバが検出可能となる。端末位置特定部１１００は、自機の位置を、接続先（例えば、ｅ−ｎｏｄｅＢ又はｎｏｄｅＢ）の基地局ＩＤから判断してもよく、ＰＳコア網でのコネクション確立によって判断してもよい。

【0096】

例えば、ＰＳ網からＣＳ網にハンドオーバしたＵＥ１００がＰＳ網に再び戻ってきたとする。また、ＵＥ１００は、ＣＳ網でコーデックＡを使用しているとする。このとき、端末位置特定部１１００は、自機がＰＳ網に接続したことを特定する。

【0097】

端末位置特定部１１００でＰＳ網に接続したことを特定したＵＥ１００は、ＵＥ１００のコーデックを、コーデックＡからコーデックＢ（コーデックＡ非互換モード）に切り替える。そして、ＵＥ１００のＲＴＰペイロード生成部７０８は、コーデックＢのペイロードフォーマットを用いてＲＴＰペイロードを生成する。このＲＴＰペイロードは、送信部７０２を介してＵＥ１０２に送信される。

【0098】

一方、ＵＥ１０２のＲＴＰペイロード解析部７０６は、ＵＥ１００から受け取ったデータのコーデックがコーデックＡ互換モードからコーデックＡ非互換モードに切り替わったことを検知する。そして、ＲＴＰペイロード解析部７０６は、ＵＥ１００のコーデックが切り替わったことを示す情報及びデータをデコーダに渡す。これにより、ＵＥ１０２のデコーダは、ＵＥ１００から受け取るデータを、コーデックＢのコーデックＡ非互換モードでデコードする。

【0099】

また、ＵＥ１０２のＲＴＰペイロード解析部７０６は、受信したＲＴＰペイロードにコーデックＡ互換モードからコーデックＡ非互換モードへの切替要求が含まれている場合、この切替要求をエンコーダ及びＲＴＰペイロード生成部７０８に渡す。これにより、ＵＥ１０２は、自機から送信するデータに対してもコーデックＢのコーデックＡ非互換モードを用いることを決定する。すなわち、ＵＥ１０２のＲＴＰペイロード生成部７０８は、エンコーダより渡されたコーデックＡ非互換モードのデータを、コーデックＢのペイロードフォーマットに格納し、ＵＥ１００へ送信する。

【0100】

なお、ＵＥ１０２に対する、コーデックＡ互換モードからコーデックＡ非互換モードへの切替要求の通知は、必ずしもＵＥ１００からＵＥ１０２へのＲＴＰペイロードに含まれる必要はない。例えば、非特許文献８に記載のＩＭＳメッセージに当該切替要求を含めてもよい。また、非特許文献６に記載のＲＴＣＰ−ＡＰＰを用いてＭＳＣ／ＭＧＷ１１０からＵＥ１０２に当該切替要求を通知してもよい。

【0101】

また、ＵＥ１０２がコーデックＡ非互換モードのデータをコーデックＢのＲＴＰペイロードフォーマットで受け取った場合、ＵＥ１０２は、当該データの受信後、ＵＥ１０２にからのデータ（送信データ）もコーデックＡ非互換モードでエンコードすべきと判断してもよい。この場合、上記切替要求は不要となる。

【0102】

こうすることで、ＰＳ網からＣＳ網にハンドオーバした端末がＰＳ網に再び戻ってきた場合でも、当該端末が自機の現在位置に基づいてコーデックを変更することで、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができる。

【0103】

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

【0104】

なお、上記各実施の形態では、ＡＴＣＦ／ＡＴＧＷ３２０、ＭＳＣ／ＭＧＷ１１０、ＳＣＣ ＡＳ／ＣＳＣＦをそれぞれ一つのノードとして説明した。しかし、ＡＴＣＦ／ＡＴＧＷ３２０、ＭＳＣ／ＭＧＷ１１０、ＳＣＣ ＡＳ／ＣＳＣＦは、互いにインタフェースによって接続される２つ以上の別々のノードで構成されてもよい。すなわち、ＡＴＣＦとＡＴＧＷとの間、ＭＳＣとＭＧＷとの間、及び、ＳＣＣ ＡＳとＣＳＣＦとの間のそれぞれにおいて、上述した機能を複数のノードに分散させてもよい。

【0105】

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

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【産業上の利用可能性】

【0112】

本発明は、通信中の通信端末の一方が利用するコーデックが変更になった場合でも通話品質の劣化を生じさせることなく、かつ、通信が途切れる時間を抑えて通信を継続することに有用である。

【符号の説明】

【0113】

１００，１０２ ＵＥ
２００，２０２，２０４，２０６，３００，３０２，３０４，３０６ シグナリング
１１０ ＭＳＣ／ＭＧＷ
３２０ ＡＴＣＦ／ＡＴＧＷ
７００，８００ 受信部
７０２，８０２ 送信部
７０４，８０６ コーデック折衝部
７０６，８１０ ＲＴＰペイロード解析部
７０８，８０８ ＲＴＰペイロード生成部
７１０ コーデック通知部
８０４ コーデック検出部
１１００ 端末位置特定部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】