Network node and communication method

TECHNICAL FIELD

0001The present invention relates to a network node and a communication method for changing a codec used in a mobile communication system.

BACKGROUND ART

0002In the related art, voice calls in a mobile communication system of the third generation partnership project (3GPP) are made using a 3GPP circuit switching (CS) network. In recent years, a Voice over Long Term Evolution (VoLTE) service, which provides a voice call using a 3GPP packet switching (PS) network, has been started.

0003However, the area where the VoLTE service is available is limited for a while. For this reason, when a user moves out of the VoLTE service area during a voice call using on VoLTE (hereinafter, refer to as VoLTE call), it is necessary to switch this call to a call based on a circuit switching technique according to the related art. As a technique that enables this switching, there is single radio voice call continuity (SRVCC) disclosed in Non-Patent Literature (hereinafter, abbreviated as “NPL”) 1. Hereinafter, a handover operation based on SRVCC will be described with reference to <figref idref="DRAWINGS">FIGS. 1 and 2</figref>.

0004<figref idref="DRAWINGS">FIG. 1</figref> is a diagram illustrating a part of a configuration of a 3GPP mobile communication network. The mobile communication network shown in <figref idref="DRAWINGS">FIG. 1</figref> is configured using an evolved universal terrestrial radio access network (e-UTRAN), an e-UTRAN base station (e-nodeB), a PS network, a CS network, a base station subsystem of the CS network, and an IP multimedia Subsystem (IMS).

0005Specifically, in <figref idref="DRAWINGS">FIG. 1</figref>, e-UTRAN is a radio access network that is capable of providing the VoLTE service. The PS network provides the VoLTE service and includes a packet data network gateway (P-GW), a serving gateway (S-GW), and a mobility management entity (MME). The CS network 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. IMS performs a call control or the like, and includes a call session control function (CSCF), and a service centralization and continuity application server (SCC AS). Note that in <figref idref="DRAWINGS">FIG. 1</figref> and <figref idref="DRAWINGS">FIG. 2</figref>, MSC and MGW are represented as a single node (MSC/MGW <b>110</b>), but may be provided as separate nodes.

0006In <figref idref="DRAWINGS">FIG. 1</figref>, it is assumed that UE <b>100</b> and UE <b>102</b> that 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 <b>102</b> are not shown). That is, it is assumed that a VoLTE call is made between UE <b>100</b> and UE <b>102</b>. Here, it is assumed that UE <b>100</b> is handed over (HO) to the CS network during the call.

0007Path A, Path B and Path C indicated by solid lines in <figref idref="DRAWINGS">FIG. 1</figref> represent paths through which speech data passes. Further, reference numerals <b>200</b>, <b>202</b>, <b>204</b> and <b>206</b> indicated by dashed lines in <figref idref="DRAWINGS">FIG. 1</figref> represent paths through which signals pass in an SRVCC handover process.

0008<figref idref="DRAWINGS">FIG. 2</figref> is a sequence chart illustrating an operation of the SRVCC handover process. UE <b>100</b> and UE <b>102</b> are initially connected to the PS network (e-UTRAN), respectively, and the speech data between UE <b>100</b> and UE <b>102</b> is transmitted and received through Path A. If UE <b>100</b> is distant from a cover area of the e-UTRAN, e-nodeB detects the fact, and exchanges signaling with RNC/nodeB through MME and MSC/MGW <b>110</b> (signaling <b>200</b> shown in <figref idref="DRAWINGS">FIG. 1</figref> and step (hereinafter, referred to as “ST”) <b>200</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>). In ST<b>200</b>, a data path in the CS network is prepared between nodeB and MSC/MGW <b>110</b>. If the preparation is finished, a command for handover to UTRAN (CS network) is given to UE <b>100</b> from MME through e-nodeB.

0009At the same time with the process of ST<b>200</b>, MSC/MGW <b>110</b> exchanges signaling with UE <b>102</b> through CSCF/SCC AS (signaling <b>202</b> shown in <figref idref="DRAWINGS">FIG. 1</figref> and ST<b>202</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>). Thus, a command is given for switching a transmission/reception destination of speech data of UE <b>102</b> from UE <b>100</b> to MSC/MGW <b>110</b>, and Path B is established.

0010After handover to UTRAN, UE <b>100</b> exchanges signaling with MSC/MGW <b>110</b> through RNC/nodeB (signaling <b>204</b> shown in <figref idref="DRAWINGS">FIG. 1</figref> and ST<b>204</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>). Thus, Path C is established.

0011After establishment of Path C, MSC/MGW <b>110</b> exchanges signaling with P-GW/S-GW through MME (signaling <b>206</b> shown in <figref idref="DRAWINGS">FIG. 1</figref> and ST<b>206</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>). Thus, Path A is deleted.

0012Hereinbefore, the operation of SRVCC handover has been described.

0013Further, as a technique that improves SRVCC to reduce the time necessary for switching data paths, there is an SRVCC method (eSRVCC: enhanced-SRVCC) that uses access transfer control function (ATCF) enhancement, as disclosed in NPL 3. An example of an operation of eSRVCC will be described with reference to <figref idref="DRAWINGS">FIGS. 3 and 4</figref>.

0014<figref idref="DRAWINGS">FIG. 3</figref> shows a part of a configuration of a 3GPP mobile communication network that enables eSRVCC. The mobile communication network shown in <figref idref="DRAWINGS">FIG. 3</figref> includes e-UTRAN, e-nodeB, a PS network, a CS network, a base station subsystem of the CS network, and IMS, similarly to <figref idref="DRAWINGS">FIG. 1</figref>. Here, an access transfer control function (ATCF) and an access transfer gateway (ATGW), in addition to CSCF and SCC AS, are present in IMS. In <figref idref="DRAWINGS">FIGS. 3 and 4</figref>, ATCF and ATGW are represented as a single node (ATCF/ATGW <b>320</b>), but may be provided as separate nodes.

0015In <figref idref="DRAWINGS">FIG. 3</figref>, UE <b>100</b> and UE <b>102</b> are initially connected to the PS network, respectively (here, a wireless access network, a base station and the PS network on the side of UE <b>102</b> are not shown). That is, it is assumed that a VoLTE call is performed between UE <b>100</b> and UE <b>102</b>. Here, it is assumed that UE <b>100</b> is handed over to the CS network during a call.

0016Path A, Path B, Path C and Path D indicated by solid lines in <figref idref="DRAWINGS">FIG. 3</figref> represent paths through which speech data passes. Further, reference numerals <b>300</b>, <b>302</b>, <b>304</b> and <b>306</b> indicated by dashed lines in <figref idref="DRAWINGS">FIG. 3</figref> represent paths through which signals in an eSRVCC handover process pass.

0017<figref idref="DRAWINGS">FIG. 4</figref> is a sequence chart illustrating an operation of eSRVCC handover. UE <b>100</b> and UE <b>102</b> are each connected to the PS network (e-UTRAN), initially. In a system in which the eSRVCC handover is realized, in ATCF/ATGW <b>320</b>, ATCF anchors signaling of IMS (IMS signaling), and ATGW anchors the speech data. That is, when a call between UE <b>100</b> and UE <b>102</b> starts, the IMS signaling for the call start is relayed by ATCF, and in a case where ATCF determines that anchoring of the speech data in ATGW is necessary, ATGW is allocated as an anchor point of the speech data. Thus, the speech data between UE <b>100</b> and UE <b>102</b> is transmitted and received through Path A and Path B.

0018If UE <b>100</b> is distant from a cover area of e-UTRAN, e-nodeB detects the fact, and exchanges signaling with RNC/nodeB through MME and MSC/MGW <b>110</b> (signaling <b>300</b> shown in <figref idref="DRAWINGS">FIG. 3</figref> and ST<b>300</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>). In ST<b>300</b>, a data path in the CS network is prepared between nodeB and MSC/MGW <b>110</b>. If the preparation is finished, a command for handover to UTRAN (CS network) is given to UE <b>100</b> from MME through e-nodeB.

0019Simultaneously with the process of ST<b>300</b>, MSC/MGW <b>110</b> transmits signaling to ATCF. Thus, a command for path switching is given to ATGW from ATCF, and a transmission/reception destination of speech data of ATGW is switched from UE <b>100</b> to MSC/MGW <b>100</b> (signaling <b>302</b> shown in <figref idref="DRAWINGS">FIG. 3</figref> and ST<b>302</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>). That is, Path C is established. Further, if the path switching process to ATGW is finished, ATCF transmits indication signaling to SCC-AS (signaling <b>302</b> shown in <figref idref="DRAWINGS">FIG. 3</figref> and ST<b>302</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>).

0020After handover to UTRAN, UE <b>100</b> exchanges signaling with MSC/MGW <b>110</b> through RNC/nodeB (signaling <b>304</b> shown in <figref idref="DRAWINGS">FIG. 3</figref> and ST<b>304</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>). Thus, Path D is established.

0021After establishment of Path D, MSC/MGW <b>110</b> exchanges signaling with P-GW/S-GW through MME (signaling <b>306</b> shown in <figref idref="DRAWINGS">FIG. 3</figref> and ST<b>306</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>). Thus, Path B is deleted.

0022Hereinbefore, the operation of eSRVCC handover has been described.

0023As a voice codec used in the CS network, an adaptive multi-rate wideband (AMR-WB) codec that is a wideband (WB) codec is widely used. AMR-WB is usable in a packet exchanging technique, and thus, may also be considered to be used in the PS network (VoLTE).

0024There is also a codec that supports an AMR-WB compatible mode as another codec other than AMR-WB used in the PS network (VoLTE) like enhanced voice service (EVS) described, for example, in NPL 4. The AMR-WB compatible mode assumes to 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 network (VoLTE), an RTP payload format of the AMR-WB codec described in NPL 2 may be used.

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

CITATION LIST

Non-Patent Literature

NPL 1

0000<ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0026">3GPP TS23.216 v9.6.0 “Single Radio Voice Call Continuity (SRVCC)”</li></ul>

NPL 2

0000<ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0027">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”</li></ul>

NPL 3

0000<ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0028">3GPP TS23.237 v11.0.0 “IP Multimedia Subsystem (IMS) Service Continuity”</li></ul>

NPL 4

0000<ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0029">3GPP TR22.813 v10.0.0 “Study of Use Cases and Requirements for Enhanced Voice Codecs for the Evolved Packet System (EPS)”</li></ul>

NPL 5

0000<ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0030">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</li></ul>

NPL 6

0000<ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0031">3GPP TS26.114 v10.0.0 “IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction”</li></ul>

NPL 7

0000<ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0032">G. Zorn (Ed), “RTP Payload Format for G.718 Speech/Audio,” Nov. 15, 2011, work in progress</li></ul>

NPL 8

0000<ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0033">3GPP TR23.885 v11.0.0 “Feasibility Study of Single Radio Voice Call Continuity (SRVCC) from UTRAN/GERAN to E-UTRAN/HSPA”</li></ul>

SUMMARY OF INVENTION

Technical Problem

0034In <figref idref="DRAWINGS">FIG. 1</figref> or <figref idref="DRAWINGS">FIG. 3</figref>, when UE <b>100</b> is handed over from the PS network to the CS network, in a case where the codec used in the PS network is not supported in the CS network, the codec used by UE <b>100</b> is changed to a codec supported by the CS network. In a case where change of the codec occurs in UE <b>100</b>, in order to enable call continuity between UE <b>100</b> and UE <b>102</b>, the following two methods may be considered. The first method is a method of performing transcoding in the MS C/MGW or ATCF/ATGW. The second method is a method of changing the codec used by UE <b>102</b> to the same codec as the changed codec of UE <b>100</b>.

0035In the method of performing transcoding, which was mentioned first, call quality deteriorates due to transcoding.

0036On the other hand, in the method of changing the codec, which was mentioned later, although deterioration of call quality which occurs in the method of performing transcoding does not occur, signaling used to change the codec of UE <b>102</b> takes time and prolongs the disconnection time of the call, which is not favorable. Further, in the eSRVCC handover, since signaling for path switching in handover of UE <b>100</b> is terminated in ATCF, it is difficult to transmit signaling for changing the codec of UE <b>102</b>. That is, in the eSRVCC handover, it is difficult to change the codec of UE <b>102</b> using the existing signaling.

0037It is an object of the present invention to provide a network node and a communication method that make it possible to continue communication and also to reduce the disconnection time of a call without deteriorating call quality even when a codec used by one of terminals in communication is changed.

Solution to Problem

0038A network node according to an aspect of the present invention is a network node that transfers, when one of two terminals performing communication in a first network performs handover to a second network that is different from the first network, data between the two terminals, the network node including: a detection section that detects a first codec used by the one of the two terminals in the first network and a second codec to be used by the one of the two terminals in the second network; a generating section that generates, when the first codec is a codec having a compatible mode that is compatible with the second codec, data for the other one of the two terminals by switching a codec of data transmitted from the one of the two terminals to the compatible mode of the first codec; and a transmitting section that transmits data for the other one of the two terminals to the other one of the two terminals.

0039A communication method according to an aspect of the present invention is a communication method for transferring, when one of two terminals performing communication in a first network performs handover to a second network that is different from the first network, data between the two terminals, the communication method including: detecting a first codec used by the one of the two terminals in the first network and a second codec to be used by the one of the two terminals in the second network; generating, when the first codec is a codec having a compatible mode that is compatible with the second codec, data for the other one of the two terminals by switching a codec of data transmitted from the one of the two terminals to the compatible mode of the first codec; and transmitting, to the other one of the two terminals, data for the other one of the two terminals.

Advantageous Effects of Invention

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

BRIEF DESCRIPTION OF DRAWINGS

0041<figref idref="DRAWINGS">FIG. 1</figref> is a configuration diagram illustrating part of a 3GPP mobile communication network;

0042<figref idref="DRAWINGS">FIG. 2</figref> is a sequence chart illustrating an SRVCC handover operation;

0043<figref idref="DRAWINGS">FIG. 3</figref> is a configuration diagram illustrating part of a 3GPP mobile communication network that enables eSRVCC;

0044<figref idref="DRAWINGS">FIG. 4</figref> is a sequence chart illustrating an eSRVCC handover operation;

0045<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example of an RTP payload format according to Embodiment 1 of the present invention;

0046<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example of an SDP offer and SDP answer according to Embodiment 1 of the present invention;

0047<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram illustrating a configuration of a terminal (UE) according to Embodiment 1 of the present invention;

0048<figref idref="DRAWINGS">FIG. 8</figref> is a block diagram illustrating a configuration of a network node (MSC/MGW) according to Embodiment 1 of the present invention;

0049<figref idref="DRAWINGS">FIG. 9</figref> is a flowchart illustrating an example of codec switching processing in MSC/MGW according to Embodiment 1 of the present invention;

0050<figref idref="DRAWINGS">FIG. 10</figref> illustrates an example of how a codec switching request is indicated in Embodiment 1 of the present invention; and

0051<figref idref="DRAWINGS">FIG. 11</figref> is a block diagram illustrating a configuration of a terminal (UE) according to Embodiment 3 of the present invention.

DESCRIPTION OF EMBODIMENTS

0052Embodiments of the present invention will be described in detail with reference to the accompanying drawings.

0053In the following description, the term “bandwidth” refers to a bandwidth of a signal serving as input/output of a codec.

0054In the following description, a codec available in both a PS network and 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.

0055A codec available to the PS network is represented by “codec B.” Codec B includes a non-compatible mode (codec A non-compatible mode) and a compatible mode (codec A compatible mode) with respect to codec A. However, codec B may be used in the CS network. Codec B is, for example, EVS or G.718 described in NPL 7.

Embodiment 1

0056<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example of a payload format (RTP payload format) of codec B. As shown in <figref idref="DRAWINGS">FIG. 5</figref>, 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 of the data portion.

0057The payload format of codec B in the present embodiment is configured to allow the payload receiving side to identify whether the data portion includes data in the codec A non-compatible mode or data in the codec A compatible mode. For example, as shown in <figref idref="DRAWINGS">FIG. 5</figref>, the header portion includes a “codec type” field and a “bit rate” field. The “codec type” includes information indicating whether the codec is in the codec A non-compatible mode or in the codec A compatible mode. The “bit rate” includes information indicating at which bit rate data is encoded among the bit rates supported in the codec A non-compatible mode or bit rates supported in the codec A compatible mode.

0058As shown in <figref idref="DRAWINGS">FIG. 5</figref>, in addition to the above-described fields, it is also possible to include a field for issuing, to a counterpart terminal on the payload receiving side, to request switching of the codec type or bit rate (“codec type/bit rate switching request” field). Note that this field need not be included for each frame, and may be included only when required.

0059The method has been described thus far with the payload format of codec B shown in <figref idref="DRAWINGS">FIG. 5</figref> in which the header portion explicitly includes the field for implementing the configuration that allows the payload receiving side to identify whether the data portion includes data in the codec A non-compatible mode or data in the codec A compatible mode (“codec type” field, “bit rate” field) and the field for issuing, to the counterpart terminal, a request for switching of the codec type or bit rate (“codec type/bit rate switching request” field). However, the method need not always be the method shown in <figref idref="DRAWINGS">FIG. 5</figref>. Furthermore, an example has been described in the payload format shown in <figref idref="DRAWINGS">FIG. 5</figref> where the payload format consists of the header portion and the data portion, but the header portion may be omitted in the payload format if the terminal on the receiving side that has received the payload can correctly decode data without the header portion.

0060The payload format of codec B is not limited to the example shown in <figref idref="DRAWINGS">FIG. 5</figref>, and a combination of layers (corresponding to bit rates) may be described as separate values as in the case of the payload format of G.718 described in NPL 7, for example.

0061Next, <figref idref="DRAWINGS">FIG. 6</figref> illustrates an example of a session description protocol (SDP) offer and SDP answer exchanged between terminals in session negotiation when a call starts.

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

0063As shown in <figref idref="DRAWINGS">FIG. 6</figref>, the UE that supports codec B describes codec A and codec B in an SDP offer even when the UE does not support codec A. This is because when the counterpart terminal supports codec A but does not support codec B, codec A is selected in codec negotiation so as to enable the codec A compatible mode of codec B to be used using the RTP payload format of codec A. In <figref idref="DRAWINGS">FIG. 6</figref>, the UE which has received the SDP offer selects codec B and describes the selected codec B in the SDP answer.

0064The SDP offer and SDP answer may also include description of a preferential mode (codec A non-compatible mode or codec A compatible mode, bit rate, bandwidth or the like) when codec B is selected. The preferential mode may be predetermined by an operator who performs a communication service and incorporated in the UE in the form of software, or the like. In the present embodiment, when codec B is selected, it is assumed that the codec A non-compatible mode is used as a preferential mode.

0065Next, the mobile communication network (<figref idref="DRAWINGS">FIG. 1</figref>) according to the present embodiment will be described.

0066First, UE <b>100</b> or <b>102</b> shown in <figref idref="DRAWINGS">FIG. 1</figref> will be described.

0067<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram illustrating a configuration of UEs <b>100</b> and <b>102</b> (terminal) according to the present embodiment. UEs <b>100</b> and <b>102</b> are each configured of receiving section <b>700</b>, transmitting section <b>702</b>, codec negotiation section <b>704</b>, RTP payload analysis section <b>706</b>, RTP payload generating section <b>708</b> and codec reporting section <b>710</b>.

0068In UEs <b>100</b> and <b>102</b> shown in <figref idref="DRAWINGS">FIG. 7</figref>, receiving section <b>700</b> receives communication data (including RTP payload) and signaling or the like. For example, when receiving an RTP payload (e.g., see <figref idref="DRAWINGS">FIG. 5</figref>) transmitted from MSC/MGW <b>110</b>, receiving section <b>700</b> outputs the received RTP payload to RTP payload analysis section <b>706</b>.

0069Transmitting section <b>702</b> transmits communication data (including RTP payload) and signaling or the like.

0070Codec negotiation section <b>704</b> negotiates a codec to be used for communication between terminals (UE <b>100</b> and UE <b>102</b>). More specifically, codec negotiation section <b>704</b> creates an SDP offer or SDP answer (e.g., see <figref idref="DRAWINGS">FIG. 6</figref>) and performs codec negotiation. In this case, when creating an SDP offer, codec negotiation section <b>704</b> includes codec A in the SDP offer as shown in <figref idref="DRAWINGS">FIG. 6</figref> even when the terminal supports codec B but does not support codec A as described above. When codec B is selected in negotiation, codec negotiation section <b>704</b> selects a preferential mode (codec A non-compatible mode or codec A compatible mode, bit rate, bandwidth or the like) according to the information described in the SDP offer and answer as described above or information incorporated beforehand in software or the like and outputs the preferential mode to RTP payload generating section <b>708</b>.

0071RTP payload analysis section <b>706</b> analyzes the header portion of the RTP payload received from receiving section <b>700</b> and identifies information relating to data included in the data portion of the RTP payload (e.g., codec type, bit rate or the like). RTP payload analysis section <b>706</b> outputs the identified information and the data included in the data portion to a decoder (not shown). When the RTP payload received from receiving section <b>700</b> includes an instruction of “codec type/bit rate switching request,” RTP payload analysis section <b>706</b> outputs the instruction to an encoder (not shown) and RTP payload generating section <b>708</b>. The encoder encodes data based on the information and instruction from RTP payload analysis section <b>706</b>.

0072RTP payload generating section <b>708</b> generates an RTP payload (e.g., see <figref idref="DRAWINGS">FIG. 5</figref>) including information (e.g., codec type, bit rate) relating to the data received from the encoder and the data received from codec negotiation section <b>704</b>. In this case, upon receiving an instruction of a “codec type/bit rate switching request” from RTP payload analysis section <b>706</b>, RTP payload generating section <b>708</b> generates an RTP payload based on the instruction. The generated RTP payload is transmitted via transmitting section <b>702</b>.

0073When the UE of codec reporting section <b>710</b> performs handover from the PS network to the CS network, codec reporting section <b>710</b> reports, to the network node (e.g., MME) of the PS network, the codec used by the UE in the PS network. The reported codec is indicated to MSC/MGW <b>110</b> via a network node (MME) of the PS network.

0074Next, MSC/MGW <b>110</b> shown in <figref idref="DRAWINGS">FIG. 1</figref> will be described. <figref idref="DRAWINGS">FIG. 8</figref> is a block diagram illustrating a configuration of MSC/MGW <b>110</b> (network node) according to the present embodiment. MSC/MGW <b>110</b> is configured of receiving section <b>800</b>, transmitting section <b>802</b>, codec detection section <b>804</b>, codec negotiation section <b>806</b>, RTP payload generating section <b>808</b> and RTP payload analysis section <b>810</b>.

0075In MSC/MGW <b>110</b> shown in <figref idref="DRAWINGS">FIG. 8</figref>, receiving section <b>800</b> receives communication data (including RTP payload) and signaling or the like. For example, upon receiving the RTP payload (e.g., see <figref idref="DRAWINGS">FIG. 5</figref>) transmitted from UE <b>102</b>, receiving section <b>800</b> outputs the received RTP payload to RTP payload analysis section <b>810</b>.

0076Transmitting section <b>802</b> transmits the communication data (including RTP payload) and signaling or the like.

0077Codec detection section <b>804</b> detects a codec to be used by a terminal that has performed handover from the PS network to the CS network (UE <b>100</b> in <figref idref="DRAWINGS">FIG. 1</figref>) in the CS network. Codec detection section <b>804</b> also detects a codec used by a terminal that has performed handover from the PS network to the CS network (UE <b>100</b> in <figref idref="DRAWINGS">FIG. 1</figref>) in the PS network. The method of detecting the codec used by the terminal (UE <b>100</b>) in the PS network may be a method as disclosed in NPL 5 which is indicated from the network node (MME or the like) in the PS network when UE <b>100</b> (codec reporting section <b>710</b>) performs handover to the CS network. Alternatively, the method of detecting the codec used by the terminal (UE <b>100</b>) in the PS network may be a method whereby the codec is acquired from other network nodes such as SCC AS. The method of detecting the codec used by the terminal (UE <b>100</b>) in the CS network may be a method using information negotiated through signaling transmitted/received between UE <b>100</b> and the network node (RNC and MSC/MGW <b>110</b>) in the CS network when UE <b>100</b> performs handover to the CS network. Codec detection section <b>804</b> outputs the codec detection result to RTP payload generating section <b>808</b>.

0078Codec negotiation section <b>806</b> negotiates the codec to be used with the UE according to an instruction from RTP payload generating section <b>808</b>, for example. For example, codec negotiation section <b>806</b> negotiates (re-negotiates) the codec to be used with the terminal (UE <b>102</b> in <figref idref="DRAWINGS">FIG. 1</figref>) which is the communicating counterpart of the terminal (UE <b>100</b> in <figref idref="DRAWINGS">FIG. 1</figref>) which has performed handover from the PS network to the CS network.

0079RTP payload generating section <b>808</b> generates data (RTP payload) for the communicating counterpart of the terminal (UE <b>102</b> in <figref idref="DRAWINGS">FIG. 1</figref>) using the data received from the terminal (UE <b>100</b> in <figref idref="DRAWINGS">FIG. 1</figref>) based on the codec detection result received from codec detection section <b>804</b>. For example, when the codec used by the terminal which has performed handover from 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, RTP payload generating section <b>808</b> switches the codec of the data (data of codec A) received from the terminal to a codec A compatible mode of codec B. That is, MSC/MGW <b>110</b> transmits the data of codec A received from the terminal as the codec A compatible mode of codec B using the RTP payload format of codec B (see <figref idref="DRAWINGS">FIG. 5</figref>) via transmitting section <b>802</b>.

0080When the codec detection result received from codec detection section <b>804</b> is other than the above-described one, RTP payload generating section <b>808</b> instructs codec negotiation section <b>806</b> to negotiate (re-negotiate) a codec with the communicating counterpart (UE <b>102</b> in <figref idref="DRAWINGS">FIG. 1</figref>) which is the transmission destination of the received data. RTP payload generating section <b>808</b> performs transcoding, if necessary, on the communication data received from the terminal that has performed handover, based on the negotiation result and switches the mode to a codec mode based on the negotiation result. The data after codec switching (generated RTP payload) is transmitted via transmitting section <b>802</b>.

0081RTP payload analysis section <b>810</b> analyzes the header portion of the RTP payload transmitted from the terminal (UE <b>102</b>) and identifies information relating to the data (e.g., codec type, bit rate) included in the data portion of the RTP payload. RTP payload analysis section <b>810</b> outputs the specified information to codec detection section <b>804</b>.

0082Next, the details of codec processing in MSC/MGW <b>110</b> (<figref idref="DRAWINGS">FIG. 8</figref>) will be described using <figref idref="DRAWINGS">FIG. 9</figref>. Here, a case will be described where as shown in <figref idref="DRAWINGS">FIG. 1</figref>, UE <b>100</b> performs handover from the PS network to the CS network while both UE <b>100</b> and UE <b>102</b> are connected to the PS network and are making a call. That is, MSC/MGW <b>110</b> is a network node which transfers data between two terminals when one UE <b>100</b> of the two terminals (UEs <b>100</b> and <b>102</b>) which perform communication in the PS network performs handover to the CS network.

0083In ST<b>900</b> shown in <figref idref="DRAWINGS">FIG. 9</figref>, RTP payload generating section <b>808</b> determines whether the codec used by UE <b>100</b> in the CS network is codec A or not based on the detection result in codec detection section <b>804</b>.

0084When the codec used by UE <b>100</b> in the CS network is codec A (ST<b>900</b>: YES), in ST<b>902</b>, RTP payload generating section <b>808</b> determines whether the codec used by UE <b>100</b> in the PS network (before handover) is codec B or not based on the detection result in codec detection section <b>804</b>.

0085When the codec used by UE <b>100</b> in the PS network is codec B (ST<b>902</b>: YES), in ST<b>904</b>, RTP payload generating section <b>808</b> switches the codec of data (codec A) transmitted from UE <b>100</b> to a codec A compatible mode of codec B. That is, RTP payload generating section <b>808</b> transforms the data of codec A transmitted from UE <b>100</b> into a codec A compatible mode of codec B using the RTP payload format of codec B and transmits the data to UE <b>102</b> via transmitting section <b>802</b>.

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

0087On the other hand, when the codec used by UE <b>100</b> in the CS network is not codec A (ST<b>900</b>: NO) or when the codec used by UE <b>100</b> in the PS network is not codec B (ST<b>902</b>: NO), in ST<b>906</b>, codec negotiation section <b>806</b> performs session re-negotiation with UE <b>102</b> and determines the codec. RTP payload generating section <b>808</b> then generates an RTP payload of the determined codec.

0088Alternatively, in ST<b>906</b>, MSC/MGW <b>110</b> may perform transcoding on the data transmitted from UE <b>100</b> and transmit the transcoded data (data for UE <b>102</b>) to UE <b>102</b>.

0089Thus, when a change of the codec of one UE is detected, MSC/MGW <b>110</b> determines whether or not the codec of data 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.

0090Next, an example of operation of UE <b>100</b> or <b>102</b> (<figref idref="DRAWINGS">FIG. 7</figref>) and MSC/MGW <b>110</b> (<figref idref="DRAWINGS">FIG. 8</figref>) in the present embodiment will be described.

0091In the following description, in <figref idref="DRAWINGS">FIG. 1</figref> and <figref idref="DRAWINGS">FIG. 2</figref>, both UE <b>100</b> and UE <b>102</b> are connected to the PS network and start a call. Here, let us suppose that a call is made from UE <b>100</b> to UE <b>102</b>.

0092When a call starts, a codec to be used between UE <b>100</b> and UE <b>102</b> is negotiated. For example, UE <b>100</b> (codec negotiation section <b>704</b>) generates an SDP offer (e.g., see <figref idref="DRAWINGS">FIG. 6</figref>) and transmits the SDP offer to UE <b>102</b>. In contrast, UE <b>102</b> (codec negotiation section <b>704</b>) generates an SDP answer (e.g., see <figref idref="DRAWINGS">FIG. 6</figref>, codec B is selected in <figref idref="DRAWINGS">FIG. 6</figref>), and transmits the SDP answer to UE <b>100</b>. Upon completion of operation of an example associated with this start of call, UE <b>100</b> or <b>102</b> makes a call using a codec A non-compatible mode of codec B (preferential mode when codec B is selected) (<figref idref="DRAWINGS">FIG. 2</figref>: Speech Session over PS).

0093Next, as shown in <figref idref="DRAWINGS">FIG. 1</figref>, UE <b>100</b> performs handover from the PS network to the CS network (ST<b>200</b> and ST<b>204</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>). Here, let us suppose that the codec used by UE <b>100</b> in the CS network is codec A.

0094Simultaneously with the handover processing of UE <b>100</b>, MSC/MGW <b>110</b> (codec detection section <b>804</b>) detects the codec to be used by UE <b>100</b> when performing handover to the CS network. MSC/MGW <b>110</b> (codec detection section <b>804</b>) also detects the codec used by UE <b>100</b> in the PS network. As described above, MSC/MGW <b>110</b> detects that the codec used by UE <b>100</b> in CS network is codec A and the codec used by UE <b>100</b> in PS network is codec B (that is, ST<b>900</b> shown in <figref idref="DRAWINGS">FIG. 9</figref>: YES and ST<b>902</b>: YES).

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

0096In this case, when RTP payload generating section <b>808</b> switches the codec of the data transmitted from UE <b>100</b>, MSC/MGW <b>110</b> may transmit a request for switching from a codec A non-compatible mode to a codec A compatible mode to UE <b>102</b> which is the communicating counterpart of UE <b>100</b>. For example, in the RTP payload format of codec B (e.g., see <figref idref="DRAWINGS">FIG. 5</figref>), MSC/MGW <b>110</b> (RTP payload generating section <b>808</b>) may include an instruction for switching from the codec A non-compatible mode to the codec A compatible mode in the header portion (“codec type/bit rate switching request” field).

0097On the other hand, UE <b>102</b> (RTP payload analysis section <b>706</b>) determines that the data included in the data portion of the RTP payload is codec A (codec that can be handled as a codec A compatible mode) from the information included in the data received from MSC/MGW <b>110</b> (information of the header portion of the RTP payload) and hands over the information and data to the decoder. This causes the decoder of UE <b>102</b> to recognize that the codec of the received data is codec A (codec A compatible mode of codec B) and decode the data.

0098When the received RTP payload includes a request for switching from the codec A non-compatible mode to codec A compatible mode, UE <b>102</b> (e.g., RTP payload analysis section <b>706</b>) outputs the request for switching to an encoder (not shown) and RTP payload generating section <b>708</b>. This causes UE <b>102</b> to determine to use the codec A compatible mode of codec B also for data transmitted from UE <b>102</b>. That is, UE <b>102</b> (RTP payload generating section <b>708</b>) stores the data of the codec A compatible mode received from the encoder in the payload format of codec B and transmits the data to MSC/MGW <b>110</b>.

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

0100That is, MSC/MGW <b>110</b> switches the data of the codec after handover from UE <b>100</b> to part of a codec before handover (one of codec modes before handover), eliminates the necessity for signaling to change the codec between UE <b>100</b> and UE <b>102</b>, and can thereby prevent the disconnection time of a call from being prolonged. MSC/MGW <b>110</b> switches only the codec mode without changing the codec data between UE <b>100</b> and UE <b>102</b>, and can thereby prevent deterioration of call quality unlike transcoding. Thus, according to the present embodiment, even when the codec used by one of the terminals in communication is changed, it is possible to continue communication and also to reduce the disconnection time of a call without causing deterioration of call quality.

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

0102Note that the indication of the request for switching from the codec A non-compatible mode to the codec A compatible mode to UE <b>102</b> need not always be included in the RTP payload from MSC/MGW <b>110</b> to UE <b>102</b>. For example, the request for switching may be indicated to UE <b>102</b> as an SDP offer shown in <figref idref="DRAWINGS">FIG. 10</figref> in the SDP of INVITE with SDP-MGW transmitted from MSC/MGW <b>110</b> in ST<b>202</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>. Moreover, the above-described request for switching may be indicated from MSC/MGW <b>110</b> to UE <b>102</b> using RTCP-APP disclosed in NPL 6.

0103When UE <b>102</b> receives data of codec A in the RTP payload format of codec B, UE <b>102</b> may determine that the data from UE <b>102</b> (transmission data) should also be encoded in the codec A compatible mode after receiving the data. In this case, the above-described request for switching becomes unnecessary.

Embodiment 2

0104The present embodiment will be described using <figref idref="DRAWINGS">FIG. 3</figref> and <figref idref="DRAWINGS">FIG. 4</figref>. In the following description, like Embodiment 1, let us suppose that UE <b>100</b> and UE <b>102</b> make a call using codec B in the PS network first, and only UE <b>100</b> performs handover from the PS network to the CS network. In addition, the codec used by UE <b>100</b> in the CS network is codec A.

0105ATCF/ATGW <b>320</b> shown in <figref idref="DRAWINGS">FIG. 3</figref> and <figref idref="DRAWINGS">FIG. 4</figref> is simply a data anchor point. Therefore, when ATCF/ATGW <b>320</b> shown in <figref idref="DRAWINGS">FIG. 3</figref> and <figref idref="DRAWINGS">FIG. 4</figref> is forwarding data from UE <b>100</b> to UE <b>102</b> or data from UE <b>102</b> to UE <b>100</b>, the functions of MSC/MGW <b>110</b> (<figref idref="DRAWINGS">FIG. 8</figref>) and UE <b>100</b>, UE <b>102</b> (<figref idref="DRAWINGS">FIG. 7</figref>) are identical to those of Embodiment 1 (<figref idref="DRAWINGS">FIG. 5</figref> to <figref idref="DRAWINGS">FIG. 9</figref>). However, MSC/MGW <b>110</b> is different from that in Embodiment 1 only in that INVITE with SDP in ST<b>202</b> shown in <figref idref="DRAWINGS">FIG. 2</figref> cannot be used when a codec switching request (request for switching from a codec A non-compatible mode to a codec A compatible mode) is indicated to UE <b>102</b>.

0106Let us suppose that ATCF/ATGW <b>320</b> has information on a codec used by UE <b>100</b> in Path B shown in <figref idref="DRAWINGS">FIG. 3</figref> and a codec used by UE <b>102</b> in Path A shown in <figref idref="DRAWINGS">FIG. 3</figref> or is provided with means capable of obtaining the information from another node.

0107In this case, even when codec detection section <b>804</b> of MSC/MGW <b>110</b> has no information on the codec used by UE <b>100</b> in the PS network (Path B shown in <figref idref="DRAWINGS">FIG. 3</figref>), ATCF/ATGW <b>320</b> can indicate, to MSC/MGW <b>110</b>, the information on the codec used by UE <b>100</b> in the PS network as a reply message of INVITE with SDP-MGW in ST<b>302</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>.

0108Thus, MSC/MGW <b>110</b> (RTP payload generating section <b>808</b>) can immediately identify a codec used by UE <b>100</b> (terminal that has performed handover) in the PS network. That is, MSC/MGW <b>110</b> can set the data transmitted from UE <b>100</b>, based on the codec used by UE <b>100</b> (terminal that has performed handover) in the PS network in a codec A compatible mode using the RTP payload format of codec B, and immediately transmit the data to UE <b>102</b>. Similarly, MSC/MGW <b>110</b> can immediately transmit, to UE <b>102</b>, a request for switching to UE <b>102</b>.

0109According to the present embodiment, even in the case of an eSRVCC scheme or a case where the codec used by one of the terminals in communication is changed like Embodiment 1, it is possible to continue communication while reducing the disconnection time of a call without causing deterioration of call quality.

Embodiment 3

0110In this embodiment, a description will be given of a case where a terminal that has performed handover from the PS network to the CS network (UE <b>100</b> in <figref idref="DRAWINGS">FIG. 1</figref>) returns to the PS network again.

0111<figref idref="DRAWINGS">FIG. 11</figref> is a block diagram illustrating a configuration of UEs <b>100</b> and <b>102</b> (terminal) according to the present embodiment. In <figref idref="DRAWINGS">FIG. 11</figref>, components identical to those of Embodiment 1 (<figref idref="DRAWINGS">FIG. 7</figref>) will be assigned the same reference numerals and description thereof will be omitted.

0112In UE <b>100</b> (<b>102</b>) shown in <figref idref="DRAWINGS">FIG. 11</figref>, terminal position identification section <b>1100</b> identifies a network (PS network or CS network) to which UE <b>100</b> (<b>102</b>) of terminal position identification section <b>1100</b> is connected, that is, terminal position identification section <b>1100</b> identifies the position of UE <b>100</b> (<b>102</b>). This allows UE <b>100</b> (<b>102</b>) to perform handover. Terminal position identification section <b>1100</b> may determine the position of UE <b>100</b> (<b>102</b>) of terminal position identification section <b>1100</b> from base station ID of the destination (e.g., e-nodeB or nodeB) or determine the position of UE <b>100</b> or <b>102</b> from establishment of connection in the PS core network.

0113For example, let us suppose that UE <b>100</b> which has performed handover from the PS network to the CS network returns to the PS network again. Moreover, it is assumed that UE <b>100</b> uses codec A in the CS network. At this time, terminal position identification section <b>1100</b> identifies that UE <b>100</b> has been connected to the PS network.

0114UE <b>100</b> which has identified through terminal position identification section <b>1100</b> that UE <b>100</b> has been connected to the PS network switches the codec of UE <b>100</b> from codec A to codec B (codec A non-compatible mode). RTP payload generating section <b>708</b> of UE <b>100</b> generates an RTP payload using the payload format of codec B. This RTP payload is transmitted to UE <b>102</b> via transmitting section <b>702</b>.

0115On the other hand, RTP payload analysis section <b>706</b> of UE <b>102</b> detects that the codec of the data received from UE <b>100</b> has been switched from a codec A compatible mode to a codec A non-compatible mode. RTP payload analysis section <b>706</b> then hands over information indicating that the codec of UE <b>100</b> has been switched and data to a decoder. Thus, the decoder of UE <b>102</b> decodes the data received from UE <b>100</b> in the codec A non-compatible mode of codec B.

0116When the RTP payload received includes a request for switching from the codec A compatible mode to the codec A non-compatible mode, RTP payload analysis section <b>706</b> of UE <b>102</b> hands over this request for switching to the encoder and RTP payload generating section <b>708</b>. Accordingly, UE <b>102</b> determines to use the codec A non-compatible mode of codec B also on the data transmitted from UE <b>102</b>. That is, RTP payload generating section <b>708</b> of UE <b>102</b> stores the data in the codec A non-compatible mode handed over by the encoder in the payload format of codec B and transmits the data to UE <b>100</b>.

0117The indication of the request for switching from the codec A compatible mode to the codec A non-compatible mode to UE <b>102</b> need not always be included in the RTP payload from UE <b>100</b> to UE <b>102</b>. For example, the request for switching may be included in an IMS message described in NPL 8. The request for switching may be indicated from MSC/MGW <b>110</b> to UE <b>102</b> using RTCP-APP described in NPL 6.

0118Upon reception of data in the codec A non-compatible mode in the RTP payload format of codec B, UE <b>102</b> may determine that the data from UE <b>102</b> (transmission data) should also be encoded in the codec A non-compatible mode after receiving the data. In this case, the above-described request for switching becomes unnecessary.

0119In this way, even when the terminal which has performed handover from the PS network to the CS network returns to the PS network again, the terminal changes the codec based on the current position of the terminal, and can thereby continue communication while reducing the disconnection time of a call without causing deterioration of call quality.

0120Hereinbefore, embodiments of the invention have been described.

0121In the above-described embodiments, ATCF/ATGW <b>320</b>, MSC/MGW <b>110</b>, and SCC AS/CSCF each have been described as a single node. However, ATCF/ATGW <b>320</b>, MSC/MGW <b>110</b>, and SCC AS/CSCF may be each configured of two or more different nodes which are connected to each other via an interface. That is, the above-described function may be distributed over a plurality of nodes between ATCF and ATGW, between MSC and MGW, and between SCC AS and CSCF.

0122Furthermore, in the above-described respective embodiments, the description has mainly been made using the codec relating to voice. However, the invention is not limited thereto, and may be applied to music, sound, images or the like.

0123In addition, the present invention is by no means limited to the embodiments described above, and various modifications are possible.

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

0125Each of the functional blocks used in the descriptions of the embodiments are realized typically by LSI (large-scale integration), which is an integrated circuit. The functional blocks may each be a separate single chip, or some or all of the functional blocks may be collectively made into a single chip. The term “LSI” is used herein but the integrated circuit may be called an IC (integrated circuit), a system LSI device, a super-LSI device, or an ultra-LSI device depending on a difference in the degree of integration.

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

0127Additionally, in the event of emergence of technology for circuit integration that replaces LSI technology by advancements in semiconductor technology or technology derivative therefrom, such technology may be used to integrate the functional blocks. Biotechnology may be applied, for example.

0128The disclosure of Japanese Patent Application No. 2011-261617, filed on Nov. 30, 2011, including the specification, drawings, and abstract, is incorporated herein by reference in its entirety.

INDUSTRIAL APPLICABILITY

0129The present invention is useful in continuing communication while reducing the disconnection time of a call without causing deterioration of call quality even when a codec used in one of communication terminals in communication is changed.

REFERENCE SIGNS LIST

0000<ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0130"><b>100</b>, <b>102</b> TIE</li><li id="ul0009-0002" num="0131"><b>200</b>, <b>202</b>, <b>204</b>, <b>206</b>, <b>300</b>, <b>302</b>, <b>304</b>, <b>306</b> Signaling</li><li id="ul0009-0003" num="0132"><b>110</b> MSC/MGW</li><li id="ul0009-0004" num="0133"><b>320</b> ATCF/ATGW</li><li id="ul0009-0005" num="0134"><b>700</b>, <b>800</b> Receiving section</li><li id="ul0009-0006" num="0135"><b>702</b>, <b>802</b> Transmitting section</li><li id="ul0009-0007" num="0136"><b>704</b>, <b>806</b> Codec negotiation section</li><li id="ul0009-0008" num="0137"><b>706</b>, <b>810</b> RTP payload analysis section</li><li id="ul0009-0009" num="0138"><b>708</b>, <b>808</b> RTP payload generating section</li><li id="ul0009-0010" num="0139"><b>710</b> Codec reporting section</li><li id="ul0009-0011" num="0140"><b>804</b> Codec detection section</li><li id="ul0009-0012" num="0141"><b>1100</b> Terminal position identification section</li></ul>