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

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

Info

Publication number
WO2015174018A1
WO2015174018A1 PCT/JP2015/002134 JP2015002134W WO2015174018A1 WO 2015174018 A1 WO2015174018 A1 WO 2015174018A1 JP 2015002134 W JP2015002134 W JP 2015002134W WO 2015174018 A1 WO2015174018 A1 WO 2015174018A1
Authority
WO
WIPO (PCT)
Prior art keywords
codec
atgw
sdp
sdp offer
supported
Prior art date
Application number
PCT/JP2015/002134
Other languages
English (en)
French (fr)
Inventor
貴子 堀
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
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 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to EP15792804.5A priority Critical patent/EP3145165B1/en
Priority to JP2016519094A priority patent/JP6420328B2/ja
Publication of WO2015174018A1 publication Critical patent/WO2015174018A1/ja
Priority to US15/285,716 priority patent/US9967782B2/en

Links

Images

Classifications

    • 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]

Definitions

  • the present disclosure relates to a network node used in a mobile communication scheme and a signaling processing method executed by the network node.
  • VoIP Voice over Long Term Evolution
  • VoLTE call the area where VoLTE service can be received is a limited area. Therefore, when going out of the VoLTE service area during a VoLTE voice call (hereinafter referred to as a VoLTE call), it is necessary to switch to a call using a conventional circuit switching system.
  • SRVCC Single Radio Voice Call Continuity
  • FIG. 1 shows part of a 3GPP mobile communication network configuration.
  • the mobile communication network shown in FIG. 1 is e-UTRAN (evolved Universal Terrestrial Radio Access Network), e-UTRAN base station (e-node B), PS network, CS network, CS network base station subsystem, non-patent document 2, IMS (IP Multimedia Subsystem) described in Non-Patent Document 3.
  • e-UTRAN is a radio access network capable of providing VoLTE service.
  • the PS network provides a VoLTE service, and includes a packet data network gateway (P-GW), a serving gateway (S-GW), and a mobility management entity (MME).
  • the CS network is composed of a mobile switching center (MSC) and a media gate way (MGW).
  • the base station subsystem of the CS network comprises an RNC (Radio Network Controller) and a nodeB.
  • the IMS performs call control and the like, and includes a CSCF (Call Session Control Function) and an SCC AS (Service Centralization and Continuity Application Server).
  • MSC and MGW are represented as one node (MSC / MGW 110) in FIG. 1 and FIG. 2, they may be represented as separate nodes.
  • FIG. 1 it is assumed that UE 100 and UE 102, which are mobile communication terminals (UE: User Equipment), are initially connected to the PS network (however, the radio access network, base station and PS network on UE 102 side are not shown). ).
  • UE 100 and UE 102 start a call, a session setup process is performed. That is, by transmitting / receiving an offer / answer of SDP (Session Description Protocol) by signaling of IMS between the UE 100 and the UE 102, a codec and the like used in a call are negotiated.
  • FIG. 5 shows an example of IMS signaling transmission / reception at the time of session setup. IMS signaling is transmitted and received (not shown in FIG.
  • FIG. 6 shows an example of the SDP offer / answer.
  • AMR and AMR-WB described later are offered, and AMR is selected by an answer.
  • HO Hand Over
  • Path A, Path B, and Path C indicated by solid lines in FIG. 1 indicate paths through which call data passes.
  • reference numerals 200, 202, 204 and 206 indicated by broken lines in FIG. 1 indicate paths through which signaling in SRVCC handover processing passes.
  • FIG. 2 is a sequence chart showing an operation of SRVCC handover processing.
  • the UE 100 and the UE 102 are initially connected to the PS network (e-UTRAN), respectively, and the call data between the UE 100 and the UE 102 is transmitted and received through the Path A.
  • the e-node B detects this and exchanges core network signaling (hereinafter referred to as signaling) with the RNC / node B via the MME, MSC / MGW 110 Signaling 200 shown in Fig. 1. Steps (hereinafter "ST") 200 shown in Fig. 2).
  • signaling core network signaling
  • a data path in the CS network is prepared between node B and MSC / MGW 110, and when the preparation is completed, MME instructs UE 100 to hand over to UTRAN (CS network) via e-node B. Is issued.
  • MSC / MGW 110 exchanges signaling of IMS (hereinafter IMS signaling) with UE 102 via CSCF / SCC AS of the UE 100's own network (signaling 202 shown in FIG. 1; ST 202 shown in FIG. 2).
  • IMS signaling signaling of IMS
  • UE 102 via CSCF / SCC AS of the UE 100's own network
  • an instruction is issued to switch the transmission / reception destination of the call data of the UE 102 from the UE 100 to the MSC / MGW 110, and the Path B is established.
  • the UE 100 exchanges signaling with the MSC / MGW 110 via the RNC / node B (signaling 204 shown in FIG. 1; ST 204 shown in FIG. 2). This establishes Path C.
  • Path C After Path C is established, the MSC / MGW 110 exchanges signaling with the P-GW / S-GW via the MME (signaling 206 shown in FIG. 1; ST 206 shown in FIG. 2). Thus, Path A is deleted.
  • SRVCC enhanced-SRVCC
  • ATCF Access Transfer Control Function
  • FIG. 3 shows part of a 3GPP mobile communication network configuration that enables eSRVCC. Similar to FIG. 1, the mobile communication network shown in FIG. 3 is composed of an e-UTRAN, an e-node B, a PS network, a CS network, a base station subsystem of the CS network, and an IMS.
  • IMS in addition to CSCF and SCC AS, there are ATCF (Access Transfer Control Function) and ATGW (Access Transfer GateWay).
  • FIG. 3 and FIG. 4 show ATCF and ATGW as one node (ATCF / ATGW 320), they may be shown as separate nodes.
  • the UE 100 and the UE 102 are initially connected to the PS network (however, the radio access network on the UE 102 side, the base station and the PS network are not shown). That is, it is assumed that a VoLTE call is being performed between the UE 100 and the UE 102. At this time, it is assumed that the UE 100 performs handover (HO: Hand Over) to the CS network in the middle of a call.
  • HO Hand Over
  • Path A, Path B, Path C, and Path D indicated by solid lines in FIG. 3 indicate paths through which call data passes.
  • 300, 302, 304 and 306, which are indicated by broken lines in FIG. 3, indicate paths through which signaling in the eSR VCC handover process and IMS signaling pass.
  • FIG. 4 is a sequence chart showing an operation of eSRVCC handover.
  • the UE 100 and the UE 102 are initially connected to the PS network (e-UTRAN) respectively.
  • ATCF anchors IMS signaling in ATCF / ATGW 320, and ATGW anchors call data that is, at the start of a call between UE 100 and UE 102, the IMS signaling of the start of the call is relayed by the ATCF of the network (the visited network) to which the UE is connected, and the ATCF needs an anchor for call data at the ATGW. If determined, the ATGW of the UE's visited network is assigned as the anchor point of the call data.
  • call data between the UE 100 and the UE 102 is transmitted and received through the Path A and the Path B.
  • the e-node B When the UE 100 tries to move away from the coverage area of the e-UTRAN, the e-node B detects this and exchanges signaling with the RNC / node B via the MME and the MSC / MGW 110 (signalling 300 shown in FIG. 3). ST300 shown in 4). In ST 300, a data path in the CS network is prepared between node B and MSC / MGW 110, and when preparation is complete, MME instructs UE 100 to hand over to UTRAN (CS network) via e-node B. Is issued.
  • the MSC / MGW 110 sends IMS signaling to the ATCF of the visited network of the UE 100.
  • an instruction of path switching is issued from the ATCF to the ATGW in the area network where the UE 100 is located, and the call data transmission / reception destination of the ATGW is switched from the UE 100 to the MSC / MGW 110 (signaling 302 shown in FIG. 3. ST 302 shown in FIG. 4). That is, Path C is established.
  • the ATCF transmits notification signaling (IMS signaling) to the SCC-AS (signaling 302 shown in FIG. 3; ST 302 shown in FIG. 4).
  • the UE 100 exchanges signaling with the MSC / MGW 110 via the RNC / node B (signaling 304 shown in FIG. 3; ST 304 shown in FIG. 4). Thereby, Path D is established.
  • the MSC / MGW 110 exchanges signaling with the P-GW / S-GW via the MME (signaling 306 shown in FIG. 3; ST 306 shown in FIG. 4). Thereby, Path B is deleted.
  • SRVCC In the configuration of SRVCC in FIG. 1, for example, while UE 100 contracted by a Japanese mobile phone company roams to a mobile phone network in Europe, the CS network is in progress during a call with UE 102 also located in the same country in Europe. Even when the handover is performed, the IMS signaling between the MGW and the UE 102 is transmitted and received via Japan, and there is a problem that the signaling between the MGW and the UE 102 takes time.
  • the MGW and the ATCF are usually provided close to each other in the same country. Furthermore, signaling is only performed between the MGW and the ATCF, and signaling with the UE 102 is not necessary. As a result, the time taken to switch data paths can be shortened.
  • AMR adaptive multi-rate
  • NB narrowband
  • AMR adaptive multi-rate wideband
  • WB wideband
  • Non-Patent Document 4 there is also a codec used in a PS network (VoLTE), such as EVS (Enhanced Voice Service) described in Non-Patent Document 4.
  • VoLTE PS network
  • EVS Enhanced Voice Service
  • the narrow band (NB: Narrowband) codec is a codec that performs encoding and decoding processing of a digital acoustic signal sampled at 8 kHz.
  • a narrow band codec generally has a frequency band of 300 Hz to 3.4 kHz, the frequency band is not limited to this and may be in the range of 0 to 4 kHz.
  • the wideband codec is a codec that performs encoding and decoding processing of a digital acoustic signal sampled at 16 kHz. Note that although a wideband codec generally has a frequency band of 50 Hz to 7 kHz, the frequency band is not limited to this and may be in the range of 0 to 8 kHz.
  • a super wide band (SWB: Super Wideband) codec is a codec that performs encoding and decoding processing of a digital acoustic signal sampled at 32 kHz.
  • the ultra wideband codec generally has a frequency band of 50 Hz to 14 kHz, but the frequency band is not limited thereto and is not limited as long as it is in the range of 0 to 16 kHz.
  • 3GPP TS 23.216 v12.6.0 Single Radio Voice Call Continuity (SRVCC)”
  • 3GPP TS 23.228 v12.0.0 IP Multimedia Subsystem (IMS); Stage 2”
  • 3GPP TS 23.237 v12.6.0 IP Multimedia Subsystem (IMS) Service Continuity”
  • 3GPP TS 22.813 v10.0.0 Student “Study of Use Cases and Requirements for Enhanced Voice Codecs for the Evolved Packet System (EPS)”
  • EPS Evolved Packet System
  • the codec used by the PS network is not supported by the CS network
  • the codec used by the UE 100 is the CS network. Change to a supported codec.
  • the first method is to perform transcoding in MSC / MGW or ATCF / ATGW.
  • the second method is a method of changing the codec used in the UE 102 to the same codec as the UE 100 after the change.
  • the former transcoding method requires that MSC / MGW or ATCF / ATGW support transcoding.
  • the speech quality may be degraded due to transcoding.
  • the latter method of changing the codec requires codec renegotiation by IMS signaling in order to change the codec of the UE 102.
  • IMS signaling for path switching at the time of handover of the UE 100 terminates at ATCF, so IMS signaling for changing the codec of the UE 102 can not be sent.
  • Patent Document 1 even when the eSRVCC scheme is used on the network side, it is detected whether or not the UE has a function of performing handover to CS, that is, whether or not the UE is compatible with SRVCC. Discloses a method in which the communication path is not anchored by the ATGW.
  • Non-Patent Document 4 even in the eSRVCC method (even when IMS signaling is via ATCF), a method of treating it as normal SRVCC, that is, the communication route is not anchored by ATGW, and either A method is described in which, when a UE is handed over to a CS network, IMS signaling is transmitted / received to / from the other UE via the ATCF from the MGW (ATCF without media anchored in ATGW).
  • whether or not IMS signaling is sent to the other UE is determined depending on whether the UE supports SRVCC regardless of the codec used by the UE.
  • Non-Patent Document 4 does not describe in any case whether eSRVCC is treated like normal SRVCC.
  • This disclosure makes it possible to change the codec of another terminal when one of the terminals in communication performs a handover involving a change of codec, and to execute the network node capable of continuing communication and the network node Provide a signaling processing method.
  • the ATCF which anchors IMS signaling, checks the contents of the SDP offer / answer, compares the codec used at the start of the call with the codec used by the CS to which the UE can handover, and transcodes it to the ATGW. If you do not want to transcode at ATGW, or if you do not want to anchor the communication path at ATGW, select a method to treat as normal SRVCC, when handover to CS of UE occurs. Performs codec re-negotiation by transmitting and receiving an SDP offer / answer with IMS signaling again with the other UE.
  • codec re-negotiation is performed by transmitting and receiving an SDP offer / answer with IMS signaling again with the other UE.
  • One aspect of the network node according to the present disclosure is a network node having at least an ATCF function (Access Transfer Control Function) used for enhanced Single Radio Voice Call Continuity (eSRVCC), and is an SDP included in IP Multimedia Subsystem (IMS) signaling.
  • ATCF Access Transfer Control Function
  • IMS IP Multimedia Subsystem
  • a reception unit that receives an offer or an SDP answer, an SDP analysis unit that acquires information on the SDP offer or a codec included in the SDP answer, a data storage unit, and a determination unit.
  • the data storage unit includes information on codecs supported by an Access Transfer Gateway (ATGW) or an MGW (Media Gateway) of a neighbor (Neighboring), information of transcoding supported by the ATGW or the MGW of a neighbor, and a neighbor.
  • ATGW Access Transfer Gateway
  • MGW Media Gateway
  • CS Circuit Switching
  • a network node capable of changing the codec of the other terminal and continuing the communication, and a signaling processing method executed in the network node Can be realized.
  • corresponds to SRVCC and it assumes that ATCF / ATGW has acquired the information.
  • ATCF / ATGW acquires whether UE corresponds to SRVCC the means as disclosed by patent document 1 may be used.
  • FIG. 7 is a block diagram particularly constituting an ATCF portion of ATCF / ATGW 320 according to the present embodiment.
  • the receiver 700 receives IMS signaling and the like.
  • the transmission unit 702 also transmits IMS signaling and the like.
  • the IMS signaling includes not only IMS signaling that the communication terminal UE transmits and receives at the time of session setup, but also IMS signaling transmitted and received with the handover of the UE.
  • the SDP analysis unit 704 analyzes the contents of SDP offers and SDP answers included in IMS signaling. For example, an SDP offer or an SDP answer is analyzed to obtain information of a voice codec used for a call.
  • the data storage unit 706 stores the capability (capability) of the ATCF / ATGW 320 itself and the capability of the neighboring MGW. For example, information on codecs supported by ATCF / ATGW320 or MGW, information on codecs supported by neighboring CS networks, information on transcoding supported by ATCF / ATGW320 or MGW (combination of codecs that can be transcoded) Information etc. are stored.
  • the information on the neighboring MGWs and the neighboring CS network may be acquired using means such as exchanging signaling messages directly by the ATCF / ATGW 320 and MGW via another network node, or manually manually in advance. May be stored.
  • the policy storage unit 708 stores a policy related to service provision. For example, two UEs performing communication may use different codecs, transcoding may be performed by ATCF / ATGW 320 or MGW, or codecs used by two UEs performing communication may be unified and transcoding may not be performed, etc. Policy is stored.
  • the determination unit 710 uses the data stored in the data storage unit 706 as a result of analysis by the SDP analysis unit 704 and the policy stored in the policy storage unit 708 to perform SDP for codec renegotiation from ATCF to the UE. Determine whether to enable the sending of offers. Specifically, it is determined whether to enable or not to change the codec by transmitting and receiving IMS signaling with the UE 102 by anchoring the communication at the ATGW or not at the ATGW.
  • FIG. 8 is a sequence chart showing an example of session setup in the first embodiment of the present disclosure.
  • the SDP offer added Invite message (IMS signaling) sent from the UE 100 is sent to the ATCF / ATGW 320 (exactly ATCF only) via another network node (not shown) (801).
  • IMS signaling IMS signaling
  • ATCF performs ATGW selection and resource allocation (802).
  • the ATCF / ATGW 320 sends an Invite message with an SDP offer to the UE 102 via another network node (not shown) (803). At this time, the ATGW is designated as the communication partner of the UE 102.
  • the UE 102 then sends an SDP answer with the IMS message to the ATCF / ATGW 320 via another network node (not shown) (804).
  • the determination unit 710 of the ATCF / ATGW 320 that has received the SDP answer uses the contents of the SDP answer, the data stored in the data storage unit 706, and the policy stored in the policy storage unit 708 to communicate in the selected ATGW. It is determined whether to anchor (805). An example of the determination method of the determination part 710 is shown in FIG.
  • the determination unit 710 first confirms what codec is selected in the SDP answer (ST 901).
  • the codec selected in the SDP answer is a codec that can be used when the UE is handed over to the CS network (a codec supported by the neighboring CS network).
  • codecs that can be used in the CS network if the conventional criteria for determining whether to anchor communications at ATGW (such as the criteria described in Patent Document 1) are met, the communications are anchored at ATGW and satisfied. If not, select not to anchor communication at ATGW. (Not shown).
  • the codec selected in the SDP answer is not the codec that can be used when the UE is handed over to the CS network, that codec is supported by the ATGW or a neighboring MGW that can be used when the UE is handed over It is confirmed whether it is a codec (ST 902). If not supported, it is impossible to perform processing related to the codec, such as transcoding, so that the communication is not anchored by the ATGW, that is, when the UE is handed over to the CS network and the codec is changed. , Transmit and receive IMS signaling for codec renegotiation with UE 102, and select to be able to unify with codec UE 100 (ST 903).
  • transcoding is not supported, it is selected not to anchor communication at ATGW (ST 903). Also, even if transcoding is supported, the policy is checked whether to allow transcoding (transcoding is used or not) (ST 905), and transcoding is not permitted. To not anchor communication at the ATGW (ST 903). That is, when the UE is handed over to the CS network and the codec is changed, it is selected to transmit / receive IMS signaling for codec re-negotiation with the UE 102 so as to be able to unify with the codec UE 100. Do.
  • the ATGW determines whether all other conditions for anchoring communication are ready at the ATGW (ST 906). For example, if the selected codec is compatible with the codec supported by the neighboring CS, as described in Patent Document 2, without transmitting or receiving IMS signaling to / from the UE 102 (RTP payload format Check if the codec has the switching function to compatible mode (without session renegotiation for switching). If there is no function or there is no policy to use even if it has it, it is selected that the communication is not anchored by the ATGW (ST 903).
  • a codec that has the function of performing operations without transcoding without transmitting / receiving IMS signaling to / from UE 102, and if there is a policy that uses that function, and other for anchoring communications at ATGW.
  • IMS signaling for codec re-negotiation with the UE 102 is transmitted and received, and between the codec UE 100 and the UE 102. It is determined that there is no need to unify them, and ATGW anchors communication (ST 907).
  • IMS signaling is transmitted and received such that the communication destinations of the UE 100 and the UE 102 become the selected ATGW, as described in Non-Patent Document 4.
  • the ATCF / ATGW 320 again transmits an IMS message to the UE 102 as shown in FIG. 8 (806), and the communication destination of the UE 102 is changed to the UE 100 instead of the ATGW.
  • the MGW or MGW or the like may not be compatible with the codec after the change. If the ATGW does not support or permit transcoding, or if there is compatibility, there is no need to transmit or receive IMS signaling with the UE 102 (RTP payload format switching to no session re-negotiation) to compatible mode Even if it does not support or permit the switching of H.264, it is possible to continue communication by transmitting and receiving IMS signaling between the ATCF / ATGW and the UE 102 and performing codec re-negotiation.
  • FIG. 7 is a block diagram of the ATCF / ATGW 320 of the present embodiment, which is the same as that of the first embodiment.
  • FIG. 10 is a sequence chart showing an example of session setup in the second embodiment of the present disclosure.
  • the SDP offer added Invite message (IMS signaling) sent from the UE 100 is sent (1001) to the ATCF / ATGW 320 (exactly ATCF only) via another network node (not shown).
  • the ATCF / ATGW 320 determines whether to determine whether to anchor communication at the ATGW from the SDP offer (1002). For example, in the determination unit 710 of the ATCF / ATGW, it is confirmed and determined whether the policy storage unit 708 has a policy for determining whether to anchor communication by the ATGW based on the contents of the SDP offer. If it is not determined from the contents of the SDP offer whether the ATGW anchors the communication, the determination is made from the SDP answer as in the first embodiment.
  • FIG. 11 shows an example of the determination method of the determination unit 710 of the ATCF / ATGW 320 according to the present embodiment. That is, when judging by the SDP offer (ST 1101), the codec of the SDP offer is analyzed by the SDP analysis unit 704 (ST 1102). If the codecs analyzed at this time include ATCF / ATGW 320 or codecs not supported by the neighboring MGW (ST 1103), delete the codecs from the SDP offer and make them only supported codecs (ST Even when the UE 100 is handed over to the neighboring CS network, it is inquired of the policy storage unit 708 whether or not only the codec can continue communication without re-negotiating the codec with the UE 102 (ST1104).
  • the ATGW When deleting, it is determined that the communication is anchored by the ATGW (ST1105). That is, the ATGW which anchors communication is selected and resources are allocated. Further, an SDP with the corresponding codec deleted is generated by the SDP analysis unit 704 or the like, and the AT GW is notified to the UE 102 by IMS signaling as a communication counterpart. Also, when receiving the SDP answer from the UE 102, the SDP answer is sent to the UE 100 by using the IMS signaling as the communication partner as the ATGW. On the contrary, when the codec is not deleted from the SDP offer, if the codec is selected, it is impossible to perform processing related to the codec such as transcoding, so it is determined that the ATGW does not anchor the communication ( ST 1106).
  • IMS signaling is sent to the UE 102 with the UE 100 as a communication counterpart. Also, upon receiving the SDP answer from the UE 102, the UE transmits IMS signaling to the UE 100 using the UE 102 as a communication partner.
  • the determination criteria (transcoding policy etc.) described in the first embodiment are applied to the ATGW. It may be determined whether to anchor the communication.
  • Embodiment 1 determines whether to anchor communication (ST1107, ST1108, ST1109).
  • the ATGW after receiving an SDP answer as in Embodiment 1, the ATGW determines whether to anchor communication or not, and if not anchored, the procedure for changing the communication partner of UE 102 from ATGW to UE 100 Can be omitted. Therefore, the time required for session setup can be shortened compared to the first embodiment.
  • FIG. 7 is a block diagram showing a configuration of ATCF / ATGW 320 according to the present embodiment, which is similar to that of the first embodiment.
  • FIG. 12 is a sequence chart showing an example of session setup in the third embodiment of the present disclosure and a case where the UE 100 performs handover to a CS network.
  • the SDP offer added Invite message (IMS signaling) transmitted from the UE 100 is transmitted to the ATCF / ATGW 320 (exactly ATCF only) via another network node (not shown) (1201).
  • IMS signaling IMS signaling
  • ATCF performs ATGW selection and resource allocation (1202).
  • the ATCF / ATGW 320 transmits an SDP offer-added Invite message to the UE 102 via another network node (not shown) (1203). At this time, the ATGW is designated as the communication partner of the UE 102.
  • the UE 102 sends an SDP answer together with the IMS message to the ATCF / ATGW 320 via another network node (not shown) (1204).
  • the ATCF / ATGW 320 that has received the SDP answer transmits an SDP answer to the UE 100 via another network node (not shown) as described in Non-Patent Document 4 (1205).
  • the ATGW is designated as the communication partner of the UE 100. That is, the ATCF / ATGW 320 anchors communication at the ATGW without analyzing the SDP offer answer.
  • Non-Patent Document 1 1206
  • the MSC / MGW transmits an Invite message with an SDP offer to the ATCF / ATGW 320 as described in Non-Patent Document 4 (1207).
  • the judging unit 710 of the ATCF / ATGW 320 that has received this message uses the contents of the SDP offer, the data stored in the data storage unit 706, and the policy stored in the policy storage unit 708 to transmit the codec from the ATCF to the UE. It is determined whether to enable transmission of the SDP offer for re-negotiation. Specifically, a determination is made as to whether to send IMS signaling (Invite message with SDP offer) to renegotiate the codec to the UE 102 (1208). An example of the determination method of the determination part 710 is shown in FIG.
  • Determination section 710 first confirms whether the codec used by UE 100 before the handover is included in the codec selected in the SDP offer (ST1301, ST1302). If it is included, IMS signaling (SDP offer) is not sent to the UE 100, and communication is continued according to the method described in Non-Patent Document 4 without changing the codec.
  • IMS signaling is transmitted / received to / from the UE 102 in the same manner as in Embodiment 1, and the SDP is again performed.
  • Determine whether to unify the codec by exchanging offer and answer That is, it is checked whether the codec used by UE 100 before handover is supported by ATGW (ST 1303). If not supported, it is impossible to perform processing related to that codec such as transcoding Therefore, it sends IMS signaling to the UE 102 and selects codec re-negotiation (ST1304).
  • the ATCF / ATGW checks whether transcoding is supported (ST1305).
  • transcoding is not supported, IMS signaling is sent to the UE 102, and codec renegotiation is selected (ST1304). Also, even if transcoding is supported, the policy is checked whether to allow transcoding (ST1306). If the policy does not allow transcoding, IMS signaling is sent to the UE 102, and codec renegotiation is selected (ST1304). Also, even in the case of a policy that allows transcoding, IMS signaling is sent to the UE 102, and it is determined whether a condition that does not require codec re-negotiation is established (ST1307).
  • the IMS signaling is not transmitted to and received from the UE 102 as described in Patent Document 2.
  • the codec after the change is the codec before the change and ATCF / ATGW and UE102 even if they do not support transcoding in MGW or ATGW when they are incompatible, and even if they do not support switching with no session re-negotiation of the RTP payload format or if they are compatible.
  • the communication can be continued by transmitting and receiving IMS signaling between them and re-negotiating the codec.
  • the ATCF / ATGW 320, the MSC / MGW 110, and the SCC AS / CSCF have been described as one node.
  • the present disclosure is not limited thereto, and the ATCF / ATGW 320, the MSC / MGW 110, and the SCC AS / CSCF may be configured of two or more separate nodes connected to each other by an interface. That is, the functions described above may be distributed to a plurality of nodes in each of ATCF and ATGW, MSC and MGW, and SCC AS and CSCF. Conversely, the functions of ATCF / ATGW 320 and MSC / MGW 110 may be implemented in one node.
  • the present disclosure is not limited to this, and can be applied to codecs such as music, sound, and images.
  • FIG. 8 to FIG. 13 show the operation (method) with hardware designed specifically, and install a program for executing the operation (method) of the present disclosure in general-purpose hardware. This also includes the case where it is realized by execution on a processor.
  • Examples of the general-purpose hardware electronic computer include personal computers, various portable information terminals such as smart phones, and mobile phones.
  • hardware specially designed includes not only finished products (consumer electronics) such as mobile phones and fixed phones but also semi-finished products and parts such as system boards and semiconductor devices.
  • the network node of the present disclosure is useful for handling codecs used for music signals and the like and codecs used for image signals, as well as handling voice codecs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (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）であるＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。ここで、ＵＥ１００とＵＥ１０２が通話を開始する場合、セッションセットアップ(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. 　ｅＳＲＶＣＣ（enhanced Single Radio Voice Call Continuity）に用いるＡＴＣＦ機能（Access Transfer Control Function）を有するネットワークノードであって、
    　ＩＭＳ（IP Multimedia Subsystem）シグナリングに含まれるＳＤＰ（Session Description Protocol）オファーまたはＳＤＰアンサーを受信する受信部と、
    　前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれるコーデックの情報を取得するＳＤＰ解析部と、
    　ＡＴＧＷ（Access Transfer Gateway）または近隣のＭＧＷ（Media Gateway）でサポートしているコーデックの情報、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているトランスコーディングの情報、および近隣のＣＳ（Circuit Switching）網がサポートしているコーデックの情報の少なくとも一つを保持するデータ格納部と、
    　前記ＳＤＰ解析部で取得した前記コーデックの情報、および前記データ格納部から読み出した情報を用いて、前記ＡＴＣＦから通信端末へコーデックを再折衝するためのＳＤＰオファーの送信を可能にするか否かを判断する判断部と、
    　を有するネットワークノード。
  2. 　前記判断部における、前記ＡＴＣＦから前記通信端末へコーデックを再折衝するための前記ＳＤＰオファーの送信を可能にするか否かの判断は、
    　　前記ＡＴＧＷで通話データをアンカーするか否か、または、
    　　前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信するか否か、
    　の判断である、
    　請求項１記載のネットワークノード。
  3. 　前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているコーデックと一致しない場合、
    　前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    　請求項２記載のネットワークノード。
  4. 　前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしている前記コーデックと一致しない場合において、
    　前記ＳＤＰオファーから前記コーデックを削除して送信する場合には、前記判断部は、前記ＡＴＧＷで通話データをアンカーすると判断し、
    　前記ＳＤＰオファーから前記コーデックを削除しないで送信する場合には、前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    　請求項３記載のネットワークノード。
  5. 　前記受信部でセッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、
    　前記判断部は、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    　請求項２記載のネットワークノード。
  6. 　前記受信部で前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷでサポートしているコーデックと一致しない場合、前記判断部は、前記通信端末にコーデック再折衝のための前記ＳＤＰオファーを送信すると判断する、
    　請求項２記載のネットワークノード。
  7. 　前記受信部で前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記判断部は、前記通信端末にコーデック再折衝のための前記ＳＤＰオファーを送信すると判断する、
    　請求項２記載のネットワークノード。
  8. 　ｅＳＲＶＣＣ（enhanced Single Radio Voice Call Continuity）に用いるＡＴＣＦ機能（Access Transfer Control Function）を有するネットワークノードにおけるシグナリング処理方法であって、
    　ＩＭＳ（IP Multimedia Subsystem）シグナリングに含まれるＳＤＰ（Session Description Protocol）オファーまたはＳＤＰアンサーを受信し、
    　前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれるコーデックの情報を取得し、
    　ＡＴＧＷ（Access Transfer Gateway）または近隣のＭＧＷ（Media Gateway）でサポートしているコーデックの情報、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているトランスコーディングの情報、および近隣のＣＳ（Circuit Switching）網がサポートしているコーデックの情報の少なくとも一つを取得し、
    　前記取得した情報を用いて、前記ＡＴＣＦから通信端末へコーデックを再折衝するためのＳＤＰオファーの送信を可能にするか否かを判断する、
    　シグナリング処理方法。
  9. 　前記ＡＴＣＦから前記通信端末へコーデックを再折衝するための前記ＳＤＰオファーの送信を可能にするか否かの判断は、
    　　前記ＡＴＧＷで通話データをアンカーするか否か、または、
    　　前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信するか否か、の判断である、
    　請求項８記載のシグナリング方法。
  10. 　セッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしているコーデックと一致しない場合、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    　請求項９記載のシグナリング方法。
  11. 　セッションセットアップの際に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷまたは近隣の前記ＭＧＷでサポートしている前記コーデックと一致しない場合において、
    　前記ＳＤＰオファーから前記コーデックを削除して送信する場合には、前記ＡＴＧＷで通話データをアンカーすると判断し、
    　前記ＳＤＰオファーから前記コーデックを削除しないで送信する場合には、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    　請求項１０記載のシグナリング方法。
  12. 　セッションセットアップの際に受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記ＡＴＧＷで通話データをアンカーしないと判断する、
    　請求項９記載のシグナリング方法。
  13. 　前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、前記ＡＴＧＷでサポートしているコーデックと一致しない場合、前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信すると判断する、
    　請求項９記載のシグナリング方法。
  14. 　前記通信端末のハンドオーバ時に受信した前記ＳＤＰオファーに含まれる前記コーデックが、近隣の前記ＣＳ網がサポートしているコーデックと一致しないまたは互換性がなく、かつ、前記ＡＴＧＷまたは近隣の前記ＭＧＷで前記ＳＤＰオファー又は前記ＳＤＰアンサーに含まれるコーデックに対しトランスコーディングを行わない場合、前記通信端末にコーデックを再折衝するための前記ＳＤＰオファーを送信すると判断する、
    　請求項９記載のシグナリング方法。
PCT/JP2015/002134 2014-05-13 2015-04-20 ネットワークノード及びシグナリング処理方法 WO2015174018A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP15792804.5A EP3145165B1 (en) 2014-05-13 2015-04-20 Network node and signaling processing method
JP2016519094A JP6420328B2 (ja) 2014-05-13 2015-04-20 ネットワークノード及びシグナリング処理方法
US15/285,716 US9967782B2 (en) 2014-05-13 2016-10-05 Network node and signaling processing method

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201461992222P 2014-05-13 2014-05-13
US61/992,222 2014-05-13
JP2014-138668 2014-07-04
JP2014138668 2014-07-04

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/285,716 Continuation US9967782B2 (en) 2014-05-13 2016-10-05 Network node and signaling processing method

Publications (1)

Publication Number Publication Date
WO2015174018A1 true WO2015174018A1 (ja) 2015-11-19

Family

ID=54479573

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/002134 WO2015174018A1 (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)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112640390A (zh) * 2018-09-07 2021-04-09 苹果公司 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法
JP7523267B2 (ja) 2020-07-10 2024-07-26 株式会社Ｎｔｔドコモ 通信制御装置

Families Citing this family (4)

* 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
US11509772B2 (en) * 2018-11-13 2022-11-22 Qualcomm Incorporated Methods for increasing Voice-over-Internet Protocol (VoIP) network coverage
EP3895395A1 (en) 2018-12-10 2021-10-20 Telefonaktiebolaget LM Ericsson (publ) Network node, entity and methods performed therein for handling a communication session in a communication network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012054620A (ja) * 2010-08-06 2012-03-15 Ntt Docomo Inc 移動通信方法及び移動通信システム
WO2013072193A2 (en) * 2011-11-14 2013-05-23 Nokia Siemens Networks Oy Method and apparatus for allocating a transfer function
WO2013080471A1 (ja) * 2011-11-30 2013-06-06 パナソニック株式会社 ネットワークノード及び通信方法

Family Cites Families (6)

* 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 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム及び移動局
JP2012105211A (ja) * 2010-11-12 2012-05-31 Ntt Docomo Inc コアネットワークおよび通信システム
CN104221429B (zh) * 2012-04-17 2019-04-05 瑞典爱立信有限公司 利用活跃编解码器选择在接入网之间的呼叫的srvcc切换

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012054620A (ja) * 2010-08-06 2012-03-15 Ntt Docomo Inc 移動通信方法及び移動通信システム
WO2013072193A2 (en) * 2011-11-14 2013-05-23 Nokia Siemens Networks Oy Method and apparatus for allocating a transfer function
WO2013080471A1 (ja) * 2011-11-30 2013-06-06 パナソニック株式会社 ネットワークノード及び通信方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3GPP SA4-EVS SWG CONFERENCE CALL #26, AHEVS-253, 28 May 2013 (2013-05-28), XP008183131, Retrieved from the Internet <URL:http:// www.3gpp.org/ftp/TSG_SA/WG4_CODEC/Ad-hoc_EVS/ Docs/AHEVS-253.zip> [retrieved on 20150624] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112640390A (zh) * 2018-09-07 2021-04-09 苹果公司 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法
US11611909B2 (en) 2018-09-07 2023-03-21 Apple Inc. Apparatus and method for signaling ran-assisted codec adaptation capabilities in IMS multimedia telephony sessions
JP7523267B2 (ja) 2020-07-10 2024-07-26 株式会社Ｎｔｔドコモ 通信制御装置

Also Published As

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

Similar Documents

Publication Publication Date Title
US10362514B2 (en) Network node and communication method
US11647428B2 (en) Communication terminal apparatus and communication method
US8957938B2 (en) Method and apparatus for handing over a video conversation from packet switch domain to circuit switch domain
JP6420328B2 (ja) ネットワークノード及びシグナリング処理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15792804

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2016519094

Country of ref document: JP

Kind code of ref document: A

REEP Request for entry into the european phase

Ref document number: 2015792804

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015792804

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE