Network node and communication method

<img file="ES2728678T3_D0001.tif" />

SPANISH OFFICE OF

PATENT S Y MARCAS

ESPAÑA

<img file="ES2728678T3_D0002.tif" />

©Int. CL:

H04W 36/14

H04W 28/06

H04W 88/18

H04W 36/00

H04L 29/06 (2009.01) (2009.01) (2009.01) (2009.01) (2006.01)

TRADUCCIÓN DE PATENTE EUROPEA

T3 © Fecha de presentación y número de la solicitud internacional: 16.11.2012 PCT/JP2012/007358 © Fecha y número de publicación internacional: 06.06.2013 W013080471 © Fecha de presentación y número de la solicitud europea: 16.11.2012 E 12853666 (1) © Fecha y número de publicación de la concesión europea: 06.03.2019 EP 2787765 © Título: Nodo de red y procedimiento de comunicación © Prioridad:

30.11.2011 JP 2011261617 © Fecha de publicación y mención en BOPI de la traducción de la patente:

28.10.2019 © Titular/es:

PANASONIC INTELLECTUAL PROPERTY

CORPORATION OF AMERICA (100.0%) 20000 Mariner Avenue, Suite 200 Torrance, CA 90503, US © Inventor/es:

HOR I, TAKAKO @ Agent / Representative:

CARPINTERO LÓPEZ, Mario

ES 2 728 678 T3

Notice: Within nine months from the date of publication in the European Patent Bulletin, of the mention of granting the European patent, any person may object to the European Patent Office to the granted patent. The opposition must be in writing and be motivated; It will only be considered as formulated once payment of the opposition fee has been made (art. 99.1 of the Convention on the Grant of European Patents).

ES 2 728 678 T3

DESCRIPTION

Network node and communication procedure

Technical field

The present invention relates to a technique for continuing communication when a codec used by one of the terminals in a mobile communication system is changed.

Background Technique

In the related technique, calls from Voice in a mobile communication system of the third generation association project (3GPP) are performed using a 3GPP circuit switching network (CS). In recent years, a Long Term Evolution Voice (VoLTE) service has been initiated, providing a voice call using a 3GPP packet switching network (PS).

However, the area where VoLTE service is available is limited for a time. For this reason, when a user leaves the VoLTE service area during a voice call using VoLTE (hereafter referred to as VoLTE call), it is necessary to switch this call to a call based on a circuit switching technique. According to the related technique. As a technique that allows this switching, the continuity of a single radio voice call (SRVCC) is disclosed in the Patent Literature (hereinafter, abbreviated as NPL) 1. Hereinafter, an operation will be described. transfer ration based on SRVCC referring to figures 1 and 2.

Figure 1 is a diagram illustrating a part of a configuration of a 3GPP mobile communication network. The mobile communication network shown in Figure 1 is configured using an evolved universal terrestrial radio access network (e-UTRAN), an e-UTRAN base station (enodeB), a PS network, a CS network, a station subsystem CS network base and an IP Multimedia Subsystem (IMS).

Specifically, in Figure 1, e-UTRAN is a radio access network that is capable of providing the VoLTE service. The PS network provides VoLTE service and includes a data packet network gateway (P-GW), a service gateway (S-GW) and a mobility management entity (MME). The CS network includes a mobile switching center (MSC) and a media gateway (MGW). The base station subsystem of the CS network includes a radio network controller (RNC) and nodeB. He IMS performs call control or similar and includes a call session control function (CSCF) and a centralization and service continuity application server (SCC AS). It should be noted that in Figure 1 and Figure 2, MSC and MGW are represented as a single node (MSC / MGW 110), but can be provided as separate nodes.

In Figure 1, it is assumed that UE 100 and UE 102 which are mobile communication terminals (user equipment) are initially connected to the PS network, respectively (here, a radio access network, a base station and a PS network on the side of UE 102 are not shown). That is, it is assumed that a VoLTE call is made between the UE 100 and the UE 102. Here, it is assumed that the UE 100 is transferred (TR) to the CS network during the call.

Route A, Route B and Route C indicated by solid lines in Figure 1 represent routes through which voice data passes. In addition, reference numbers 200, 202, 204 and 206 indicated by dashed lines in Figure 1 represent the routes through which the signals pass in an SRVCC handover process.

Figure 2 is a sequence diagram illustrating an operation of the SRVCC handover process. The UE 100 and the UE 102 are initially connected to the PS network (e-UTRAN), respectively, and the voice data between the UE 100 and the UE 102 is transmitted and received via Route A. If the Ue 100 is remote from a coverage area of ​​the e-UTRAN, enodeB detects the fact and exchanges signaling with RNC / nodeB through MME and MSC / MGW 110 (signaling 200 shown in Figure 1 and stage (from here hereinafter, referred to as ST) 200 shown in Figure 2). In ST200, a data path is prepared in the CS network between nodeB and MSC / MGW 110. If the preparation is completed, a command is given to the UE 100 from MME to e-nodeB for transfer to UTRAN (CS network).

At the same time as with the ST200 process, the MSC / MGW 110 i Exchange signals with UE 102 via CSCF / SCC AS (signaling 202 shown in Figure 1 and ST202 shown in Figure 2). Therefore, a command is given to switch a voice data transmission / reception destination of the UE 102 from the UE 100 to the MSC / MGW 110, and Route B is established.

After the transfer to UTRAN, the UE 100 exchanges signaling with the MSC / MGW 110 via RNC / nodeB (the signaling 204 shown in Figure 1 and ST204 shown in Figure 2). Therefore, Route C is established.

ES 2 728 678 T3

After the establishment of Route C, the MSC / MGW 110 exchanges signaling with P-GW / S-GW through MME (signaling 206 shown in Figure 1 and ST206 shown in Figure 2). Therefore, Route A is eliminated.

In the aforementioned, the operation of the SRVCC handover has been described.

In addition, as a technique that improves SRVCC to reduce the time needed to commute In the data paths, there is an SRVCC procedure (eSRVCC: enhanced SRVCC) that uses improved access transfer control (ATCF) function, as disclosed in NPL 3. An example of an eSRVCC operation will be described referring to figures 3 and 4.

Figure 3 shows a part of a configuration of a 3GPP mobile communication network that allows eSRVCC. The mobile communication network shown in Figure 3, similar to Figure 1, includes eUTRAN, e-nodeB, a PS network, a CS network, a base station subsystem of the CS and IMS network. Here, an access transfer control (ATCF) function and an access transfer gateway (ATGW), in addition to CSCF and SCC AS, are present in IMS. In Figures 3 and 4, ATCF and ATGW are represented as a single node (ATCF / ATGW 320), but can be provided as separate nodes.

In Figure 3, UE 100 and UE 102 are initially connected to the PS network, respectively (Here, a wireless access network, a base station and the PS network on the side of the UE 102 are not shown). That is, it is assumed that a VoLTE call is made between the UE 100 and the UE 102. Here, it is assumed that the UE 100 is transferred to the CS network during a call.

Route A, Route B, Route C and Route D indicated by solid lines in Figure 3 represent routes through which voice data passes. In addition, reference numbers 300, 302, 304 and 306 indicated by dashed lines in Figure 3 represent routes through which the signals pass in an eSRVCC handover process.

Figure 4 is a sequence diagram illustrating an eSRVCC handover operation. Initially, UE 100 and UE 102 are connected to the PS network (e-UTRAN). In a system in which the eSRVCC handover is performed, in the ATCF / ATGW 320, the ATCF anchors the IMS signaling (IMS signaling), and the ATGW anchors the voice data. That is, when in If a call between the UE 100 and the UE 102, the IMS signaling for the initiation of the call is retransmitted by the ATCF, and in a case where the ATCF determines that the anchoring of the voice data in the ATGW is necessary, the ATGW is assigned as an anchor point for voice data. Therefore, voice data between UE 100 and UE 102 is transmitted and received through Route A and Route B.

If the UE 100 is remote from an eUTRAN coverage area, e-nodeB detects this fact and exchanges the signaling with RNC / nodeB through MME and MSC / MGW 110 (signaling 300 shown in Figure 3 and ST300 shown in Figure 4). In ST300, a data path is prepared in the CS network between nodeB and MSC / MGW 110. If the preparation is completed, a command is given for the transfer to UTRAN (CS network) to the UE 100 from MME via e- nodeB.

Simultaneously with the ST300 process, the MSC / MGW 110 transmits the signaling to the ATCF. Therefore, a pa command is given ra route switching to the ATGW from the ATCF, and an ATGW voice data transmission / reception destination is switched from the UE 100 to the mSc / MGW 100 (signaling 302 shown in Figure 3 and ST302 shown in Figure 4). That is, Route C is established. In addition, if the route switching process to the ATGW ends, the ATCF transmits the indication signaling to the SCC-AS (signaling 302 shown in Figure 3 and ST302 shown in Figure 4).

After the transfer to UTRAN, the UE 100 exchanges the signaling with the MSC / MGW 110 through RNC / nodeB (signaling 304 shown in Figure 3 and ST304 shown in Figure 4). Therefore, Route D is established

After the establishment of Route D, the MSC / MGW 110 exchanges signaling with P-GW / S-GW through MME (signaling 306 shown in Figure 3 and ST306 shown in Figure 4). Therefore, Route B is removed.

In the aforementioned, it must be I scan the operation of the eSRVCC handover.

As a voice codec used in the CS network, a multi-speed adaptive broadband codec (AMR-WB) which is a broadband codec (WB) is generally used. AMR-WB can be used in a packet exchange technique and, therefore, can also be considered to be used in the PS (VoLTE) network.

There is also a codec that supports an AMR-WB compatible mode as another codec other than AMR-WB used in the PS (VoLTE) network such as the Enhanced Voice Service (EVS) described, for example, in NPL 4. It assumes that the AMR-WB compatible mode will be used as an AMR-WB codec with a legacy terminal that normally supports an AMR-WB codec. Therefore, when the codec is used in the PS (VoLTE) network, an RTP payload format of the AMR-WB codec described in NPL 2 can be used.

ES 2 728 678 T3

In the related technique, the narrowband codec (NB) is a codec that performs the encoding and decoding processing on a digital acoustic signal sampled at 8kHz. The narrowband codec generally has a frequency band of 300Hz to 3.4kHz, but the frequency band is not limited to this and may be within a range of 0 to 4kHz. On the other hand, the broadband codec is a codec that performs encoding and decoding processing on a digital acoustic signal sampled at 16kHz. The broadband codec generally has a frequency band of 50Hz to 7kHz, but the frequency band is not limited to this and may be within a range of 0 to 8kHz. A superanch band codec (SWB) is a codec that performs the encoding and decoding process of a digital acoustic signal sampled at 32kHz. The superanch band codec generally has a frequency band of 50Hz to 14kHz, but the frequency band is not limited to this and may be within a range of 0 to 16kHz.

In addition, document US 200 7/173239 discloses a technique for a first mobile terminal that has an ongoing call with a second terminal under a first communications service through a base station of the access network of a first subsystem. A condition is detected for transferring the call to a base station of the radio access network of a second subsystem in a radio network controller of the first subsystem. A central network switch that is linked to the radio network controller of the first subsystem is informed of said detection of a call transfer condition. If the second subsystem cannot process the call under the first communications service, a service change is requested so that the call can continue under the second communications service.

Appointment List

Non-Patent Literature

NPL 1 3GPP TS23.216 v9.6.0 Single Radio Voice Call Continuity (SRVCC)

NPL 2 IETF RFC 4867, RTP Payl oad Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs

NPL 3 3GPP TS23.237 v11.0.0 IP Multimedia Subsystem (IMS) Service Continuity

NPL 4 3GPP TR22.813 v10.0.0 Study of Use Cases and Requirements for Enhanced Voice Codecs for the Evolved Packet System (EPS)

NPL 5 Takashi Koshimizu and Katsutoshi Nishida, Audio Video Call Application of Single Radio Voice Call Continuity, General meeting of the Institute of Electronics, Information and Communication Engineers in 2011, B-6-77

NPL 6 3GPP TS26.114 v10.0.0 IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction

NPL 7 G. Zorn (Ed), RTP Payload Format for G.718 Speech/Audio, November 15, 2011, work in progress

NPL 8 3GPP TR23.885 v11.0.0 Feasibility Study of Single Radio Voice Call Continuity (SRVCC) from UTRAN/GERAN to E-UTRAN/HSPA

Sumario de la invención

Technical problem

In Figure 1 or Figure 3, when the UE 100 is transferred from the PS network to the CS network, in case the codec used in the PS network is not compatible with the CS network, the codec used by the UE 100 is changed to a codec supported by the CS network. In the event that a codec change occurs in the UE 100, to allow continuity of the call between the UE 100 and the UE 102, the following two procedures can be considered. The first procedure is a procedure for transcoding in the MSC / MGW or the ATCF / ATGW. The second procedure is a procedure for changing the codec used by the UE 102 to the same codec as the changed codec of the UE 100.

In the procedure for transcoding, which was mentioned first, the quality of the call deteriorates due to transcoding.

On the other hand, in the codec change procedure, which was mentioned later, although There is no deterioration in the quality of the call that occurs in the transcoding procedure, the signaling used to change the codec of the UE 102 takes time and prolongs the call disconnection time, which is not favorable . In addition, in the eSRVCC handover, because the signaling for the route switching in the handover of the UE 100 is terminated in the ATCF, it is difficult to transmit the signaling for

It is 2 728 678 T3 to change the codec of the UE 102. That is, in the transfer of eSRVCC, it is difficult to change the codec of the UE 102 using the existing signaling.

An object of the present invention is to provide a technique that allows communication to continue and also to reduce the disconnection time of a call without deteriorating the quality of the call even when changing a codec used by one of the terminals in communication.

Solution to the problem

The invention is presented nta through the content of the independent claims. Preferred embodiments are claimed in the dependent claims.

In a useful example for understanding the background of the present invention, a network node transfers data between the two terminals, when one of the two terminals performing communication in a first network performs a transfer to a second network that is different from the First network, the network node that includes: a detection section that detects a first codec used by one of the two terminals in the first network and a second codec to be used by one of the two terminals in the second network; a generation section that generates, when the first codec is a codec that has a compatible mode that is compatible with the second codec, data for the other of the two terminals by switching a data codec transmitted from one of the two terminals to the compatible mode of the first codec; and a section of work A transmission that transmits data for the other of the two terminals to the other of the two terminals.

In another example, a communication procedure for transferring data between the two terminals, when one of the two terminals performing the communication in a first network performs a transfer to a second network that is different from the first network, the communication procedure that includes: detecting a first codec used by one of the two terminals in the first network and a second codec to be used by one of the two terminals in the second network; generate, when the first codec is a codec that has a compatible mode that is compatible with the second codec, data for the other of the two terminals by switching a codec of data transmitted from one of the two terminals to the compatible mode of the first codec; and transmit, to the other of the two terminals, data for the other of the two terminals.

Advantageous effects of the invention

According to l In the present invention, even when one of the terminals in communication changes a codec in use, it is possible to continue the communication and also reduce the disconnection time of a call without causing deterioration of the quality of the call.

Brief description of the drawings

Figure 1 is a configuration diagram illustrating part of a 3GPP mobile communication network;

Figure 2 is a sequence diagram illustrating an SRVCC handover operation;

Figure 3 is a configuration diagram illustrating part of a 3GPP mobile communication network that allows eSRVCC;

Figure 4 is a sequence diagram illustrating an eSRVCC handover operation;

Figure 5 illustrates an example of an RTP payload format in accordance with Embodiment Mode 1 of the present invention;

Figure 6 illustrates an example of an SDP offering and an SDP response according to the M Embodiment 1 of the present invention;

Figure 7 is a block diagram illustrating a configuration of a terminal (UE) in accordance with Embodiment Mode 1 of the present invention;

Figure 8 is a block diagram illustrating a configuration of a network node (MSC / MGW) in accordance with Embodiment Mode 1 of the present invention;

Figure 9 is a flowchart illustrating an example of codec switching processing in the MSC / MGW according to Embodiment Mode 1 of the present invention;

Figure 10 illustrates an example of how a codec switching request is indicated in Embodiment Mode 1 of the present invention; and

Figure 11 is a block diagram illustrating a configuration of a terminal (UE) in accordance with Embodiment Mode 3 of the present invention.

ES 2 728 678 T3

Description of the embodiments

The embodiments of the present invention will be described in detail with reference to the accompanying drawings.

In the following description, the term bandwidth refers to a bandwidth of a signal that serves as input / output of a codec.

In the following description, a codec available both in a PS network and in a CS network is represented by codec A. Codec A has a dedicated payload format. Codec A is, for example, AMR-WB or AMR-NB.

A codec available for the PS network is represented by codec B. Codec B includes an unsupported mode (mode not compatible with codec A) and a compatible mode (mode compatible with codec A) with respect to codec A. However , codec B can be used in the CS network. Codec B is, for example, EVS or G.718 described in NPL 7.

(Embodiment 1)

Figure 5 illustrates an example of a payload format (payload format of RTP) of codec B. As shown in Figure 5, the payload format consists of a data portion and a header portion. The data portion includes data encoded by an encoder and the header portion includes information necessary for a decoder to decode data from the data portion.

The payload format of codec B in the present embodiment is configured to allow the receiving payload side to identify whether the data portion includes data in the mode not compatible with codec A or data in the mode compatible with the codec A. For example, as shown in Figure 5, the header portion includes a codec type field and a bit rate field. The codec type includes information that indicates whether the codec is in the mode that is not compatible with codec A or in the mode that is compatible with codec A. The bit rate includes information that indicates which bit rate is encoded. s data between bit rates supported in mode not compatible with codec A or bit rates supported in mode compatible with codec A.

As shown in Figure 5, in addition to the fields described above, it is also possible to include a field to issue, to a homologous terminal on the receiving side of the payload, the request for switching of the codec type or bit rate (field request for codec type change / bit rate). It should be noted that this field does not need to be included for each frame, and can be included only when necessary.

The procedure has been described so far with the payload format of codec B shown in Figure 5 in which the header portion explicitly includes the field to implement the configuration that allows the receiving side of the payload to identify whether the portion data includes data in the mode not compatible with codec A or data in compatibility mode e with codec A (codec type field, bit rate field) and the field to emit, to the counterpart terminal, a codec type or bit rate switching request (codec type / bit rate switching request field). However, the procedure does not always have to be the procedure shown in Figure 5. In addition, an example has been described in the payload format shown in Figure 5, where the payload format consists of the header portion and the data portion, but the header portion can be omitted in the format payload if the terminal on the receiving side that has received the payload can correctly decode data without the header portion.

The payload format of codec B is not limited to the example shown in Figure 5, and a combination of layers (corresponding to bit rates) can be described as separate values, for example, in the case of the format of G.718 payload described in NPL 7.

Next, Figure 6 illustrates an example of a session description protocol (SDP) offering and an SDP response exchanged between terminals in the session negotiation when a call begins.

Here, it is assumed that both UEs making a call support codec B and that both UEs are connected to the PS network when the call is initiated.

As shown in Figure 6, the UE that supports codec B describes codec A and codec B in an SDP offering even when the UE does not support codec A. This is because when the homologous terminal supports the codec A but does not support codec B, codec A is selected in codec negotiation to allow the use of codec compatible mode A of codec B using the RTP payload format of codec A. In Figure 6, the UE that has received the SDP offer selects codec B and describes codec B selected in the SDP response.

ES 2 728 678 T3

The SDP offering and the SDP response may also include the description in a preferential mode (mode not compatible with codec A or mode compatible with codec A, bit rate, bandwidth or the like) when codec B is selected The preferential mode can be predetermined by an operator performing a communication service and incorporated into the UE in the form of software, or the like. In the present embodiment, when codec B is selected, it is assumed that the mode not compatible with codec A is used as a preferential mode.

Next, the mobile communication network (Figure 1) will be described in accordance with the present embodiment.

First, the UE 100 or 102 shown in Figure 1 will be described.

Figure 7 is a block diagram illustrating a configuration of UE 100 and 102 (terminal) in accordance with the present embodiment ion. The UEs 100 and 102 are each configured by the reception section 700, the transmission section 702, the codec negotiation section 704, the RTP payload analysis section 706, the payload generation section 708 of RTP and codec report section 710.

In UEs 100 and 102 shown in Figure 7, the reception section 700 receives communication data (including the RTP payload) and signaling or the like. For example, when an RTP payload is received (for example, see Figure 5) transmitted from the MSC / MGW 110, the receiving section 700 sends the received RTP payload to the RTP payload analysis section 706 .

The transmission section 702 transmits communication data (including the RTP payload) and signaling or the like.

Codec negotiation section 704 negotiates a codec to use for communication between terminals (UE 100 and UE 102). More specifically, the s Codec negotiation section 704 creates an SDP offer or an SDP response (for example, see figure 6) and performs the codec negotiation. In this case, when creating an SDP offer, section 704 of codec negotiation includes codec A in the offer of SDP as shown in Figure 6 even when the terminal supports codec B but does not support codec A as it is described above. When codec B is selected in the negotiation, the codec negotiation section 704 selects a preferential mode (mode not compatible with codec A or mode compatible with codec A, bit rate, bandwidth or the like) according to the information described in the offer and the response of the SDP as described above or information previously incorporated in the software or the like and sends the preferential mode to the 708 section of RTP payload generation.

Section 706 of RTP payload analysis analyzes the portion of header of the RTP payload received from the receiving section 700 and identifies the information relating to the data included in the data portion of the RTP payload (for example, codec type, bit rate or the like). Section 706 of RTP payload analysis sends the identified information and data included in the data portion to a decoder (not shown). When the RTP payload received from the receiving section 700 includes a codec type / bit rate switching request instruction, the RTP payload analysis section 706 sends the instruction to an encoder (not shown) already section 708 of RTP payload generation. The encoder encodes the data based on the information and instructions in section 706 of RTP payload analysis.

RTP payload generation section 708 generates an RTP payload (for example, see figure 5) that includes information (eg plo, type of codec, bit rate) related to the data received from the encoder and the data received from section 704 of codec negotiation. In this case, upon receiving an instruction from a codec / bit rate switching request of the RTP payload analysis section 706, the RTP payload generation section 708 generates an RTP payload in basis for instruction. The generated RTP payload is transmitted through transmission section 702.

When the UE of the codec report section 710 transfers the PS network to the CS network, the codec report section 710 informs the network node (for example, MME) of the PS network of the codec used by the UE in the PS network. The reported codec is indicated to the MSC / MGW 110 through a network node (MME) of the PS network.

Next, the MSC / MGW 110 shown in Figure 1 will be described. Figure 8 is a block diagram illustrating a configuration of l MSC / MGW 110 (network node) in accordance with the present embodiment. The MSC / MGW 110 is configured by receive section 800, transmission section 802, codec detection section 804, codec negotiation section 806, RTP payload generation section 808 and section 810 of RTP payload analysis.

In the MSC / MGW 110 shown in Figure 8, the receiving section 800 receives communication data (including the RTP payload) and signaling or the like. For example, upon receiving the RTP payload (for example, see Figure 5) transmitted from the UE 102, the receiving section 800 sends the received RTP payload to the RTP payload analysis section 810.

ES 2 728 678 T3

The transmission section 802 transmits the communication data (including the RTP payload) and signaling or the like.

Codec detection section 804 detects a codec to be used by a terminal that has made the transfer from the PS network to the CS network (UE 100 in Figure 1) in the CS network. The codec detection section 804 also detects a codec used by a terminal that has transferred the PS network to the CS network (UE 100 in Figure 1) in the PS network. The codec detection procedure used by the terminal (UE 100) in the PS network may be a procedure such as that disclosed in NPL 5 which is indicated from the network node (MME or similar) in the Ps network when the UE 100 (section 710 of codec report) performs the transfer to the CS network. Alternatively, the codec detection procedure used by the terminal (UE 100) in the PS network can be a procedure by which the codec is acquired from other network nodes such as the SCC AS. The codec detection procedure used by the terminal (UE 100) in the CS network may be a procedure that uses information negotiated through the signaling transmitted / received between the UE 100 and the network node (RNC and MSC / MGW 110) in the CS network when the UE 100 transfers to the CS network. Codec detection section 804 sends the codec detection result to section 808 of RTP payload generation.

Section 806 of codec negotiation negotiates the codec to be used with the UE according to an instruction, for example, of section 808 of RTP payload generation. For example, codec negotiation section 806 negotiates (renegotiates) the codec to be used with the terminal (UE 102 in Figure 1) which is the communication counterpart of the terminal (UE 100 in Figure 1) that has performed the transfer from the PS network to the CS network.

RTP payload generation section 808 generates data (RTP payload) for the terminal communication counterpart (UE 102 in Figure 1) using the data received from the terminal (UE 100 in Figure 1) on the basis to the codec detection result received from section 804 of dete Codec ction For example, when the codec used by the terminal that has transferred the PS network to the CS network in the CS network is codec A and when the codec used by the terminal in the PS network is codec B, the section RTP payload generation 808 switches the codec of the data (codec data A) received from the terminal to a mode compatible with codec A of codec B. That is, the MSC / MGW 110 transmits the codec A data received from the terminal while the codec compatible mode A of the codec B using the RTP payload format of the codec B (see Figure 5) through section 802 of transmission.

When the codec detection result received from the codec detection section 804 is different from that described above, the RTP payload generation section 808 instructs the codec negotiation section 806 to negotiate (renegotiate) a codec with the communication counterpart (EU 102 in figure 1) what is the dest Inno of transmission of the received data. RTP payload generation section 808 performs the transcoding, if necessary, of the communication data received from the terminal that performed the handover, based on the negotiation result and switches the mode to a codec mode based on to the result of the negotiation. The data after the codec switching (generated RTP payload) is transmitted through the transmission section 802.

Section 810 of the RTP payload analysis analyzes the header portion of the RTP payload transmitted from the terminal (UE 102) and identifies the information related to the data (e.g. codec type, bit rate) included in the data portion of the RTP payload. Section 810 of RTP payload analysis sends the specified information to section 804 of codec detection.

Next, the details of the codec processing will be described in the MSC / MGW 110 (Figure 8) using Figure 9. Here, a case will be described where, as shown in Figure 1, the UE 100 transfers the PS network to the CS network while both the UE 100 and the UE 102 are connected to the PS network and are making a call. That is, the MSC / MGW 110 is a network node that transfers data between two terminals when a UE 100 of the two terminals (UE 100 and 102) that communicates on the PS network transfers to the CS network.

In ST900 shown in Figure 9, the RTP payload generation section 808 determines whether the codec used by the UE 100 in the CS network is codec A or not based on the detection result in the detection section 804 of codec

When the codec used by the UE 100 in the CS network is codec A (ST900: SI), in ST902, the section 808 of RTP payload generation determines whether the codec used by the UE 100 in the PS network (before of the transfer) is codec B or not based on detection result in section 804 codec detection.

When the codec used by the UE 100 in the PS network is codec B (ST902: YES), in ST904, the RTP payload generation section 808 switches the data codec (codec A) transmitted from the UE 100 to a mode compatible with codec A of codec B. That is, the RTP payload generation section 808 transforms the codec A data transmitted from the UE 100 into a mode compatible with the codec A of the codec B using the RTP payload format of the codec B and transmits the data to UE 102 through transmission section 802.

ES 2 728 678 T3

This allows UE 102 using codec B to handle the data transmitted from MSC / MGW 110 to UE 102 as data from codec B (mode compatible with codec A of codec B).

On the other hand, when the codec used by the UE 100 in the CS network is not codec A (ST900: NO) or when the codec used by the UE 100 in the PS network is not codec B (ST902: NO), in sT906, section 806 of codec negotiation performs a session renegotiation with UE 102 and determines the codec. The 808 RTP payload generation section generates an RTP payload of the determined codec.

Alternatively, in ST906, the MSC / MGW 110 can transcode the data transmitted from the UE 100 and transmit the transcoded data (data for the UE 102) to the UE 102.

Therefore, when a change in the codec of one UE is detected, the MSC / MGW 110 determines whether the data codec for the other UE can be switched based on the codec after the change of the UE and the codec before the change of the UE.

Next, an example of operation of the UE 100 or 102 (figure 7) and the MSC / MGW 110 (figure 8) in the present embodiment will be described.

In the following description, in Figure 1 and Figure 2, both the UE 100 and the UE 102 are connected to the r PS ed and initiate a call. Here, suppose a call is made from UE 100 to UE 102.

When a call is initiated, a codec is negotiated for use between UE 100 and UE 102. For example, UE 100 (section 704 of codec negotiation) generates an SDP offer (for example, see figure 6) and transmits the offer of SDP to UE 102. On the contrary, UE 102 (codec negotiation section 704) generates an SDP response (for example, see figure 6, codec B is selected in figure 6), and transmits the SDP response to UE 100. Upon completion of the operation of an example associated with this call initiation, the UE 100 or 102 makes a call using a mode not compatible with codec A of codec B (preferential mode when codec B is selected) (Figure 2: Session of Voice over PS).

Then, as shown in Figure 1, the UE 100 transfers the PS network to the CS network (ST200 and ST204 shown in the figure two). Here, suppose that the codec used by the UE 100 in the CS network is codec A.

Simultaneously with the handover processing of the UE 100, the MSC / MGW 110 (section 804 codec detection) detects the codec that the UE 100 will use when handover to the CS network. The MSC / MGW 110 (section 804 codec detection) also detects the codec used by the UE 100 in the PS network. As described above, the MSC / MGW 110 detects that the codec used by the UE 100 in the CS network is codec A and the codec used by the UE 100 in the PS network is codec B (ie, ST900 shown in Figure 9: YES and ST902: YES).

In this case, the MSC / MGW 110 (section 808 of RTP payload generation) switches the codec of the data transmitted from the UE 100 (codec A) to a mode compatible with codec A of codec B and, of this mode, generates an RTP payload for UE 102. That is, the MSC / MGW 110 transmits the codec A data transmitted from the UE 100 as a mode compatible with codec A of codec B to UE 102 using the RTP payload format of codec B.

In this case, when the RTP payload generation section 808 switches the codec of the data transmitted from the UE 100, the MSC / MGW 110 may transmit a request to switch in a manner not compatible with codec A to a mode compatible with codec A to UE 102, which is the communication counterpart of UE 100. For example, in the RTP payload format of codec B (for example, see figure 5), the MSC / MGW 110 (section 808 of RTP payload generation) may include an instruction to switch from unsupported mode with codec A to the mode compatible with codec A in the header portion (codec type change / bit rate request field).

On the other hand, UE 102 (section 706 of RTP payload analysis) determines that the data included in the data portion of the RTP payload is codec A (codec that can be managed as a mode compatible with codec A) from the information included in the data received from mSc / MGW 110 (information from the header portion of the RTP payload) and transfers the information and the data to the decoder. This causes the decoder of the UE 102 to recognize that the codec of the received data is codec A (mode compatible with codec A of codec B) and decodes the data.

When the received RTP payload includes a request to switch from mode not compatible with codec A to mode compatible with codec A, UE 102 (for example, section 706 of RTP payload analysis) sends the request to switch to an encoder (not shown) and section 708 of RTP payload generation. This causes the UE 102 to determine the use of the codec compatible mode A of the codec B also for data transmitted from the UE 102. That is, UE 102 (section 708 of payload generation RTP) stores the data in the mode compatible with codec A received from the encoder in the payload format of codec B and transmits the data to mSc / MGW 110.

ES 2 728 678 T3

Therefore, according to the present embodiment, in the MSC / MGW 110, the codec detection section 804 detects the codec used by the UE 100 in the PS network and the codec to be used by the UE 100 in the CS network, and when the codec used by the UE 100 in the PS network is a codec that has a mode compatible with the codec used by the UE 100 in the CS network, RTP payload generation section 808 generates data for UE 102 by switching the data codec transmitted from the UE 100 to a compatible mode of the codec used by the UE 100 in the PS network. That is, when the codec used by the UE 100 in the PS network is a codec that has a mode compatible with the codec used by the UE 100 in the CS network, the MSC / MGW 110 transmits the data of the codec A transmitted from UE 100 in codec compatible mode using the RTP payload format of codec B. This allows UE 102 using codec B to receive data from UE 100 without changing the codec of UE 102.

That is, the MSC / MGW 110 switches the codec data after the transfer from the UE 100 to part of a codec before the transfer (one of the codec modes before the transfer), eliminates the need to signal to change the codec between the UE 100 and UE 102 and can thus prevent the disconnection time of a call from being prolonged. The MSC / MGW 110 switches only the codec mode without changing the codec data between the UE 100 and the UE 102 and can thus prevent deterioration of call quality as opposed to transcoding. Therefore, according to the present embodiment, even when the codec used by one of the terminals in the communication is changed, it is possible to continue the communication and also reduce the time mpo disconnecting a call without causing deterioration of call quality.

According to the present embodiment, when a codec of data transmitted from one terminal (UE 100) is switched, the MSC / MGW 110 transmits, to the other terminal (UE 102), a request to switch to a compatible mode for the data transmitted by the other terminal (UE 102). The UE 102 then transmits data in the codec compatible mode according to the request to switch to codec compatible mode from the MSC / MGW 110. This allows the MSC / MGW 110 and the UE 100 to handle the data transmitted from the UE 102 (mode compatible with codec A of codec B) as codec data A.

It should be noted that the indication of the switching request from mode not compatible with codec A to mode compatible with codec A to UE 102 does not always need to be included in the RTP payload from MSC / MGW 110 to UE 102. example, the request for with mutation can be indicated to UE 102 as an offer of SDP shown in Figure 10 in the INVITE SDP with the SDP-MGW transmitted from MSC / MGW 110 in ST202 shown in Figure 2. In addition, the switching request described above can be indicated from MSC / MGW 110 to UE 102 using the RTCP-APP disclosed in NPL 6.

When UE 102 receives data from codec A in the RTP payload format of codec B, UE 102 may determine that data from UE 102 (transmission data) should also be encoded in the mode compatible with codec A afterwards. of receiving the data. In this case, the switching request described above becomes unnecessary.

(Embodiment 2)

The present embodiment will be described using Fig. 3 and Fig. 4. In the following description, as in Embodiment 1, suppose that UE 100 and UE 102 make a call using codec B in to the PS network first, and only the UE 100 transfers the PS network to the CS network. In addition, the codec used by the UE 100 in the CS network is codec A.

The ATCF / ATGW 320 shown in Figure 3 and Figure 4 is simply a data anchor point. Therefore, when the ATCF / ATGW 320 shown in Figure 3 and Figure 4 is forwarding data from the UE 100 to the UE 102 or data from the UE 102 to the UE 100, the functions of the MSC / MGW 110 (Figure 8) and UE 100, UE 102 (Figure 7) are identical to those of Embodiment 1 (Figure 5 to Figure 9). However, the MSC / MGW 110 is different from that of Embodiment 1 only because INVITING with SDP in ST202 shown in Figure 2 cannot be used when a codec switching request (request to switch from an unsupported mode with codec A to a mode compatible with codec A), Ue 102 is indicated.

Assume that the ATCF / ATGW 320 has information about a codec used by the UE 100 in the Ru ta B shown in figure 3 and a codec used by the UE 102 in Route A shown in figure 3 or is provided with means capable of obtaining the information from another node.

In this case, even when the codec detection section 804 of the MSC / MGW 110 does not have information on the codec used by the UE 100 in the PS network (Route B shown in Figure 3), the ATCF / ATGW 320 may indicate , to MSC / MGW 110, the codec information used by the UE 100 in the PS network as an INVITE response message with the SDP-MGW in the ST302 shown in Figure 4.

Therefore, the MSC / MGW 110 (section 808 of RTP payload generation) can immediately identify a codec used by the UE 100 (terminal that has performed the handover) in the PS network. That is, the MSC / MGW 110 can establish the data transmitted from the UE 100, based on the codec used by the UE 100 (terminal that has performed the transfer) in the PS network in a mode compatible with the code ec A using the payload format of

ES 2 728 678 T3

RTP of codec B, and immediately transmit the data to UE 102. Similarly, the MSC / MGW 110 can immediately transmit, to UE 102, a switching request to UE 102.

In accordance with the present embodiment, even in the case of an eSRVCC scheme or a case in which the codec used by one of the communication terminals is changed as in Embodiment 1, it is possible to continue the communication while reduces the disconnection time of a call without causing deterioration of the quality of the call.

(Embodiment 3)

In this embodiment, a description of a case will be provided in which a terminal that has made the transfer from the PS network to the CS network (UE 100 in Figure 1) returns to the PS network.

Figure 11 is a block diagram illustrating a configuration of UE 100 and 102 (terminal) of ac I agree with the present embodiment. In Figure 11, identical components to those of Embodiment 1 (Figure 7) will be assigned the same reference numbers and their description will be omitted.

In the UE 100 (102) shown in Figure 11, the terminal position identification section 1100 identifies a network (PS network or CS network) to which the UE 100 (102) of the identification identification section 1100 is connected The position of the terminal, that is, section 1100 identifying the position of the terminal identifies the position of the UE 100 (102). This allows the UE 100 (102) to carry out the handover. The terminal position identification section 1100 may determine the position of the UE 100 (102) of the terminal position identification section 1100 from the destination base station ID (for example, e-nodeB or nodeB) or determine the position of the UE 100 or 102 from the establishment of the connection in the central network PS.

For example, suppose that the UE 100 that has transferred the PS network to the CS network returns back to the Ps network. Also, suppose that UE 100 uses codec A in the CS network. At this time, section 1100 of the terminal position identification identifies that the UE 100 has been connected to the PS network.

The UE 100 that has identified through the terminal position identification section 1100 that the UE 100 has connected to the PS network, switches the codec of the UE 100 from codec A to codec B (mode not compatible with codec A ). The RTP payload generation section 708 of the UE 100 generates an RTP payload using the codec B payload format. This RTP payload is transmitted to the UE 102 through the transmission section 702.

On the other hand, the RTP payload analysis section 706 of the UE 102 detects that the codec of the data received from the UE 100 has been changed in a manner compatible with the A au codec n mode not compatible with codec A. Section 706 of RTP payload analysis then transfers information to a decoder indicating that the codec of the UE 100 has been switched and the data. Therefore, the decoder of the UE 102 decodes the data received from the UE 100 in the mode not compatible with codec A of codec B.

When the received RTP payload includes a request to switch from mode compatible with codec A to mode not compatible with codec A, section 706 of UE RTP payload analysis 102 transfers this switching request to the encoder and section 708 of RTP payload generation. Accordingly, the UE 102 determines to use the mode not compatible with the codec A of the codec B also in the data transmitted from the UE 102. That is, the RTP payload generation section UE UE 102 stores the data in the mode not compatible with codec A transferred by the encoder in the payload format of the code ec B and transmits the data to UE 100.

The indication of the switching request from mode compatible with codec A to mode not compatible with codec A to UE 102 does not always need to be included in the RTP payload from UE 100 to UE 102. For example, the switching request it can be included in an IMS message described in NPL 8. The switching request can be indicated from MSC / MGW 110 to UE 102 using the RTCP-APP described in NPL 6.

Upon receiving the data in the mode not compatible with codec A in the RTP payload format of codec B, the UE 102 may determine that the data of the UE 102 (transmission data) should also be encoded in the mode not compatible with the codec A after receiving the data. In this case, the switching request described above becomes unnecessary.

Thus, even when the terminal that has made the transfer from the PS network to the CS network returns back to the PS network, the term inal changes the codec based on the current position of the terminal and, in this way, can continue the communication while reducing the disconnection time of a call without causing deterioration of the quality of the call.

In the aforementioned, embodiments of the invention have been described.

In the embodiments described above, the ATCF / ATGW 320, the MSC / MGW 110, and the SCC AS / CSCF have been described as a single node. However, the ATCF / ATGW 320, the MSC / MGW 110 and the SCC

ES 2 728 678 T3

AS / CSCF can each be configured by two or more different nodes that are connected to each other through an interface. That is, the function described above can be distributed over a plurality of nodes between the ATCF and ATGW, between the MSC and MGW, and between the SCC As and CSCF.

In addition, in the respective embodiments described above, the description has been made primarily using zando the codec relative to the voice. However, the invention is not limited to this, and can be applied to music, sound, images or the like.

Furthermore, the present invention is not limited in any way to the embodiments described above, and various modifications are possible.

Although the above embodiments have been described for the hardware implementation example of the present invention, the present invention can be implemented with software, in conjunction with hardware.

Each of the functional blocks used in the descriptions of the embodiments is normally carried out by means of LSI (large-scale integration), which is an integrated circuit. Each of the functional blocks can be a single separate chip, or some or all of the functional blocks can be made together on a single chip. In this document the term LSI is used, but the integrated circuit can be called narse CI (integrated circuit), a system LSI device, a super-LSI device or an ultra-LSI device depending on the difference in the degree of integration.

In addition, the integrated circuit is not limited to the LSI and can be implemented by a dedicated circuit or by a general purpose processor. In addition, an FPGA (field programmable door array), which is programmable, or a reconfigurable processor that allows reconfiguration of the connections or configurations of the circuit cells in the LSI after LSI production can be used.

In addition, in the event that a technology for circuit integration emerges that replaces LSI technology with advances in semiconductor technology or technology derived therefrom, said technology can be used to integrate the functional blocks. For example, biotechnology can be applied.

Industrial applicability

List of signs reference

100, 102 EU

200, 202, 204, 206, 300, 302, 304, 306 Signaling

110 MSC / MGW

320 ATCF / ATGW

700, 800 Reception section.

702, 802 Transmission section

704, 806 Codec negotiation section.

706, 810 RTP payload analysis section

708, 808 RTP payload generation section

710 Codec Report Section

804 Codec Detection Section

1100 Codec position identification section

ES 2 728 678 T3