JP5947294B2 - 通信端末装置、ネットワークノード及び通信方法 - Google Patents

通信端末装置、ネットワークノード及び通信方法 Download PDF

Info

Publication number
JP5947294B2
JP5947294B2 JP2013519368A JP2013519368A JP5947294B2 JP 5947294 B2 JP5947294 B2 JP 5947294B2 JP 2013519368 A JP2013519368 A JP 2013519368A JP 2013519368 A JP2013519368 A JP 2013519368A JP 5947294 B2 JP5947294 B2 JP 5947294B2
Authority
JP
Japan
Prior art keywords
codec
bandwidth
signaling
communication
network
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.)
Active
Application number
JP2013519368A
Other languages
English (en)
Other versions
JPWO2012169134A1 (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 JPWO2012169134A1 publication Critical patent/JPWO2012169134A1/ja
Application granted granted Critical
Publication of JP5947294B2 publication Critical patent/JP5947294B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/13Cell handover without a predetermined boundary, e.g. virtual cells
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/04Wireless resource allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • H04W76/22Manipulation of transport tunnels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/006Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H04M7/0072Speech codec negotiation
    • 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)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

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において、移動通信端末(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/MGW経由でRNC/nodeBとの間でシグナリングをやり取りする(図1に示すシグナリング200。図2に示すステップ(以下、「ST」という)200)。ST200において、nodeBとMSC/MGWとの間にCS網でのデータ経路が準備され、準備が終わると、MMEからe−nodeB経由で、UE100に対し、UTRAN(CS網)側にハンドオーバするよう命令が出される。
ST200の処理と同時に、MSC/MGWは、CSCF/SCC AS経由でUE102とシグナリングをやり取りする(図1に示すシグナリング202。図2に示すST202)。これにより、UE102の通話データの送受信先を、UE100からMSC/MGWに切り替えるよう命令が出され、Path Bが確立される。
UE100は、UTRANにハンドオーバした後、RNC/nodeB経由でMSC/MGWとシグナリングをやり取りする(図1に示すシグナリング204。図2に示すST204)。これにより、Path Cが確立される。
Path C確立後、MSC/MGWは、MME経由でP−GW/S−GWとシグナリングをやり取りする(図1に示すシグナリング206。図2に示すST206)。これにより、Path Aは削除される。
以上、SRVCCハンドオーバの動作について説明した。
また、SRVCCを改良し、データ経路切替にかかる時間を短縮する方式として、非特許文献3に記載の、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/ATGW1120)として表しているが、これらは別々のノードとして表してもよい。
図3において、UE100及びUE102は、最初PS網にそれぞれ接続されているとする(ただし、UE102側の無線アクセス網、基地局及びPS網は図示せず)。つまり、UE100とUE102とでVoLTE通話が行われているとする。このとき、通話の途中でUE100がCS網にハンドオーバ(HO:Hand Over)することを仮定する。
図3の実線で示されたPath A、Path B、Path C及びPath Dは、通話データが通る経路を示す。また、図3の破線で示された1100、1102、1104及び1106は、eSRVCCハンドオーバ処理におけるシグナリングが通る経路を示す。
図4は、eSRVCCハンドオーバの動作を示すシーケンスチャートである。UE100及びUE102は最初PS網(e−UTRAN)にそれぞれ接続されている。eSRVCCハンドオーバを実現するシステムでは、ATCF/ATGW1120において、ATCFはIMSのシグナリング(IMSシグナリング)をアンカーし、ATGWは通話データをアンカーする。つまり、UE100とUE102との間の通話開始時において、通話開始のIMSシグナリングはATCFで中継され、ATCFがATGWでの通話データのアンカーが必要と判断した場合、通話データのアンカーポイントとしてATGWが割り当てられる。これにより、UE100とUE102との間の通話データは、Path A及びPath Bを通って送受信される。
UE100がe−UTRANのカバーエリアから遠ざかろうとすると、e−nodeBは、これを検知し、MME、MSC/MGW経由でRNC/nodeBとの間でシグナリングをやり取りする(図3に示すシグナリング1100。図4に示すST1100)。ST1100において、nodeBとMSC/MGWとの間にCS網でのデータ経路が準備され、準備が終わると、MMEからe−nodeB経由で、UE100に対し、UTRAN(CS網)側にハンドオーバするよう命令が出される。
ST1100の処理と同時に、MSC/MGWは、ATCFにシグナリングを送る。これによりATCFからATGWに経路切替の指示が出され、ATGWの通話データ送受信先がUE100からMSC/MGWに切り替わる(図3に示すシグナリング1102。図4に示すST1102)。すなわち、Path Cが確立される。また、ATGWへの経路切替処理が完了すると、ATCFは、SCC−ASに通知シグナリングを送信する(図3に示すシグナリング1102。図4に示すST1102)。
UE100は、UTRANにハンドオーバした後、RNC/nodeB経由でMSC/MGWとシグナリングをやり取りする(図3に示すシグナリング1104。図4に示すST1104)。これにより、Path Dが確立される。
Path D確立後、MSC/MGWは、MME経由でP−GW/S−GWとシグナリングをやり取りする(図3に示すシグナリング1106。図4に示すST1106)。これにより、Path Bは削除される。
以上、eSRVCCハンドーバの動作について説明した。
CS網で利用される音声コーデックとして、狭帯域(NB:Narrowband)コーデックであるAMR(Adaptive Multi-Rate)コーデック及び広帯域(WB:Wideband)コーデックであるAMR−WBコーデック等が広く用いられている。AMR及びAMR−WBは、パケット交換方式で利用可能であるため、PS網(VoLTE)での利用も考えられている。
AMR及びAMR−WBは、サポートしているビットレートがそれぞれ異なる。更に、AMR及びAMR−WBがPS網で用いられる場合には、非特許文献2に記載の通り、RTP(Real-time Transport Protocol)ペイロードフォーマットで用いられる、ビットレートに対する番号付け(Frame Type Index)が双方でオーバラップしている。このため、CS網での利用においてもPS網での利用においても、セッション開始時にAMR若しくはAMR−WBのどちらを用いるかを決める必要がある。つまり、セッションの再折衝無しでAMRとAMR−WBとを切り替えることは不可能である。
尚、従来技術において、狭帯域コーデックとは、一般的に300Hz〜3.4kHzの帯域幅で、8kHzでサンプリングされるコーデックである。また、広帯域コーデックとは、一般的に50Hz〜7kHzの帯域幅で、16kHzでサンプリングされるコーデックである。また、超広帯域(SWB:Super Wideband)コーデックとは、一般的に50Hz〜14kHzの帯域幅で、32kHzでサンプリングされるコーデックである。
3GPP TS23.216 v9.6.0 "Single Radio Voice Call Continuity (SRVCC)" IETF RFC 4867、 "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs" 3GPP TS23.237 v11.0.0 "IP Multimedia Subsystem (IMS) Service Continuity" Takashi Koshimizu and Katsutoshi Noshida, "Audio Viedo Callof Single Radio Voice Call Continuity", 2011年電子情報通信学会総合大会,B-6-77 西田克利,輿水敬,「音声呼のIMS−回線交換間ハンドオーバ方式の改善提案移動機能力に基づく在圏アンカー型SRVCC方式」,信学技報 NS2010-178,pp85-90
図1または図3において、UE100がPS網からCS網にハンドオーバした際、PS網で使用していたコーデックがCS網でサポートされていない場合には、UE100で使用されるコーデックは、CS網でサポートされているコーデックに変更される。UE100のコーデックに変更が生じた場合、UE100とUE102との通話継続を可能にするためには、次の2つの方法が考えられる。1つ目の方法は、UE102で使用されるコーデックをUE100の変更後のコーデックと同じものに変更する方法である。2つ目の方法は、MSC/MGWにおいてトランスコーディングを行う方法である。
前者の方法では、UE102のコーデックを変更するためのシグナリングに時間がかかり、通話が途切れる時間が長くなるので好ましくない。更に、eSRVCCハンドオーバでは、UE100のハンドオーバの際の経路切替のためのシグナリングがATCFで終端するため、UE102のコーデックを変更するためのシグナリングを送ることすらできない。すなわち、eSRVCCハンドオーバでは、既存のシグナリングを使ってUE102のコーデックを変更することができない。
よって、後者のトランスコーディングの方法が比較的好ましいと考えられる。しかしながら、トランスコーディングを行った場合、特にコーデックの帯域幅(コーデックの入出力となる信号の帯域幅)が異なる場合には、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする際、通話品質の劣化が生じてしまう。
本発明の目的は、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる通信端末装置、ネットワークノード及通信方法を提供することである。
本発明の一態様に係るネットワークノードは、異なるコーデックを使用する2つの端末間の通信に対してトランスコーディングを行うネットワークノードであって、前記2つの端末がそれぞれ使用するコーデックを検出する検出手段と、前記検出手段での検出結果に基づいて、前記2つの端末のうちいずれか一方の端末が使用するコーデックの変更を検出した場合、前記一方の端末以外の他方の端末の第1のコーデック、及び、前記一方の端末の変更後の第2のコーデックを用いて、前記第1のコーデックの第1の帯域幅の制限を行うか否かを判断する判断手段と、前記判断手段において前記第1の帯域幅を制限すると判断された場合、前記第1の帯域幅を制限させるためのシグナリングを、前記他方の端末へ送信する送信手段と、を具備する構成を採る。
本発明の一態様に係る端末は、異なるコーデックを使用する端末間の通信に対して、端末間に位置するネットワークノードでトランスコーディングが行われる通信システムで用いられる端末であって、前記端末と、前記端末の通信相手である相手端末との間の通信に使用する第1のコーデックを折衝する折衝手段と、折衝された前記第1のコーデックに対して、前記端末においてエンコードされる入力信号の第1の帯域幅を決定する決定手段と、前記ネットワークノードから通知される、前記第1の帯域幅を制限させるためのシグナリングに従って、前記決定手段で決定された前記第1の帯域幅の変更を制御する変更手段と、を具備する構成を採る。
本発明の一態様に係る帯域幅変更判断方法は、異なるコーデックを使用する2つの端末間の通信に対してトランスコーディングを行うネットワークノードにおける帯域幅変更判断方法であって、前記2つの端末がそれぞれ使用するコーデックを検出し、検出結果に基づいて、前記2つの端末のうちいずれか一方の端末が使用するコーデックの変更を検出した場合、前記一方の端末以外の他方の端末の第1のコーデック、及び、前記一方の端末の変更後の第2のコーデックを用いて、前記第1のコーデックの第1の帯域幅の制限を行うか否かを判断し、前記第1の帯域幅を制限すると判断された場合、前記第1の帯域幅を制限させるためのシグナリングを、前記他方の端末へ送信する。
本発明の一態様に係る帯域幅変更方法は、異なるコーデックを使用する端末間の通信に対して、端末間に位置するネットワークノードでトランスコーディングが行われる通信システムで用いられる端末における帯域幅変更方法であって、前記端末と、前記端末の通信相手である相手端末との間の通信に使用する第1のコーデックを折衝し、折衝された前記第1のコーデックに対して、前記端末においてエンコードされる入力信号の第1の帯域幅を選択し、前記ネットワークノードから通知される、前記第1の帯域幅を制限させるためのシグナリングに従って、前記第1の帯域幅の変更を制御し、前記第1の帯域幅の変更の制御に従って、前記第1の帯域幅を決定する。
本発明によれば、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる。
3GPPの移動通信ネットワークの一部を示す構成図 SRVCCハンドオーバの動作を示すシーケンスチャート eSRVCCを可能にする、3GPPの移動通信ネットワークの一部を示す構成図 eSRVCCハンドオーバの動作を示すシーケンスチャート 本発明の実施の形態1に係る移動通信ネットワークの一部を示す構成図 本発明の実施の形態1に係るネットワークノード(MSC/MGW)の構成を示すブロック図 本発明の実施の形態1に係るMSC/MGWの変更判断部における判断方法の一例を示すフローチャート 本発明の実施の形態1に係る端末(UE)の構成を示すブロック図 本発明の実施の形態1に係るコーデック折衝に用いるSDPの一例を示す図 本発明の実施の形態1に係る動作を示すシーケンスチャート 本発明の実施の形態1に係る帯域制限依頼メッセージの一例を示す図 本発明の実施の形態2に係る端末(UE)の構成を示すブロック図 本発明の実施の形態3に係る移動通信ネットワークの一部を示す構成図 本発明の実施の形態3に係るネットワークノード(MSC/MGW)の構成を示すブロック図 本発明の実施の形態3に係る動作を示すシーケンスチャート 本発明の実施の形態3に係るMSC/MGWのコーデック選択部におけるコーデックの選択方法の一例を示すフローチャート 本発明の実施の形態3のバリエーションに係る動作を示すシーケンスチャート 本発明の実施の形態4に係る移動通信ネットワークの一部を示す構成図 本発明の実施の形態4に係るネットワークノード(ATCF/ATGW、MSC/MGW)の構成を示すブロック図 本発明の実施の形態4に係る端末(UE)の構成を示すブロック図 本発明の実施の形態4に係る動作を示すシーケンスチャート
以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
以下の説明では、「帯域幅」とはコーデックの入出力となる信号の帯域幅のことを指す。
また、以下の説明では、「帯域幅の指定が必ずしも必要の無いコーデック」とは、エンコードされる入力信号の帯域幅を、セッションの再折衝無しで切り替えることが可能なコーデックを意味する。例えば、EVS(Enhanced Voice Services)コーデックの非互換(non interoperable)モードは、PS網のみで利用される上、サポートされるビットレートは、どの帯域幅においても共通である(「3GPP TSG SA WG4 S4-110539 “EVS Permanent Document #4 (EVS-4): EVS design constraints”」参照)。このため、EVSコーデックの非互換モードでは、ナイキスト周波数(Nyquist frequency:サンプリング周波数の1/2)以下の帯域幅であれば、セッション途中でも、エンコードされる入力信号の帯域幅を自由に変更できるよう設計することが可能である。よって、セッションの開始から終了までにおける帯域幅の指定が必ずしも必要ではない。この場合、エンコーダは、例えば入力信号の特性(例えば入力信号の周波数特性及び入力信号を分析して得られるパラメータ等)、又は、エンコーディングビットレートに応じて、エンコードされる入力信号の帯域幅を設定又は変更する。
(実施の形態1)
図5は、本発明の実施の形態1に係る移動通信ネットワークの一部を示す構成である。なお、図5において、図1と同一構成である部分には同一の符号を付してその説明を省略する。図5では、図1と比較して、UE100、102及びMSC/MGW300の動作が異なる。
まず、図5に示すMSC/MGW300について説明する。MSC/MGW300は、異なるコーデックを使用する2つの端末間の通信に対してトランスコーディングを行う。
図6は、本実施の形態に係るMSC/MGW300(ネットワークノード)の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図6では、本発明と密接に関連する帯域制限(帯域変更)処理に関わる主な構成部(例えば、図5に示すST402〜406(後述する)に関わる構成部)を示す。
図6に示すMSC/MGW300において、受信部600は、通話データ(以下、通信データとする)、シグナリング等を受信する。例えば、受信部600は、UE100及びUE102からそれぞれ送信されるシグナリング(例えば、図1に示すシグナリング202,204)を受信すると、受信したシグナリングを、コーデック検出部604及びコーデック帯域幅検出部606に出力する。
送信部602は、通信データ、シグナリング等を送信する。例えば、送信部602は、シグナリング生成部610から出力されるシグナリングをUE102へ通知する。
コーデック検出部604は、受信部600から入力されるUE100及びUE102からのシグナリング、通信データ等に基づいて、UE100及びUE102がそれぞれ使用するコーデックを検出する。そして、コーデック検出部604は、検出したコーデックを示す情報(検出結果)を変更判断部608に出力する。
コーデック帯域幅検出部606は、受信部600から入力されるUE100及びUE102からのシグナリング、通信データ等に基づいて、UE100及びUE102がそれぞれ使用するコーデックの帯域幅を検出する。そして、コーデック帯域幅検出部606は、検出したコーデックの帯域幅を示す情報(検出結果)を、変更判断部608に出力する。
変更判断部608は、コーデック検出部604から入力される情報に示されるコーデック、及び、コーデック帯域幅検出部606から入力される情報に示されるコーデックの帯域幅に基づいて、UE102へのエンコードされる入力信号の帯域幅制限が可能であるか、及び、帯域幅制限が必要であるかを判断する。例えば、変更判断部608は、コーデック検出部604での検出結果に基づいて、2つの端末(UE100及びUE102)のうち一方のUE100が使用するコーデックの変更を検出した場合、他方のUE102のコーデック、及び、UE100の変更後のコーデックを用いて、UE102のコーデックの帯域幅の制限を行うか否かを判断する。変更判断部608は、判断結果をシグナリング生成部610に出力する。なお、変更判断部608における帯域幅の変更判断処理の詳細については後述する。
シグナリング生成部610は、変更判断部608でUE102へのエンコードされる入力信号の帯域幅制限が可能であり、かつ、帯域幅制限が必要であると判断された場合、UE102でエンコードされる入力信号の帯域幅の制限を、UE102に対して依頼するシグナリングを生成する。帯域幅制限を依頼するシグナリングには、例えば、UE100の変更後の帯域幅を示す情報を含めてもよい。シグナリング生成部610は、生成したシグナリングを、送信部602を介して、UE102へ送信する。このようにして、変更判断部608においてUE102のコーデックの帯域幅を制限すると判断された場合、帯域幅を制限させるためのシグナリングが、送信部602を介して、UE102へ送信される。
トランスコーディング部612は、UE100及びUE102がそれぞれ異なるコーデックを使用する場合、UE100からUE102への通信データ、及び、UE102からUE100への通信データに対してトランスコーディングを行う。
次いで、図7を用いて、MSC/MGW300の変更判断部608における帯域幅の変更判断処理の詳細について説明する。
図7に示すST800において、変更判断部608は、コーデック検出部604での検出結果(検出されるコーデック)に基づいて、UE100のコーデックが変更されたか否かを判断する。
UE100のコーデックが変更された場合(ST800:Yes)、ST802において、変更判断部608は、コーデック検出部604での検出結果に基づいて、UE102で使用されているコーデックが、コーデックAのように、帯域幅の指定不要なコーデックであるか否かを判断する。
UE102で使われているコーデックが帯域幅の指定不要なコーデックである場合(ST802:Yes)、ST804において、変更判断部608は、コーデック帯域幅検出部606での検出結果に基づいて、UE100の変更後のコーデックの帯域幅が、UE102が現在使用しているコーデックの最大帯域幅よりも狭いか否かを判断する。
UE100の変更後のコーデックの帯域幅が、UE102が現在使用しているコーデックの最大帯域幅よりも狭い場合(ST804:Yes)、ST806において、変更判断部608は、UE102へのエンコードされる入力信号の帯域幅の制限が可能かつ必要であると判断する。例えば、変更判断部608は、UE102のコーデックの帯域幅を、UE100の変更後のコーデックの帯域幅に制限(変更)すると判断する。
一方、UE100のコーデックが変更されていない場合(ST800:No)、UE102で使われているコーデックが、帯域幅の指定不要なコーデックではない場合(ST802:No)、又は、UE100の変更後のコーデックの帯域幅が、UE102が現在使用しているコーデックの最大帯域幅以上の場合(ST804:No)、ST808において、変更判断部608は、UE102への帯域制限は行わないと判断する。
このようにして、具体的には、MSC/MGW300は、一方のUEのコーデックの変更が検出された場合、他方のUEのコーデックが帯域幅の指定不要なコーデックであるか否かを判断することで、他方のUEのコーデックの帯域幅を制限(変更)することが可能か否かを判断する。また、MSC/MGW300は、一方のUEの変更後のコーデックの帯域幅が、他方のUEのコーデックの最大帯域幅よりも狭いか否かを判断することで、他方のUEのコーデックの帯域幅の制限(変更)が必要であるか否かを判断する。
次に、図5に示すUE100,102について説明する。
図8は、本実施の形態に係るUE100,102(端末)の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図8では、本発明と密接に関連する帯域制限処理に関わる主な構成部(例えば、図5に示すST400〜406(後述する)に関わる構成部)を示す。
図8に示すUE100,102において、受信部700は、通信データ及びシグナリング等を受信する。例えば、受信部700は、MSC/MGW300から送信されるシグナリング(例えば、図1に示すシグナリング202又は204)を受信すると、受信したシグナリングを、コーデック折衝部704及びシグナリング解析部710に出力する。
送信部702は、通信データ及びシグナリング(例えば、図1に示すシグナリング202又は204)等を送信する。
コーデック折衝部704は、端末(ここではUE100とUE102)間の通信に使用するコーデックを折衝する。具体的には、コーデック折衝部704は、SDP(Session Description Protocol)オファー又はSDPアンサーを作成し、コーデック折衝を行う。また、UE(図5ではUE100)がCS網に移動した場合には、当該UEのコーデック折衝部704は、CS網での折衝方法に基づき、コーデック折衝を行う。コーデック折衝部704は、コーディング折衝の結果をコーデック選択部706に出力する。
図9は、本発明の実施の形態におけるコーデック折衝に用いるSDPの一例を示す。発呼側UEは、帯域幅の指定が必ずしも必要の無いコーデック(以下、コーデックAという)をサポートしている場合、コーデックAに対し、サンプリング周波数のみ指定し、帯域幅の指定はせずにSDPオファーを生成する。例えば、図9では、発呼側UEが生成するSDPオファー(SDP offer)には、従来のWBコーデックであるAMR−WBコーデック(例えば、帯域幅:50Hz〜7kHz、サンプリング周波数:16000)、従来のNBコーデックであるAMRコーデック(例えば、帯域幅:300Hz〜3.4kHz、サンプリング周波数:8000)、及び、帯域幅の指定不要なコーデックA(サンプリング周波数:32000)が記載されている。
また、着呼側UEは、自らがコーデックAをサポートしている場合、帯域幅の指定が無く、コーデックAのサンプリング周波数のみ指定された条件を受け入れ(図9に示すコーデックAを選択し)、SDPアンサー(SDP answer)を生成する。なお、コーデックAは前述のEVSコーデックの非互換モードであってもよい。ここで、コーデックAのサンプリング周波数32000がサポートしている最大の帯域幅は、SWB(Super Wideband)相当であり、エンコーダはこの帯域幅内においては、セッション途中でも、入力信号の特性又はエンコーディングビットレートに応じて、帯域幅を自由に変更することが可能であるとする。
コーデック選択部706は、コーデック折衝部704により折衝されたコーデックを選択し、選択したコーデックを示す情報を帯域幅決定部708に出力する。
帯域幅決定部708は、コーデック選択部706で選択されたコーデックに対して、自端末においてエンコードされる入力信号の帯域幅を決定する。例えば、帯域幅決定部708は、コーデック選択部706により選択されたコーデックの帯域幅が一定である場合、当該帯域幅を選択する。一方、帯域幅決定部708は、コーデック選択部706により選択されたコーデックの帯域幅がコーデックAのように帯域幅を1セッションの中で変更できる場合には、エンコードされる入力信号の帯域幅をフレーム毎に決定する。帯域幅決定部708は、例えば、エンコーディングビットレート、入力信号特性、又は、外部シグナリングによる帯域幅制限の依頼等に応じて、エンコードされる入力信号の帯域幅をフレーム毎に決定する。より詳細には、帯域幅決定部708は、例えば、コーデックモード変更部712からコーデックの帯域幅の制限(変更)を依頼されていることが通知されると、エンコードされる入力信号の帯域幅を、依頼されている帯域幅に制限(変更)する。
シグナリング解析部710は、受信部700から入力されるシグナリングを解析する。シグナリングには、例えば、MSC/MGW300からの帯域幅の制限を依頼するシグナリング(帯域幅を制限させるためのシグナリング)が含まれる。シグナリング解析部710は、シグナリング解析の結果を、コーデックモード変更部712に通知する。
コーデックモード変更部712は、シグナリング解析部710から入力されるシグナリング解析結果が、コーデックの帯域幅の制限(変更)を依頼するシグナリングの場合、エンコードされる入力信号の帯域幅を制限(変更)することを決定し、その旨を帯域幅決定部708に通知する。すなわち、コーデックモード変更部712は、MSC/MGW300から通知される、コーデックの帯域幅を制限させるためのシグナリングに従って、帯域幅決定部708で決定された帯域幅の変更を制御する。
なお、シグナリング解析部710は、他の外部シグナリングを解析し、その解析結果をコーデックモード変更部712に通知してもよい。例えばシグナリング解析部710は、上述したRTCP−APPを解析し、その解析結果(例えばエンコーディングビットレートの変更依頼)を、コーデックモード変更部712に通知してもよい。この場合、コーデックモード変更部712は、エンコーディングビットレートを決定すると、決定したエンコーディングビットレートを、帯域幅決定部708に通知する。そして、帯域幅決定部708は、決定されたエンコーディングビットレートに応じて、帯域幅を決定する。
次に、本実施の形態におけるUE100,102、及び、MSC/MGW300の動作の一例について説明する。
図10は、図5に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。なお、図10において、図2と同一動作である部分には同一の符号を付してその説明を省略する。
以下の説明では、図5において、現在、UE100及びUE102の双方ともにe−UTRAN等のVoLTE通話サービスを可能とする無線アクセス網に接続しているとする(ただし、UE102側の無線アクセス網、基地局、PS網は図示せず)。つまり、図5に示すUE100とUE102との間でVoLTE通話を開始する。
通話開始の際、UE100とUE102との間で使用するコーデックの折衝が行われる(例えば、「3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS);Multimedia Telephony; Media Handling and interaction”」参照)。例えば、UE100及びUE102(コーデック折衝部704)は、帯域幅の指定が必ずしも必要の無いコーデックに対して、当該コーデックの折衝を帯域幅指定無しで行う(図5及び図10に示すST400)。
次いで、図5に示すように、UE100がSRVCCによるハンドオーバを行い、UTRANに移動したとする。つまり、UE100がPS網からCS網に移動したとする。
この場合、図10のST204のプロセスの中で、UE100(コーデック折衝部704)とMSC/MGW300との間においてCS網で使用するコーデックが再折衝される。ここでは、例えば、UE100に対してAMRコーデックを利用するよう折衝され、UE100が使用するコーデックの帯域幅がNBに制限されたと仮定する(図5及び図10に示すST402)。
また、MSC/MGW300(コーデック検出部604及びコーデック帯域幅検出部606)は、図10のST202のプロセスにより、UE102が使用しているコーデックがコーデックAであり、最大帯域幅がSWBであることを検出する。
また、MSC/MGW300(コーデック検出部604及びコーデック帯域幅検出部606)は、図10のST204のプロセスにより、UE100で使用されるコーデックがAMRになり、帯域幅がNBに制限されたことを検出する。
MSC/MGW300(変更判断部608)は、UE102へのエンコードされる入力信号の帯域幅制限が可能であるか、及び、帯域幅制限が必要であるかを判断する。ここでは、UE100のコーデックが変更され(図7に示すST800:Yes)、UE102のコーデックがコーデックAであり(図7に示すST802:Yes)、かつ、UE100のAMRコーデックの帯域幅(NB)がUE102のコーデックAの最大帯域幅(SWB)よりも狭い(図7に示すST804:Yes)。そこで、MSC/MGW300(変更判断部608)は、UE102へのエンコードされる入力信号の帯域幅制限が可能かつ必要であると判断する(図7に示すST806)。
そこで、MSC/MGW300(シグナリング生成部610)は、UE102に対し、コーデックAのエンコードされる入力信号の帯域幅を、NB(UE100の変更後のコーデックの帯域幅)に制限するよう依頼するシグナリングを送る(図5及び図10に示すST404)。このシグナリングは、例えばST202の一連のシグナリング(即ち、IMSシグナリング)に含まれてもよく、RTCP(Real-time Transport Control Protocol)−APP(Application-defined)(例えば、「3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS);Multimedia Telephony; Media Handling and interaction”」参照)のような別のシグナリングで送られてもよい。図11Aは、帯域制限を通知するシグナリングがIMSシグナリングに含まれる場合の一例を示す。また、図11Bは、帯域制限を通知するシグナリングがRTCP−APPに含まれる場合の一例を示す。
UE102(シグナリング解析部710)は、MSC/MGW300からのシグナリングを解析する。そして、UE102(コーデックモード変更部712)は、コーデックAの帯域幅の制限を依頼されていることを特定する。そこで、UE102(帯域幅決定部708)は、UE102のエンコードされる入力信号の帯域幅を、依頼された帯域幅(ここではNB)に制限する。そして、UE102は、制限した帯域幅で通信データをエンコードする(図10に示すST406)。
このようにして、UE100は、変更後のコーデックの帯域幅(NB)を使用し、UE102は、コーデックAの帯域制限した帯域幅(NB)を使用する。これにより、UE100及びUE102の双方ともコーデック帯域幅として同一のNBを使用する。よって、MSC/MGW300(トランスコーディング部612)では、UE102側からUE100側へのトランスコーディング(コーデックA(超広帯域)からAMRコーデック(狭帯域)へのトランスコーディング)を行う場合でも、通話品質の劣化を抑えることができる。
このように、本実施の形態では、MSC/MGW300(ネットワークノード)は、通信中のUEの一部のUE100にコーデックの変更が生じた場合でも、他のUE102に対して、UE100の変更後のコーデックの帯域幅に合わせるように、コーデックの帯域幅の制限を要求する。また、UE102は、VoLTE通話中の通信相手であるUE100のコーデックが変更(狭帯域幅に変更)された場合でも、UE102のエンコードされる入力信号の帯域幅をUE100に合わせて制限する。すなわち、UE102は、通信相手であるUE100のネットワーク状況に応じて、UE100との通信を途切れさせることなく、エンコードされる入力信号の帯域幅を変更する。
これにより、一方のUEのネットワーク状況が変わった場合でも、UE間のコーデックの帯域幅を同等に維持することができる。よって、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする場合に生じる通話品質の劣化を抑えることができる。すなわち、MSC/MGW300は、通信品質の劣化を抑えてトランスコーディングを行うことができる。
更に、UE102では、コーデックを変更せずに、エンコードされる入力信号の帯域幅のみを制限するので、コーデックを変更するためのシグナリングが不要となり、通話が途切れる時間が長くなることを防ぐことができる。
よって、本実施の形態によれば、VoLTE通話中のUE100がCS網にハンドオーバし、ハンドオーバ先CS網でコーデックが変更された場合でも、通話を途切れさせることなくUE102のエンコードされる入力信号の帯域幅を制限することができる。これにより、UE102側からUE100側へのトランスコーディングによる通話品質の劣化を抑えることができる。つまり、本実施の形態によれば、VoLTE通話中の端末(UE)の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる。
なお、上記実施の形態(例えば、図5参照)において、UE100がrSRVCC(reverse SRVCC。例えば、「3GPP TR23.885 v1.2.0 “Feasibility Study of Single Radio Voice Call Continuity (SRVCC) from UTRAN/GERAN to E-UTRAN/HSPA”」参照)に対応している場合、PS網からCS網にハンドオーバした後、再びPS網にハンドオーバする可能性もある。この場合、MSC/MGW300は、UE100のCS網からPS網へのハンドオーバ処理に関するシグナリングを受け取った時点で、UE102に対して、コーデックの帯域幅制限を解除するシグナリングを送信してもよい。又は、MSC/MGW300は、UE100がPS網へのハンドオーバ完了後に、UE102に対して、コーデックの帯域幅制限を解除するシグナリングを送信してもよい。
また、上記実施の形態(例えば、図5参照)では、UE100が通話開始の際、PS網に接続している場合について説明した。しかし、UE100が通話開始時に、CS網に接続している場合もあり得る。この場合、例えば、「3GPP TS23.292 v10.3.0 “IP Multimedia Subsystem (IMS) centralized services”」に記載の方法で、UE100は、PS網に接続しているUE102との間で通話を開始する。ここで、UE100がrSRVCCに対応している場合(即ち、UE100がPS網にハンドオーバし得る場合)、MSC/MGW300は、UE102との間で、コーデックの折衝を行う際、UE102に対し、UE100が使用するコーデックの帯域幅を最大帯域幅としてエンコードするように、予め折衝してもよい。又は、MSC/MGW300は、UE102との折衝後に別のシグナリングで、UE102にエンコードされる入力信号の帯域幅の制限を依頼してもよい。
また、本実施の形態では、SRVCC方式を用いて説明したが、eSRVCC方式においても本実施の形態を適用することができる。
SRVCC方式では、通信中のUEが使用するコーデックが異なる場合、MGW(MSC/MGW300)においてトランスコーディングが行われる。一方、非特許文献3によると、eSRVCC方式では、MGWがトランスコーディングを行う代わりに、ATGWがトランスコーディングを行ってもよいことになっている。
ここで、eSRVCC方式において、MGWではなくATGWでトランスコーディングを行う場合、SRVCC方式について、本実施の形態に係るMSC/MGW300(図5参照)へ追加された機能は、ATCF/ATGW1120(図3参照)に追加される。すなわち、eSRVCC方式では、ATCF/ATGW1120が、図6に示す受信部600、送信部602、コーデック検出部604、コーデック帯域幅検出部606、変更判断部608、シグナリング生成部610及びトランスコーディング部612を具備する構成を採る。ここで、eSRVCC方式においてATCF/ATGW1120が有する、送信部602、コーデック検出部604、変更判断部608、シグナリング生成部610及びトランスコーディング部612に関しては、SRVCC方式においてMSC/MGW300が有する各構成部と同一の機能を持つ。
eSRVCC方式におけるATCF/ATGW1120の受信部600(図6)は、通信データ、シグナリング等を受信する。例えば、受信部600は、UE100、UE102、ATCF、及びMSC/MGWからそれぞれ送信されるシグナリング(例えば、図3に示すシグナリング1102)を受信すると、受信したシグナリングを、コーデック検出部604及びコーデック帯域幅検出部606に出力する。
コーデック検出部604は、受信部600から入力されるUE100、UE102、ATCF、及びMSC/MGWからのシグナリング、通信データ等に基づいて、UE100及びUE102がそれぞれ使用するコーデックを検出する。そして、コーデック検出部604は、検出したコーデックを示す情報(検出結果)を変更判断部608に出力する。
コーデック帯域幅検出部606は、受信部600から入力されるUE100、UE102、及びMSC/MGWからのシグナリング、通信データ等に基づいて、UE100及びUE102がそれぞれ使用するコーデックの帯域幅を検出する。そして、コーデック帯域幅検出部606は、検出したコーデックの帯域幅を示す情報(検出結果)を、変更判断部608に出力する。
なお、ここでは、ATCF/ATGW1120を一つのノードとして説明したが、別々のノードでもよい。よって、上述したATCF/ATGW1120が有する機能を、ATCF又はATGWの何れか一方若しくは両方が有していてもよい。また、ATCFとATGWとの間で必要な情報をやり取りしてもよい。
また、上記実施の形態において、各UEは、コーディング折衝の際、図9のようにSDPで帯域幅を固定して指定しない代わりに、SDPで最大帯域幅を指定してもよい。
また、上記実施の形態では、MSC/MGW300、及びATGWがUE102に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する場合について説明した。しかし、MSC/MGW300、及びATGWは、帯域幅の制限を依頼するシグナリングの代わりに、エンコーディングビットレートの制限を依頼するシグナリングを送信してもよい。ここで、各UEは入力信号のエンコーディングビットレートに基づいて、エンコードされる入力信号の帯域幅を設定する。よって、MSC/MGW300、及びATGWがエンコーディングビットレートの制限を依頼するシグナリングをUEに送信することで、当該UEは、制限されたエンコーディングビットレートを設定し、かつ、制限されたエンコーディングビットレートに基づいて、エンコードされる入力信号の帯域幅を制限することが可能となる。または、MSC/MGW300、及びATGWは、帯域幅及びエンコーディングビットレートの双方の制限を依頼するシグナリングを送信してもよい。
また、上記実施の形態では、MSC/MGW300(図6)を1つのノードとして説明した。しかし、MSC/MGW300は、互いにインタフェースによって接続される2つ以上のノードで構成されてもよく、上述したMSC/MGW300の各機能をこれらの複数のノードに分散させてもよい。
(実施の形態2)
実施の形態1では、MSC/MGW300又はATGW(ATCF/ATGW1120)がUE102に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する場合について説明した。これに対して、本実施の形態では、MSC/MGW300又はATGW(ATCF/ATGW1120)が帯域幅の制限を依頼するシグナリングを送信する代わりに、UE102が通信データを受け取ることにより、UE100のコーデックの帯域幅が制限されたことを検知し、UE102のエンコードされる入力信号の帯域幅を制限する場合について説明する。
図12を用いて、本実施の形態に係るUEについて説明する。
図12に示すUE100,102において、受信部700、送信部702、コーデック折衝部704、コーデック選択部706、及び帯域幅決定部708は、図8と同一動作を行う構成部であり、その説明を省略する。
データ解析部1200は、受信部700から入力される通信データを解析する。データ解析部1200は、或る時刻から一定時間における通信データのコーデックの帯域幅の上限値が、その直前までのコーデック帯域幅の上限値、又は、通話開始時に折衝したコーデックの帯域幅の上限値と比較して異なる場合、通信相手先端末(UE)の通信データのコーデックの帯域幅が制限(変更)されたと解析する。データ解析部1200は、解析結果を、コーデックモード変更部1202に通知する。
コーデックモード変更部1202は、データ解析部1200からの解析結果に基づき、エンコードされる入力信号の帯域幅を制限(変更)することを決定し、その旨を帯域幅決定部708に通知する。これにより、帯域幅決定部708は、コーデックモード変更部1202において決定された帯域幅の変更を制御する。
このように、本実施の形態では、UE100、102は、受け取った通信データのコーデックの帯域幅の上限値が変更されたか否かに応じて、通信相手端末のコーデックが変更されたか否かを判断する。そして、UE100、102は、通信相手端末のコーデックが変更されたと判断した場合、自装置のコーデックの帯域幅の変更を制御する。これにより、実施の形態1と同様、一方のUEのネットワーク状況が変わった場合でも、UE間のコーデックの帯域幅を同等に維持することができる。よって、実施の形態1と同様、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする場合に生じる通話品質の劣化を抑えることができる。
(実施の形態3)
図13は、本発明の実施の形態3に係る移動通信ネットワークの一部を示す構成である。なお、図13に示す各ノードの動作は前述(例えば図5)した通りである。
図13において、UE100は、最初SRVCCにてCS網にハンドオーバ(以下、SRVCCハンドオーバと呼ぶこともある)を行い、PS網に存在するUE102と、MSC/MGW1300を経由して、通信データを送受信している(図13に示すPath A及びPath B)。この際、UE100はCS網で利用するコーデックとしてAMR−WBを用い、UE102はPS網で利用するコーデックとして、例えば上述したコーデックA(帯域幅の指定が必ずしも必要の無いコーデック)を用い、MSC/MGW1300でトランスコーディングが行われていたとする。
次に、UE102もSRVCCによりCS網にハンドオーバを行ったとする。
この際、非特許文献1のハンドオーバ手順に従えば、UE102の移動先CS網での通信はMSC/MGW1302で終端され、MSC/MGW1300の通信相手先は、UE102からMSC/MGW1302に変更される。すなわち、UE100とUE102との間の通信データの経路は、Path D、Path C及びPath Bを通る経路に変更される。
更に、UE102がCS網で使用するコーデックがAMR−WBに変更になったとする。この場合、UE102からMSC/MGW1302までは、UE102からUE100へ送信される通信データは、Path Dを通り、かつ、AMR−WBを用いて送信される。次いで、MSC/MGW1302は、UE102がCS網で使用するAMR−WBからPS網で使用していたコーデックAにトランスコーディングを行う。よって、MSC/MGW1302からMSC/MGW1300までは、UE102からUE100へ送信される通信データは、Path Cを通り、かつ、コーデックAを用いて送信される。次いで、MSC/MGW1300は、コーデックAからAMR−WBにトランスコーディングを行う。よって、MSC/MGW1300からUE100までは、UE102からUE100へ送信される通信データは、Path Bを通り、かつ、AMR−WBを用いて送信される。UE100からUE102へ送信される通信データについても同様である。
本実施の形態では、通信中のUE100及びUE102の双方がSRVCCハンドオーバを行った場合でも、MSC/MGW1300,1302におけるトランスコーディングを最小限に抑える方法について説明する。
まず、図13に示すMSC/MGW1300、1302について説明する。
図14は、本実施の形態に係るMSC/MGW1300、1302構成を示すブロック図である。なお、図14に示すMSC/MGW1300、1302は、図示される機能ブロックの他に、図8に示される機能ブロック又はその他の機能ブロックを具備していてもよい。
図14に示すMSC/MGW1300、1302において、受信部1500は、通信データ、シグナリング等を受信する。
送信部1502は、通信データ、シグナリング等を送信する。
シグナリング解析部1504は、SRVCC処理のためのシグナリング、又は、IMSのシグナリング(IMSシグナリング)等を解析する。シグナリング解析部1504は、シグナリング解析の結果を、シグナリング生成部1506、端末位置判断部1508及びコーデック選択部1510に通知する。
シグナリング生成部1506は、シグナリング解析部1504のシグナリング解析結果等に基づいて、シグナリングを生成する。
端末位置判断部1508は、シグナリング解析部1504のシグナリング解析結果に基づいて、通信中の双方の端末(UE100、102)がPS網に存在するのか、CS網に存在するのかを判断する。端末位置判断部1508は、判断結果をコーデック選択部1510及び経路選択部1512に出力する。
コーデック選択部1510は、シグナリング解析部1504のシグナリング解析結果及び端末位置判断部1508の判断結果に基づいて、利用するコーデック、又はコーデック候補を選択する。
経路選択部1512は、端末位置判断部1508の判断結果に基づいて、通信データが通る経路を選択する。
次に、本実施の形態におけるMSC/MGW1300,1302の動作の一例について説明する。
図15は、図13に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。なお、図13において、SCC AS及びCSCFは図示していないが、IMSの一部として存在しているものとする。
現在、UE100とUE102は、双方ともe−UTRANに接続し、VoLTE通信を行っているとする。つまり、現在、UE100及びUE102では、音声コーデックとして、前述のコーデックA(帯域幅の指定が必ずしも必要の無いコーデック)が使用されているものとする(図15に示すST1400)。
次いで、UE100はCS網にハンドオーバ(SRVCCハンドオーバ)する(図10に示すST200の処理(SRVCC処理)と同等の処理)。また、UE100はCS網にハンドオーバし、CS網との間にコネクションを確立する(図10に示すST204の処理(コネクション確立処理)と同等の処理)。
ST200の処理及びST204の処理と同時に、MSC/MGW1300のシグナリング生成部1506は、UE102に送信するIMSシグナリングを生成して、送信部1502を介して送信する(図15に示すST1402)。このとき、シグナリング生成部1506は、当該IMSシグナリングの中に、SRVCCハンドオーバにより発生したIMSシグナリングであることを示す情報を含める。例えば、SRVCCハンドオーバにより発生したIMSシグナリングであることを示す情報は、非特許文献3に記載のSTN−SR(Session Transfer Number for SRVCC)等であってもよい。
また、MSC/MGW1300のシグナリング生成部1506は、UE100がPS網で使用していたコーデック(コーデックA)の他に、自網側のCS網(MSC/MGW1300が属するCS網)でサポートしているコーデックのリストをIMSシグナリングの中に含める(図15に示すST1402)。この際、シグナリング解析部1504が、ST204のコネクション確立処理を待って、コネクション確立に関するシグナリングを解析し、UE100がCS網で使うコーデック情報を得て、その後、シグナリング生成部1506が、このコーデック情報をIMSシグナリングの中に明示的に含めてもよい。
これにより、UE100〜MSC/MGW1300ではCS網を使った通信が行われ、MSC/MGW1300〜UE102ではPS網を使った通信が行われる(図15に示すST1404)。
次いで、UE102はCS網にハンドオーバ(SRVCCハンドオーバ)する(図10に示すST200(SRVCC処理)と同等の処理)。また、UE102はCS網にハンドオーバし、CS網との間にコネクションを確立する(図10に示すST204の処理(コネクション確立処理)と同等の処理)。
ST200の処理及びST204の処理と同時に、MSC/MGW1302のシグナリング生成部1506は、MSC/MGW1300に送信するIMSシグナリングを生成して、送信部1502を介して送信する(図15に示すST1406)。このとき、シグナリング生成部1506は、当該IMSシグナリングの中に、SRVCCハンドオーバにより発生したIMSシグナリングであることを示す情報を含める。例えば、SRVCCハンドオーバにより発生したIMSシグナリングであることを示す情報は、非特許文献3に記載のSTN−SR(Session Transfer Number for SRVCC)等であってもよい。
また、MSC/MGW1302のシグナリング生成部1506は、UE102がPS網で使用していたコーデック(コーデックA)の他に、自網側のCS網(MSC/MGW1302が属するCS網)でサポートしているコーデックのリストをIMSシグナリングの中に含める(図15に示すST1406)。この際、シグナリング解析部1504が、ST204のコネクション確立処理を待って、コネクション確立に関するシグナリングを解析し、UE102がCS網で使うコーデック情報を得て、その後、シグナリング生成部1506が、このコーデック情報をIMSシグナリングの中に明示的に含めてもよい。
MSC/MGW1300の受信部1500は、MSC/MGW1302からのIMSシグナリングを受け取り、シグナリング解析部1504に出力する。シグナリング解析部1504は、このIMSシグナリングを解析することにより、UE102がSRVCCハンドオーバを行ったことを特定し、UE102がSRVCCハンドオーバを行ったことを示す情報を端末位置判断部1508に出力する。また、シグナリング解析部1504は、このIMSシグナリング(SDPオファー)に含まれるコーデックのリスト(MSC/MGW1302が属するCS網でサポートしているコーデックのリスト)を、コーデック選択部1510に出力する。端末位置判断部1508は、UE102がSRVCCハンドオーバを行ったことにより、UE100及び102の双方ともCS網に存在すると判断する。コーデック選択部1510は、端末位置判断部1508の判断結果、及び、シグナリング解析部1504から入力される、MSC/MGW1302が属するCS網でサポートされているコーデック情報(コーデックのリスト)を用いて、利用するコーデックを選択する(図15に示すST1406)。
また、経路選択部1512は、端末位置判断部1508の判断結果に基づいて、通信データが通る経路を選択する(図15に示すST1406)。これにより、UE100とUE102との通信は、選択された経路を通って行われる(図15に示すST1408)。
次に、図13及び図15に示すMSC/MGW1300のコーデック選択部1510におけるコーデックの選択方法の一例を図16に示す。
図16に示すST1600において、コーデック選択部1510は、端末位置判断部1508の判断結果に基づいて、通信中の双方の端末(UE100,102)がCS網に移動(存在)しているか否かを判断する。
通信中の双方の端末がCS網に移動している場合(ST1600:YES)、ST1602において、コーデック選択部1510は、受信部1500で受け取ったIMSシグナリングに、通信相手端末(UE102)がCS網で使用するコーデック情報(コーデックのリスト)が含まれるか否かを判断する。
IMSシグナリングに通信相手端末がCS網で使用するコーデック情報が含まれる場合(ST1602:YES)、ST1604において、コーデック選択部1510は、通信相手端末(UE102)がCS網で使用するコーデック情報が、自網側の端末(UE100)が使用中のコーデックと一致するか否かを判断する。上記コーデック情報が自網側の端末(UE100)が使用中のコーデックと一致する場合、ST1614の処理に進む。
通信中の双方の端末がCS網に移動していない場合(ST1600:NO)、ST1606において、コーデック選択部1510は、自装置(MSC/MGW1300)が、PS網で使用されているコーデックに対応するか否かを判断する。自装置(MSC/MGW1300)が、PS網で使われているコーデックに対応しない場合(ST1606:NO)、ST1612の処理に進む。
IMSシグナリングに通信相手端末がCS網で使用するコーデック情報が含まれない場合(ST1602:NO)、又は、自装置(MSC/MGW1300)が、PS網で使われているコーデックに対応する場合、ST1608において、コーデック選択部1510は、IMSシグナリング(SDPオファー)によってオファーされているコーデック情報(コーデックリスト)の中に、現在自網側のUE(UE100)が使用中のコーデックが含まれるか否かを判断する。オファーされているコーデックリストの中に、現在自網側のUE(UE100)が使用中のコーデックが含まれる場合(ST1608:YES)、ST1614の処理に進む。
オファーされているコーデックリストの中に、現在自網側のUE(UE100)が使用中のコーデックが含まれない場合(ST1608:NO)、ST1610において、コーデック選択部1510は、IMSシグナリング(SDPオファー)によってオファーされているコーデックリストの中に、自装置(MSC/MGW1300)がサポートしているコーデックが含まれるか否かを判断する。オファーされているコーデックリストの中に、自装置がサポートしているコーデックが含まれる場合(ST1610:YES)、ST1616の処理に進む。オファーされているコーデックリストの中に、自装置がサポートしているコーデックが含まれない場合(ST1610:NO)、ST1618の処理に進む。
ST1612では、コーデック選択部1510は、PS網で使用されているコーデックを選択する。
ST1614では、コーデック選択部1510は、自網側の端末(UE100)が使用中のコーデックを、使用するコーデックとして選択する。
ST1616では、コーデック選択部1510は、オファーされているコーデックリストのうち、自装置(MSC/MGW1300)がサポートしているコーデックの中から、使用するコーデックを選択する。
ST1618では、コーデック選択部1510は、エラーを選択する。
このようにして、MSC/MGW1300,1302は、ハンドオーバにより発生したIMSシグナリングの中に、自網側のCS網でサポートしているコーデックのリストを含める。また、上記IMSシグナリングを受け取ると、MSC/MGW1300(MSC/MGW1302)は、まず、通信中の双方の端末がCS網に存在すると判断する。更に、MSC/MGW1300(MSC/MGW1302)は、IMSシグナリングの送信先のMSC/MGWが属するCS網でサポートされているコーデック情報を用いて、利用するコーデックを選択する。具体的には、MSC/MGW1300,1302は、通信中の双方の端末(UE100,102)が同一のコーデックを使用可能な場合には、双方の端末で当該同一のコーデックが使用されるように、利用するコーデックを選択する。
すなわち、一方の端末(UE100)がCS網にハンドオーバし、他方の端末(UE102)がCS網にハンドオーバした場合において、例えば、UE100側のCS網に属するMSC/MGW1300は、UE102側のCS網に属するMSC/MGW1302から、UE102側のCS網でサポートしているコーデックリスト(コーデック群)を含むメッセージを受信し、上記コーデックリスト、及び、UE100が使用するコーデック(変更後のコーデック)を用いて、UE102が使用するコーデックを選択する。例えば、MSC/MGW1300は、受信したコーデックリストに、UE100が使用するコーデック(変更後のコーデック)が含まれる場合、UE102が使用するコーデックとして、UE100が使用するコーデックを選択する。
これにより、双方の端末(UE100,102)では、可能であれば同一コーデックが使用されるので、MSC/MGW1300,1302では、トランスコーディングが行われない。よって、本実施の形態によれば、通信中のUE100及びUE102の双方がSRVCCハンドオーバを行った場合でも、MSC/MGW1300,1302における、トランスコーディングを最小限に抑えることができる。
また、実施の形態1では、MSC/MGW300がコーデック帯域幅の変更を検出し、UE102に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する方法について説明した。これに対して、本実施の形態では、MSC/MGW1300,1302は、自網側の端末がCS網で使うコーデック情報を得た後、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングに代えて、当該コーデック情報をIMSシグナリングの中に明示的に含めて通信相手側端末に送信する。この場合でも、実施の形態1と同様、一方又は双方のUEのネットワーク状況が変わった場合でも、UE間のコーデックの帯域幅を同等に維持することができる。
なお、端末位置判断部1508により、UE100、102の双方ともCS網に存在すると判断された場合、経路選択部1512は、ネットワーク側の経路を全てCS網用の経路に切り替えてもよい。端末位置判断部1508は、この判断方法として、例えば両方の端末がrSRVCCに対応しているか否かで判断してもよい。すなわち、両方の端末(UE100,102)がrSRVCCに対応していない場合、経路選択部1512は、ネットワーク側の経路をCS網用の経路に切り替えてもよい。なお、両方の端末がrSRVCCに対応しているかどうかに関しては、非特許文献3に記載の、SRVCCサポートの登録又はSRVCCサポートしているか否かの入手方法と同等の方法で実現できる。
また、端末(例えば図17に示すUE102)は、エンコードされる入力信号の帯域幅の制限を依頼するシグナリング等の受信により、通信相手側端末(例えば図17に示すUE100)がSRVCCによるハンドオーバを行ったことを判断した場合、自装置がSRVCCによるハンドオーバを行う際のシグナリング(図15に示すST200又はST204)によって、自網側MSC/MGW(例えば、図17に示すMSC/MGW1310)に対し、通信相手側端末(UE100)が既にSRVCCによるハンドオーバを行っていることを通知してもよい。これにより、MSC/MGW1310の端末位置判断部1508は、双方の端末(UE100,102)がCS網にハンドオーバしたと判断し、IMSシグナリング(SDPオファー)のコーデックリストの中に、PS網のみでサポートしているコーデックを含めることを回避できる。つまり、MSC/MGW1310は、CS網でサポートしているコーデックのみをSDPオファーに含めることができる(図17参照)。この際、MSC/MGW1310は、自装置がMGWであることを明示的に伝えてもよい(例えば図17参照)。また、上記通知を受け取ったMSC/MGW1300は、CS網同士で通信することを決定してもよい(例えば図17参照)。また、上記通知は、例えば、UE102がCS網にハンドオーバした際にUE102から送信される既存のシグナリングに含まれてもよいし、新しいシグナリングでもよい。また、上記通知は、UE102がCS網にハンドオーバする以前に、MME(図示せず)に対して送信されるシグナリングに含まれてもよい(例えば、非特許文献4参照)。
(実施の形態4)
本実施の形態では、通信を行う双方のUEがeSRVCC方式によってPS網からCS網へのハンドオーバを行う場合、又は、一方のUEがeSRVCC方式によってPS網からCS網へハンドオーバを行い、他方のUEがSRVCC方式によってPS網からCS網へハンドオーバを行う場合について説明する。本実施の形態では、eSRVCC方式において、通信データはATGWでアンカーされ、ATGWにおいてトランスコーディングが行われると仮定する。
図18は、本発明の実施の形態4に係る移動通信ネットワークの一部を示す構成である。なお、図18に示す各ノードの動作は前述(例えば図3及び図5)した通りである。
図18において、UE100及びUE102の双方は、最初e−UTRANに存在し、PS網でVoLTE通信を行っている。この際、上述したコーデックA(帯域幅の指定が必ずしも必要の無いコーデック)が使用されていると仮定する。図18では、UE100側のネットワーク、及び、UE102側のネットワークの双方ともeSRVCCに対応していると仮定する。これより、UE100とUE102との間の現在の通信経路は、ATCF/ATGW1700及びATCF/ATGW1702を経由した、Path A、Path B及びPath Cとなる。
なお、図18では、ATCF/ATGW1700,1702を一つのノードとして表しているが、別々のノードでもよい。また、図18において、UE100側のネットワークがeSRVCCに対応していない場合には、UE100とUE102との間の通信経路としてATCF/ATGW1700及びPath Bは存在しないので、Path Aは、UE100とATCF/ATGW1702との間に確立される。同様に、UE102側のネットワークがeSRVCCに対応していない場合には、通信経路としてATCF/ATGW1702及びPath Bは存在しないので、Path Cは、UE102とATCF/ATGW1700との間に確立される。
次に、UE100、UE102のそれぞれがeSRVCCによりハンドオーバを行ったとする。この場合、非特許文献3によると、ハンドオーバ後のUE100とUE102との間の通信経路は、MSC/MGW1704、ATCF/ATGW1700、ATCF/ATGW1702及びMSC/MGW1706を経由した、Path D、Path E、Path B、Path G、及びPath Fとなる。
なお、図18において、UE100側のネットワークがeSRVCCに対応していない場合には、UE100とUE102との間の通信路としてATCF/ATGW1700及びPath Bは存在しないので、Path EはMSC/MGW1704とATCF/ATGW1702との間に確立される。同様に、UE102側のネットワークがeSRVCCに対応していない場合には、UE100とUE102との間の通信経路としてATCF/ATGW1702及びPath Bは存在しないので、Path Gは、MSC/MGW1706とATCF/ATGW1700との間に確立される。
ここで、例えばUE100,102がCS網にハンドオーバした際に使用するコーデックを双方ともAMR−WBであるとする。この場合、UE100からATCF/ATGW1700までの通信データはAMR−WBでエンコードされる。次いで、ATGW1700はAMR−WBからコーデックAにトランスコーディングを行う。よって、ATGW1700からATGW1702までの間の通信データはコーデックAでエンコードされる。次いで、ATGW1702は再びコーデックAからAMR−WBにトランスコーディングを行う。よって、ATGW1702からUE102までの間の通信データはAMR−WBでエンコードされる。
なお、UE100側のネットワークがeSRVCCに対応していない場合には、ATGE1700の代わりにMSC/MGW1704でトランスコーディングが行われる。同様に、UE102側のネットワークがeSRVCCに対応していない場合には、ATGE1702の代わりにMSC/MGW1706でトランスコーディングが行われる。
本実施の形態では、通信中のUE100及びUE102の双方がeSRVCC方式によってPS網からCS網へのハンドオーバを行う場合、又は、一方のUEがeSRVCC方式によってPS網からCS網へハンドオーバを行い、他方のUEがSRVCC方式によってPS網からCS網へハンドオーバを行う場合について、実施の形態3と同様、トランスコーディングを最小限に抑える方法について説明する。
まず、図18に示すATCF/ATGW1700、1702、及び、UE100、102について説明する。
図19は、本実施の形態に係るATCF/ATGW1700、1702の構成を示すブロック図である。なお、図19に示すATCF/ATGW1700、1702は、図示される機能ブロックの他に、図8に示される機能ブロック又はその他機能ブロックを具備していてもよい。
図19に示すATCF/ATGW1700、1702において、受信部1900は、通信データ、シグナリング等を受信する。
送信部1902は、通信データ、シグナリング等を送信する。
シグナリング解析部1904は、SRVCC処理又はeSRVCC処理のためのシグナリング、又は、IMSのシグナリング(IMSシグナリング)等を解析する。シグナリング解析部1904は、シグナリング解析の結果を、シグナリング生成部1906、端末位置判断部1908及びコーデック選択部1910に通知する。
シグナリング生成部1906は、シグナリング解析部1904のシグナリング解析結果等に基づいて、シグナリングを生成する。
端末位置判断部1908は、シグナリング解析部1904のシグナリング解析結果に基づいて、通信中の双方の端末(UE100、102)がPS網に存在するのか、CS網に存在するのかを判断する。端末位置判断部1908は、判断結果をコーデック選択部1910及び経路選択部1912に出力する。
コーデック選択部1910は、シグナリング解析部1904のシグナリング解析結果及び端末位置判断部1908の判断結果に基づいて、利用するコーデック、又はコーデック候補を選択する。
経路選択部1912は、端末位置判断部1908の判断結果に基づいて、通信データが通る経路を選択する。
図20は、本実施の形態に係るUE100、102の構成を示すブロック図である。UE100、102は、図示される機能ブロックの他に、図12に示される機能ブロック又はその他機能ブロックを具備していてもよい。なお、図20に示すUE100,102において、受信部700及び送信部702は、図12と同一動作を行う構成部であり、その説明を省略する。
図20に示すUE100、102において、通信相手コーデック変更検出部2000は、通信相手が使用しているコーデックが変更になったことを検出する。通信相手が使用しているコーデックが変更される理由には、例えば、PS網からCS網に移動したことが挙げられる。また、通信相手コーデック変更検出部2000におけるコーデック変更の検出方法は、例えば、実施の形態1で示したような、帯域制限通知等のシグナリングをネットワークから受け取る方法、及び、実施の形態2で示したような、通信相手が使用しているコーデックの帯域が制限されたことを検出する方法等が挙げられる。
シグナリング生成部2002は、通信相手コーデック変更検出部2000で通信相手のコーデックが変更になったことが検出された場合、通信相手のコーデックが変更されたことをネットワークに通知するためのシグナリングを生成する。
次に、本実施の形態におけるUE100,102、及び、ATCF/ATGW1700,1702の動作の一例について説明する。ここでは、UE100側のネットワーク、及び、UE102側のネットワークの双方がeSRVCCに対応していると仮定する。
図21は、図18に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。
UE100及びUE102は、e−UTRANに接続処理を行い、IMSに対してVoLTEに関する登録をする際、例えば、ATCF(ATCF/ATGW1700,1702)に関する情報をSCC AS、HSS(図示せず)又はMME(図示せず)に送信し、送信先で当該情報が保持される(例えば、非特許文献5参照)。更に、発呼の際(本実施の形態では、UE100からUE102への発呼と仮定する。UE102からUE100への発呼の場合も同様である。)には、ATCF/ATGW1700,1702において、ATCFは、ATGWでセッションをアンカーするかどうかを判断する(例えば、非特許文献3又は非特許文献5を参照)。
その後、UE100及びUE102は、共にe−UTRANに接続し、VoLTE通信を行っている。この時、音声コーデックとして、前述のコーデックA(帯域幅の指定が必ずしも必要の無いコーデック)が使用されているものとする(図21に示すST1800)。
次いで、UE100がPS網からCS網にハンドオーバする。このとき、図10に示すST200の処理(SRVCC処理)及びST204の処理(コネクション確立処理)と同等の処理が行われる。また、ST200の処理及びST204の処理と同時に、図4に示すST1102の処理と同等の処理が行われる。これにより、UE100とUE102との間のデータ通信経路がMSC/MGW1704経由に切り替わる(図21に示すST1802)。
この際、ATCF/ATGW1700のシグナリング生成部1906は、UE100がCS網で使用するコーデック(例えばAMR)を含むメッセージを生成し、当該メッセージを送信部1902を介して、SCC AS/CSCF1708に通知する(図21に示すST1802’)。この通知は非特許文献3に記載のAccess Transfer Updateメッセージと共に通知されてもよい。この後、実施の形態1で示したように、ATCF/ATGW1700は、UE102に対して帯域制限通知を送信してもよい。
UE102の通信相手コーデック変更検出部2000は、UE100のコーデックがコーデックAから変更になったことを検出する(図21に示すST1804)。
次に、UE102もPS網からCS網にハンドオーバする。このとき、UE102のシグナリング生成部2002は、通信相手であるUE100のコーデックが変更になっていることをネットワークに通知するためのシグナリングを生成する。このシグナリングは、例えば、UE102がCS網にハンドオーバした際に、UE102から送信される既存のシグナリングに含まれてもよく、新しいシグナリングに含まれてもよい(図21に示すST1806)。また、上記通知は、UE102がCS網にハンドオーバする以前に、MME(図示せず)に対し送信されるシグナリングに含まれ、MMEからMSC/MGW1706に通知されてもよい(例えば、非特許文献4参照)。
UE102からのシグナリングを受け取ったMSC/MGW1706は、UE102の通信相手であるUE100のコーデックが変更になっていることを検知し、UE100のコーデックが変更になっていることを示す情報を、ATCF/ATGW1702に送信するINVITEメッセージに含める。
このINVITEメッセージを受け取ったATCF/ATGW1702のシグナリング解析部1904は、UE102の通信相手であるUE100のコーデックが変更になっていることを検出する。そこで、ATCF/ATGW1702のシグナリング生成部1906は、SCC AS/CSCF1708に対して、UE100のコーデック問い合わせのためのシグナリングを生成し、当該シグナリングを送信部1902を介して送信する(図21に示すST1808)。
ATCF/ATGW1702の受信部1900は、ST1808で送信したシグナリングに対する返信シグナリングをSCC AS/CSCF1708から受け取る。そして、ATCF/ATGW1702のシグナリング解析部1904は、この返信シグナリングを解析し、解析結果(UE100のコーデックに関する情報)に基づいて、ATCF/ATGW1700との間でコーデック折衝を行い(図21に示すST1810)、コーデックを選択する(図21に示すST1812)。なお、コーデック折衝は、ATCF/ATGW1702とSCC AS/CSCF1708との間、及び、SCC AS/CSCF1708とATCF/ATGW1700との間で行われてもよい(すなわち、SCC ASでアンカーしてもよい)。なお、ATCF/ATGW1700,1702は、SCC AS/CSCF1708を介さずに、コーデック折衝を行ってもよい。この場合、図21に示すST1802の処理及びST1808の処理は不要となる。
このようにして、ATCF/ATGW1700,1702は、端末(UE100,102)がハンドオーバした場合、ハンドオーバした端末がCS網で使用するコーデックを含むメッセージを生成し、当該メッセージをSCC AS/CSCF1708に通知する。この場合、ハンドオーバした端末と通信している通信相手端末は、ハンドオーバした端末のコーデックが変更されたことを検出している。また、ATCF/ATGW1700,1702は、ハンドオーバした端末のコーデックが変更されたことを検出している通信相手端末もハンドオーバした場合、当該通信相手端末からの通知によって、最初にハンドオーバした端末のコーデックが変更になっていることを検出すると、SCC AS/CSCF1708に対して、当該通信相手のコーデック問い合わせを行う。そして、ATCF/ATGW1700,1702は、問い合わせにより得たコーデック(最初にハンドオーバした端末のコーデック)に関する情報に基づいて、コーデック折衝を行い、コーデックを選択する。例えば、ATCF/ATGW1700,1702は、通信中の双方の端末(UE100,102)が同一のコーデックを使用可能な場合には、双方の端末で当該同一のコーデックが使用されるように、利用するコーデックを選択する。
すなわち、一方の端末(UE100)がCS網にハンドオーバした後に、他方の端末(UE102)がCS網にハンドオーバした場合において、ATCF/ATGW1702は、SCC AS/CSCF1708への問い合わせにより、UE100が使用するコーデック(変更後のコーデック)を含むメッセージを受信し、UE102側のMSC/MGW1706から、UE100がCS網にハンドオーバしたことを示す情報を含むメッセージを受信し、UE100がCS網にハンドオーバしたことを示す情報を受信した場合、上記UE100が使用するコーデックに基づいて、UE102が使用するコーデックを選択する。
これにより、双方の端末(UE100,102)では、実施の形態3と同様、可能であれば同一コーデックが使用されるので、ATCF/ATGW1700,1702では、トランスコーディングが行われない。よって、本実施の形態によれば、通信中のUE100及びUE102の双方がeSRVCC方式によってPS網からCS網へのンドオーバを行う場合、実施の形態3と同様、トランスコーディングを最小限に抑えることができる。
なお、端末位置判断部1908により、UE100、102の双方ともCS網に存在すると判断された場合、経路選択部1912は、ネットワーク側の経路を全てCS網用の経路に切り替えてもよい。端末位置判断部1908は、この判断方法として、例えば両方の端末がrSRVCCに対応しているか否かで判断してもよい。すなわち、両方の端末(UE100,102)がrSRVCCに対応していない場合、経路選択部1912は、ネットワーク側の経路をCS網用の経路に切り替えてもよい。なお、両方の端末がrSRVCCに対応しているかどうかに関しては、非特許文献3に記載の、SRVCCサポートの登録又はSRVCCサポートしているか否かの入手方法と同等の方法で実現できる。
また、端末(例えば図21に示すUE102)は、エンコードされる入力信号の帯域幅の制限を依頼するシグナリング等の受信により、通信相手側端末(例えば図21に示すUE100)がSRVCC又はeSRVCCによるハンドオーバを行ったことを判断した場合、自装置がeSRVCCによるハンドオーバを行う際のシグナリング(図21に示すST200/ST204)によって、自網側MSC/MGW(例えば、図21に示すMSC/MGW1706)に対し、通信相手側端末(UE100)が既にSRVCC又はeSRVCCによるハンドオーバを行っていることを通知してもよい。これにより、MSC/MGW1706の端末位置判断部1908は、双方の端末(UE100,102)がCS網にハンドオーバしたと判断し、IMSシグナリング(SDPオファー)のコーデックリストの中に、PS網のみでサポートしているコーデックを含めることを回避できる。この通知は、例えば、UE102がCS網にハンドオーバした際にUE102から送られる既存のシグナリングに含まれてもよいし、新しいシグナリングでもよい(図21に示すST1806)。また、上記通知は、UE102がCS網にハンドオーバする以前に、MME(図示せず)に対し送信されるシグナリングに含まれてもよい(例えば、非特許文献4参照)。
また、図19に示すように、MSC/MGW1704,1706は、ATCF/ATGW1700,1702と同等の機能を具備してもよい。図18において、UE100側のネットワークがeSRVCCに対応していない場合、MSC/MGW1704のシグナリング解析部1904は、UE100がCS網にハンドオーバした際、CS網で使用するコ−デックを含むシグナリングを解析し、UE100がCS網で使用するコーデックの情報を得る。次いで、MSC/MGW1704のシグナリング生成部1906は、UE100がCS網で使用するコーデックの情報を生成し、SCC AS/CSCF1708に通知する。この通知は、INVITEメッセージに含まれてもよい。また、図18において、UE102側のネットワークがeSRVCCに対応していない場合、MSC/MGW1706のシグナリング解析部1904は、UE102から、通信相手であるUE100のコーデックが変更になっていることを通知する内容を含むシグナリングを受け取った際、UE102の通信相手であるUE100のコーデックが変更になっていることを検知する。次いで、MSC/MGW1706のシグナリング生成部1906は、SCC AS/CSCF1708に対してUE100のコーデックを問い合わせるシグナリングを生成し、SCC AS/CSCF1708に送信する。SCC AS/CSCF1708より返信シグナリングを受け取ると、MSC/MGW1706のシグナリング解析部1904は、この返信シグナリングを解析し、解析結果に基づいて、UE100側でトランスコーディングを行うノード(MSC/MGW1704又はATCF/ATGW1700)との間でコーデック折衝を行い、コーデックを選択する。なお、コーデック折衝は、MSC/MGW1706とSCC AS/CSCF1708との間、及び、SCC AS/CSCF1708とUE100側でトランスコーディングを行うノードとの間で行われてもよい(すなわち、SCC ASでアンカーしてもよい)。これにより、一方のUEがeSRVCC方式により、他方のUEがSRVCC方式によって、PS網からCS網へハンドオーバを行う場合でも、実施の形態3と同様、トランスコーディングを最小限に抑えることができる。
(実施の形態5)
実施の形態1、3及び4では、MSC/MGW又はATCF/ATGWが、セッション途中における片方のUEの通信データの帯域幅の変更を検出した場合、もう片方のUEに対し帯域制限通知を行う方法を説明した。これに対して、本実施の形態では、帯域制限通知を送る代わりに、又は帯域制限通知を送る事に加え、MSC/MGW又はATCF/ATGWが送る通信データ、又は通信データのRTPペイロードのヘッダ部に帯域情報を明示的に含める方法を説明する。
例えば、実施の形態1において、MSC/MGW300のコーデック帯域幅検出部606でUE100の帯域幅変更を検出し、変更判断部608でUE102へのエンコードされる入力信号の帯域幅制限が可能であり、かつ、帯域幅制限が必要であると判断された場合、MSC/MGW300からUE102へ送られる通信データの帯域幅も制限する。この際、MSC/MGW300が送る通信データそのもの、又は通信データが格納されるRTPのペイロードヘッダ部に、明示的に変更後の帯域幅情報を含める。
RTPペイロードヘッダ部に変更後の帯域情報を含める場合、帯域情報を含めるパケットは、帯域変更後のある一定期間(例えば200msec)に送られるパケット、又はある一定個数のパケット(例えば10パケット)に限る。
受信側(UE102)では、ある一定期間以上(例えば150msec以上)又はある特定個数(例えば5パケット以上)のRTPのペイロードヘッダに帯域情報が付加されている事を検出すると、その後送られてくるRTPペイロードヘッダに帯域情報が付加されていなかった場合においても、格納されている通信データの帯域幅が制限され続けると判断する。
帯域制限通知を受け取ったUE102が、帯域を制限した通信データをMGW300に送信する場合においても同様に、ある一定期間(例えば200msec)に送られるパケット、又はある一定個数のパケット(例えば10パケット)のRTPペイロードヘッダ部に帯域情報を付加する。受信側(MGW300)では、ある一定期間以上(例えば150msec以上)又はある特定個数(例えば5パケット以上)のRTPのペイロードヘッダに帯域情報が付加されている事を検出すると、その後送られてくるRTPペイロードヘッダに帯域情報が付加されていなかった場合においても、格納されている通信データの帯域幅が制限され続けると判断する。
また、実施の形態2において、帯域制限通知を受け取る代わりに、UE102のデータ解析部1200において、データそのものの帯域幅が一定時間以上制限されている事を検出し、送信するデータの帯域を制限する方法を説明した。これに代えて、本実施の形態の上述の方法(ある一定期間以上(例えば150msec以上)又はある特定個数(例えば5パケット以上)のRTPのペイロードヘッダに帯域情報が付加されている事)を用いて、コーデックモード変更部1202において、帯域の変更を決定してもよい。
また、実施の形態1、3及び4において、帯域制限通知そのものを、RTPペイロードヘッダに含めてもよい。帯域制限通知をRTPペイロードヘッダに含める場合においても、帯域制限通知を含めるパケットは、帯域変更通知が必要であると判定された後のある一定期間(例えば100msec)に送られるパケット、又はある一定個数のパケット(例えば5パケット)に限る。受信側(UE102)では、ある一定期間以上(例えば20msec以上)又はある特定個数(例えば1パケット以上)のRTPのペイロードヘッダに帯域制限通知が付加されている事を検出すると、その後送られてくるRTPペイロードヘッダに帯域制限通知が付加されていなかった場合においても、帯域幅の制限(変更)を依頼されていることが通知されたと判断する。尚、帯域制限通知をRTPペイロードヘッダに含める場合には、帯域制限通知と共に上述の帯域情報を含めてもよい。
これにより、送信データの帯域幅の変更を、セッション途中でも明示的に通信相手に通知する事ができる。
以上、本発明の各実施の形態について説明した。
なお、上記各実施の形態では、ATCF/ATGW、MSC/MGW、SCC AS/CSCFをそれぞれ一つのノードとして説明したが、別々のノードでもよい。すなわち、ATCFとATGWとの間、MSCとMGWとの間、及び、SCC ASとCSCFとの間のそれぞれにおいて、上述した機能をいずれか一方若しくは両方が具備していればよい。また、ATCFとATGWとの間、MSCとMGWとの間、及び、SCC ASとCSCFとの間のそれぞれで必要な情報をやり取りしてもよい。
また、上記各実施の形態において、UE100及びUE102の双方ともCS網へのハンドオーバ(SRVCC、eSRVCC等によるハンドオーバ)をサポートしている場合には、PS網上でのセッション折衝の際、CS網でサポートされているコーデック若しくはCS網でサポートされているコーデックと互換性のあるコーデックが初めから選択されてもよい。
また、上記各実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、これに限らず、音楽、音響、画像等に関しても、本発明は適用可能である。
また、本発明は、上記各実施の形態に限定されず、種々変更して実施することが可能である。
また、上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部又は全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)または、LSI内部の回路セルの接続若しくは設定を再構成可能なリコンフィギュラブル/プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
2011年6月9日出願の特願2011−129422、2011年11月11日出願の特願2011−247330および2012年2月15日出願の特願2012−030419の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
本発明は、通信中の通信端末の一方が利用するコーデックが変更になった場合、通信相手の利用するコーデックのエンコードされる入力信号の帯域幅又はエンコーディングビットレートを調整する機能を有するため、トランスコーディングによる品質劣化を抑える事に有用である。
100,102 UE
200,202,204,206,1100,1102,1104,1106 シグナリング
300,1300,1302,1310,1704,1706 MSC/MGW
1120,1700,1702 ATCF/ATGW
600,700,1500,1900 受信部
602,702,1502,1902 送信部
604 コーデック検出部
606 コーデック帯域幅検出部
608 変更判断部
610,1506,1906,2002 シグナリング生成部
612 トランスコーディング部
704 コーデック折衝部
706,1510,1910 コーデック選択部
708 帯域幅決定部
710,1504,1904 シグナリング解析部
712,1202 コーデックモード変更部
1200 データ解析部
1508,1908 端末位置判断部
1512,1912 経路選択部
1708 SCC AS/CSCF
2000 通信相手コーデック変更検出部

Claims (10)

  1. SDPオファーまたはSDPアンサーを含むIMSシグナリングを用いて、相手端末との通信に利用するコーデックを通信開始時に折衝するコーデック折衝部と、
    前記折衝されたコーデックは複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を1つのセッションの中で変更可能なコーデックであって、
    ネットワークノードから通知される、前記コーデックの入力信号の帯域幅の制限を指示するシグナリングに基づいて、前記相手端末との通信中に、前記コーデックの入力信号の帯域幅を制限する帯域幅決定部と、
    を備える通信端末装置。
  2. 通信開始時の折衝の際、前記折衝されるコーデックに対して入力信号の帯域幅(band width)が指定されない、
    請求項1に記載の通信端末装置。
  3. 前記コーデックの入力信号の帯域幅を制限するシグナリングは、RTCP(Real-time Transport Control Protocol)に含まれる、
    請求項1に記載の通信端末装置。
  4. 前記コーデックの入力信号の帯域幅を制限するシグナリングは、RTPペイロード(Real-time Transport Protocol)のヘッダに含まれる、
    請求項1に記載の通信端末装置。
  5. SDPオファーまたはSDPアンサーを含むIMSシグナリングを用いて、相手端末との通信に利用するコーデックを通信開始時に折衝し、
    前記折衝されたコーデックは複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を1つのセッションの中で変更可能なコーデックであって、
    ネットワークノードから通知される、前記コーデックの入力信号の帯域幅の制限を指示するシグナリングに基づいて、前記相手端末との通信中に、前記コーデックの入力信号の帯域幅を制限する、
    通信方法。
  6. 通信開始時の折衝の際、前記折衝されるコーデックに対して入力信号の帯域幅(band width)が指定されない、
    請求項5に記載の通信方法。
  7. 前記コーデックの入力信号の帯域幅を制限するシグナリングは、RTCP(Real-time Transport Control Protocol)に含まれる、
    請求項5に記載の通信方法。
  8. 前記コーデックの入力信号の帯域幅を制限するシグナリングは、RTPペイロード(Real-time Transport Protocol)のヘッダに含まれる、
    請求項5に記載の通信方法。
  9. 異なるコーデックを使用する第1の通信端末装置と第2の通信端末装置との間の通信に対してトランスコーディングを行うネットワークノードであって、
    前記第1の通信端末装置と前記第2の通信端末装置がそれぞれ使用するコーデックを検出する検出部と、
    前記検出された前記第1の通信端末装置で使用される第1のコーデックは、複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を1つのセッションの中で変更可能なコーデックであって、
    前記検出部での検出結果に基づいて、前記第2の通信端末装置が使用するコーデックの変更を検出した場合、前記第1の通信端末装置の前記第1のコーデック、及び、前記第2の通信端末装置の変更後の第2のコーデックを用いて、前記第1のコーデックの帯域幅の制限を行うか否かを判断する判断部と、
    前記2つの端末の通信中に、前記第1のコーデックの帯域幅を制限すると判断した場合、前記帯域幅を制限させるためのシグナリングを、前記第の通信端末装置へ送信する送信部と、
    を備えるネットワークノード。
  10. 異なるコーデックを使用する第1の通信端末装置と第2の通信端末装置との間の通信に対してトランスコーディングを行うネットワークノードの通信方法であって、
    前記第1の通信端末装置と前記第2の通信端末装置がそれぞれ使用するコーデックを検出し、
    前記検出された前記第1の通信端末装置で使用される第1のコーデックは、複数のコーデックの入力信号の帯域幅をサポートし、かつ、コーデックの入力信号の帯域幅を1つのセッションの中で変更可能なコーデックであり、
    前記検出結果に基づいて、前記第2の通信端末装置が使用するコーデックの変更を検出した場合、前記第1の通信端末装置の前記第1のコーデック、及び、前記第2の通信端末装置の変更後の第2のコーデックを用いて、前記第1のコーデックの帯域幅の制限を行うか否かを判断し、
    前記2つの端末の通信中に、前記第1のコーデックの帯域幅を制限すると判断した場合、前記帯域幅を制限させるためのシグナリングを、前記第の通信端末装置へ送信する、
    通信方法。
JP2013519368A 2011-06-09 2012-05-25 通信端末装置、ネットワークノード及び通信方法 Active JP5947294B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
JP2011129422 2011-06-09
JP2011129422 2011-06-09
JP2011247330 2011-11-11
JP2011247330 2011-11-11
JP2012030419 2012-02-15
JP2012030419 2012-02-15
PCT/JP2012/003410 WO2012169134A1 (ja) 2011-06-09 2012-05-25 ネットワークノード、端末、帯域幅変更判断方法及び帯域幅変更方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2016110022A Division JP6231160B2 (ja) 2011-06-09 2016-06-01 通信端末装置、ネットワークノード及び通信方法

Publications (2)

Publication Number Publication Date
JPWO2012169134A1 JPWO2012169134A1 (ja) 2015-02-23
JP5947294B2 true JP5947294B2 (ja) 2016-07-06

Family

ID=47295726

Family Applications (4)

Application Number Title Priority Date Filing Date
JP2013519368A Active JP5947294B2 (ja) 2011-06-09 2012-05-25 通信端末装置、ネットワークノード及び通信方法
JP2016110022A Active JP6231160B2 (ja) 2011-06-09 2016-06-01 通信端末装置、ネットワークノード及び通信方法
JP2017201265A Active JP6419289B2 (ja) 2011-06-09 2017-10-17 通信端末装置及び通信方法
JP2018189945A Active JP6647364B2 (ja) 2011-06-09 2018-10-05 通信端末装置、通信方法及び集積回路

Family Applications After (3)

Application Number Title Priority Date Filing Date
JP2016110022A Active JP6231160B2 (ja) 2011-06-09 2016-06-01 通信端末装置、ネットワークノード及び通信方法
JP2017201265A Active JP6419289B2 (ja) 2011-06-09 2017-10-17 通信端末装置及び通信方法
JP2018189945A Active JP6647364B2 (ja) 2011-06-09 2018-10-05 通信端末装置、通信方法及び集積回路

Country Status (7)

Country Link
US (3) US9288792B2 (ja)
EP (3) EP2706766B1 (ja)
JP (4) JP5947294B2 (ja)
CN (2) CN107197488B (ja)
ES (1) ES2812123T3 (ja)
PL (1) PL3139696T3 (ja)
WO (1) WO2012169134A1 (ja)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2920998A4 (en) * 2012-11-16 2016-06-15 Ericsson Telefon Ab L M METHOD AND SYSTEM FOR IMPROVED PS-CS HANDOVER OF A USER DEVICE
JP5998923B2 (ja) * 2012-12-28 2016-09-28 富士通株式会社 プログラム、情報処理装置、及び通信方法
WO2015062674A1 (en) * 2013-11-04 2015-05-07 Nokia Solutions And Networks Oy Improved access domain transfer
US9344933B1 (en) * 2014-04-10 2016-05-17 Sprint Communications Company L.P. Mobility management entity (MME) system and method to disable voice over LTE (VoLTE) service of a long term evolution (LTE) base station
EP3217612A4 (en) * 2014-04-21 2017-11-22 Samsung Electronics Co., Ltd. Device and method for transmitting and receiving voice data in wireless communication system
WO2015169210A1 (en) * 2014-05-05 2015-11-12 Mediatek Inc. Method and apparatus for managing a call during a handover procedure in a communications system
US10085196B1 (en) 2014-07-03 2018-09-25 Sprint Communications Company L.P. Wireless communication control based on border gateway protocol
BR112017002286A2 (pt) * 2014-09-05 2019-09-03 Intel Corp impedimento de transcodificação durante continuidade de chamada de voz de rádio única (srvcc)
KR102414522B1 (ko) * 2014-09-25 2022-06-30 삼성전자주식회사 무선 거리 측정 장치 및 방법
WO2016055308A1 (en) * 2014-10-08 2016-04-14 Nokia Solutions And Networks Oy Transfer of communication parameters
US20160323425A1 (en) * 2015-04-29 2016-11-03 Qualcomm Incorporated Enhanced voice services (evs) in 3gpp2 network
CN105100046A (zh) * 2015-05-19 2015-11-25 华为技术有限公司 一种媒体互通方法及其装置
CN107251610B (zh) * 2015-05-20 2020-09-25 松下电器(美国)知识产权公司 通信节点、终端及通信控制方法
US9867106B2 (en) * 2015-12-30 2018-01-09 T-Mobile Usa, Inc. Codec-specific handover thresholds
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)
EP3927012B1 (en) * 2016-03-28 2023-04-12 Panasonic Intellectual Property Corporation of America User equipment, base station and codec mode switching method
EP3497965B1 (en) * 2016-08-11 2022-04-13 Kyocera Corporation Ran-assisted rate adaptation
US10904798B2 (en) * 2016-11-04 2021-01-26 Apple Inc. UE and devices for codec rate adaptation
WO2018170705A1 (zh) * 2017-03-20 2018-09-27 华为技术有限公司 一种业务通信方法及设备
MX2019013558A (es) 2017-05-18 2020-01-20 Fraunhofer-Gesellschaft zur Förderung der Angewandten Forschung Ev Dispositivo de red de gestion.
US11601483B2 (en) * 2018-02-14 2023-03-07 Genband Us Llc System, methods, and computer program products for selecting codec parameters

Family Cites Families (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60026138T2 (de) * 2000-04-26 2006-10-26 Fujitsu Ltd., Kawasaki Mehrpunkt-kommunikationsverfahren und kommunikationssteuereinrichtung
US7142847B2 (en) 2000-08-10 2006-11-28 Ntt Docomo, Inc. Mobile communication system, resource switching method thereof, network control apparatus included therein, same and network control method
US20030028643A1 (en) * 2001-03-13 2003-02-06 Dilithium Networks, Inc. Method and apparatus for transcoding video and speech signals
EP1248431B1 (en) * 2001-03-27 2007-10-31 Sony Deutschland GmbH Method for achieving end-to-end quality of service negotiation for distributed multimedia applications
US20020163908A1 (en) * 2001-05-07 2002-11-07 Ari Lakaniemi Apparatus, and associated method, for synchronizing operation of codecs operable pursuant to a communicaton session
FI20011715A (fi) * 2001-08-27 2003-02-28 Nokia Corp Koodekin toiminnallisen moodin valinta
US7639601B2 (en) * 2002-07-05 2009-12-29 Nortel Networks Limited Methods and apparatus for data communication
CA2496366A1 (en) * 2002-09-23 2004-04-01 Nokia Corporation Bandwidth adaptation
FI116498B (fi) * 2002-09-23 2005-11-30 Nokia Corp Kaistanleveyden mukauttaminen
WO2005036896A2 (en) * 2003-09-12 2005-04-21 Motorola, Inc. , A Corporation Of The State Of Delaware Apparatus and method for supporting enhanced transcoding functionality
US7751359B1 (en) * 2003-11-26 2010-07-06 Ericsson Ab Call origination in a CDMA legacy MS domain using SIP
JP2005236388A (ja) * 2004-02-17 2005-09-02 Nippon Telegr & Teleph Corp <Ntt> リソース管理方法、リソース管理装置、リソース管理プログラム及びそのプログラムを記録した記録媒体
US7668712B2 (en) * 2004-03-31 2010-02-23 Microsoft Corporation Audio encoding and decoding with intra frames and adaptive forward error correction
FI119533B (fi) 2004-04-15 2008-12-15 Nokia Corp Audiosignaalien koodaus
US7596486B2 (en) * 2004-05-19 2009-09-29 Nokia Corporation Encoding an audio signal using different audio coder modes
US7463901B2 (en) * 2004-08-13 2008-12-09 Telefonaktiebolaget Lm Ericsson (Publ) Interoperability for wireless user devices with different speech processing formats
US20060230169A1 (en) * 2004-11-15 2006-10-12 Kaplan Mark M System and method to simultaneously transcode audio and video content for optimized streaming via mobile telecommunications
KR100735274B1 (ko) * 2004-11-18 2007-07-03 삼성전자주식회사 트랜스코더를 구비한 분산형 멀티미디어 전송 네트워크의트랜스코딩 방법 및 장치
DE102005006174A1 (de) * 2005-02-10 2006-08-17 Siemens Ag Signalisierung eines Wechsels von einem ersten Dienst zu einem zweiten Dienst während einer Gesprächsverbindung
US20060251093A1 (en) * 2005-05-03 2006-11-09 Nokia Corporation Signaling quality of service (QoS) parameters for a multimedia session
DE102005050586B3 (de) * 2005-10-21 2006-11-02 Siemens Ag Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
US7593325B1 (en) * 2005-12-28 2009-09-22 At&T Corp. Method and apparatus for controlling call volume in a packet network
US8019371B2 (en) * 2005-12-28 2011-09-13 Vantrix Corporation Multi-users real-time transcoding system and method for multimedia sessions
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
GB2440381B (en) * 2006-07-27 2008-11-05 Motorola Inc An internet protocol multimedia subsystem network element and method of operation therefor
JP4827652B2 (ja) * 2006-08-10 2011-11-30 富士通株式会社 中継装置、中継方法および中継プログラム
KR100744567B1 (ko) * 2006-09-29 2007-08-01 한국전자통신연구원 멀티 네트워크 멀티 코덱 환경에서 트랜스코딩 횟수를최소화하는 장치 및 방법
US7907523B2 (en) * 2006-12-05 2011-03-15 Electronics And Telecommunications Research Institute Method and apparatus for controlling variable bit-rate voice codec
CN101601269B (zh) * 2006-12-08 2015-11-25 艾利森电话股份有限公司 用户媒体与通告媒体之间切换的方法,系统及通告服务器
EP2163068B1 (en) * 2007-05-22 2016-02-03 Telefonaktiebolaget LM Ericsson (publ) Method, apparatuses and computer program for dynamically configuring a proxy call session control function of the ip multimedia subsystem from a policy control rules server
US8625608B2 (en) * 2007-07-09 2014-01-07 Telefonaktiebolaget L M Ericsson (Publ) Adaptive rate control in a communications system
EP2204011B1 (en) * 2007-10-16 2018-05-30 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for improving the efficiency of resource utilisation in a communications system
US9479967B1 (en) * 2007-10-26 2016-10-25 Genband Us Llc Enhanced media gateway
US7801543B2 (en) * 2007-12-14 2010-09-21 Motorola, Inc. Dynamic vocoder assignment in a communication system
KR101167523B1 (ko) * 2008-01-17 2012-07-20 노키아 코포레이션 무선 시스템에서의 적응적 멀티-레이트 코덱 비트 레이트 제어
ATE548884T1 (de) * 2008-02-11 2012-03-15 Nokia Siemens Networks Oy Verfahren und vorrichtungen zur codec-änderung bei laufenden anrufen auf ip-basierter a- schnittstelle
US8204022B2 (en) * 2008-02-20 2012-06-19 Alcatel Lucent Method of providing transcoding during voice-over-internet protocol handoff
WO2009118038A1 (en) * 2008-03-25 2009-10-01 Telefonaktiebolaget Lm Ericsson (Publ) Policy and charging control architecture
US8619761B2 (en) * 2008-05-02 2013-12-31 Nokia Corporation Circuit switched domain codec list for single radio voice call continuity
KR101523590B1 (ko) * 2009-01-09 2015-05-29 한국전자통신연구원 통합 인터넷 프로토콜망의 코덱 모드 제어방법 및 단말기
GB2454606C (en) * 2009-02-02 2017-01-25 Skype Ltd Method of transmitting data in a communication system
EP2417749A4 (en) * 2009-04-07 2017-01-11 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for session negotiation
KR101056209B1 (ko) * 2009-04-14 2011-08-11 포항공과대학교 산학협력단 이종망간 핸드오버시 적응적 코덱 변환 방법 및 적응적 코덱 변환 기능을 갖는 sip 클라이언트 장치
US9357568B2 (en) * 2009-06-16 2016-05-31 Futurewei Technologies, Inc. System and method for adapting an application source rate to a load condition
JP5629091B2 (ja) 2009-12-18 2014-11-19 パナソニック株式会社 配線ダクト接続装置
US9106672B2 (en) * 2009-12-31 2015-08-11 Nokia Technologies Oy Method and apparatus for performing multiple forms of communications in one session
JP2011247330A (ja) 2010-05-26 2011-12-08 Toyota Motor Corp 電磁式リニア弁
JP2012030419A (ja) 2010-07-29 2012-02-16 Kyocera Mita Corp 画像形成装置
US8665828B2 (en) * 2010-08-18 2014-03-04 Blackberry Limited Methods and apparatus to maintain call continuity
SI3239979T1 (sl) * 2010-10-25 2024-09-30 Voiceage Evs Llc Kodiranje generičnih zvočnih signalov pri nizkih bitnih hitrostih in majhni zakasnitvi
WO2012095700A1 (en) * 2011-01-12 2012-07-19 Nokia Corporation An audio encoder/decoder apparatus
US9026434B2 (en) * 2011-04-11 2015-05-05 Samsung Electronic Co., Ltd. Frame erasure concealment for a multi rate speech and audio codec

Also Published As

Publication number Publication date
EP2706766A1 (en) 2014-03-12
ES2812123T3 (es) 2021-03-16
JP2018042261A (ja) 2018-03-15
JP2018207546A (ja) 2018-12-27
CN103548369B (zh) 2017-07-21
EP2706766B1 (en) 2016-11-30
JP2016181919A (ja) 2016-10-13
EP3139696B1 (en) 2020-05-20
EP3684104A1 (en) 2020-07-22
JP6647364B2 (ja) 2020-02-14
CN107197488B (zh) 2020-05-22
US20140099966A1 (en) 2014-04-10
CN107197488A (zh) 2017-09-22
JP6419289B2 (ja) 2018-11-07
US20160157136A1 (en) 2016-06-02
CN103548369A (zh) 2014-01-29
EP2706766A4 (en) 2015-12-09
US10841842B2 (en) 2020-11-17
PL3139696T3 (pl) 2020-11-16
US11647428B2 (en) 2023-05-09
WO2012169134A1 (ja) 2012-12-13
JPWO2012169134A1 (ja) 2015-02-23
US20210029595A1 (en) 2021-01-28
US9288792B2 (en) 2016-03-15
EP3139696A1 (en) 2017-03-08
JP6231160B2 (ja) 2017-11-15

Similar Documents

Publication Publication Date Title
JP6419289B2 (ja) 通信端末装置及び通信方法
JP6434601B2 (ja) ネットワークノード及び通信方法
JP6420328B2 (ja) ネットワークノード及びシグナリング処理方法
JPWO2016185649A1 (ja) 通信ノード、端末及び通信制御方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150512

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150512

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160209

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160412

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: 20160510

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160602

R150 Certificate of patent or registration of utility model

Ref document number: 5947294

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150