JPWO2016185649A1 - 通信ノード、端末及び通信制御方法 - Google Patents

通信ノード、端末及び通信制御方法 Download PDF

Info

Publication number
JPWO2016185649A1
JPWO2016185649A1 JP2017518732A JP2017518732A JPWO2016185649A1 JP WO2016185649 A1 JPWO2016185649 A1 JP WO2016185649A1 JP 2017518732 A JP2017518732 A JP 2017518732A JP 2017518732 A JP2017518732 A JP 2017518732A JP WO2016185649 A1 JPWO2016185649 A1 JP WO2016185649A1
Authority
JP
Japan
Prior art keywords
codec
network
terminals
mode
signaling
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2017518732A
Other languages
English (en)
Other versions
JP6787884B2 (ja
Inventor
貴子 堀
貴子 堀
江原 宏幸
宏幸 江原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JPWO2016185649A1 publication Critical patent/JPWO2016185649A1/ja
Application granted granted Critical
Publication of JP6787884B2 publication Critical patent/JP6787884B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10LSPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16Vocoder architecture
    • G10L19/18Vocoders using multiple modes
    • G10L19/22Mode decision, i.e. based on audio signal content versus external parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/14Reselecting a network or an air interface
    • H04W36/144Reselecting a network or an air interface over a different radio air interface technology
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/24Reselection being triggered by specific parameters
    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10LSPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16Vocoder architecture
    • G10L19/173Transcoding, i.e. converting between two coded representations avoiding cascaded coding-decoding
    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10LSPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16Vocoder architecture
    • G10L19/18Vocoders using multiple modes
    • G10L19/24Variable rate codecs, e.g. for generating different qualities using a scalable representation such as hierarchical encoding or layered encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18Negotiating wireless communication parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H04W36/00226Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0055Transmission or use of information for re-establishing the radio link
    • H04W36/0066Transmission or use of information for re-establishing the radio link of control information between different types of networks in order to establish a new radio link in the target network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18Service support devices; Network management devices
    • H04W88/181Transcoding devices; Rate adaptation devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computational Linguistics (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • Acoustics & Sound (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

IMSノード310は、第1の網において通信を行う2つの端末のうち一方の端末が第1の網と異なる第2の網にハンドオーバした際に、2つの端末で使用されるコーデック及びコーデックモードを判断する通信ノードに関する。判断部506は、第1の網における通信で使用しているコーデック及びコーデックモードを示す情報と、一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、第2の網がサポートしているコーデック及びコーデックモードを示す情報と、の共通部分を2つの端末で使用されるコーデック及びコーデックモードに設定し、シグナリング生成部510は、設定された2つの端末で使用されるコーデック及びコーデックモードへの変更を2つの端末へ要求するためのシグナリングを生成する。

Description

本開示は、移動通信方式で用いられるコーデック制御を行う通信ノード、端末及び通信制御方法に関する。
従来、3GPP(Third Generation Partnership Project)の移動通信方式における音声通話は、3GPPの回線交換(CS:Circuit Switching)網を用いて行われていた。近年では、3GPPのパケット交換(PS:Packet Switching)網を用いた音声通話であるVoLTE(Voice over Long Term Evolution)サービスが行われつつある。
しかし、VoLTEサービスが受けられるエリアは当面の間限られる。このため、VoLTEによる音声通話(以下、VoLTE通話という)中にVoLTEサービスエリアの外に出た場合、従来の回線交換方式を用いた通話に切り替える必要がある。この切替を可能にする技術として、非特許文献1に記載のSRVCC(Single Radio Voice Call Continuity)がある。以下、図1及び図2を用いて、SRVCCによるハンドオーバの動作について説明する。
図1は3GPPの移動通信ネットワーク構成の一部を示す。図1に示す移動通信ネットワークは、e−UTRAN(evolved Universal Terrestrial Radio Access Network)、e−UTRANの基地局(e−nodeB)、PS網、CS網、CS網の基地局サブシステム、及びIMS(IP Multimedia Subsystem)から構成される。
具体的には、図1において、e−UTRANは、VoLTEサービスを提供可能な無線アクセス網である。PS網は、VoLTEサービスを提供し、P−GW(Packet Data Network Gateway)、S−GW(Serving Gateway)及びMME(Mobility Management Entity)から構成される。CS網は、MSC(Mobile Switching Center)、MGW(Media GateWay)から構成される。CS網の基地局サブシステムは、RNC(Radio Network Controller)及びnodeBから構成される。IMSは、呼制御等を行い、CSCF(Call Session Control Function)及びSCC AS(Service Centralization and Continuity Application Server)から構成される。なお、図1及び図2では、MSCとMGWとを一つのノード(MSC/MGW110)として表しているが、これらは別々のノードとして表してもよい。
図1において、移動通信端末(UE:User Equipment)であるUE100及びUE102は、最初PS網にそれぞれ接続されているとする(ただし、UE102側の無線アクセス網、基地局及びPS網は図示せず)。つまり、UE100とUE102とでVoLTE通話が行われているとする。このとき、通話の途中でUE100がCS網にハンドオーバ(HO:Hand Over)することを仮定する。
図1の実線で示されたPath A、Path B及びPath Cは、通話データが通る経路を示す。また、図1の破線で示された200、202、204及び206は、SRVCCハンドオーバ処理におけるシグナリングが通る経路を示す。
図2は、SRVCCハンドオーバ処理の動作を示すシーケンスチャートである。UE100及びUE102は最初PS網(e−UTRAN)にそれぞれ接続されており、UE100とUE102との間の通話データはPath Aを通って送受信されている。UE100がe−UTRANのカバーエリアから遠ざかろうとすると、e−nodeBは、これを検知し、MME、MSC/MGW110経由でRNC/nodeBとの間でシグナリングをやり取りする(図1に示すシグナリング200。図2に示すステップ(以下、「ST」という)200)。ST200において、nodeBとMSC/MGW110との間にCS網でのデータ経路が準備され、準備が終わると、MMEからe−nodeB経由で、UE100に対し、UTRAN(CS網)側にハンドオーバするよう命令(HO Command)が出される。
ST200の処理と同時に、MSC/MGW110は、CSCF/SCC AS経由でUE102とシグナリングをやり取りする(図1に示すシグナリング202。図2に示すST202)。これにより、UE102の通話データの送受信先を、UE100からMSC/MGW110に切り替えるよう命令が出され、Path Bが確立される。
UE100は、UTRANにハンドオーバした後、RNC/nodeB経由でMSC/MGW110とシグナリングをやり取りする(図1に示すシグナリング204。図2に示すST204)。これにより、Path Cが確立される。
Path C確立後、MSC/MGW110は、MME経由でP−GW/S−GWとシグナリングをやり取りする(図1に示すシグナリング206。図2に示すST206)。これにより、Path Aは削除される。
以上、SRVCCハンドオーバの動作について説明した。
また、SRVCCを改良し、データ経路切替にかかる時間を短縮する方式として、非特許文献2に記載の、ATCF(Access Transfer Control Function)エンハンスメントを用いたSRVCC方式(eSRVCC:enhanced-SRVCC)がある。このeSRVCCの動作の一例について、以下、図3及び図4を用いて説明する。
図3は、eSRVCCを可能にする、3GPPの移動通信ネットワーク構成の一部を示す。図3に示す移動通信ネットワークは、図1と同様、e−UTRAN、e−nodeB、PS網、CS網、CS網の基地局サブシステム、及びIMSから構成される。ここでIMSには、CSCF及びSCC ASの他、ATCF(Access Transfer Control Function)及びATGW(Access Transfer GateWay)が存在する。なお、図3及び図4では、ATCFとATGWとを一つのノード(ATCF/ATGW320)として表しているが、これらは別々のノードとして表してもよい。また、図3では、IMSの各ノードをまとめてIMSノード310として表すこともある。
図3において、UE100及びUE102は、最初PS網にそれぞれ接続されているとする(ただし、UE102側の無線アクセス網、基地局及びPS網は図示せず)。つまり、UE100とUE102とでVoLTE通話が行われているとする。このとき、通話の途中でUE100がCS網にハンドオーバ(HO:Hand Over)することを仮定する。
図3の実線で示されたPath A、Path B、Path C及びPath Dは、通話データが通る経路を示す。また、図3の破線で示された300、302、304及び306は、eSRVCCハンドオーバ処理におけるシグナリングが通る経路を示す。
図4は、eSRVCCハンドオーバの動作を示すシーケンスチャートである。UE100及びUE102は最初PS網(e−UTRAN)にそれぞれ接続されている。eSRVCCハンドオーバを実現するシステムでは、ATCF/ATGW320において、ATCFはIMSのシグナリング(IMSシグナリング)をアンカーし、ATGWは通話データをアンカーする。つまり、UE100とUE102との間の通話開始時において、通話開始のIMSシグナリングはATCFで中継され、ATCFがATGWでの通話データのアンカーが必要と判断した場合、通話データのアンカーポイントとしてATGWが割り当てられる。これにより、UE100とUE102との間の通話データは、Path A及びPath Bを通って送受信される。
UE100がe−UTRANのカバーエリアから遠ざかろうとすると、e−nodeBは、これを検知し、MME、MSC/MGW110経由でRNC/nodeBとの間でシグナリングをやり取りする(図3に示すシグナリング300。図4に示すST300)。ST300において、nodeBとMSC/MGW110との間にCS網でのデータ経路が準備され、準備が終わると、MMEからe−nodeB経由で、UE100に対し、UTRAN(CS網)側にハンドオーバするよう命令(HO Command)が出される。
ST300の処理と同時に、MSC/MGW110は、ATCFにシグナリングを送る。これによりATCFからATGWに経路切替の指示が出され、ATGWの通話データ送受信先がUE100からMSC/MGW110に切り替わる(図3に示すシグナリング302。図4に示すST302)。すなわち、Path Cが確立される。また、ATGWへの経路切替処理が完了すると、ATCFは、SCC−ASに通知シグナリングを送信する(図3に示すシグナリング302。図4に示すST302)。
UE100は、UTRANにハンドオーバした後、RNC/nodeB経由でMSC/MGW110とシグナリングをやり取りする(図3に示すシグナリング304。図4に示すST304)。これにより、Path Dが確立される。
Path D確立後、MSC/MGW110は、MME経由でP−GW/S−GWとシグナリングをやり取りする(図3に示すシグナリング306。図4に示すST306)。これにより、Path Bは削除される。
以上、eSRVCCハンドオーバの動作について説明した。
次に3GPPの音声通話に使用される音声コーデックについて説明する。
3GPP標準規格のコーデックとして、非特許文献3に記載の狭帯域(NB:Narrowband)のマルチレート(Multi-Rate)コーデックであるAMR(Adaptive Multi-Rate)コーデック、及び、非特許文献4に記載の広帯域(WB:Wideband)のマルチレートコーデックであるAMR−WB(Adaptive Multi-Rate Wideband)コーデックがある。AMRコーデック及びAMR−WBコーデックは、CELP(Code-Exited Linear Predictive)方式を用いている。また、AMRコーデック及びAMR−WBコーデックは、CS網などの伝送路で起こりうるビット誤りにも、PS網で起こりうるパケットロスにも耐性があるため、CS網でもPS網でも利用が可能である。
また、3GPP標準規格の別のコーデックとして、非特許文献5に記載のEVS(Enhanced Voice Service)コーデックがある。EVSコーデックは、狭帯域、広帯域に加え、超広帯域(SWB:Super Wideband)及びフル帯域(FB:Fullband)をサポートしたマルチレートコーデックであり、ビットレートも5.9kbpsから128kbpsまでをサポートしている。EVSコーデックでは、上述のEVSオリジナルのコーデックモード(EVSプライマリモード)の他、AMR−WB互換モード(EVS AMR−WB互換モード)もサポートしている。EVSコーデックのEVSプライマリモードでは、PS網での利用のみを想定し、ビット誤りを想定していないため、CELP方式に加え、符号化効率を優先した算術符号を用いた方式が一部に組み込まれた、MDCT(Modified Discrete Cosine Transform)方式が用いられている。ただし、EVSコーデックのCS網でのサポートも2014年9月頃より議論されている(例えば、非特許文献6を参照)。
なお、狭帯域(NB:Narrowband)コーデックとは、8kHzでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。狭帯域コーデックでは、一般的に300Hz〜3.4kHzの周波数帯域を有するが、周波数帯域はこれに限らず0〜4kHzの範囲内であればよい。
また、広帯域(WB:Wideband)コーデックとは、16kHzでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。広帯域コーデックでは、一般的に50Hz〜7kHzの周波数帯域を有するが、周波数帯域はこれに限らず0〜8kHzの範囲内であればよい。
また、超広帯域(SWB:Super Wideband)コーデックとは、32kHzでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。超広帯域コーデックでは、一般的に50Hz〜14kHzの周波数帯域を有するが、周波数帯域はこれに限らず0〜16kHzの範囲内であればこれに限定されない。
また、フル帯域(FB:Fullband)コーデックとは、48kHzでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。超広帯域コーデックでは、一般的に20Hz〜20kHzの周波数帯域を有するが、周波数帯域はこれに限らず0〜24kHzの範囲内であればこれに限定されない。
また、マルチレートコーデックとは、複数のビットレートをサポートするコーデックである。
また、ここでは、「帯域(又は帯域幅)」とはコーデックの入出力となる信号の帯域のことを指す。
また、コーデックモードとは、ビットレート又は帯域、EVSコーデックにおけるEVSプライマリモードとEVS AMR−WB互換モードなど、コーデックを構成する要素の部分集合(subset)を意味する。
国際公開第2013/156063号
図1又は図3において、UE100がPS網からCS網にハンドオーバした際、UE100が使用するコーデックはCS網でサポートされているコーデックに再設定される。このときに再設定されるコーデックは、UE100がPS網で使用していたコーデックと異なること、又は、同一であってもCS網でサポートされるモード(ビットレート又はオーディオ帯域など)がPS網と異なることが考えられる。
しかしながら、UEがPS網からCS網にハンドオーバした際に再設定されるコーデック又はコーデックモードがPS網で使用していたコーデック又はコーデックモードと異なる場合の動作については未だ十分な検討がなされていない。
本開示の一態様は、通信中の端末の一方が使用していたコーデックが再設定される場合でも、通話品質の劣化を抑えて通信を継続することができる通信ノード、端末及び通信制御方法を提供する。
本開示の一態様に係る通信ノードは、第1の網において通信を行う2つの端末のうち一方の端末が前記第1の網と異なる第2の網にハンドオーバした際に、前記2つの端末で使用されるコーデック及びコーデックモードを判断する通信ノードに関する。第1の網における通信で使用しているコーデック及びコーデックモードを示す情報と、一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、第2の網がサポートしているコーデック及びコーデックモードを示す情報と、の共通部分を2つの端末で使用されるコーデック及びコーデックモードに設定する判断部と、設定された2つの端末で使用されるコーデック及びコーデックモードへの変更を2つの端末へ要求するためのシグナリングを生成する生成部と、を具備する構成を採る。
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
本開示の一態様によれば、通信中の端末の一方が使用していたコーデックが再設定される場合でも、通話品質の劣化を抑えて通信を継続することができる。
本開示の一態様における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および/または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、1つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
3GPPの移動通信ネットワークの一部を示す構成図 SRVCCハンドオーバの動作を示すシーケンスチャート eSRVCCを可能にする、3GPPの移動通信ネットワークの一部を示す構成図 eSRVCCハンドオーバの動作を示すシーケンスチャート 実施の形態1に係るIMSノードの構成を示すブロック図 実施の形態1に係る動作の一例を示すシーケンスチャート 実施の形態1に係るSDPオファー・アンサーの一例を示す図 実施の形態1に係るMSC/MGW110におけるUE100がサポートするコーデックとCS網がサポートするコーデック及びコーデックモードとの比較結果の一例を示す図 実施の形態1に係る判断部における判断の一例を示すフローチャート 実施の形態2に係るMSC/MGWノードの構成を示すブロック図 実施の形態2に係る動作の一例を示すシーケンスチャート 実施の形態3に係る端末(UE)の構成を示すブロック図
[本開示の一態様に至った経緯]
図1又は図3において、UE100がPS網からCS網にハンドオーバした際、UE100とUE102との通話継続を可能にするためには、次の2つの方法が考えられる。1つ目の方法は、MSC/MGW110又はATCF/ATGWにおいてトランスコーディングを行う方法である。2つ目の方法は、UE102で使用されるコーデックをUE100の変更後のコーデックと同じものに変更する方法である。
前者のトランスコーディングを行う方法では、トランスコーディングによる通話品質の劣化が生じてしまう。
一方、後者のコーデックを変更する方法では、トランスコーディングを行う方法のような通話品質の劣化は生じないものの、UE102のコーデックを変更するためのシグナリングに時間がかかり、通話が途切れる時間が長くなるので好ましくない。更に、eSRVCCハンドオーバでは、UE100のハンドオーバの際の経路切替のためのシグナリングがATCFで終端するため、UE102のコーデックを変更するためのシグナリングを送ることすらできない。すなわち、eSRVCCハンドオーバでは、既存のシグナリングを使ってUE102のコーデックを変更することができない。
特許文献1には、SRVCCハンドオーバ又はeSRVCCのハンドオーバ過程において、MGW/MSCがMMEよりPS->CS reqメッセージ(図2又は図4を参照)を受け取った際、このメッセージの中に含まれる情報に基づいて、UEがCS網で使用するコーデックを予め決定する方法が開示されている。メッセージの中に含まれる情報とは、例えば、ハンドオーバするUEがサポートするコーデックを示す情報、及び、IMS側(SCC AS又はATCF/ATGW)から受け取った、UEがPS網における通信で使用していたコーデックを示すである。
この方法を用いれば、MGW/MSCは、UEがCS網で使用するコーデックを決定する前に、UEがPSで使用していたコーデックを知ることができる。このため、PS網で使用されているコーデック及びコーデックモードがCS網でもサポート可能な場合には、CS網においてコーデック及びコーデックモードをPS網側と統一することができるので、この方法は有用である。
しかしながら、非特許文献1には、PS網で使用されているコーデック及びコーデックモードがCS網でサポート可能ではない場合の解決方法に関しては何ら開示されていない。よって、PS網で使用されているコーデック及びコーデックモードがCS網でサポート可能ではない場合には、CS網において、PS網でのセッション開始時に折衝したコーデック及びコーデックモードの品質が担保できないという課題が生じる。
また、第二の課題として、CS網でEVSコーデックを利用した場合、エンコード方式によっては、伝送路で発生するビット誤りにより復号が正しく行われず、品質劣化が生じてしまう。
非特許文献7には、AMR−WBコーデックをCS網にて用いる際、誤り耐性が無いビットに対してCRC(Cyclic Redundancy Check)を付加し、誤りを検出する方法が開示されている。また非特許文献8には、AMRコーデック又はAMR−WBコーデックを用いた際にCS網で誤りが生じた場合、この誤りを含むフレームをPS網に送る際、Qビット又はSPEECH LOSTなどを用いて、当該フレームに誤りが生じていることをPS網の端末に通知する方法が開示されている。
これらの方法を用いることにより、PS網の端末は誤りが生じたフレームを復号せずに破棄することが可能である。しかしながら、EVSコーデックの一部で使用されている、符号化効率を優先した算術符号を用いた方式の場合には、符号化されたビットの大半に誤り耐性が無いため、上述したCRCを用いた方式の有効性は低くなる。
そこで、本開示の一態様では、PS網で使用されているコーデック及びコーデックモードがCS網でサポート可能でない場合でも、CS網において、PS網でのセッション開始時に折衝されたコーデック/コーデックモードの品質(つまり、通話品質)を担保する。また、ビット誤り耐性を有さない方式(アルゴリズム)を用いるコーデック(a codec utilizing the algorithm which is not robust against bit errors)が、ビット誤りを生じる可能性のある網(例えば、CS網)で使用される場合においても、品質の劣化を抑えて通信を継続することができる。
以下、本開示の各実施の形態について、図面を参照して詳細に説明する。
(実施の形態1)
図5は、本実施の形態に係るIMSノード310の構成を示すブロック図である。「IMSノード」とは、例えば、SCC AS又はATCF/ATGWを指す。
IMSノード310は、受信部500、送信部502、記憶部504、判断部506、ポリシ参照部508及びシグナリング生成部510を有して構成される。なお、IMSノード310は、図5に示す構成部の他に、IMSノードが標準で有する機能も具備する。
受信部500は、シグナリングを受信する。受信部500が受信するシグナリングには、例えば、PS網での通信開始時の呼制御(セッションセットアップ)におけるSDP(Session Description Protocol)オファー及びSDPアンサー又はその一部を示す情報(すなわち、PS網における通信で端末が使用しているコーデック及びコーデックモードを示す情報)、CS網にハンドオーバする端末がサポートしているコーデック及びコーデックモードを示す情報、又は、CS網がサポートしているコーデック及びコーデックモードを示す情報等が挙げられる。
なお、受信部500は、CS網にハンドオーバする端末がサポートしているコーデック及びコーデックモードを示す情報、及び、CS網がサポートしているコーデック及びコーデックモードを示す情報の代わりに、CS網にハンドオーバする端末がサポートしているコーデック及びコーデックモードを示す情報と、CS網がサポートしているコーデック及びコーデックモードを示す情報との間で合致するコーデック及びそのコーデックモードを示す情報(コーデック/コーデックモード情報)をCS網(例えば、MGW/MSC110)から受信してもよい。
送信部502は、シグナリングを送信する。送信部502が送信するシグナリングには、例えば、コーデックモードの変更を要求するコーデックモード変更要求(モード変更リクエスト)が挙げられる。
記憶部504は、受信部500から出力されるSDPオファー及びSDPアンサーの内容(つまり、PS網で使用しているコーデック/コーデックモードの情報)を記憶する。
判断部506は、SRVCCハンドオーバ又はeSRVCCハンドオーバが発生した場合に、ハンドオーバする端末(図1又は図3ではUE100)がPS網における通信で使用しているコーデック及びコーデックモードと、当該端末がサポートしているコーデック及びコーデックモードと、ハンドオーバ先のCS網がサポートしているコーデック及びコーデックモードとを比較する。そして、判断部506は、コーデック/コーデックモードの比較結果、及び、後述するポリシ参照部508で参照されたポリシに基づいて、コーデック及びコーデックモードの変更が必要か否かを判断する。
ポリシ参照部508は、サービスオペレータが有するポリシを参照する。
シグナリング生成部510は、判断部506においてコーデックモードの変更が必要と判断された場合、コーデックモード変更要求を含むシグナリングを生成する。シグナリング生成部510は、生成したシグナリングを送信部502に出力する。
図6は、本実施の形態に係る動作の一例を示すシーケンスチャートである。
図6では、UE100は、最初PS網(LTE網)に在圏しており、同じくPS網(LTE網)に在圏しているUE102と、IMSノード310を介して、セッションセットアップを行い(例えば、非特許文献2を参照)、SDPオファー/SDPアンサーにより、音声通信で使用するコーデック及びコーデックモードを決定する(ST601)。
この際、IMSノード310(記憶部504)は、セッションセットアップにおいて端末間でやり取りされるSDPオファー及びSDPアンサーの情報又はその一部(例えば、SDPアンサーの内容のみ)を記憶する(ST602)。
図7は、セッションセットアップにおいて端末間でやり取りされるSDPオファー及びSDPアンサーの一例を示す。図7に示す例では、コーデック折衝において、SDPオファーを受け取ったUEは、EVSコーデックの超広帯域(SWB)(bw=swb)であり、ビットレート9.6kbps〜24.4kbpsの範囲(br=9.6-24.4)を選択し、選択したコーデックモードをSDPアンサーに記述している。IMSノード310の記憶部504は、少なくともこのSDPアンサーの内容を記憶している。
UE100は、UE102とPS網(LTE網)で音声通話を行っている際に(ST603)、PS網からCS網へのSRVCCハンドオーバ又はeSRVCCハンドオーバを行う。
具体的には、SRVCCハンドオーバ又はeSRVCCのハンドオーバ過程において、UE100がe−UTRANのカバーエリアから遠ざかろうとすると、e−nodeBは、これを検知し、MMEに対してHO Requiredメッセージを送信し(ST604)、MMEは、MSC/MGW110に対してPS->CS reqメッセージを送信する(ST605)。なお、図6において、HO Requiredメッセージ及びPS->CS reqメッセージは、非特許文献1に記載の通りである。例えば、PS->CS reqメッセージには、UE100がサポートしているコーデック(UE supported codec)を示すリスト(Supported Codec List)が含まれる。
MGW/MSC110は、PS->CS reqメッセージを受け取とると、PS->CS reqメッセージに含まれるUE100がサポートしているコーデックのリストと、自網(CS網)でサポートしているコーデック及びコーデックモードを照合(比較)する(ST606)。MGW/MSC110は、照合の結果、合致するコーデック及びそのコーデックモードを示すコーデック/コーデックモード情報をIMSノード310に送信する(ST607)。なお、コーデック/コーデックモード情報の送信方法は、例えばIMSでSDPを使用して送信してもよく、別の方法でもよい。
図8は、MSC/MGW110における、UE100がサポートするコーデックと、CS網がサポートするコーデック及びコーデックモードとの照合(比較)結果の一例を示す。すなわち、図8に示す情報は、CS網にハンドオーバするUE100がサポートしているコーデック及びコーデックモードを示す情報と、CS網がサポートしているコーデック及びコーデックモードを示す情報との間で合致するコーデック及びそのコーデックモードを示す情報である。
IMSノード310の判断部506は、MGW/MSC110から受け取ったコーデック/コーデックモード情報と、記憶部504に記憶されているSDPオファー/SDPアンサーの内容(又はその一部)と、ポリシ参照部508が参照するサービスオペレータが有するポリシとに基づいて、CS網で使用するコーデック/コーデックモード(つまり、UE100が使用するコーデック/コーデックモード)、及び、PS網で使用するコーデック/コーデックモード(つまり、UE102が使用するコーデック/コーデックモード)を判断する(ST608)。なお、判断部506における判断処理の詳細については後述する。
そして、IMSノード310は、判断したコーデック/コーデックモードをMSC/MGW110に指示する(ST609)。また、MSC/MGW110は、CS網側(RNC/nodeB)にHO Reqメッセージを送る際、IMSノード310から指示されたコーデック及びコーデックモードを選択することを通知する(ST610)。
nodeBとMSC/MGW110との間にCS網でのデータ経路が準備され、準備が終わると、MMEからe−nodeB経由で、UE100に対し、UTRAN(CS網)側にハンドオーバするよう命令(HO Command)が出される(ST611)。
MGW/MSC110とIMSノード310との間でIMSのセッショントランスファー(initiation of session transfer)が行われる(ST612)。
UE100は、UTRAN(CS網)にハンドオーバした後、RNC/nodeB経由でMSC/MGW110とシグナリングをやり取りする(ST613)。これにより、UE100とMSC/MGW110との間の通信経路が切り替えられる。
また、UE102の通話データの通信経路をUE100からMSC/MGW110に切り替えるよう命令が出され、当該通信経路が切り替えられる(ST614)。
また、IMSノード310は、PS網のUE102に、ST608で判断したコーデックモードへの変更を要求するモード変更リクエストを通知する(ST615)。
なお、PS網に対するモード変更リクエストの通知(ST615)は、図6に示すように、データの通信経路の変更(Speech Data path switched)が行われた直後に行われてもよく、データの通信経路の変更前に行われてもよい。
また、モード変更リクエストは、RTP(Real-time Transport Protocol)ペイロードヘッダに含まれてもよく、RTCP(RTP Control Protocol)に含まれてもよい。例えば、モード変更リクエストは、非特許文献9に記載されたRTPペイロードフォーマットヘッダのCMR(Codec Mode Request)バイトを用いて通知されてもよく、非特許文献10に記載のRTCP(RTP Control Protocol)−APPのCMRを用いて通知されてもよく、他の方法を用いて通知されてもよい。
また、図6において、モード変更リクエストは、データ経路上に存在するノードがIMSノード310から指示を受けてUE102に送信すればよい。例えば、このデータ経路上のノードは、ATGWでもよく、MGWでもよい。例えば、ATGWがRTPペイロードフォーマットヘッダのCMRバイトを用いてモード変更リクエストを通知する場合には、ATGWは、MGWから送信されたデータに対して、モード変更リクエストを含んだCMRバイトを追加する。
次に、IMSノード310の判断部506における判断について詳細に説明する。図9は、判断部506における判断の一例を示すフローチャートである。
判断部506は、まず、ポリシ参照部508により参照されたサービスオペレータのポリシ(ローカルポリシ)が存在するか否かを判断する(ST900)。サービスオペレータのポリシが存在する場合(ST900:YES)、判断部506は、このポリシに従ったコーデック及びコーデックモードを使用することを判断する(ST902)。IMSノード310は、必要に応じてCS網側又はPS網側、又はその両方にコーデック/コーデックモードを示すシグナリングメッセージを送信する。
例えば、サービスオペレータのポリシの一例として、「PS網で使用されていたコーデックがCS網でもサポートされているのであれば、PS網でのセッションセットアップ時に折衝されたコーデックモードはCS網側のコーデックモードで上書きされてもよい」という内容が挙げられる。例えば、図7に示すSDPアンサーと図8に示す照合結果とを比較した場合、図7に示すSDPアンサーに記述された、セッションセットアップ時に折衝されたEVSのビットレートは9.8kbpsから24.4kbpsであるのに対して、図8に示すCS網でサポートされているEVSのビットレートは5.9kbpsから13.2kbpsである。この場合、上記ポリシに従う場合には、IMSノード310は、MSC/MGW110に対してEVSのビットレートとして5.9kbpsから13.2kbpsを選択することを指示し、MSC/MGW110は、CS網側にHO Reqを送信する際、EVSのビットレートとして5.9kbpsから13.2kbpsを選択することを通知する(ST610)。また、IMSノード310は、PS網側には、ビットレートの上限を13.2kbpsに設定することを通知する(ST615)。
一方、サービスオペレータのポリシが存在しない場合(ST900:NO)、判断部506は、MSC/MGW110から通知されたコーデック/コーデックモード情報(ST607)に示されるコーデック及びコーデックモードと、PS網で使用されているコーデック及びコーデックモードとに共通部分があるか否かを判断する(ST904)。
共通部分がある場合(ST904:YES)、判断部506は、共通部分であるコーデック及びコーデックモードを使用することを判断する(ST906)。IMSノード310は、CS網側又はPS網側、又はその両方に共通部分のコーデック/コーデックモードの使用を促すシグナリングメッセージを送信する。
例えば、例えば図7に示すSDPアンサーと図8に示す照合結果とを比較した場合、EVSのビットレートの共通部分は9.8kbps及び13.2kbpsである。そこで、IMSノード310は、MSC/MGW110に対してEVSのビットレートとして9.8kbps及び13.2kbpsのみを使用することを指示し、MSC/MGW110は、CS網側にHO Reqを送信する際、EVSのビットレートとして9.8kbps及び13.2kbpsのみを選択することを通知する(ST610)。また、IMSノード310は、PS網側には、ビットレートを9.8kbps及び13.2kbpsに設定することを通知する(ST615)。
なお、図9に示すST906の処理は、ST900の判断において存在が確認されたポリシが「PS網側で使用されていたコーデックがCS網側でもサポートされているなら、コーデックモードとして共通部分を使用する」という内容である場合にST902で行われる処理と等価である。
また、共通部分とは、完全に一致する部分ではなく、共通の上限値であってもよい。例えば、図7に示すSDPアンサーと図8に示す照合結果とを比較した場合、EVSのビットレートの上限は13.2kbpsであるので、PS網側にはビットレートの上限を13.2kbpsにする通知が送られる。また、CS網側で使われるビットレートの組み合わせは、非特許文献11に記載の通り、予め数通り決められている場合がある。例えば、EVSの場合であっても、図8に示される組み合わせ、すなわち{5.9kbps,7.2kbps,8.0kbps,9.6kbps,13.2kbps}の他に、例えば{8.0kbps,9.6kbps,13.2kbps}の組み合わせがサポートされているとする。この場合、ビットレートの下限値として、PS網で折衝されたビットレートの下限値に近い後者の組み合わせ、すなわち{8.0kbps,9.6kbps,13.2kbps}が選択されてもよい。
一方、PS網及びCS網で使用される同一コーデックのコーデックモードに共通部分が無い場合(ST904:NO)、判断部506は、PS網で使用されていたコーデックに別のコーデックとの互換モードが存在する場合、コーデック/コーデックモード情報に示されるコーデック/コーデックモードの中に、互換性のあるコーデックが存在するか否かを判断する(ST908)。つまり、判断部506は、PS網で使用されたコーデックに互換モードが存在する場合に、CS網において当該互換モードに変更可能であるか否かを判断する。
CS網において当該互換モードに変更可能である場合(ST908:YES)、判断部506は、互換モードのコーデックを使用することを判断する(ST910)。IMSノード310は、CS網側又はPS網側、又はその両方に、互換モードのコーデックの使用を促すシグナリングメッセージを送信する(ST610,ST615)。
上述したように、EVSコーデックは、AMR−WB互換モードもサポートしている。そこで、IMSノード310は、ST910では、MSC/MGW110に対してEVSのAMR−WB互換モードを使用することを指示し、MSC/MGW110は、CS網側にHO Reqを送信する際、EVSのAMR−WB互換モードに変更することを通知する(ST610)。また、IMSノード310は、PS網側には、EVSのAMR−WB互換モード、かつ、ビットレートの上限を12.65kbps(図8を参照)に設定することを通知する(ST615)。
なお、図9に示すST910の処理は、ST900の判断において存在が確認されたポリシが「PS網側で使用されているコーデックに別のコーデックとの互換モードが存在する場合に、CS網において当該互換モードに変更する」という内容である場合にST902で行われる処理と等価である。
一方、PS網で使用されていたコーデックに別のコーデックとの互換モードが存在しない場合、又は、CS網において互換モードに変更可能ではない場合(ST908:NO)、判断部506は、CS網でサポートしているコーデックをCS網で使用し、PS網とCS網との間でトランスコーディングを行うと判断する(ST912)。
なお、図9に示すST912の処理は、ST900の判断において存在が確認されたポリシが「トランスコーディングを行う」という内容である場合にST902で行われる処理と等価である。
また、ST912において、トランスコーディングの代わりに、セッションの再折衝を行い、再折衝の結果に従ってUE102のコーデックをCS網でサポート可能なコーデックに変更してもよい。
また、トランスコーディングは、データ経路上に存在するノードがIMSノードからトランスコーディングをするよう指示を受けて行われればよい。例えば、トランスコーディングを行うノードは、ATGWでもよく、MGWでもよい。
以上、IMSノード310の判断部506における判断について説明した。
このようにして、IMSノード310の判断部506は、PS網において通信を行う2つの端末のうち一方の端末がCS網にハンドオーバした際、PS網における通信で使用しているコーデック及びコーデックモードを示す情報と、ハンドオーバした一方の端末(UE100)がサポートしているコーデック及びコーデックモードを示す情報と、CS網がサポートしているコーデック及びコーデックモードを示す情報と、の共通部分を上記2つの端末で使用されるコーデック及びコーデックモードに設定する。そして、IMSノード310のシグナリング生成部510は、設定された上記2つの端末で使用されるコーデック及びコーデックモードへの変更を当該2つの端末へ要求するためのシグナリングを生成する。
このように、本実施の形態では、上記共通部分であるコーデック/コーデックモードを用いることにより、PS網で使用されているコーデック及びコーデックモードがCS網でサポート可能でない場合でも、CS網において、PS網でのセッション開始時に折衝したコーデック及びコーデックモードの品質を担保することができる。
また、上記共通部分が存在しない場合、IMSノード310の判断部506は、PS網における通信で使用しているコーデックに、別のコーデックとの互換モードが存在し、かつ、ハンドオーバした一方の端末がサポートしているコーデック及びCS網がサポートしているコーデックに、当該別のコーデックが含まれる場合、その別のコーデック又は別のコーデックとの互換モードを、上記2つの端末で使用されるコーデック及びコーデックモードに設定する。
更に、本実施の形態では、サービスオペレータのポリシが存在する場合には、当該ポリシに従ってコーデック/コーデックモードが設定される。
これにより、本実施の形態によれば、UEのハンドオーバ先のCS網でサポートしている、コーデック及びコーデックモードが、PS網での通信開始時のセッションセットアップ時に折衝されたコーデック及びコーデックモードと異なる場合でも、サービスオペレータのポリシ及びセッションセットアップ時に折衝された内容から外れる事なく、通信を継続することができる。
よって、本実施の形態によれば、通信中の端末の一方が使用していたコーデックが再設定される場合でも、通話品質の劣化を抑えて通信を継続することができる。
(実施の形態2)
実施の形態1ではIMSノード310がCS網への端末のハンドオーバ時に使用するコーデックの判断を行う場合について説明したのに対して、本実施の形態では、MSC/MGW110がCS網への端末のハンドオーバ時に使用するコーデックの判断を行う場合について説明する。
図10は、本実施の形態に係るMSC/MGW110の構成を示すブロック図である。
MSC/MGW110は、受信部1000、送信部1002、記憶部1004、判断部1006、ポリシ参照部1008及びシグナリング生成部1010を有して構成される。なお、MSC/MGW110は、図10に示す構成部の他に、MSC/MGWが標準で有する機能も具備する。
受信部1000は、シグナリングを受信する。受信部1000が受信するシグナリングには、例えば、IMSノード310から受け取る、PS網での通信開始時の呼制御(セッションセットアップ)におけるSDPオファー及びSDPアンサーの内容又はその一部を示す情報(すなわち、PS網における通信で端末が使用しているコーデック及びコーデックモードを示す情報。本実施の形態ではコーデック/コーデックモード情報と呼ぶ)、MMEから受け取る、UE100がサポートしているコーデックを示すリストを含むPS->CS reqメッセージ等が挙げられる。
送信部1002は、シグナリングを送信する。送信部1002が送信するシグナリングには、例えば、コーデックモードの変更を要求するコーデックモード変更要求(モード変更リクエスト)、及び、IMSノード310に対してコーデック/コーデックモード情報を要求するクエリが挙げられる。
記憶部1004は、受信部1000から出力される、SDPオファー及びSDPアンサーの内容又はその一部、及び、CS網から送信されるUE100がサポートしているコーデック情報を記憶する。また、記憶部1004は、CS網がサポートしているコーデック及びコーデックモードを示す情報を記憶してもよい。
判断部1006は、SRVCCハンドオーバ又はeSRVCCハンドオーバが発生した場合に、ハンドオーバする端末(図1又は図3ではUE100)がPS網における通信で使用しているコーデック及びコーデックモードと、当該端末がサポートしているコーデック及びコーデックモードと、CS網がサポートしているコーデック及びコーデックモードとを比較する。そして、判断部1006は、コーデック/コーデックモードの比較結果、及び、後述するポリシ参照部1008で参照されたポリシに基づいて、コーデック及びコーデックモードの変更が必要か否かを判断する。
ポリシ参照部1008は、サービスオペレータが有するポリシを参照する。
シグナリング生成部1010は、判断部1006においてコーデックモードの変更が必要と判断された場合、コーデックモード変更要求を含むシグナリングを生成する。また、シグナリング生成部1010は、IMSノード310に対して、SDPオファー/SDPアンサーの内容又はその一部を受け取るためのシグナリング(クエリ)を生成する。シグナリング生成部1010は、生成したシグナリングを送信部502に出力する。
図11は、本実施の形態に係る動作の一例を示すシーケンスチャートである。なお、図11において、実施の形態1(図6)と同様の処理については同一符号を付し、その説明を省略する。
図11では、実施の形態1と同様、UE100は、最初PS網(LTE網)に在圏しており、同じくPS網(LTE網)に在圏しているUE102と、音声通話を行っている。
MSC/MGW110の記憶部1004は、ST605においてMMEから受け取ったPS->CS reqメッセージに含まれる、UE100がサポートしているコーデックを示す情報(Supported Codec List)を記憶する。
MGW/MSC110のシグナリング生成部1010は、ST601においてUE100とUE102との間でやり取りされたSDPオファー/SDPアンサーの内容又はその一部を要求する、IMSノード310に対するクリエメッセージを生成する。生成されたクリエメッセージは、MGW/MSC110からIMSノード310へ送信される(ST1101)。なお、このクリエメッセージは、IMSシグナリングでもよく、別の方法でもよい。
IMSノード310は、ST1101においてクリエメッセージを受け取ると、保持しているSDPオファー/SDPアンサーの内容又はその一部を含むコーデック/コーデックモード情報をMGW/MSC110へ送信する(ST1102)。MGW/MSC110の記憶部1004は、受け取ったコーデック/コーデックモード情報を記憶する。
MGW/MSC110の判断部1006は、IMSノード310から受け取ったコーデック/コーデックモード情報(PS網における通信で使用しているコーデック/コーデックモード)と、UE100がサポートしているコーデックのリストと、自網(CS網)でサポートしているコーデック/コーデックモードと、ポリシ参照部508が参照するサービスオペレータが有するポリシと、に基づいて、CS網で使用するコーデック/コーデックモード(つまり、UE100が使用するコーデック/コーデックモード)、及び、PS網で使用するコーデック/コーデックモード(つまり、UE102が使用するコーデック/コーデックモード)を判断する(ST1103)。
なお、判断部1006における判断処理は、実施の形態1(例えば、図9を参照)と同様であるのでここではその説明を省略する。
そして、MGW/MSC110は、CS網側(RNC/nodeB)にHO Reqメッセージを送る際、判断したコーデック/コーデックモードを含めて通知する(ST610)。また、MGW/MSC110は、判断したコーデック/コーデックモードのうち、PS網で使用するコーデック/コーデックモードを、IMSノード310に通知する(ST1104)。IMSノード310へのコーデック/コーデックモードの通知には、IMSシグナリングを用いてもよく、別の方法でもよい。
また、MGW/MSC110は、PS網のUE102に、ST1103で判断したコーデックモードへの変更を要求するモード変更リクエストを通知する(ST1105)。
なお、PS網に対するモード変更リクエストの通知(ST1105)は、図11に示すように、データの通信経路の変更(Speech Data path switched)が行われた直後に行われてもよく、データの通信経路の変更前に行われてもよい。
また、モード変更リクエストは、RTPペイロードヘッダに含まれてもよく、RTCPに含まれてもよい。例えば、モード変更リクエストは、非特許文献9に記載されたRTPペイロードフォーマットヘッダのCMR(Codec Mode Request)バイトを用いて通知されてもよく、非特許文献10に記載のRTCP−APPのCMRを用いて通知されてもよく、他の方法を用いて通知されてもよい。
また、図11において、モード変更リクエストは、MGW/MSC110から送信されてもよく、ATGWから送信されてもよい。例えば、ATGWがRTPペイロードフォーマットヘッダのCMRバイトを用いてモード変更リクエストを通知する場合には、ATGWは、MGWから送信されたデータに対して、モード変更リクエストを含んだCMRバイトを追加する。
また、例えば、サービスオペレータのポリシが「セッションの再折衝を行い、PS網側のコーデックを変更する」という内容の場合には、MGW/MSC110は、PS網で使用するコーデックを決定する前にIMSノード310を通じてUE102にSDPオファーを送信し、UE102からIMSノード310経由でSDPアンサーを受け取った後に、CS側で使用するコーデック及びコーデックモードを含む、HO reqメッセージを送信してもよい。
このようにして、MGW/MSC110の判断部1006は、PS網において通信を行う2つの端末のうち一方の端末がCS網にハンドオーバした際、PS網における通信で使用しているコーデック及びコーデックモードを示す情報と、ハンドオーバした一方の端末(UE100)がサポートしているコーデック及びコーデックモードを示す情報と、CS網がサポートしているコーデック及びコーデックモードを示す情報と、の共通部分を上記2つの端末で使用されるコーデック及びコーデックモードに設定する。そして、MGW/MSC110のシグナリング生成部1010は、設定された上記2つの端末で使用されるコーデック及びコーデックモードへの変更を当該2つの端末へ要求するためのシグナリングを生成する。
このように、本実施の形態では、実施の形態1と同様、上記共通部分であるコーデック/コーデックモードを用いることにより、PS網で使用されているコーデック及びコーデックモードがCS網でサポート可能でない場合でも、CS網において、PS網でのセッション開始時に折衝したコーデック及びコーデックモードの品質を担保することができる。
また、本実施の形態によれば、実施の形態1と同様、UEのハンドオーバ先のCS網でサポートしている、コーデック及びコーデックモードが、PS網での通信開始時のセッションセットアップ時に折衝されたコーデック及びコーデックモードと異なる場合でも、サービスオペレータのポリシ及びセッションセットアップ時に折衝された内容から外れる事なく、通信を継続することができる。
よって、本実施の形態によれば、通信中の端末の一方が使用していたコーデックが再設定される場合でも、通話品質の劣化を抑えて通信を継続することができる。
(実施の形態3)
本実施の形態では、UE100に対するSRVCCハンドオーバ又はeSRVCCハンドオーバが起きた際、UE100がCS網で使用するコーデックとして、EVSプライマリモードのように、ビット誤り耐性を有さない方式(アルゴリズム)を用いるコーデックが選択された場合に、CS網におけるビット誤りによる影響を抑える方法について説明する。
図12は、本実施の形態に係るUE100,102(端末)の構成を示すブロック図である。UE100,102は、受信部1200、送信部1202、接続先検出部1204、コーデック検出部1206、判断部1208、コマンド送信部1210、及び通知送受信部1212を有して構成される。なお、UE100,102は、図12に示す構成部の他に、端末が標準で有する機能も具備する。
受信部1200は、通信データ及びシグナリング等を受信する。受信部1200が受信するシグナリングには、例えば、CS網にハンドオーバした通信相手端末(又は、データ経路上の通信ノード)から、通信相手端末がCS網にハンドオーバしたこと、又は、コーデックのエンコード方式の制限が必要であることを通知するためのシグナリングが挙げられる。
送信部1202は、通信データ及びシグナリング等を送信する。送信部1202が送信するシグナリングには、例えば、PS網に在圏の通信相手端末に対して、自機がCS網にハンドオーバしたこと、又は、コーデックのエンコード方式の制限が必要であることを通知するためのシグナリングが挙げられる。
接続先検出部1204は、ハンドオーバなどによる自機の接続先網(PS網又はCS網)を検出する。
コーデック検出部1206は、接続先検出部1204で検出された接続先網で使用されるコーデックを検出する。
判断部1208は、接続先検出部1204で検出された接続先網及びコーデック検出部1206で検出されたコーデックに基づいて、自機及び通信相手端末で使用されるコーデックで用いるエンコード方式の制限が必要であるか否かを判断する。例えば、判断部1208は、自機がPS網からCS網へハンドオーバした際に、コーデック検出部1206で検出されたCS網で使用されるコーデックがビット誤り耐性を有さないエンコード方式を用いるコーデックである場合に、エンコード方式の制限が必要であると判断する。
コマンド送信部1210は、例えば、自機がCS網にハンドオーバし、判断部1208においてエンコード方式の制限が必要であると判断された場合、又は、自機がPS網に在圏し、後述する通知送受信部1212において通信相手端末(CS網に在圏)から接続先網の通知(又はエンコード方式の制限を通知するためのシグナリング)を受信した場合、接続先網で使用されるエンコード方式を制限するための内部コマンドを、エンコーダ(図示せず)に送信する。
通知送受信部1212は、受信部1200を介して通信相手端末から接続先網の通知(エンコード方式を制限するためのシグナリング)を受信する。また、通知送受信部1212は、例えば、自機がCS網にハンドオーバし、判断部1208においてエンコード方式の制限が必要であると判断された場合、PS網に在圏の通信相手端末に対して、自機がCS網にハンドオーバしたこと、又は、コーデックのエンコード方式の制限が必要であることを通知するためのシグナリングを生成する。このシグナリングは、送信部1202を介して通信相手端末に通知される。
次に、本実施の形態に係るUE100の動作について説明する。
例えば、図6及び図11において、UE100がeNBからCS網へのハンドオーバの命令(HO Command)を受け取り(ST611)、接続先をRNC/nodeBに変更した場合(ST613)、UE100の接続先検出部1204は、基地局情報などを用いて、接続先網がCS網に変更されたことを検出する。
また、図6及び図11において、UE100がRNC/nodeBに接続する過程において(例えば、ST613)、UE100のコーデック検出部1206は、CS網で使用するコーデックを検出する。UE100がCS網で使用するコーデックは、例えば、MGW/MSC110によってRNC/nodeBに通知されている(例えば、ST610)。なお、UE100がCS網で使用するコーデックの設定方法は、実施の形態1、2で説明した方法でもよく、他の方法でもよい。
例えば、UE100に対してCS網で使用されるコーデック及びコーデックモードが、EVSプライマリモードの9.6kbps及び13.2kbpsであるとする。上述したように、CS網は、伝送路でビット誤りが起こりうる網であり、EVSプライマリモードは、ビット誤りを想定していないコーデックモードである。よって、この場合、UE100の判断部1208は、接続先検出部1204で検出されたCS網の情報、及び、コーデック検出部1206で検出されたコーデックの情報に基づいて、ビット誤り耐性を有さない方式を用いるEVSプライマリモードの9.6kbps及び13.2kbpsが、ビット誤りが起こりうるCS網で使用されることを検出する。つまり、判断部1208は、CS網で使用するコーデックのエンコード方式の制限が必要であると判断する。
そして、UE100のコマンド送信部1210は、UE100のエンコーダに対して、ビット誤り耐性を有する方式のみを用いてエンコードするように、エンコード方式を制限する内部コマンドを送信する。
また、図6及び図11において、MGW/MSC110とIMSノード310との間でIMSのセッショントランスファー(initiation of session transfer)が行われる(ST612)。MGW/MSC110又はATGW(IMSノード310)のシグナリング生成部510,1010(図5及び図10を参照)は、UE102に対して、UE100がCS網に接続したことを通知するシグナリング、又は、使用しているコーデックのエンコード方式を制限すること(ビット誤り耐性を有する方式を用いてエンコードすること)を通知するシグナリングを生成し、送信する。
つまり、UE100においてエンコード方式の制限が必要であると判断された場合、UE100がCS網に接続したことを通知するシグナリング、又は、使用しているコーデックのエンコード方式を制限することを通知するためのシグナリングは、UE100及びUE102のデータ経路上に存在する通信ノードで生成され、UE102に送信される。
このシグナリングは、RTPペイロードヘッダに含まれてもよく、RTCPに含まれてもよい。例えば、シグナリングは、非特許文献9に記載されたRTPペイロードフォーマットヘッダのCMR(Codec Mode Request)バイトのフィールド又はビットに、通信相手(図6及び図11ではUE100)がCS網に接続したこと、又は、エンコード方式を制限することを通知するための機能を追加して用いてもよい。又は、このシグナリングの通知には、非特許文献10に記載のRTCP−APPのCMRに、通信相手がCS網に接続したこと、又は、エンコード方式を制限することを通知するための新たなフィールドを追加して用いてもよい。または、このシグナリングは、IMSシグナルリングなどの別の方法を用いて通知されてもよい。
また、UE100がCS網に接続したこと、又は、エンコード方式を制限することを通知するシグナリングが送信されるタイミングは、図6及び図11に示すモード変更リクエストの送信タイミングと同時でもよく、異なるタイミングでもよい。
また、このシグナリングには、CS網でEVSプライマリモードが使われていることが暗黙的又は明示的に含まれていてもよい。また、UE100がCS網に接続したこと、又は、エンコード方式を制限することを通知するシグナリングは、UE100からUE102に対して送信されてもよい。
一方で、CS網にハンドオーバしたUE100の通信相手端末であるUE102の通知送受信部1212は、UE100がCS網に接続したこと、又は、エンコード方式を制限することを通知するシグナリングを受け取ると、CS網に移動したUE100がEVSプライマリモードを使用して通信することを検出する。そして、UE102の判断部1208は、エンコード方式の制限が必要であると判断し、コマンド送信部1210は、UE102のエンコーダ(図示せず)に対して、ビット誤り耐性を有する方式のみを用いてエンコードするように、エンコード方式を制限する内部コマンドを送信する。
なお、上述したようにCS網でEVSプライマリモードを使用する際にビット誤り耐性を有する方式のみを用いてエンコードするように内部コマンドを送信する方式は、SRVCCハンドオーバ又はeSRVCCハンドオーバの時のみでなく、例えば、UE100が最初からCS網に接続している時に用いられていてもよい。また、UE100がCS網に接続していることをPS網に接続している通信相手(例えばUE102)に通知する方法は、SRVCCハンドオーバ又はeSRVCCハンドオーバの時のみでなく、例えば、UE100がCS網に接続し、UE102がPS網に接続している際の通信の開始時から用いられてもよい。
また、「ビット誤り耐性を有する方式」とは、EVS AMR−WB互換モードであってもよい。この場合、UE100において、接続先検出部1204がUE100のCS網への接続を検出し、コーデック検出部1206がCS網で使用するコーデックとしてEVSを検出した場合、コマンド送信部1210は、エンコーダに対して、エンコード方式をAMR−WB互換モードに変更するように内部コマンドを送信する。また、この場合のUE102への通知のためのシグナリングは、UE100がCS網にハンドオーバを行ったことを通知するものではなく、EVSプライマリモードをAMR−WB互換モードに切り替えるという切替要求でもよい。
この切替要求の通知には、非特許文献9に記載のRTPペイロードフォーマットヘッダのCMRバイトを用いてもよく、非特許文献10に記載のRTCP−APPのCMRを用いてもよい。または、この切替要求は、IMSシグナリングなどの別の方法を用いて通知されてもよい。また、切替要求が送信されるタイミングは、図6及び図11に示すモード変更リクエストの送信タイミングと同時でもよく、異なるタイミングでもよい。また、切替要求は、UE100からUE102に対して送信されてもよい。
以上のように、本実施の形態では、UE100,102は、CS網に接続されたUEがCS網で使用するコーデックとして、EVSプライマリモードのように、ビット誤り耐性を有さない方式(アルゴリズム)を用いるコーデックが設定された場合に、ビット誤り耐性を有さない方式(アルゴリズム)を用いるようにエンコーダに指示する。
このように、CS網で使用するコーデックで用いるエンコード方式を制限することにより、本実施の形態によれば、CS網に接続したUEがビット誤り耐性を有さない方式を用いるコーデックが設定された場合でも、CS網におけるビット誤りによる影響を抑えることができる。すなわち、CS網でEVSコーデックを利用した場合でも、伝送路で発生するビット誤りに対応して正しく復号が行われ、品質劣化を防ぐことができる。
よって、本実施の形態によれば、ビット誤りを生じる可能性のある網で使用される場合においても、品質の劣化を抑えて通信を継続させることができる。
なお、通信開始時のIMSによるセッションセットアップの際(例えば、図6及び図11のST601)、サービスを提供するオペレータ間で、使用するペイロードフォーマットに対するポリシが異なる場合が考えられる。このポリシは、例えば、非特許文献9に記載のEVSコーデックのRTPペイロードフォーマットにおける、コンパクトフォーマットとヘッダフルフォーマットの両方を用いる方式か、又はヘッダフルフォーマットのみを用いる方式かを表すポリシ、または、非特許文献8に記載のAMR又はAMR−WBコーデックのRTPペイロードフォーマットにおける、Bandwidth-Efficientモードを用いる方式か、Octet-Aligned Modeモードを用いる方式かを表すポリシを意味する。このペイロードフォーマットに関するポリシが異なる場合、IMSノード310は、ポリシの違いを許可し、例えばATGWなどのデータ経路上に存在するノードがペイロードフォーマットを変更(トランスフォーマット)してもよい。
以上、本開示の各実施の形態について説明した。
なお、上記各実施の形態では、ATCF/ATGW320、MSC/MGW110、SCC AS/CSCFをそれぞれ一つのノードとして説明した。しかし、ATCF/ATGW320、MSC/MGW110、SCC AS/CSCFは、互いにインタフェースによって接続される2つ以上の別々のノードで構成されてもよい。すなわち、ATCFとATGWとの間、MSCとMGWとの間、及び、SCC ASとCSCFとの間のそれぞれにおいて、上述した機能を複数のノードに分散させてもよい。
また、上記各実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、これに限らず、音楽、音響、画像等に関しても、本開示の一態様は適用可能である。
また、本開示の一態様は、上記各実施の形態に限定されず、種々変更して実施することが可能である。
また、上記各実施の形態では、本開示の一態様をハードウェアで構成する場合を例にとって説明したが、本開示はハードウェアとの連携においてソフトウェアでも実現することも可能である。
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。集積回路は、上記実施の形態の説明に用いた各機能ブロックを制御し、入力と出力を備えてもよい。これらは個別に1チップ化されてもよいし、一部又は全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)または、LSI内部の回路セルの接続若しくは設定を再構成可能なリコンフィギュラブル/プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
本開示の一態様は、UEのハンドオーバ先であるCS網でサポートしているコーデック/コーデックモードが、通信開始時のセッションセットアップにおいて折衝されたコーデック/コーデックモードと異なる場合でも、サービスオペレータのポリシ又はセッションセットアップにおいて折衝された内容から外れることなく、通信を継続することができる。また、CS網に接続したUEがビット誤り耐性を有さない方式を用いるコーデックを使用する場合でも、CS網におけるビット誤りによる影響を抑えた通信を行うことに有用である。
100,102 UE
200,202,204,206,300,302,304,306 シグナリング
110 MSC/MGW
310 IMSノード
320 ATCF/ATGW
500,1000,1200 受信部
502,1002,1202 送信部
504,1004 記憶部
506,1006,1208 判断部
508,1008 ポシリ参照部
510,1010 シグナリング生成部
1204 接続先検出部
1206 コーデック検出部
1210 コマンド送信部
1212 通知送受信部

Claims (12)

  1. 第1の網において通信を行う2つの端末のうち一方の端末が前記第1の網と異なる第2の網にハンドオーバした際に、前記2つの端末で使用されるコーデック及びコーデックモードを判断する通信ノードであって、
    前記第1の網における通信で使用しているコーデック及びコーデックモードを示す情報と、
    前記一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、
    前記第2の網がサポートしているコーデック及びコーデックモードを示す情報と、
    の共通部分を前記2つの端末で使用されるコーデック及びコーデックモードに設定する判断部と、
    設定された前記2つの端末で使用されるコーデック及びコーデックモードへの変更を前記2つの端末へ要求するためのシグナリングを生成する生成部と、
    を具備する通信ノード。
  2. 前記判断部は、前記共通部分が存在しない場合に、
    前記第1の網における通信で使用しているコーデックに、別のコーデックとの互換モードが存在し、かつ、前記一方の端末がサポートしているコーデック及び前記第2の網がサポートしているコーデックに、前記別のコーデックが含まれる場合、前記別のコーデック又は前記別のコーデックとの互換モードを、前記2つの端末で使用されるコーデック及びコーデックモードに設定する、
    請求項1に記載の通信ノード。
  3. 前記判断部は、サービスオペレータのポリシが存在する場合には前記ポリシに従って前記2つの端末で使用されるコーデック及びコーデックモードを設定し、前記ポリシが存在しない場合には前記共通部分を前記2つの端末で使用されるコーデック及びコーデックモードに設定する、
    請求項1又は2に記載の通信ノード。
  4. 第1の網において通信を行う2つの端末のうち、前記第1の網と異なる網にハンドオーバする端末であって、
    ハンドオーバによる接続先網を検出する接続先検出部と、
    前記接続先網で使用するコーデックを検出するコーデック検出部と、
    前記検出された接続先網と、前記検出されたコーデックとに基づいて、前記2つの端末で使用されるコーデックで用いるエンコード方式の制限が必要であるか否かを判断する判断部と、
    前記エンコード方式の制限が必要であると判断された場合、前記エンコード方式を制限するための内部コマンドをエンコーダに送信するコマンド送信部と、
    を具備する端末。
  5. 前記第1の網がパケット交換網であり、前記接続先網が回線交換網であり、
    前記判断部は、前記検出されたコーデックがビット誤り耐性を有さないエンコード方式を用いるコーデックである場合に、前記エンコード方式の制限が必要であると判断する、
    請求項4に記載の端末。
  6. 前記エンコード方式の制限が必要であると判断された場合、前記接続先網にハンドオーバしたこと、又は、前記エンコード方式の制限が必要であることを通信相手端末に通知するためのシグナリングを生成する生成部と、
    前記シグナリングを前記通信相手端末に送信する送信部と、を更に具備する、
    請求項4に記載の端末。
  7. 前記エンコード方式の制限が必要であると判断された場合、
    前記端末が前記接続先網にハンドオーバしたこと、又は、前記エンコード方式の制限が必要であることを通知するためのシグナリングは、前記2つの端末のデータ経路上に存在する通信ノードで生成され、前記端末の通信相手端末に送信される、
    請求項4に記載の端末。
  8. 前記シグナリングを受け取った前記通信相手端末は、前記エンコード方式を制限するための内部コマンドを、前記通信相手端末内のエンコーダに送信する、
    請求項6又は7に記載の端末。
  9. 前記シグナリングは、RTP(Real-time Transport Protocol)ペイロードヘッダに含まれる、
    請求項6から8の何れかに記載の端末。
  10. 前記シグナリングは、RTCP(Real-time Transport Protocol Control Protocol)に含まれる、
    請求項6から8の何れかに記載の端末。
  11. 第1の網において通信を行う2つの端末のうち一方の端末が前記第1の網と異なる第2の網にハンドオーバした際に、前記2つの端末で使用されるコーデック及びコーデックモードを判断する通信制御方法であって、
    前記第1の網における通信で使用しているコーデック及びコーデックモードを示す情報と、
    前記一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、
    前記第2の網がサポートしているコーデック及びコーデックモードを示す情報と、
    の共通部分を前記2つの端末で使用されるコーデック及びコーデックモードに設定し、
    設定された前記2つの端末で使用されるコーデック及びコーデックモードへの変更を前記2つの端末へ要求するためのシグナリングを生成する、
    通信制御方法。
  12. 第1の網において通信を行う2つの端末のうち、前記第1の網と異なる網にハンドオーバする端末における通信制御方法であって、
    ハンドオーバによる接続先網を検出し、
    前記接続先網で使用するコーデックを検出し、
    前記検出された接続先網と、前記検出されたコーデックとに基づいて、前記2つの端末で使用されるコーデックで用いるエンコード方式の制限が必要であるか否かを判断し、
    前記エンコード方式の制限が必要であると判断された場合、前記エンコード方式を制限するための内部コマンドをエンコーダに送信する、
    通信制御方法。
JP2017518732A 2015-05-20 2016-03-16 通信ノード、端末及び通信制御方法 Expired - Fee Related JP6787884B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2015102810 2015-05-20
JP2015102810 2015-05-20
PCT/JP2016/001495 WO2016185649A1 (ja) 2015-05-20 2016-03-16 通信ノード、端末及び通信制御方法

Publications (2)

Publication Number Publication Date
JPWO2016185649A1 true JPWO2016185649A1 (ja) 2018-03-08
JP6787884B2 JP6787884B2 (ja) 2020-11-18

Family

ID=57319790

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017518732A Expired - Fee Related JP6787884B2 (ja) 2015-05-20 2016-03-16 通信ノード、端末及び通信制御方法

Country Status (4)

Country Link
US (1) US10911988B2 (ja)
JP (1) JP6787884B2 (ja)
CN (1) CN107251610B (ja)
WO (1) WO2016185649A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10278100B1 (en) 2016-03-16 2019-04-30 Sprint Communications Company L.P. Long term evolution (LTE) mobility management entity (MME) management of an internet protocol multimedia subsystem (IMS) media session service level for a user equipment (UE)
MX2019013558A (es) 2017-05-18 2020-01-20 Fraunhofer-Gesellschaft zur Förderung der Angewandten Forschung Ev Dispositivo de red de gestion.
US10778729B2 (en) * 2017-11-07 2020-09-15 Verizon Patent And Licensing, Inc. Codec parameter adjustment based on call endpoint RF conditions in a wireless network
US11611909B2 (en) * 2018-09-07 2023-03-21 Apple Inc. Apparatus and method for signaling ran-assisted codec adaptation capabilities in IMS multimedia telephony sessions
JP7523267B2 (ja) 2020-07-10 2024-07-26 株式会社Nttドコモ 通信制御装置

Family Cites Families (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6856612B1 (en) * 1999-02-24 2005-02-15 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for call routing and codec negotiation in hybrid voice/data/internet/wireless systems
EP1312235B1 (en) * 2000-08-14 2010-10-13 Nokia Siemens Networks Oy Communication system and method providing a mode selection procedure
KR100659197B1 (ko) * 2000-09-05 2006-12-21 유티스타콤코리아 유한회사 통합 인터넷 프로토콜 망에서의 보코딩 방법
US6879600B1 (en) * 2002-06-03 2005-04-12 Sprint Spectrum, L.P. Method and system for intersystem wireless communication session arbitration
US20040131051A1 (en) * 2002-09-06 2004-07-08 Rafi Rabipour Methods and apparatus for data communication
US7443879B2 (en) * 2002-11-14 2008-10-28 Lucent Technologies Inc. Communication between user agents through employment of codec format unsupported by one of the user agents
US7680143B2 (en) * 2002-12-12 2010-03-16 Rpx Corporation Methods and apparatus for combining session acceleration techniques for media oriented negotiation acceleration
WO2004064353A1 (en) * 2003-01-09 2004-07-29 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for codec selection
US8254372B2 (en) * 2003-02-21 2012-08-28 Genband Us Llc Data communication apparatus and method
US7305230B2 (en) * 2003-07-01 2007-12-04 Nokia Corporation System, apparatus, and method for providing a mobile server
EP2549829A3 (en) * 2004-03-04 2014-10-15 Telefonaktiebolaget L M Ericsson (publ) Method for transmitting data in a telecommunications network and device utilising that method
US7602901B1 (en) * 2004-07-21 2009-10-13 Sprint Spectrum L.P. System and method for providing calling-party identification and/or calling-party or called-party ringback services
US8700729B2 (en) * 2005-01-21 2014-04-15 Robin Dua Method and apparatus for managing credentials through a wireless network
CN101218774B (zh) * 2005-06-15 2012-10-10 艾利森电话股份有限公司 通过因特网协议网络的自适应移动电话语音传输
US20070011277A1 (en) * 2005-07-11 2007-01-11 Ralph Neff System and method for transferring data
US7974270B2 (en) * 2005-09-09 2011-07-05 Kineto Wireless, Inc. Media route optimization in network communications
US20100203584A1 (en) * 2005-09-20 2010-08-12 Hideharu Taira Host Cells Used For Production of Recombinant Protein
DE102005050588B4 (de) * 2005-10-21 2010-07-08 Siemens Ag Signalisierung bezüglich des Aufbaus von H.324 Videotelefonie zwischen einer Mediagateway und einem Controller
PL1954769T3 (pl) * 2005-11-02 2013-03-29 Sun Chemical Corp Farby do drukowania fleksograficznego i grawiurowego dla nietkanych podłoży
US7835346B2 (en) * 2006-01-17 2010-11-16 Genband Us Llc Methods, systems, and computer program products for providing transcoder free operation (TrFO) and interworking between unlicensed mobile access (UMA) and universal mobile telecommunications system (UMTS) call legs using a media gateway
US7787377B2 (en) * 2006-02-03 2010-08-31 Telefonaktiebolaget Lm Ericsson (Publ) Selective redundancy for Voice over Internet transmissions
EP1982485B1 (en) * 2006-02-10 2019-07-24 III Holdings 2, LLC System and method for connecting mobile devices
KR101419959B1 (ko) * 2006-08-21 2014-07-16 텔레폰악티에볼라겟엘엠에릭슨(펍) 인코딩된 미디어의 전송을 적응시키는 방법 및 장치
RU2431239C2 (ru) * 2007-02-02 2011-10-10 Хуавэй Текнолоджиз Ко., Лтд. Способ, устройство и система для установления канала-носителя в gsm-сети
KR101167523B1 (ko) * 2008-01-17 2012-07-20 노키아 코포레이션 무선 시스템에서의 적응적 멀티-레이트 코덱 비트 레이트 제어
US20090270098A1 (en) * 2008-04-29 2009-10-29 Gallagher Michael D Method and Apparatus for User Equipment Registration in a Voice over Long Term Evolution via Generic Access
US20100172332A1 (en) * 2009-01-07 2010-07-08 Rao Anil M Method and apparatus for controlling a vocoder mode in a packet switched voice wirelss network
KR101523590B1 (ko) * 2009-01-09 2015-05-29 한국전자통신연구원 통합 인터넷 프로토콜망의 코덱 모드 제어방법 및 단말기
US9007914B2 (en) * 2009-09-30 2015-04-14 Qualcomm Incorporated Methods and apparatus for enabling rate adaptation across network configurations
WO2011095221A1 (en) * 2010-02-05 2011-08-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and network node for monitoring a quality of media transfer in a session initiation protocol based voice over internet protocol communications network
US8548460B2 (en) * 2010-05-25 2013-10-01 Qualcomm Incorporated Codec deployment using in-band signals
EP2640052B1 (en) * 2010-11-10 2019-07-24 Panasonic Intellectual Property Corporation of America Terminal and coding mode selection method
JP5947294B2 (ja) * 2011-06-09 2016-07-06 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 通信端末装置、ネットワークノード及び通信方法
KR101843052B1 (ko) * 2011-10-25 2018-03-29 삼성전자주식회사 무선통신 시스템에서 서로 다른 망들을 이용한 음성 호의 연속성 제공을 위한 장치 및 방법
US9848339B2 (en) * 2011-11-07 2017-12-19 Qualcomm Incorporated Voice service solutions for flexible bandwidth systems
CN102448135A (zh) * 2011-11-17 2012-05-09 中兴通讯股份有限公司 一种单无线语音连续切换的方法及系统
EP2787765B1 (en) * 2011-11-30 2019-03-06 Panasonic Intellectual Property Corporation of America Network node and communication method
EP2839695B1 (en) * 2012-04-17 2016-06-08 Telefonaktiebolaget LM Ericsson (publ) Srvcc handover of calls between access networks with active codec selection
WO2014030714A1 (ja) * 2012-08-24 2014-02-27 日本電気株式会社 リモート通信システム、サーバ装置、リモート通信方法、および、プログラム
US8483699B1 (en) * 2012-08-29 2013-07-09 Sprint Spectrum L.P. Codec selection for wireless communication
US8908605B1 (en) * 2012-10-09 2014-12-09 Sprint Spectrum L.P. Coordination of codec assignment and radio configuration in wireless communications
US9526037B2 (en) * 2013-02-04 2016-12-20 Apple Inc. SRVCC handover indication for remote party to voice call
US9338718B2 (en) * 2013-03-14 2016-05-10 Apple Inc. Voice call resumption on a legacy network
US9386563B1 (en) * 2013-04-11 2016-07-05 Sprint Spectrum L.P. Coordination of codec consistency based on cross-carrier assignment
EP3038104B1 (en) * 2013-08-22 2018-12-19 Panasonic Intellectual Property Corporation of America Speech coding device and method for same
US9467480B2 (en) * 2013-09-16 2016-10-11 Qualcomm Incorporated Selectively multiplexing incoming WebRTC traffic and/or de-multiplexing outgoing WebRTC traffic by a client-based WebRTC proxy on behalf of a WebRTC multimedia client application
US9712425B2 (en) * 2014-05-23 2017-07-18 Telefonaktiebolaget Lm Ericsson (Publ) Maintaining optimal media routing
US20160204908A1 (en) * 2015-01-14 2016-07-14 Qualcomm Incorporated Adaptive multi-rate partial decode

Also Published As

Publication number Publication date
WO2016185649A1 (ja) 2016-11-24
CN107251610A (zh) 2017-10-13
US10911988B2 (en) 2021-02-02
US20180041924A1 (en) 2018-02-08
JP6787884B2 (ja) 2020-11-18
CN107251610B (zh) 2020-09-25

Similar Documents

Publication Publication Date Title
JP6647364B2 (ja) 通信端末装置、通信方法及び集積回路
JP6434601B2 (ja) ネットワークノード及び通信方法
US10911988B2 (en) Communication node, terminal, and communication control method
JP6420328B2 (ja) ネットワークノード及びシグナリング処理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190129

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20190717

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20191114

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200324

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200526

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20201027

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20201029

R150 Certificate of patent or registration of utility model

Ref document number: 6787884

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees