WO2013080471A1 - ネットワークノード及び通信方法 - Google Patents

ネットワークノード及び通信方法 Download PDF

Info

Publication number
WO2013080471A1
WO2013080471A1 PCT/JP2012/007358 JP2012007358W WO2013080471A1 WO 2013080471 A1 WO2013080471 A1 WO 2013080471A1 JP 2012007358 W JP2012007358 W JP 2012007358W WO 2013080471 A1 WO2013080471 A1 WO 2013080471A1
Authority
WO
WIPO (PCT)
Prior art keywords
codec
network
terminal
data
rtp payload
Prior art date
Application number
PCT/JP2012/007358
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 EP12853666.1A priority Critical patent/EP2787765B1/en
Priority to JP2013546973A priority patent/JP6012625B2/ja
Priority to ES12853666T priority patent/ES2728678T3/es
Priority to US14/357,306 priority patent/US9456388B2/en
Priority to EP19153189.6A priority patent/EP3493595B1/en
Priority to PL12853666T priority patent/PL2787765T3/pl
Publication of WO2013080471A1 publication Critical patent/WO2013080471A1/ja
Priority to US15/242,968 priority patent/US9906990B2/en
Priority to US15/870,256 priority patent/US10225767B2/en
Priority to US16/250,391 priority patent/US10362514B2/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
    • H04W36/00224—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H04W36/00226—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • 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 and a communication 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).
  • MSC and MGW are represented as one node (MSC / MGW110), but they may be represented as separate nodes.
  • 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 the MSC / MGW 110 (signaling 200 shown in FIG. 1). 2 (hereinafter referred to as “ST”) 200 shown in FIG.
  • a data path in the CS network is prepared between nodeB and MSC / MGW110, and when the preparation is completed, an instruction is issued from MME to hand over UE100 to the UTRAN (CS network) side via e-nodeB. Is issued.
  • the MSC / MGW 110 exchanges signaling with the UE 102 via the CSCF / SCC AS (signaling 202 shown in FIG. 1; 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 110, and Path B is established.
  • UE 100 After handing over to UTRAN, UE 100 exchanges signaling with MSC / MGW 110 via RNC / nodeB (signaling 204 shown in FIG. 1; ST204 shown in FIG. 2). Thereby, Path C is established.
  • the MSC / MGW 110 exchanges signaling with the P-GW / S-GW via the MME (signaling 206 shown in FIG. 1 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 320), 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. Also, 300, 302, 304, and 306 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 320 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 detects this and exchanges signaling with the RNC / nodeB via the MME and MSC / MGW 110 (signaling 300 shown in FIG. 3).
  • the MSC / MGW 110 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 110 (signaling 302 shown in FIG. 3 and ST302 shown in FIG. 4). That is, Path C is established.
  • the ATCF transmits notification signaling to the SCC-AS (signaling 302 shown in FIG. 3 and ST302 shown in FIG. 4).
  • UE 100 After handing over to UTRAN, UE 100 exchanges signaling with MSC / MGW 110 via RNC / nodeB (signaling 304 shown in FIG. 3 and ST304 shown in FIG. 4). Thereby, Path D is established.
  • Path D After Path D is established, MSC / MGW 110 exchanges signaling with P-GW / S-GW via MME (signaling 306 shown in FIG. 3; ST306 shown in FIG. 4). As a result, Path B is deleted.
  • AMR-WB Adaptive Multi-Rate Wideband
  • WB wideband
  • a codec that supports an AMR-WB compatible mode as a codec other than the AMR-WB used in the PS network (VoLTE), such as EVS (Enhanced Voice Service) described in Non-Patent Document 4.
  • the AMR-WB compatible mode is assumed to be used as an AMR-WB codec with a legacy terminal that normally supports the AMR-WB codec. For this reason, when the codec is used in the PS network (VoLTE), it is considered that the RTP payload format of the AMR-WB codec described in Non-Patent Document 2 is used.
  • a narrowband (NB) codec is a codec that performs encoding and decoding processing of a digital audio signal sampled at 8 kHz.
  • a narrowband codec generally has a frequency band of 300 Hz to 3.4 kHz, but the frequency band is not limited to this and may be in the range of 0 to 4 kHz.
  • the wideband codec is a codec that performs encoding and decoding processing of a digital audio signal sampled at 16 kHz.
  • a wideband codec generally has a frequency band of 50 Hz to 7 kHz, but the frequency band is not limited to this and may be in the range of 0 to 8 kHz.
  • the super wideband (SWB) codec is a codec that performs encoding and decoding processing of a digital audio signal sampled at 32 kHz.
  • An ultra-wideband codec generally has a frequency band of 50 Hz to 14 kHz, but the frequency band is not limited to this and is not limited to this as long as it is within a range of 0 to 16 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” 3GPP TS22.813 v10.0.0 “Study” Use “Cases” and “Requirements” for “Enhanced” Voice “Codecs” for “the” Evolved “Packet” System ”(EPS)” Takashi Koshimizu and Katsutoshi Noshida, “Audio Viedo Callof Single Radio Voice Call Continuity”, 2011 IEICE General Conference, B-6-77 3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS); Multimedia Telephony;
  • the codec used in the UE 100 is the CS network. Changed to a supported codec.
  • the first method is a method of transcoding in MSC / MGW or ATCF / ATGW.
  • the second method is a method of changing the codec used in the UE 102 to the same codec after the UE 100 is changed.
  • the latter method of changing the codec does not cause deterioration in call quality unlike the method of transcoding, but it takes time for signaling to change the codec of the UE 102, and the call is interrupted for a long time. It is not preferable.
  • 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.
  • An object of the present invention is to continue communication without causing degradation in call quality and suppressing the time during which a call is interrupted even when the codec used by one of the communicating terminals is changed. It is to provide a network node and a communication method that can be used.
  • a network node provides a network node between two terminals when one of two terminals communicating in the first network is handed over to a second network different from the first network.
  • the first codec is a codec having a compatibility mode with the second codec
  • the codec of the data transmitted from the one terminal is set as the codec of the first codec.
  • the communication method is the communication method between the two terminals when one of the two terminals communicating in the first network is handed over to a second network different from the first network.
  • a first codec used by the one terminal in the first network and a second codec used by the one terminal in the second network.
  • the first codec is a codec having a compatibility mode with the second codec
  • the codec of data transmitted from the one terminal is set to the compatibility mode of the first codec.
  • the communication can be continued without causing deterioration of the call quality and suppressing the time during which the call is interrupted. it can.
  • Configuration diagram showing a part of a 3GPP mobile communication network Sequence chart showing operation of SRVCC handover Configuration diagram showing part of 3GPP mobile communication network enabling eSRVCC Sequence chart showing operation of eSRVCC handover
  • the figure which shows an example of the RTP payload format which concerns on Embodiment 1 of this invention.
  • the figure which shows an example of the SDP offer and SDP answer which concern on Embodiment 1 of this invention The block diagram which shows the structure of the terminal (UE) which concerns on Embodiment 1 of this invention.
  • the block diagram which shows the structure of the network node (MSC / MGW) which concerns on Embodiment 1 of this invention.
  • bandwidth refers to the bandwidth of a signal that is input / output of a codec.
  • codec A a codec that can be used in both the PS network and the CS network is represented as “codec A”.
  • Codec A has a dedicated payload format.
  • the codec A is, for example, AMR-WB or AMR-NB.
  • Codec B has an incompatible mode (codec A incompatible mode) and a compatible mode (codec A compatible mode) for codec A.
  • codec B may be used in the CS network.
  • Codec B is, for example, GVS described in EVS or Non-Patent Document 7. 718.
  • FIG. 5 shows an example of the payload format (RTP payload format) of Codec B.
  • the payload format includes a data part and a header part.
  • the data portion includes data encoded by the encoder, and the header portion includes information necessary for the decoder to decode the data in the data portion.
  • the payload format of codec B in the present embodiment has a configuration that allows the payload receiving side to identify whether the data portion includes data in codec A incompatible mode or data in codec A compatible mode.
  • the header portion includes a “codec type” field and a “bit rate” field.
  • the “codec type” includes information indicating whether the codec A incompatible mode or the codec A compatible mode.
  • the “bit rate” includes information indicating at which bit rate the encoded data is the bit rate supported in each of the codec A incompatible mode and the codec A compatible mode.
  • a field (“codec type / bit rate switching request” field) for instructing a partner terminal on the payload receiving side to switch the codec type or bit rate is provided. May be included. This field need not be included for each frame, and may be included only when necessary.
  • the payload format of codec B is not limited to the example shown in FIG. Like the payload format of 718, the combination of each layer (corresponding to the bit rate) may be described as separate values.
  • FIG. 6 shows an example of an SDP (Session Description Protocol) offer and an SDP answer exchanged between terminals in session negotiation at the start of a call.
  • SDP Session Description Protocol
  • a UE that supports codec B describes codec A and codec B in the SDP offer even when codec A is not supported. This is because when the other terminal supports codec A but does not support codec B, codec A is selected in codec negotiation, and codec A compatibility mode of codec B is used as the RTP payload format of codec A. This is to enable use.
  • the UE that has received the SDP offer selects codec B, and describes the selected codec B in the SDP answer.
  • a mode that is prioritized when Codec B is selected (Codec A incompatible mode or Codec A compatible mode, bit rate, bandwidth, etc.) may be described.
  • the mode to be prioritized may be determined in advance by an operator who performs a communication service, and may be incorporated in the UE in the form of software or the like. In the present embodiment, it is assumed that when codec B is selected, codec A incompatible mode is used as the priority mode.
  • FIG. 7 is a block diagram showing a configuration of UEs 100 and 102 (terminals) according to the present embodiment.
  • the UEs 100 and 102 are configured to include a reception unit 700, a transmission unit 702, a codec negotiation unit 704, an RTP payload analysis unit 706, an RTP payload generation unit 708, and a codec notification unit 710.
  • the reception unit 700 receives communication data (including RTP payload), signaling, and the like. For example, when receiving the RTP payload (see, for example, FIG. 5) transmitted from the MSC / MGW 110, the receiving unit 700 outputs the received RTP payload to the RTP payload analyzing unit 706.
  • the transmission unit 702 transmits communication data (including RTP payload), signaling, and the like.
  • the codec negotiation unit 704 negotiates a codec used for communication between the terminals (UE100 and UE102). Specifically, the codec negotiation unit 704 creates an SDP offer or an SDP answer (see, for example, FIG. 6) and performs codec negotiation. At this time, when the codec negotiation unit 704 creates the SDP offer, as described above, even when the terminal supports the codec B but does not support the codec A, the codec A becomes the SDP offer as shown in FIG. include. Further, when the codec B is selected in the negotiation, the codec negotiation unit 704, according to the information described in the SDP offer and answer as described above, or the information previously incorporated in the software etc. A incompatible mode or codec A compatible mode, bit rate, bandwidth, etc.) are selected and output to the RTP payload generation unit 708.
  • the RTP payload analysis unit 706 analyzes the header part of the RTP payload received from the reception unit 700, and specifies information (eg, codec type, bit rate, etc.) regarding data included in the data part of the RTP payload.
  • the RTP payload analysis unit 706 outputs the specified information and data included in the data unit to a decoder (not shown).
  • the RTP payload analyzing unit 706 transmits the instruction to the encoder (not shown) and the RTP payload generating unit. Output to 708.
  • the encoder encodes data based on information and instructions from the RTP payload analysis unit 706.
  • the RTP payload generation unit 708 generates an RTP payload (see, for example, FIG. 5) including data received from the encoder and information (eg, codec type, bit rate, etc.) related to the data received from the codec negotiation unit 704.
  • an instruction “codec type / bit rate switching request” is input from the RTP payload analysis unit 706, the RTP payload generation unit 708 generates an RTP payload based on the instruction.
  • the generated RTP payload is transmitted via the transmission unit 702.
  • the codec notification unit 710 notifies the network node (for example, MME) of the PS network of the codec used by the own device in the PS network when the own device hands over from the PS network to the CS network.
  • the notified codec is notified to the MSC / MGW 110 via the network node (MME) of the PS network.
  • FIG. 8 is a block diagram showing a configuration of MSC / MGW 110 (network node) according to the present embodiment.
  • the MSC / MGW 110 includes a reception unit 800, a transmission unit 802, a codec detection unit 804, a codec negotiation unit 806, an RTP payload generation unit 808, and an RTP payload analysis unit 810.
  • the receiving unit 800 receives communication data (including RTP payload), signaling, and the like. For example, when receiving the RTP payload (see, for example, FIG. 5) transmitted from the UE 102, the receiving unit 800 outputs the received RTP payload to the RTP payload analyzing unit 810.
  • the transmission unit 802 transmits communication data (including RTP payload), signaling, and the like.
  • the codec detection unit 804 detects a codec used in the CS network by a terminal (UE 100 in FIG. 1) handed over from the PS network to the CS network. Further, the codec detection unit 804 detects the codec used in the PS network by the terminal (UE 100 in FIG. 1) handed over from the PS network to the CS network.
  • a method of detecting the codec used by the terminal (UE 100) in the PS network as disclosed in Non-Patent Document 5, when the UE 100 (codec notification unit 710) hands over to the CS network, A method notified from a network node (MME or the like) may also be used.
  • a method of detecting the codec used by the terminal (UE 100) in the PS network for example, a method of acquiring from another network node such as SCC AS may be used.
  • a method for detecting the codec used by the terminal (UE 100) in the CS network when the UE 100 is handed over to the CS network, the UE 100 and the network nodes (RNC and MSC / MGW 110) in the CS network are connected. There is a method of using information negotiated by signaling transmitted / received in the network.
  • the codec detection unit 804 outputs the codec detection result to the RTP payload generation unit 808.
  • the codec negotiation unit 806 negotiates a codec to be used with the UE, for example, in accordance with an instruction from the RTP payload generation unit 808. For example, the codec negotiation unit 806 negotiates (re-negotiates) a codec to be used with a terminal (UE 102 in FIG. 1) that is a communication partner of a terminal (UE 100 in FIG. 1) that has been handed over from the PS network to the CS network.
  • the RTP payload generation unit 808 uses the data received from the terminal (UE 100 in FIG. 1) and is intended for the communication partner of the terminal (UE 102 in FIG. 1). Data (RTP payload).
  • the RTP payload generation unit 808 uses the codec A used as the codec used by the terminal handed over from the PS network to the CS network in the CS network, and the codec used by the terminal in the PS network as the codec B.
  • the codec of the data (codec A data) received from the terminal is switched to the codec A compatible mode of codec B. That is, the MSC / MGW 110 transmits the codec A data received from the terminal as the codec A compatible mode of the codec B using the codec B RTP payload format (see FIG. 5) via the transmission unit 802. .
  • the RTP payload generation unit 808 transmits to the codec negotiation unit 806 a communication partner ( In FIG. 1, a codec negotiation (re-negotiation) with the UE 102) is instructed. Then, the RTP payload generation unit 808 transcodes the communication data received from the handed over terminal if necessary based on the negotiation result, and switches to the codec mode based on the negotiation result. Data after the codec switching (generated RTP payload) is transmitted via the transmission unit 802.
  • the RTP payload analysis unit 810 analyzes the header part of the RTP payload transmitted from the terminal (UE 102), and specifies information (eg, codec type, bit rate, etc.) regarding the data included in the data part of the RTP payload.
  • the RTP payload analyzer 810 outputs the specified information to the codec detector 804.
  • the MSC / MGW 110 is a network node that transfers data between two terminals when one of the two terminals (UEs 100 and 102) communicating in the PS network is handed over to the CS network.
  • the RTP payload generation unit 808 determines whether the codec used by the UE 100 in the CS network is the codec A based on the detection result in the codec detection unit 804.
  • the RTP payload generation unit 808 determines that the UE 100 is in the PS network (before handover) based on the detection result in the codec detection unit 804. B) Determine whether the codec used is codec B or not.
  • the RTP payload generation unit 808 changes the codec of the data (codec A) transmitted from the UE 100 to the codec of the codec B. Switch to A compatibility mode. That is, the RTP payload generation unit 808 transmits the codec A data transmitted from the UE 100 to the UE 102 via the transmission unit 802 in the codec B codec A compatible mode using the codec B RTP payload format.
  • the UE 102 using the codec B can handle data transmitted from the MSC / MGW 110 to the UE 102 as codec B data (codec B codec A compatible mode).
  • the codec in ST906 The negotiation unit 806 performs session renegotiation with the UE 102 to determine a codec. Then, the RTP payload generation unit 808 generates an RTP payload of the determined codec.
  • the MSC / MGW 110 may perform transcoding on the data transmitted from the UE 100 and transmit the data after transcoding (data for the UE 102) to the UE 102.
  • the MSC / MGW 110 detects the data for the other UE based on the codec after the change of the UE and the codec before the change of the UE. It is determined whether the codec can be switched.
  • both the UE 100 and the UE 102 are connected to the PS network and start a call.
  • a call is made from UE 100 to UE 102.
  • a codec to be used between the UE 100 and the UE 102 is negotiated.
  • the UE 100 (codec negotiation unit 704) generates an SDP offer (see, for example, FIG. 6) and transmits the SDP offer to the UE 102.
  • the UE 102 (codec negotiation unit 704) generates an SDP answer (see, for example, FIG. 6 and selects codec B in FIG. 6), and transmits it to the UE 100.
  • the UEs 100 and 102 make a call using the codec A incompatible mode of codec B (a mode that is prioritized when codec B is selected) (FIG. 2: SpeechSSession). over PS).
  • the UE 100 hands over from the PS network to the CS network (ST200 and ST204 shown in FIG. 2).
  • the codec used by the UE 100 in the CS network is referred to as codec A.
  • the MSC / MGW 110 detects the codec used when the UE 100 is handed over to the CS network. Further, the MSC / MGW 110 (codec detection unit 804) detects the codec used by the UE 100 in the PS network. As described above, the MSC / MGW 110 detects that the codec used by the UE 100 in the CS network is codec A, and the codec used by the UE 100 in the PS network is codec B (that is, as shown in FIG. 9). ST900: YES and ST902: YES).
  • the MSC / MGW 110 (RTP payload generation unit 808) generates the RTP payload for the UE 102 by switching the codec of the data (codec A) transmitted from the UE 100 to the codec A compatible mode of the codec B. That is, the MSC / MGW 110 transmits the codec A data transmitted from the UE 100 to the UE 102 as a codec A compatible mode of the codec B using the RTP payload format of the codec B.
  • the MSC / MGW 110 sends a request for switching from the codec A incompatible mode to the codec A compatible mode. You may transmit to UE102 which is.
  • the MSC / MGW 110 sends an instruction to switch from the codec A incompatible mode to the codec A compatible mode in the codec B RTP payload format (for example, see FIG. 5). It may be included in the “bit rate switching request” field).
  • the UE 102 determines that the data included in the data portion of the RTP payload is codec A (codec A compatible mode) from the information included in the data received from the MSC / MGW 110 (information in the header portion of the RTP payload). And the information and data are passed to the decoder. As a result, the decoder of the UE 102 recognizes that the codec of the received data is codec A (codec A codec A compatible mode), and decodes the data.
  • codec A codec A compatible mode
  • the UE 102 when the received RTP payload includes a switching request from the codec A incompatible mode to the codec A compatible mode, the UE 102 (for example, the RTP payload analyzing unit 706) transmits the switching request to an encoder (not shown). ) And the RTP payload generation unit 708. Thereby, the UE 102 determines to use the codec A compatible mode of the codec B for the data transmitted from the own device. That is, the UE 102 (RTP payload generation unit 708) stores the codec A compatible mode data received from the encoder in the payload format of the codec B and transmits it to the MSC / MGW 110.
  • the codec detection unit 804 detects the codec used by the UE 100 in the PS network and the codec used by the UE 100 in the CS network, and the RTP payload generation unit.
  • the codec used by the UE 100 in the PS network is a codec having a compatibility mode with the codec used by the UE 100 in the CS network
  • a codec of data transmitted from the UE 100 is displayed in the PS network.
  • the data for the UE 102 is generated by switching to the compatibility mode of the codec used in the above.
  • the MSC / MGW 110 transmits the codec A data transmitted from the UE 100.
  • the codec B is transmitted in the codec A compatible mode using the RTP payload format of the codec B.
  • the MSC / MGW 110 changes the codec between the UE 100 and the UE 102 by switching the codec data after the handover from the UE 100 to a part of the codec before the handover (one of the codec modes before the handover). Therefore, it is possible to prevent the call from being interrupted for a long time. Further, in MSC / MGW 110, by changing only the codec mode without changing the codec data between UE 100 and UE 102, it is possible to prevent the deterioration of call quality as in transcoding. Therefore, according to the present embodiment, even when the codec used by one of the communicating terminals is changed, the communication is performed without reducing the call quality and suppressing the time during which the call is interrupted. Can continue.
  • MSC / MGW 110 issues a request to switch to the compatible mode for data transmitted from the other terminal (UE 102). To the other terminal (UE 102). Then, the UE 102 transmits data in the codec A compatible mode in accordance with the request for switching to the codec A compatible mode from the MSC / MGW 110. Thereby, MSC / MGW110 and UE100 can handle the data (Codec A compatibility mode of Codec B) transmitted from UE102 as the data of Codec A.
  • the notification of the switching request from the codec A incompatible mode to the codec A compatible mode to the UE 102 is not necessarily included in the RTP payload from the MSC / MGW 110 to the UE 102.
  • the switching request may be notified to the UE 102 as an SDP offer shown in FIG. 10 in the SDP of INVITE with SDP-MGW transmitted from the MSC / MGW 110 in ST202 shown in FIG.
  • the switching request may be notified from the MSC / MGW 110 to the UE 102 using RTCP-APP described in Non-Patent Document 6.
  • the UE 102 determines that the data (transmission data) from the UE 102 should be encoded in the codec A compatible mode after receiving the data. Also good. In this case, the switching request is not necessary.
  • the ATCF / ATGW 320 shown in FIGS. 3 and 4 is merely an anchor point of data. Therefore, when the ATCF / ATGW 320 shown in FIGS. 3 and 4 forwards data from the UE 100 to the UE 102 or data from the UE 102 to the UE 100, the MSC / MGW 110 (FIG. 8), the UE 100, and the UE 102 (FIG. 7) The function is the same as that of the first embodiment (FIGS. 5 to 9). However, in MSC / MGW110, when notifying a codec switching request (switching request from codec A incompatible mode to codec A compatible mode) to UE 102, the INVITE with SDP of ST202 shown in FIG. 2 cannot be used. Is different from the first embodiment.
  • the ATCF / ATGW 320 holds information on the codec used by the UE 100 in Path B shown in FIG. 3 and the codec used in the Path A shown in FIG. 3 by the UE 100, or obtains the information from other nodes. Suppose that
  • the ATCF / ATGW 320 may Information of the codec used in the PS network can be notified to the MSC / MGW 110 as a reply message of the INVITE with SDP-MGW of ST302 shown in FIG.
  • the MSC / MGW 110 (RTP payload generation unit 808) can immediately specify the codec used by the UE 100 (handovered terminal) in the PS network. That is, the MSC / MGW 110 transmits the data transmitted from the UE 100 to the UE 102 as the codec A compatible mode using the RTP payload format of the codec B based on the codec used by the UE 100 (handovered terminal) in the PS network. Can be sent immediately. Similarly, the MSC / MGW 110 can immediately send a switching request to the UE 102 to the UE 102.
  • the present embodiment even in the case of the eSRVCC method, as in the first embodiment, even when the codec used by one of the communicating terminals is changed, the call quality is deteriorated. In addition, communication can be continued while suppressing the time during which the call is interrupted.
  • FIG. 11 is a block diagram showing a configuration of UEs 100 and 102 (terminals) according to the present embodiment.
  • the same components as those in the first embodiment (FIG. 7) are denoted by the same reference numerals, and description thereof is omitted.
  • the terminal location specifying unit 1100 specifies the network (PS network or CS network) to which the own device is connected, that is, the location of the own device. Thereby, the handover of the own device can be detected.
  • the terminal location specifying unit 1100 may determine the location of the own device from the base station ID of the connection destination (for example, e-nodeB or nodeB) or may be determined by establishing a connection in the PS core network.
  • the terminal location specifying unit 1100 specifies that the own device is connected to the PS network.
  • the UE100 which specified having connected with PS network in the terminal location specific
  • specification part 1100 switches the codec of UE100 from the codec A to the codec B (codec A incompatible mode). Then, the RTP payload generation unit 708 of the UE 100 generates an RTP payload using the codec B payload format. The RTP payload is transmitted to the UE 102 via the transmission unit 702.
  • the RTP payload analysis unit 706 of the UE 102 detects that the codec of the data received from the UE 100 has been switched from the codec A compatible mode to the codec A incompatible mode. Then, the RTP payload analysis unit 706 passes information and data indicating that the codec of the UE 100 has been switched to the decoder. Thereby, the decoder of UE102 decodes the data received from UE100 in the codec A incompatible mode of codec B.
  • the RTP payload analyzing unit 706 of the UE 102 passes this switching request to the encoder and the RTP payload generating unit 708. .
  • the UE 102 determines to use the codec A incompatible mode of the codec B for the data transmitted from the own device. That is, the RTP payload generation unit 708 of the UE 102 stores the codec A incompatible mode data passed from the encoder in the payload format of the codec B, and transmits it to the UE 100.
  • the notification of the switching request from the codec A compatible mode to the codec A incompatible mode to the UE 102 is not necessarily included in the RTP payload from the UE 100 to the UE 102.
  • the switching request may be included in the IMS message described in Non-Patent Document 8. Further, the switching request may be notified from the MSC / MGW 110 to the UE 102 using RTCP-APP described in Non-Patent Document 6.
  • the UE 102 When the UE 102 receives codec A incompatible mode data in the codec B RTP payload format, the UE 102 also encodes data (transmission data) from the UE 102 in the codec A incompatible mode after receiving the data. You may judge that you should. In this case, the switching request is not necessary.
  • the terminal changes the codec based on the current location of the own device, thereby causing a deterioration in call quality.
  • the communication can be continued while the time during which the call is interrupted is suppressed.
  • the ATCF / ATGW 320, the MSC / MGW 110, and the SCC AS / CSCF are described as one node.
  • the ATCF / ATGW 320, the MSC / MGW 110, and the SCC AS / CSCF may be configured by two or more separate nodes connected to each other by an interface. That is, the functions described above may be distributed to a plurality of nodes between the ATCF and ATGW, between the MSC and MGW, and between the SCC AS and CSCF.
  • 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.
  • the name used here is LSI, but it may also be called 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 is useful for continuing communication without causing deterioration in call quality even when the codec used by one of the communication terminals in communication is changed, and suppressing the time during which communication is interrupted. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

　通信中の端末の一方が使用していたコーデックが変更される場合でも、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができるネットワークノード。第１の網において通信を行う２つの端末のうち一方の端末が第１の網と異なる第２の網にハンドオーバした際に２つの端末間のデータを転送するＭＳＣ／ＭＧＷ（１１０）であって、コーデック検出部（８０４）は一方の端末が第１の網で使用していた第１のコーデック、及び、一方の端末が第２の網で使用する第２のコーデックを検出し、ＲＴＰペイロード生成部（８０８）は第１のコーデックが第２のコーデックとの間の互換モードを有するコーデックである場合、一方の端末から送信されるデータのコーデックを、第１のコーデックの互換モードに切り替えることにより、他方の端末向けのデータを生成し、送信部（８０２）は他方の端末向けのデータを、他方の端末へ送信する。

Description

ネットワークノード及び通信方法
　本発明は、移動通信方式で用いられるコーデック変更を行うネットワークノード及び通信方法に関する。
　従来、３ＧＰＰ（Third Generation Partnership Project）の移動通信方式における音声通話は、３ＧＰＰの回線交換（ＣＳ：Circuit Switching）網を用いて行われていた。近年では、３ＧＰＰのパケット交換（ＰＳ：Packet Switching）網を用いた音声通話であるＶｏＬＴＥ（Voice over Long Term Evolution）サービスが行われつつある。
　しかし、ＶｏＬＴＥサービスが受けられるエリアは当面の間限られる。このため、ＶｏＬＴＥによる音声通話（以下、ＶｏＬＴＥ通話という）中にＶｏＬＴＥサービスエリアの外に出た場合、従来の回線交換方式を用いた通話に切り替える必要がある。この切替を可能にする技術として、非特許文献１に記載のＳＲＶＣＣ（Single Radio Voice Call Continuity）がある。以下、図１及び図２を用いて、ＳＲＶＣＣによるハンドオーバの動作について説明する。
　図１は３ＧＰＰの移動通信ネットワーク構成の一部を示す。図１に示す移動通信ネットワークは、ｅ－ＵＴＲＡＮ（evolved Universal Terrestrial Radio Access Network）、ｅ－ＵＴＲＡＮの基地局（ｅ－ｎｏｄｅＢ）、ＰＳ網、ＣＳ網、ＣＳ網の基地局サブシステム、及びＩＭＳ（IP Multimedia Subsystem）から構成される。
　具体的には、図１において、ｅ－ＵＴＲＡＮは、ＶｏＬＴＥサービスを提供可能な無線アクセス網である。ＰＳ網は、ＶｏＬＴＥサービスを提供し、Ｐ－ＧＷ（Packet Data Network Gateway）、Ｓ－ＧＷ（Serving Gateway）及びＭＭＥ（Mobility Management Entity）から構成される。ＣＳ網は、ＭＳＣ（Mobile Switching Center）、ＭＧＷ（Media GateWay）から構成される。ＣＳ網の基地局サブシステムは、ＲＮＣ（Radio Network Controller）及びｎｏｄｅＢから構成される。ＩＭＳは、呼制御等を行い、ＣＳＣＦ（Call Session Control Function）及びＳＣＣ　ＡＳ（Service Centralization and Continuity Application Server）から構成される。なお、図１及び図２では、ＭＳＣとＭＧＷとを一つのノード（ＭＳＣ／ＭＧＷ１１０）として表しているが、これらは別々のノードとして表してもよい。
　図１において、移動通信端末（ＵＥ：User Equipment）であるＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。つまり、ＵＥ１００とＵＥ１０２とでＶｏＬＴＥ通話が行われているとする。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。
　図１の実線で示されたＰａｔｈ　Ａ、Ｐａｔｈ　Ｂ及びＰａｔｈ　Ｃは、通話データが通る経路を示す。また、図１の破線で示された２００、２０２、２０４及び２０６は、ＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。
　図２は、ＳＲＶＣＣハンドオーバ処理の動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ－ＵＴＲＡＮ）にそれぞれ接続されており、ＵＥ１００とＵＥ１０２との間の通話データはＰａｔｈ　Ａを通って送受信されている。ＵＥ１００がｅ－ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ－ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ１１０経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図１に示すシグナリング２００。図２に示すステップ（以下、「ＳＴ」という）２００）。ＳＴ２００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷ１１０との間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ－ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令が出される。
　ＳＴ２００の処理と同時に、ＭＳＣ／ＭＧＷ１１０は、ＣＳＣＦ／ＳＣＣ　ＡＳ経由でＵＥ１０２とシグナリングをやり取りする（図１に示すシグナリング２０２。図２に示すＳＴ２０２）。これにより、ＵＥ１０２の通話データの送受信先を、ＵＥ１００からＭＳＣ／ＭＧＷ１１０に切り替えるよう命令が出され、Ｐａｔｈ　Ｂが確立される。
　ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷ１１０とシグナリングをやり取りする（図１に示すシグナリング２０４。図２に示すＳＴ２０４）。これにより、Ｐａｔｈ　Ｃが確立される。
　Ｐａｔｈ　Ｃ確立後、ＭＳＣ／ＭＧＷ１１０は、ＭＭＥ経由でＰ－ＧＷ／Ｓ－ＧＷとシグナリングをやり取りする（図１に示すシグナリング２０６。図２に示すＳＴ２０６）。これにより、Ｐａｔｈ　Ａは削除される。
　以上、ＳＲＶＣＣハンドオーバの動作について説明した。
　また、ＳＲＶＣＣを改良し、データ経路切替にかかる時間を短縮する方式として、非特許文献３に記載の、ＡＴＣＦ（Access Transfer Control Function）エンハンスメントを用いたＳＲＶＣＣ方式（ｅＳＲＶＣＣ：enhanced-SRVCC）がある。このｅＳＲＶＣＣの動作の一例について、以下、図３及び図４を用いて説明する。
　図３は、ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワーク構成の一部を示す。図３に示す移動通信ネットワークは、図１と同様、ｅ－ＵＴＲＡＮ、ｅ－ｎｏｄｅＢ、ＰＳ網、ＣＳ網、ＣＳ網の基地局サブシステム、及びＩＭＳから構成される。ここでＩＭＳには、ＣＳＣＦ及びＳＣＣ　ＡＳの他、ＡＴＣＦ（Access Transfer Control Function）及びＡＴＧＷ（Access Transfer GateWay）が存在する。なお、図３及び図４では、ＡＴＣＦとＡＴＧＷとを一つのノード（ＡＴＣＦ／ＡＴＧＷ３２０）として表しているが、これらは別々のノードとして表してもよい。
　図３において、ＵＥ１００及びＵＥ１０２は、最初ＰＳ網にそれぞれ接続されているとする（ただし、ＵＥ１０２側の無線アクセス網、基地局及びＰＳ網は図示せず）。つまり、ＵＥ１００とＵＥ１０２とでＶｏＬＴＥ通話が行われているとする。このとき、通話の途中でＵＥ１００がＣＳ網にハンドオーバ（ＨＯ：Hand Over）することを仮定する。
　図３の実線で示されたＰａｔｈ　Ａ、Ｐａｔｈ　Ｂ、Ｐａｔｈ　Ｃ及びＰａｔｈ　Ｄは、通話データが通る経路を示す。また、図３の破線で示された３００、３０２、３０４及び３０６は、ｅＳＲＶＣＣハンドオーバ処理におけるシグナリングが通る経路を示す。
　図４は、ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャートである。ＵＥ１００及びＵＥ１０２は最初ＰＳ網（ｅ－ＵＴＲＡＮ）にそれぞれ接続されている。ｅＳＲＶＣＣハンドオーバを実現するシステムでは、ＡＴＣＦ／ＡＴＧＷ３２０において、ＡＴＣＦはＩＭＳのシグナリング（ＩＭＳシグナリング）をアンカーし、ＡＴＧＷは通話データをアンカーする。つまり、ＵＥ１００とＵＥ１０２との間の通話開始時において、通話開始のＩＭＳシグナリングはＡＴＣＦで中継され、ＡＴＣＦがＡＴＧＷでの通話データのアンカーが必要と判断した場合、通話データのアンカーポイントとしてＡＴＧＷが割り当てられる。これにより、ＵＥ１００とＵＥ１０２との間の通話データは、Ｐａｔｈ　Ａ及びＰａｔｈ　Ｂを通って送受信される。
　ＵＥ１００がｅ－ＵＴＲＡＮのカバーエリアから遠ざかろうとすると、ｅ－ｎｏｄｅＢは、これを検知し、ＭＭＥ、ＭＳＣ／ＭＧＷ１１０経由でＲＮＣ／ｎｏｄｅＢとの間でシグナリングをやり取りする（図３に示すシグナリング３００。図４に示すＳＴ３００）。ＳＴ３００において、ｎｏｄｅＢとＭＳＣ／ＭＧＷ１１０との間にＣＳ網でのデータ経路が準備され、準備が終わると、ＭＭＥからｅ－ｎｏｄｅＢ経由で、ＵＥ１００に対し、ＵＴＲＡＮ（ＣＳ網）側にハンドオーバするよう命令が出される。
　ＳＴ３００の処理と同時に、ＭＳＣ／ＭＧＷ１１０は、ＡＴＣＦにシグナリングを送る。これによりＡＴＣＦからＡＴＧＷに経路切替の指示が出され、ＡＴＧＷの通話データ送受信先がＵＥ１００からＭＳＣ／ＭＧＷ１１０に切り替わる（図３に示すシグナリング３０２。図４に示すＳＴ３０２）。すなわち、Ｐａｔｈ　Ｃが確立される。また、ＡＴＧＷへの経路切替処理が完了すると、ＡＴＣＦは、ＳＣＣ－ＡＳに通知シグナリングを送信する（図３に示すシグナリング３０２。図４に示すＳＴ３０２）。
　ＵＥ１００は、ＵＴＲＡＮにハンドオーバした後、ＲＮＣ／ｎｏｄｅＢ経由でＭＳＣ／ＭＧＷ１１０とシグナリングをやり取りする（図３に示すシグナリング３０４。図４に示すＳＴ３０４）。これにより、Ｐａｔｈ　Ｄが確立される。
　Ｐａｔｈ　Ｄ確立後、ＭＳＣ／ＭＧＷ１１０は、ＭＭＥ経由でＰ－ＧＷ／Ｓ－ＧＷとシグナリングをやり取りする（図３に示すシグナリング３０６。図４に示すＳＴ３０６）。これにより、Ｐａｔｈ　Ｂは削除される。
　以上、ｅＳＲＶＣＣハンドオーバの動作について説明した。
　ＣＳ網で利用される音声コーデックとして、広帯域（ＷＢ：Wideband）コーデックであるＡＭＲ－ＷＢ（Adaptive Multi-Rate Wideband）コーデックがある。ＡＭＲ－ＷＢは、パケット交換方式で利用可能であるため、ＰＳ網（ＶｏＬＴＥ）での利用も考えられている。
　また、例えば、非特許文献４に記載のＥＶＳ（Enhanced Voice Service）のように、ＰＳ網（ＶｏＬＴＥ）で利用される、ＡＭＲ－ＷＢ以外の他のコーデックとして、ＡＭＲ－ＷＢ互換モードをサポートするコーデックもある。ＡＭＲ－ＷＢ互換モードは、通常ＡＭＲ－ＷＢコーデックをサポートするレガシー端末との間でＡＭＲ－ＷＢコーデックとして使用されることを想定している。このため、ＰＳ網（ＶｏＬＴＥ）で当該コーデックが利用される際には、非特許文献２に記載のＡＭＲ－ＷＢコーデックのＲＴＰペイロードフォーマットが用いられることが考えられる。
　なお、従来技術において、狭帯域（ＮＢ：Narrowband）コーデックとは、８ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。なお、狭帯域コーデックでは、一般的に３００Ｈｚ～３．４ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０～４ｋＨｚの範囲内であればよい。また、広帯域コーデックとは、１６ｋＨｚでサンプリングされたデジタル音響信号の符号化及び復号処理を行うコーデックである。なお、広帯域コーデックでは、一般的に５０Ｈｚ～７ｋＨｚの周波数帯域を有するが、周波数帯域はこれに限らず０～８ｋＨｚの範囲内であればよい。また、超広帯域（ＳＷＢ：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" 3GPP TS22.813 v10.0.0 "Study of Use Cases and Requirements for Enhanced Voice Codecs for the Evolved Packet System (EPS)" Takashi Koshimizu and Katsutoshi Noshida, "Audio Viedo Callof Single Radio Voice Call Continuity", 2011年電子情報通信学会総合大会，B-6-77 3GPP TS26.114 v10.0.0 "IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction" G. Zorn (Ed), "RTP Payload Format for G.718 Speech/Audio," November 15, 2011, work in progress 3GPP TR23.885 v11.0.0 "Feasibility Study of Single Radio Voice Call Continuity (SRVCC) from UTRAN/GERAN to E-UTRAN/HSPA"
　図１又は図３において、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバした際、ＰＳ網で使用していたコーデックがＣＳ網でサポートされていない場合には、ＵＥ１００で使用されるコーデックは、ＣＳ網でサポートされているコーデックに変更される。ＵＥ１００のコーデックに変更が生じた場合、ＵＥ１００とＵＥ１０２との通話継続を可能にするためには、次の２つの方法が考えられる。１つ目の方法は、ＭＳＣ／ＭＧＷ又はＡＴＣＦ／ＡＴＧＷにおいてトランスコーディングを行う方法である。２つ目の方法は、ＵＥ１０２で使用されるコーデックをＵＥ１００の変更後のコーデックと同じものに変更する方法である。
　前者のトランスコーディングを行う方法では、トランスコーディングによる通話品質の劣化が生じてしまう。
　一方、後者のコーデックを変更する方法では、トランスコーディングを行う方法のような通話品質の劣化は生じないものの、ＵＥ１０２のコーデックを変更するためのシグナリングに時間がかかり、通話が途切れる時間が長くなるので好ましくない。更に、ｅＳＲＶＣＣハンドオーバでは、ＵＥ１００のハンドオーバの際の経路切替のためのシグナリングがＡＴＣＦで終端するため、ＵＥ１０２のコーデックを変更するためのシグナリングを送ることすらできない。すなわち、ｅＳＲＶＣＣハンドオーバでは、既存のシグナリングを使ってＵＥ１０２のコーデックを変更することができない。
　本発明の目的は、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができるネットワークノード及び通信方法を提供することである。
　本発明の一態様に係るネットワークノードは、第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末間のデータを転送するネットワークノードであって、前記一方の端末が前記第１の網で使用していた第１のコーデック、及び、前記一方の端末が前記第２の網で使用する第２のコーデックを検出する検出手段と、前記第１のコーデックが前記第２のコーデックとの間の互換モードを有するコーデックである場合、前記一方の端末から送信されるデータのコーデックを、前記第１のコーデックの前記互換モードに切り替えることにより、他方の端末向けのデータを生成する生成手段と、前記他方の端末向けのデータを、前記他方の端末へ送信する送信手段と、を具備する構成を採る。
　本発明の一態様に係る通信方法は、第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末間のデータを転送する通信方法であって、前記一方の端末が前記第１の網で使用していた第１のコーデック、及び、前記一方の端末が前記第２の網で使用する第２のコーデックを検出し、前記第１のコーデックが前記第２のコーデックとの間の互換モードを有するコーデックである場合、前記一方の端末から送信されるデータのコーデックを、前記第１のコーデックの前記互換モードに切り替えることにより、他方の端末向けのデータを生成し、前記他方の端末向けのデータを、前記他方の端末へ送信する。
　本発明によれば、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができる。
３ＧＰＰの移動通信ネットワークの一部を示す構成図 ＳＲＶＣＣハンドオーバの動作を示すシーケンスチャート ｅＳＲＶＣＣを可能にする、３ＧＰＰの移動通信ネットワークの一部を示す構成図 ｅＳＲＶＣＣハンドオーバの動作を示すシーケンスチャート 本発明の実施の形態１に係るＲＴＰペイロードフォーマットの一例を示す図 本発明の実施の形態１に係るＳＤＰオファー及びＳＤＰアンサーの一例を示す図 本発明の実施の形態１に係る端末（ＵＥ）の構成を示すブロック図 本発明の実施の形態１に係るネットワークノード（ＭＳＣ／ＭＧＷ）の構成を示すブロック図 本発明の実施の形態１に係るＭＳＣ／ＭＧＷにおけるコーデック切替処理の一例を示すフローチャート 本発明の実施の形態１に係るコーデック切替要求の通知例を示す図 本発明の実施の形態３に係る端末（ＵＥ）の構成を示すブロック図
　以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
　以下の説明では、「帯域幅」とはコーデックの入出力となる信号の帯域幅のことを指す。
　また、以下の説明では、ＰＳ網及びＣＳ網の双方において利用可能なコーデックを「コーデックＡ」と表す。コーデックＡは、専用のペイロードフォーマットを持つ。コーデックＡは、例えば、ＡＭＲ－ＷＢ又はＡＭＲ－ＮＢである。
　また、ＰＳ網において利用可能なコーデックを「コーデックＢ」と表す。コーデックＢは、コーデックＡに対する、非互換モード（コーデックＡ非互換モード）と互換モード（コーデックＡ互換モード）とを有する。ただし、コーデックＢはＣＳ網で利用されてもよい。コーデックＢは、例えば、ＥＶＳ又は非特許文献７に記載のＧ．７１８である。
　（実施の形態１）
　図５は、コーデックＢのペイロードフォーマット（ＲＴＰペイロードフォーマット）の一例を示す。図５に示すように、ペイロードフォーマットは、データ部とヘッダ部とにより構成される。データ部にはエンコーダによりエンコードされたデータが含まれ、ヘッダ部にはデコーダがデータ部のデータをデコードするために必要な情報が含まれる。
　本実施の形態におけるコーデックＢのペイロードフォーマットは、データ部にコーデックＡ非互換モードのデータが含まれるのか、コーデックＡ互換モードのデータが含まれるのかをペイロード受信側で識別できる構成を持つ。例えば、図５に示すように、ヘッダ部には、「コーデックタイプ」フィールドと「ビットレート」フィールドが含まれる。「コーデックタイプ」には、コーデックＡ非互換モード又はコーデックＡ互換モードのいずれであるかを示す情報が含まれる。「ビットレート」には、コーデックＡ非互換モード、コーデックＡ互換モードのそれぞれでサポートしているビットレートのうち、どのビットレートでエンコードされたデータであるかを示す情報が含まれる。
　また、図５に示すように、上記フィールドの他に、ペイロード受信側である相手端末に対してコーデックタイプ又はビットレートの切替要求指示を行うフィールド（「コーデックタイプ・ビットレート切替要求」フィールド）を含んでもよい。なお、このフィールドは、フレーム毎に含まれる必要はなく、必要な時にだけ含まれてもよい。
　なお、図５に示すコーデックＢのペイロードフォーマットにおいて、データ部にコーデックＡ非互換モードのデータが含まれるのか、コーデックＡ互換モードのデータが含まれるのかをペイロード受信側で識別できる構成を取るためのフィールド（「コーデックタイプ」フィールド、「ビットレート」フィールド）、及び、相手端末に対して、コーデックタイプ又はビットレートの切替要求指示を行うフィールド（「コーデックタイプ・ビットレート切替要求」フィールド）を、ヘッダ部に明示的に含める方法を示した。しかし、必ずしも図５に示す方法でなくてもよい。また、図５に示すペイロードフォーマットの一例では、ペイロードフォーマットがヘッダ部とデータ部とから構成される例を示したが、ヘッダ部が無くてもペイロードを受け取った受信側の端末が正しくデータをデコードできる場合には、ペイロードフォーマットにおいてヘッダ部は無くてもよい。
　また、コーデックＢのペイロードフォーマットは図５に示す一例に限らず、例えば、非特許文献７に記載のＧ．７１８のペイロードフォーマットのように、各レイヤの組み合わせ（ビットレート相当）が、別々の値として記述されていてもよい。
　次に、図６は、通話開始時のセッション折衝において端末間でやり取りされる、ＳＤＰ（Session Description Protocol）オファー及びＳＤＰアンサーの一例を示す。
　ここでは、通話を行う双方のＵＥがコーデックＢをサポートしており、かつ、通話開始時に共にＰＳ網に接続していると仮定する。
　図６に示すように、コーデックＢをサポートするＵＥは、コーデックＡをサポートしていない場合においても、コーデックＡ及びコーデックＢをＳＤＰオファーに記述する。これは、相手端末が、コーデックＡをサポートしているがコーデックＢをサポートしていなかった場合、コーデック折衝においてコーデックＡを選択し、コーデックＢのコーデックＡ互換モードをコーデックＡのＲＴＰペイロードフォーマットを用いて使用する事を可能にするためである。図６では、ＳＤＰオファーを受け取ったＵＥは、コーデックＢを選択し、選択したコーデックＢをＳＤＰアンサーに記述する。
　なお、このＳＤＰオファー及びＳＤＰアンサーの中に、コーデックＢを選択した場合に優先されるモード（コーデックＡ非互換モード又はコーデックＡ互換モード、ビットレート、帯域幅等）が記述されていてもよい。優先されるモードは、通信サービスを行うオペレータによって予め決められ、ソフトウェアの形式等でＵＥに組み込まれていてもよい。本実施の形態では、コーデックＢが選択された場合、コーデックＡ非互換モードを優先モードとして使用すると仮定する。
　次に、本実施の形態に係る移動通信ネットワーク（図１）について説明する。
　まず、図１に示すＵＥ１００，１０２について説明する。
　図７は、本実施の形態に係るＵＥ１００，１０２（端末）の構成を示すブロック図である。ＵＥ１００，１０２は、受信部７００、送信部７０２、コーデック折衝部７０４、ＲＴＰペイロード解析部７０６、ＲＴＰペイロード生成部７０８及びコーデック通知部７１０を有して構成される。
　図７に示すＵＥ１００，１０２において、受信部７００は、通信データ（ＲＴＰペイロードを含む）及びシグナリング等を受信する。例えば、受信部７００は、ＭＳＣ／ＭＧＷ１１０から送信されるＲＴＰペイロード（例えば図５参照）を受信すると、受信したＲＴＰペイロードをＲＴＰペイロード解析部７０６に出力する。
　送信部７０２は、通信データ（ＲＴＰペイロードを含む）及びシグナリング等を送信する。
　コーデック折衝部７０４は、端末（ＵＥ１００，ＵＥ１０２）間の通信に使用するコーデックを折衝する。具体的には、コーデック折衝部７０４は、ＳＤＰオファー又はＳＤＰアンサーを作成し（例えば図６参照）、コーデック折衝を行う。この際、コーデック折衝部７０４は、ＳＤＰオファーを作成する際、前述の通り、端末がコーデックＢをサポートするがコーデックＡをサポートしていない場合においても、図６のようにコーデックＡをＳＤＰオファーに含める。またコーデック折衝部７０４は、折衝においてコーデックＢが選択された場合、前述のようにＳＤＰオファー及びアンサーの中に記述された情報、又はあらかじめソフトウェア等に組み込まれた情報に従い、優先されるモード（コーデックＡ非互換モード又はコーデックＡ互換モード、ビットレート、帯域幅等）を選択し、ＲＴＰペイロード生成部７０８に出力する。
　ＲＴＰペイロード解析部７０６は、受信部７００から受け取ったＲＴＰペイロードのヘッダ部を解析して、ＲＴＰペイロードのデータ部に含まれるデータに関する情報（例えば、コーデックタイプ、ビットレート等）を特定する。ＲＴＰペイロード解析部７０６は、特定した情報及びデータ部に含まれるデータをデコーダ（図示せず）に出力する。また、ＲＴＰペイロード解析部７０６は、受信部７００から受け取ったＲＴＰペイロードに「コーデックタイプ・ビットレート切替要求」の指示が含まれる場合には、当該指示をエンコーダ（図示せず）及びＲＴＰペイロード生成部７０８に出力する。エンコーダは、ＲＴＰペイロード解析部７０６からの情報及び指示に基づいてデータをエンコードする。
　ＲＴＰペイロード生成部７０８は、エンコーダから受け取ったデータ及びコーデック折衝部７０４から受け取った当該データに関する情報（例えば、コーデックタイプ、ビットレート等）を含むＲＴＰペイロード（例えば、図５参照）を生成する。この際、ＲＴＰペイロード生成部７０８は、ＲＴＰペイロード解析部７０６から、「コーデックタイプ・ビットレート切替要求」の指示が入力される場合には、当該指示に基づいてＲＴＰペイロードを生成する。生成されたＲＴＰペイロードは、送信部７０２を介して送信される。
　コーデック通知部７１０は、自機がＰＳ網からＣＳ網へハンドオーバする際、自機がＰＳ網で使用しているコーデックをＰＳ網のネットワークノード（例えばＭＭＥ等）に通知する。通知されたコーデックは、ＰＳ網のネットワークノード（ＭＭＥ）を介して、ＭＳＣ／ＭＧＷ１１０に通知される。
　次いで、図１に示すＭＳＣ／ＭＧＷ１１０について説明する。図８は、本実施の形態に係るＭＳＣ／ＭＧＷ１１０（ネットワークノード）の構成を示すブロック図である。ＭＳＣ／ＭＧＷ１１０は、受信部８００、送信部８０２、コーデック検出部８０４、コーデック折衝部８０６、ＲＴＰペイロード生成部８０８及びＲＴＰペイロード解析部８１０を有して構成される。
　図８に示すＭＳＣ／ＭＧＷ１１０において、受信部８００は、通信データ（ＲＴＰペイロードを含む）、シグナリング等を受信する。例えば、受信部８００は、ＵＥ１０２から送信されるＲＴＰペイロード（例えば図５参照）を受信すると、受信したＲＴＰペイロードをＲＴＰペイロード解析部８１０に出力する。
　送信部８０２は、通信データ（ＲＴＰペイロードを含む）、シグナリング等を送信する。
　コーデック検出部８０４は、ＰＳ網からＣＳ網にハンドオーバした端末（図１ではＵＥ１００）がＣＳ網で使用するコーデックを検出する。また、コーデック検出部８０４は、ＰＳ網からＣＳ網にハンドオーバした端末（図１ではＵＥ１００）がＰＳ網で使用していたコーデックを検出する。端末（ＵＥ１００）がＰＳ網で使用していたコーデックを検出する方法としては、非特許文献５に開示されているように、ＵＥ１００（コーデック通知部７１０）がＣＳ網にハンドオーバする際にＰＳ網のネットワークノード（ＭＭＥなど）から通知される方法でもよい。または、端末（ＵＥ１００）がＰＳ網で使用していたコーデックを検出する方法としては、例えば、ＳＣＣ　ＡＳ等の他のネットワークノードから取得する方法でもよい。また、端末（ＵＥ１００）がＣＳ網で使用しているコーデックを検出する方法としては、ＵＥ１００がＣＳ網にハンドオーバした際に、ＵＥ１００とＣＳ網内のネットワークノード（ＲＮＣ及びＭＳＣ／ＭＧＷ１１０）との間で送受信されるシグナリングにより折衝された情報を利用する方法がある。コーデック検出部８０４は、コーデックの検出結果をＲＴＰペイロード生成部８０８に出力する。
　コーデック折衝部８０６は、例えば、ＲＴＰペイロード生成部８０８からの指示に従って、ＵＥとの間で使用するコーデックを折衝する。例えば、コーデック折衝部８０６は、ＰＳ網からＣＳ網にハンドオーバした端末（図１ではＵＥ１００）の通信相手である端末（図１ではＵＥ１０２）との間で使用するコーデックを折衝（再折衝）する。
　ＲＴＰペイロード生成部８０８は、コーデック検出部８０４から入力されるコーデックの検出結果に基づいて、端末（図１ではＵＥ１００）から受け取ったデータを用いて、当該端末の通信相手（図１ではＵＥ１０２）向けのデータ（ＲＴＰペイロード）を生成する。例えば、ＲＴＰペイロード生成部８０８は、ＰＳ網からＣＳ網へハンドオーバした端末がＣＳ網で使用するコーデックがコーデックＡであり、当該端末がＰＳ網で使用していたコーデックがコーデックＢである場合、当該端末から受け取ったデータ（コーデックＡのデータ）のコーデックを、コーデックＢのコーデックＡ互換モードに切り替える。すなわち、ＭＳＣ／ＭＧＷ１１０は、当該端末から受け取ったコーデックＡのデータを、コーデックＢのＲＴＰペイロードフォーマット（図５参照）を用いて、コーデックＢのコーデックＡ互換モードとして、送信部８０２を介して送信する。
　また、コーデック検出部８０４から入力されるコーデックの検出結果が上記以外の場合には、ＲＴＰペイロード生成部８０８は、例えば、コーデック折衝部８０６に対して、受け取ったデータの送信先である通信相手（図１ではＵＥ１０２）との間のコーデックの折衝（再折衝）を指示する。そして、ＲＴＰペイロード生成部８０８は、ハンドオーバした端末から受け取った通信データを折衝結果に基づいて必要であればトランスコーディングし、折衝結果に基づくコーデックモードに切り替える。コーデック切替後のデータ（生成されたＲＴＰペイロード）は、送信部８０２を介して送信される。
　ＲＴＰペイロード解析部８１０は、端末（ＵＥ１０２）から送信されるＲＴＰペイロードのヘッダ部を解析して、ＲＴＰペイロードのデータ部に含まれるデータに関する情報（例えば、コーデックタイプ、ビットレート等）を特定する。ＲＴＰペイロード解析部８１０は、特定した情報をコーデック検出部８０４に出力する。
　次いで、図９を用いて、ＭＳＣ／ＭＧＷ１１０（図８）におけるコーデック処理の詳細について説明する。なお、ここでは、図１に示すように、ＵＥ１００とＵＥ１０２とが共にＰＳ網に接続されて通話を行っている途中に、ＵＥ１００がＰＳ網からＣＳ網にハンドオーバした場合について説明する。すなわち、ＭＳＣ／ＭＧＷ１１０は、ＰＳ網において通信を行う２つの端末（ＵＥ１００，１０２）のうち一方のＵＥ１００がＣＳ網にハンドオーバした際に、２つの端末間のデータを転送するネットワークノードである。
　図９に示すＳＴ９００において、ＲＴＰペイロード生成部８０８は、コーデック検出部８０４での検出結果に基づいて、ＵＥ１００がＣＳ網で使用するコーデックがコーデックＡであるか否かを判断する。
　ＵＥ１００がＣＳ網で使用するコーデックがコーデックＡである場合（ＳＴ９００：ＹＥＳ）、ＳＴ９０２において、ＲＴＰペイロード生成部８０８は、コーデック検出部８０４での検出結果に基づいて、ＵＥ１００がＰＳ網で（ハンドオーバ前に）使用していたコーデックがコーデックＢであるか否かを判断する。
　ＵＥ１００がＰＳ網で使用していたコーデックがコーデックＢである場合（ＳＴ９０２：ＹＥＳ）、ＳＴ９０４において、ＲＴＰペイロード生成部８０８は、ＵＥ１００から送信されたデータ（コーデックＡ）のコーデックを、コーデックＢのコーデックＡ互換モードに切り替える。つまり、ＲＴＰペイロード生成部８０８は、ＵＥ１００から送信されたコーデックＡのデータを、コーデックＢのＲＴＰペイロードフォーマットを用いてコーデックＢのコーデックＡ互換モードとして、送信部８０２を介してＵＥ１０２へ送信する。
　これにより、コーデックＢを使用するＵＥ１０２は、ＭＳＣ／ＭＧＷ１１０からＵＥ１０２へ送信されるデータを、コーデックＢのデータ（コーデックＢのコーデックＡ互換モード）として扱うことが可能となる。
　一方、ＵＥ１００がＣＳ網で使用するコーデックがコーデックＡではない場合（ＳＴ９００：ＮＯ）、又は、ＵＥ１００がＰＳ網で使用していたコーデックがコーデックＢではない場合（ＳＴ９０２：ＮＯ）、ＳＴ９０６において、コーデック折衝部８０６は、ＵＥ１０２との間でセッション再折衝を行って、コーデックを決定する。そして、ＲＴＰペイロード生成部８０８は、決定されたコーデックのＲＴＰペイロードを生成する。
　または、ＳＴ９０６において、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００から送信されたデータに対してトランスコーディングを行い、トランスコーディング後のデータ（ＵＥ１０２向けのデータ）をＵＥ１０２に送信してもよい。
　このようにして、ＭＳＣ／ＭＧＷ１１０は、一方のＵＥのコーデックの変更が検出された場合、当該ＵＥの変更後のコーデックと、当該ＵＥの変更前のコーデックとに基づいて、他方のＵＥ向けデータのコーデックを切り替えることが可能であるか否かを判断する。
　次に、本実施の形態におけるＵＥ１００，１０２（図７）、及び、ＭＳＣ／ＭＧＷ１１０（図８）の動作の一例について説明する。
　以下の説明では、図１及び図２において、ＵＥ１００及びＵＥ１０２の双方ともにＰＳ網に接続され、通話を開始する。ここでは、ＵＥ１００からＵＥ１０２へ発呼を行うと仮定する。
　通話開始の際、ＵＥ１００とＵＥ１０２との間で使用するコーデックの折衝が行われる。例えば、ＵＥ１００（コーデック折衝部７０４）は、ＳＤＰオファー（例えば図６参照）を生成し、ＵＥ１０２に送信する。これに対して、ＵＥ１０２（コーデック折衝部７０４）は、ＳＤＰアンサー（例えば、図６参照。図６ではコーデックＢを選択）を生成し、ＵＥ１００に送信する。この通話開始に伴う一例の動作が完了すると、ＵＥ１００，１０２は、コーデックＢのコーデックＡ非互換モード（コーデックＢを選択した場合に優先されるモード）を用いて通話を行う（図２：Speech Session over PS）。
　次いで、図１に示すように、ＵＥ１００がＰＳ網からＣＳ網へハンドオーバする（図２に示すＳＴ２００及びＳＴ２０４）。ここでは、ＵＥ１００がＣＳ網で使用するコーデックをコーデックＡとする。
　ＵＥ１００のハンドオーバ処理と同時に、ＭＳＣ／ＭＧＷ１１０（コーデック検出部８０４）は、ＵＥ１００がＣＳ網にハンドオーバした際に使用するコーデックを検出する。また、ＭＳＣ／ＭＧＷ１１０（コーデック検出部８０４）は、ＵＥ１００がＰＳ網で使用していたコーデックを検出する。上述したように、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００がＣＳ網で使用するコーデックがコーデックＡであり、ＵＥ１００がＰＳ網で使用していたコーデックがコーデックＢであることを検出する（つまり、図９に示すＳＴ９００：ＹＥＳかつＳＴ９０２：ＹＥＳ）。
　この場合、ＭＳＣ／ＭＧＷ１１０（ＲＴＰペイロード生成部８０８）は、ＵＥ１００から送信されたデータ（コーデックＡ）のコーデックを、コーデックＢのコーデックＡ互換モードに切り替えることにより、ＵＥ１０２向けのＲＴＰペイロードを生成する。つまり、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００から送信されたコーデックＡのデータを、コーデックＢのＲＴＰペイロードフォーマットを用いて、コーデックＢのコーデックＡ互換モードとしてＵＥ１０２へ送信する。
　また、この際、ＭＳＣ／ＭＧＷ１１０は、ＲＴＰペイロード生成部８０８においてＵＥ１００から送信されるデータのコーデックが切り替えられた場合、コーデックＡ非互換モードからコーデックＡ互換モードへの切替要求を、ＵＥ１００の通信相手であるＵＥ１０２へ送信してもよい。例えば、ＭＳＣ／ＭＧＷ１１０（ＲＴＰペイロード生成部８０８）は、コーデックＢのＲＴＰペイロードフォーマット（例えば図５参照）において、コーデックＡ非互換モードからコーデックＡ互換モードへの切替指示をヘッダ部（「コーデックタイプ・ビットレート切替要求」フィールド）に含めてもよい。
　一方、ＵＥ１０２（ＲＴＰペイロード解析部７０６）は、ＭＳＣ／ＭＧＷ１１０から受け取るデータに含まれる情報（ＲＴＰペイロードのヘッダ部の情報）から、ＲＴＰペイロードのデータ部に含まれるデータがコーデックＡ（コーデックＡ互換モードとして扱うことができるコーデック）であることを判断し、当該情報及びデータをデコーダに渡す。これにより、ＵＥ１０２のデコーダは、受け取ったデータのコーデックがコーデックＡ（コーデックＢのコーデックＡ互換モード）であると認識して、当該データをデコードする。
　また、ＵＥ１０２（例えば、ＲＴＰペイロード解析部７０６）は、受信したＲＴＰペイロードに、コーデックＡ非互換モードからコーデックＡ互換モードへの切替要求が含まれている場合、当該切替要求をエンコーダ（図示せず）及びＲＴＰペイロード生成部７０８に出力する。これにより、ＵＥ１０２は、自機から送信するデータに対してもコーデックＢのコーデックＡ互換モードを用いることを決定する。すなわち、ＵＥ１０２（ＲＴＰペイロード生成部７０８）は、エンコーダより受け取ったコーデックＡ互換モードのデータを、コーデックＢのペイロードフォーマットに格納して、ＭＳＣ/ＭＧＷ１１０へ送信する。
　このように、本実施の形態では、ＭＳＣ／ＭＧＷ１１０において、コーデック検出部８０４は、ＵＥ１００がＰＳ網で使用していたコーデック、及び、ＵＥ１００がＣＳ網で使用するコーデックを検出し、ＲＴＰペイロード生成部８０８は、ＵＥ１００がＰＳ網で使用していたコーデックが、ＵＥ１００がＣＳ網で使用するコーデックとの間の互換モードを有するコーデックである場合、ＵＥ１００から送信されるデータのコーデックを、ＵＥ１００がＰＳ網で使用していたコーデックの互換モードに切り替えることにより、ＵＥ１０２向けのデータを生成する。すなわち、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００がＰＳ網で使用していたコーデックが、ＵＥ１００がＣＳ網で使用するコーデックとの間の互換モードを有するコーデックである場合、ＵＥ１００から送信されるコーデックＡのデータを、コーデックＢのＲＴＰペイロードフォーマットを用いてコーデックＡ互換モードで送信する。これにより、コーデックＢを使用するＵＥ１０２は、自機のコーデックを変更することなく、ＵＥ１００からのデータを受け取ることができる。
　つまり、ＭＳＣ／ＭＧＷ１１０においてＵＥ１００からのハンドオーバ後のコーデックのデータをハンドオーバ前のコーデックの一部（ハンドオーバ前のコーデックのモードの一つ）に切り替えることで、ＵＥ１００及びＵＥ１０２との間では、コーデックを変更するためのシグナリングが不要となるので、通話が途切れる時間が長くなることを防ぐことができる。また、ＭＳＣ／ＭＧＷ１１０において、ＵＥ１００とＵＥ１０２との間のコーデックのデータの変更を行わず、コーデックのモードだけを切り替えることで、トランスコーディングのように通話品質の劣化が生じることを防ぐことができる。よって、本実施の形態によれば、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができる。
　また、本実施の形態では、ＭＳＣ／ＭＧＷ１１０は、一方の端末（ＵＥ１００）から送信されるデータのコーデックが切り替えられた場合、他方の端末（ＵＥ１０２）が送信するデータに対する互換モードへの切替要求を、当該他方の端末（ＵＥ１０２）へ送信する。そして、ＵＥ１０２は、ＭＳＣ／ＭＧＷ１１０からのコーデックＡ互換モードへの切替要求に従ってコーデックＡ互換モードのデータを送信する。これにより、ＭＳＣ／ＭＧＷ１１０及びＵＥ１００は、ＵＥ１０２から送信されるデータ（コーデックＢのコーデックＡ互換モード）をコーデックＡのデータとして扱うことができる。
　なお、ＵＥ１０２に対する、コーデックＡ非互換モードからコーデックＡ互換モードへの切替要求の通知は、必ずしもＭＳＣ／ＭＧＷ１１０からＵＥ１０２へのＲＴＰペイロードに含まれる必要はない。例えば、当該切替要求は、図２に示すＳＴ２０２において、ＭＳＣ／ＭＧＷ１１０から送信されるＩＮＶＩＴＥ ｗｉｔｈ ＳＤＰ－ＭＧＷのＳＤＰの中に、図１０に示すＳＤＰオファーとしてＵＥ１０２に通知されてもよい。また、非特許文献６に記載のＲＴＣＰ－ＡＰＰを用いてＭＳＣ／ＭＧＷ１１０からＵＥ１０２に上記切替要求を通知してもよい。
　また、ＵＥ１０２がコーデックＡのデータをコーデックＢのＲＴＰペイロードフォーマットで受け取った場合、ＵＥ１０２は、当該データの受信後、ＵＥ１０２からのデータ（送信データ）もコーデックＡ互換モードでエンコードすべきと判断してもよい。この場合、上記切替要求は不要となる。
　（実施の形態２）
　図３及び図４用いて、本実施形態について説明する。なお、以下の説明では、実施の形態１と同様、ＵＥ１００及びＵＥ１０２は最初ＰＳ網でコーデックＢを用いて通話を行っており、ＵＥ１００のみがＰＳ網からＣＳ網にハンドオーバしたとする。また、ＵＥ１００がＣＳ網で使用するコーデックをコーデックＡとする。
　図３及び図４に示すＡＴＣＦ／ＡＴＧＷ３２０は、単なるデータのアンカーポイントである。よって、図３及び図４に示すＡＴＣＦ／ＡＴＧＷ３２０がＵＥ１００からＵＥ１０２へのデータ又はＵＥ１０２からＵＥ１００へのデータをフォワードしている場合において、ＭＳＣ／ＭＧＷ１１０（図８）及びＵＥ１００、ＵＥ１０２（図７）の機能は、実施の形態１（図５～図９）と同一である。ただし、ＭＳＣ／ＭＧＷ１１０において、ＵＥ１０２へのコーデック切替要求（コーデックＡ非互換モードからコーデックＡ互換モードへの切替要求）の通知の際、図２に示すＳＴ２０２のＩＮＶＩＴＥ　ｗｉｔｈ　ＳＤＰを使うことができない点のみが実施の形態１と異なる。
　また、ＡＴＣＦ／ＡＴＧＷ３２０が、ＵＥ１００が図３に示すＰａｔｈ　Ｂで使用するコーデック、及び、ＵＥ１０２が図３に示すＰａｔｈ　Ａで使用するコーデックの情報を保有、若しくは、他のノードから当該情報を得る手段を具備していたとする。
　この場合、ＭＳＣ／ＭＧＷ１１０のコーデック検出部８０４が、ＵＥ１００がＰＳ網（図３に示すＰａｔｈ　Ｂ）で使用していたコーデックの情報を予め保有していなかった場合でも、ＡＴＣＦ／ＡＴＧＷ３２０は、ＵＥ１００がＰＳ網で使用していたコーデックの情報を、図４に示すＳＴ３０２のＩＮＶＩＴＥ　ｗｉｔｈ　ＳＤＰ－ＭＧＷの返信メッセージとして、ＭＳＣ／ＭＧＷ１１０に通知することができる。
　これにより、ＭＳＣ／ＭＧＷ１１０（ＲＴＰペイロード生成部８０８）は、ＵＥ１００（ハンドオーバした端末）がＰＳ網で使用するコーデックを即座に特定することができる。すなわち、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１００（ハンドオーバした端末）がＰＳ網で使用するコーデックに基づいて、ＵＥ１００から送信されるデータを、コーデックＢのＲＴＰペイロードフォーマットを用いて、コーデックＡ互換モードとして、ＵＥ１０２に即座に送信することができる。同様に、ＭＳＣ／ＭＧＷ１１０は、ＵＥ１０２への切替要求を、ＵＥ１０２に即座に送信することができる。
　よって、本実施の形態によれば、ｅＳＲＶＣＣ方式の場合でも、実施の形態１と同様、通信中の端末の一方が使用していたコーデックが変更される場合でも、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができる。
　（実施の形態３）
　本実施の形態では、ＰＳ網からＣＳ網にハンドオーバした端末（図１ではＵＥ１００）がＰＳ網に再び戻ってきた場合について説明する。
　図１１は、本実施の形態に係るＵＥ１００，１０２（端末）の構成を示すブロック図である。なお、図１１において、実施の形態１（図７）と同一の構成部には同一の符号を付し、説明を省略する。
　図１１に示すＵＥ１００，１０２において、端末位置特定部１１００は、自機が接続している網（ＰＳ網又はＣＳ網）、つまり、自機の位置を特定する。これにより、自機のハンドオーバが検出可能となる。端末位置特定部１１００は、自機の位置を、接続先（例えば、ｅ－ｎｏｄｅＢ又はｎｏｄｅＢ）の基地局ＩＤから判断してもよく、ＰＳコア網でのコネクション確立によって判断してもよい。
　例えば、ＰＳ網からＣＳ網にハンドオーバしたＵＥ１００がＰＳ網に再び戻ってきたとする。また、ＵＥ１００は、ＣＳ網でコーデックＡを使用しているとする。このとき、端末位置特定部１１００は、自機がＰＳ網に接続したことを特定する。
　端末位置特定部１１００でＰＳ網に接続したことを特定したＵＥ１００は、ＵＥ１００のコーデックを、コーデックＡからコーデックＢ（コーデックＡ非互換モード）に切り替える。そして、ＵＥ１００のＲＴＰペイロード生成部７０８は、コーデックＢのペイロードフォーマットを用いてＲＴＰペイロードを生成する。このＲＴＰペイロードは、送信部７０２を介してＵＥ１０２に送信される。
　一方、ＵＥ１０２のＲＴＰペイロード解析部７０６は、ＵＥ１００から受け取ったデータのコーデックがコーデックＡ互換モードからコーデックＡ非互換モードに切り替わったことを検知する。そして、ＲＴＰペイロード解析部７０６は、ＵＥ１００のコーデックが切り替わったことを示す情報及びデータをデコーダに渡す。これにより、ＵＥ１０２のデコーダは、ＵＥ１００から受け取るデータを、コーデックＢのコーデックＡ非互換モードでデコードする。
　また、ＵＥ１０２のＲＴＰペイロード解析部７０６は、受信したＲＴＰペイロードにコーデックＡ互換モードからコーデックＡ非互換モードへの切替要求が含まれている場合、この切替要求をエンコーダ及びＲＴＰペイロード生成部７０８に渡す。これにより、ＵＥ１０２は、自機から送信するデータに対してもコーデックＢのコーデックＡ非互換モードを用いることを決定する。すなわち、ＵＥ１０２のＲＴＰペイロード生成部７０８は、エンコーダより渡されたコーデックＡ非互換モードのデータを、コーデックＢのペイロードフォーマットに格納し、ＵＥ１００へ送信する。
　なお、ＵＥ１０２に対する、コーデックＡ互換モードからコーデックＡ非互換モードへの切替要求の通知は、必ずしもＵＥ１００からＵＥ１０２へのＲＴＰペイロードに含まれる必要はない。例えば、非特許文献８に記載のＩＭＳメッセージに当該切替要求を含めてもよい。また、非特許文献６に記載のＲＴＣＰ－ＡＰＰを用いてＭＳＣ／ＭＧＷ１１０からＵＥ１０２に当該切替要求を通知してもよい。
　また、ＵＥ１０２がコーデックＡ非互換モードのデータをコーデックＢのＲＴＰペイロードフォーマットで受け取った場合、ＵＥ１０２は、当該データの受信後、ＵＥ１０２にからのデータ（送信データ）もコーデックＡ非互換モードでエンコードすべきと判断してもよい。この場合、上記切替要求は不要となる。
　こうすることで、ＰＳ網からＣＳ網にハンドオーバした端末がＰＳ網に再び戻ってきた場合でも、当該端末が自機の現在位置に基づいてコーデックを変更することで、通話品質の劣化を生じさせることなく、かつ、通話が途切れる時間を抑えて通信を継続することができる。
　以上、本発明の各実施の形態について説明した。
　なお、上記各実施の形態では、ＡＴＣＦ／ＡＴＧＷ３２０、ＭＳＣ／ＭＧＷ１１０、ＳＣＣ　ＡＳ／ＣＳＣＦをそれぞれ一つのノードとして説明した。しかし、ＡＴＣＦ／ＡＴＧＷ３２０、ＭＳＣ／ＭＧＷ１１０、ＳＣＣ　ＡＳ／ＣＳＣＦは、互いにインタフェースによって接続される２つ以上の別々のノードで構成されてもよい。すなわち、ＡＴＣＦとＡＴＧＷとの間、ＭＳＣとＭＧＷとの間、及び、ＳＣＣ　ＡＳとＣＳＣＦとの間のそれぞれにおいて、上述した機能を複数のノードに分散させてもよい。
　また、上記各実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、これに限らず、音楽、音響、画像等に関しても、本発明は適用可能である。
　また、本発明は、上記各実施の形態に限定されず、種々変更して実施することが可能である。
　また、上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。
　また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
　また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）または、ＬＳＩ内部の回路セルの接続若しくは設定を再構成可能なリコンフィギュラブル／プロセッサを利用してもよい。
　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　２０１１年１１月３０日出願の特願２０１１－２６１６１７の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
　本発明は、通信中の通信端末の一方が利用するコーデックが変更になった場合でも通話品質の劣化を生じさせることなく、かつ、通信が途切れる時間を抑えて通信を継続することに有用である。
　１００，１０２　ＵＥ
　２００，２０２，２０４，２０６，３００，３０２，３０４，３０６　シグナリング
　１１０　ＭＳＣ／ＭＧＷ
　３２０　ＡＴＣＦ／ＡＴＧＷ
　７００，８００　受信部
　７０２，８０２　送信部
　７０４，８０６　コーデック折衝部
　７０６，８１０　ＲＴＰペイロード解析部
　７０８，８０８　ＲＴＰペイロード生成部
　７１０　コーデック通知部
　８０４　コーデック検出部
　１１００　端末位置特定部

Claims (4)

  1. 　第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末間のデータを転送するネットワークノードであって、
    　前記一方の端末が前記第１の網で使用していた第１のコーデック、及び、前記一方の端末が前記第２の網で使用する第２のコーデックを検出する検出手段と、
    　前記第１のコーデックが前記第２のコーデックとの間の互換モードを有するコーデックである場合、前記一方の端末から送信されるデータのコーデックを、前記第１のコーデックの前記互換モードに切り替えることにより、他方の端末向けのデータを生成する生成手段と、
    　前記他方の端末向けのデータを、前記他方の端末へ送信する送信手段と、
    　を具備するネットワークノード。
  2. 　前記送信手段は、前記第１のコーデックが前記第２のコーデックとの間の互換モードを有するコーデックである場合、前記一方の端末から送信されるデータを、前記第１のコーデックのフォーマットを用いて、前記互換モードで送信する、
    　請求項１記載のネットワークノード。
  3. 　前記送信手段は、前記生成手段において前記一方の端末から送信されるデータのコーデックが切り替えられた場合、前記他方の端末が送信するデータに対する前記互換モードへの切替要求を、前記他方の端末へ送信する、
    　請求項１記載のネットワークノード。
  4. 　第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末間のデータを転送する通信方法であって、
    　前記一方の端末が前記第１の網で使用していた第１のコーデック、及び、前記一方の端末が前記第２の網で使用する第２のコーデックを検出し、
    　前記第１のコーデックが前記第２のコーデックとの間の互換モードを有するコーデックである場合、前記一方の端末から送信されるデータのコーデックを、前記第１のコーデックの前記互換モードに切り替えることにより、他方の端末向けのデータを生成し、
    　前記他方の端末向けのデータを、前記他方の端末へ送信する、
    　通信方法。
PCT/JP2012/007358 2011-11-30 2012-11-16 ネットワークノード及び通信方法 WO2013080471A1 (ja)

Priority Applications (9)

Application Number Priority Date Filing Date Title
EP12853666.1A EP2787765B1 (en) 2011-11-30 2012-11-16 Network node and communication method
JP2013546973A JP6012625B2 (ja) 2011-11-30 2012-11-16 ネットワークノード及び通信方法
ES12853666T ES2728678T3 (es) 2011-11-30 2012-11-16 Nodo de red y procedimiento de comunicación
US14/357,306 US9456388B2 (en) 2011-11-30 2012-11-16 Network node and communication method
EP19153189.6A EP3493595B1 (en) 2011-11-30 2012-11-16 Network node and communication method
PL12853666T PL2787765T3 (pl) 2011-11-30 2012-11-16 Węzeł sieciowy i sposób prowadzenia komunikacji
US15/242,968 US9906990B2 (en) 2011-11-30 2016-08-22 Network node and communication method
US15/870,256 US10225767B2 (en) 2011-11-30 2018-01-12 Network node and communication method
US16/250,391 US10362514B2 (en) 2011-11-30 2019-01-17 Network node and communication method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2011261617 2011-11-30
JP2011-261617 2011-11-30

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US14/357,306 A-371-Of-International US9456388B2 (en) 2011-11-30 2012-11-16 Network node and communication method
US15/242,968 Continuation US9906990B2 (en) 2011-11-30 2016-08-22 Network node and communication method

Publications (1)

Publication Number Publication Date
WO2013080471A1 true WO2013080471A1 (ja) 2013-06-06

Family

ID=48534970

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/007358 WO2013080471A1 (ja) 2011-11-30 2012-11-16 ネットワークノード及び通信方法

Country Status (7)

Country Link
US (4) US9456388B2 (ja)
EP (2) EP2787765B1 (ja)
JP (3) JP6012625B2 (ja)
ES (1) ES2728678T3 (ja)
PL (1) PL2787765T3 (ja)
TR (1) TR201907782T4 (ja)
WO (1) WO2013080471A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015129181A1 (ja) * 2014-02-28 2015-09-03 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 音声通信端末、中間ノード、処理装置、接続方法およびプログラム
WO2015174018A1 (ja) * 2014-05-13 2015-11-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ ネットワークノード及びシグナリング処理方法
WO2016036490A1 (en) * 2014-09-05 2016-03-10 Intel Corporation Transcoding avoidance during single radio voice call continuity (srvcc)
WO2016185649A1 (ja) * 2015-05-20 2016-11-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信ノード、端末及び通信制御方法

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2728678T3 (es) 2011-11-30 2019-10-28 Panasonic Ip Corp America Nodo de red y procedimiento de comunicación
US9813950B2 (en) * 2014-05-05 2017-11-07 Mediatek Inc. Method and apparatus for managing a call during a handover procedure in a communications system
US10148703B2 (en) 2014-10-09 2018-12-04 T-Mobile Usa, Inc. Service capabilities in heterogeneous network
US10057393B2 (en) * 2016-04-05 2018-08-21 T-Mobile Usa, Inc. Codec-specific radio link adaptation
US9826072B1 (en) * 2016-09-29 2017-11-21 T-Mobile Usa, Inc. Network-terminal interoperation using compatible payloads
US11799922B2 (en) 2016-12-21 2023-10-24 T-Mobile Usa, Inc. Network core facilitating terminal interoperation
WO2018170705A1 (zh) 2017-03-20 2018-09-27 华为技术有限公司 一种业务通信方法及设备
US10771509B2 (en) 2017-03-31 2020-09-08 T-Mobile Usa, Inc. Terminal interoperation using called-terminal functional characteristics
EP3625947B1 (en) * 2017-05-18 2021-06-02 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Managing network device
KR20200009834A (ko) * 2018-07-20 2020-01-30 삼성전자주식회사 축합환 화합물, 이를 포함한 조성물 및 이를 포함한 유기 발광 소자
CN116566958A (zh) * 2018-09-07 2023-08-08 苹果公司 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法
WO2020122771A1 (en) * 2018-12-10 2020-06-18 Telefonaktiebolaget Lm Ericsson (Publ) Network node, entity and methods performed therein for handling a communication session in a communication network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002185554A (ja) * 2000-12-13 2002-06-28 Nec Corp 通信方式およびトランスコーダのアライメント方法
JP2011514755A (ja) * 2008-02-20 2011-05-06 アルカテル−ルーセント ユーエスエー インコーポレーテッド ボイスオーバインターネットプロトコルのハンドオフの間にトランスコーディングを提供する方法
WO2011136187A1 (ja) * 2010-04-26 2011-11-03 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム及び移動局

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6751477B1 (en) * 2000-05-17 2004-06-15 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for dynamically optimizing the fidelity of a speech signal received from a wireless telephony device and transmitted through a packet-switched network
US7149515B2 (en) * 2003-10-17 2006-12-12 Motorola, Inc. Vocoder selection method
FR2862473B1 (fr) 2003-11-18 2006-03-24 Nortel Networks Ltd Procede de controle de service de communication dans un systeme de telecommunication et commutateur associe
JP2005236388A (ja) * 2004-02-17 2005-09-02 Nippon Telegr & Teleph Corp <Ntt> リソース管理方法、リソース管理装置、リソース管理プログラム及びそのプログラムを記録した記録媒体
WO2005096585A1 (en) * 2004-03-04 2005-10-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and node for selecting a codec type or configuration by extending the list comprising codecs for transcoder/tandem free operation by further codecs supported by the node
US20050254440A1 (en) * 2004-05-05 2005-11-17 Sorrell John D Private multimedia network
US20090003570A1 (en) * 2007-06-26 2009-01-01 Texas Instruments Incorporated Method, system and apparatus for providing endpoint-to-endpoint transcoding free connection
CA2696284C (en) * 2007-08-14 2016-02-09 Dirk Kampmann Improvements in or relating to codec negotiation and selection
EP2206368A1 (en) * 2007-10-04 2010-07-14 Telefonaktiebolaget LM Ericsson (PUBL) Inter-system handoff using circuit switched bearers for serving general packet radio service support nodes
CN101222690B (zh) * 2008-02-01 2012-12-12 华为技术有限公司 一种编码切换方法、系统和设备
EP2417749A4 (en) * 2009-04-07 2017-01-11 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for session negotiation
JP5001983B2 (ja) 2009-07-21 2012-08-15 株式会社エヌ・ティ・ティ・ドコモ 通信制御システム、及び通信制御方法
US9027062B2 (en) * 2009-10-20 2015-05-05 Time Warner Cable Enterprises Llc Gateway apparatus and methods for digital content delivery in a network
WO2011153475A1 (en) * 2010-06-04 2011-12-08 Skype Ireland Technologies Holdings Limited Server-assisted video conversation
US20140114653A1 (en) * 2011-05-06 2014-04-24 Nokia Corporation Pitch estimator
ES2728678T3 (es) * 2011-11-30 2019-10-28 Panasonic Ip Corp America Nodo de red y procedimiento de comunicación

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002185554A (ja) * 2000-12-13 2002-06-28 Nec Corp 通信方式およびトランスコーダのアライメント方法
JP2011514755A (ja) * 2008-02-20 2011-05-06 アルカテル−ルーセント ユーエスエー インコーポレーテッド ボイスオーバインターネットプロトコルのハンドオフの間にトランスコーディングを提供する方法
WO2011136187A1 (ja) * 2010-04-26 2011-11-03 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム及び移動局

Non-Patent Citations (9)

* Cited by examiner, † Cited by third party
Title
"Feasibility Study of Single Radio Voice Call Continuity (SRVCC) from UTRAN/GERAN to E-UTRAN/HSPA", 3GPP TR23.885 VLL.0.0
"IP Multimedia Subsystem (IMS) Service Continuity", 3GPP TS23.237 VL 1.0.0
"IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction", 3GPP TS26.114 V10.0.0
"RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", IETF RFC 4867
"Single Radio Voice Call Continuity (SRVCC", 3GPP TS23.216 V9.6.0
"Study of Use Cases and Requirements for Enhanced Voice Codecs for the Evolved Packet System (EPS", 3GPP TR22.813 V10.0.0
G. ZORN: "RTP Payload Format for G.718 Speech/Audio", 15 November 2011
See also references of EP2787765A4
TAKASHI KOSHIMIZU; KATSUTOSHI NISHIDA: "Audio Video Call Application of Single Radio Voice Call Continuity", GENERAL MEETING OF THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS, 2011, pages B-6 - 77

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10594744B2 (en) 2014-02-28 2020-03-17 Panasonic Intellectual Property Corporation Of America Speech communication terminal, intermediate node, processing device, connection method, and non-transitory computer-readable recording medium
WO2015129181A1 (ja) * 2014-02-28 2015-09-03 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 音声通信端末、中間ノード、処理装置、接続方法およびプログラム
JPWO2015129181A1 (ja) * 2014-02-28 2017-03-30 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 音声通信端末、中間ノード、処理装置、接続方法およびプログラム
JPWO2015174018A1 (ja) * 2014-05-13 2017-04-20 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ ネットワークノード及びシグナリング処理方法
WO2015174018A1 (ja) * 2014-05-13 2015-11-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ ネットワークノード及びシグナリング処理方法
US9967782B2 (en) 2014-05-13 2018-05-08 Panasonic Intellectual Property Corporation Of America Network node and signaling processing method
JP2017528058A (ja) * 2014-09-05 2017-09-21 インテル・コーポレーション 単一無線音声通信継続（ｓｒｖｃｃ）中のトランスコーディング回避
CN106797374A (zh) * 2014-09-05 2017-05-31 英特尔公司 在单一无线语音呼叫连续性(srvcc)期间的转码避免
KR20170026558A (ko) * 2014-09-05 2017-03-08 인텔 코포레이션 단일 라디오 음성 호출 연속성(srvcc) 동안의 트랜스코딩 회피
US10165475B2 (en) 2014-09-05 2018-12-25 Intel Corporation Transcoding avoidance during single radio voice call continuity (SRVCC)
WO2016036490A1 (en) * 2014-09-05 2016-03-10 Intel Corporation Transcoding avoidance during single radio voice call continuity (srvcc)
US10609605B2 (en) 2014-09-05 2020-03-31 Intel Corporation Transcoding avoidance during single radio voice call continuity (SRVCC)
CN106797374B (zh) * 2014-09-05 2020-11-24 英特尔公司 在单一无线语音呼叫连续性(srvcc)期间的转码避免
KR102246204B1 (ko) 2014-09-05 2021-04-30 인텔 코포레이션 단일 라디오 음성 호출 연속성(srvcc) 동안의 트랜스코딩 회피
US11178582B2 (en) 2014-09-05 2021-11-16 Intel Corporation Transcoding avoidance during single radio voice call continuity (SRVCC)
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

Also Published As

Publication number Publication date
PL2787765T3 (pl) 2019-09-30
US20140342739A1 (en) 2014-11-20
US10225767B2 (en) 2019-03-05
US20190150038A1 (en) 2019-05-16
US10362514B2 (en) 2019-07-23
EP2787765A4 (en) 2015-07-29
JP2017017746A (ja) 2017-01-19
ES2728678T3 (es) 2019-10-28
US20180139662A1 (en) 2018-05-17
JP6012625B2 (ja) 2016-10-25
EP3493595A1 (en) 2019-06-05
JP6246293B2 (ja) 2017-12-13
EP3493595B1 (en) 2020-05-20
JP6434601B2 (ja) 2018-12-05
US20160360448A1 (en) 2016-12-08
US9456388B2 (en) 2016-09-27
EP2787765A1 (en) 2014-10-08
TR201907782T4 (tr) 2019-06-21
US9906990B2 (en) 2018-02-27
EP2787765B1 (en) 2019-03-06
JP2018029398A (ja) 2018-02-22
JPWO2013080471A1 (ja) 2015-04-27

Similar Documents

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

Legal Events

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

Ref document number: 12853666

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013546973

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14357306

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE