(57)【要約】  本開示のネットワークノードは、ｅＳＲＶＣＣに用いるＡＴＣＦ機能を有し、受信したＳＤＰオファー／ＳＤＰアンサーに含まれるコーデック情報を取得するＳＤＰ解析部（７０４）と、ＡＴＧＷ又は近隣のＭＧＷでサポートされるコーデック情報、ＡＴＧＷ又は近隣のＭＧＷでサポートされるトランスコーディングの情報、及び近隣のＣＳ網がサポートしているコーデック情報の少なくとも一つを保持するデータ格納部（７０６）と、ＳＤＰ解析部で取得したコーデック情報、及びデータ格納部から読出した情報を用いてＡＴＣＦから通信端末へコーデック再折衝のためのＳＤＰオファーの送信を可能にするか否かを判断する判断部（７１０）と、を有する。
2015174018.tif 000002
【特許請求の範囲】
【請求項１】
ｅＳＲＶＣＣ（enhanced Single Radio Voice Call Continuity）に用いるＡＴＣＦ機能（Access Transfer Control Function）を有するネットワークノードであって、
ＩＭＳ（IP Multimedia Subsystem）シグナリングに含まれるＳＤＰ（Session Description Protocol）オファーまたはＳＤＰアンサーを受信する受信部と、
前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれるコーデックの情報を取得するＳＤＰ解析部と、
ＡＴＧＷ（Access Transfer Gateway）または近隣のＭＧＷ（Media Gateway）でサポートしているコーデックの情報、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているトランスコーディングの情報、および近隣のＣＳ（Circuit Switching）網がサポートしているコーデックの情報の少なくとも一つを保持するデータ格納部と、
前記ＳＤＰ解析部で取得した前記コーデックの情報、および前記データ格納部から読み出した情報を用いて、前記ＡＴＣＦから通信端末へコーデックを再折衝するためのＳＤＰオファーの送信を可能にするか否かを判断する判断部と、
を有するネットワークノード。
【請求項２】
前記判断部における、前記ＡＴＣＦから前記通信端末へコーデックを再折衝するための前記ＳＤＰオファーの送信を可能にするか否かの判断は、
前記ＡＴＧＷで通話データをアンカーするか否か、または、
前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信するか否か、
の判断である、
請求項１記載のネットワークノード。
【請求項３】
前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているコーデックと一致しない場合、
前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項２記載のネットワークノード。
【請求項４】
前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしている前記コーデックと一致しない場合において、
前記ＳＤＰオファーから前記コーデックを削除して送信する場合には、前記判断部は、前記ＡＴＧＷで通話データをアンカーすると判断し、
前記ＳＤＰオファーから前記コーデックを削除しないで送信する場合には、前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項３記載のネットワークノード。
【請求項５】
前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、
前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項２記載のネットワークノード。
【請求項６】
前記受信部で前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷでサポートしているコーデックと一致しない場合、前記判断部は、前記通信端末にコーデック再折衝のための前記ＳＤＰオファーを送信すると判断する、
請求項２記載のネットワークノード。
【請求項７】
前記受信部で前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記判断部は、前記通信端末にコーデック再折衝のための前記ＳＤＰオファーを送信すると判断する、
請求項２記載のネットワークノード。
【請求項８】
ｅＳＲＶＣＣ（enhanced Single Radio Voice Call Continuity）に用いるＡＴＣＦ機能（Access Transfer Control Function）を有するネットワークノードにおけるシグナリング処理方法であって、
ＩＭＳ（IP Multimedia Subsystem）シグナリングに含まれるＳＤＰ（Session Description Protocol）オファーまたはＳＤＰアンサーを受信し、
前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれるコーデックの情報を取得し、
ＡＴＧＷ（Access Transfer Gateway）または近隣のＭＧＷ（Media Gateway）でサポートしているコーデックの情報、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているトランスコーディングの情報、および近隣のＣＳ（Circuit Switching）網がサポートしているコーデックの情報の少なくとも一つを取得し、
前記取得した情報を用いて、前記ＡＴＣＦから通信端末へコーデックを再折衝するためのＳＤＰオファーの送信を可能にするか否かを判断する、
シグナリング処理方法。
【請求項９】
前記ＡＴＣＦから前記通信端末へコーデックを再折衝するための前記ＳＤＰオファーの送信を可能にするか否かの判断は、
前記ＡＴＧＷで通話データをアンカーするか否か、または、
前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信するか否か、の判断である、
請求項８記載のシグナリング方法。
【請求項１０】
セッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているコーデックと一致しない場合、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項９記載のシグナリング方法。
【請求項１１】
セッションセットアップの際に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしている前記コーデックと一致しない場合において、
前記ＳＤＰオファーから前記コーデックを削除して送信する場合には、前記ＡＴＧＷで通話データをアンカーすると判断し、
前記ＳＤＰオファーから前記コーデックを削除しないで送信する場合には、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項１０記載のシグナリング方法。
【請求項１２】
セッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項９記載のシグナリング方法。
【請求項１３】
前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷでサポートしているコーデックと一致しない場合、前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信すると判断する、
請求項９記載のシグナリング方法。
【請求項１４】
前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信すると判断する、
請求項９記載のシグナリング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、移動通信方式で用いられるネットワークノード及び当該ネットワークノードで実行するシグナリング処理方法に関する。
【背景技術】
【０００２】
従来、３ＧＰＰ（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）であるＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。ここで、ＵＥ１００とＵＥ１０２が通話を開始する場合、セッションセットアップ(Session setup)処理が行われる。すなわちＵＥ１００とＵＥ１０２の間でＩＭＳのシグナリングによるＳＤＰ(Session Description Protocol)のオファー/アンサーが送受信される事により、通話の際に使用されるコーデック等が折衝される。図５にセッションセットアップの際のＩＭＳシグナリング送受信の一例を示す。ＩＭＳシグナリングは各ＵＥが契約している網（自網）のＩＭＳノード（図１のＣＳＣＦやＳＣＣ  ＡＳ）を介して送受信される（図５では不図示）。また図６に、ＳＤＰオファー/アンサーの一例を示す。図６の例では、後述のＡＭＲとＡＭＲ−ＷＢがオファーされ、ＡＭＲがアンサーにより選択される例である。ＩＭＳシグナリングの送受信が完了すると、ＵＥ１００とＵＥ１０２の間でＶｏＬＴＥ通話が開始される。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。【０００７】
図１の実線で示されたＰａｔｈ  Ａ、Ｐａｔｈ  Ｂ及びＰａｔｈ  Ｃは、通話データが通る経路を示す。また、図１の破線で示された２００、２０２、２０４及び２０６は、ＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。【０００８】
図２は、ＳＲＶＣＣハンドオーバ処理の動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ−ＵＴＲＡＮ）にそれぞれ接続されており、ＵＥ１００とＵＥ１０２との間の通話データはＰａｔｈ  Ａを通って送受信されている。ＵＥ１００がｅ−ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ−ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ１１０経由でＲＮＣ／ｎｏｄｅＢとの間でコア網のシグナリング（以下、シグナリング）をやり取りする（図１に示すシグナリング２００。図２に示すステップ（以下、「ＳＴ」という）２００）。ＳＴ２００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷ１１０との間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ−ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令が出される。【０００９】
ＳＴ２００の処理と同時に、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００の自網のＣＳＣＦ／ＳＣＣ  ＡＳ経由でＵＥ１０２とＩＭＳのシグナリング（以下ＩＭＳシグナリング）をやり取りする（図１に示すシグナリング２０２。図２に示すＳＴ２０２）。これにより、ＵＥ１０２の通話データの送受信先を、ＵＥ１００からＭＳＣ／ＭＧＷ１１０に切り替えるよう命令が出され、Ｐａｔｈ  Ｂが確立される。【００１０】
ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷ１１０とシグナリングをやり取りする（図１に示すシグナリング２０４。図２に示すＳＴ２０４）。これにより、Ｐａｔｈ  Ｃが確立される。【００１１】
Ｐａｔｈ  Ｃ確立後、ＭＳＣ／ＭＧＷ１１０は、ＭＭＥ経由でＰ−ＧＷ／Ｓ−ＧＷとシグナリングをやり取りする（図１に示すシグナリング２０６。図２に示すＳＴ２０６）。これにより、Ｐａｔｈ  Ａは削除される。【００１２】
以上、ＳＲＶＣＣハンドオーバの動作について説明した。【００１３】
上述のように、ＩＭＳシグナリングは自網での処理が行われる。このためＵＥが海外のネットワークなどにローミングしている状態でＳＲＶＣＣを行った場合、ローミング先でのハンドオーバにも関わらず、自網までＩＭＳシグナリングが送られてしまうため、距離などに起因した遅延が発生することがあった。このＳＲＶＣＣの課題を改良し、データ経路切替にかかる時間を短縮する方式として、非特許文献４に記載の、ＡＴＣＦ（Access Transfer Control Function）エンハンスメントを用いたＳＲＶＣＣ方式（ｅＳＲＶＣＣ：enhanced-SRVCC）がある。このｅＳＲＶＣＣの動作の一例について、以下、図３及び図４を用いて説明する。【００１４】
図３は、ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワーク構成の一部を示す。図３に示す移動通信ネットワークは、図１と同様、ｅ−ＵＴＲＡＮ、ｅ−ｎｏｄｅＢ、ＰＳ網、ＣＳ網、ＣＳ網の基地局サブシステム、及びＩＭＳから構成される。ここでＩＭＳには、ＣＳＣＦ及びＳＣＣ  ＡＳの他、ＡＴＣＦ（Access Transfer Control Function）及びＡＴＧＷ（Access Transfer GateWay）が存在する。なお、図３及び図４では、ＡＴＣＦとＡＴＧＷとを一つのノード（ＡＴＣＦ／ＡＴＧＷ３２０）として表しているが、これらは別々のノードとして表してもよい。【００１５】
図３において、ＵＥ１００及びＵＥ１０２は、最初にＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。つまり、ＵＥ１００とＵＥ１０２とでＶｏＬＴＥ通話が行われているとする。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。【００１６】
図３の実線で示されたＰａｔｈ  Ａ、Ｐａｔｈ  Ｂ、Ｐａｔｈ  Ｃ及びＰａｔｈ  Ｄは、通話データが通る経路を示す。また、図３の破線で示された３００、３０２、３０４及び３０６は、ｅＳＲＶＣＣハンドオーバ処理におけるシグナリング及びＩＭＳシグナリングが通る経路を示す。【００１７】
図４は、ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ−ＵＴＲＡＮ）にそれぞれ接続されている。ｅＳＲＶＣＣハンドオーバを実現するシステムでは、ＡＴＣＦ／ＡＴＧＷ３２０において、ＡＴＣＦはＩＭＳシグナリングをアンカー（anchor）し、ＡＴＧＷは通話データをアンカーする。つまり、ＵＥ１００とＵＥ１０２との間の通話開始時において、通話開始のＩＭＳシグナリングはＵＥが接続している網（在圏網）のＡＴＣＦで中継され、ＡＴＣＦがＡＴＧＷでの通話データのアンカーが必要と判断した場合、通話データのアンカーポイントとしてＵＥの在圏網のＡＴＧＷが割り当てられる。これにより、ＵＥ１００とＵＥ１０２との間の通話データは、Ｐａｔｈ  Ａ及びＰａｔｈ  Ｂを通って送受信される。【００１８】
ＵＥ１００がｅ−ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ−ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ１１０経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図３に示すシグナリング３００。図４に示すＳＴ３００）。ＳＴ３００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷ１１０との間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ−ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令が出される。【００１９】
ＳＴ３００の処理と同時に、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００の在圏網のＡＴＣＦにＩＭＳシグナリングを送る。これによりＡＴＣＦからＵＥ１００の在圏網のＡＴＧＷに経路切替の指示が出され、ＡＴＧＷの通話データ送受信先がＵＥ１００からＭＳＣ／ＭＧＷ１１０に切り替わる（図３に示すシグナリング３０２。図４に示すＳＴ３０２）。すなわち、Ｐａｔｈ  Ｃが確立される。また、ＡＴＧＷへの経路切替処理が完了すると、ＡＴＣＦは、ＳＣＣ−ＡＳに通知シグナリング（ＩＭＳシグナリング）を送信する（図３に示すシグナリング３０２。図４に示すＳＴ３０２）。【００２０】
ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷ１１０とシグナリングをやり取りする（図３に示すシグナリング３０４。図４に示すＳＴ３０４）。これにより、Ｐａｔｈ  Ｄが確立される。【００２１】
Ｐａｔｈ  Ｄ確立後、ＭＳＣ／ＭＧＷ１１０は、ＭＭＥ経由でＰ−ＧＷ／Ｓ−ＧＷとシグナリングをやり取りする（図３に示すシグナリング３０６。図４に示すＳＴ３０６）。これにより、Ｐａｔｈ  Ｂは削除される。【００２２】
図１のＳＲＶＣＣの構成では、例えば日本の携帯電話会社で回線契約しているＵＥ１００がヨーロッパの携帯電話網にローミングした状態で、同じくヨーロッパの同一国に在圏するＵＥ１０２との通話中にＣＳ網にハンドオーバした場合でも、ＭＧＷとＵＥ１０２とのＩＭＳシグナリングは日本を経由して送受信されるため、ＭＧＷとＵＥ１０２との間のシグナリングに時間がかかるという問題があった。しかし、図３のｅＳＲＶＣＣであれば、ＭＧＷとＡＴＣＦは通常同一国内でしかも近接して設けられている。さらに、シグナリングはＭＧＷとＡＴＣＦ間で行われるだけであり、ＵＥ１０２との間のシグナリングは不要である。その結果、データ経路切替にかかる時間を短縮することができる。【００２３】
以上、ｅＳＲＶＣＣハンドオーバの動作について説明した。【００２４】
ＣＳ網で利用される音声コーデックとして、狭帯域（ＮＢ：Narrowband）コーデックであるＡＭＲ(Adaptive Multi-Rate)コーデックや，広帯域（ＷＢ：Wideband）コーデックであるＡＭＲ−ＷＢ（Adaptive Multi-Rate Wideband）コーデックがある。ＡＭＲやＡＭＲ−ＷＢは、パケット交換方式で利用可能であるため、ＰＳ網（ＶｏＬＴＥ）での利用も考えられる。【００２５】
また、例えば、非特許文献４に記載のＥＶＳ（Enhanced Voice Service）のように、ＰＳ網（ＶｏＬＴＥ）で利用されるコーデックもある。【００２６】
なお、上記先行技術文献において、狭帯域（ＮＢ：Narrowband）コーデックとは、８ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。なお、狭帯域コーデックでは、一般的に３００Ｈｚ〜３．４ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０〜４ｋＨｚの範囲内であればよい。また、広帯域コーデックとは、１６ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。なお、広帯域コーデックでは、一般的に５０Ｈｚ〜７ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０〜８ｋＨｚの範囲内であればよい。また、超広帯域（ＳＷＢ：Super Wideband）コーデックとは、３２ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。超広帯域コーデックでは、一般的に５０Ｈｚ〜１４ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０〜１６ｋＨｚの範囲内であればこれに限定されない。
【先行技術文献】
【特許文献】
【００２７】
【特許文献１】国際公開第２０１２／０１７９５１号
【特許文献２】国際公開第２０１３／０８０４７１号
【非特許文献】
【００２８】
【非特許文献１】3GPP TS23.216 v12.6.0 “Single Radio Voice Call Continuity (SRVCC)”
【非特許文献２】3GPP TS23.228 v12.0.0 “IP Multimedia Subsystem (IMS); Stage2”
【非特許文献３】3GPP TS23.237 v12.6.0 “IP Multimedia Subsystem (IMS) Service Continuity”
【非特許文献４】3GPP TS22.813 v10.0.0 “Study of Use Cases and Requirements for Enhanced Voice Codecs for the Evolved Packet System (EPS)”
【発明の概要】
【００２９】
図１又は図３において、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバした際、ＰＳ網で使用していたコーデックがＣＳ網でサポートされていない場合には、ＵＥ１００で使用されるコーデックは、ＣＳ網でサポートされているコーデックに変更される。ＵＥ１００のコーデックに変更が生じた場合、ＵＥ１００とＵＥ１０２との通話継続を可能にするためには、次の２つの方法が考えられる。１つ目の方法は、ＭＳＣ／ＭＧＷ又はＡＴＣＦ／ＡＴＧＷにおいてトランスコーディングを行う方法である。２つ目の方法は、ＵＥ１０２で使用されるコーデックをＵＥ１００の変更後のコーデックと同じものに変更する方法である。
【００３０】
前者のトランスコーディングを行う方法では、ＭＳＣ／ＭＧＷ又はＡＴＣＦ／ＡＴＧＷがトランスコーディングをサポートしている必要がある。またトランスコーディングによる通話品質の劣化が生じてしまう。
【００３１】
一方、後者のコーデックを変更する方法では、ＵＥ１０２のコーデックを変更するため、ＩＭＳシグナリングによるコーデック再折衝が必要である。しかし、ｅＳＲＶＣＣハンドオーバでは、ＵＥ１００のハンドオーバの際の経路切替のためのＩＭＳシグナリングがＡＴＣＦで終端するため、ＵＥ１０２のコーデックを変更するためのＩＭＳシグナリングを送ることができない。
【００３２】
特許文献１には、ネットワーク側でｅＳＲＶＣＣ方式が用いられている場合でも、ＵＥがＣＳにハンドオーバする機能があるか否か、すなわちＳＲＶＣＣに対応しているか否かを検出し、対応していない場合には通信経路をＡＴＧＷでアンカーさせない方法が開示されている。また非特許文献４にはｅＳＲＶＣＣ方式であっても（ＩＭＳシグナリングがＡＴＣＦを経由する場合であっても）、通常のＳＲＶＣＣのように扱う方法、即ち通信経路をＡＴＧＷでアンカーさせず、また一方のＵＥがＣＳ網にハンドオーバした際には、ＭＧＷからＡＴＣＦを経由して、もう一方のＵＥとの間でＩＭＳシグナリングが送受信される方法が記述されている（ATCF without media anchored in ATGW）。しかしながら、特許文献１に開示の方法ではＵＥが使用するコーデックにかかわらずＵＥがＳＲＶＣＣをサポートしているか否かにより、ＩＭＳシグナリングがもう一方のＵＥに送られるか否かが決定される。また非特許文献４には、どのような場合にｅＳＲＶＣＣであっても通常のＳＲＶＣＣのように扱われるかは記載されていない。
【００３３】
本開示は、通信中の端末の一方がコーデックの変更を伴うハンドオーバを行った場合に、もう一方の端末のコーデックの変更を可能にし、通信を継続することができるネットワークノード及び当該ネットワークノードで実行するシグナリング処理方法を提供する。
【００３４】
セッションセットアップの際、ＩＭＳシグナリングをアンカーするＡＴＣＦがＳＤＰオファー/アンサーの内容を確認し、通話開始時に使われるコーデック、ＵＥがハンドオーバしうる先のＣＳで使われるコーデックを比較し、ＡＴＧＷにトランスコーディング機能が無ければ、又はＡＴＧＷでのトランスコーディングを希望しないのであれば、通信経路をＡＴＧＷでアンカーさせずに、通常のＳＲＶＣＣのように扱う方法を選択し、ＵＥのＣＳへのハンドオーバが生じた際には、もう片方のＵＥとの間で再度ＩＭＳシグナリングによるＳＤＰオファー/アンサーの送受信により、コーデックの再折衝を行う。
【００３５】
または、通常のｅＳＲＶＣＣであってＡＴＧＷでアンカーさせる場合であっても、ＵＥがＣＳにハンドオーバしコーデックが変更になった場合、ＡＴＧＷにトランスコーディング機能が無ければ、又はＡＴＧＷでのトランスコーディングを希望しないのであればもう片方のＵＥとの間で再度ＩＭＳシグナリングによるＳＤＰオファー/アンサーの送受信により、コーデックの再折衝を行う。
【００３６】
本開示にかかるネットワークノードの一態様は、ｅＳＲＶＣＣ（enhanced Single Radio Voice Call Continuity）に用いる少なくともＡＴＣＦ機能（Access Transfer Control Function）を有するネットワークノードであって、ＩＭＳ（IP Multimedia Subsystem）シグナリングに含まれるＳＤＰ（Session Description Protocol）オファーまたはＳＤＰアンサーを受信する受信部と、前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれるコーデックの情報を取得するＳＤＰ解析部と、データ格納部と、判断部とを有する。データ格納部は、ＡＴＧＷ（Access Transfer Gateway）または近隣（Neighboring）のＭＧＷ（Media Gateway）でサポートしているコーデックの情報、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているトランスコーディングの情報、および近隣のＣＳ（Circuit Switching）網がサポートしているコーデックの情報の少なくとも一つを保持する。判断部は、ＳＤＰ解析部で取得した前記コーデックの情報、および前記データ格納部から読み出した情報を用いて、前記ＡＴＣＦから通信端末へのコーデック再折衝のためのＳＤＰオファーの送信を可能にするか否かを判断する。
【００３７】
通信中の端末の一方がコーデックの変更を伴うハンドオーバを行った場合に、もう一方の端末のコーデックの変更を可能にし、通信を継続することができるネットワークノード及び当該ネットワークノードで実行するシグナリング処理方法を実現することができる。
【図面の簡単な説明】
【００３８】
【図１】ＳＲＶＣＣにおける移動通信ネットワークの構成図
【図２】ＳＲＶＣＣにおけるハンドオーバ動作の説明図
【図３】ｅＳＲＶＣＣにおける移動通信ネットワークの構成図
【図４】ｅＳＲＶＣＣにおけるハンドオーバ動作の説明図
【図５】セッションアップ時におけるＩＭＳシグナリング送受信を示す説明図
【図６】セッションアップ時に交わされるＳＤＰオファー／アンサーの説明図
【図７】本開示のネットワークノードの構成図
【図８】本開示の実施形態１におけるセッションセットアップ動作の説明図
【図９】本開示の実施形態１におけるネットワークノードの動作を示す説明図
【図１０】本開示の実施形態２におけるセッションセットアップ動作の説明図
【図１１】本開示の実施形態２におけるネットワークノードの動作を示す説明図
【図１２】本開示の実施形態３におけるセッションセットアップ動作およびハンドオーバ動作の説明図
【図１３】本開示の実施形態３におけるネットワークノードの動作を示す説明図
【発明を実施するための形態】
【００３９】
本開示の各実施の形態について、図面を参照して詳細に説明する。なお、本開示の各実施の形態において、ＵＥはＳＲＶＣＣに対応しており、ＡＴＣＦ／ＡＴＧＷがその情報を取得している事を前提とする。ＵＥがＳＲＶＣＣに対応しているか否かをＡＴＣＦ／ＡＴＧＷが取得する方法としては、特許文献１で開示されているような手段が用いられてもよい。
【００４０】
（実施形態１）
図７〜図９を用いて実施の形態１を説明する。図７は本実施の形態のＡＴＣＦ/ＡＴＧＷ３２０のうち、特にＡＴＣＦ部分を構成するブロック図である。
【００４１】
受信部７００ではＩＭＳシグナリングなどを受信する。また送信部７０２はＩＭＳシグナリングなどを送信する。
【００４２】
ここで、ＩＭＳシグナリングは、通信端末であるＵＥがセッションセットアップの際に送受信するＩＭＳシグナリングのほか、ＵＥのハンドオーバに伴い送受信するＩＭＳシグナリングも含む。
【００４３】
ＳＤＰ解析部７０４は、ＩＭＳシグナリングに含まれるＳＤＰオファーやＳＤＰアンサーの中身を解析する。例えばＳＤＰオファーやＳＤＰアンサーを解析し、通話に使用される音声コーデックの情報を取得する。
【００４４】
データ格納部７０６は、ＡＴＣＦ／ＡＴＧＷ３２０自体の能力(Capability)や、近隣ＭＧＷの能力が格納されている。例えばＡＴＣＦ／ＡＴＧＷ３２０やＭＧＷがサポートしているコーデックの情報や、近隣のＣＳ網がサポートしているコーデックの情報、ＡＴＣＦ／ＡＴＧＷ３２０やＭＧＷがサポートしているトランスコーディングの情報（トランスコードできるコーデックの組み合わせ情報）などが格納されている。
【００４５】
なお、近隣ＭＧＷや近隣ＣＳ網の情報はＡＴＣＦ／ＡＴＧＷ３２０とＭＧＷが直接、又は他のネットワークノードを介してシグナリングメッセージを交換するなどの手段を用いて情報取得しても良いし、あらかじめ手動でデータが格納されていてもよい。
【００４６】
ポリシー格納部７０８には、サービス提供に関するポリシーが格納されている。例えば通信を行う２つのＵＥが異なるコーデックを使用する事を許し、ＡＴＣＦ／ＡＴＧＷ３２０やＭＧＷでトランスコーディングを行うか、又は通信行う２つのＵＥが使用するコーデックを統一し、トランスコーディングは行わない、などのポリシーが格納されている。
【００４７】
判断部７１０は、ＳＤＰ解析部７０４の解析結果、データ格納部７０６に格納されているデータ、ポリシー格納部７０８に格納されているポリシーを用いて、ＡＴＣＦからＵＥへのコーデック再折衝のためのＳＤＰオファーの送信を可能にするか否かを判断する。具体的には、ＡＴＧＷで通信をアンカーするか、又はＡＴＧＷでアンカーせず、ＵＥ１０２との間でＩＭＳシグナリングを送受信する事によるコーデックの変更を可能にするか否かの判断を行う。
【００４８】
図８は、本開示の実施の形態１におけるセッションセットアップの一例を示すシーケンスチャートである。ＵＥ１００から送信された、ＳＤＰオファー付きInviteメッセージ（ＩＭＳシグナリング）は、他のネットワークノード（不図示）を経由してＡＴＣＦ/ＡＴＧＷ３２０（正確にはＡＴＣＦのみ）に送信される（８０１）。
【００４９】
ＡＴＣＦでは非特許文献４に記載の通り、ＡＴＧＷの選択とリソース割り当てを行う（８０２）。
【００５０】
次にＡＴＣＦ／ＡＴＧＷ３２０は他のネットワークノード（不図示）を介してＵＥ１０２にＳＤＰオファー付きInviteメッセージを送信する（８０３）。この際、ＵＥ１０２の通信相手としてＡＴＧＷが指定されている。
【００５１】
次にＵＥ１０２はＳＤＰアンサーをＩＭＳメッセージと共に、他のネットワークノード（不図示）を経由し、ＡＴＣＦ／ＡＴＧＷ３２０に送信する（８０４）。ＳＤＰアンサーを受け取ったＡＴＣＦ／ＡＴＧＷ３２０の判断部７１０は、ＳＤＰアンサーの中身、データ格納部７０６に格納されているデータ、ポリシー格納部７０８に格納されているポリシーを用いて、選択したＡＴＧＷで通信をアンカーさせるか否かの判断を行う（８０５）。判断部７１０の判断方法の一例を図９に示す。
【００５２】
判断部７１０はまずＳＤＰアンサーで選択されているコーデックが何であるかを確認する（ＳＴ９０１）。
【００５３】
次にＳＤＰアンサーで選択されているコーデックが、ＵＥがＣＳ網にハンドオーバした際に使われうるコーデック（近隣のＣＳ網でサポートされているコーデック）か否かを確認する。ＣＳ網で使われうるコーデックの場合は、ＡＴＧＷで通信をアンカーするか否かの従来の判断基準（特許文献１に記載の判断基準等）を満たす場合には、ＡＴＧＷで通信をアンカーし、満たさない場合はＡＴＧＷで通信をアンカーしない事を選択する。（不図示）。
【００５４】
ＳＤＰアンサーで選択されているコーデックが、ＵＥがＣＳ網にハンドオーバした際に使われうるコーデックで無い場合、そのコーデックがＡＴＧＷや、ＵＥがハンドオーバした際に使われうる近隣のＭＧＷでサポートしているコーデックか否かを確認する（ＳＴ９０２）。サポートしていない場合は、トランスコーディング等そのコーデックに関する処理を行う事が不可能であるため、ＡＴＧＷで通信をアンカーしない事、すなわちＵＥがＣＳ網にハンドオーバしてコーデックが変更になった場合には、ＵＥ１０２との間でコーデック再折衝のためのＩＭＳシグナリングを送受信し、コーデックＵＥ１００との間で統一できるようにする事を選択する（ＳＴ９０３）。またＡＴＧＷや近隣のＭＧＷでサポートしているコーデックの場合、ＵＥがハンドオーバし得る近隣のＣＳ網でサポートされているコーデックが、選択されたコーデックとの互換性があるか否かを確認し、互換性が無い場合には、トランスコーディングをサポートしているか否かを確認する（ＳＴ９０４）。
【００５５】
トランスコーディングをサポートしていない場合にはＡＴＧＷで通信をアンカーしない事を選択する（ＳＴ９０３）。またトランスコーディングをサポートしていた場合でも、トランスコーディングを許すか否か（トランスコーディングを使用するか否か）ポリシーの確認を行い（ＳＴ９０５）、トランスコーディングを許さないポリシーであった場合はトランスコーディングを行わない場合に該当するとして、ＡＴＧＷで通信をアンカーしない事を選択する（ＳＴ９０３）。すなわちＵＥがＣＳ網にハンドオーバしてコーデックが変更になった場合には、ＵＥ１０２との間でコーデック再折衝のためのＩＭＳシグナリングを送受信し、コーデックＵＥ１００との間で統一できるようにする事を選択する。
【００５６】
また、トランスコーディングをサポートしており、トランスコーディングを許すポリシーであった場合でも、ＡＴＧＷで通信をアンカーするための他の条件が全て整っているかを判断する（ＳＴ９０６）。例えば選択されたコーデックが、近隣ＣＳがサポートしているコーデックとの互換性がある場合に、特許文献２に記載のようにＩＭＳシグナリングをＵＥ１０２との間で送受信する事なしに、（ＲＴＰペイロードフォーマット切替のためのセッション再折衝無しで）互換モードへの切替機能を持つコーデックかを確認する。機能を持たない、又は持っていても使用するポリシーが無い場合には、ＡＴＧＷで通信をアンカーしない事を選択する（ＳＴ９０３）。すなわちＵＥがＣＳ網にハンドオーバしてコーデックが変更になった場合には、ＵＥ１０２との間でコーデック再折衝のためのＩＭＳシグナリングを送受信し、コーデックＵＥ１００との間で統一できるようにする事を選択する。ＩＭＳシグナリングをＵＥ１０２との間で送受信する事なしに、トランスコーディングなしのオペレーションを行う機能を持つコーデックで、かつその機能を使用するポリシーがある場合で、かつ、ＡＴＧＷで通信をアンカーするための他の条件が全て整っている場合には、ＵＥがＣＳ網にハンドオーバしてコーデックが変更になった場合でも、ＵＥ１０２との間でコーデック再折衝のためのＩＭＳシグナリングを送受信し、コーデックＵＥ１００との間で統一する必要は無いと判断し、ＡＴＧＷで通信をアンカーさせる（ＳＴ９０７）。
【００５７】
ＡＴＧＷで通信をアンカーさせる事が判断された場合（ＳＴ９０７）、非特許文献４に記載の通り、ＵＥ１００、及びＵＥ１０２の通信先が選択されたＡＴＧＷとなるようＩＭＳシグナリングが送受信される。
【００５８】
一方ＡＴＧＷで通信をアンカーさせない事が判断された場合（ＳＴ９０３）、図８のようにＡＴＣＦ／ＡＴＧＷ３２０は再びＵＥ１０２にＩＭＳメッセージを送信し（８０６）、ＵＥ１０２の通信先はＡＴＧＷではなく、ＵＥ１００に変更するよう指示を送る。またＵＥ１００へのＩＭＳシグナリングには、選択されたコーデック（ＳＤＰアンサー）の他、ＵＥ１００の通信相手としてＵＥ１０２が記される（８０７）。またこの時、ＡＴＧＷに割り当てたリソースは解放される。
【００５９】
このように、本実施の形態のセッションセットアップの後、ＵＥ１００がＣＳ網にハンドオーバし、使用するコーデックが変更になった際、変更後のコーデックが変更前のコーデックと互換性が無い場合でＭＧＷやＡＴＧＷでトランスコーディングをサポート又は許可していない場合や、また互換性が有る場合でＩＭＳシグナリングをＵＥ１０２との間で送受信する事なしに（ＲＴＰペイロードフォーマットの切替をセッション再折衝無しで）互換モードへの切替をサポート又は許可していない場合でも、ＡＴＣＦ／ＡＴＧＷとＵＥ１０２との間でＩＭＳシグナリングを送受信し、コーデックの再折衝を行う事により、通信の継続が可能になる。
【００６０】
（実施形態２）
図７及び図１０〜１１を用いて実施の形態２を説明する。図７は本実施の形態のＡＴＣＦ/ＡＴＧＷ３２０を構成するブロック図であり、実施の形態１と同様である。図１０は、本開示の実施の形態２におけるセッションセットアップの一例を示すシーケンスチャートである。
【００６１】
ＵＥ１００から送信された、ＳＤＰオファー付きInviteメッセージ（ＩＭＳシグナリング）は、他のネットワークノード（不図示）を経由してＡＴＣＦ／ＡＴＧＷ３２０（正確にはＡＴＣＦのみ）に送信される（１００１）。ここで、ＡＴＣＦ／ＡＴＧＷ３２０は、ＳＤＰオファーからＡＴＧＷで通信をアンカーさせるか否かを判断するか否かを決定する（１００２）。例えばＡＴＣＦ／ＡＴＧＷの判断部７１０において、ＳＤＰオファーの内容からＡＴＧＷで通信をアンカーさせるか否かを判断するポリシーが、ポリシー格納部７０８にあるかを確認し、判断する。ＳＤＰオファーの内容からＡＴＧＷで通信をアンカーさせるか否かの判断を行わない場合、実施の形態１のようにＳＤＰアンサーから判断を行う。
【００６２】
図１１は本実施の形態のＡＴＣＦ／ＡＴＧＷ３２０の判断部７１０の判断方法の一例である。すなわちＳＤＰオファーで判断する場合（ＳＴ１１０１）、ＳＤＰオファーのコーデックをＳＤＰ解析部７０４で解析する（ＳＴ１１０２）。この時解析されたコーデックの中に、ＡＴＣＦ／ＡＴＧＷ３２０や、近隣のＭＧＷでサポートされないコーデックが含まれていた場合（ＳＴ１１０３）、ＳＤＰオファーからそのコーデックを削除しサポートされているコーデックのみにするか（ＵＥ１００が近隣ＣＳ網にハンドオーバした場合にも、ＵＥ１０２とコーデックを再折衝する事なしに通信が継続できるコーデックのみにするか）どうかをポリシー格納部７０８に問い合わせる（ＳＴ１１０４）。削除する場合にはＡＴＧＷで通信をアンカーすると判断する（ＳＴ１１０５）。すなわち通信をアンカーするＡＴＧＷを選択し、リソースを割り当てる。また該当コーデックを削除したＳＤＰをＳＤＰ解析部７０４などで生成し、ＡＴＧＷを通信相手としてＩＭＳシグナリングによりＵＥ１０２に通知する。また、ＵＥ１０２からＳＤＰアンサーを受け取ると、ＵＥ１００に対しＩＭＳシグナリングにより、通信相手をＡＴＧＷとしてＳＤＰアンサーを送る。反対にＳＤＰオファーから該当コーデックを削除しない場合には、該当コーデックが選択された場合、トランスコーディング等そのコーデックに関する処理を行う事が不可能であるため、ＡＴＧＷで通信をアンカーしない事と判断する（ＳＴ１１０６）。すなわちＡＴＧＷの選択やリソース割り当ては行わず、ＵＥ１００を通信相手としてＵＥ１０２にＩＭＳシグナリングを送る。またＵＥ１０２からＳＤＰアンサーを受け取ると、ＵＥ１０２を通信相手としてＩＭＳシグナリングをＵＥ１００へ送る。
【００６３】
また、ＳＤＰオファーから該当コーデックを削除する場合であっても、すぐにＡＴＧＷで通信をアンカーすると判断せず、実施の形態１に記載の判断基準（トランスコーディングのポリシー等）を適応させ、ＡＴＧＷで通信をアンカーするか否かを判断してもよい。
【００６４】
また、ＵＥ１００から送られたＳＤＰオファーの内容から、全てのコーデックがＡＴＣＦ／ＡＴＧＷ３２０や近隣ＭＧＷでサポートされているが、近隣ＣＳ網でサポートされていないコーデックが含まれている場合、実施の形態１と同様の方法で、ＡＴＧＷで通信をアンカーするか否かを判断する（ＳＴ１１０７、ＳＴ１１０８、ＳＴ１１０９）。
【００６５】
本実施の形態では、実施の形態１のようにＳＤＰアンサーを受けてからＡＴＧＷで通信をアンカーするか否かを判断し、アンカーしない場合には、ＵＥ１０２の通信相手をＡＴＧＷからＵＥ１００に変更する手続きが省略できる。そのため実施の形態１に比べセッションセットアップにかかる時間を短縮する事ができる。
【００６６】
（実施形態３）
本実施の形態では、セッションセットアップ時にＡＴＧＷで通信をアンカーする場合においても、ＵＥ１００のＣＳ網へのハンドオーバなどでＵＥ１０２とのコーデックの再折衝が必要になった場合には、ＡＴＣＦ／ＡＴＧＷ３２０からＵＥ１０２にＩＭＳシグナリングを送る機能をＡＴＣＦ／ＡＴＧＷ３２０に持たせる。
【００６７】
図７及び図１２〜１３を用いて、本実施の形態を説明する。図７は本実施の形態のＡＴＣＦ／ＡＴＧＷ３２０の構成を示すブロック図であり、実施の形態１と同様である。
【００６８】
図１２は、本開示の実施の形態３におけるセッションセットアップ及び、ＵＥ１００がＣＳ網にハンドオーバを行った際の一例を示すシーケンスチャートである。ＵＥ１００から送信された、ＳＤＰオファー付きInviteメッセージ（ＩＭＳシグナリング）は、他のネットワークノード（不図示）を経由してＡＴＣＦ/ＡＴＧＷ３２０（正確にはＡＴＣＦのみ）に送信される（１２０１）。ＡＴＣＦでは非特許文献４に記載の通り、ＡＴＧＷの選択とリソース割り当てを行う（１２０２）。
【００６９】
次にＡＴＣＦ／ＡＴＧＷ３２０は他のネットワークノード（不図示）を介してＵＥ１０２にＳＤＰオファー付きInviteメッセージを送信する（１２０３）。この際、ＵＥ１０２の通信相手としてＡＴＧＷが指定されている。
【００７０】
次にＵＥ１０２はＳＤＰアンサーをＩＭＳメッセージと共に、他のネットワークノード（不図示）を経由し、ＡＴＣＦ／ＡＴＧＷ３２０に送信する（１２０４）。ＳＤＰアンサーを受け取ったＡＴＣＦ／ＡＴＧＷ３２０は、非特許文献４に記載の通り、他のネットワークノード（不図示）を介して、ＵＥ１００にＳＤＰアンサーを送信する（１２０５）。この際、ＵＥ１００の通信相手としてＡＴＧＷが指定されている。即ちＡＴＣＦ／ＡＴＧＷ３２０はＳＤＰオファー・アンサーを解析する事なく、ＡＴＧＷで通信をアンカーさせる。
【００７１】
次に、ＵＥ１００がＣＳ網へハンドオーバし、非特許文献１に記載の方法で、ＣＳ網を通じてＭＳＣ／ＭＧＷまでの通信経路が確立されたとする（１２０６）。ＭＳＣ／ＭＧＷは非特許文献４に記載の通り、ＡＴＣＦ／ＡＴＧＷ３２０にＳＤＰオファー付きInviteメッセージを送信する（１２０７）。
【００７２】
このメッセージを受け取ったＡＴＣＦ／ＡＴＧＷ３２０の判断部７１０は、ＳＤＰオファーの中身、データ格納部７０６に格納されているデータ、ポリシー格納部７０８に格納されているポリシーを用いて、ＡＴＣＦからＵＥへのコーデック再折衝のためのＳＤＰオファーの送信を可能にするか否かを判断する。具体的には、ＵＥ１０２にコーデックを再折衝するＩＭＳシグナリング（ＳＤＰオファー付きInviteメッセージ）を送るか否かの判断を行う（１２０８）。判断部７１０の判断方法の一例を図１３に示す。
【００７３】
判断部７１０はまずＳＤＰオファーで選択されているコーデックの中にＵＥ１００がハンドオーバ前に使用していたコーデックが含まれるか否かを確認する（ＳＴ１３０１、ＳＴ１３０２）。含まれていた場合にはＵＥ１００にＩＭＳシグナリング（ＳＤＰオファー）は送らず、コーデックの変更無しに非特許文献４に記載の方法で通信を継続する。
【００７４】
ＳＤＰオファーで選択されているコーデックの中にＵＥ１００がハンドオーバ前に使用していたコーデックが含まれていない場合、実施形態１と同様の方法でＵＥ１０２との間でＩＭＳシグナリングを送受信して、再度ＳＤＰオファー・アンサーをやり取りする事によるコーデックの統一を行なうか否かを判断する。すなわちＵＥ１００がハンドオーバ前に使用していたコーデックが、ＡＴＧＷでサポートしているか否かを確認し（ＳＴ１３０３）、サポートしていない場合は、トランスコーディング等そのコーデックに関する処理を行う事が不可能であるため、ＵＥ１０２にＩＭＳシグナリングを送りコーデックの再折衝を選択する（ＳＴ１３０４）。またＵＥ１００がハンドオーバ前に使用していたコーデックをサポートしていた場合、ＳＤＰオファーのコーデックの中に、ＵＥ１００がハンドオーバ前に使用していたコーデックとの互換性があるものが存在するか否かを確認し、互換性が無い場合には、ＡＴＣＦ／ＡＴＧＷにおいてトランスコーディングをサポートしているか否かを確認する（ＳＴ１３０５）。
【００７５】
トランスコーディングをサポートしていない場合には、ＵＥ１０２にＩＭＳシグナリングを送り、コーデック再折衝をする事を選択する（ＳＴ１３０４）。またトランスコーディングをサポートしていた場合でも、トランスコーディングを許すか否かポリシーの確認を行う（ＳＴ１３０６）。トランスコーディングを許さないポリシーであった場合は、ＵＥ１０２にＩＭＳシグナリングを送り、コーデック再折衝をする事を選択する（ＳＴ１３０４）。また、トランスコーディングを許すポリシーであった場合でも、ＵＥ１０２にＩＭＳシグナリングを送り、コーデック再折衝をする必要の無い条件が整っているかを判断する（ＳＴ１３０７）。例えば、ＳＤＰオファーの中にＵＥ１００がハンドオーバ前に使っていたコーデックとの互換性があるものが含まれる場合でも、特許文献２に記載のようにＩＭＳシグナリングをＵＥ１０２との間で送受信する事なしに、（ＲＴＰペイロードフォーマット切替のためのセッション再折衝無しで）互換モードへの切替機能を持つコーデックかを確認する。機能を持たない、又は持っていても使用するポリシーが無い場合には、ＵＥ１０２にＩＭＳシグナリングを送る事を選択する（ＳＴ１３０４）。コーデック再折衝をする必要の無い条件が全て整っている場合、ＡＴＣＦ／ＡＴＧＷ３２０はＵＥ１０２にはＩＭＳシグナリングを送らず（ＳＴ１３０８）、ＳＤＰオファーの中から適当なコーデックを選び、ＳＤＰアンサーをＭＳＣ／ＭＧＷに返すと共に、ＡＴＧＷの通信先をＵＥ１００からＭＧＷに変更する。
【００７６】
本実施の形態により、非特許文献４に記載のセッションセットアップ方法を変更する事なく、ＵＥ１００がＣＳ網にハンドオーバし、使用するコーデックが変更になった際、変更後のコーデックが変更前のコーデックと互換性が無い場合でＭＧＷやＡＴＧＷでトランスコーディングをサポートしていない場合や、また互換性が有る場合でもＲＴＰペイロードフォーマットのセッション再折衝無しによる切替をサポートしていない場合でも、ＡＴＣＦ／ＡＴＧＷとＵＥ１０２との間でＩＭＳシグナリングを送受信し、コーデックの再折衝を行う事により、通信の継続が可能になる。
【００７７】
以上、本開示の各実施の形態について説明した。
【００７８】
なお、上記各実施の形態では、ＡＴＣＦ／ＡＴＧＷ３２０、ＭＳＣ／ＭＧＷ１１０、ＳＣＣ  ＡＳ／ＣＳＣＦをそれぞれ一つのノードとして説明した。しかし、本開示はこれに限られず、ＡＴＣＦ／ＡＴＧＷ３２０、ＭＳＣ／ＭＧＷ１１０、ＳＣＣ  ＡＳ／ＣＳＣＦが、互いにインタフェースによって接続される２つ以上の別々のノードで構成されてもよい。すなわち、ＡＴＣＦとＡＴＧＷとの間、ＭＳＣとＭＧＷとの間、及び、ＳＣＣ  ＡＳとＣＳＣＦとの間のそれぞれにおいて、上述した機能を複数のノードに分散させてもよい。また逆にＡＴＣＦ／ＡＴＧＷ３２０、ＭＳＣ／ＭＧＷ１１０の機能は一つのノードの中で実行されてもよい。
【００７９】
また、上記各実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、本開示はこれに限らず、音楽、音響、画像等のコーデックにも適用することができる。
【００８０】
なお、図８から図１３までの動作説明図は、専用に設計されたハードウェアでの動作（方法）を表すとともに、汎用のハードウェアに本開示の動作（方法）を実行するプログラムをインストールしてプロセッサで実行することにより実現する場合も含む。汎用のハードウェアたる電子計算機として、例えばパーソナルコンピュータ、スマートフォンなどの各種携帯情報端末、および携帯電話などが挙げられる。
【００８１】
また、専用に設計されたハードウェアは、携帯電話や固定電話などの完成品レベル（コンシューマエレクトロニクス）に限らず、システムボードや半導体素子など、半完成品や部品レベルをも含むものである。
【００８２】
また、本開示は、上記各実施の形態に限定されず、種々変更して実施することが可能である。
【産業上の利用可能性】
【００８３】
本開示のネットワークノードは、音声コーデックを扱う場合の他、音楽信号等に用いるコーデックや画像信号に用いるコーデックを扱う場合に有用である。
【符号の説明】
【００８４】
３２０  ＡＴＣＦ／ＡＴＧＷ
７００  受信部
７０４  ＳＤＰ解析部
７０６  データ格納部
７１０  判断部
【図１】
2015174018.tif 000003
【図２】
2015174018.tif 000004
【図３】
2015174018.tif 000005
【図４】
2015174018.tif 000006
【図５】
2015174018.tif 000007
【図６】
2015174018.tif 000008
【図７】
2015174018.tif 000009
【図８】
2015174018.tif 000010
【図９】
2015174018.tif 000011
【図１０】
2015174018.tif 000012
【図１１】
2015174018.tif 000013
【図１２】
2015174018.tif 000014
【図１３】
2015174018.tif 000015
【手続補正書】
【提出日】平成27年8月28日(2015.8.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ｅＳＲＶＣＣ（ｅｎｈａｎｃｅｄ  Ｓｉｎｇｌｅ  Ｒａｄｉｏ  Ｖｏｉｃｅ  Ｃａｌｌ  Ｃｏｎｔｉｎｕｉｔｙ）に用いるＡＴＣＦ（Ａｃｃｅｓｓ  Ｔｒａｎｓｆｅｒ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）を有するネットワークノードであって、
ＩＭＳ（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ）シグナリングに含まれるＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）オファーまたはＳＤＰアンサーを受信する受信部と、
前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれるコーデックの情報を取得するＳＤＰ解析部と、
ＡＴＧＷ（Ａｃｃｅｓｓ  Ｔｒａｎｓｆｅｒ  Ｇａｔｅｗａｙ）または近隣のＭＧＷ（Ｍｅｄｉａ  Ｇａｔｅｗａｙ）でサポートしているコーデックの情報、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているトランスコーディングの情報、および近隣のＣＳ（Ｃｉｒｃｕｉｔ  Ｓｗｉｔｃｈｉｎｇ）網がサポートしているコーデックの情報の少なくとも一つを保持するデータ格納部と、
前記ＳＤＰ解析部で取得した前記コーデックの情報、および前記データ格納部から読み出した情報を用いて、前記ＡＴＣＦから通信端末へコーデックを再折衝するためのＳＤＰオファーの送信を可能にするか否かを判断する判断部と、
を有するネットワークノード。
【請求項２】
前記判断部における、前記ＡＴＣＦから前記通信端末へコーデックを再折衝するための前記ＳＤＰオファーの送信を可能にするか否かの判断は、
前記ＡＴＧＷで通話データをアンカーするか否か、または、前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信するか否か、の判断である、
請求項１記載のネットワークノード。
【請求項３】
前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているコーデックと一致しない場合、
前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項２記載のネットワークノード。
【請求項４】
前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしている前記コーデックと一致しない場合において、
前記ＳＤＰオファーから前記コーデックを削除して送信する場合には、前記判断部は、前記ＡＴＧＷで通話データをアンカーすると判断し、
前記ＳＤＰオファーから前記コーデックを削除しないで送信する場合には、前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項３記載のネットワークノード。
【請求項５】
前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、
前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項２記載のネットワークノード。
【請求項６】
前記受信部で前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷでサポートしているコーデックと一致しない場合、前記判断部は、前記通信端末にコーデック再折衝のための前記ＳＤＰオファーを送信すると判断する、
請求項２記載のネットワークノード。
【請求項７】
前記受信部で前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記判断部は、前記通信端末にコーデック再折衝のための前記ＳＤＰオファーを送信すると判断する、
請求項２記載のネットワークノード。
【請求項８】
ｅＳＲＶＣＣ（ｅｎｈａｎｃｅｄ  Ｓｉｎｇｌｅ  Ｒａｄｉｏ  Ｖｏｉｃｅ  Ｃａｌｌ  Ｃｏｎｔｉｎｕｉｔｙ）に用いるＡＴＣＦ（Ａｃｃｅｓｓ  Ｔｒａｎｓｆｅｒ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）を有するネットワークノードにおけるシグナリング処理方法であって、
ＩＭＳ（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ）シグナリングに含まれるＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）オファーまたはＳＤＰアンサーを受信し、
前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれるコーデックの情報を取得し、
ＡＴＧＷ（Ａｃｃｅｓｓ  Ｔｒａｎｓｆｅｒ  Ｇａｔｅｗａｙ）または近隣のＭＧＷ（Ｍｅｄｉａ  Ｇａｔｅｗａｙ）でサポートしているコーデックの情報、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているトランスコーディングの情報、および近隣のＣＳ（Ｃｉｒｃｕｉｔ  Ｓｗｉｔｃｈｉｎｇ）網がサポートしているコーデックの情報の少なくとも一つを取得し、
前記取得した情報を用いて、前記ＡＴＣＦから通信端末へコーデックを再折衝するためのＳＤＰオファーの送信を可能にするか否かを判断する、
シグナリング処理方法。
【請求項９】
前記ＡＴＣＦから前記通信端末へコーデックを再折衝するための前記ＳＤＰオファーの送信を可能にするか否かの判断は、
前記ＡＴＧＷで通話データをアンカーするか否か、または、
前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信するか否か、の判断である、
請求項８記載のシグナリング方法。
【請求項１０】
セッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているコーデックと一致しない場合、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項９記載のシグナリング方法。
【請求項１１】
セッションセットアップの際に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしている前記コーデックと一致しない場合において、
前記ＳＤＰオファーから前記コーデックを削除して送信する場合には、前記ＡＴＧＷで通話データをアンカーすると判断し、
前記ＳＤＰオファーから前記コーデックを削除しないで送信する場合には、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項１０記載のシグナリング方法。
【請求項１２】
セッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記ＡＴＧＷで通話データをアンカーしないと判断する、
請求項９記載のシグナリング方法。
【請求項１３】
前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷでサポートしているコーデックと一致しない場合、前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信すると判断する、
請求項９記載のシグナリング方法。
【請求項１４】
前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信すると判断する、
請求項９記載のシグナリング方法。
【国際調査報告】
2015174018.tif 000016
2015174018.tif 000017
2015174018.tif 000018
2015174018.tif 000019