WO2016185649A1 - 通信ノード、端末及び通信制御方法 - Google Patents

通信ノード、端末及び通信制御方法 Download PDF

Info

Publication number
WO2016185649A1
WO2016185649A1 PCT/JP2016/001495 JP2016001495W WO2016185649A1 WO 2016185649 A1 WO2016185649 A1 WO 2016185649A1 JP 2016001495 W JP2016001495 W JP 2016001495W WO 2016185649 A1 WO2016185649 A1 WO 2016185649A1
Authority
WO
WIPO (PCT)
Prior art keywords
codec
network
terminals
mode
signaling
Prior art date
Application number
PCT/JP2016/001495
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 CN201680009667.5A priority Critical patent/CN107251610B/zh
Priority to JP2017518732A priority patent/JP6787884B2/ja
Publication of WO2016185649A1 publication Critical patent/WO2016185649A1/ja
Priority to US15/788,722 priority patent/US10911988B2/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
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16—Vocoder architecture
    • G10L19/18—Vocoders using multiple modes
    • G10L19/22—Mode decision, i.e. based on audio signal content versus external parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H04W36/144—Reselecting a network or an air interface over a different radio air interface technology
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16—Vocoder architecture
    • G10L19/173—Transcoding, i.e. converting between two coded representations avoiding cascaded coding-decoding
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16—Vocoder architecture
    • G10L19/18—Vocoders using multiple modes
    • G10L19/24—Variable rate codecs, e.g. for generating different qualities using a scalable representation such as hierarchical encoding or layered encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H04W36/00226—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0066—Transmission or use of information for re-establishing the radio link of control information between different types of networks in order to establish a new radio link in the target network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/181—Transcoding devices; Rate adaptation devices

Definitions

  • the present disclosure relates to a communication node, a terminal, and a communication control method that perform codec control used in a mobile communication method.
  • 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. (HO Command) 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.
  • the IMS nodes may be collectively represented as an IMS node 310.
  • 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.
  • an AMR (Adaptive Multi-Rate) codec which is a narrowband (NB) multi-rate codec described in Non-Patent Document 3, and a non-patent document 4
  • An AMR-WB (Adaptive Multi-Rate Wideband) codec which is a wideband (WB) multi-rate codec.
  • the AMR codec and the AMR-WB codec use a CELP (Code-Exited Linear Predictive) method.
  • CELP Code-Exited Linear Predictive
  • the AMR codec and the AMR-WB codec are resistant to bit errors that may occur in a transmission line such as a CS network and packet loss that may occur in the PS network, and therefore can be used in both the CS network and the PS network. .
  • EVS Enhanced Voice Service
  • the EVS codec is a multi-rate codec that supports super-wideband (SWB) and full-band (FB) in addition to narrowband and wideband, and supports bit rates from 5.9 kbps to 128 kbps.
  • the EVS codec supports an AMR-WB compatible mode (EVS AMR-WB compatible mode) in addition to the above-mentioned EVS original codec mode (EVS primary mode).
  • EVS primary mode In the EVS primary mode of the EVS codec, only the use in the PS network is assumed and no bit error is assumed.
  • 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.
  • a wideband (WB) 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 acoustic 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.
  • the full-band (FB) codec is a codec that performs encoding and decoding processing of a digital audio signal sampled at 48 kHz.
  • An ultra-wideband codec generally has a frequency band of 20 Hz to 20 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 24 kHz.
  • a multi-rate codec is a codec that supports multiple bit rates.
  • band refers to a band of a signal that is an input / output of a codec.
  • the codec mode means a subset of elements constituting the codec such as bit rate or band, EVS primary mode and EVS ⁇ ⁇ ⁇ ⁇ AMR-WB compatible mode in the EVS codec.
  • 3GPP TS23.216 (v12.2.0) “Single Radio (Voice) Call (Continuity) (SRVCC)” 3GPP TS23.237 v12.8.0 “IP Multimedia Subsystem IMS (IMS) Service Continuity” 3GPP TS26.071 v12.0.0 “Mandatory speech CODEC speech processing functions; AMR speech Codec; General description” 3GPP TS26.171 v12.0.0 “Speech codec speech processing functions; Adaptive Multi-Rate-Wideband (AMR-WB) speech codec; General description” 3GPP TS 26.441 v12.1.0 “Codec for Enhanced Voice Services (EVS); General overview” SP-140485, 3GPP Work Item Description, “Support of EVS in 3G Circuit-Switched Networks 3GPP TS26.201 v12.0.0 “Speech codec speech processing functions; Adaptive Multi-Rate-Wideband (AMR-WB) speech codec; Frame structure” IETF RFC
  • the codec used by the UE 100 is reset to a codec supported by the CS network.
  • the codec reconfigured at this time is different from the codec used by the UE 100 in the PS network, or the mode (bit rate, audio band, etc.) supported by the CS network is the same as that in the PS network even if it is the same. It can be different.
  • One aspect of the present disclosure provides a communication node, a terminal, and a communication control method capable of continuing communication while suppressing deterioration in call quality even when the codec used by one of the communicating terminals is reset. provide.
  • the communication node is configured so that when one of the two terminals communicating in the first network is handed over to a second network different from the first network, the two terminals
  • the present invention relates to a communication node that determines a codec to be used and a codec mode.
  • a determination unit that sets the common part of the information to the codec and codec mode used by the two terminals, and requests the two terminals to change to the codec and codec mode used by the set two terminals
  • a generating unit that generates signaling for performing the above.
  • FIG. 3 is a block diagram showing a configuration of an IMS node according to the first embodiment. Sequence chart showing an example of operation according to the first embodiment The figure which shows an example of the SDP offer answer based on Embodiment 1 The figure which shows an example of the comparison result of the codec which UE100 supports in MSC / MGW110 which concerns on Embodiment 1, and the codec and codec mode which CS network supports The flowchart which shows an example of the judgment in the judgment part which concerns on Embodiment 1.
  • Block diagram showing a configuration of an MSC / MGW node according to the second embodiment Sequence chart showing an example of operation according to Embodiment 2
  • the first method is a method of transcoding in MSC / MGW110 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.
  • Patent Document 1 when the MGW / MSC receives a PS-> CS req message (see FIG. 2 or FIG. 4) from the MME in the SRVCC handover or eSRVCC handover process, the information included in this message is included. Based on this, a method for predetermining a codec used by a UE in a CS network is disclosed.
  • the information included in the message includes, for example, information indicating the codec supported by the UE to be handed over, and the UE received from the IMS side (SCC AS or ATCF / ATGW) and used in communication in the PS network. It is a codec.
  • the MGW / MSC can know the codec used by the UE in the PS before the UE determines the codec used in the CS network. For this reason, when the codec and codec mode used in the PS network can also be supported in the CS network, the codec and codec mode can be unified with the PS network side in the CS network, so this method is useful. .
  • Non-Patent Document 1 does not disclose any solution for a case where the codec and codec mode used in the PS network cannot be supported by the CS network. Therefore, when the codec and codec mode used in the PS network cannot be supported by the CS network, there is a problem that the quality of the codec and codec mode negotiated at the start of the session in the PS network cannot be secured in the CS network. Arise.
  • Non-Patent Document 7 discloses a method of detecting an error by adding a CRC (Cyclic Redundancy Check) to a bit having no error tolerance when an AMR-WB codec is used in a CS network.
  • CRC Cyclic Redundancy Check
  • Non-Patent Document 8 when an error occurs in the CS network when the AMR codec or the AMR-WB codec is used, when sending a frame including this error to the PS network, the Q bit or SPEECH LOST is used.
  • the terminal of the PS network can discard an errored frame without decoding.
  • the terminal of the PS network can discard an errored frame without decoding.
  • the terminal of the PS network can discard an errored frame without decoding.
  • codecs that use methods (algorithms) that do not have bit error tolerance are used in networks that may cause bit errors (for example, CS networks). Even in the case of communication, it is possible to continue communication while suppressing deterioration in quality.
  • FIG. 5 is a block diagram showing a configuration of IMS node 310 according to the present embodiment.
  • IMS node refers to, for example, SCC AS or ATCF / ATGW.
  • the IMS node 310 includes a reception unit 500, a transmission unit 502, a storage unit 504, a determination unit 506, a policy reference unit 508, and a signaling generation unit 510.
  • the IMS node 310 has a function that the IMS node has as a standard.
  • the receiving unit 500 receives signaling.
  • the signaling received by the receiving unit 500 includes, for example, information indicating an SDP (Session Description Protocol) offer and an SDP answer or a part thereof in call control (session setup) at the start of communication in the PS network (that is, in the PS network)
  • Information indicating the codec and codec mode used by the terminal in communication information indicating the codec and codec mode supported by the terminal handed over to the CS network, or the codec and codec mode supported by the CS network.
  • the information etc. which are shown are mentioned.
  • the receiving unit 500 performs handover to the CS network instead of information indicating the codec and codec mode supported by the terminal handed over to the CS network, and information indicating the codec and codec mode supported by the CS network.
  • Information indicating the codec and codec mode supported by the mobile terminal and information indicating the codec and codec mode supported by the CS network and information indicating the codec mode (codec / codec mode information) ) May be received from a CS network (eg, MGW / MSC 110).
  • the transmission unit 502 transmits signaling.
  • the signaling transmitted by the transmission unit 502 includes, for example, a codec mode change request (mode change request) for requesting a change of the codec mode.
  • the storage unit 504 stores the contents of the SDP offer and SDP answer output from the receiving unit 500 (that is, information on the codec / codec mode used in the PS network).
  • the determination unit 506 supports the codec and codec mode used by the terminal to be handed over (UE 100 in FIG. 1 or 3) in communication in the PS network, and the terminal supports Are compared with the codec and codec mode supported by the CS network of the handover destination. Then, the determination unit 506 determines whether it is necessary to change the codec and the codec mode based on the comparison result of the codec / codec mode and the policy referred to by the policy reference unit 508 described later.
  • the policy reference unit 508 refers to the policy that the service operator has.
  • the signaling generation unit 510 When the determination unit 506 determines that the codec mode needs to be changed, the signaling generation unit 510 generates signaling including a codec mode change request. Signaling generation section 510 outputs the generated signaling to transmission section 502.
  • FIG. 6 is a sequence chart showing an example of the operation according to the present embodiment.
  • the UE 100 is initially located in the PS network (LTE network), and performs session setup with the UE 102 that is also located in the PS network (LTE network) via the IMS node 310 (for example, , Refer to Non-Patent Document 2), the codec and codec mode to be used in voice communication are determined by the SDP offer / SDP answer (ST601).
  • IMS node 310 stores information on SDP offer and SDP answer exchanged between terminals in session setup or a part thereof (for example, only the contents of SDP answer) (ST602).
  • FIG. 7 shows an example of SDP offer and SDP answer exchanged between terminals in session setup.
  • SWB ultra wideband
  • the bit rate range from 9.6 kbps to 24.4 kbps
  • br 9.6-24.4
  • the storage unit 504 of the IMS node 310 stores at least the contents of this SDP answer.
  • the UE 100 performs SRVCC handover or eSRVCC handover from the PS network to the CS network when performing a voice call with the UE 102 via the PS network (LTE network) (ST603).
  • PS network LTE network
  • the e-nodeB detects this and transmits a HO Required message to the MME (ST604).
  • the MME transmits a PS-> CS req message to the MSC / MGW 110 (ST605).
  • the HO Required message and the PS-> CS req message are as described in Non-Patent Document 1.
  • the PS-> CS req message includes a list (Supported Codec List) indicating codecs (UE supported codec) supported by the UE 100.
  • the MGW / MSC 110 When the MGW / MSC 110 receives the PS-> CS req message, the MGW / MSC 110 receives a list of codecs supported by the UE 100 included in the PS-> CS req message, and the codecs and codecs supported by the own network (CS network). The modes are collated (compared) (ST606). As a result of the collation, MGW / MSC 110 transmits codec / codec mode information indicating the matching codec and its codec mode to IMS node 310 (ST607). In addition, the transmission method of codec / codec mode information may be transmitted using SDP in IMS, for example, or another method may be used.
  • FIG. 8 shows an example of collation (comparison) results between the codec supported by the UE 100 and the codec and codec mode supported by the CS network in the MSC / MGW 110. That is, the information shown in FIG. 8 is a codec that matches between the information indicating the codec and codec mode supported by the UE 100 handed over to the CS network and the information indicating the codec and codec mode supported by the CS network. And information indicating the codec mode.
  • the determination unit 506 of the IMS node 310 includes the codec / codec mode information received from the MGW / MSC 110, the content (or part thereof) of the SDP offer / SDP answer stored in the storage unit 504, and the policy reference unit 508. Based on the policy of the service operator to be referenced, the codec / codec mode used in the CS network (that is, the codec / codec mode used by the UE 100) and the codec / codec mode used in the PS network (that is, the UE 102) The codec / codec mode to be used is determined (ST608). Details of the determination process in the determination unit 506 will be described later.
  • IMS node 310 then instructs the determined codec / codec mode to MSC / MGW 110 (ST609). Further, MSC / MGW 110 notifies the selection of the codec and codec mode instructed from IMS node 310 when sending the HO Req message to the CS network side (RNC / nodeB) (ST610).
  • a data path in the CS network is prepared between the node B and the MSC / MGW 110, and when the preparation is completed, an instruction (HO Command) to hand over the UE 100 to the UTRAN (CS network) side from the MME via the e-nodeB. ) Is issued (ST611).
  • IMS session transfer (initiation of session transfer) is performed between the MGW / MSC 110 and the IMS node 310 (ST612).
  • UE 100 After handing over to UTRAN (CS network), UE 100 exchanges signaling with MSC / MGW 110 via RNC / nodeB (ST613). Thereby, the communication path between UE100 and MSC / MGW110 is switched.
  • UTRAN CS network
  • RNC Radio Network Controller
  • a command is issued to switch the communication path of the call data of UE 102 from UE 100 to MSC / MGW 110, and the communication path is switched (ST614).
  • the IMS node 310 notifies the mode change request for requesting the change to the codec mode determined in ST608 to the UE 102 of the PS network (ST615).
  • mode change request notification (ST615) to the PS network may be performed immediately after the data communication path change (Speech Data path switched), as shown in FIG. It may be done before the change.
  • the mode change request may be included in an RTP (Real-time Transport Protocol) payload header or may be included in an RTCP (RTP Control Protocol).
  • RTP Real-time Transport Protocol
  • RTCP RTP Control Protocol
  • the mode change request may be notified using a CMR (Codec Mode Request) byte of an RTP payload format header described in Non-Patent Document 9, or RTCP (RTP Control Protocol)-described in Non-Patent Document 10. Notification may be performed using the CMR of APP, or may be performed using other methods.
  • the mode change request may be transmitted to the UE 102 in response to an instruction from the IMS node 310 by a node existing on the data path.
  • the node on this data path may be ATGW or MGW.
  • the ATGW adds the CMR byte including the mode change request to the data transmitted from the MGW.
  • FIG. 9 is a flowchart illustrating an example of determination by the determination unit 506.
  • the determination unit 506 first determines whether or not there is a service operator policy (local policy) referred to by the policy reference unit 508 (ST900). If there is a service operator policy (ST900: YES), determination section 506 determines to use a codec and codec mode according to this policy (ST902).
  • the IMS node 310 transmits a signaling message indicating the codec / codec mode to the CS network side, the PS network side, or both as required.
  • the codec mode negotiated during the session setup in the PS network is the codec mode on the CS network side. May be overwritten by ".
  • the bit rate of EVS negotiated at the time of session setup described in the SDP answer shown in FIG. 7 is 9.8 kbps to 24.4 kbps.
  • the bit rate of EVS supported by the CS network shown in FIG. 8 is 5.9 kbps to 13.2 kbps.
  • the IMS node 310 instructs the MSC / MGW 110 to select a bit rate of EVS from 5.9 kbps to 13.2 kbps, and the MSC / MGW 110 sends the HO Req to the CS network side. Is transmitted, it is notified that the bit rate of EVS is selected from 5.9 kbps to 13.2 kbps (ST610). IMS node 310 also notifies the PS network side that the upper limit of the bit rate is set to 13.2 kbps (ST615).
  • the determination unit 506 is used in the PS network and the codec and codec mode indicated in the codec / codec mode information (ST607) notified from the MSC / MGW110. It is determined whether or not there is a common part between the current codec and the codec mode (ST904).
  • the determination unit 506 determines to use the codec and codec mode that are the common part (ST906).
  • the IMS node 310 transmits a signaling message prompting the use of the codec / codec mode of the common part to the CS network side, the PS network side, or both.
  • the IMS node 310 instructs the MSC / MGW 110 to use only 9.8 kbps and 13.2 kbps as the EVS bit rate, and when the MSC / MGW 110 transmits HO Req to the CS network side, It is notified that only 9.8 kbps and 13.2 kbps are selected as the bit rate (ST610). IMS node 310 also notifies the PS network side that the bit rate is set to 9.8 kbps and 13.2 kbps (ST615).
  • the processing of ST906 shown in FIG. 9 indicates that the policy confirmed to exist in the determination of ST900 is “if the codec used on the PS network side is also supported on the CS network side, the common part is used as the codec mode. Is equivalent to the process performed in ST902.
  • the common part may not be a completely matching part, but may be a common upper limit value.
  • the upper limit of the EVS bit rate is 13.2 kbps, so the PS network side is notified that the upper limit of the bit rate is 13.2 kbps.
  • Sent Further, as described in Non-Patent Document 11, several combinations of bit rates used on the CS network side may be determined in advance. For example, even in the case of EVS, in addition to the combinations shown in FIG.
  • the determination unit 506 determines that the codec used in the PS network has a compatibility mode with another codec. If present, it is determined whether or not there is a compatible codec in the codec / codec mode indicated in the codec / codec mode information (ST908). That is, when the codec used in the PS network has a compatible mode, the determining unit 506 determines whether or not the CS network can be changed to the compatible mode.
  • the determination unit 506 determines to use the codec in the compatible mode (ST910).
  • IMS node 310 transmits a signaling message that prompts the use of the codec in the compatible mode to the CS network side, the PS network side, or both (ST610, ST615).
  • the EVS codec also supports the AMR-WB compatible mode. Therefore, in ST910, the IMS node 310 instructs the MSC / MGW 110 to use the EVS AMR-WB compatible mode, and when the MSC / MGW 110 transmits the HO Req to the CS network side, the EMR AMR -Notification of changing to the WB compatible mode is sent (ST610). Also, IMS node 310 notifies the PS network side that the EVS AMR-WB compatible mode and the upper limit of the bit rate are set to 12.65 kbps (see FIG. 8) (ST615).
  • the process of ST910 shown in FIG. 9 indicates that the policy confirmed to exist in the determination of ST900 is “if the codec used on the PS network side has a compatibility mode with another codec, the CS network This is equivalent to the processing performed in ST902 when the content is “change to compatible mode”.
  • the determination unit 506 is the CS network. It is determined that a supported codec is used in the CS network and transcoding is performed between the PS network and the CS network (ST912).
  • session re-negotiation may be performed instead of transcoding, and the codec of UE 102 may be changed to a codec that can be supported by the CS network according to the result of re-negotiation.
  • the transcoding may be performed when a node existing on the data path receives an instruction from the IMS node to perform transcoding.
  • the node that performs transcoding may be ATGW or MGW.
  • the determination in the determination unit 506 of the IMS node 310 has been described above.
  • the determination unit 506 of the IMS node 310 determines the codec and codec mode used for communication in the PS network when one of the two terminals communicating in the PS network is handed over to the CS network.
  • the above two terminals share a common part of the information indicating, the information indicating the codec and codec mode supported by one handed over terminal (UE 100), and the information indicating the codec and codec mode supported by the CS network.
  • the signaling generation unit 510 of the IMS node 310 generates signaling for requesting the two terminals to change to the codec and codec mode used in the set two terminals.
  • the PS network uses the PS codec / codec mode.
  • the quality of the codec and codec mode negotiated at the start of the session on the network can be ensured.
  • the determination unit 506 of the IMS node 310 has a compatibility mode with another codec in the codec used for communication in the PS network, and one of the terminals that has been handed over When another codec is included in the supported codec and the codec supported by the CS network, the codec and codec used in the two terminals are changed to another codec or a compatibility mode with another codec. Set to mode.
  • the codec / codec mode is set according to the policy.
  • the codec and codec mode supported by the CS handover destination CS network are different from the codec and codec mode negotiated at the time of session setup at the start of communication in the PS network. Even in this case, the communication can be continued without departing from the contents negotiated at the time of session setup and the service operator policy.
  • FIG. 10 is a block diagram showing a configuration of MSC / MGW 110 according to the present embodiment.
  • the MSC / MGW 110 includes a reception unit 1000, a transmission unit 1002, a storage unit 1004, a determination unit 1006, a policy reference unit 1008, and a signaling generation unit 1010. Note that the MSC / MGW 110 has a standard function of the MSC / MGW in addition to the components shown in FIG.
  • the receiving unit 1000 receives signaling.
  • the signaling received by the receiving unit 1000 includes, for example, information indicating the contents of an SDP offer and SDP answer or part thereof in call control (session setup) received from the IMS node 310 at the start of communication in the PS network (that is, Information indicating the codec and codec mode used by the terminal in communication in the PS network (referred to as codec / codec mode information in this embodiment), a PS including a list received from the MME and indicating the codec supported by the UE 100 -> CS req message etc.
  • the transmission unit 1002 transmits signaling.
  • Examples of signaling transmitted by the transmission unit 1002 include a codec mode change request (mode change request) for requesting a change in codec mode, and a query for requesting the IMS node 310 for codec / codec mode information.
  • the storage unit 1004 stores the contents of the SDP offer and SDP answer or a part thereof output from the receiving unit 1000, and codec information supported by the UE 100 transmitted from the CS network.
  • the storage unit 1004 may store information indicating codecs and codec modes supported by the CS network.
  • the determination unit 1006 supports the codec and codec mode used by the terminal (UE 100 in FIG. 1 or 3) used for communication in the PS network, and the terminal supports The codec and the codec mode are compared with the codec and the codec mode supported by the CS network. Then, the determination unit 1006 determines whether it is necessary to change the codec and the codec mode based on the comparison result of the codec / codec mode and the policy referred to by the policy reference unit 1008 described later.
  • the policy reference unit 1008 refers to the policy that the service operator has.
  • the signaling generation unit 1010 When the determination unit 1006 determines that the codec mode needs to be changed, the signaling generation unit 1010 generates signaling including a codec mode change request. In addition, the signaling generation unit 1010 generates signaling (query) for receiving the contents of the SDP offer / SDP answer or a part thereof with respect to the IMS node 310. The signaling generation unit 1010 outputs the generated signaling to the transmission unit 502.
  • FIG. 11 is a sequence chart showing an example of the operation according to the present embodiment.
  • the same reference numerals are assigned to the same processes as those in the first embodiment (FIG. 6), and the description thereof is omitted.
  • UE 100 is initially located in the PS network (LTE network) and is performing a voice call with UE 102 that is also located in the PS network (LTE network). .
  • the storage unit 1004 of the MSC / MGW 110 stores information (Supported Codec List) indicating codecs supported by the UE 100, which is included in the PS-> CS req message received from the MME in ST605.
  • the signaling generation unit 1010 of the MGW / MSC 110 generates a query message for the IMS node 310 that requests the content of the SDP offer / SDP answer exchanged between the UE 100 and the UE 102 or a part thereof in ST601.
  • the generated CLIE message is transmitted from MGW / MSC 110 to IMS node 310 (ST1101). Note that this CLIE message may be IMS signaling or another method.
  • IMS node 310 upon receiving the inquiry message in ST1101, transmits codec / codec mode information including the contents of the held SDP offer / SDP answer or a part thereof to MGW / MSC 110 (ST1102).
  • the storage unit 1004 of the MGW / MSC 110 stores the received codec / codec mode information.
  • the determination unit 1006 of the MGW / MSC 110 includes codec / codec mode information (codec / codec mode used for communication in the PS network) received from the IMS node 310, a list of codecs supported by the UE 100, and the own network
  • codec / codec mode used in the CS network that is, the codec used by the UE 100
  • the codec / codec mode used in the CS network that is, the codec used by the UE 100
  • the codec / codec mode used in the PS network that is, the codec / codec mode used by the UE 102 are determined (ST1103).
  • determination processing in the determination unit 1006 is the same as that in the first embodiment (see, for example, FIG. 9), and thus the description thereof is omitted here.
  • the MGW / MSC 110 notifies the CS network side (RNC / nodeB) including the determined codec / codec mode when sending the HO Req message (ST610). Also, MGW / MSC 110 notifies IMS node 310 of the determined codec / codec mode to be used in the PS network (ST 1104). IMS signaling may be used for notifying the IMS node 310 of the codec / codec mode, or another method may be used.
  • the MGW / MSC 110 notifies the UE 102 of the PS network of a mode change request for requesting the change to the codec mode determined in ST1103 (ST1105).
  • mode change request notification (ST1105) to the PS network may be performed immediately after the change of the data communication path (Speech Data path switched) as shown in FIG. It may be done before the change.
  • the mode change request may be included in the RTP payload header or may be included in RTCP.
  • the mode change request may be notified using a CMR (Codec Mode Request) byte of an RTP payload format header described in Non-Patent Document 9, and an RTCP-APP CMR described in Non-Patent Document 10 is used. May be notified, or may be notified using other methods.
  • CMR Codec Mode Request
  • the mode change request may be transmitted from the MGW / MSC 110 or from the ATGW.
  • the ATGW adds the CMR byte including the mode change request to the data transmitted from the MGW.
  • the MGW / MSC 110 performs IMS before determining the codec to be used in the PS network. After transmitting the SDP offer to the UE 102 through the node 310 and receiving the SDP answer from the UE 102 via the IMS node 310, a HO req message including the codec and codec mode used on the CS side may be transmitted.
  • the determination unit 1006 of the MGW / MSC 110 determines the codec and codec mode used for communication in the PS network when one of the two terminals communicating in the PS network is handed over to the CS network.
  • the above two terminals share a common part of the information indicating, the information indicating the codec and codec mode supported by one handed over terminal (UE 100), and the information indicating the codec and codec mode supported by the CS network.
  • the signaling generation unit 1010 of the MGW / MSC 110 generates signaling for requesting the two terminals to change to the codec and codec mode used in the set two terminals.
  • the codec / codec mode used in the PS network cannot be supported in the CS network by using the codec / codec mode that is the common part.
  • the quality of the codec and codec mode negotiated at the start of the session in the PS network can be ensured.
  • the codec and codec mode supported in the CS handover destination CS network are negotiated at the time of session setup at the start of communication in the PS network. Even when the codec and the codec mode are different from each other, communication can be continued without departing from the contents negotiated at the time of service operator policy and session setup.
  • FIG. 12 is a block diagram showing a configuration of UEs 100 and 102 (terminals) according to the present embodiment.
  • the UEs 100 and 102 include a reception unit 1200, a transmission unit 1202, a connection destination detection unit 1204, a codec detection unit 1206, a determination unit 1208, a command transmission unit 1210, and a notification transmission / reception unit 1212.
  • the UEs 100 and 102 have functions that the terminal has as a standard in addition to the components shown in FIG.
  • the receiving unit 1200 receives communication data, signaling, and the like.
  • the signaling received by the receiving unit 1200 includes, for example, that the communication partner terminal has been handed over to the CS network from the communication partner terminal handed over to the CS network (or a communication node on the data path), or the codec encoding method. Signaling for notifying that the restriction is necessary is included.
  • the transmission unit 1202 transmits communication data, signaling, and the like.
  • the signaling transmitted by the transmission unit 1202 notifies, for example, that a communication partner terminal located in the PS network has handed over to the CS network or that the codec encoding method needs to be restricted. Signaling to do this is mentioned.
  • the connection destination detection unit 1204 detects its own connection destination network (PS network or CS network) by handover or the like.
  • the codec detection unit 1206 detects the codec used in the connection destination network detected by the connection destination detection unit 1204.
  • the determination unit 1208 Based on the connection destination network detected by the connection destination detection unit 1204 and the codec detected by the codec detection unit 1206, the determination unit 1208 needs to limit the encoding method used by the codec used by the own device and the communication partner terminal. It is determined whether or not.
  • the determination unit 1208 is a codec that uses an encoding method in which the codec used in the CS network detected by the codec detection unit 1206 does not have bit error tolerance when the own device is handed over from the PS network to the CS network. In some cases, it is determined that the encoding method needs to be restricted.
  • the command transmission unit 1210 for example, when the own device is handed over to the CS network and the determination unit 1208 determines that the encoding method needs to be restricted, or the own device is in the PS network, and will be described later.
  • the transmission / reception unit 1212 receives a notification of the connection destination network (or signaling for notifying the restriction of the encoding method) from the communication partner terminal (located in the CS network), the encoding method used in the connection destination network is limited. An internal command is transmitted to an encoder (not shown).
  • the notification transmission / reception unit 1212 receives a notification of a connection destination network (signaling for limiting the encoding method) from the communication partner terminal via the reception unit 1200. Also, the notification transmission / reception unit 1212, for example, when the own device is handed over to the CS network and the determination unit 1208 determines that the encoding method needs to be limited, Signaling for notifying that the own device has handed over to the CS network or that the codec encoding method needs to be restricted is generated. This signaling is notified to the communication partner terminal via the transmission unit 1202.
  • the connection destination detection unit of the UE 100 1204 detects that the connection destination network has been changed to the CS network using the base station information and the like.
  • the codec detection unit 1206 of the UE 100 detects the codec used in the CS network.
  • the codec used by the UE 100 in the CS network is notified to the RNC / nodeB by the MGW / MSC 110, for example (for example, ST610).
  • the codec setting method used by the UE 100 in the CS network may be the method described in the first and second embodiments, or may be another method.
  • the codec and codec mode used in the CS network for the UE 100 are 9.6 kbps and 13.2 kbps in the EVS primary mode.
  • the CS network is a network in which a bit error can occur in the transmission path
  • the EVS primary mode is a codec mode in which no bit error is assumed. Therefore, in this case, the determination unit 1208 of the UE 100 does not have bit error tolerance based on the CS network information detected by the connection destination detection unit 1204 and the codec information detected by the codec detection unit 1206.
  • the EVS primary mode 9.6 kbps and 13.2 kbps using the scheme is detected to be used in the CS network where bit errors can occur. That is, the determination unit 1208 determines that the encoding method of the codec used in the CS network needs to be limited.
  • the command transmission part 1210 of UE100 transmits the internal command which restrict
  • an IMS session transfer (initiation of session transfer) is performed between the MGW / MSC 110 and the IMS node 310 (ST612).
  • the signaling generators 510 and 1010 (see FIGS. 5 and 10) of the MGW / MSC 110 or the ATGW (IMS node 310) perform signaling or use to notify the UE 102 that the UE 100 is connected to the CS network. Signaling for notifying that the encoding method of the codec being used is limited (encoding using a method having bit error tolerance) is generated and transmitted.
  • the UE 100 when it is determined that the UE 100 needs to restrict the encoding method, signaling for notifying that the UE 100 is connected to the CS network, or notifying that the encoding method of the used codec is restricted.
  • the signaling is generated at a communication node that exists on the data path of the UE 100 and the UE 102 and is transmitted to the UE 102.
  • This signaling may be included in the RTP payload header or may be included in RTCP.
  • the communication partner UE 100 in FIGS. 6 and 11
  • the communication partner is connected to the CS network in the field or bit of the CMR (Codec Mode Request) byte of the RTP payload format header described in Non-Patent Document 9.
  • a function for notifying that the encoding method is restricted may be added and used.
  • a new field for notifying the RTCP-APP CMR described in Non-Patent Document 10 that the communication partner has connected to the CS network or that the encoding method is restricted is provided. You may use it additionally.
  • this signaling may be signaled using another method such as IMS signaling.
  • timing at which signaling for notifying that the UE 100 has connected to the CS network or that the encoding method is limited may be transmitted at the same time as the transmission timing of the mode change request shown in FIGS. But you can.
  • this signaling may implicitly or explicitly include that the EVS primary mode is used in the CS network. Further, signaling that notifies that the UE 100 is connected to the CS network or restricts the encoding method may be transmitted from the UE 100 to the UE 102.
  • the notification transmission / reception unit 1212 of the UE 102 which is a communication counterpart terminal of the UE 100 handed over to the CS network receives the signaling notifying that the UE 100 is connected to the CS network or restricts the encoding method
  • the CS network It detects that UE100 which moved to communicates using EVS primary mode. Then, the determination unit 1208 of the UE 102 determines that the encoding method needs to be limited, and the command transmission unit 1210 encodes the encoder (not shown) of the UE 102 using only a method having bit error resistance. To send an internal command to limit the encoding method.
  • the method of transmitting the internal command to encode only using the method having bit error tolerance is not only at the time of SRVCC handover or eSRVCC handover, For example, it may be used when the UE 100 is connected to the CS network from the beginning.
  • the method of notifying the communication partner (for example, UE 102) connected to the PS network that the UE 100 is connected to the CS network is not limited to the SRVCC handover or the eSRVCC handover. It may be used from the start of communication when connected and the UE 102 is connected to the PS network.
  • the “method with bit error tolerance” may be an EVS AMR-WB compatible mode.
  • the connection destination detection unit 1204 detects the connection of the UE 100 to the CS network
  • the codec detection unit 1206 detects EVS as the codec used in the CS network
  • the command transmission unit 1210 Then, an internal command is transmitted to change the encoding method to the AMR-WB compatible mode.
  • the signaling for notification to the UE 102 in this case does not notify that the UE 100 has performed handover to the CS network, but may be a switching request for switching the EVS primary mode to the AMR-WB compatible mode.
  • the CMR byte of the RTP payload format header described in Non-Patent Document 9 may be used, or the CMR of RTCP-APP described in Non-Patent Document 10 may be used.
  • this switching request may be notified using another method such as IMS signaling.
  • the timing at which the switching request is transmitted may be the same as the transmission timing of the mode change request shown in FIGS. 6 and 11 or may be a different timing. Further, the switching request may be transmitted from the UE 100 to the UE 102.
  • UEs 100 and 102 are schemes (algorithms) that do not have bit error resilience, such as EVS primary mode, as a codec used by a UE connected to the CS network in the CS network.
  • EVS primary mode a codec used by a UE connected to the CS network in the CS network.
  • the encoder is instructed to use a method (algorithm) that does not have bit error tolerance.
  • a codec that uses a method in which the UE connected to the CS network does not have bit error tolerance is set. Even in this case, the influence of bit errors in the CS network can be suppressed. That is, even when the EVS codec is used in the CS network, the decoding is correctly performed in response to the bit error occurring in the transmission path, and quality degradation can be prevented.
  • This policy is, for example, a policy that indicates whether the RTP payload format of the EVS codec described in Non-Patent Document 9 is a scheme that uses both the compact format and the header full format, or a scheme that uses only the header full format. This means a policy indicating whether the method uses the Bandwidth-Efficient mode or the method that uses the Octet-Aligned-Mode mode in the RTP payload format of the AMR or AMR-WB codec described in Patent Document 8.
  • the IMS node 310 allows the policy difference, and the node existing on the data path such as ATGW may change the payload format (transformat).
  • 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.
  • the integrated circuit may control each functional block used in the description of the above embodiment, and may include an input and an output. 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computational Linguistics (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • Acoustics & Sound (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

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

Description

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

Claims (12)

  1. 　第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末で使用されるコーデック及びコーデックモードを判断する通信ノードであって、
    　　前記第１の網における通信で使用しているコーデック及びコーデックモードを示す情報と、
    　　前記一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、
    　　前記第２の網がサポートしているコーデック及びコーデックモードを示す情報と、
    　の共通部分を前記２つの端末で使用されるコーデック及びコーデックモードに設定する判断部と、
    　設定された前記２つの端末で使用されるコーデック及びコーデックモードへの変更を前記２つの端末へ要求するためのシグナリングを生成する生成部と、
    　を具備する通信ノード。
  2. 　前記判断部は、前記共通部分が存在しない場合に、
    　前記第１の網における通信で使用しているコーデックに、別のコーデックとの互換モードが存在し、かつ、前記一方の端末がサポートしているコーデック及び前記第２の網がサポートしているコーデックに、前記別のコーデックが含まれる場合、前記別のコーデック又は前記別のコーデックとの互換モードを、前記２つの端末で使用されるコーデック及びコーデックモードに設定する、
    　請求項１に記載の通信ノード。
  3. 　前記判断部は、サービスオペレータのポリシが存在する場合には前記ポリシに従って前記２つの端末で使用されるコーデック及びコーデックモードを設定し、前記ポリシが存在しない場合には前記共通部分を前記２つの端末で使用されるコーデック及びコーデックモードに設定する、
    　請求項１又は２に記載の通信ノード。
  4. 　第１の網において通信を行う２つの端末のうち、前記第１の網と異なる網にハンドオーバする端末であって、
    　ハンドオーバによる接続先網を検出する接続先検出部と、
    　前記接続先網で使用するコーデックを検出するコーデック検出部と、
    　前記検出された接続先網と、前記検出されたコーデックとに基づいて、前記２つの端末で使用されるコーデックで用いるエンコード方式の制限が必要であるか否かを判断する判断部と、
    　前記エンコード方式の制限が必要であると判断された場合、前記エンコード方式を制限するための内部コマンドをエンコーダに送信するコマンド送信部と、
    　を具備する端末。
  5. 　前記第１の網がパケット交換網であり、前記接続先網が回線交換網であり、
    　前記判断部は、前記検出されたコーデックがビット誤り耐性を有さないエンコード方式を用いるコーデックである場合に、前記エンコード方式の制限が必要であると判断する、
    　請求項４に記載の端末。
  6. 　前記エンコード方式の制限が必要であると判断された場合、前記接続先網にハンドオーバしたこと、又は、前記エンコード方式の制限が必要であることを通信相手端末に通知するためのシグナリングを生成する生成部と、
    　前記シグナリングを前記通信相手端末に送信する送信部と、を更に具備する、
    　請求項４に記載の端末。
  7. 　前記エンコード方式の制限が必要であると判断された場合、
    　前記端末が前記接続先網にハンドオーバしたこと、又は、前記エンコード方式の制限が必要であることを通知するためのシグナリングは、前記２つの端末のデータ経路上に存在する通信ノードで生成され、前記端末の通信相手端末に送信される、
    　請求項４に記載の端末。
  8. 　前記シグナリングを受け取った前記通信相手端末は、前記エンコード方式を制限するための内部コマンドを、前記通信相手端末内のエンコーダに送信する、
    　請求項６又は７に記載の端末。
  9. 　前記シグナリングは、ＲＴＰ（Real-time Transport Protocol）ペイロードヘッダに含まれる、
    　請求項６から８の何れかに記載の端末。
  10. 　前記シグナリングは、ＲＴＣＰ（Real-time Transport Protocol Control Protocol）に含まれる、
    　請求項６から８の何れかに記載の端末。
  11. 　第１の網において通信を行う２つの端末のうち一方の端末が前記第１の網と異なる第２の網にハンドオーバした際に、前記２つの端末で使用されるコーデック及びコーデックモードを判断する通信制御方法であって、
    　　前記第１の網における通信で使用しているコーデック及びコーデックモードを示す情報と、
    　　前記一方の端末がサポートしているコーデック及びコーデックモードを示す情報と、
    　　前記第２の網がサポートしているコーデック及びコーデックモードを示す情報と、
    　の共通部分を前記２つの端末で使用されるコーデック及びコーデックモードに設定し、
    　設定された前記２つの端末で使用されるコーデック及びコーデックモードへの変更を前記２つの端末へ要求するためのシグナリングを生成する、
    　通信制御方法。
  12. 　第１の網において通信を行う２つの端末のうち、前記第１の網と異なる網にハンドオーバする端末における通信制御方法であって、
    　ハンドオーバによる接続先網を検出し、
    　前記接続先網で使用するコーデックを検出し、
    　前記検出された接続先網と、前記検出されたコーデックとに基づいて、前記２つの端末で使用されるコーデックで用いるエンコード方式の制限が必要であるか否かを判断し、
    　前記エンコード方式の制限が必要であると判断された場合、前記エンコード方式を制限するための内部コマンドをエンコーダに送信する、
    　通信制御方法。
PCT/JP2016/001495 2015-05-20 2016-03-16 通信ノード、端末及び通信制御方法 WO2016185649A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201680009667.5A CN107251610B (zh) 2015-05-20 2016-03-16 通信节点、终端及通信控制方法
JP2017518732A JP6787884B2 (ja) 2015-05-20 2016-03-16 通信ノード、端末及び通信制御方法
US15/788,722 US10911988B2 (en) 2015-05-20 2017-10-19 Communication node, terminal, and communication control method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015-102810 2015-05-20
JP2015102810 2015-05-20

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/788,722 Continuation US10911988B2 (en) 2015-05-20 2017-10-19 Communication node, terminal, and communication control method

Publications (1)

Publication Number Publication Date
WO2016185649A1 true WO2016185649A1 (ja) 2016-11-24

Family

ID=57319790

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/001495 WO2016185649A1 (ja) 2015-05-20 2016-03-16 通信ノード、端末及び通信制御方法

Country Status (4)

Country Link
US (1) US10911988B2 (ja)
JP (1) JP6787884B2 (ja)
CN (1) CN107251610B (ja)
WO (1) WO2016185649A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2727794C1 (ru) * 2017-05-18 2020-07-24 Фраунхофер-Гезелльшафт Цур Фердерунг Дер Ангевандтен Форшунг Е.Ф. Управляющее сетевое устройство

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10278100B1 (en) 2016-03-16 2019-04-30 Sprint Communications Company L.P. Long term evolution (LTE) mobility management entity (MME) management of an internet protocol multimedia subsystem (IMS) media session service level for a user equipment (UE)
US10778729B2 (en) * 2017-11-07 2020-09-15 Verizon Patent And Licensing, Inc. Codec parameter adjustment based on call endpoint RF conditions in a wireless network
CN112640390B (zh) * 2018-09-07 2023-06-16 苹果公司 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012169134A1 (ja) * 2011-06-09 2012-12-13 パナソニック株式会社 ネットワークノード、端末、帯域幅変更判断方法及び帯域幅変更方法
WO2013080471A1 (ja) * 2011-11-30 2013-06-06 パナソニック株式会社 ネットワークノード及び通信方法
US20130272194A1 (en) * 2012-04-17 2013-10-17 Telefonaktiebolaget L M Ericsson (Publ) Handover of calls between access networks
US20140328323A1 (en) * 2011-11-17 2014-11-06 Zte Corporation Method And System For Single Radio Voice Continuity Handover

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6856612B1 (en) * 1999-02-24 2005-02-15 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for call routing and codec negotiation in hybrid voice/data/internet/wireless systems
CN1262097C (zh) * 2000-08-14 2006-06-28 诺基亚公司 在通信系统中执行的编译码器选择方法以及通信系统
KR100659197B1 (ko) * 2000-09-05 2006-12-21 유티스타콤코리아 유한회사 통합 인터넷 프로토콜 망에서의 보코딩 방법
US6879600B1 (en) * 2002-06-03 2005-04-12 Sprint Spectrum, L.P. Method and system for intersystem wireless communication session arbitration
US20040131051A1 (en) * 2002-09-06 2004-07-08 Rafi Rabipour Methods and apparatus for data communication
US7443879B2 (en) * 2002-11-14 2008-10-28 Lucent Technologies Inc. Communication between user agents through employment of codec format unsupported by one of the user agents
US7680143B2 (en) * 2002-12-12 2010-03-16 Rpx Corporation Methods and apparatus for combining session acceleration techniques for media oriented negotiation acceleration
DE60319744D1 (de) * 2003-01-09 2008-04-24 Ericsson Telefon Ab L M Verfahren und vorrichtung zur codec-auswahl
WO2004075582A1 (en) * 2003-02-21 2004-09-02 Nortel Networks Limited Data communication apparatus and method for establishing a codec-bypass connection
US7305230B2 (en) * 2003-07-01 2007-12-04 Nokia Corporation System, apparatus, and method for providing a mobile server
DK1721435T3 (da) * 2004-03-04 2013-07-29 Ericsson Telefon Ab L M Fremgangsmåde og knudepunkt til udvælgelse af en type eller konfiguration af koder-dekoder ved udvidelse af listen omfattende koder-dekodere til omkoder/tandem-fri operation med andre koder-dekodere understøttet af knudepunktet
US7602901B1 (en) * 2004-07-21 2009-10-13 Sprint Spectrum L.P. System and method for providing calling-party identification and/or calling-party or called-party ringback services
US8700729B2 (en) * 2005-01-21 2014-04-15 Robin Dua Method and apparatus for managing credentials through a wireless network
US20080212575A1 (en) * 2005-06-15 2008-09-04 Lars Westberg Codec Rate Adaptation as a Function of Air-Interface as Wel as Network in a Packet-Based Network
CN101218579B (zh) * 2005-07-11 2012-12-19 派克维迪奥公司 转移数据的系统和方法
US7974270B2 (en) * 2005-09-09 2011-07-05 Kineto Wireless, Inc. Media route optimization in network communications
WO2007034809A1 (ja) * 2005-09-20 2007-03-29 Taisho Pharmaceutical Co., Ltd. 組み換え蛋白質産生のための宿主細胞
DE102005050588B4 (de) * 2005-10-21 2010-07-08 Siemens Ag Signalisierung bezüglich des Aufbaus von H.324 Videotelefonie zwischen einer Mediagateway und einem Controller
WO2007056660A1 (en) * 2005-11-02 2007-05-18 Sun Chemical Corporation Flexographic and gravure printing inks for nonwoven substrates
US7835346B2 (en) * 2006-01-17 2010-11-16 Genband Us Llc Methods, systems, and computer program products for providing transcoder free operation (TrFO) and interworking between unlicensed mobile access (UMA) and universal mobile telecommunications system (UMTS) call legs using a media gateway
US7787377B2 (en) * 2006-02-03 2010-08-31 Telefonaktiebolaget Lm Ericsson (Publ) Selective redundancy for Voice over Internet transmissions
WO2007095071A2 (en) * 2006-02-10 2007-08-23 Packetvideo Corp. System and method for connecting mobile devices
WO2008024056A1 (en) * 2006-08-21 2008-02-28 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for adapting transmission of encoded media
EP3512226B1 (en) * 2007-02-02 2022-11-23 Huawei Technologies Co., Ltd. Method, device and system for establishing a bearer for a gsm network
WO2009090582A1 (en) * 2008-01-17 2009-07-23 Nokia Corporation Adaptive multi-rate codec bit rate control in a wireless system
US20090268635A1 (en) * 2008-04-29 2009-10-29 Gallagher Michael D Method and Apparatus for Mapping E-UTRAN Cells at Call Establishment
US20100172332A1 (en) * 2009-01-07 2010-07-08 Rao Anil M Method and apparatus for controlling a vocoder mode in a packet switched voice wirelss network
KR101523590B1 (ko) * 2009-01-09 2015-05-29 한국전자통신연구원 통합 인터넷 프로토콜망의 코덱 모드 제어방법 및 단말기
US9007914B2 (en) * 2009-09-30 2015-04-14 Qualcomm Incorporated Methods and apparatus for enabling rate adaptation across network configurations
WO2011095221A1 (en) * 2010-02-05 2011-08-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and network node for monitoring a quality of media transfer in a session initiation protocol based voice over internet protocol communications network
US8548460B2 (en) * 2010-05-25 2013-10-01 Qualcomm Incorporated Codec deployment using in-band signals
ES2749222T3 (es) * 2010-11-10 2020-03-19 Panasonic Ip Corp America Terminal y procedimiento de selección de modo de codificación
KR101843052B1 (ko) * 2011-10-25 2018-03-29 삼성전자주식회사 무선통신 시스템에서 서로 다른 망들을 이용한 음성 호의 연속성 제공을 위한 장치 및 방법
US9848339B2 (en) * 2011-11-07 2017-12-19 Qualcomm Incorporated Voice service solutions for flexible bandwidth systems
WO2014030714A1 (ja) * 2012-08-24 2014-02-27 日本電気株式会社 リモート通信システム、サーバ装置、リモート通信方法、および、プログラム
US8483699B1 (en) * 2012-08-29 2013-07-09 Sprint Spectrum L.P. Codec selection for wireless communication
US8908605B1 (en) * 2012-10-09 2014-12-09 Sprint Spectrum L.P. Coordination of codec assignment and radio configuration in wireless communications
US9526037B2 (en) * 2013-02-04 2016-12-20 Apple Inc. SRVCC handover indication for remote party to voice call
US9338718B2 (en) * 2013-03-14 2016-05-10 Apple Inc. Voice call resumption on a legacy network
US9386563B1 (en) * 2013-04-11 2016-07-05 Sprint Spectrum L.P. Coordination of codec consistency based on cross-carrier assignment
EP3038104B1 (en) * 2013-08-22 2018-12-19 Panasonic Intellectual Property Corporation of America Speech coding device and method for same
US9467480B2 (en) * 2013-09-16 2016-10-11 Qualcomm Incorporated Selectively multiplexing incoming WebRTC traffic and/or de-multiplexing outgoing WebRTC traffic by a client-based WebRTC proxy on behalf of a WebRTC multimedia client application
US9712425B2 (en) * 2014-05-23 2017-07-18 Telefonaktiebolaget Lm Ericsson (Publ) Maintaining optimal media routing
US20160204908A1 (en) * 2015-01-14 2016-07-14 Qualcomm Incorporated Adaptive multi-rate partial decode

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012169134A1 (ja) * 2011-06-09 2012-12-13 パナソニック株式会社 ネットワークノード、端末、帯域幅変更判断方法及び帯域幅変更方法
US20140328323A1 (en) * 2011-11-17 2014-11-06 Zte Corporation Method And System For Single Radio Voice Continuity Handover
WO2013080471A1 (ja) * 2011-11-30 2013-06-06 パナソニック株式会社 ネットワークノード及び通信方法
US20130272194A1 (en) * 2012-04-17 2013-10-17 Telefonaktiebolaget L M Ericsson (Publ) Handover of calls between access networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SAMSUNG: "Proposal for transcodingless SRVCC operation", 3GPP TSG-SA WG2#105 S 2-143766, 13 October 2014 (2014-10-13), XP050891518 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2727794C1 (ru) * 2017-05-18 2020-07-24 Фраунхофер-Гезелльшафт Цур Фердерунг Дер Ангевандтен Форшунг Е.Ф. Управляющее сетевое устройство
US11290509B2 (en) 2017-05-18 2022-03-29 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Network device for managing a call between user terminals

Also Published As

Publication number Publication date
US10911988B2 (en) 2021-02-02
JPWO2016185649A1 (ja) 2018-03-08
US20180041924A1 (en) 2018-02-08
CN107251610B (zh) 2020-09-25
JP6787884B2 (ja) 2020-11-18
CN107251610A (zh) 2017-10-13

Similar Documents

Publication Publication Date Title
JP6647364B2 (ja) 通信端末装置、通信方法及び集積回路
JP6434601B2 (ja) ネットワークノード及び通信方法
US10911988B2 (en) Communication node, terminal, and communication control method
JP6420328B2 (ja) ネットワークノード及びシグナリング処理方法
Bruhn et al. System aspects of the 3GPP evolution towards enhanced voice services

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017518732

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16796046

Country of ref document: EP

Kind code of ref document: A1