Nothing Special   »   [go: up one dir, main page]

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

    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00—Speech 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/04—Speech 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/16—Vocoder architecture
    • G10L19/18—Vocoders using multiple modes
    • G10L19/22—Mode decision, i.e. based on audio signal content versus external parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H04W36/144—Reselecting a network or an air interface over a different radio air interface technology
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00—Speech 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/04—Speech 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/16—Vocoder architecture
    • G10L19/173—Transcoding, i.e. converting between two coded representations avoiding cascaded coding-decoding
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00—Speech 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/04—Speech 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/16—Vocoder architecture
    • G10L19/18—Vocoders using multiple modes
    • G10L19/24—Variable rate codecs, e.g. for generating different qualities using a scalable representation such as hierarchical encoding or layered encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control 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/00224—Control 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/00226—Control 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0066—Transmission 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/181—Transcoding 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

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

Description

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

Claims (12)

  1. 第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末で使用されるコーデック及びコーデックモードを判断する通信ノードであって、
    前記第１の網における通信で使用しているコーデック及びコーデックモードを示す情報と、
    前記一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、
    前記第２の網がサポートしているコーデック及びコーデックモードを示す情報と、
    の共通部分を前記２つの端末で使用されるコーデック及びコーデックモードに設定する判断部と、
    設定された前記２つの端末で使用されるコーデック及びコーデックモードへの変更を前記２つの端末へ要求するためのシグナリングを生成する生成部と、
    を具備する通信ノード。
  2. 前記判断部は、前記共通部分が存在しない場合に、
    前記第１の網における通信で使用しているコーデックに、別のコーデックとの互換モードが存在し、かつ、前記一方の端末がサポートしているコーデック及び前記第２の網がサポートしているコーデックに、前記別のコーデックが含まれる場合、前記別のコーデック又は前記別のコーデックとの互換モードを、前記２つの端末で使用されるコーデック及びコーデックモードに設定する、
    請求項１に記載の通信ノード。
  3. 前記判断部は、サービスオペレータのポリシが存在する場合には前記ポリシに従って前記２つの端末で使用されるコーデック及びコーデックモードを設定し、前記ポリシが存在しない場合には前記共通部分を前記２つの端末で使用されるコーデック及びコーデックモードに設定する、
    請求項１又は２に記載の通信ノード。
  4. 第１の網において通信を行う２つの端末のうち、前記第１の網と異なる網にハンドオーバする端末であって、
    ハンドオーバによる接続先網を検出する接続先検出部と、
    前記接続先網で使用するコーデックを検出するコーデック検出部と、
    前記検出された接続先網と、前記検出されたコーデックとに基づいて、前記２つの端末で使用されるコーデックで用いるエンコード方式の制限が必要であるか否かを判断する判断部と、
    前記エンコード方式の制限が必要であると判断された場合、前記エンコード方式を制限するための内部コマンドをエンコーダに送信するコマンド送信部と、
    を具備する端末。
  5. 前記第１の網がパケット交換網であり、前記接続先網が回線交換網であり、
    前記判断部は、前記検出されたコーデックがビット誤り耐性を有さないエンコード方式を用いるコーデックである場合に、前記エンコード方式の制限が必要であると判断する、
    請求項４に記載の端末。
  6. 前記エンコード方式の制限が必要であると判断された場合、前記接続先網にハンドオーバしたこと、又は、前記エンコード方式の制限が必要であることを通信相手端末に通知するためのシグナリングを生成する生成部と、
    前記シグナリングを前記通信相手端末に送信する送信部と、を更に具備する、
    請求項４に記載の端末。
  7. 前記エンコード方式の制限が必要であると判断された場合、
    前記端末が前記接続先網にハンドオーバしたこと、又は、前記エンコード方式の制限が必要であることを通知するためのシグナリングは、前記２つの端末のデータ経路上に存在する通信ノードで生成され、前記端末の通信相手端末に送信される、
    請求項４に記載の端末。
  8. 前記シグナリングを受け取った前記通信相手端末は、前記エンコード方式を制限するための内部コマンドを、前記通信相手端末内のエンコーダに送信する、
    請求項６又は７に記載の端末。
  9. 前記シグナリングは、ＲＴＰ（Real-time Transport Protocol）ペイロードヘッダに含まれる、
    請求項６から８の何れかに記載の端末。
  10. 前記シグナリングは、ＲＴＣＰ（Real-time Transport Protocol Control Protocol）に含まれる、
    請求項６から８の何れかに記載の端末。
  11. 第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末で使用されるコーデック及びコーデックモードを判断する通信制御方法であって、
    前記第１の網における通信で使用しているコーデック及びコーデックモードを示す情報と、
    前記一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、
    前記第２の網がサポートしているコーデック及びコーデックモードを示す情報と、
    の共通部分を前記２つの端末で使用されるコーデック及びコーデックモードに設定し、
    設定された前記２つの端末で使用されるコーデック及びコーデックモードへの変更を前記２つの端末へ要求するためのシグナリングを生成する、
    通信制御方法。
  12. 第１の網において通信を行う２つの端末のうち、前記第１の網と異なる網にハンドオーバする端末における通信制御方法であって、
    ハンドオーバによる接続先網を検出し、
    前記接続先網で使用するコーデックを検出し、
    前記検出された接続先網と、前記検出されたコーデックとに基づいて、前記２つの端末で使用されるコーデックで用いるエンコード方式の制限が必要であるか否かを判断し、
    前記エンコード方式の制限が必要であると判断された場合、前記エンコード方式を制限するための内部コマンドをエンコーダに送信する、
    通信制御方法。
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)
ES2881704T3 (es) * 2017-05-18 2021-11-30 Fraunhofer Ges Forschung Dispositivo de red de gestión
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
CN112640390B (zh) * 2018-09-07 2023-06-16 苹果公司 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法
JP7523267B2 (ja) 2020-07-10 2024-07-26 株式会社Ｎｔｔドコモ 通信制御装置

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
BR0017311B1 (pt) * 2000-08-14 2014-11-11 Nokia Siemens Networks Oy Método a ser realizado em um sistema de comunicação, sistema de comunicação, e, elemento de rede
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
EP1582046B1 (en) * 2003-01-09 2008-03-12 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
EP1721435B1 (en) * 2004-03-04 2013-05-08 Telefonaktiebolaget LM Ericsson (publ) Method and node for selecting a codec type or configuration by extending the list comprising codecs for transcoder/tandem free operation by further codecs supported by the node
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
DE112006001591T5 (de) * 2005-06-15 2008-04-30 Telefonaktiebolaget Lm Ericsson (Publ) Adaptiver Mobiltelefonie-Sprachtransport über ein Internetprotokollnetz
JP5394735B2 (ja) * 2005-07-11 2014-01-22 パケットビデオ コーポレーション データ転送システム及び方法
US7974270B2 (en) * 2005-09-09 2011-07-05 Kineto Wireless, Inc. Media route optimization in network communications
WO2007034809A1 (ja) * 2005-09-20 2007-03-29 Taisho Pharmaceutical Co., Ltd. 組み換え蛋白質産生のための宿主細胞
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
CN101300316A (zh) * 2005-11-02 2008-11-05 太阳化学公司 用于非织造基材的柔性版和凹版印刷油墨
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
EP3641239B1 (en) * 2006-02-10 2022-08-03 III Holdings 2, LLC System and method for connecting mobile devices
US8422382B2 (en) * 2006-08-21 2013-04-16 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for adapting transmission of encoded media
WO2008098501A1 (fr) * 2007-02-02 2008-08-21 Huawei Technologies Co., Ltd. Procede, appareil et systeme de reglage de relevement gsm
RU2450485C2 (ru) * 2008-01-17 2012-05-10 Нокиа Корпорейшн Управление битовой скоростью адаптивного мультискоростного кодека в системе беспроводной связи
US20090268635A1 (en) * 2008-04-29 2009-10-29 Gallagher Michael D Method and Apparatus for Mapping E-UTRAN Cells at Call Establishment
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
CN103548369B (zh) * 2011-06-09 2017-07-21 松下电器（美国）知识产权公司 网络节点、终端、带宽变更判断方法及带宽变更方法
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 中兴通讯股份有限公司 一种单无线语音连续切换的方法及系统
ES2728678T3 (es) * 2011-11-30 2019-10-28 Panasonic Ip Corp America Nodo de red y procedimiento de comunicación
WO2013156063A1 (en) 2012-04-17 2013-10-24 Telefonaktiebolaget L M Ericsson (Publ) Srvcc handover of calls between access networks with active codec selection
JP5943082B2 (ja) * 2012-08-24 2016-06-29 日本電気株式会社 リモート通信システム、サーバ装置、リモート通信方法、および、プログラム
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
JP6385936B2 (ja) * 2013-08-22 2018-09-05 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 音声符号化装置およびその方法
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
CN107251610B (zh) 2020-09-25
US10911988B2 (en) 2021-02-02
JP6787884B2 (ja) 2020-11-18
US20180041924A1 (en) 2018-02-08
CN107251610A (zh) 2017-10-13
WO2016185649A1 (ja) 2016-11-24

Similar Documents

Publication Publication Date Title
JP6647364B2 (ja) 通信端末装置、通信方法及び集積回路
JP6434601B2 (ja) ネットワークノード及び通信方法
JP6787884B2 (ja) 通信ノード、端末及び通信制御方法
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