JP6420328B2 - ネットワークノード及びシグナリング処理方法 - Google Patents

ネットワークノード及びシグナリング処理方法 Download PDF

Info

Publication number
JP6420328B2
JP6420328B2 JP2016519094A JP2016519094A JP6420328B2 JP 6420328 B2 JP6420328 B2 JP 6420328B2 JP 2016519094 A JP2016519094 A JP 2016519094A JP 2016519094 A JP2016519094 A JP 2016519094A JP 6420328 B2 JP6420328 B2 JP 6420328B2
Authority
JP
Japan
Prior art keywords
codec
atgw
sdp
neighboring
sdp offer
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.)
Expired - Fee Related
Application number
JP2016519094A
Other languages
English (en)
Other versions
JPWO2015174018A1 (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 JPWO2015174018A1 publication Critical patent/JPWO2015174018A1/ja
Application granted granted Critical
Publication of JP6420328B2 publication Critical patent/JP6420328B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • 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/14—Reselecting a network or an air interface

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

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

Claims (14)

  1. ｅＳＲＶＣＣ（ｅｎｈａｎｃｅｄ Ｓｉｎｇｌｅ Ｒａｄｉｏ Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ）に用いるＡＴＣＦ（Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）を有するネットワークノードであって、
    ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）シグナリングに含まれるＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）オファーまたはＳＤＰアンサーを受信する受信部と、
    前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれるコーデックの情報を取得するＳＤＰ解析部と、
    ＡＴＧＷ（Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｇａｔｅｗａｙ）または近隣のＭＧＷ（Ｍｅｄｉａ Ｇａｔｅｗａｙ）でサポートしているコーデックの情報、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているトランスコーディングの情報、および近隣のＣＳ（Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｉｎｇ）網がサポートしているコーデックの情報の少なくとも一つを保持するデータ格納部と、
    前記ＳＤＰ解析部で取得した前記コーデックの情報、および前記データ格納部から読み出した情報を用いて、前記ＡＴＣＦから通信端末へコーデックを再折衝するためのＳＤＰオファーの送信を可能にするか否かを判断する判断部と、
    を有するネットワークノード。
  2. 前記判断部における、前記ＡＴＣＦから前記通信端末へコーデックを再折衝するための前記ＳＤＰオファーの送信を可能にするか否かの判断は、
    前記ＡＴＧＷで通話データをアンカーするか否か、または、前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信するか否か、の判断である、
    請求項１記載のネットワークノード。
  3. 前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているコーデックと一致しない場合、
    前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    請求項２記載のネットワークノード。
  4. 前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしている前記コーデックと一致しない場合において、
    前記ＳＤＰオファーから前記コーデックを削除して送信する場合には、前記判断部は、前記ＡＴＧＷで通話データをアンカーすると判断し、
    前記ＳＤＰオファーから前記コーデックを削除しないで送信する場合には、前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    請求項３記載のネットワークノード。
  5. 前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、
    前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    請求項２記載のネットワークノード。
  6. 前記受信部で前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷでサポートしているコーデックと一致しない場合、前記判断部は、前記通信端末にコーデック再折衝のための前記ＳＤＰオファーを送信すると判断する、
    請求項２記載のネットワークノード。
  7. 前記受信部で前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記判断部は、前記通信端末にコーデック再折衝のための前記ＳＤＰオファーを送信すると判断する、
    請求項２記載のネットワークノード。
  8. ｅＳＲＶＣＣ（ｅｎｈａｎｃｅｄ Ｓｉｎｇｌｅ Ｒａｄｉｏ Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ）に用いるＡＴＣＦ（Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）を有するネットワークノードにおけるシグナリング処理方法であって、
    ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）シグナリングに含まれるＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）オファーまたはＳＤＰアンサーを受信し、
    前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれるコーデックの情報を取得し、
    ＡＴＧＷ（Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｇａｔｅｗａｙ）または近隣のＭＧＷ（Ｍｅｄｉａ Ｇａｔｅｗａｙ）でサポートしているコーデックの情報、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているトランスコーディングの情報、および近隣のＣＳ（Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｉｎｇ）網がサポートしているコーデックの情報の少なくとも一つを取得し、
    前記取得した情報を用いて、前記ＡＴＣＦから通信端末へコーデックを再折衝するためのＳＤＰオファーの送信を可能にするか否かを判断する、
    シグナリング処理方法。
  9. 前記ＡＴＣＦから前記通信端末へコーデックを再折衝するための前記ＳＤＰオファーの送信を可能にするか否かの判断は、
    前記ＡＴＧＷで通話データをアンカーするか否か、または、
    前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信するか否か、の判断である、
    請求項８記載のシグナリング方法。
  10. セッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているコーデックと一致しない場合、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    請求項９記載のシグナリング方法。
  11. セッションセットアップの際に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしている前記コーデックと一致しない場合において、
    前記ＳＤＰオファーから前記コーデックを削除して送信する場合には、前記ＡＴＧＷで通話データをアンカーすると判断し、
    前記ＳＤＰオファーから前記コーデックを削除しないで送信する場合には、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    請求項１０記載のシグナリング方法。
  12. セッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    請求項９記載のシグナリング方法。
  13. 前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷでサポートしているコーデックと一致しない場合、前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信すると判断する、
    請求項９記載のシグナリング方法。
  14. 前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信すると判断する、
    請求項９記載のシグナリング方法。
JP2016519094A 2014-05-13 2015-04-20 ネットワークノード及びシグナリング処理方法 Expired - Fee Related JP6420328B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201461992222P 2014-05-13 2014-05-13
US61/992,222 2014-05-13
JP2014138668 2014-07-04
JP2014138668 2014-07-04
PCT/JP2015/002134 WO2015174018A1 (ja) 2014-05-13 2015-04-20 ネットワークノード及びシグナリング処理方法

Publications (2)

Publication Number Publication Date
JPWO2015174018A1 JPWO2015174018A1 (ja) 2017-04-20
JP6420328B2 true JP6420328B2 (ja) 2018-11-07

Family

ID=54479573

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016519094A Expired - Fee Related JP6420328B2 (ja) 2014-05-13 2015-04-20 ネットワークノード及びシグナリング処理方法

Country Status (4)

Country Link
US (1) US9967782B2 (ja)
EP (1) EP3145165B1 (ja)
JP (1) JP6420328B2 (ja)
WO (1) WO2015174018A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11089519B2 (en) * 2016-04-13 2021-08-10 Qualcomm Incorporated Migration of local gateway function in cellular networks
US11082455B2 (en) * 2017-05-03 2021-08-03 T-Mobile Usa, Inc. Network gateway transcoder-utilization-aware session control
CN112640390B (zh) * 2018-09-07 2023-06-16 苹果公司 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法
US11509772B2 (en) * 2018-11-13 2022-11-22 Qualcomm Incorporated Methods for increasing Voice-over-Internet Protocol (VoIP) network coverage
US11689583B2 (en) 2018-12-10 2023-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Network node, entity and methods performed therein for handling a communication session in a communication network

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005050586B3 (de) * 2005-10-21 2006-11-02 Siemens Ag Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
JP2009147692A (ja) * 2007-12-14 2009-07-02 Ntt Docomo Inc 移動通信端末、交換局、蓄積装置、及び、メッセージ蓄積方法
US8204022B2 (en) * 2008-02-20 2012-06-19 Alcatel Lucent Method of providing transcoding during voice-over-internet protocol handoff
JP5140696B2 (ja) * 2010-04-26 2013-02-06 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム及び移動局
JP4944232B2 (ja) * 2010-08-06 2012-05-30 株式会社エヌ・ティ・ティ・ドコモ 移動通信方法及び移動通信システム
JP2012105211A (ja) * 2010-11-12 2012-05-31 Ntt Docomo Inc コアネットワークおよび通信システム
WO2013072193A2 (en) * 2011-11-14 2013-05-23 Nokia Siemens Networks Oy Method and apparatus for allocating a transfer function
TR201907782T4 (tr) * 2011-11-30 2019-06-21 Panasonic Ip Corp America Ağ düğümü ve iletişim yöntemi.
EP2839695B1 (en) * 2012-04-17 2016-06-08 Telefonaktiebolaget LM Ericsson (publ) Srvcc handover of calls between access networks with active codec selection

Also Published As

Publication number Publication date
EP3145165A4 (en) 2017-04-26
EP3145165B1 (en) 2019-10-16
US9967782B2 (en) 2018-05-08
EP3145165A1 (en) 2017-03-22
US20170026878A1 (en) 2017-01-26
WO2015174018A1 (ja) 2015-11-19
JPWO2015174018A1 (ja) 2017-04-20

Similar Documents

Publication Publication Date Title
JP6434601B2 (ja) ネットワークノード及び通信方法
JP6419289B2 (ja) 通信端末装置及び通信方法
KR101446028B1 (ko) 패킷 스위칭된 도메인으로부터 회로 스위칭된 도메인으로 비디오 호를 핸드 오버하기 위한 방법 및 디바이스
JP6420328B2 (ja) ネットワークノード及びシグナリング処理方法
JP6787884B2 (ja) 通信ノード、端末及び通信制御方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180220

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181011

R150 Certificate of patent or registration of utility model

Ref document number: 6420328

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees