WO2012169134A1 - ネットワークノード、端末、帯域幅変更判断方法及び帯域幅変更方法 - Google Patents

ネットワークノード、端末、帯域幅変更判断方法及び帯域幅変更方法 Download PDF

Info

Publication number
WO2012169134A1
WO2012169134A1 PCT/JP2012/003410 JP2012003410W WO2012169134A1 WO 2012169134 A1 WO2012169134 A1 WO 2012169134A1 JP 2012003410 W JP2012003410 W JP 2012003410W WO 2012169134 A1 WO2012169134 A1 WO 2012169134A1
Authority
WO
WIPO (PCT)
Prior art keywords
codec
bandwidth
terminal
network
signaling
Prior art date
Application number
PCT/JP2012/003410
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 EP20160616.7A priority Critical patent/EP3684104A1/en
Priority to US14/123,333 priority patent/US9288792B2/en
Priority to PL16193870T priority patent/PL3139696T3/pl
Priority to EP16193870.9A priority patent/EP3139696B1/en
Priority to EP12796764.4A priority patent/EP2706766B1/en
Priority to JP2013519368A priority patent/JP5947294B2/ja
Priority to CN201280024440.XA priority patent/CN103548369B/zh
Publication of WO2012169134A1 publication Critical patent/WO2012169134A1/ja
Priority to US15/014,405 priority patent/US10841842B2/en
Priority to US17/069,499 priority patent/US11647428B2/en

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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/13—Cell handover without a predetermined boundary, e.g. virtual cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H04M7/0072—Speech codec negotiation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/181—Transcoding devices; Rate adaptation devices

Definitions

  • the present invention relates to a network node, a terminal, a bandwidth change determination method, and a bandwidth change method for changing a codec used in a mobile communication system.
  • VoLTE Voice over Long Term Evolution
  • PS 3GPP packet switching
  • VoLTE Voice Call Continuity
  • SRVCC Single Radio Radio Voice Call Continuity
  • FIG. 1 shows a part of a 3GPP mobile communication network configuration.
  • 1 includes an e-UTRAN (evolved Universal Terrestrial Radio Access Network), an e-UTRAN base station (e-nodeB), a PS network, a CS network, a CS network base station subsystem, and an IMS ( IP (Multimedia Subsystem).
  • e-UTRAN evolved Universal Terrestrial Radio Access Network
  • e-nodeB evolved Universal Terrestrial Radio Access Network
  • PS network e-UTRAN base station
  • CS network a CS network base station subsystem
  • IMS IP (Multimedia Subsystem).
  • IP Multimedia Subsystem
  • e-UTRAN is a radio access network capable of providing a VoLTE service.
  • the PS network provides a VoLTE service and is composed of P-GW (Packet Data Gateway), S-GW (Serving Gateway), and MME (Mobility Management Entity).
  • the CS network is composed of MSC (Mobile Switching Center) and MGW (Media Gateway).
  • the base station subsystem of the CS network is composed of an RNC (Radio Network Controller) and a node B.
  • IMS performs call control and the like, and is composed of CSCF (Call Session Control Function) and SCC AS (Service Centralization and Continuity Application Server).
  • CSCF Call Session Control Function
  • SCC AS Service Centralization and Continuity Application Server
  • 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 the UE 102 side are not shown). ). That is, it is assumed that a VoLTE call is performed between the UE 100 and the UE 102. At this time, it is assumed that the UE 100 is handed over to the CS network (HO: Hand ⁇ Over) during the call.
  • 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 the SRVCC handover process passes.
  • FIG. 2 is a sequence chart showing the operation of SRVCC handover processing.
  • UE 100 and UE 102 are initially connected to a PS network (e-UTRAN), respectively, and call data between UE 100 and UE 102 is transmitted and received through Path A.
  • the e-nodeB detects this and exchanges signaling with the RNC / nodeB via the MME and MSC / MGW (the signaling 200 shown in FIG. 1). 2 (hereinafter referred to as “ST”) 200 shown in FIG.
  • ST200 a data path in the CS network is prepared between the nodeB and the MSC / MGW.
  • a command is issued from the MME to the UE 100 via the e-nodeB to hand over to the UTRAN (CS network) side. Is issued.
  • the MSC / MGW exchanges signaling with the UE 102 via the CSCF / SCC AS (signaling 202 shown in FIG. 1 and ST202 shown in FIG. 2).
  • a command is issued to switch the UE 102 call data transmission / reception destination from the UE 100 to the MSC / MGW, and Path B is established.
  • UE 100 After handing over to UTRAN, UE 100 exchanges signaling with MSC / MGW via RNC / nodeB (signaling 204 shown in FIG. 1 and ST204 shown in FIG. 2). Thereby, Path C is established.
  • the MSC / MGW exchanges signaling with the P-GW / S-GW via the MME (signaling 206 shown in FIG. 1 and ST206 shown in FIG. 2). As a result, 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.
  • the mobile communication network shown in FIG. 3 includes an e-UTRAN, e-nodeB, PS network, CS network, CS network base station subsystem, and IMS.
  • IMS there are ATCF (Access TransferATControl Function) and ATGW (Access Transfer Gateway) in addition to CSCF and SCC AS. 3 and 4, the ATCF and ATGW are represented as one node (ATCF / ATGW 1120), but they may be represented as separate nodes.
  • ATCF Access TransferATControl Function
  • ATGW Access Transfer Gateway
  • UE 100 and UE 102 are initially connected to the PS network (however, the radio access network, base station, and PS network on the UE 102 side are not shown). That is, it is assumed that a VoLTE call is performed between the UE 100 and the UE 102. At this time, it is assumed that the UE 100 is handed over to the CS network (HO: Hand ⁇ Over) during the 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. Further, 1100, 1102, 1104, and 1106 indicated by broken lines in FIG. 3 indicate paths through which signaling in the eSRVCC handover process passes.
  • FIG. 4 is a sequence chart showing the operation of eSRVCC handover.
  • UE 100 and UE 102 are initially connected to a PS network (e-UTRAN), respectively.
  • ATCF / ATGW 1120 ATCF anchors IMS signaling (IMS signaling), and ATGW anchors call data. That is, at the start of a call between the UE 100 and the UE 102, the IMS signaling of the call start is relayed by the ATCF, and when the ATCF determines that the call data anchor in the ATGW is necessary, the ATGW is assigned as the call data anchor point. It is done. Thereby, the call data between the UE 100 and the UE 102 are transmitted and received through the Path A and the Path B.
  • IMS signaling IMS signaling
  • the e-nodeB When the UE 100 tries to move away from the e-UTRAN coverage area, the e-nodeB detects this and exchanges signaling with the RNC / nodeB via the MME and MSC / MGW (signaling 1100 shown in FIG. 3).
  • ST1100 shown in FIG. 3 a data path in the CS network is prepared between the nodeB and the MSC / MGW, and when the preparation is completed, a command is issued from the MME to the UE 100 via the e-nodeB to hand over to the UTRAN (CS network) side. Is issued.
  • the MSC / MGW sends signaling to the ATCF.
  • a route switching instruction is issued from the ATCF to the ATGW, and the call data transmission / reception destination of the ATGW is switched from the UE 100 to the MSC / MGW (signaling 1102 shown in FIG. 3 and ST1102 shown in FIG. 4). That is, Path C is established.
  • the ATCF transmits notification signaling to the SCC-AS (signaling 1102 shown in FIG. 3 and ST1102 shown in FIG. 4).
  • UE 100 After handing over to UTRAN, UE 100 exchanges signaling with MSC / MGW via RNC / nodeB (signaling 1104 shown in FIG. 3 and ST1104 shown in FIG. 4). Thereby, Path D is established.
  • Path D After Path D is established, MSC / MGW exchanges signaling with P-GW / S-GW via MME (signaling 1106 shown in FIG. 3; ST1106 shown in FIG. 4). As a result, Path B is deleted.
  • an AMR (Adaptive Multi-Rate) codec that is a narrowband (NB) codec
  • an AMR-WB codec that is a wideband (WB) codec
  • VoIP PS network
  • AMR and AMR-WB support different bit rates. Further, when AMR and AMR-WB are used in the PS network, as described in Non-Patent Document 2, the numbering (Frame ⁇ ⁇ ⁇ Type Index) for the bit rate used in the RTP (Real-Time Protocol) payload format is as follows. It overlaps on both sides. For this reason, it is necessary to decide whether to use AMR or AMR-WB at the start of a session, whether it is used in the CS network or the PS network. That is, it is impossible to switch between AMR and AMR-WB without session re-negotiation.
  • RTP Real-Time Protocol
  • a narrowband codec is a codec that is generally sampled at 8 kHz with a bandwidth of 300 Hz to 3.4 kHz.
  • the wideband codec is a codec that is generally sampled at 16 kHz with a bandwidth of 50 Hz to 7 kHz.
  • a super wideband (SWB) codec is a codec that is generally sampled at 32 kHz with a bandwidth of 50 Hz to 14 kHz.
  • 3GPP TS23.216 v9.6.0 “Single Radio (Voice) Call (Continuity) (SRVCC)” IETF RFC 4867, “RTP Payload Format Format and File File Storage Format Format for the adaptive Adaptive Multi-Rate (AMR) and adaptive Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs 3GPP TS23.237 v11.0.0 “IP Multimedia Subsystem (IMS) Service Continuity” Takashi Koshimizu and Katsutoshi Noshida, “Audio Viedo Callof Single Radio Voice Call Continuity”, 2011 IEICE General Conference, B-6-77 Katsutoshi Nishida, Takashi Usui, “Proposal for Improving Handover between IMS and Circuit Switch for Voice Calls, Anchored SRVCC Method Based on Mobility Capability”, IEICE Tech. Rep. NS2010-178, pp85-90
  • the codec used in the UE 100 is the CS network. Changed to a supported codec.
  • the first method is a method of changing the codec used in the UE 102 to the same codec after the UE 100 is changed.
  • the second method is a method of transcoding in MSC / MGW.
  • the former method is not preferable because it takes time for signaling to change the codec of the UE 102 and the time for which the call is interrupted becomes longer. Furthermore, in eSRVCC handover, since the signaling for path switching at the time of handover of the UE 100 terminates at the ATCF, it is not possible to send signaling for changing the codec of the UE 102. That is, in the eSRVCC handover, the codec of the UE 102 cannot be changed using existing signaling.
  • the latter transcoding method is considered to be relatively preferable.
  • the codec bandwidth the bandwidth of the signal that is input / output of the codec
  • An object of the present invention is to provide a network node, a terminal, and a bandwidth that can suppress deterioration in call quality due to transcoding without interrupting the call even when the codec used by one of the communicating terminals is changed. It is to provide a width change determination method and a bandwidth change method.
  • a network node is a network node that performs transcoding for communication between two terminals that use different codecs, and a detecting unit that detects a codec used by each of the two terminals.
  • the first codec of the other terminal other than the one terminal, and Determining means for determining whether or not to limit the first bandwidth of the first codec using the second codec after the change of the one terminal; and in the determining means, the first codec Transmitting means for transmitting signaling for limiting the first bandwidth to the other terminal when it is determined to limit the bandwidth;
  • a configuration that.
  • a terminal is a terminal used in a communication system in which transcoding is performed in a network node located between terminals for communication between terminals using different codecs, Negotiation means for negotiating a first codec used for communication with a partner terminal which is a communication partner of the terminal, and a first input signal encoded in the terminal with respect to the negotiated first codec. And determining a change in the first bandwidth determined by the determining means according to signaling for limiting the first bandwidth notified from the network node. And a changing means.
  • a bandwidth change determination method is a bandwidth change determination method in a network node that performs transcoding for communication between two terminals using different codecs, and each of the two terminals Detecting a codec to be used, and detecting a change in codec used by either one of the two terminals based on a detection result, the first codec of the other terminal other than the one terminal; And determining whether or not to limit the first bandwidth of the first codec using the second codec after the change of the one terminal, and determining to limit the first bandwidth If so, signaling for limiting the first bandwidth is transmitted to the other terminal.
  • a bandwidth changing method is a bandwidth changing method in a terminal used in a communication system in which transcoding is performed in a network node located between terminals for communication between terminals using different codecs.
  • a first codec used for communication between the terminal and a partner terminal which is a communication partner of the terminal is negotiated and the first codec negotiated is encoded in the terminal.
  • the first bandwidth of the input signal is selected, and the change of the first bandwidth is controlled according to signaling notified from the network node to limit the first bandwidth, and the first bandwidth is controlled.
  • the first bandwidth is determined according to the bandwidth change control.
  • the present invention even when the codec used by one of the communicating terminals is changed, it is possible to suppress deterioration in call quality due to transcoding without interrupting the call.
  • the figure which shows an example of SDP used for the codec negotiation based on Embodiment 1 of this invention Sequence chart showing operation according to Embodiment 1 of the present invention
  • Configuration diagram showing a part of a mobile communication network according to a third embodiment of the present invention The block diagram which shows the structure of the network node (MSC / MGW) which concerns on Embodiment 3 of this invention.
  • Sequence chart showing operation according to Embodiment 3 of the present invention The flowchart which shows an example of the codec selection method in the codec selection part of MSC / MGW concerning Embodiment 3 of this invention
  • bandwidth refers to the bandwidth of a signal that is input / output of a codec.
  • a codec that does not necessarily require a bandwidth designation means a codec that can switch the bandwidth of an input signal to be encoded without re-negotiation of a session.
  • the non-interoperable mode of the EVS (Enhanced Voice Services) codec is used only in the PS network, and the supported bit rate is the same in any bandwidth ("3GPP TSG SA SA WG4 S4 -110539 (see “EVS Permanent Document # 4 (EVS-4):“ EVS design constraints ”)).
  • EVS-4 EVS Permanent Document # 4
  • the encoder sets the bandwidth of the input signal to be encoded according to, for example, the characteristics of the input signal (for example, the frequency characteristics of the input signal and parameters obtained by analyzing the input signal) or the encoding bit rate. Or change.
  • FIG. 5 is a configuration showing a part of the mobile communication network according to Embodiment 1 of the present invention.
  • parts having the same configuration as in FIG. 5 operations of the UEs 100 and 102 and the MSC / MGW 300 are different from those in FIG.
  • MSC / MGW 300 performs transcoding for communication between two terminals using different codecs.
  • FIG. 6 is a block diagram showing a configuration of MSC / MGW 300 (network node) according to the present embodiment.
  • main components related to the band limiting (band changing) process closely related to the present invention for example, ST 402 to 406 shown in FIG. 5 (to be described later) ).
  • receiving section 600 receives call data (hereinafter referred to as communication data), signaling, and the like. For example, upon receiving signaling (for example, signaling 202 and 204 shown in FIG. 1) transmitted from UE 100 and UE 102, receiving unit 600 outputs the received signaling to codec detection unit 604 and codec bandwidth detection unit 606. To do.
  • signaling for example, signaling 202 and 204 shown in FIG. 1
  • the transmission unit 602 transmits communication data, signaling, and the like. For example, the transmission unit 602 notifies the UE 102 of the signaling output from the signaling generation unit 610.
  • the codec detection unit 604 detects codecs used by the UE 100 and the UE 102 based on signaling, communication data, and the like from the UE 100 and the UE 102 input from the reception unit 600, respectively. Then, the codec detection unit 604 outputs information (detection result) indicating the detected codec to the change determination unit 608.
  • the codec bandwidth detection unit 606 detects the bandwidth of the codec used by each of the UE 100 and the UE 102 based on signaling, communication data, and the like from the UE 100 and the UE 102 input from the reception unit 600. Then, the codec bandwidth detection unit 606 outputs information (detection result) indicating the detected codec bandwidth to the change determination unit 608.
  • the change determination unit 608 is encoded to the UE 102 based on the codec indicated in the information input from the codec detection unit 604 and the bandwidth of the codec indicated in the information input from the codec bandwidth detection unit 606. It is determined whether bandwidth limitation of the input signal is possible and whether bandwidth limitation is necessary. For example, when the change determination unit 608 detects a change in codec used by one UE 100 out of two terminals (UE 100 and UE 102) based on the detection result in the codec detection unit 604, the codec of the other UE 102, Then, using the codec after the change of the UE 100, it is determined whether or not to limit the bandwidth of the codec of the UE 102. The change determination unit 608 outputs the determination result to the signaling generation unit 610. The details of the bandwidth change determination process in the change determination unit 608 will be described later.
  • the change determination unit 608 determines that the bandwidth of the input signal encoded into the UE 102 can be limited, and the signaling generation unit 610 determines that the bandwidth limitation is necessary, the signaling generation unit 610 inputs the input signal encoded by the UE 102 Signaling for requesting the UE 102 to limit the bandwidth is generated.
  • the signaling requesting the bandwidth limitation may include, for example, information indicating the bandwidth after the UE 100 is changed.
  • the signaling generation unit 610 transmits the generated signaling to the UE 102 via the transmission unit 602. In this way, when the change determination unit 608 determines to limit the bandwidth of the codec of the UE 102, signaling for limiting the bandwidth is transmitted to the UE 102 via the transmission unit 602.
  • the transcoding unit 612 When the UE 100 and the UE 102 use different codecs, the transcoding unit 612 performs transcoding on the communication data from the UE 100 to the UE 102 and the communication data from the UE 102 to the UE 100.
  • change determination section 608 determines whether or not the codec of UE 100 has been changed based on the detection result (detected codec) in codec detection section 604.
  • the change determination unit 608 determines that the codec used in the UE 102 is codec A based on the detection result of the codec detection unit 604. It is determined whether or not the codec does not need to specify a bandwidth.
  • the change determination unit 608 changes the UE100 based on the detection result in the codec bandwidth detection unit 606. It is determined whether the bandwidth of the later codec is narrower than the maximum bandwidth of the codec currently used by the UE 102.
  • the change determination unit 608 inputs the input signal to be encoded to the UE 102 It is determined that it is possible and necessary to limit the bandwidth. For example, the change determination unit 608 determines to limit (change) the bandwidth of the codec of the UE 102 to the bandwidth of the codec after the change of the UE 100.
  • the change determination unit 608 determines that the UE 102 is not limited in bandwidth.
  • the MSC / MGW 300 determines whether the codec of the other UE is a codec that does not need to specify a bandwidth. Thus, it is determined whether it is possible to limit (change) the bandwidth of the codec of the other UE. Further, the MSC / MGW 300 determines whether the codec bandwidth after the change of one UE is narrower than the maximum bandwidth of the codec of the other UE, thereby determining the codec bandwidth of the other UE. Determine whether restrictions (changes) are necessary.
  • FIG. 8 is a block diagram showing a configuration of UEs 100 and 102 (terminals) according to the present embodiment.
  • the configuration related to the main components related to the bandwidth limiting process for example, ST 400 to 406 (described later) shown in FIG. 5 closely related to the present invention. Part).
  • the receiving unit 700 receives communication data, signaling, and the like. For example, when receiving the signaling (for example, signaling 202 or 204 shown in FIG. 1) transmitted from the MSC / MGW 300, the receiving unit 700 outputs the received signaling to the codec negotiation unit 704 and the signaling analysis unit 710.
  • the signaling for example, signaling 202 or 204 shown in FIG. 1
  • the receiving unit 700 outputs the received signaling to the codec negotiation unit 704 and the signaling analysis unit 710.
  • the transmission unit 702 transmits communication data and signaling (for example, signaling 202 or 204 shown in FIG. 1) and the like.
  • the codec negotiation unit 704 negotiates a codec used for communication between the terminals (here, the UE 100 and the UE 102). Specifically, the codec negotiation unit 704 creates an SDP (Session Description Protocol) offer or SDP answer and performs codec negotiation. When the UE (UE 100 in FIG. 5) moves to the CS network, the codec negotiation unit 704 of the UE performs codec negotiation based on the negotiation method in the CS network. The codec negotiation unit 704 outputs the coding negotiation result to the codec selection unit 706.
  • SDP Session Description Protocol
  • FIG. 9 shows an example of SDP used for codec negotiation in the embodiment of the present invention.
  • codec A a codec that does not necessarily need to specify a bandwidth
  • the calling side UE specifies only the sampling frequency and does not specify the bandwidth. Generate an offer. For example, in FIG.
  • the SDP offer (SDP offer) generated by the calling UE includes an AMR-WB codec (for example, bandwidth: 50 Hz to 7 kHz, sampling frequency: 16000), which is a conventional WB codec, An AMR codec (for example, bandwidth: 300 Hz to 3.4 kHz, sampling frequency: 8000), which is an NB codec, and codec A (sampling frequency: 32000) that do not require designation of a bandwidth are described.
  • AMR-WB codec for example, bandwidth: 50 Hz to 7 kHz, sampling frequency: 16000
  • An AMR codec for example, bandwidth: 300 Hz to 3.4 kHz, sampling frequency: 8000
  • NB codec which is an NB codec
  • codec A sampling frequency: 32000
  • Codec A may be an incompatible mode of the above-mentioned EVS codec.
  • the maximum bandwidth supported by the sampling frequency 32000 of the codec A is equivalent to SWB (Super Wideband), and the encoder does not have the characteristics of the input signal or the encoding bit rate within this bandwidth even during the session. It is assumed that the bandwidth can be changed freely according to the above.
  • the codec selection unit 706 selects the codec negotiated by the codec negotiation unit 704, and outputs information indicating the selected codec to the bandwidth determination unit 708.
  • the bandwidth determination unit 708 determines the bandwidth of the input signal encoded in the own terminal with respect to the codec selected by the codec selection unit 706. For example, if the bandwidth of the codec selected by the codec selection unit 706 is constant, the bandwidth determination unit 708 selects the bandwidth. On the other hand, when the bandwidth of the codec selected by the codec selection unit 706 can be changed within one session, the bandwidth determination unit 708 changes the bandwidth of the input signal to be encoded. Decide for each frame. The bandwidth determination unit 708 determines the bandwidth of the input signal to be encoded for each frame in accordance with, for example, an encoding bit rate, input signal characteristics, or a request for bandwidth limitation by external signaling.
  • the bandwidth determining unit 708 determines the bandwidth of the input signal to be encoded. Limit (change) the requested bandwidth.
  • the signaling analysis unit 710 analyzes the signaling input from the reception unit 700.
  • the signaling includes, for example, signaling for requesting bandwidth limitation from the MSC / MGW 300 (signaling for bandwidth limitation).
  • the signaling analysis unit 710 notifies the codec mode change unit 712 of the result of the signaling analysis.
  • the codec mode changing unit 712 limits (changes) the bandwidth of the input signal to be encoded when the signaling analysis result input from the signaling analysis unit 710 is signaling requesting the limitation (change) of the bandwidth of the codec. And notifies the bandwidth determination unit 708 to that effect. That is, the codec mode changing unit 712 controls the change of the bandwidth determined by the bandwidth determining unit 708 according to signaling notified from the MSC / MGW 300 for limiting the bandwidth of the codec.
  • the signaling analysis unit 710 may analyze other external signaling and notify the codec mode change unit 712 of the analysis result.
  • the signaling analysis unit 710 may analyze the above-described RTCP-APP and notify the codec mode change unit 712 of the analysis result (for example, an encoding bit rate change request).
  • the codec mode changing unit 712 when determining the encoding bit rate, notifies the bandwidth determining unit 708 of the determined encoding bit rate. Then, the bandwidth determining unit 708 determines the bandwidth according to the determined encoding bit rate.
  • FIG. 10 is a sequence chart showing the operation of each device of the mobile communication network shown in FIG. 10, parts that are the same as those in FIG. 2 are given the same reference numerals, and descriptions thereof are omitted.
  • both UE 100 and UE 102 are currently connected to a radio access network that enables a VoLTE call service such as e-UTRAN (however, the radio access network and the base on UE 102 side) (Station and PS network not shown). That is, the VoLTE call is started between the UE 100 and the UE 102 illustrated in FIG.
  • a codec to be used is negotiated between the UE 100 and the UE 102 (see, for example, “3GPP TS26.114 v10.0.0“ IP Multimedia Subsystem (IMS); Multimedia Telephony; Media Handling and interaction ””) .
  • IMS IP Multimedia Subsystem
  • the UE 100 and the UE 102 (codec negotiation unit 704) negotiate the codec without specifying the bandwidth for the codec that does not necessarily need to specify the bandwidth (ST400 shown in FIGS. 5 and 10).
  • the UE 100 performs handover by SRVCC and moves to UTRAN. That is, assume that the UE 100 moves from the PS network to the CS network.
  • the codec used in the CS network is renegotiated between the UE 100 (codec negotiation unit 704) and the MSC / MGW 300 in the process of ST204 in FIG.
  • codec negotiation unit 704 it is assumed that the UE 100 is negotiated to use the AMR codec, and the bandwidth of the codec used by the UE 100 is limited to NB (ST 402 shown in FIGS. 5 and 10).
  • the MSC / MGW 300 (codec detection unit 604 and codec bandwidth detection unit 606) confirms that the codec used by the UE 102 is codec A and the maximum bandwidth is SWB by the process of ST202 in FIG. To detect.
  • MSC / MGW300 detects that the codec used in UE 100 is AMR and the bandwidth is limited to NB by the process of ST204 in FIG. To do.
  • MSC / MGW 300 determines whether the bandwidth of the input signal to be encoded to UE 102 can be limited and whether bandwidth limitation is necessary.
  • the codec of UE 100 is changed (ST800: Yes shown in FIG. 7)
  • the codec of UE 102 is codec A (ST802: Yes shown in FIG. 7)
  • the bandwidth (NB) of the AMR codec of UE 100 is It is narrower than the maximum bandwidth (SWB) of codec A of UE 102 (ST804: Yes shown in FIG. 7). Therefore, MSC / MGW 300 (change determining section 608) determines that the bandwidth of the input signal encoded to UE 102 can be limited and necessary (ST806 shown in FIG. 7).
  • the MSC / MGW 300 performs signaling for requesting the UE 102 to limit the bandwidth of the input signal encoded by the codec A to NB (the bandwidth of the codec after the change of the UE 100).
  • Send ST404 shown in FIGS. 5 and 10.
  • This signaling may be included in a series of signaling of ST202 (ie, IMS signaling), for example, RTCP (Real Time Control Control Protocol) -APP (Application-defined) (for example, “3GPP TS 26.114 v10.0.0” IP "Multimedia Subsystem” (IMS); Multimedia "Telephony;” Media “Handling” and “interaction” ").
  • FIG. 11A shows an example of the case where signaling for notifying band limitation is included in IMS signaling.
  • FIG. 11B shows an example of the case where RTCP-APP includes signaling for notifying bandwidth limitation.
  • the UE 102 (signaling analysis unit 710) analyzes signaling from MSC / MGW 300. Then, the UE 102 (codec mode changing unit 712) specifies that the bandwidth limitation of the codec A is requested. Therefore, the UE 102 (bandwidth determination unit 708) limits the bandwidth of the input signal encoded by the UE 102 to the requested bandwidth (here, NB). And UE102 encodes communication data with the limited bandwidth (ST406 shown in FIG. 10).
  • the UE 100 uses the codec bandwidth (NB) after the change, and the UE 102 uses the bandwidth limited bandwidth (NB) of the codec A.
  • NB codec bandwidth
  • both UE100 and UE102 use the same NB as the codec bandwidth. Therefore, in the MSC / MGW 300 (transcoding unit 612), even when transcoding from the UE 102 side to the UE 100 side (transcoding from codec A (ultra-wideband) to AMR codec (narrowband)) is performed, call quality is deteriorated. Can be suppressed.
  • the MSC / MGW 300 can change the UE 100 after changing the UE 100 with respect to the other UEs 102 even when the codec change occurs in some UEs 100 of the UE in communication.
  • the UE 102 limits the bandwidth of the input signal encoded by the UE 102 according to the UE 100 even when the codec of the UE 100 that is the communication partner during the VoLTE call is changed (changed to a narrow bandwidth). That is, the UE 102 changes the bandwidth of the input signal to be encoded without interrupting the communication with the UE 100 according to the network status of the UE 100 that is the communication counterpart.
  • the MSC / MGW 300 can perform transcoding while suppressing deterioration in communication quality.
  • the UE 102 limits only the bandwidth of the input signal to be encoded without changing the codec, signaling for changing the codec becomes unnecessary, and it is possible to prevent the call from being interrupted for a long time. .
  • the bandwidth of the input signal encoded by the UE 102 without interrupting the call can be limited.
  • the UE 100 uses rSRVCC (reverse SRVCC.
  • SRVCC reverse SRVCC.
  • the MSC / MGW 300 may transmit signaling for releasing the codec bandwidth restriction to the UE 102 at the time of receiving signaling related to the handover process from the CS network of the UE 100 to the PS network.
  • the MSC / MGW 300 may transmit signaling for releasing the codec bandwidth limitation to the UE 102 after the UE 100 completes the handover to the PS network.
  • the UE 100 may be connected to the CS network at the start of the call.
  • the UE 100 starts a call with the UE 102 connected to the PS network by a method described in “3GPP TS23.292 v10.3.0“ IP Multimedia Subsystem (IMS) centralized services ””.
  • IMS IP Multimedia Subsystem
  • the MSC / MGW 300 when the UE 100 supports rSRVCC (that is, when the UE 100 can be handed over to the PS network), when the MSC / MGW 300 negotiates a codec with the UE 102, the UE 100 Negotiations may be made in advance so that the bandwidth of the codec to be used is encoded as the maximum bandwidth. Alternatively, the MSC / MGW 300 may request bandwidth limitation of the input signal encoded in the UE 102 by another signaling after negotiation with the UE 102.
  • present embodiment has been described using the SRVCC scheme, the present embodiment can also be applied to the eSRVCC scheme.
  • transcoding is performed in the MGW (MSC / MGW300) when the codec used by the UE in communication is different.
  • the ATGW may transcode instead of the MGW transcoding.
  • the function added to the MSC / MGW 300 (see FIG. 5) according to the present embodiment for the SRVCC scheme is the ATCF / ATGW 1120 (see FIG. 3).
  • the ATCF / ATGW 1120 includes the reception unit 600, the transmission unit 602, the codec detection unit 604, the codec bandwidth detection unit 606, the change determination unit 608, the signaling generation unit 610, and the transcoding unit 612 illustrated in FIG.
  • the structure to comprise is taken.
  • the receiving unit 600 (FIG. 6) of the ATCF / ATGW 1120 in the eSRVCC method receives communication data, signaling, and the like. For example, when receiving unit 600 receives signaling (for example, signaling 1102 shown in FIG. 3) transmitted from UE 100, UE 102, ATCF, and MSC / MGW, the received unit 600 converts the received signaling into codec detection unit 604 and codec bandwidth. The data is output to the detection unit 606.
  • signaling for example, signaling 1102 shown in FIG. 3
  • the codec detection unit 604 detects the codec used by each of the UE 100 and the UE 102 based on signaling, communication data, and the like from the UE 100, UE 102, ATCF, and MSC / MGW input from the reception unit 600. Then, the codec detection unit 604 outputs information (detection result) indicating the detected codec to the change determination unit 608.
  • the codec bandwidth detection unit 606 detects codec bandwidths used by the UE 100 and the UE 102 based on signaling, communication data, and the like from the UE 100, the UE 102, and the MSC / MGW input from the reception unit 600. Then, the codec bandwidth detection unit 606 outputs information (detection result) indicating the detected codec bandwidth to the change determination unit 608.
  • ATCF / ATGW 1120 has been described as one node, but separate nodes may be used. Therefore, either or both of ATCF and ATGW may have the functions of ATCF / ATGW 1120 described above. Further, necessary information may be exchanged between the ATCF and the ATGW.
  • each UE may specify the maximum bandwidth in SDP instead of fixing and specifying the bandwidth in SDP as shown in FIG. 9 during coding negotiation.
  • the MSC / MGW 300 and ATGW may transmit signaling requesting the UE 102 to limit the bandwidth of the input signal to be encoded.
  • the MSC / MGW 300 and the ATGW may transmit signaling requesting the encoding bit rate limitation instead of the signaling requesting the bandwidth limitation.
  • each UE sets the bandwidth of the input signal to be encoded based on the encoding bit rate of the input signal. Therefore, the MSC / MGW 300 and the ATGW send a signaling requesting a restriction on the encoding bit rate to the UE, so that the UE sets the restricted encoding bit rate and based on the restricted encoding bit rate.
  • the MSC / MGW 300 and the ATGW may transmit signaling requesting a restriction on both the bandwidth and the encoding bit rate.
  • the MSC / MGW 300 (FIG. 6) has been described as one node.
  • the MSC / MGW 300 may be configured with two or more nodes connected to each other through an interface, and the functions of the MSC / MGW 300 described above may be distributed among these nodes.
  • Embodiment 2 In Embodiment 1, the case has been described in which MSC / MGW 300 or ATGW (ATCF / ATGW 1120) transmits signaling requesting UE 102 to limit the bandwidth of the input signal to be encoded.
  • the MSC / MGW 300 or the ATGW (ATCF / ATGW 1120) transmits the signaling for requesting the bandwidth limitation, instead of transmitting the communication data by the UE 102, so that the codec band of the UE 100 is received.
  • a case where it is detected that the width is limited and the bandwidth of the input signal encoded by the UE 102 is limited will be described.
  • the UE according to the present embodiment will be described with reference to FIG.
  • the reception unit 700, the transmission unit 702, the codec negotiation unit 704, the codec selection unit 706, and the bandwidth determination unit 708 are components that perform the same operations as in FIG. Omitted.
  • the data analysis unit 1200 analyzes communication data input from the reception unit 700.
  • the data analysis unit 1200 determines that the upper limit value of the codec bandwidth of communication data from a certain time to a predetermined time is the upper limit value of the codec bandwidth up to that time, or the upper limit value of the codec bandwidth negotiated at the start of the call. If it is different from the above, it is analyzed that the codec bandwidth of the communication data of the communication partner terminal (UE) is limited (changed).
  • the data analysis unit 1200 notifies the codec mode change unit 1202 of the analysis result.
  • the codec mode changing unit 1202 determines to limit (change) the bandwidth of the input signal to be encoded based on the analysis result from the data analyzing unit 1200, and notifies the bandwidth determining unit 708 to that effect. Thereby, the bandwidth determination unit 708 controls the change of the bandwidth determined by the codec mode change unit 1202.
  • UEs 100 and 102 determine whether or not the codec of the communication partner terminal has been changed according to whether or not the upper limit value of the codec bandwidth of the received communication data has been changed. To do.
  • the UEs 100 and 102 control the change of the bandwidth of the codec of the own device.
  • the bandwidth of the codec between the UEs can be maintained equal. Therefore, as in the first embodiment, it is possible to suppress deterioration in call quality that occurs when transcoding from a wide bandwidth codec to a narrow bandwidth codec.
  • FIG. 13 shows a configuration of a part of the mobile communication network according to Embodiment 3 of the present invention.
  • the operation of each node shown in FIG. 13 is as described above (for example, FIG. 5).
  • UE 100 first performs handover to the CS network using SRVCC (hereinafter also referred to as SRVCC handover), and transmits / receives communication data to / from UE 102 existing in the PS network via MSC / MGW 1300. (Path A and Path B shown in FIG. 13).
  • the UE 100 uses AMR-WB as a codec used in the CS network
  • the UE 102 uses, for example, the above-described codec A (a codec that does not necessarily need to specify a bandwidth) as a codec used in the PS network.
  • transcoding is performed in the MGW 1300.
  • the UE 102 also performs handover to the CS network by SRVCC.
  • the communication of the UE 102 in the destination CS network is terminated at the MSC / MGW 1302, and the communication partner of the MSC / MGW 1300 is changed from the UE 102 to the MSC / MGW 1302. That is, the path of communication data between the UE 100 and the UE 102 is changed to a path that passes Path D, Path C, and Path B.
  • the codec used by the UE 102 in the CS network is changed to AMR-WB.
  • communication data transmitted from UE 102 to UE 100 passes through Path D and is transmitted using AMR-WB.
  • the MSC / MGW 1302 performs transcoding from the AMR-WB used by the UE 102 in the CS network to the codec A used in the PS network. Therefore, from MSC / MGW 1302 to MSC / MGW 1300, communication data transmitted from UE 102 to UE 100 passes through Path C and is transmitted using codec A.
  • MSC / MGW 1300 performs transcoding from codec A to AMR-WB. Therefore, from MSC / MGW 1300 to UE 100, communication data transmitted from UE 102 to UE 100 passes through Path B and is transmitted using AMR-WB. The same applies to communication data transmitted from the UE 100 to the UE 102.
  • FIG. 14 is a block diagram showing a configuration of MSC / MGW 1300 and 1302 according to the present embodiment. Note that the MSC / MGWs 1300 and 1302 illustrated in FIG. 14 may include the functional blocks illustrated in FIG. 8 or other functional blocks in addition to the functional blocks illustrated.
  • the receiving unit 1500 receives communication data, signaling, and the like.
  • the transmission unit 1502 transmits communication data, signaling, and the like.
  • the signaling analysis unit 1504 analyzes signaling for SRVCC processing, IMS signaling (IMS signaling), or the like. The signaling analysis unit 1504 notifies the signaling analysis result to the signaling generation unit 1506, the terminal location determination unit 1508, and the codec selection unit 1510.
  • the signaling generation unit 1506 generates signaling based on the signaling analysis result of the signaling analysis unit 1504 and the like.
  • the terminal location determination unit 1508 determines whether both communicating terminals (UEs 100 and 102) exist in the PS network or the CS network based on the signaling analysis result of the signaling analysis unit 1504. Terminal position determination unit 1508 outputs the determination result to codec selection unit 1510 and route selection unit 1512.
  • the codec selection unit 1510 selects a codec or a codec candidate to be used based on the signaling analysis result of the signaling analysis unit 1504 and the determination result of the terminal location determination unit 1508.
  • the route selection unit 1512 selects a route through which communication data passes based on the determination result of the terminal position determination unit 1508.
  • FIG. 15 is a sequence chart showing the operation of each device of the mobile communication network shown in FIG. In FIG. 13, the SCC AS and CSCF are not shown, but are assumed to exist as part of the IMS.
  • UE 100 and UE 102 are both connected to e-UTRAN and performing VoLTE communication. That is, at present, UE 100 and UE 102 use the above-described codec A (a codec that does not necessarily need to specify a bandwidth) as a voice codec (ST1400 shown in FIG. 15).
  • codec A a codec that does not necessarily need to specify a bandwidth
  • the UE 100 performs handover (SRVCC handover) to the CS network (processing equivalent to the processing of ST200 (SRVCC processing) shown in FIG. 10). Also, the UE 100 hands over to the CS network and establishes a connection with the CS network (a process equivalent to the process of ST204 (connection establishment process) shown in FIG. 10).
  • SRVCC handover handover
  • ST200 processing of ST200
  • ST204 connection establishment process
  • the signaling generation unit 1506 of the MSC / MGW 1300 generates IMS signaling to be transmitted to the UE 102 and transmits it via the transmission unit 1502 (ST1402 shown in FIG. 15).
  • the signaling generation unit 1506 includes information indicating the IMS signaling generated by the SRVCC handover in the IMS signaling.
  • the information indicating that the IMS signaling is generated by SRVCC handover may be STN-SR (Session Transfer Number for SRVCC) described in Non-Patent Document 3.
  • the signaling generation unit 1506 of the MSC / MGW 1300 is supported by the CS network (CS network to which the MSC / MGW 1300 belongs) in addition to the codec (codec A) used by the UE 100 in the PS network.
  • the codec list is included in the IMS signaling (ST1402 shown in FIG. 15).
  • signaling analysis section 1504 waits for connection establishment processing of ST204, analyzes signaling related to connection establishment, obtains codec information used by UE 100 in the CS network, and then signaling generation section 1506 obtains this codec information. It may be explicitly included in IMS signaling.
  • UE 100 to MSC / MGW 1300 perform communication using the CS network
  • MSC / MGW 1300 to UE 102 perform communication using the PS network (ST1404 shown in FIG. 15).
  • the UE 102 performs handover (SRVCC handover) to the CS network (processing equivalent to ST200 (SRVCC processing) shown in FIG. 10). Also, the UE 102 hands over to the CS network and establishes a connection with the CS network (a process equivalent to the process of ST204 (connection establishment process) shown in FIG. 10).
  • the signaling generation unit 1506 of the MSC / MGW 1302 generates IMS signaling to be transmitted to the MSC / MGW 1300 and transmits it via the transmission unit 1502 (ST1406 shown in FIG. 15).
  • the signaling generation unit 1506 includes information indicating the IMS signaling generated by the SRVCC handover in the IMS signaling.
  • the information indicating that the IMS signaling is generated by SRVCC handover may be STN-SR (Session Transfer Number for SRVCC) described in Non-Patent Document 3.
  • the signaling generation unit 1506 of the MSC / MGW 1302 is supported by the CS network on the local network side (CS network to which the MSC / MGW 1302 belongs) in addition to the codec (codec A) used by the UE 102 in the PS network.
  • the codec list is included in the IMS signaling (ST1406 shown in FIG. 15).
  • signaling analysis section 1504 waits for connection establishment processing of ST204, analyzes signaling related to connection establishment, obtains codec information used by UE 102 in the CS network, and then signaling generation section 1506 obtains this codec information. It may be explicitly included in IMS signaling.
  • the reception unit 1500 of the MSC / MGW 1300 receives the IMS signaling from the MSC / MGW 1302 and outputs it to the signaling analysis unit 1504.
  • the signaling analysis unit 1504 analyzes the IMS signaling to identify that the UE 102 has performed SRVCC handover, and outputs information indicating that the UE 102 has performed SRVCC handover to the terminal location determination unit 1508. Further, the signaling analysis unit 1504 outputs a codec list (a list of codecs supported by the CS network to which the MSC / MGW 1302 belongs) included in the IMS signaling (SDP offer) to the codec selection unit 1510.
  • a codec list a list of codecs supported by the CS network to which the MSC / MGW 1302 belongs
  • Terminal location determining section 1508 determines that both UE 100 and 102 exist in the CS network when UE 102 performs SRVCC handover.
  • the codec selection unit 1510 uses the determination result of the terminal location determination unit 1508 and the codec information (codec list) supported by the CS network to which the MSC / MGW 1302 belongs, input from the signaling analysis unit 1504.
  • the codec to be selected is selected (ST1406 shown in FIG. 15).
  • route selection section 1512 selects a route through which communication data passes based on the determination result of terminal position determination section 1508 (ST1406 shown in FIG. 15). Thereby, communication between UE100 and UE102 is performed through the selected path
  • FIG. 16 shows an example of a codec selection method in the codec selection unit 1510 of the MSC / MGW 1300 shown in FIGS.
  • codec selection section 1510 determines whether or not both terminals (UEs 100 and 102) in communication have moved (exists) to the CS network based on the determination result of terminal position determination section 1508. to decide.
  • the codec selection unit 1510 indicates that the communication partner terminal (UE102) is in the CS network according to the IMS signaling received by the reception unit 1500. It is determined whether or not codec information to be used (codec list) is included.
  • the codec selection unit 1510 determines that the codec information used by the communication partner terminal (UE102) in the CS network is It is determined whether or not the network side terminal (UE 100) matches the codec being used. When the codec information matches the codec being used by the terminal (UE 100) on the own network side, the process proceeds to ST1614.
  • codec selection section 1510 When both communicating terminals have not moved to the CS network (ST1600: NO), in ST1606, codec selection section 1510 has its own device (MSC / MGW1300) corresponding to the codec used in the PS network. Determine whether or not. When the device itself (MSC / MGW 1300) does not support the codec used in the PS network (ST1606: NO), the process proceeds to ST1612.
  • the codec selection unit 1510 determines whether the codec currently used by the UE (UE 100) on the local network side is included in the codec information (codec list) offered by IMS signaling (SDP offer). to decide. If the offered codec list includes a codec currently used by the UE (UE 100) on the local network side (ST1608: YES), the process proceeds to ST1614.
  • the codec selection unit 1510 performs IMS signaling (SDP offer). It is determined whether or not a codec supported by the own device (MSC / MGW 1300) is included in the codec list offered by the device. If the offered codec list includes a codec supported by the own device (ST1610: YES), the process proceeds to ST1616. If the codec list supported by the device is not included in the offered codec list (ST1610: NO), the process proceeds to ST1618.
  • SDP offer IMS signaling
  • the codec selection unit 1510 selects a codec used in the PS network.
  • the codec selection unit 1510 selects a codec being used by the terminal (UE 100) on the own network side as a codec to be used.
  • the codec selection unit 1510 selects a codec to be used from the codecs supported by the own device (MSC / MGW 1300) from the offered codec list.
  • the codec selection unit 1510 selects an error.
  • the MSC / MGW 1300 and 1302 include a list of codecs supported by the CS network on the local network side in the IMS signaling generated by the handover.
  • the MSC / MGW 1300 (MSC / MGW 1302) first determines that both terminals in communication exist in the CS network. Further, the MSC / MGW 1300 (MSC / MGW 1302) selects a codec to be used using codec information supported by the CS network to which the MSC / MGW to which the IMS signaling is transmitted belongs. Specifically, the MSC / MGW 1300 and 1302 can use the same codec in both terminals when both terminals (UE 100 and 102) in communication can use the same codec. Select the codec to use.
  • the MSC / MGW 1300 belonging to the CS network on the UE 100 side moves to the CS network on the UE 102 side.
  • a message including a codec list (codec group) supported by the CS network on the UE 102 side is received from the MSC / MGW 1302 to which the UE belongs, and using the codec list and the codec (changed codec) used by the UE 100, The codec used by the UE 102 is selected. For example, when the received codec list includes the codec used by the UE 100 (changed codec), the MSC / MGW 1300 selects the codec used by the UE 100 as the codec used by the UE 102.
  • MSC / MGW 1300, 1302 does not perform transcoding. Therefore, according to the present embodiment, even when both UE 100 and UE 102 in communication perform SRVCC handover, transcoding in MSC / MGW 1300 and 1302 can be minimized.
  • the MSC / MGW 300 detects a change in the codec bandwidth and transmits signaling requesting the UE 102 to limit the bandwidth of the encoded input signal.
  • MSC / MGW 1300 and 1302 perform signaling for requesting limitation of the bandwidth of the input signal to be encoded after obtaining the codec information used by the terminal on the network side in the CS network.
  • the codec information is explicitly included in the IMS signaling and transmitted to the communication counterpart terminal. Even in this case, as in the first embodiment, even when the network conditions of one or both UEs change, the bandwidth of the codec between the UEs can be kept equal.
  • the route selection unit 1512 may switch all the routes on the network side to routes for the CS network. For example, the terminal position determination unit 1508 may determine whether both terminals support rSRVCC. That is, when both terminals (UEs 100 and 102) do not support rSRVCC, the route selection unit 1512 may switch the route on the network side to the route for the CS network. Whether or not both terminals support rSRVCC can be realized by a method equivalent to the registration method of SRVCC support or the method of obtaining whether or not SRVCC support is described in Non-Patent Document 3.
  • the terminal receives the signaling requesting the bandwidth limitation of the input signal to be encoded
  • the communication partner side terminal performs the handover by SRVCC. If it is determined that the communication is made to the MSC / MGW on the network side (for example, MSC / MGW1310 shown in FIG. 17) by signaling (ST200 or ST204 shown in FIG. 15) when the own device performs handover by SRVCC. You may notify that the other party side terminal (UE100) has already performed the hand-over by SRVCC.
  • the terminal location determination unit 1508 of the MSC / MGW 1310 determines that both terminals (UEs 100 and 102) have handed over to the CS network, and is supported only in the PS network in the codec list of IMS signaling (SDP offer). Can be included. That is, the MSC / MGW 1310 can include only codecs supported by the CS network in the SDP offer (see FIG. 17). At this time, the MSC / MGW 1310 may explicitly notify that the own device is an MGW (see, for example, FIG. 17). Further, the MSC / MGW 1300 that has received the notification may decide to communicate with each other between CS networks (see, for example, FIG. 17).
  • the notification may be included in existing signaling transmitted from the UE 102 when the UE 102 is handed over to the CS network, or may be new signaling. Further, the notification may be included in signaling transmitted to the MME (not shown) before the UE 102 hands over to the CS network (see, for example, Non-Patent Document 4).
  • FIG. 18 is a configuration showing a part of the mobile communication network according to Embodiment 4 of the present invention. The operation of each node shown in FIG. 18 is as described above (for example, FIGS. 3 and 5).
  • both the UE 100 and the UE 102 initially exist in the e-UTRAN, and perform VoLTE communication in the PS network.
  • codec A a codec that does not necessarily need to specify a bandwidth
  • FIG. 18 it is assumed that both the network on the UE 100 side and the network on the UE 102 side support eSRVCC. Accordingly, the current communication path between the UE 100 and the UE 102 is Path A, Path B, and Path C via the ATCF / ATGW 1700 and the ATCF / ATGW 1702.
  • ATCF / ATGW 1700 and 1702 are represented as one node, but may be separate nodes.
  • the UE 100 side network does not support eSRVCC
  • ATCF / ATGW 1700 and Path B do not exist as communication paths between the UE 100 and the UE 102
  • Path A is connected to the UE 100 and the ATCF / Established with the ATGW 1702.
  • the network on the UE 102 side does not support eSRVCC
  • ATCF / ATGW 1702 and Path B do not exist as communication paths
  • Path C is established between the UE 102 and the ATCF / ATGW 1700.
  • each of the UE 100 and the UE 102 performs handover by eSRVCC.
  • the communication path between the UE 100 and the UE 102 after the handover passes through the MSC / MGW 1704, the ATCF / ATGW 1700, the ATCF / ATGW 1702, and the MSC / MGW 1706, Path D, Path E, and Path.
  • both codecs used when the UEs 100 and 102 are handed over to the CS network are AMR-WB.
  • communication data from the UE 100 to the ATCF / ATGW 1700 is encoded by AMR-WB.
  • the ATGW 1700 then transcodes from AMR-WB to Codec A. Therefore, communication data between ATGW 1700 and ATGW 1702 is encoded by codec A.
  • ATGW 1702 performs transcoding from codec A to AMR-WB again. Therefore, communication data between the ATGW 1702 and the UE 102 is encoded by AMR-WB.
  • transcoding is performed by MSC / MGW 1704 instead of ATGE1700.
  • transcoding is performed by the MSC / MGW 1706 instead of the ATGE 1702.
  • both UE 100 and UE 102 in communication perform handover from the PS network to the CS network by the eSRVCC method, or one UE performs handover from the PS network to the CS network by the eSRVCC method
  • a method for minimizing transcoding will be described in the case where the UE performs handover from the PS network to the CS network by the SRVCC method.
  • FIG. 19 is a block diagram showing a configuration of ATCF / ATGW 1700 and 1702 according to the present embodiment. Note that the ATCF / ATGWs 1700 and 1702 shown in FIG. 19 may include the functional blocks shown in FIG. 8 or other functional blocks in addition to the functional blocks shown.
  • the receiving unit 1900 receives communication data, signaling, and the like.
  • the transmission unit 1902 transmits communication data, signaling, and the like.
  • the signaling analysis unit 1904 analyzes signaling for SRVCC processing or eSRVCC processing, IMS signaling (IMS signaling), or the like.
  • the signaling analysis unit 1904 notifies the signaling analysis result to the signaling generation unit 1906, the terminal location determination unit 1908, and the codec selection unit 1910.
  • the signaling generation unit 1906 generates signaling based on the signaling analysis result of the signaling analysis unit 1904 and the like.
  • the terminal location determination unit 1908 determines whether both communicating terminals (UEs 100 and 102) exist in the PS network or the CS network based on the signaling analysis result of the signaling analysis unit 1904. Terminal position determination section 1908 outputs the determination result to codec selection section 1910 and route selection section 1912.
  • the codec selection unit 1910 selects a codec to be used or a codec candidate based on the signaling analysis result of the signaling analysis unit 1904 and the determination result of the terminal location determination unit 1908.
  • the route selection unit 1912 selects a route through which communication data passes based on the determination result of the terminal position determination unit 1908.
  • FIG. 20 is a block diagram showing a configuration of UEs 100 and 102 according to the present embodiment.
  • the UEs 100 and 102 may include the functional blocks illustrated in FIG. 12 or other functional blocks in addition to the functional blocks illustrated.
  • the receiving part 700 and the transmission part 702 are a structure part which performs the same operation
  • the communication partner codec change detection unit 2000 detects that the codec used by the communication partner has been changed.
  • the reason for changing the codec used by the communication partner is, for example, that the PS network has moved to the CS network.
  • the codec change detection method in the communication partner codec change detection unit 2000 includes, for example, a method of receiving signaling such as a bandwidth limitation notification from the network as described in the first embodiment, and the second embodiment. For example, a method for detecting that the bandwidth of the codec used by the communication partner is limited, and the like.
  • the signaling generation unit 2002 When the communication partner codec change detection unit 2000 detects that the communication partner codec has been changed, the signaling generation unit 2002 generates signaling for notifying the network that the communication partner codec has been changed. .
  • FIG. 21 is a sequence chart showing the operation of each device of the mobile communication network shown in FIG.
  • ATCF / ATGW 1700, 1702 information on the ATCF (ATCF / ATGW 1700, 1702) is sent to the SCC AS, HSS (not shown) or MME (not shown). The information is held at the transmission destination (see, for example, Non-Patent Document 5).
  • ATCF / ATGW 1700 and 1702 perform ATCF. Determines whether to anchor the session with ATGW (see, for example, Non-Patent Document 3 or Non-Patent Document 5).
  • the UE 100 and the UE 102 are both connected to the e-UTRAN and perform VoLTE communication.
  • codec A a codec that does not necessarily need to specify a bandwidth
  • an audio codec ST1800 shown in FIG. 21.
  • the UE 100 hands over from the PS network to the CS network.
  • processing equivalent to the processing of ST200 (SRVCC processing) and the processing of ST204 (connection establishment processing) shown in FIG. 10 is performed.
  • processing equivalent to the processing of ST1102 shown in FIG. 4 is performed.
  • the data communication path between UE 100 and UE 102 is switched via MSC / MGW 1704 (ST1802 shown in FIG. 21).
  • the signaling generation unit 1906 of the ATCF / ATGW 1700 generates a message including a codec (for example, AMR) used by the UE 100 in the CS network, and notifies the SCC AS / CSCF 1708 via the transmission unit 1902 ( ST1802 ′ shown in FIG.
  • This notification may be notified together with the Access Transfer Update message described in Non-Patent Document 3.
  • the ATCF / ATGW 1700 may transmit a band limitation notification to the UE 102.
  • the communication partner codec change detection unit 2000 of the UE 102 detects that the codec of the UE 100 is changed from the codec A (ST1804 shown in FIG. 21).
  • the UE 102 also hands over from the PS network to the CS network.
  • the signaling generation unit 2002 of the UE 102 generates signaling for notifying the network that the codec of the UE 100 that is the communication partner has been changed.
  • This signaling may be included in the existing signaling transmitted from the UE 102 when the UE 102 is handed over to the CS network, or may be included in the new signaling (ST1806 shown in FIG. 21).
  • the notification may be included in signaling transmitted to the MME (not shown) before the UE 102 hands over to the CS network, and may be notified from the MME to the MSC / MGW 1706 (for example, Non-Patent Document 4). reference).
  • the MSC / MGW 1706 that has received the signaling from the UE 102 detects that the codec of the UE 100 that is the communication partner of the UE 102 has been changed, and displays information indicating that the codec of the UE 100 has been changed as ATCF / ATGW 1702. It is included in the INVITE message transmitted to.
  • the signaling analysis unit 1904 of the ATCF / ATGW 1702 that has received this INVITE message detects that the codec of the UE 100 that is the communication partner of the UE 102 has been changed. Therefore, the signaling generator 1906 of the ATCF / ATGW 1702 generates signaling for the codec inquiry of the UE 100 to the SCC AS / CSCF 1708, and transmits the signaling via the transmitter 1902 (ST1808 shown in FIG. 21). .
  • the receiving section 1900 of the ATCF / ATGW 1702 receives from SCC AS / CSCF 1708 return signaling for the signaling transmitted in ST1808. Then, the signaling analysis section 1904 of the ATCF / ATGW 1702 analyzes this return signaling and performs codec negotiation with the ATCF / ATGW 1700 based on the analysis result (information on the codec of the UE 100) (ST1810 shown in FIG. 21). The codec is selected (ST1812 shown in FIG. 21). The codec negotiation may be performed between the ATCF / ATGW 1702 and the SCC AS / CSCF 1708 and between the SCC AS / CSCF 1708 and the ATCF / ATGW 1700 (that is, may be anchored by the SCC AS). The ATCF / ATGW 1700 and 1702 may perform codec negotiation without using the SCC AS / CSCF 1708. In this case, the processing of ST1802 and the processing of ST1808 shown in FIG. 21 are not necessary.
  • the ATCF / ATGW 1700, 1702 when the terminal (UE 100, 102) is handed over, the ATCF / ATGW 1700, 1702 generates a message including the codec used by the handed over terminal in the CS network, and notifies the SCC AS / CSCF 1708 of the message. .
  • the communication partner terminal communicating with the handed over terminal detects that the codec of the handed over terminal has been changed.
  • the ATCF / ATGW 1700 and 1702 change the codec of the terminal handed over first according to the notification from the communication partner terminal.
  • the SCC AS / CSCF 1708 is inquired about the codec of the communication partner.
  • the ATCF / ATGW 1700 and 1702 perform codec negotiation based on the information regarding the codec (the codec of the terminal that has first performed handover) obtained through the inquiry, and select the codec.
  • the ATCF / ATGW 1700 and 1702 use a codec to be used so that both terminals (UEs 100 and 102) in communication can use the same codec when both terminals can use the same codec. Select.
  • the ATCF / ATGW 1702 uses the codec used by the UE 100 by making an inquiry to the SCC AS / CSCF 1708.
  • Information indicating that the UE 100 has been handed over to the CS network by receiving a message containing information indicating that the UE 100 has been handed over to the CS network from the MSC / MGW 1706 on the UE 102 side. Is received, the codec used by the UE 102 is selected based on the codec used by the UE 100.
  • the same codec is used if possible, as in Embodiment 3, and therefore transcoding is not performed in ATCF / ATGW 1700 and 1702. Therefore, according to the present embodiment, when both UE 100 and UE 102 in communication perform handover from the PS network to the CS network by the eSRVCC method, the transcoding can be minimized as in the third embodiment. it can.
  • the route selection unit 1912 may switch all the routes on the network side to the routes for the CS network. For example, the terminal position determination unit 1908 may determine whether both terminals support rSRVCC. That is, when both terminals (UE 100 and 102) do not support rSRVCC, the route selection unit 1912 may switch the route on the network side to the route for the CS network. Whether or not both terminals support rSRVCC can be realized by a method equivalent to the registration method of SRVCC support or the method of obtaining whether or not SRVCC support is described in Non-Patent Document 3.
  • the terminal receives a request for limiting the bandwidth of the input signal to be encoded, and the other party terminal (for example, UE 100 shown in FIG. 21) performs handover by SRVCC or eSRVCC. If it is determined that the mobile station MSC / MGW (for example, MSC / MGW 1706 shown in FIG. 21) is subject to signaling (ST200 / ST204 shown in FIG. 21) when the mobile station performs handover by eSRVCC. The communication counterpart terminal (UE 100) may notify that the handover by SRVCC or eSRVCC has already been performed.
  • the terminal location determination unit 1908 of the MSC / MGW 1706 determines that both terminals (UEs 100 and 102) have handed over to the CS network, and is supported only in the PS network in the codec list of IMS signaling (SDP offer). Can be included.
  • This notification may be included in, for example, existing signaling sent from the UE 102 when the UE 102 is handed over to the CS network, or may be new signaling (ST 1806 shown in FIG. 21). Further, the notification may be included in signaling transmitted to the MME (not shown) before the UE 102 hands over to the CS network (for example, see Non-Patent Document 4).
  • the MSC / MGW 1704 and 1706 may have functions equivalent to those of the ATCF / ATGW 1700 and 1702.
  • the signaling analysis unit 1904 of the MSC / MGW 1704 analyzes the signaling including the codec used in the CS network when the UE 100 is handed over to the CS network. The information of the codec used by the UE 100 in the CS network is obtained.
  • the signaling generator 1906 of the MSC / MGW 1704 generates codec information used by the UE 100 in the CS network, and notifies the SCC AS / CSCF 1708 of the information. This notification may be included in the INVITE message.
  • FIG. 1904 of the MSC / MGW 1704 analyzes the signaling including the codec used in the CS network when the UE 100 is handed over to the CS network. The information of the codec used by the UE 100 in the CS network is obtained.
  • the signaling generator 1906 of the MSC / MGW 1704 generates codec information used by the
  • the MSC / MGW 1706 signaling analysis unit 1904 notifies the UE 102 that the codec of the communication partner UE 100 has been changed. Is detected, it is detected that the codec of the UE 100 that is the communication partner of the UE 102 has been changed.
  • the signaling generator 1906 of the MSC / MGW 1706 generates signaling for inquiring the codec of the UE 100 to the SCC AS / CSCF 1708 and transmits the signaling to the SCC AS / CSCF 1708.
  • the signaling analysis unit 1904 of the MSC / MGW 1706 analyzes the reply signaling, and based on the analysis result, a node (MSC / MGW 1704 or ATCF / ATGW 1700) that performs transcoding on the UE 100 side.
  • a codec To select a codec. Note that codec negotiation may be performed between the MSC / MGW 1706 and the SCC AS / CSCF 1708 and between the SCC AS / CSCF 1708 and the node that performs transcoding on the UE 100 side (ie, anchored by the SCC AS). May be) Thereby, even when one UE performs handover from the PS network to the CS network by the eSRVCC scheme and the other UE by the SRVCC scheme, the transcoding can be minimized as in the third embodiment.
  • Embodiment 5 In Embodiments 1, 3, and 4, when MSC / MGW or ATCF / ATGW detects a change in the bandwidth of communication data of one UE during a session, a method of performing band limitation notification to the other UE Explained.
  • communication data sent by MSC / MGW or ATCF / ATGW, or a header part of an RTP payload of communication data A method for explicitly including bandwidth information in the.
  • the codec bandwidth detection unit 606 of the MSC / MGW 300 detects the bandwidth change of the UE 100, and the change determination unit 608 can limit the bandwidth of the input signal encoded to the UE 102.
  • the bandwidth of communication data sent from the MSC / MGW 300 to the UE 102 is also limited.
  • the changed bandwidth information is explicitly included in the communication data itself sent by the MSC / MGW 300 or the RTP payload header part in which the communication data is stored.
  • the packets including the bandwidth information are limited to packets sent within a certain period after the bandwidth change (for example, 200 msec) or a certain number of packets (for example, 10 packets). .
  • the receiving side detects that the bandwidth information is added to the RTP payload header of a certain period (for example, 150 msec or more) or a specific number (for example, 5 packets or more), the RTP sent after that is detected. Even when band information is not added to the payload header, it is determined that the bandwidth of the stored communication data continues to be limited.
  • a certain period for example, 150 msec or more
  • a specific number for example, 5 packets or more
  • the UE 102 that has received the bandwidth limitation notification transmits the communication data whose bandwidth is limited to the MGW 300
  • a packet sent in a certain period for example, 200 msec
  • a certain number of packets for example, 10 packets
  • Band information is added to the RTP payload header.
  • the receiving side detects that the bandwidth information is added to the RTP payload header of a certain period (for example, 150 msec or more) or a specific number (for example, 5 packets or more), the RTP sent after that is detected. Even when band information is not added to the payload header, it is determined that the bandwidth of the stored communication data continues to be limited.
  • the data analysis unit 1200 of the UE 102 instead of receiving the bandwidth limitation notification, the data analysis unit 1200 of the UE 102 detects that the bandwidth of the data itself is limited for a certain time and limits the bandwidth of the data to be transmitted.
  • the above-described method of the present embodiment bandwidth information is added to a RTP payload header of a certain period (for example, 150 msec or more) or a specific number (for example, 5 packets or more) is used.
  • the codec mode changing unit 1202 may decide to change the band.
  • the bandwidth limitation notification itself may be included in the RTP payload header.
  • the packet including the bandwidth limitation notification is a packet sent for a certain period (for example, 100 msec) after it is determined that the bandwidth change notification is necessary, or a certain number of packets. Packets (for example, 5 packets).
  • the receiving side UE 102 detects that a bandwidth limit notification is added to a RTP payload header of a certain period (for example, 20 msec or more) or a specific number (for example, 1 packet or more), it is sent thereafter.
  • bandwidth limitation notification is not added to the RTP payload header, it is determined that it is notified that the bandwidth limitation (change) is requested. Note that when the bandwidth limitation notification is included in the RTP payload header, the above-described bandwidth information may be included together with the bandwidth limitation notification.
  • ATCF / ATGW, MSC / MGW, and SCC AS / CSCF are described as one node, but separate nodes may be used. That is, either one or both of the above functions may be provided between the ATCF and the ATGW, between the MSC and the MGW, and between the SCC AS and the CSCF. Further, necessary information may be exchanged between the ATCF and the ATGW, between the MSC and the MGW, and between the SCC AS and the CSCF.
  • the session is negotiated with the CS network during session negotiation on the PS network.
  • a codec that is compatible with a supported codec or a codec supported by the CS network may be selected from the beginning.
  • each functional block used in the description of each of the above embodiments is typically realized as an LSI which is an integrated circuit. These may be individually made into one chip, or may be made into one chip so as to include a part or all of them. Although referred to as LSI here, it may be referred to as IC, system LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable / processor that can reconfigure the connection or setting of circuit cells inside the LSI may be used.
  • the present invention has a function of adjusting the bandwidth or encoding bit rate of the input signal encoded by the codec used by the communication partner when the codec used by one of the communication terminals in communication is changed. This is useful for suppressing quality degradation due to coding.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)

Abstract

　通信中の端末の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えること。変更判断部（６０８）は２つの端末の一方の端末が使用するコーデックの変更を検出した場合、他方の端末の第１のコーデック、及び、一方の端末の変更後の第２のコーデックを用いて第１のコーデックの帯域幅を制限するか否かを判断し、シグナリング生成部（６１０）は帯域幅を制限する場合に帯域幅を制限させるためのシグナリングを他方の端末へ送信する。

Description

ネットワークノード、端末、帯域幅変更判断方法及び帯域幅変更方法
　本発明は、移動通信方式で用いられるコーデック変更を行うネットワークノード、端末、帯域幅変更判断方法及び帯域幅変更方法に関する。
　従来、３ＧＰＰ（Third Generation Partnership Project）の移動通信方式における音声通話は、３ＧＰＰの回線交換（ＣＳ：Circuit Switching）網を用いて行われていた。近年では、３ＧＰＰのパケット交換（ＰＳ：Packet Switching）網を用いた音声通話であるＶｏＬＴＥ（Voice over Long Term Evolution）サービスが行われつつある。
　しかし、ＶｏＬＴＥサービスが受けられるエリアは当面の間限られる。このため、ＶｏＬＴＥによる音声通話（以下、ＶｏＬＴＥ通話という）中にＶｏＬＴＥサービスエリアの外に出た場合、従来の回線交換方式を用いた通話に切り替える必要がある。この切替を可能にする技術として、非特許文献１に記載のＳＲＶＣＣ（Single Radio Voice Call Continuity）がある。以下、図１及び図２を用いて、ＳＲＶＣＣによるハンドオーバの動作について説明する。
　図１は３ＧＰＰの移動通信ネットワーク構成の一部を示す。図１に示す移動通信ネットワークは、ｅ－ＵＴＲＡＮ（evolved Universal Terrestrial Radio Access Network）、ｅ－ＵＴＲＡＮの基地局（ｅ－ｎｏｄｅＢ）、ＰＳ網、ＣＳ網、ＣＳ網の基地局サブシステム、及びＩＭＳ（IP Multimedia Subsystem）から構成される。
　具体的には、図１において、ｅ－ＵＴＲＡＮは、ＶｏＬＴＥサービスを提供可能な無線アクセス網である。ＰＳ網は、ＶｏＬＴＥサービスを提供し、Ｐ－ＧＷ（Packet Data Network Gateway）、Ｓ－ＧＷ（Serving Gateway）及びＭＭＥ（Mobility Management Entity）から構成される。ＣＳ網は、ＭＳＣ（Mobile Switching Center）、ＭＧＷ（Media Gateway）から構成される。ＣＳ網の基地局サブシステムは、ＲＮＣ（Radio Network Controller）及びｎｏｄｅＢから構成される。ＩＭＳは、呼制御等を行い、ＣＳＣＦ（Call Session Control Function）及びＳＣＣ　ＡＳ（Service Centralization and Continuity Application Server）から構成される。
　図１において、移動通信端末（ＵＥ：User Equipment）であるＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。つまり、ＵＥ１００とＵＥ１０２とでＶｏＬＴＥ通話が行われているとする。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。
　図１の実線で示されたＰａｔｈ　Ａ、Ｐａｔｈ　Ｂ及びＰａｔｈ　Ｃは、通話データが通る経路を示す。また、図１の破線で示された２００、２０２、２０４及び２０６は、ＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。
　図２は、ＳＲＶＣＣハンドオーバ処理の動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ－ＵＴＲＡＮ）にそれぞれ接続されており、ＵＥ１００とＵＥ１０２との間の通話データはＰａｔｈ　Ａを通って送受信されている。ＵＥ１００がｅ－ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ－ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図１に示すシグナリング２００。図２に示すステップ（以下、「ＳＴ」という）２００）。ＳＴ２００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷとの間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ－ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令が出される。
　ＳＴ２００の処理と同時に、ＭＳＣ／ＭＧＷは、ＣＳＣＦ／ＳＣＣ　ＡＳ経由でＵＥ１０２とシグナリングをやり取りする（図１に示すシグナリング２０２。図２に示すＳＴ２０２）。これにより、ＵＥ１０２の通話データの送受信先を、ＵＥ１００からＭＳＣ／ＭＧＷに切り替えるよう命令が出され、Ｐａｔｈ　Ｂが確立される。
　ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷとシグナリングをやり取りする（図１に示すシグナリング２０４。図２に示すＳＴ２０４）。これにより、Ｐａｔｈ　Ｃが確立される。
　Ｐａｔｈ　Ｃ確立後、ＭＳＣ／ＭＧＷは、ＭＭＥ経由でＰ－ＧＷ／Ｓ－ＧＷとシグナリングをやり取りする（図１に示すシグナリング２０６。図２に示すＳＴ２０６）。これにより、Ｐａｔｈ　Ａは削除される。
　以上、ＳＲＶＣＣハンドオーバの動作について説明した。
　また、ＳＲＶＣＣを改良し、データ経路切替にかかる時間を短縮する方式として、非特許文献３に記載の、ＡＴＣＦ（Access Transfer Control Function）エンハンスメントを用いたＳＲＶＣＣ方式（ｅＳＲＶＣＣ：enhanced-SRVCC）がある。このｅＳＲＶＣＣの動作の一例について、以下、図３及び図４を用いて説明する。
　図３は、ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワーク構成の一部を示す。図３に示す移動通信ネットワークは、図１と同様、ｅ－ＵＴＲＡＮ、ｅ－ｎｏｄｅＢ、ＰＳ網、ＣＳ網、ＣＳ網の基地局サブシステム、及びＩＭＳから構成される。ここでＩＭＳには、ＣＳＣＦ及びＳＣＣ　ＡＳの他、ＡＴＣＦ（Access Transfer Control Function）及びＡＴＧＷ（Access Transfer GateWay）が存在する。なお、図３及び図４では、ＡＴＣＦとＡＴＧＷとを一つのノード（ＡＴＣＦ／ＡＴＧＷ１１２０）として表しているが、これらは別々のノードとして表してもよい。
　図３において、ＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。つまり、ＵＥ１００とＵＥ１０２とでＶｏＬＴＥ通話が行われているとする。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。
　図３の実線で示されたＰａｔｈ　Ａ、Ｐａｔｈ　Ｂ、Ｐａｔｈ　Ｃ及びＰａｔｈ　Ｄは、通話データが通る経路を示す。また、図３の破線で示された１１００、１１０２、１１０４及び１１０６は、ｅＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。
　図４は、ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ－ＵＴＲＡＮ）にそれぞれ接続されている。ｅＳＲＶＣＣハンドオーバを実現するシステムでは、ＡＴＣＦ／ＡＴＧＷ１１２０において、ＡＴＣＦはＩＭＳのシグナリング（ＩＭＳシグナリング）をアンカーし、ＡＴＧＷは通話データをアンカーする。つまり、ＵＥ１００とＵＥ１０２との間の通話開始時において、通話開始のＩＭＳシグナリングはＡＴＣＦで中継され、ＡＴＣＦがＡＴＧＷでの通話データのアンカーが必要と判断した場合、通話データのアンカーポイントとしてＡＴＧＷが割り当てられる。これにより、ＵＥ１００とＵＥ１０２との間の通話データは、Ｐａｔｈ　Ａ及びＰａｔｈ　Ｂを通って送受信される。
　ＵＥ１００がｅ－ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ－ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図３に示すシグナリング１１００。図４に示すＳＴ１１００）。ＳＴ１１００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷとの間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ－ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令が出される。
　ＳＴ１１００の処理と同時に、ＭＳＣ／ＭＧＷは、ＡＴＣＦにシグナリングを送る。これによりＡＴＣＦからＡＴＧＷに経路切替の指示が出され、ＡＴＧＷの通話データ送受信先がＵＥ１００からＭＳＣ／ＭＧＷに切り替わる（図３に示すシグナリング１１０２。図４に示すＳＴ１１０２）。すなわち、Ｐａｔｈ　Ｃが確立される。また、ＡＴＧＷへの経路切替処理が完了すると、ＡＴＣＦは、ＳＣＣ－ＡＳに通知シグナリングを送信する（図３に示すシグナリング１１０２。図４に示すＳＴ１１０２）。
　ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷとシグナリングをやり取りする（図３に示すシグナリング１１０４。図４に示すＳＴ１１０４）。これにより、Ｐａｔｈ　Ｄが確立される。
　Ｐａｔｈ　Ｄ確立後、ＭＳＣ／ＭＧＷは、ＭＭＥ経由でＰ－ＧＷ／Ｓ－ＧＷとシグナリングをやり取りする（図３に示すシグナリング１１０６。図４に示すＳＴ１１０６）。これにより、Ｐａｔｈ　Ｂは削除される。
　以上、ｅＳＲＶＣＣハンドーバの動作について説明した。
　ＣＳ網で利用される音声コーデックとして、狭帯域（ＮＢ：Narrowband）コーデックであるＡＭＲ（Adaptive Multi-Rate）コーデック及び広帯域（ＷＢ：Wideband）コーデックであるＡＭＲ－ＷＢコーデック等が広く用いられている。ＡＭＲ及びＡＭＲ－ＷＢは、パケット交換方式で利用可能であるため、ＰＳ網（ＶｏＬＴＥ）での利用も考えられている。
　ＡＭＲ及びＡＭＲ－ＷＢは、サポートしているビットレートがそれぞれ異なる。更に、ＡＭＲ及びＡＭＲ－ＷＢがＰＳ網で用いられる場合には、非特許文献２に記載の通り、ＲＴＰ（Real-Time Protocol）ペイロードフォーマットで用いられる、ビットレートに対する番号付け（Frame Type Index）が双方でオーバラップしている。このため、ＣＳ網での利用においてもＰＳ網での利用においても、セッション開始時にＡＭＲ若しくはＡＭＲ－ＷＢのどちらを用いるかを決める必要がある。つまり、セッションの再折衝無しでＡＭＲとＡＭＲ－ＷＢとを切り替えることは不可能である。
　尚、従来技術において、狭帯域コーデックとは、一般的に３００Ｈｚ～３．４ｋＨｚの帯域幅で、８ｋＨｚでサンプリングされるコーデックである。また、広帯域コーデックとは、一般的に５０Ｈｚ～７ｋＨｚの帯域幅で、１６ｋＨｚでサンプリングされるコーデックである。また、超広帯域（ＳＷＢ：Super Wideband）コーデックとは、一般的に５０Ｈｚ～１４ｋＨｚの帯域幅で、３２ｋＨｚでサンプリングされるコーデックである。
3GPP TS23.216 v9.6.0 "Single Radio Voice Call Continuity (SRVCC)" IETF RFC 4867、 "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs" 3GPP TS23.237 v11.0.0 "IP Multimedia Subsystem (IMS) Service Continuity" Takashi Koshimizu and Katsutoshi Noshida, "Audio Viedo Callof Single Radio Voice Call Continuity", 2011年電子情報通信学会総合大会，B-6-77 西田克利，輿水敬，「音声呼のＩＭＳ－回線交換間ハンドオーバ方式の改善提案移動機能力に基づく在圏アンカー型ＳＲＶＣＣ方式」，信学技報 NS2010-178，pp85-90
　図１または図３において、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバした際、ＰＳ網で使用していたコーデックがＣＳ網でサポートされていない場合には、ＵＥ１００で使用されるコーデックは、ＣＳ網でサポートされているコーデックに変更される。ＵＥ１００のコーデックに変更が生じた場合、ＵＥ１００とＵＥ１０２との通話継続を可能にするためには、次の２つの方法が考えられる。１つ目の方法は、ＵＥ１０２で使用されるコーデックをＵＥ１００の変更後のコーデックと同じものに変更する方法である。２つ目の方法は、ＭＳＣ／ＭＧＷにおいてトランスコーディングを行う方法である。
　前者の方法では、ＵＥ１０２のコーデックを変更するためのシグナリングに時間がかかり、通話が途切れる時間が長くなるので好ましくない。更に、ｅＳＲＶＣＣハンドオーバでは、ＵＥ１００のハンドオーバの際の経路切替のためのシグナリングがＡＴＣＦで終端するため、ＵＥ１０２のコーデックを変更するためのシグナリングを送ることすらできない。すなわち、ｅＳＲＶＣＣハンドオーバでは、既存のシグナリングを使ってＵＥ１０２のコーデックを変更することができない。
　よって、後者のトランスコーディングの方法が比較的好ましいと考えられる。しかしながら、トランスコーディングを行った場合、特にコーデックの帯域幅（コーデックの入出力となる信号の帯域幅）が異なる場合には、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする際、通話品質の劣化が生じてしまう。
　本発明の目的は、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができるネットワークノード、端末、帯域幅変更判断方法及び帯域幅変更方法を提供することである。
　本発明の一態様に係るネットワークノードは、異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行うネットワークノードであって、前記２つの端末がそれぞれ使用するコーデックを検出する検出手段と、前記検出手段での検出結果に基づいて、前記２つの端末のうちいずれか一方の端末が使用するコーデックの変更を検出した場合、前記一方の端末以外の他方の端末の第１のコーデック、及び、前記一方の端末の変更後の第２のコーデックを用いて、前記第１のコーデックの第１の帯域幅の制限を行うか否かを判断する判断手段と、前記判断手段において前記第１の帯域幅を制限すると判断された場合、前記第１の帯域幅を制限させるためのシグナリングを、前記他方の端末へ送信する送信手段と、を具備する構成を採る。
　本発明の一態様に係る端末は、異なるコーデックを使用する端末間の通信に対して、端末間に位置するネットワークノードでトランスコーディングが行われる通信システムで用いられる端末であって、前記端末と、前記端末の通信相手である相手端末との間の通信に使用する第１のコーデックを折衝する折衝手段と、折衝された前記第１のコーデックに対して、前記端末においてエンコードされる入力信号の第１の帯域幅を決定する決定手段と、前記ネットワークノードから通知される、前記第１の帯域幅を制限させるためのシグナリングに従って、前記決定手段で決定された前記第１の帯域幅の変更を制御する変更手段と、を具備する構成を採る。
　本発明の一態様に係る帯域幅変更判断方法は、異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行うネットワークノードにおける帯域幅変更判断方法であって、前記２つの端末がそれぞれ使用するコーデックを検出し、検出結果に基づいて、前記２つの端末のうちいずれか一方の端末が使用するコーデックの変更を検出した場合、前記一方の端末以外の他方の端末の第１のコーデック、及び、前記一方の端末の変更後の第２のコーデックを用いて、前記第１のコーデックの第１の帯域幅の制限を行うか否かを判断し、前記第１の帯域幅を制限すると判断された場合、前記第１の帯域幅を制限させるためのシグナリングを、前記他方の端末へ送信する。
　本発明の一態様に係る帯域幅変更方法は、異なるコーデックを使用する端末間の通信に対して、端末間に位置するネットワークノードでトランスコーディングが行われる通信システムで用いられる端末における帯域幅変更方法であって、前記端末と、前記端末の通信相手である相手端末との間の通信に使用する第１のコーデックを折衝し、折衝された前記第１のコーデックに対して、前記端末においてエンコードされる入力信号の第１の帯域幅を選択し、前記ネットワークノードから通知される、前記第１の帯域幅を制限させるためのシグナリングに従って、前記第１の帯域幅の変更を制御し、前記第１の帯域幅の変更の制御に従って、前記第１の帯域幅を決定する。
　本発明によれば、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる。
３ＧＰＰの移動通信ネットワークの一部を示す構成図 ＳＲＶＣＣハンドオーバの動作を示すシーケンスチャート ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワークの一部を示す構成図 ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャート 本発明の実施の形態１に係る移動通信ネットワークの一部を示す構成図 本発明の実施の形態１に係るネットワークノード（ＭＳＣ／ＭＧＷ）の構成を示すブロック図 本発明の実施の形態１に係るＭＳＣ／ＭＧＷの変更判断部における判断方法の一例を示すフローチャート 本発明の実施の形態１に係る端末（ＵＥ）の構成を示すブロック図 本発明の実施の形態１に係るコーデック折衝に用いるＳＤＰの一例を示す図 本発明の実施の形態１に係る動作を示すシーケンスチャート 本発明の実施の形態１に係る帯域制限依頼メッセージの一例を示す図 本発明の実施の形態２に係る端末（ＵＥ）の構成を示すブロック図 本発明の実施の形態３に係る移動通信ネットワークの一部を示す構成図 本発明の実施の形態３に係るネットワークノード（ＭＳＣ／ＭＧＷ）の構成を示すブロック図 本発明の実施の形態３に係る動作を示すシーケンスチャート 本発明の実施の形態３に係るＭＳＣ／ＭＧＷのコーデック選択部におけるコーデックの選択方法の一例を示すフローチャート 本発明の実施の形態３のバリエーションに係る動作を示すシーケンスチャート 本発明の実施の形態４に係る移動通信ネットワークの一部を示す構成図 本発明の実施の形態４に係るネットワークノード（ＡＴＣＦ／ＡＴＧＷ、ＭＳＣ／ＭＧＷ）の構成を示すブロック図 本発明の実施の形態４に係る端末（ＵＥ）の構成を示すブロック図 本発明の実施の形態４に係る動作を示すシーケンスチャート
　以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
　以下の説明では、「帯域幅」とはコーデックの入出力となる信号の帯域幅のことを指す。
　また、以下の説明では、「帯域幅の指定が必ずしも必要の無いコーデック」とは、エンコードされる入力信号の帯域幅を、セッションの再折衝無しで切り替えることが可能なコーデックを意味する。例えば、ＥＶＳ（Enhanced Voice Services）コーデックの非互換(non interoperable)モードは、ＰＳ網のみで利用される上、サポートされるビットレートは、どの帯域幅においても共通である（「3GPP TSG SA WG4 S4-110539 “EVS Permanent Document #4 (EVS-4): EVS design constraints”」参照）。このため、ＥＶＳコーデックの非互換モードでは、ナイキスト周波数（Nyquist frequency：サンプリング周波数の１／２）以下の帯域幅であれば、セッション途中でも、エンコードされる入力信号の帯域幅を自由に変更できるよう設計することが可能である。よって、セッションの開始から終了までにおける帯域幅の指定が必ずしも必要ではない。この場合、エンコーダは、例えば入力信号の特性（例えば入力信号の周波数特性及び入力信号を分析して得られるパラメータ等）、又は、エンコーディングビットレートに応じて、エンコードされる入力信号の帯域幅を設定又は変更する。
　（実施の形態１）
　図５は、本発明の実施の形態１に係る移動通信ネットワークの一部を示す構成である。なお、図５において、図１と同一構成である部分には同一の符号を付してその説明を省略する。図５では、図１と比較して、ＵＥ１００、１０２及びＭＳＣ／ＭＧＷ３００の動作が異なる。
　まず、図５に示すＭＳＣ／ＭＧＷ３００について説明する。ＭＳＣ／ＭＧＷ３００は、異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行う。
　図６は、本実施の形態に係るＭＳＣ／ＭＧＷ３００（ネットワークノード）の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図６では、本発明と密接に関連する帯域制限（帯域変更）処理に関わる主な構成部（例えば、図５に示すＳＴ４０２～４０６（後述する）に関わる構成部）を示す。
　図６に示すＭＳＣ／ＭＧＷ３００において、受信部６００は、通話データ（以下、通信データとする）、シグナリング等を受信する。例えば、受信部６００は、ＵＥ１００及びＵＥ１０２からそれぞれ送信されるシグナリング（例えば、図１に示すシグナリング２０２，２０４）を受信すると、受信したシグナリングを、コーデック検出部６０４及びコーデック帯域幅検出部６０６に出力する。
　送信部６０２は、通信データ、シグナリング等を送信する。例えば、送信部６０２は、シグナリング生成部６１０から出力されるシグナリングをＵＥ１０２へ通知する。
　コーデック検出部６０４は、受信部６００から入力されるＵＥ１００及びＵＥ１０２からのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックを検出する。そして、コーデック検出部６０４は、検出したコーデックを示す情報（検出結果）を変更判断部６０８に出力する。
　コーデック帯域幅検出部６０６は、受信部６００から入力されるＵＥ１００及びＵＥ１０２からのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックの帯域幅を検出する。そして、コーデック帯域幅検出部６０６は、検出したコーデックの帯域幅を示す情報（検出結果）を、変更判断部６０８に出力する。
　変更判断部６０８は、コーデック検出部６０４から入力される情報に示されるコーデック、及び、コーデック帯域幅検出部６０６から入力される情報に示されるコーデックの帯域幅に基づいて、ＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であるか、及び、帯域幅制限が必要であるかを判断する。例えば、変更判断部６０８は、コーデック検出部６０４での検出結果に基づいて、２つの端末（ＵＥ１００及びＵＥ１０２）のうち一方のＵＥ１００が使用するコーデックの変更を検出した場合、他方のＵＥ１０２のコーデック、及び、ＵＥ１００の変更後のコーデックを用いて、ＵＥ１０２のコーデックの帯域幅の制限を行うか否かを判断する。変更判断部６０８は、判断結果をシグナリング生成部６１０に出力する。なお、変更判断部６０８における帯域幅の変更判断処理の詳細については後述する。
　シグナリング生成部６１０は、変更判断部６０８でＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であり、かつ、帯域幅制限が必要であると判断された場合、ＵＥ１０２でエンコードされる入力信号の帯域幅の制限を、ＵＥ１０２に対して依頼するシグナリングを生成する。帯域幅制限を依頼するシグナリングには、例えば、ＵＥ１００の変更後の帯域幅を示す情報を含めてもよい。シグナリング生成部６１０は、生成したシグナリングを、送信部６０２を介して、ＵＥ１０２へ送信する。このようにして、変更判断部６０８においてＵＥ１０２のコーデックの帯域幅を制限すると判断された場合、帯域幅を制限させるためのシグナリングが、送信部６０２を介して、ＵＥ１０２へ送信される。
　トランスコーディング部６１２は、ＵＥ１００及びＵＥ１０２がそれぞれ異なるコーデックを使用する場合、ＵＥ１００からＵＥ１０２への通信データ、及び、ＵＥ１０２からＵＥ１００への通信データに対してトランスコーディングを行う。
　次いで、図７を用いて、ＭＳＣ／ＭＧＷ３００の変更判断部６０８における帯域幅の変更判断処理の詳細について説明する。
　図７に示すＳＴ８００において、変更判断部６０８は、コーデック検出部６０４での検出結果（検出されるコーデック）に基づいて、ＵＥ１００のコーデックが変更されたか否かを判断する。
　ＵＥ１００のコーデックが変更された場合（ＳＴ８００：Ｙｅｓ）、ＳＴ８０２において、変更判断部６０８は、コーデック検出部６０４での検出結果に基づいて、ＵＥ１０２で使用されているコーデックが、コーデックＡのように、帯域幅の指定不要なコーデックであるか否かを判断する。
　ＵＥ１０２で使われているコーデックが帯域幅の指定不要なコーデックである場合（ＳＴ８０２：Ｙｅｓ）、ＳＴ８０４において、変更判断部６０８は、コーデック帯域幅検出部６０６での検出結果に基づいて、ＵＥ１００の変更後のコーデックの帯域幅が、ＵＥ１０２が現在使用しているコーデックの最大帯域幅よりも狭いか否かを判断する。
　ＵＥ１００の変更後のコーデックの帯域幅が、ＵＥ１０２が現在使用しているコーデックの最大帯域幅よりも狭い場合（ＳＴ８０４：Ｙｅｓ）、ＳＴ８０６において、変更判断部６０８は、ＵＥ１０２へのエンコードされる入力信号の帯域幅の制限が可能かつ必要であると判断する。例えば、変更判断部６０８は、ＵＥ１０２のコーデックの帯域幅を、ＵＥ１００の変更後のコーデックの帯域幅に制限（変更）すると判断する。
　一方、ＵＥ１００のコーデックが変更されていない場合（ＳＴ８００：Ｎｏ）、ＵＥ１０２で使われているコーデックが、帯域幅の指定不要なコーデックではない場合（ＳＴ８０２：Ｎｏ）、又は、ＵＥ１００の変更後のコーデックの帯域幅が、ＵＥ１０２が現在使用しているコーデックの最大帯域幅以上の場合（ＳＴ８０４：Ｎｏ）、ＳＴ８０８において、変更判断部６０８は、ＵＥ１０２への帯域制限は行わないと判断する。
　このようにして、具体的には、ＭＳＣ／ＭＧＷ３００は、一方のＵＥのコーデックの変更が検出された場合、他方のＵＥのコーデックが帯域幅の指定不要なコーデックであるか否かを判断することで、他方のＵＥのコーデックの帯域幅を制限（変更）することが可能か否かを判断する。また、ＭＳＣ／ＭＧＷ３００は、一方のＵＥの変更後のコーデックの帯域幅が、他方のＵＥのコーデックの最大帯域幅よりも狭いか否かを判断することで、他方のＵＥのコーデックの帯域幅の制限（変更）が必要であるか否かを判断する。
　次に、図５に示すＵＥ１００，１０２について説明する。
　図８は、本実施の形態に係るＵＥ１００，１０２（端末）の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図８では、本発明と密接に関連する帯域制限処理に関わる主な構成部（例えば、図５に示すＳＴ４００～４０６（後述する）に関わる構成部）を示す。
　図８に示すＵＥ１００，１０２において、受信部７００は、通信データ及びシグナリング等を受信する。例えば、受信部７００は、ＭＳＣ／ＭＧＷ３００から送信されるシグナリング（例えば、図１に示すシグナリング２０２又は２０４）を受信すると、受信したシグナリングを、コーデック折衝部７０４及びシグナリング解析部７１０に出力する。
　送信部７０２は、通信データ及びシグナリング（例えば、図１に示すシグナリング２０２又は２０４）等を送信する。
　コーデック折衝部７０４は、端末（ここではＵＥ１００とＵＥ１０２）間の通信に使用するコーデックを折衝する。具体的には、コーデック折衝部７０４は、ＳＤＰ（Session Description Protocol）オファー又はＳＤＰアンサーを作成し、コーデック折衝を行う。また、ＵＥ（図５ではＵＥ１００）がＣＳ網に移動した場合には、当該ＵＥのコーデック折衝部７０４は、ＣＳ網での折衝方法に基づき、コーデック折衝を行う。コーデック折衝部７０４は、コーディング折衝の結果をコーデック選択部７０６に出力する。
　図９は、本発明の実施の形態におけるコーデック折衝に用いるＳＤＰの一例を示す。発呼側ＵＥは、帯域幅の指定が必ずしも必要の無いコーデック（以下、コーデックＡという）をサポートしている場合、コーデックＡに対し、サンプリング周波数のみ指定し、帯域幅の指定はせずにＳＤＰオファーを生成する。例えば、図９では、発呼側ＵＥが生成するＳＤＰオファー（SDP offer）には、従来のＷＢコーデックであるＡＭＲ－ＷＢコーデック（例えば、帯域幅：５０Ｈｚ～７ｋＨｚ、サンプリング周波数：16000）、従来のＮＢコーデックであるＡＭＲコーデック（例えば、帯域幅：３００Ｈｚ～３．４ｋＨｚ、サンプリング周波数：8000）、及び、帯域幅の指定不要なコーデックＡ（サンプリング周波数:32000）が記載されている。
　また、着呼側ＵＥは、自らがコーデックＡをサポートしている場合、帯域幅の指定が無く、コーデックＡのサンプリング周波数のみ指定された条件を受け入れ（図９に示すコーデックＡを選択し）、ＳＤＰアンサー（SDP answer）を生成する。なお、コーデックＡは前述のＥＶＳコーデックの非互換モードであってもよい。ここで、コーデックＡのサンプリング周波数32000がサポートしている最大の帯域幅は、ＳＷＢ（Super Wideband）相当であり、エンコーダはこの帯域幅内においては、セッション途中でも、入力信号の特性又はエンコーディングビットレートに応じて、帯域幅を自由に変更することが可能であるとする。
　コーデック選択部７０６は、コーデック折衝部７０４により折衝されたコーデックを選択し、選択したコーデックを示す情報を帯域幅決定部７０８に出力する。
　帯域幅決定部７０８は、コーデック選択部７０６で選択されたコーデックに対して、自端末においてエンコードされる入力信号の帯域幅を決定する。例えば、帯域幅決定部７０８は、コーデック選択部７０６により選択されたコーデックの帯域幅が一定である場合、当該帯域幅を選択する。一方、帯域幅決定部７０８は、コーデック選択部７０６により選択されたコーデックの帯域幅がコーデックＡのように帯域幅を１セッションの中で変更できる場合には、エンコードされる入力信号の帯域幅をフレーム毎に決定する。帯域幅決定部７０８は、例えば、エンコーディングビットレート、入力信号特性、又は、外部シグナリングによる帯域幅制限の依頼等に応じて、エンコードされる入力信号の帯域幅をフレーム毎に決定する。より詳細には、帯域幅決定部７０８は、例えば、コーデックモード変更部７１２からコーデックの帯域幅の制限（変更）を依頼されていることが通知されると、エンコードされる入力信号の帯域幅を、依頼されている帯域幅に制限（変更）する。
　シグナリング解析部７１０は、受信部７００から入力されるシグナリングを解析する。シグナリングには、例えば、ＭＳＣ／ＭＧＷ３００からの帯域幅の制限を依頼するシグナリング（帯域幅を制限させるためのシグナリング）が含まれる。シグナリング解析部７１０は、シグナリング解析の結果を、コーデックモード変更部７１２に通知する。
　コーデックモード変更部７１２は、シグナリング解析部７１０から入力されるシグナリング解析結果が、コーデックの帯域幅の制限（変更）を依頼するシグナリングの場合、エンコードされる入力信号の帯域幅を制限（変更）することを決定し、その旨を帯域幅決定部７０８に通知する。すなわち、コーデックモード変更部７１２は、ＭＳＣ／ＭＧＷ３００から通知される、コーデックの帯域幅を制限させるためのシグナリングに従って、帯域幅決定部７０８で決定された帯域幅の変更を制御する。
　なお、シグナリング解析部７１０は、他の外部シグナリングを解析し、その解析結果をコーデックモード変更部７１２に通知してもよい。例えばシグナリング解析部７１０は、上述したＲＴＣＰ－ＡＰＰを解析し、その解析結果（例えばエンコーディングビットレートの変更依頼）を、コーデックモード変更部７１２に通知してもよい。この場合、コーデックモード変更部７１２は、エンコーディングビットレートを決定すると、決定したエンコーディングビットレートを、帯域幅決定部７０８に通知する。そして、帯域幅決定部７０８は、決定されたエンコーディングビットレートに応じて、帯域幅を決定する。
　次に、本実施の形態におけるＵＥ１００，１０２、及び、ＭＳＣ／ＭＧＷ３００の動作の一例について説明する。
　図１０は、図５に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。なお、図１０において、図２と同一動作である部分には同一の符号を付してその説明を省略する。
　以下の説明では、図５において、現在、ＵＥ１００及びＵＥ１０２の双方ともにｅ－ＵＴＲＡＮ等のＶｏＬＴＥ通話サービスを可能とする無線アクセス網に接続しているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局、ＰＳ網は図示せず）。つまり、図５に示すＵＥ１００とＵＥ１０２との間でＶｏＬＴＥ通話を開始する。
　通話開始の際、ＵＥ１００とＵＥ１０２との間で使用するコーデックの折衝が行われる（例えば、「3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS);Multimedia Telephony; Media Handling and interaction”」参照）。例えば、ＵＥ１００及びＵＥ１０２（コーデック折衝部７０４）は、帯域幅の指定が必ずしも必要の無いコーデックに対して、当該コーデックの折衝を帯域幅指定無しで行う（図５及び図１０に示すＳＴ４００）。
　次いで、図５に示すように、ＵＥ１００がＳＲＶＣＣによるハンドオーバを行い、ＵＴＲＡＮに移動したとする。つまり、ＵＥ１００がＰＳ網からＣＳ網に移動したとする。
　この場合、図１０のＳＴ２０４のプロセスの中で、ＵＥ１００（コーデック折衝部７０４）とＭＳＣ／ＭＧＷ３００との間においてＣＳ網で使用するコーデックが再折衝される。ここでは、例えば、ＵＥ１００に対してＡＭＲコーデックを利用するよう折衝され、ＵＥ１００が使用するコーデックの帯域幅がＮＢに制限されたと仮定する（図５及び図１０に示すＳＴ４０２）。
　また、ＭＳＣ／ＭＧＷ３００（コーデック検出部６０４及びコーデック帯域幅検出部６０６）は、図１０のＳＴ２０２のプロセスにより、ＵＥ１０２が使用しているコーデックがコーデックＡであり、最大帯域幅がＳＷＢであることを検出する。
　また、ＭＳＣ／ＭＧＷ３００（コーデック検出部６０４及びコーデック帯域幅検出部６０６）は、図１０のＳＴ２０４のプロセスにより、ＵＥ１００で使用されるコーデックがＡＭＲになり、帯域幅がＮＢに制限されたことを検出する。
　ＭＳＣ／ＭＧＷ３００（変更判断部６０８）は、ＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であるか、及び、帯域幅制限が必要であるかを判断する。ここでは、ＵＥ１００のコーデックが変更され（図７に示すＳＴ８００：Ｙｅｓ）、ＵＥ１０２のコーデックがコーデックＡであり（図７に示すＳＴ８０２：Ｙｅｓ）、かつ、ＵＥ１００のＡＭＲコーデックの帯域幅（ＮＢ）がＵＥ１０２のコーデックＡの最大帯域幅（ＳＷＢ）よりも狭い（図７に示すＳＴ８０４：Ｙｅｓ）。そこで、ＭＳＣ／ＭＧＷ３００（変更判断部６０８）は、ＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能かつ必要であると判断する（図７に示すＳＴ８０６）。
　そこで、ＭＳＣ／ＭＧＷ３００（シグナリング生成部６１０）は、ＵＥ１０２に対し、コーデックＡのエンコードされる入力信号の帯域幅を、ＮＢ（ＵＥ１００の変更後のコーデックの帯域幅）に制限するよう依頼するシグナリングを送る（図５及び図１０に示すＳＴ４０４）。このシグナリングは、例えばＳＴ２０２の一連のシグナリング（即ち、ＩＭＳシグナリング）に含まれてもよく、ＲＴＣＰ（Real Time Control Protocol）－ＡＰＰ（Application-defined）（例えば、「3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS);Multimedia Telephony; Media Handling and interaction”」参照）のような別のシグナリングで送られてもよい。図１１Ａは、帯域制限を通知するシグナリングがＩＭＳシグナリングに含まれる場合の一例を示す。また、図１１Ｂは、帯域制限を通知するシグナリングがＲＴＣＰ－ＡＰＰに含まれる場合の一例を示す。
　ＵＥ１０２（シグナリング解析部７１０）は、ＭＳＣ／ＭＧＷ３００からのシグナリングを解析する。そして、ＵＥ１０２（コーデックモード変更部７１２）は、コーデックＡの帯域幅の制限を依頼されていることを特定する。そこで、ＵＥ１０２（帯域幅決定部７０８）は、ＵＥ１０２のエンコードされる入力信号の帯域幅を、依頼された帯域幅（ここではＮＢ）に制限する。そして、ＵＥ１０２は、制限した帯域幅で通信データをエンコードする（図１０に示すＳＴ４０６）。
　このようにして、ＵＥ１００は、変更後のコーデックの帯域幅（ＮＢ）を使用し、ＵＥ１０２は、コーデックＡの帯域制限した帯域幅（ＮＢ）を使用する。これにより、ＵＥ１００及びＵＥ１０２の双方ともコーデック帯域幅として同一のＮＢを使用する。よって、ＭＳＣ／ＭＧＷ３００（トランスコーディング部６１２）では、ＵＥ１０２側からＵＥ１００側へのトランスコーディング（コーデックＡ（超広帯域）からＡＭＲコーデック（狭帯域）へのトランスコーディング）を行う場合でも、通話品質の劣化を抑えることができる。
　このように、本実施の形態では、ＭＳＣ／ＭＧＷ３００（ネットワークノード）は、通信中のＵＥの一部のＵＥ１００にコーデックの変更が生じた場合でも、他のＵＥ１０２に対して、ＵＥ１００の変更後のコーデックの帯域幅に合わせるように、コーデックの帯域幅の制限を要求する。また、ＵＥ１０２は、ＶｏＬＴＥ通話中の通信相手であるＵＥ１００のコーデックが変更（狭帯域幅に変更）された場合でも、ＵＥ１０２のエンコードされる入力信号の帯域幅をＵＥ１００に合わせて制限する。すなわち、ＵＥ１０２は、通信相手であるＵＥ１００のネットワーク状況に応じて、ＵＥ１００との通信を途切れさせることなく、エンコードされる入力信号の帯域幅を変更する。
　これにより、一方のＵＥのネットワーク状況が変わった場合でも、ＵＥ間のコーデックの帯域幅を同等に維持することができる。よって、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする場合に生じる通話品質の劣化を抑えることができる。すなわち、ＭＳＣ／ＭＧＷ３００は、通信品質の劣化を抑えてトランスコーディングを行うことができる。
　更に、ＵＥ１０２では、コーデックを変更せずに、エンコードされる入力信号の帯域幅のみを制限するので、コーデックを変更するためのシグナリングが不要となり、通話が途切れる時間が長くなることを防ぐことができる。
　よって、本実施の形態によれば、ＶｏＬＴＥ通話中のＵＥ１００がＣＳ網にハンドオーバし、ハンドオーバ先ＣＳ網でコーデックが変更された場合でも、通話を途切れさせることなくＵＥ１０２のエンコードされる入力信号の帯域幅を制限することができる。これにより、ＵＥ１０２側からＵＥ１００側へのトランスコーディングによる通話品質の劣化を抑えることができる。つまり、本実施の形態によれば、ＶｏＬＴＥ通話中の端末（ＵＥ）の一方が使用していたコーデックが変更される場合でも、通話を途切れさせることなく、トランスコーディングによる通話品質の劣化を抑えることができる。
　なお、上記実施の形態（例えば、図５参照）において、ＵＥ１００がｒＳＲＶＣＣ（reverse SRVCC。例えば、「3GPP TR23.885 v1.2.0 “Feasibility Study of Single Radio Voice Call Continuity (SRVCC) from UTRAN/GERAN to E-UTRAN/HSPA”」参照）に対応している場合、ＰＳ網からＣＳ網にハンドオーバした後、再びＰＳ網にハンドオーバする可能性もある。この場合、ＭＳＣ／ＭＧＷ３００は、ＵＥ１００のＣＳ網からＰＳ網へのハンドオーバ処理に関するシグナリングを受け取った時点で、ＵＥ１０２に対して、コーデックの帯域幅制限を解除するシグナリングを送信してもよい。又は、ＭＳＣ／ＭＧＷ３００は、ＵＥ１００がＰＳ網へのハンドオーバ完了後に、ＵＥ１０２に対して、コーデックの帯域幅制限を解除するシグナリングを送信してもよい。
　また、上記実施の形態（例えば、図５参照）では、ＵＥ１００が通話開始の際、ＰＳ網に接続している場合について説明した。しかし、ＵＥ１００が通話開始時に、ＣＳ網に接続している場合もあり得る。この場合、例えば、「3GPP TS23.292 v10.3.0 “IP Multimedia Subsystem (IMS) centralized services”」に記載の方法で、ＵＥ１００は、ＰＳ網に接続しているＵＥ１０２との間で通話を開始する。ここで、ＵＥ１００がｒＳＲＶＣＣに対応している場合（即ち、ＵＥ１００がＰＳ網にハンドオーバし得る場合）、ＭＳＣ／ＭＧＷ３００は、ＵＥ１０２との間で、コーデックの折衝を行う際、ＵＥ１０２に対し、ＵＥ１００が使用するコーデックの帯域幅を最大帯域幅としてエンコードするように、予め折衝してもよい。又は、ＭＳＣ／ＭＧＷ３００は、ＵＥ１０２との折衝後に別のシグナリングで、ＵＥ１０２にエンコードされる入力信号の帯域幅の制限を依頼してもよい。
　また、本実施の形態では、ＳＲＶＣＣ方式を用いて説明したが、ｅＳＲＶＣＣ方式においても本実施の形態を適用することができる。
　ＳＲＶＣＣ方式では、通信中のＵＥが使用するコーデックが異なる場合、ＭＧＷ（ＭＳＣ／ＭＧＷ３００）においてトランスコーディングが行われる。一方、非特許文献３によると、ｅＳＲＶＣＣ方式では、ＭＧＷがトランスコーディングを行う代わりに、ＡＴＧＷがトランスコーディングを行ってもよいことになっている。
　ここで、ｅＳＲＶＣＣ方式において、ＭＧＷではなくＡＴＧＷでトランスコーディングを行う場合、ＳＲＶＣＣ方式について、本実施の形態に係るＭＳＣ／ＭＧＷ３００（図５参照）へ追加された機能は、ＡＴＣＦ／ＡＴＧＷ１１２０（図３参照）に追加される。すなわち、ｅＳＲＶＣＣ方式では、ＡＴＣＦ／ＡＴＧＷ１１２０が、図６に示す受信部６００、送信部６０２、コーデック検出部６０４、コーデック帯域幅検出部６０６、変更判断部６０８、シグナリング生成部６１０及びトランスコーディング部６１２を具備する構成を採る。ここで、ｅＳＲＶＣＣ方式においてＡＴＣＦ／ＡＴＧＷ１１２０が有する、送信部６０２、コーデック検出部６０４、変更判断部６０８、シグナリング生成部６１０及びトランスコーディング部６１２に関しては、ＳＲＶＣＣ方式においてＭＳＣ／ＭＧＷ３００が有する各構成部と同一の機能を持つ。
　ｅＳＲＶＣＣ方式におけるＡＴＣＦ／ＡＴＧＷ１１２０の受信部６００（図６）は、通信データ、シグナリング等を受信する。例えば、受信部６００は、ＵＥ１００、ＵＥ１０２、ＡＴＣＦ、及びＭＳＣ／ＭＧＷからそれぞれ送信されるシグナリング（例えば、図３に示すシグナリング１１０２）を受信すると、受信したシグナリングを、コーデック検出部６０４及びコーデック帯域幅検出部６０６に出力する。
　コーデック検出部６０４は、受信部６００から入力されるＵＥ１００、ＵＥ１０２、ＡＴＣＦ、及びＭＳＣ／ＭＧＷからのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックを検出する。そして、コーデック検出部６０４は、検出したコーデックを示す情報（検出結果）を変更判断部６０８に出力する。
　コーデック帯域幅検出部６０６は、受信部６００から入力されるＵＥ１００、ＵＥ１０２、及びＭＳＣ／ＭＧＷからのシグナリング、通信データ等に基づいて、ＵＥ１００及びＵＥ１０２がそれぞれ使用するコーデックの帯域幅を検出する。そして、コーデック帯域幅検出部６０６は、検出したコーデックの帯域幅を示す情報（検出結果）を、変更判断部６０８に出力する。
　なお、ここでは、ＡＴＣＦ／ＡＴＧＷ１１２０を一つのノードとして説明したが、別々のノードでもよい。よって、上述したＡＴＣＦ／ＡＴＧＷ１１２０が有する機能を、ＡＴＣＦ又はＡＴＧＷの何れか一方若しくは両方が有していてもよい。また、ＡＴＣＦとＡＴＧＷとの間で必要な情報をやり取りしてもよい。
　また、上記実施の形態において、各ＵＥは、コーディング折衝の際、図９のようにＳＤＰで帯域幅を固定して指定しない代わりに、ＳＤＰで最大帯域幅を指定してもよい。
　また、上記実施の形態では、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷがＵＥ１０２に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する場合について説明した。しかし、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷは、帯域幅の制限を依頼するシグナリングの代わりに、エンコーディングビットレートの制限を依頼するシグナリングを送信してもよい。ここで、各ＵＥは入力信号のエンコーディングビットレートに基づいて、エンコードされる入力信号の帯域幅を設定する。よって、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷがエンコーディングビットレートの制限を依頼するシグナリングをＵＥに送信することで、当該ＵＥは、制限されたエンコーディングビットレートを設定し、かつ、制限されたエンコーディングビットレートに基づいて、エンコードされる入力信号の帯域幅を制限することが可能となる。または、ＭＳＣ／ＭＧＷ３００、及びＡＴＧＷは、帯域幅及びエンコーディングビットレートの双方の制限を依頼するシグナリングを送信してもよい。
　また、上記実施の形態では、ＭＳＣ／ＭＧＷ３００（図６）を１つのノードとして説明した。しかし、ＭＳＣ／ＭＧＷ３００は、互いにインタフェースによって接続される２つ以上のノードで構成されてもよく、上述したＭＳＣ／ＭＧＷ３００の各機能をこれらの複数のノードに分散させてもよい。
　（実施の形態２）
　実施の形態１では、ＭＳＣ／ＭＧＷ３００又はＡＴＧＷ（ＡＴＣＦ／ＡＴＧＷ１１２０）がＵＥ１０２に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する場合について説明した。これに対して、本実施の形態では、ＭＳＣ／ＭＧＷ３００又はＡＴＧＷ（ＡＴＣＦ／ＡＴＧＷ１１２０）が帯域幅の制限を依頼するシグナリングを送信する代わりに、ＵＥ１０２が通信データを受け取ることにより、ＵＥ１００のコーデックの帯域幅が制限されたことを検知し、ＵＥ１０２のエンコードされる入力信号の帯域幅を制限する場合について説明する。
　図１２を用いて、本実施の形態に係るＵＥについて説明する。
　図１２に示すＵＥ１００，１０２において、受信部７００、送信部７０２、コーデック折衝部７０４、コーデック選択部７０６、及び帯域幅決定部７０８は、図８と同一動作を行う構成部であり、その説明を省略する。
　データ解析部１２００は、受信部７００から入力される通信データを解析する。データ解析部１２００は、或る時刻から一定時間における通信データのコーデックの帯域幅の上限値が、その直前までのコーデック帯域幅の上限値、又は、通話開始時に折衝したコーデックの帯域幅の上限値と比較して異なる場合、通信相手先端末（ＵＥ）の通信データのコーデックの帯域幅が制限（変更）されたと解析する。データ解析部１２００は、解析結果を、コーデックモード変更部１２０２に通知する。
　コーデックモード変更部１２０２は、データ解析部１２００からの解析結果に基づき、エンコードされる入力信号の帯域幅を制限（変更）することを決定し、その旨を帯域幅決定部７０８に通知する。これにより、帯域幅決定部７０８は、コーデックモード変更部１２０２において決定された帯域幅の変更を制御する。
　このように、本実施の形態では、ＵＥ１００、１０２は、受け取った通信データのコーデックの帯域幅の上限値が変更されたか否かに応じて、通信相手端末のコーデックが変更されたか否かを判断する。そして、ＵＥ１００、１０２は、通信相手端末のコーデックが変更されたと判断した場合、自装置のコーデックの帯域幅の変更を制御する。これにより、実施の形態１と同様、一方のＵＥのネットワーク状況が変わった場合でも、ＵＥ間のコーデックの帯域幅を同等に維持することができる。よって、実施の形態１と同様、帯域幅の広いコーデックから帯域幅の狭いコーデックにトランスコーディングする場合に生じる通話品質の劣化を抑えることができる。
　（実施の形態３）
　図１３は、本発明の実施の形態３に係る移動通信ネットワークの一部を示す構成である。なお、図１３に示す各ノードの動作は前述（例えば図５）した通りである。
　図１３において、ＵＥ１００は、最初ＳＲＶＣＣにてＣＳ網にハンドオーバ（以下、ＳＲＶＣＣハンドオーバと呼ぶこともある）を行い、ＰＳ網に存在するＵＥ１０２と、ＭＳＣ／ＭＧＷ１３００を経由して、通信データを送受信している（図１３に示すＰａｔｈ　Ａ及びＰａｔｈ　Ｂ）。この際、ＵＥ１００はＣＳ網で利用するコーデックとしてＡＭＲ－ＷＢを用い、ＵＥ１０２はＰＳ網で利用するコーデックとして、例えば上述したコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）を用い、ＭＳＣ／ＭＧＷ１３００でトランスコーディングが行われていたとする。
　次に、ＵＥ１０２もＳＲＶＣＣによりＣＳ網にハンドオーバを行ったとする。
　この際、非特許文献１のハンドオーバ手順に従えば、ＵＥ１０２の移動先ＣＳ網での通信はＭＳＣ／ＭＧＷ１３０２で終端され、ＭＳＣ／ＭＧＷ１３００の通信相手先は、ＵＥ１０２からＭＳＣ／ＭＧＷ１３０２に変更される。すなわち、ＵＥ１００とＵＥ１０２との間の通信データの経路は、Ｐａｔｈ　Ｄ、Ｐａｔｈ　Ｃ及びＰａｔｈ　Ｂを通る経路に変更される。
　更に、ＵＥ１０２がＣＳ網で使用するコーデックがＡＭＲ－ＷＢに変更になったとする。この場合、ＵＥ１０２からＭＳＣ／ＭＧＷ１３０２までは、ＵＥ１０２からＵＥ１００へ送信される通信データは、Ｐａｔｈ　Ｄを通り、かつ、ＡＭＲ－ＷＢを用いて送信される。次いで、ＭＳＣ／ＭＧＷ１３０２は、ＵＥ１０２がＣＳ網で使用するＡＭＲ－ＷＢからＰＳ網で使用していたコーデックＡにトランスコーディングを行う。よって、ＭＳＣ／ＭＧＷ１３０２からＭＳＣ／ＭＧＷ１３００までは、ＵＥ１０２からＵＥ１００へ送信される通信データは、Ｐａｔｈ　Ｃを通り、かつ、コーデックＡを用いて送信される。次いで、ＭＳＣ／ＭＧＷ１３００は、コーデックＡからＡＭＲ－ＷＢにトランスコーディングを行う。よって、ＭＳＣ／ＭＧＷ１３００からＵＥ１００までは、ＵＥ１０２からＵＥ１００へ送信される通信データは、Ｐａｔｈ　Ｂを通り、かつ、ＡＭＲ－ＷＢを用いて送信される。ＵＥ１００からＵＥ１０２へ送信される通信データについても同様である。
　本実施の形態では、通信中のＵＥ１００及びＵＥ１０２の双方がＳＲＶＣＣハンドオーバを行った場合でも、ＭＳＣ／ＭＧＷ１３００，１３０２におけるトランスコーディングを最小限に抑える方法について説明する。
　まず、図１３に示すＭＳＣ／ＭＧＷ１３００、１３０２について説明する。
　図１４は、本実施の形態に係るＭＳＣ／ＭＧＷ１３００、１３０２構成を示すブロック図である。なお、図１４に示すＭＳＣ／ＭＧＷ１３００、１３０２は、図示される機能ブロックの他に、図８に示される機能ブロック又はその他の機能ブロックを具備していてもよい。
　図１４に示すＭＳＣ／ＭＧＷ１３００、１３０２において、受信部１５００は、通信データ、シグナリング等を受信する。
　送信部１５０２は、通信データ、シグナリング等を送信する。
　シグナリング解析部１５０４は、ＳＲＶＣＣ処理のためのシグナリング、又は、ＩＭＳのシグナリング（ＩＭＳシグナリング）等を解析する。シグナリング解析部１５０４は、シグナリング解析の結果を、シグナリング生成部１５０６、端末位置判断部１５０８及びコーデック選択部１５１０に通知する。
　シグナリング生成部１５０６は、シグナリング解析部１５０４のシグナリング解析結果等に基づいて、シグナリングを生成する。
　端末位置判断部１５０８は、シグナリング解析部１５０４のシグナリング解析結果に基づいて、通信中の双方の端末（ＵＥ１００、１０２）がＰＳ網に存在するのか、ＣＳ網に存在するのかを判断する。端末位置判断部１５０８は、判断結果をコーデック選択部１５１０及び経路選択部１５１２に出力する。
　コーデック選択部１５１０は、シグナリング解析部１５０４のシグナリング解析結果及び端末位置判断部１５０８の判断結果に基づいて、利用するコーデック、又はコーデック候補を選択する。
　経路選択部１５１２は、端末位置判断部１５０８の判断結果に基づいて、通信データが通る経路を選択する。
　次に、本実施の形態におけるＭＳＣ／ＭＧＷ１３００，１３０２の動作の一例について説明する。
　図１５は、図１３に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。なお、図１３において、ＳＣＣ　ＡＳ及びＣＳＣＦは図示していないが、ＩＭＳの一部として存在しているものとする。
　現在、ＵＥ１００とＵＥ１０２は、双方ともｅ－ＵＴＲＡＮに接続し、ＶｏＬＴＥ通信を行っているとする。つまり、現在、ＵＥ１００及びＵＥ１０２では、音声コーデックとして、前述のコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）が使用されているものとする（図１５に示すＳＴ１４００）。
　次いで、ＵＥ１００はＣＳ網にハンドオーバ（ＳＲＶＣＣハンドオーバ）する（図１０に示すＳＴ２００の処理（ＳＲＶＣＣ処理）と同等の処理）。また、ＵＥ１００はＣＳ網にハンドオーバし、ＣＳ網との間にコネクションを確立する（図１０に示すＳＴ２０４の処理（コネクション確立処理）と同等の処理）。
　ＳＴ２００の処理及びＳＴ２０４の処理と同時に、ＭＳＣ／ＭＧＷ１３００のシグナリング生成部１５０６は、ＵＥ１０２に送信するＩＭＳシグナリングを生成して、送信部１５０２を介して送信する（図１５に示すＳＴ１４０２）。このとき、シグナリング生成部１５０６は、当該ＩＭＳシグナリングの中に、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報を含める。例えば、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報は、非特許文献３に記載のＳＴＮ－ＳＲ（Session Transfer Number for SRVCC）等であってもよい。
　また、ＭＳＣ／ＭＧＷ１３００のシグナリング生成部１５０６は、ＵＥ１００がＰＳ網で使用していたコーデック（コーデックＡ）の他に、自網側のＣＳ網（ＭＳＣ／ＭＧＷ１３００が属するＣＳ網）でサポートしているコーデックのリストをＩＭＳシグナリングの中に含める（図１５に示すＳＴ１４０２）。この際、シグナリング解析部１５０４が、ＳＴ２０４のコネクション確立処理を待って、コネクション確立に関するシグナリングを解析し、ＵＥ１００がＣＳ網で使うコーデック情報を得て、その後、シグナリング生成部１５０６が、このコーデック情報をＩＭＳシグナリングの中に明示的に含めてもよい。
　これにより、ＵＥ１００～ＭＳＣ／ＭＧＷ１３００ではＣＳ網を使った通信が行われ、ＭＳＣ／ＭＧＷ１３００～ＵＥ１０２ではＰＳ網を使った通信が行われる（図１５に示すＳＴ１４０４）。
　次いで、ＵＥ１０２はＣＳ網にハンドオーバ（ＳＲＶＣＣハンドオーバ）する（図１０に示すＳＴ２００（ＳＲＶＣＣ処理）と同等の処理）。また、ＵＥ１０２はＣＳ網にハンドオーバし、ＣＳ網との間にコネクションを確立する（図１０に示すＳＴ２０４の処理（コネクション確立処理）と同等の処理）。
　ＳＴ２００の処理及びＳＴ２０４の処理と同時に、ＭＳＣ／ＭＧＷ１３０２のシグナリング生成部１５０６は、ＭＳＣ／ＭＧＷ１３００に送信するＩＭＳシグナリングを生成して、送信部１５０２を介して送信する（図１５に示すＳＴ１４０６）。このとき、シグナリング生成部１５０６は、当該ＩＭＳシグナリングの中に、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報を含める。例えば、ＳＲＶＣＣハンドオーバにより発生したＩＭＳシグナリングであることを示す情報は、非特許文献３に記載のＳＴＮ－ＳＲ（Session Transfer Number for SRVCC）等であってもよい。
　また、ＭＳＣ／ＭＧＷ１３０２のシグナリング生成部１５０６は、ＵＥ１０２がＰＳ網で使用していたコーデック（コーデックＡ）の他に、自網側のＣＳ網（ＭＳＣ／ＭＧＷ１３０２が属するＣＳ網）でサポートしているコーデックのリストをＩＭＳシグナリングの中に含める（図１５に示すＳＴ１４０６）。この際、シグナリング解析部１５０４が、ＳＴ２０４のコネクション確立処理を待って、コネクション確立に関するシグナリングを解析し、ＵＥ１０２がＣＳ網で使うコーデック情報を得て、その後、シグナリング生成部１５０６が、このコーデック情報をＩＭＳシグナリングの中に明示的に含めてもよい。
　ＭＳＣ／ＭＧＷ１３００の受信部１５００は、ＭＳＣ／ＭＧＷ１３０２からのＩＭＳシグナリングを受け取り、シグナリング解析部１５０４に出力する。シグナリング解析部１５０４は、このＩＭＳシグナリングを解析することにより、ＵＥ１０２がＳＲＶＣＣハンドオーバを行ったことを特定し、ＵＥ１０２がＳＲＶＣＣハンドオーバを行ったことを示す情報を端末位置判断部１５０８に出力する。また、シグナリング解析部１５０４は、このＩＭＳシグナリング（ＳＤＰオファー）に含まれるコーデックのリスト（ＭＳＣ／ＭＧＷ１３０２が属するＣＳ網でサポートしているコーデックのリスト）を、コーデック選択部１５１０に出力する。端末位置判断部１５０８は、ＵＥ１０２がＳＲＶＣＣハンドオーバを行ったことにより、ＵＥ１００及び１０２の双方ともＣＳ網に存在すると判断する。コーデック選択部１５１０は、端末位置判断部１５０８の判断結果、及び、シグナリング解析部１５０４から入力される、ＭＳＣ／ＭＧＷ１３０２が属するＣＳ網でサポートされているコーデック情報（コーデックのリスト）を用いて、利用するコーデックを選択する（図１５に示すＳＴ１４０６）。
　また、経路選択部１５１２は、端末位置判断部１５０８の判断結果に基づいて、通信データが通る経路を選択する（図１５に示すＳＴ１４０６）。これにより、ＵＥ１００とＵＥ１０２との通信は、選択された経路を通って行われる（図１５に示すＳＴ１４０８）。
　次に、図１３及び図１５に示すＭＳＣ／ＭＧＷ１３００のコーデック選択部１５１０におけるコーデックの選択方法の一例を図１６に示す。
　図１６に示すＳＴ１６００において、コーデック選択部１５１０は、端末位置判断部１５０８の判断結果に基づいて、通信中の双方の端末（ＵＥ１００，１０２）がＣＳ網に移動（存在）しているか否かを判断する。
　通信中の双方の端末がＣＳ網に移動している場合（ＳＴ１６００：ＹＥＳ）、ＳＴ１６０２において、コーデック選択部１５１０は、受信部１５００で受け取ったＩＭＳシグナリングに、通信相手端末（ＵＥ１０２）がＣＳ網で使用するコーデック情報（コーデックのリスト）が含まれるか否かを判断する。
　ＩＭＳシグナリングに通信相手端末がＣＳ網で使用するコーデック情報が含まれる場合（ＳＴ１６０２：ＹＥＳ）、ＳＴ１６０４において、コーデック選択部１５１０は、通信相手端末（ＵＥ１０２）がＣＳ網で使用するコーデック情報が、自網側の端末（ＵＥ１００）が使用中のコーデックと一致するか否かを判断する。上記コーデック情報が自網側の端末（ＵＥ１００）が使用中のコーデックと一致する場合、ＳＴ１６１４の処理に進む。
　通信中の双方の端末がＣＳ網に移動していない場合（ＳＴ１６００：ＮＯ）、ＳＴ１６０６において、コーデック選択部１５１０は、自装置（ＭＳＣ／ＭＧＷ１３００）が、ＰＳ網で使用されているコーデックに対応するか否かを判断する。自装置（ＭＳＣ／ＭＧＷ１３００）が、ＰＳ網で使われているコーデックに対応しない場合（ＳＴ１６０６：ＮＯ）、ＳＴ１６１２の処理に進む。
　ＩＭＳシグナリングに通信相手端末がＣＳ網で使用するコーデック情報が含まれない場合（ＳＴ１６０２：ＮＯ）、又は、自装置（ＭＳＣ／ＭＧＷ１３００）が、ＰＳ網で使われているコーデックに対応する場合、ＳＴ１６０８において、コーデック選択部１５１０は、ＩＭＳシグナリング（ＳＤＰオファー）によってオファーされているコーデック情報（コーデックリスト）の中に、現在自網側のＵＥ（ＵＥ１００）が使用中のコーデックが含まれるか否かを判断する。オファーされているコーデックリストの中に、現在自網側のＵＥ（ＵＥ１００）が使用中のコーデックが含まれる場合（ＳＴ１６０８：ＹＥＳ）、ＳＴ１６１４の処理に進む。
　オファーされているコーデックリストの中に、現在自網側のＵＥ（ＵＥ１００）が使用中のコーデックが含まれない場合（ＳＴ１６０８：ＮＯ）、ＳＴ１６１０において、コーデック選択部１５１０は、ＩＭＳシグナリング（ＳＤＰオファー）によってオファーされているコーデックリストの中に、自装置（ＭＳＣ／ＭＧＷ１３００）がサポートしているコーデックが含まれるか否かを判断する。オファーされているコーデックリストの中に、自装置がサポートしているコーデックが含まれる場合（ＳＴ１６１０：ＹＥＳ）、ＳＴ１６１６の処理に進む。オファーされているコーデックリストの中に、自装置がサポートしているコーデックが含まれない場合（ＳＴ１６１０：ＮＯ）、ＳＴ１６１８の処理に進む。
　ＳＴ１６１２では、コーデック選択部１５１０は、ＰＳ網で使用されているコーデックを選択する。
　ＳＴ１６１４では、コーデック選択部１５１０は、自網側の端末（ＵＥ１００）が使用中のコーデックを、使用するコーデックとして選択する。
　ＳＴ１６１６では、コーデック選択部１５１０は、オファーされているコーデックリストのうち、自装置（ＭＳＣ／ＭＧＷ１３００）がサポートしているコーデックの中から、使用するコーデックを選択する。
　ＳＴ１６１８では、コーデック選択部１５１０は、エラーを選択する。
　このようにして、ＭＳＣ／ＭＧＷ１３００，１３０２は、ハンドオーバにより発生したＩＭＳシグナリングの中に、自網側のＣＳ網でサポートしているコーデックのリストを含める。また、上記ＩＭＳシグナリングを受け取ると、ＭＳＣ／ＭＧＷ１３００（ＭＳＣ／ＭＧＷ１３０２）は、まず、通信中の双方の端末がＣＳ網に存在すると判断する。更に、ＭＳＣ／ＭＧＷ１３００（ＭＳＣ／ＭＧＷ１３０２）は、ＩＭＳシグナリングの送信先のＭＳＣ／ＭＧＷが属するＣＳ網でサポートされているコーデック情報を用いて、利用するコーデックを選択する。具体的には、ＭＳＣ／ＭＧＷ１３００，１３０２は、通信中の双方の端末（ＵＥ１００，１０２）が同一のコーデックを使用可能な場合には、双方の端末で当該同一のコーデックが使用されるように、利用するコーデックを選択する。
　すなわち、一方の端末（ＵＥ１００）がＣＳ網にハンドオーバし、他方の端末（ＵＥ１０２）がＣＳ網にハンドオーバした場合において、例えば、ＵＥ１００側のＣＳ網に属するＭＳＣ／ＭＧＷ１３００は、ＵＥ１０２側のＣＳ網に属するＭＳＣ／ＭＧＷ１３０２から、ＵＥ１０２側のＣＳ網でサポートしているコーデックリスト（コーデック群）を含むメッセージを受信し、上記コーデックリスト、及び、ＵＥ１００が使用するコーデック（変更後のコーデック）を用いて、ＵＥ１０２が使用するコーデックを選択する。例えば、ＭＳＣ／ＭＧＷ１３００は、受信したコーデックリストに、ＵＥ１００が使用するコーデック（変更後のコーデック）が含まれる場合、ＵＥ１０２が使用するコーデックとして、ＵＥ１００が使用するコーデックを選択する。
　これにより、双方の端末（ＵＥ１００，１０２）では、可能であれば同一コーデックが使用されるので、ＭＳＣ／ＭＧＷ１３００，１３０２では、トランスコーディングが行われない。よって、本実施の形態によれば、通信中のＵＥ１００及びＵＥ１０２の双方がＳＲＶＣＣハンドオーバを行った場合でも、ＭＳＣ／ＭＧＷ１３００，１３０２における、トランスコーディングを最小限に抑えることができる。
　また、実施の形態１では、ＭＳＣ／ＭＧＷ３００がコーデック帯域幅の変更を検出し、ＵＥ１０２に対して、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングを送信する方法について説明した。これに対して、本実施の形態では、ＭＳＣ／ＭＧＷ１３００，１３０２は、自網側の端末がＣＳ網で使うコーデック情報を得た後、エンコードされる入力信号の帯域幅の制限を依頼するシグナリングに代えて、当該コーデック情報をＩＭＳシグナリングの中に明示的に含めて通信相手側端末に送信する。この場合でも、実施の形態１と同様、一方又は双方のＵＥのネットワーク状況が変わった場合でも、ＵＥ間のコーデックの帯域幅を同等に維持することができる。
　なお、端末位置判断部１５０８により、ＵＥ１００、１０２の双方ともＣＳ網に存在すると判断された場合、経路選択部１５１２は、ネットワーク側の経路を全てＣＳ網用の経路に切り替えてもよい。端末位置判断部１５０８は、この判断方法として、例えば両方の端末がｒＳＲＶＣＣに対応しているか否かで判断してもよい。すなわち、両方の端末（ＵＥ１００，１０２）がｒＳＲＶＣＣに対応していない場合、経路選択部１５１２は、ネットワーク側の経路をＣＳ網用の経路に切り替えてもよい。なお、両方の端末がｒＳＲＶＣＣに対応しているかどうかに関しては、非特許文献３に記載の、ＳＲＶＣＣサポートの登録又はＳＲＶＣＣサポートしているか否かの入手方法と同等の方法で実現できる。
　また、端末（例えば図１７に示すＵＥ１０２）は、エンコードされる入力信号の帯域幅の制限を依頼するシグナリング等の受信により、通信相手側端末（例えば図１７に示すＵＥ１００）がＳＲＶＣＣによるハンドオーバを行ったことを判断した場合、自装置がＳＲＶＣＣによるハンドオーバを行う際のシグナリング（図１５に示すＳＴ２００又はＳＴ２０４）によって、自網側ＭＳＣ／ＭＧＷ（例えば、図１７に示すＭＳＣ／ＭＧＷ１３１０）に対し、通信相手側端末（ＵＥ１００）が既にＳＲＶＣＣによるハンドオーバを行っていることを通知してもよい。これにより、ＭＳＣ／ＭＧＷ１３１０の端末位置判断部１５０８は、双方の端末（ＵＥ１００，１０２）がＣＳ網にハンドオーバしたと判断し、ＩＭＳシグナリング（ＳＤＰオファー）のコーデックリストの中に、ＰＳ網のみでサポートしているコーデックを含めることを回避できる。つまり、ＭＳＣ／ＭＧＷ１３１０は、ＣＳ網でサポートしているコーデックのみをＳＤＰオファーに含めることができる（図１７参照）。この際、ＭＳＣ／ＭＧＷ１３１０は、自装置がＭＧＷであることを明示的に伝えてもよい（例えば図１７参照）。また、上記通知を受け取ったＭＳＣ／ＭＧＷ１３００は、ＣＳ網同士で通信することを決定してもよい（例えば図１７参照）。また、上記通知は、例えば、ＵＥ１０２がＣＳ網にハンドオーバした際にＵＥ１０２から送信される既存のシグナリングに含まれてもよいし、新しいシグナリングでもよい。また、上記通知は、ＵＥ１０２がＣＳ網にハンドオーバする以前に、ＭＭＥ（図示せず）に対して送信されるシグナリングに含まれてもよい（例えば、非特許文献４参照）。
　（実施の形態４）
　本実施の形態では、通信を行う双方のＵＥがｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へのハンドオーバを行う場合、又は、一方のＵＥがｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行い、他方のＵＥがＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行う場合について説明する。本実施の形態では、ｅＳＲＶＣＣ方式において、通信データはＡＴＧＷでアンカーされ、ＡＴＧＷにおいてトランスコーディングが行われると仮定する。
　図１８は、本発明の実施の形態４に係る移動通信ネットワークの一部を示す構成である。なお、図１８に示す各ノードの動作は前述（例えば図３及び図５）した通りである。
　図１８において、ＵＥ１００及びＵＥ１０２の双方は、最初ｅ－ＵＴＲＡＮに存在し、ＰＳ網でＶｏＬＴＥ通信を行っている。この際、上述したコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）が使用されていると仮定する。図１８では、ＵＥ１００側のネットワーク、及び、ＵＥ１０２側のネットワークの双方ともｅＳＲＶＣＣに対応していると仮定する。これより、ＵＥ１００とＵＥ１０２との間の現在の通信経路は、ＡＴＣＦ／ＡＴＧＷ１７００及びＡＴＣＦ／ＡＴＧＷ１７０２を経由した、Ｐａｔｈ　Ａ、Ｐａｔｈ　Ｂ及びＰａｔｈ　Ｃとなる。
　なお、図１８では、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２を一つのノードとして表しているが、別々のノードでもよい。また、図１８において、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＵＥ１００とＵＥ１０２との間の通信経路としてＡＴＣＦ／ＡＴＧＷ１７００及びＰａｔｈ　Ｂは存在しないので、Ｐａｔｈ　Ａは、ＵＥ１００とＡＴＣＦ／ＡＴＧＷ１７０２との間に確立される。同様に、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合には、通信経路としてＡＴＣＦ／ＡＴＧＷ１７０２及びＰａｔｈ　Ｂは存在しないので、Ｐａｔｈ　Ｃは、ＵＥ１０２とＡＴＣＦ／ＡＴＧＷ１７００との間に確立される。
　次に、ＵＥ１００、ＵＥ１０２のそれぞれがｅＳＲＶＣＣによりハンドオーバを行ったとする。この場合、非特許文献３によると、ハンドオーバ後のＵＥ１００とＵＥ１０２との間の通信経路は、ＭＳＣ／ＭＧＷ１７０４、ＡＴＣＦ／ＡＴＧＷ１７００、ＡＴＣＦ／ＡＴＧＷ１７０２及びＭＳＣ／ＭＧＷ１７０６を経由した、Ｐａｔｈ　Ｄ、Ｐａｔｈ　Ｅ、Ｐａｔｈ　Ｂ、Ｐａｔｈ　Ｇ、及びＰａｔｈ　Ｆとなる。
　なお、図１８において、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＵＥ１００とＵＥ１０２との間の通信路としてＡＴＣＦ／ＡＴＧＷ１７００及びＰａｔｈ　Ｂは存在しないので、Ｐａｔｈ　ＥはＭＳＣ／ＭＧＷ１７０４とＡＴＣＦ／ＡＴＧＷ１７０２との間に確立される。同様に、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＵＥ１００とＵＥ１０２との間の通信経路としてＡＴＣＦ／ＡＴＧＷ１７０２及びＰａｔｈ　Ｂは存在しないので、Ｐａｔｈ　Ｇは、ＭＳＣ／ＭＧＷ１７０６とＡＴＣＦ／ＡＴＧＷ１７００との間に確立される。
　ここで、例えばＵＥ１００，１０２がＣＳ網にハンドオーバした際に使用するコーデックを双方ともＡＭＲ－ＷＢであるとする。この場合、ＵＥ１００からＡＴＣＦ／ＡＴＧＷ１７００までの通信データはＡＭＲ－ＷＢでエンコードされる。次いで、ＡＴＧＷ１７００はＡＭＲ－ＷＢからコーデックＡにトランスコーディングを行う。よって、ＡＴＧＷ１７００からＡＴＧＷ１７０２までの間の通信データはコーデックＡでエンコードされる。次いで、ＡＴＧＷ１７０２は再びコーデックＡからＡＭＲ－ＷＢにトランスコーディングを行う。よって、ＡＴＧＷ１７０２からＵＥ１０２までの間の通信データはＡＭＲ－ＷＢでエンコードされる。
　なお、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＡＴＧＥ１７００の代わりにＭＳＣ／ＭＧＷ１７０４でトランスコーディングが行われる。同様に、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合には、ＡＴＧＥ１７０２の代わりにＭＳＣ／ＭＧＷ１７０６でトランスコーディングが行われる。
　本実施の形態では、通信中のＵＥ１００及びＵＥ１０２の双方がｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へのハンドオーバを行う場合、又は、一方のＵＥがｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行い、他方のＵＥがＳＲＶＣＣ方式によってＰＳ網からＣＳ網へハンドオーバを行う場合について、実施の形態３と同様、トランスコーディングを最小限に抑える方法について説明する。
　まず、図１８に示すＡＴＣＦ／ＡＴＧＷ１７００、１７０２、及び、ＵＥ１００、１０２について説明する。
　図１９は、本実施の形態に係るＡＴＣＦ／ＡＴＧＷ１７００、１７０２の構成を示すブロック図である。なお、図１９に示すＡＴＣＦ／ＡＴＧＷ１７００、１７０２は、図示される機能ブロックの他に、図８に示される機能ブロック又はその他機能ブロックを具備していてもよい。
　図１９に示すＡＴＣＦ／ＡＴＧＷ１７００、１７０２において、受信部１９００は、通信データ、シグナリング等を受信する。
　送信部１９０２は、通信データ、シグナリング等を送信する。
　シグナリング解析部１９０４は、ＳＲＶＣＣ処理又はｅＳＲＶＣＣ処理のためのシグナリング、又は、ＩＭＳのシグナリング（ＩＭＳシグナリング）等を解析する。シグナリング解析部１９０４は、シグナリング解析の結果を、シグナリング生成部１９０６、端末位置判断部１９０８及びコーデック選択部１９１０に通知する。
　シグナリング生成部１９０６は、シグナリング解析部１９０４のシグナリング解析結果等に基づいて、シグナリングを生成する。
　端末位置判断部１９０８は、シグナリング解析部１９０４のシグナリング解析結果に基づいて、通信中の双方の端末（ＵＥ１００、１０２）がＰＳ網に存在するのか、ＣＳ網に存在するのかを判断する。端末位置判断部１９０８は、判断結果をコーデック選択部１９１０及び経路選択部１９１２に出力する。
　コーデック選択部１９１０は、シグナリング解析部１９０４のシグナリング解析結果及び端末位置判断部１９０８の判断結果に基づいて、利用するコーデック、又はコーデック候補を選択する。
　経路選択部１９１２は、端末位置判断部１９０８の判断結果に基づいて、通信データが通る経路を選択する。
　図２０は、本実施の形態に係るＵＥ１００、１０２の構成を示すブロック図である。ＵＥ１００、１０２は、図示される機能ブロックの他に、図１２に示される機能ブロック又はその他機能ブロックを具備していてもよい。なお、図２０に示すＵＥ１００，１０２において、受信部７００及び送信部７０２は、図１２と同一動作を行う構成部であり、その説明を省略する。
　図２０に示すＵＥ１００、１０２において、通信相手コーデック変更検出部２０００は、通信相手が使用しているコーデックが変更になったことを検出する。通信相手が使用しているコーデックが変更される理由には、例えば、ＰＳ網からＣＳ網に移動したことが挙げられる。また、通信相手コーデック変更検出部２０００におけるコーデック変更の検出方法は、例えば、実施の形態１で示したような、帯域制限通知等のシグナリングをネットワークから受け取る方法、及び、実施の形態２で示したような、通信相手が使用しているコーデックの帯域が制限されたことを検出する方法等が挙げられる。
　シグナリング生成部２００２は、通信相手コーデック変更検出部２０００で通信相手のコーデックが変更になったことが検出された場合、通信相手のコーデックが変更されたことをネットワークに通知するためのシグナリングを生成する。
　次に、本実施の形態におけるＵＥ１００，１０２、及び、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２の動作の一例について説明する。ここでは、ＵＥ１００側のネットワーク、及び、ＵＥ１０２側のネットワークの双方がｅＳＲＶＣＣに対応していると仮定する。
　図２１は、図１８に示す移動通信ネットワークの各装置の動作を示すシーケンスチャートである。
　ＵＥ１００及びＵＥ１０２は、ｅ－ＵＴＲＡＮに接続処理を行い、ＩＭＳに対してＶｏＬＴＥに関する登録をする際、例えば、ＡＴＣＦ（ＡＴＣＦ／ＡＴＧＷ１７００，１７０２）に関する情報をＳＣＣ　ＡＳ、ＨＳＳ（図示せず）又はＭＭＥ（図示せず）に送信し、送信先で当該情報が保持される（例えば、非特許文献５参照）。更に、発呼の際（本実施の形態では、ＵＥ１００からＵＥ１０２への発呼と仮定する。ＵＥ１０２からＵＥ１００への発呼の場合も同様である。）には、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２において、ＡＴＣＦは、ＡＴＧＷでセッションをアンカーするかどうかを判断する（例えば、非特許文献３又は非特許文献５を参照）。
　その後、ＵＥ１００及びＵＥ１０２は、共にｅ－ＵＴＲＡＮに接続し、ＶｏＬＴＥ通信を行っている。この時、音声コーデックとして、前述のコーデックＡ（帯域幅の指定が必ずしも必要の無いコーデック）が使用されているものとする（図２１に示すＳＴ１８００）。
　次いで、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバする。このとき、図１０に示すＳＴ２００の処理（ＳＲＶＣＣ処理）及びＳＴ２０４の処理（コネクション確立処理）と同等の処理が行われる。また、ＳＴ２００の処理及びＳＴ２０４の処理と同時に、図４に示すＳＴ１１０２の処理と同等の処理が行われる。これにより、ＵＥ１００とＵＥ１０２との間のデータ通信経路がＭＳＣ／ＭＧＷ１７０４経由に切り替わる（図２１に示すＳＴ１８０２）。
　この際、ＡＴＣＦ／ＡＴＧＷ１７００のシグナリング生成部１９０６は、ＵＥ１００がＣＳ網で使用するコーデック（例えばＡＭＲ）を含むメッセージを生成し、当該メッセージを送信部１９０２を介して、ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８に通知する（図２１に示すＳＴ１８０２’）。この通知は非特許文献３に記載のAccess Transfer Updateメッセージと共に通知されてもよい。この後、実施の形態１で示したように、ＡＴＣＦ／ＡＴＧＷ１７００は、ＵＥ１０２に対して帯域制限通知を送信してもよい。
　ＵＥ１０２の通信相手コーデック変更検出部２０００は、ＵＥ１００のコーデックがコーデックＡから変更になったことを検出する（図２１に示すＳＴ１８０４）。
　次に、ＵＥ１０２もＰＳ網からＣＳ網にハンドオーバする。このとき、ＵＥ１０２のシグナリング生成部２００２は、通信相手であるＵＥ１００のコーデックが変更になっていることをネットワークに通知するためのシグナリングを生成する。このシグナリングは、例えば、ＵＥ１０２がＣＳ網にハンドオーバした際に、ＵＥ１０２から送信される既存のシグナリングに含まれてもよく、新しいシグナリングに含まれてもよい（図２１に示すＳＴ１８０６）。また、上記通知は、ＵＥ１０２がＣＳ網にハンドオーバする以前に、ＭＭＥ（図示せず）に対し送信されるシグナリングに含まれ、ＭＭＥからＭＳＣ／ＭＧＷ１７０６に通知されてもよい（例えば、非特許文献４参照）。
　ＵＥ１０２からのシグナリングを受け取ったＭＳＣ／ＭＧＷ１７０６は、ＵＥ１０２の通信相手であるＵＥ１００のコーデックが変更になっていることを検知し、ＵＥ１００のコーデックが変更になっていることを示す情報を、ＡＴＣＦ／ＡＴＧＷ１７０２に送信するＩＮＶＩＴＥメッセージに含める。
　このＩＮＶＩＴＥメッセージを受け取ったＡＴＣＦ／ＡＴＧＷ１７０２のシグナリング解析部１９０４は、ＵＥ１０２の通信相手であるＵＥ１００のコーデックが変更になっていることを検出する。そこで、ＡＴＣＦ／ＡＴＧＷ１７０２のシグナリング生成部１９０６は、ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８に対して、ＵＥ１００のコーデック問い合わせのためのシグナリングを生成し、当該シグナリングを送信部１９０２を介して送信する（図２１に示すＳＴ１８０８）。
　ＡＴＣＦ／ＡＴＧＷ１７０２の受信部１９００は、ＳＴ１８０８で送信したシグナリングに対する返信シグナリングをＳＣＣ　ＡＳ／ＣＳＣＦ１７０８から受け取る。そして、ＡＴＣＦ／ＡＴＧＷ１７０２のシグナリング解析部１９０４は、この返信シグナリングを解析し、解析結果（ＵＥ１００のコーデックに関する情報）に基づいて、ＡＴＣＦ／ＡＴＧＷ１７００との間でコーデック折衝を行い（図２１に示すＳＴ１８１０）、コーデックを選択する（図２１に示すＳＴ１８１２）。なお、コーデック折衝は、ＡＴＣＦ／ＡＴＧＷ１７０２とＳＣＣ　ＡＳ／ＣＳＣＦ１７０８との間、及び、ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８とＡＴＣＦ／ＡＴＧＷ１７００との間で行われてもよい（すなわち、ＳＣＣ　ＡＳでアンカーしてもよい）。なお、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８を介さずに、コーデック折衝を行ってもよい。この場合、図２１に示すＳＴ１８０２の処理及びＳＴ１８０８の処理は不要となる。
　このようにして、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、端末（ＵＥ１００，１０２）がハンドオーバした場合、ハンドオーバした端末がＣＳ網で使用するコーデックを含むメッセージを生成し、当該メッセージをＳＣＣ　ＡＳ／ＣＳＣＦ１７０８に通知する。この場合、ハンドオーバした端末と通信している通信相手端末は、ハンドオーバした端末のコーデックが変更されたことを検出している。また、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、ハンドオーバした端末のコーデックが変更されたことを検出している通信相手端末もハンドオーバした場合、当該通信相手端末からの通知によって、最初にハンドオーバした端末のコーデックが変更になっていることを検出すると、ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８に対して、当該通信相手のコーデック問い合わせを行う。そして、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、問い合わせにより得たコーデック（最初にハンドオーバした端末のコーデック）に関する情報に基づいて、コーデック折衝を行い、コーデックを選択する。例えば、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２は、通信中の双方の端末（ＵＥ１００，１０２）が同一のコーデックを使用可能な場合には、双方の端末で当該同一のコーデックが使用されるように、利用するコーデックを選択する。
　すなわち、一方の端末（ＵＥ１００）がＣＳ網にハンドオーバした後に、他方の端末（ＵＥ１０２）がＣＳ網にハンドオーバした場合において、ＡＴＣＦ／ＡＴＧＷ１７０２は、ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８への問い合わせにより、ＵＥ１００が使用するコーデック（変更後のコーデック）を含むメッセージを受信し、ＵＥ１０２側のＭＳＣ／ＭＧＷ１７０６から、ＵＥ１００がＣＳ網にハンドオーバしたことを示す情報を含むメッセージを受信し、ＵＥ１００がＣＳ網にハンドオーバしたことを示す情報を受信した場合、上記ＵＥ１００が使用するコーデックに基づいて、ＵＥ１０２が使用するコーデックを選択する。
　これにより、双方の端末（ＵＥ１００，１０２）では、実施の形態３と同様、可能であれば同一コーデックが使用されるので、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２では、トランスコーディングが行われない。よって、本実施の形態によれば、通信中のＵＥ１００及びＵＥ１０２の双方がｅＳＲＶＣＣ方式によってＰＳ網からＣＳ網へのンドオーバを行う場合、実施の形態３と同様、トランスコーディングを最小限に抑えることができる。
　なお、端末位置判断部１９０８により、ＵＥ１００、１０２の双方ともＣＳ網に存在すると判断された場合、経路選択部１９１２は、ネットワーク側の経路を全てＣＳ網用の経路に切り替えてもよい。端末位置判断部１９０８は、この判断方法として、例えば両方の端末がｒＳＲＶＣＣに対応しているか否かで判断してもよい。すなわち、両方の端末（ＵＥ１００，１０２）がｒＳＲＶＣＣに対応していない場合、経路選択部１９１２は、ネットワーク側の経路をＣＳ網用の経路に切り替えてもよい。なお、両方の端末がｒＳＲＶＣＣに対応しているかどうかに関しては、非特許文献３に記載の、ＳＲＶＣＣサポートの登録又はＳＲＶＣＣサポートしているか否かの入手方法と同等の方法で実現できる。
　また、端末（例えば図２１に示すＵＥ１０２）は、エンコードされる入力信号の帯域幅の制限を依頼するシグナリング等の受信により、通信相手側端末（例えば図２１に示すＵＥ１００）がＳＲＶＣＣ又はｅＳＲＶＣＣによるハンドオーバを行ったことを判断した場合、自装置がｅＳＲＶＣＣによるハンドオーバを行う際のシグナリング（図２１に示すＳＴ２００／ＳＴ２０４）によって、自網側ＭＳＣ／ＭＧＷ（例えば、図２１に示すＭＳＣ／ＭＧＷ１７０６）に対し、通信相手側端末（ＵＥ１００）が既にＳＲＶＣＣ又はｅＳＲＶＣＣによるハンドオーバを行っていることを通知してもよい。これにより、ＭＳＣ／ＭＧＷ１７０６の端末位置判断部１９０８は、双方の端末（ＵＥ１００，１０２）がＣＳ網にハンドオーバしたと判断し、ＩＭＳシグナリング（ＳＤＰオファー）のコーデックリストの中に、ＰＳ網のみでサポートしているコーデックを含めることを回避できる。この通知は、例えば、ＵＥ１０２がＣＳ網にハンドオーバした際にＵＥ１０２から送られる既存のシグナリングに含まれてもよいし、新しいシグナリングでもよい（図２１に示すＳＴ１８０６）。また、上記通知は、ＵＥ１０２がＣＳ網にハンドオーバする以前に、ＭＭＥ（図示せず）に対し送信されるシグナリングに含まれてもよい（例えば、非特許文献４参照）。
　また、図１９に示すように、ＭＳＣ／ＭＧＷ１７０４，１７０６は、ＡＴＣＦ／ＡＴＧＷ１７００，１７０２と同等の機能を具備してもよい。図１８において、ＵＥ１００側のネットワークがｅＳＲＶＣＣに対応していない場合、ＭＳＣ／ＭＧＷ１７０４のシグナリング解析部１９０４は、ＵＥ１００がＣＳ網にハンドオーバした際、ＣＳ網で使用するコ－デックを含むシグナリングを解析し、ＵＥ１００がＣＳ網で使用するコーデックの情報を得る。次いで、ＭＳＣ／ＭＧＷ１７０４のシグナリング生成部１９０６は、ＵＥ１００がＣＳ網で使用するコーデックの情報を生成し、ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８に通知する。この通知は、ＩＮＶＩＴＥメッセージに含まれてもよい。また、図１８において、ＵＥ１０２側のネットワークがｅＳＲＶＣＣに対応していない場合、ＭＳＣ／ＭＧＷ１７０６のシグナリング解析部１９０４は、ＵＥ１０２から、通信相手であるＵＥ１００のコーデックが変更になっていることを通知する内容を含むシグナリングを受け取った際、ＵＥ１０２の通信相手であるＵＥ１００のコーデックが変更になっていることを検知する。次いで、ＭＳＣ／ＭＧＷ１７０６のシグナリング生成部１９０６は、ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８に対してＵＥ１００のコーデックを問い合わせるシグナリングを生成し、ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８に送信する。ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８より返信シグナリングを受け取ると、ＭＳＣ／ＭＧＷ１７０６のシグナリング解析部１９０４は、この返信シグナリングを解析し、解析結果に基づいて、ＵＥ１００側でトランスコーディングを行うノード（ＭＳＣ／ＭＧＷ１７０４又はＡＴＣＦ／ＡＴＧＷ１７００）との間でコーデック折衝を行い、コーデックを選択する。なお、コーデック折衝は、ＭＳＣ／ＭＧＷ１７０６とＳＣＣ　ＡＳ／ＣＳＣＦ１７０８との間、及び、ＳＣＣ　ＡＳ／ＣＳＣＦ１７０８とＵＥ１００側でトランスコーディングを行うノードとの間で行われてもよい（すなわち、ＳＣＣ　ＡＳでアンカーしてもよい）。これにより、一方のＵＥがｅＳＲＶＣＣ方式により、他方のＵＥがＳＲＶＣＣ方式によって、ＰＳ網からＣＳ網へハンドオーバを行う場合でも、実施の形態３と同様、トランスコーディングを最小限に抑えることができる。
　（実施の形態５）
　実施の形態１、３及び４では、ＭＳＣ／ＭＧＷ又はＡＴＣＦ／ＡＴＧＷが、セッション途中における片方のＵＥの通信データの帯域幅の変更を検出した場合、もう片方のＵＥに対し帯域制限通知を行う方法を説明した。これに対して、本実施の形態では、帯域制限通知を送る代わりに、又は帯域制限通知を送る事に加え、ＭＳＣ／ＭＧＷ又はＡＴＣＦ／ＡＴＧＷが送る通信データ、又は通信データのＲＴＰペイロードのヘッダ部に帯域情報を明示的に含める方法を説明する。
　例えば、実施の形態１において、ＭＳＣ／ＭＧＷ３００のコーデック帯域幅検出部６０６でＵＥ１００の帯域幅変更を検出し、変更判断部６０８でＵＥ１０２へのエンコードされる入力信号の帯域幅制限が可能であり、かつ、帯域幅制限が必要であると判断された場合、ＭＳＣ／ＭＧＷ３００からＵＥ１０２へ送られる通信データの帯域幅も制限する。この際、ＭＳＣ／ＭＧＷ３００が送る通信データそのもの、又は通信データが格納されるＲＴＰのペイロードヘッダ部に、明示的に変更後の帯域幅情報を含める。
　ＲＴＰペイロードヘッダ部に変更後の帯域情報を含める場合、帯域情報を含めるパケットは、帯域変更後のある一定期間（例えば２００ｍｓｅｃ）に送られるパケット、又はある一定個数のパケット（例えば１０パケット）に限る。
　受信側（ＵＥ１０２）では、ある一定期間以上（例えば１５０ｍｓｅｃ以上）又はある特定個数（例えば５パケット以上）のＲＴＰのペイロードヘッダに帯域情報が付加されている事を検出すると、その後送られてくるＲＴＰペイロードヘッダに帯域情報が付加されていなかった場合においても、格納されている通信データの帯域幅が制限され続けると判断する。
　帯域制限通知を受け取ったＵＥ１０２が、帯域を制限した通信データをＭＧＷ３００に送信する場合においても同様に、ある一定期間（例えば２００ｍｓｅｃ）に送られるパケット、又はある一定個数のパケット（例えば１０パケット）のＲＴＰペイロードヘッダ部に帯域情報を付加する。受信側（ＭＧＷ３００）では、ある一定期間以上（例えば１５０ｍｓｅｃ以上）又はある特定個数（例えば５パケット以上）のＲＴＰのペイロードヘッダに帯域情報が付加されている事を検出すると、その後送られてくるＲＴＰペイロードヘッダに帯域情報が付加されていなかった場合においても、格納されている通信データの帯域幅が制限され続けると判断する。
　また、実施の形態２において、帯域制限通知を受け取る代わりに、ＵＥ１０２のデータ解析部１２００において、データそのものの帯域幅が一定時間以上制限されている事を検出し、送信するデータの帯域を制限する方法を説明した。これに代えて、本実施の形態の上述の方法（ある一定期間以上（例えば１５０ｍｓｅｃ以上）又はある特定個数（例えば５パケット以上）のＲＴＰのペイロードヘッダに帯域情報が付加されている事）を用いて、コーデックモード変更部１２０２において、帯域の変更を決定してもよい。
　また、実施の形態１、３及び４において、帯域制限通知そのものを、ＲＴＰペイロードヘッダに含めてもよい。帯域制限通知をＲＴＰペイロードヘッダに含める場合においても、帯域制限通知を含めるパケットは、帯域変更通知が必要であると判定された後のある一定期間（例えば１００ｍｓｅｃ）に送られるパケット、又はある一定個数のパケット（例えば５パケット）に限る。受信側（ＵＥ１０２）では、ある一定期間以上（例えば２０ｍｓｅｃ以上）又はある特定個数（例えば１パケット以上）のＲＴＰのペイロードヘッダに帯域制限通知が付加されている事を検出すると、その後送られてくるＲＴＰペイロードヘッダに帯域制限通知が付加されていなかった場合においても、帯域幅の制限（変更）を依頼されていることが通知されたと判断する。尚、帯域制限通知をＲＴＰペイロードヘッダに含める場合には、帯域制限通知と共に上述の帯域情報を含めてもよい。
　これにより、送信データの帯域幅の変更を、セッション途中でも明示的に通信相手に通知する事ができる。
　以上、本発明の各実施の形態について説明した。
　なお、上記各実施の形態では、ＡＴＣＦ／ＡＴＧＷ、ＭＳＣ／ＭＧＷ、ＳＣＣ　ＡＳ／ＣＳＣＦをそれぞれ一つのノードとして説明したが、別々のノードでもよい。すなわち、ＡＴＣＦとＡＴＧＷとの間、ＭＳＣとＭＧＷとの間、及び、ＳＣＣ　ＡＳとＣＳＣＦとの間のそれぞれにおいて、上述した機能をいずれか一方若しくは両方が具備していればよい。また、ＡＴＣＦとＡＴＧＷとの間、ＭＳＣとＭＧＷとの間、及び、ＳＣＣ　ＡＳとＣＳＣＦとの間のそれぞれで必要な情報をやり取りしてもよい。
　また、上記各実施の形態において、ＵＥ１００及びＵＥ１０２の双方ともＣＳ網へのハンドオーバ（ＳＲＶＣＣ、ｅＳＲＶＣＣ等によるハンドオーバ）をサポートしている場合には、ＰＳ網上でのセッション折衝の際、ＣＳ網でサポートされているコーデック若しくはＣＳ網でサポートされているコーデックと互換性のあるコーデックが初めから選択されてもよい。
　また、上記各実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、これに限らず、音楽、音響、画像等に関しても、本発明は適用可能である。
　また、本発明は、上記各実施の形態に限定されず、種々変更して実施することが可能である。
　また、上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。
　また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
　また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）または、ＬＳＩ内部の回路セルの接続若しくは設定を再構成可能なリコンフィギュラブル／プロセッサを利用してもよい。
　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　２０１１年６月９日出願の特願２０１１－１２９４２２、２０１１年１１月１１日出願の特願２０１１－２４７３３０および２０１２年２月１５日出願の特願２０１２－０３０４１９の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
　本発明は、通信中の通信端末の一方が利用するコーデックが変更になった場合、通信相手の利用するコーデックのエンコードされる入力信号の帯域幅又はエンコーディングビットレートを調整する機能を有するため、トランスコーディングによる品質劣化を抑える事に有用である。
　１００，１０２　ＵＥ
　２００，２０２，２０４，２０６，１１００，１１０２，１１０４，１１０６　シグナリング
　３００，１３００，１３０２，１３１０，１７０４，１７０６　ＭＳＣ／ＭＧＷ
　１１２０，１７００，１７０２　ＡＴＣＦ／ＡＴＧＷ
　６００，７００，１５００，１９００　受信部
　６０２，７０２，１５０２，１９０２　送信部
　６０４　コーデック検出部
　６０６　コーデック帯域幅検出部
　６０８　変更判断部
　６１０，１５０６，１９０６，２００２　シグナリング生成部
　６１２　トランスコーディング部
　７０４　コーデック折衝部
　７０６，１５１０，１９１０　コーデック選択部
　７０８　帯域幅決定部
　７１０，１５０４，１９０４　シグナリング解析部
　７１２，１２０２　コーデックモード変更部
　１２００　データ解析部
　１５０８，１９０８　端末位置判断部
　１５１２，１９１２　経路選択部
　１７０８　ＳＣＣ　ＡＳ／ＣＳＣＦ
　２０００　通信相手コーデック変更検出部

Claims (10)

  1. 　異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行うネットワークノードであって、
    　前記２つの端末がそれぞれ使用するコーデックを検出する検出手段と、
    　前記検出手段での検出結果に基づいて、前記２つの端末のうちいずれか一方の端末が使用するコーデックの変更を検出した場合、前記一方の端末以外の他方の端末の第１のコーデック、及び、前記一方の端末の変更後の第２のコーデックを用いて、前記第１のコーデックの第１の帯域幅の制限を行うか否かを判断する判断手段と、
    　前記判断手段において前記第１の帯域幅を制限すると判断された場合、前記第１の帯域幅を制限させるためのシグナリングを、前記他方の端末へ送信する送信手段と、
    　を具備するネットワークノード。
  2. 　前記判断手段は、
    　前記検出手段で前記一方の端末のコーデックの変更が検出され、前記第１のコーデックが帯域幅の指定不要なコーデックであり、かつ、前記第２のコーデックの第２の帯域幅が前記第１のコーデックの最大帯域幅よりも狭い場合、前記第１の帯域幅を、前記第２の帯域幅に変更すると判断する、
    　請求項１記載のネットワークノード。
  3. 　前記送信手段は、前記第１の帯域幅の制限を依頼する前記シグナリングを前記他方の端末へ送信する、
    　請求項１記載のネットワークノード。
  4. 　各端末では入力信号のエンコーディングビットレートに基づいてコーデックの帯域幅が設定され、
    　前記送信手段は、前記他方の端末における入力信号のエンコーディングビットレートの制限を依頼する前記シグナリングを前記他方の端末へ送信する、
    　請求項１記載のネットワークノード。
  5. 　前記一方の端末が第１の網にハンドオーバし、前記他方の端末が第２の網にハンドオーバした場合において、前記ネットワークノードは前記第１の網に属し、
    　前記第２の網の他のネットワークノードから、前記第２の網でサポートしているコーデック群を含むメッセージを受信する受信手段と、
    　前記コーデック群、及び、前記一方の端末が使用する前記第２のコーデックを用いて、前記他方の端末が使用するコーデックを選択する選択手段と、
    　を更に具備する、
    　請求項１記載のネットワークノード。
  6. 　前記選択手段は、前記コーデック群に前記第２のコーデックが含まれる場合、前記他方の端末が使用するコーデックとして、前記第２のコーデックを選択する、
    　請求項５記載のネットワークノード。
  7. 　前記一方の端末が第１の網にハンドオーバした後に、前記他方の端末が第２の網にハンドオーバした場合において、
    　前記第２の網のネットワークノードから、前記一方の端末が前記第１の網にハンドオーバしたことを示す情報を含むメッセージを受信し、他のネットワークノードへの問い合わせにより、前記一方の端末が使用する前記第２のコーデックを含むメッセージを受信する受信手段と、
    　前記一方の端末が前記第１の網にハンドオーバしたことを示す情報を受信した場合、前記一方の端末が使用する第２のコーデックに基づいて、前記他方の端末が使用するコーデックを選択する選択手段と、
    　を更に具備する、
    　請求項１記載のネットワークノード。
  8. 　異なるコーデックを使用する端末間の通信に対して、端末間に位置するネットワークノードでトランスコーディングが行われる通信システムで用いられる端末であって、
    　前記端末と、前記端末の通信相手である相手端末との間の通信に使用する第１のコーデックを折衝する折衝手段と、
    　折衝された前記第１のコーデックに対して、前記端末においてエンコードされる入力信号の第１の帯域幅を決定する決定手段と、
    　前記ネットワークノードから通知される、前記第１の帯域幅を制限させるためのシグナリングに従って、前記決定手段で決定された前記第１の帯域幅の変更を制御する変更手段と、
    　を具備する端末。
  9. 　異なるコーデックを使用する２つの端末間の通信に対してトランスコーディングを行うネットワークノードにおける帯域幅変更判断方法であって、
    　前記２つの端末がそれぞれ使用するコーデックを検出し、
    　検出結果に基づいて、前記２つの端末のうちいずれか一方の端末が使用するコーデックの変更を検出した場合、前記一方の端末以外の他方の端末の第１のコーデック、及び、前記一方の端末の変更後の第２のコーデックを用いて、前記第１のコーデックの第１の帯域幅の制限を行うか否かを判断し、
    　前記第１の帯域幅を制限すると判断された場合、前記第１の帯域幅を制限させるためのシグナリングを、前記他方の端末へ送信する、
    　帯域幅変更判断方法。
  10. 　異なるコーデックを使用する端末間の通信に対して、端末間に位置するネットワークノードでトランスコーディングが行われる通信システムで用いられる端末における帯域幅変更方法であって、
    　前記端末と、前記端末の通信相手である相手端末との間の通信に使用する第１のコーデックを折衝し、
    　折衝された前記第１のコーデックに対して、前記端末においてエンコードされる入力信号の第１の帯域幅を選択し、
    　前記ネットワークノードから通知される、前記第１の帯域幅を制限させるためのシグナリングに従って、前記第１の帯域幅の変更を制御し、
    　前記第１の帯域幅の変更の制御に従って、前記第１の帯域幅を決定する、
    　帯域幅変更方法。
PCT/JP2012/003410 2011-06-09 2012-05-25 ネットワークノード、端末、帯域幅変更判断方法及び帯域幅変更方法 WO2012169134A1 (ja)

Priority Applications (9)

Application Number Priority Date Filing Date Title
EP20160616.7A EP3684104A1 (en) 2011-06-09 2012-05-25 Communication terminal and communication method
US14/123,333 US9288792B2 (en) 2011-06-09 2012-05-25 Network node, terminal, bandwidth modification determination method and bandwidth modification method
PL16193870T PL3139696T3 (pl) 2011-06-09 2012-05-25 Terminal połączeniowy i sposób łączności
EP16193870.9A EP3139696B1 (en) 2011-06-09 2012-05-25 Communication terminal and communication method
EP12796764.4A EP2706766B1 (en) 2011-06-09 2012-05-25 Network node, terminal, bandwidth modification determination method and bandwidth modification method
JP2013519368A JP5947294B2 (ja) 2011-06-09 2012-05-25 通信端末装置、ネットワークノード及び通信方法
CN201280024440.XA CN103548369B (zh) 2011-06-09 2012-05-25 网络节点、终端、带宽变更判断方法及带宽变更方法
US15/014,405 US10841842B2 (en) 2011-06-09 2016-02-03 Communication terminal apparatus and communication method
US17/069,499 US11647428B2 (en) 2011-06-09 2020-10-13 Communication terminal apparatus and communication method

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2011-129422 2011-06-09
JP2011129422 2011-06-09
JP2011-247330 2011-11-11
JP2011247330 2011-11-11
JP2012030419 2012-02-15
JP2012-030419 2012-02-15

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US14/123,333 A-371-Of-International US9288792B2 (en) 2011-06-09 2012-05-25 Network node, terminal, bandwidth modification determination method and bandwidth modification method
US15/014,405 Continuation US10841842B2 (en) 2011-06-09 2016-02-03 Communication terminal apparatus and communication method

Publications (1)

Publication Number Publication Date
WO2012169134A1 true WO2012169134A1 (ja) 2012-12-13

Family

ID=47295726

Family Applications (1)

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

Country Status (7)

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

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015062674A1 (en) * 2013-11-04 2015-05-07 Nokia Solutions And Networks Oy Improved access domain transfer
WO2016185649A1 (ja) * 2015-05-20 2016-11-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信ノード、端末及び通信制御方法
JP2018524840A (ja) * 2015-04-29 2018-08-30 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ ３ｇｐｐ（登録商標）２ネットワークにおける拡張音声サービス（ｅｖｓ）
JP2019525592A (ja) * 2016-08-11 2019-09-05 京セラ株式会社 Ｒａｎ補助のレートアダプテーション

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9622118B2 (en) * 2012-11-16 2017-04-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for improved PS to CS handover of a user equipment
JP5998923B2 (ja) * 2012-12-28 2016-09-28 富士通株式会社 プログラム、情報処理装置、及び通信方法
US9344933B1 (en) * 2014-04-10 2016-05-17 Sprint Communications Company L.P. Mobility management entity (MME) system and method to disable voice over LTE (VoLTE) service of a long term evolution (LTE) base station
CN106416366B (zh) * 2014-05-05 2019-06-21 联发科技股份有限公司 通信系统中切换过程期间管理呼叫的方法及装置
US10085196B1 (en) 2014-07-03 2018-09-25 Sprint Communications Company L.P. Wireless communication control based on border gateway protocol
EP3189644A1 (en) * 2014-09-05 2017-07-12 Intel Corporation Transcoding avoidance during single radio voice call continuity (srvcc)
KR102414522B1 (ko) * 2014-09-25 2022-06-30 삼성전자주식회사 무선 거리 측정 장치 및 방법
EP3205143B1 (en) * 2014-10-08 2020-09-02 Nokia Solutions and Networks Oy Transfer of communication parameters
CN113259058A (zh) * 2014-11-05 2021-08-13 三星电子株式会社 用于在无线通信系统中发射和接收语音数据的装置和方法
CN105100046A (zh) * 2015-05-19 2015-11-25 华为技术有限公司 一种媒体互通方法及其装置
US9867106B2 (en) * 2015-12-30 2018-01-09 T-Mobile Usa, Inc. Codec-specific handover thresholds
US10278100B1 (en) * 2016-03-16 2019-04-30 Sprint Communications Company L.P. Long term evolution (LTE) mobility management entity (MME) management of an internet protocol multimedia subsystem (IMS) media session service level for a user equipment (UE)
CN108702372B (zh) * 2016-03-28 2021-09-07 松下电器（美国）知识产权公司 终端、基站及编解码器模式切换方法
WO2018085668A1 (en) * 2016-11-04 2018-05-11 Intel IP Corporation Ue and devices for codec rate adaptation
EP3582581B1 (en) 2017-03-20 2022-01-26 Huawei Technologies Co., Ltd. Service communication method, access network device and system
CA3061833C (en) 2017-05-18 2022-05-24 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Managing network device
US11601483B2 (en) * 2018-02-14 2023-03-07 Genband Us Llc System, methods, and computer program products for selecting codec parameters

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002015630A1 (fr) * 2000-08-10 2002-02-21 Ntt Docomo, Inc. Systeme de communication mobile, son procede de commutation de ressources, dispositif et procede de controle de reseau compris dans ce systeme
JP2009512379A (ja) * 2005-10-21 2009-03-19 シーメンス アクチエンゲゼルシヤフト データネットワークにおいてビデオ電話コネクションおよび／またはマルチメディア電話コネクションを確立する方法

Family Cites Families (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001082640A1 (fr) * 2000-04-26 2001-11-01 Fujitsu Limited Procede de communication multipoint et dispositif de commande de communication
US20030028643A1 (en) * 2001-03-13 2003-02-06 Dilithium Networks, Inc. Method and apparatus for transcoding video and speech signals
EP1248431B1 (en) * 2001-03-27 2007-10-31 Sony Deutschland GmbH Method for achieving end-to-end quality of service negotiation for distributed multimedia applications
US20020163908A1 (en) * 2001-05-07 2002-11-07 Ari Lakaniemi Apparatus, and associated method, for synchronizing operation of codecs operable pursuant to a communicaton session
FI20011715A (fi) * 2001-08-27 2003-02-28 Nokia Corp Koodekin toiminnallisen moodin valinta
US7639601B2 (en) * 2002-07-05 2009-12-29 Nortel Networks Limited Methods and apparatus for data communication
FI116498B (fi) * 2002-09-23 2005-11-30 Nokia Corp Kaistanleveyden mukauttaminen
MXPA05003127A (es) * 2002-09-23 2005-06-22 Nokia Corp Adaptacion de ancho de banda.
WO2005036896A2 (en) * 2003-09-12 2005-04-21 Motorola, Inc. , A Corporation Of The State Of Delaware Apparatus and method for supporting enhanced transcoding functionality
US7751359B1 (en) * 2003-11-26 2010-07-06 Ericsson Ab Call origination in a CDMA legacy MS domain using SIP
JP2005236388A (ja) * 2004-02-17 2005-09-02 Nippon Telegr & Teleph Corp <Ntt> リソース管理方法、リソース管理装置、リソース管理プログラム及びそのプログラムを記録した記録媒体
US7668712B2 (en) * 2004-03-31 2010-02-23 Microsoft Corporation Audio encoding and decoding with intra frames and adaptive forward error correction
FI119533B (fi) 2004-04-15 2008-12-15 Nokia Corp Audiosignaalien koodaus
US7596486B2 (en) * 2004-05-19 2009-09-29 Nokia Corporation Encoding an audio signal using different audio coder modes
US7463901B2 (en) * 2004-08-13 2008-12-09 Telefonaktiebolaget Lm Ericsson (Publ) Interoperability for wireless user devices with different speech processing formats
US20060230169A1 (en) * 2004-11-15 2006-10-12 Kaplan Mark M System and method to simultaneously transcode audio and video content for optimized streaming via mobile telecommunications
KR100735274B1 (ko) * 2004-11-18 2007-07-03 삼성전자주식회사 트랜스코더를 구비한 분산형 멀티미디어 전송 네트워크의트랜스코딩 방법 및 장치
DE102005006174A1 (de) * 2005-02-10 2006-08-17 Siemens Ag Signalisierung eines Wechsels von einem ersten Dienst zu einem zweiten Dienst während einer Gesprächsverbindung
US20060251093A1 (en) * 2005-05-03 2006-11-09 Nokia Corporation Signaling quality of service (QoS) parameters for a multimedia session
JP2009522830A (ja) * 2005-12-28 2009-06-11 ヴァントリックス コーポレーション マルチメディアセッションのためのマルチユーザリアルタイムトランスコーディングシステムおよび方法
US7593325B1 (en) * 2005-12-28 2009-09-22 At&T Corp. Method and apparatus for controlling call volume in a packet network
US7835346B2 (en) * 2006-01-17 2010-11-16 Genband Us Llc Methods, systems, and computer program products for providing transcoder free operation (TrFO) and interworking between unlicensed mobile access (UMA) and universal mobile telecommunications system (UMTS) call legs using a media gateway
GB2440381B (en) * 2006-07-27 2008-11-05 Motorola Inc An internet protocol multimedia subsystem network element and method of operation therefor
JP4827652B2 (ja) * 2006-08-10 2011-11-30 富士通株式会社 中継装置、中継方法および中継プログラム
KR100744567B1 (ko) * 2006-09-29 2007-08-01 한국전자통신연구원 멀티 네트워크 멀티 코덱 환경에서 트랜스코딩 횟수를최소화하는 장치 및 방법
US7907523B2 (en) * 2006-12-05 2011-03-15 Electronics And Telecommunications Research Institute Method and apparatus for controlling variable bit-rate voice codec
WO2008069723A2 (en) * 2006-12-08 2008-06-12 Telefonaktiebolaget Lm Ericsson (Publ) Handling announcement media in a communication network environment
WO2008141675A1 (en) * 2007-05-22 2008-11-27 Telefonaktiebolaget Lm Ericsson (Publ) Method, apparatuses and computer program for dynamically configuring a proxy call session control function of the ip multimedia subsystem from a policy control rules server
JP5284355B2 (ja) * 2007-07-09 2013-09-11 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信システムにおける適応レート制御
WO2009051531A1 (en) * 2007-10-16 2009-04-23 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for improving the efficiency of resource utilisation in a communications system
US9479967B1 (en) * 2007-10-26 2016-10-25 Genband Us Llc Enhanced media gateway
US7801543B2 (en) * 2007-12-14 2010-09-21 Motorola, Inc. Dynamic vocoder assignment in a communication system
KR101167523B1 (ko) * 2008-01-17 2012-07-20 노키아 코포레이션 무선 시스템에서의 적응적 멀티-레이트 코덱 비트 레이트 제어
ATE548884T1 (de) * 2008-02-11 2012-03-15 Nokia Siemens Networks Oy Verfahren und vorrichtungen zur codec-änderung bei laufenden anrufen auf ip-basierter a- schnittstelle
US8204022B2 (en) * 2008-02-20 2012-06-19 Alcatel Lucent Method of providing transcoding during voice-over-internet protocol handoff
ATE541385T1 (de) * 2008-03-25 2012-01-15 Ericsson Telefon Ab L M Richtlinien- und vergebührungssteuerarchitektur
PL3324656T3 (pl) * 2008-05-02 2021-06-28 Nokia Technologies Oy Lista kodeków w domenie z komutacją obwodów dla ciągłości pojedynczego radiowego połączenia głosowego
KR101523590B1 (ko) * 2009-01-09 2015-05-29 한국전자통신연구원 통합 인터넷 프로토콜망의 코덱 모드 제어방법 및 단말기
GB2454606C (en) * 2009-02-02 2017-01-25 Skype Ltd Method of transmitting data in a communication system
EP2417749A4 (en) * 2009-04-07 2017-01-11 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for session negotiation
KR101056209B1 (ko) * 2009-04-14 2011-08-11 포항공과대학교 산학협력단 이종망간 핸드오버시 적응적 코덱 변환 방법 및 적응적 코덱 변환 기능을 갖는 ｓｉｐ 클라이언트 장치
US9357568B2 (en) * 2009-06-16 2016-05-31 Futurewei Technologies, Inc. System and method for adapting an application source rate to a load condition
JP5629091B2 (ja) 2009-12-18 2014-11-19 パナソニック株式会社 配線ダクト接続装置
EP2520130B1 (en) * 2009-12-31 2020-12-09 Nokia Technologies Oy Method and apparatus for performing multiple forms of communications in one session
JP2011247330A (ja) 2010-05-26 2011-12-08 Toyota Motor Corp 電磁式リニア弁
JP2012030419A (ja) 2010-07-29 2012-02-16 Kyocera Mita Corp 画像形成装置
ES2918456T3 (es) * 2010-08-18 2022-07-15 Blackberry Ltd Métodos para mantener la continuidad de las llamadas
RU2596584C2 (ru) * 2010-10-25 2016-09-10 Войсэйдж Корпорейшн Кодирование обобщенных аудиосигналов на низких скоростях передачи битов и с низкой задержкой
WO2012095700A1 (en) * 2011-01-12 2012-07-19 Nokia Corporation An audio encoder/decoder apparatus
US9026434B2 (en) * 2011-04-11 2015-05-05 Samsung Electronic Co., Ltd. Frame erasure concealment for a multi rate speech and audio codec

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002015630A1 (fr) * 2000-08-10 2002-02-21 Ntt Docomo, Inc. Systeme de communication mobile, son procede de commutation de ressources, dispositif et procede de controle de reseau compris dans ce systeme
JP2009512379A (ja) * 2005-10-21 2009-03-19 シーメンス アクチエンゲゼルシヤフト データネットワークにおいてビデオ電話コネクションおよび／またはマルチメディア電話コネクションを確立する方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KATSUTOSHI NISHIDA; TAKASHI KOSHIMIZU: "Proposal on an Improvement of the IMS-Circuit Switch Voice Call Continuity: Local Anchoring SRVCC based on the Terminal Capability", IEICE TECHNICAL REPORT NS2010-178, pages 85 - 90
See also references of EP2706766A4
TAKASHI KOSHIMIZU; KATSUTOSHI NOSHIDA: "Audio Video Calloff Single Radio Voice Call Continuity", GENERAL MEETING OF THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS, 2011, pages B-6 - 77

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015062674A1 (en) * 2013-11-04 2015-05-07 Nokia Solutions And Networks Oy Improved access domain transfer
JP2018524840A (ja) * 2015-04-29 2018-08-30 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ ３ｇｐｐ（登録商標）２ネットワークにおける拡張音声サービス（ｅｖｓ）
WO2016185649A1 (ja) * 2015-05-20 2016-11-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信ノード、端末及び通信制御方法
US10911988B2 (en) 2015-05-20 2021-02-02 Panasonic Intellectual Property Corporation Of America Communication node, terminal, and communication control method
JP2019525592A (ja) * 2016-08-11 2019-09-05 京セラ株式会社 Ｒａｎ補助のレートアダプテーション
JP2021061630A (ja) * 2016-08-11 2021-04-15 京セラ株式会社 Ｒａｎ支援レートの適応
JP7030178B2 (ja) 2016-08-11 2022-03-04 京セラ株式会社 Ｒａｎ支援レートの適応

Also Published As

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

Similar Documents

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

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013519368

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14123333

Country of ref document: US

REEP Request for entry into the european phase

Ref document number: 2012796764

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2012796764

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE