WO2010106663A1 - 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法 - Google Patents

受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法 Download PDF

Info

Publication number
WO2010106663A1
WO2010106663A1 PCT/JP2009/055451 JP2009055451W WO2010106663A1 WO 2010106663 A1 WO2010106663 A1 WO 2010106663A1 JP 2009055451 W JP2009055451 W JP 2009055451W WO 2010106663 A1 WO2010106663 A1 WO 2010106663A1
Authority
WO
WIPO (PCT)
Prior art keywords
call state
node
receiving
data
audio data
Prior art date
Application number
PCT/JP2009/055451
Other languages
English (en)
French (fr)
Inventor
督 矢部
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to EP09841868.4A priority Critical patent/EP2410725A4/en
Priority to PCT/JP2009/055451 priority patent/WO2010106663A1/ja
Priority to CN200980158061.8A priority patent/CN102349285B/zh
Priority to JP2011504677A priority patent/JP5278532B2/ja
Priority to KR1020117020322A priority patent/KR20110113649A/ko
Publication of WO2010106663A1 publication Critical patent/WO2010106663A1/ja
Priority to US13/217,900 priority patent/US8521098B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information

Definitions

  • the present invention relates to a reception device, a transmission device, a reception method, a transmission method, a communication system, and a communication method that perform voice communication.
  • the LTE (Long Term Evolution) system is being internationally standardized by 3GPP (3rd Generation Partnership Project) with the aim of dramatically improving performance from 3G cellular systems.
  • the LTE system is expected as a system that realizes high-speed transmission by mobile communication, provides an advanced service environment such as high-speed video distribution, and enables efficient frequency utilization.
  • Real-time data transmission in the LTE system is realized by each protocol of RTP / UDP / IP, as in VoIP (Voice over IP) in a general wired IP network. For this reason, overhead is increased in real-time data in the LTE system by adding a header of each protocol.
  • a function for compressing the header of each protocol that is an overhead is required in order to improve the bandwidth utilization efficiency of the wireless section.
  • This header compression function is expected to be realized in the LTE system.
  • ROHC RObust Header Compression
  • PDCP Packet Data Convergence Protocol
  • UE Packet Data Convergence Protocol
  • ROHC has a plurality of operation modes having different header compression efficiencies (for example, see Patent Document 1 below).
  • the disclosed reception device, transmission device, reception method, transmission method, communication system, and communication method are intended to solve the above-described problems, and are intended to improve the sound quality and bandwidth utilization efficiency of audio data.
  • the receiving apparatus performs header compression of audio data, and performs the header compression in a receiving apparatus in a communication system having a plurality of operation modes having different header compression frequencies.
  • a call state can be determined, and a plurality of operation modes having different header compression frequencies can be switched according to the determined call state.
  • reception device transmission device, reception method, transmission method, communication system, and communication method, it is possible to improve the sound quality and bandwidth utilization efficiency of audio data.
  • FIG. 1 is a block diagram of a configuration example of a receiving node according to the first embodiment.
  • FIG. 2 is a block diagram of a configuration example of the transmission node according to the first embodiment.
  • FIG. 3 is a diagram of a configuration example of the communication system according to the first embodiment.
  • FIG. 4 is a diagram showing a protocol stack in the communication system shown in FIG.
  • FIG. 5 is a diagram (part 1) illustrating the operation of the ROHC U-mode.
  • FIG. 6 is a diagram (part 2) illustrating the operation of the ROHC U-mode.
  • FIG. 7 is a diagram illustrating the operation of the ROHC O-mode.
  • FIG. 8 is a diagram illustrating the operation of the ROHC R-mode.
  • FIG. 1 is a block diagram of a configuration example of a receiving node according to the first embodiment.
  • FIG. 2 is a block diagram of a configuration example of the transmission node according to the first embodiment.
  • FIG. 3 is a diagram of a configuration example
  • FIG. 9 is a diagram illustrating an example of a change in the call state.
  • FIG. 10 is a diagram illustrating an example of the MAC_PDU.
  • FIG. 11 is a diagram illustrating the MAC_Control_Element illustrated in FIG.
  • FIG. 12 is a diagram illustrating the Short_BSR illustrated in FIG.
  • FIG. 13 is a diagram illustrating the Long_BSR illustrated in FIG.
  • FIG. 14 is a diagram illustrating an index of the buffer size.
  • FIG. 15 is a diagram illustrating an example of the format of the data PDU.
  • FIG. 16 is a diagram illustrating an example of the format of the control PDU.
  • FIG. 17 is a flowchart illustrating an example of the operation of the receiving node illustrated in FIG. FIG.
  • FIG. 18 is a flowchart showing a specific example of step S1701 shown in FIG.
  • FIG. 19 is a diagram illustrating an example of operation mode switching of ROHC.
  • FIG. 20 is a block diagram of a configuration example of a receiving node according to the second embodiment.
  • FIG. 21 is a flowchart of an example of operation of the transmission node according to the second embodiment.
  • FIG. 22 is a block diagram of a configuration example of a receiving node according to the third embodiment.
  • FIG. 23 is a block diagram of a configuration example of a transmission node according to the third embodiment.
  • FIG. 24 is a diagram illustrating an example of a format of a PDCP frame.
  • FIG. 25 is a flowchart illustrating an example of the operation of the transmission node illustrated in FIG. FIG.
  • FIG. 26 is a flowchart showing a specific example of step S2501 shown in FIG.
  • FIG. 27 is a block diagram of a configuration example of a receiving node according to the fourth embodiment.
  • FIG. 28 is a block diagram of a configuration example of a transmission node according to the fourth embodiment.
  • FIG. 29 is a diagram illustrating an example of a format of a PDCP frame.
  • FIG. 30 is a flowchart of an example of operation of the receiving node according to the fifth embodiment.
  • FIG. 31 is a diagram showing a specific example of call state determination by the operation shown in FIG.
  • FIG. 32 is a block diagram of a configuration example of a receiving node according to the sixth embodiment.
  • FIG. 33 is a block diagram of a configuration example of a transmission node according to the sixth embodiment.
  • FIG. 34 is a diagram illustrating a specific example of switching from U-mode to O-mode.
  • FIG. 35 is a diagram illustrating a specific example of switching from U-mode to R-mode.
  • FIG. 36 is a diagram illustrating a specific example of switching from O-mode to U-mode.
  • FIG. 1 is a block diagram of a configuration example of a receiving node according to the first embodiment.
  • a receiving node 100 illustrated in FIG. 1 is an example in which the receiving apparatus according to the embodiment is applied to a UE (User Equipment: user terminal) in an LTE system.
  • the receiving node 100 includes a MAC layer termination unit 110, an RLC layer termination unit 120, a PDCP termination unit 130, an RTP / UDP / IP termination unit 140, and an AMR termination unit 150.
  • the MAC layer termination unit 110 terminates the function of the MAC layer in communication with the transmission node (see FIG. 2). For example, the MAC layer termination unit 110 performs error correction and retransmission control on voice data or control data transmitted from the transmission node.
  • the RLC layer termination unit 120 terminates the function of the RLC layer in communication with the transmission node.
  • the PDCP termination unit 130 terminates the function of the PDCP layer in communication with the transmission node. Further, the PDCP termination unit 130 terminates the function of the ROHC layer in communication with the transmission node. Specifically, the PDCP termination unit 130 includes a reception buffer 131, a reception processing unit 132, an expansion unit 133, a call state determination unit 134, a ROHC control unit 135, and a transmission processing unit 136. .
  • the reception buffer 131 temporarily stores PDCP_PDUs received via the MAC layer termination unit 110 and the RLC layer termination unit 120.
  • the reception processing unit 132 (reception unit) reads the PDCP_PDU stored in the reception buffer 131, performs header processing, and outputs the data subjected to the header processing to the decompression unit 133.
  • the PDCP_PDU read by the reception processing unit 132 is erased from the reception buffer 131.
  • the decompression unit 133 performs ROHC header decompression of the data output from the reception processing unit 132. Then, the decompression unit 133 outputs the data obtained by decompressing the ROHC header to the RTP / UDP / IP termination unit 140. The decompression unit 133 performs ROHC header decompression according to the operation mode switched by the ROHC control unit 135.
  • the call state determination unit 134 determines the call state of the voice data received by the reception node 100 from the transmission node, and notifies the ROHC control unit 135 of the determination result.
  • the call state determined by the call state determination unit 134 is, for example, a state relating to whether the sound indicated by the sound data is “sound” or “silence”. For example, the call state determination unit 134 determines the call state based on the amount of staying data in the reception buffer 131.
  • the call state determination unit 134 determines that the call state is “sound” when the amount of staying data in the reception buffer 131 is larger than the threshold, and when the amount of staying data in the reception buffer 131 is less than or equal to the threshold.
  • the call state is determined as “silent”.
  • the threshold value to be compared with the amount of voice data is, for example, a value corresponding to the size of SID data (Silence Insertion Descriptor) transmitted from the transmission node when the call state is “silent”.
  • the ROHC control unit 135 switches the operation mode of ROHC in the receiving node 100 and the transmitting node according to the determination result output from the call state determining unit 134. For example, the ROHC control unit 135 switches the operation mode of ROHC in the receiving node 100 and the transmitting node to any of U-mode, O-mode, and R-mode. Each operation of these ROHC will be described later (see FIGS. 5 to 8).
  • the ROHC control unit 135 generates a switching instruction signal indicating the switching operation mode in order to switch the operation mode of the ROHC. Then, the ROHC control unit 135 outputs the generated switching instruction signal to the transmission processing unit 136. Thereby, a switching instruction signal is transmitted to the transmission node, and the operation mode of ROHC is switched.
  • the transmission processing unit 136 adds a header to the PDCP_PDU. For example, the transmission processing unit 136 adds a header to the switching instruction signal output from the ROHC control unit 135. Then, the transmission processing unit 136 transmits the switching instruction signal provided with the header to the transmission node via the MAC layer termination unit 110 and the RLC layer termination unit 120.
  • the RTP / UDP / IP termination unit 140 terminates the function of the RTP / UDP / IP layer in communication with the transmission node.
  • the AMR termination unit 150 terminates the function of the AMR layer in communication with the transmission node. For example, the AMR termination unit 150 decodes audio data received from the transmission node.
  • the receiving node 100 may have a function related to an uplink in which the receiving node 100 (UE) transmits voice data to the transmitting node (eNB).
  • the call state determination unit 134 shown in FIG. 1 writes the determination result of the call state in the memory (not shown) of the receiving node 100.
  • the call state determination unit 134 is a calculation means such as a CPU (Central Processing Unit).
  • the ROHC control unit 135 reads the determination result written in the memory of the receiving node 100 by the call state determination unit 134, and switches the operation mode of the ROHC according to the read determination result.
  • the ROHC control unit 135 is a calculation means such as a CPU.
  • FIG. 2 is a block diagram of a configuration example of the transmission node according to the first embodiment.
  • a transmission node 200 illustrated in FIG. 2 is an example in which the transmission device according to the embodiment is applied to an eNB in an LTE system.
  • the transmission node 200 includes a PDCP termination unit 210, an RLC layer termination unit 220, and a MAC layer termination unit 230.
  • the PDCP termination unit 210 terminates the function of the PDCP layer in communication with the receiving node 100.
  • the PDCP termination unit 210 terminates the function of the ROHC layer in communication with the receiving node 100.
  • the PDCP termination unit 210 includes a transmission buffer 211, a compression unit 212, a transmission processing unit 213, and a reception processing unit 214.
  • the transmission buffer 211 temporarily stores PDCP_SDU transmitted from a higher system (for example, S-GW_IF) of the transmission node 200.
  • the compression unit 212 reads the PDCP_SDU stored in the transmission buffer 211, performs header compression, and outputs the PDCP_SDU subjected to header compression to the transmission processing unit 213.
  • the PDCP_SDU read by the compression unit 212 is deleted from the transmission buffer 211.
  • the compression unit 212 performs header compression according to the ROHC operation mode set in the transmission node 200. Specifically, the compression unit 212 acquires the ROHC operation mode switching instruction signal received from the reception node 100 from the reception processing unit 214. Then, the compression unit 212 performs header compression according to the operation mode indicated by the acquired switching instruction signal.
  • the transmission processing unit 213 adds a PDCP header to the PDCP_SDU output from the compression unit 212 and transmits the PDCP_PDU to the receiving node 100 via the RLC layer termination unit 220 and the MAC layer termination unit 230.
  • the reception processing unit 214 performs header processing of the PDCP_PDU received from the reception node 100 via the RLC layer termination unit 220 and the MAC layer termination unit 230.
  • the reception processing unit 214 performs header processing of the switching instruction signal received from the reception node 100 and outputs the result to the compression unit 212.
  • the RLC layer termination unit 220 terminates the RLC layer function in communication with the receiving node 100.
  • the MAC layer termination unit 230 terminates the function of the MAC layer in communication with the receiving node 100.
  • the transmission node 200 may have a function related to an uplink in which the reception node 100 (UE) transmits voice data to the transmission node 200 (eNB).
  • FIG. 3 is a diagram of a configuration example of the communication system according to the first embodiment.
  • a communication system 300 illustrated in FIG. 3 is an example in which the communication system according to the embodiment is applied to an LTE system.
  • the communication system 300 includes MME / S-GWs 311 and 312, eNBs 321 to 323, and UEs 331 and 332.
  • Each of the MME / S-GWs 311 and 312 has the functions of MME (Mobility Management Entity) and S-GW (Serving Gateway) in the LTE system.
  • MME Mobility Management Entity
  • S-GW Serving Gateway
  • Each of the eNBs 321 to 323 is an E-UTRAN_NodeB of the LTE system.
  • the eNBs 321 to 323 are connected to each other by an X2 interface.
  • each of the eNBs 321 to 323 performs voice communication with the UEs 331 and 332 by wireless communication.
  • Each of the UEs 331 and 332 is a mobile terminal such as a mobile phone.
  • 1 can be applied to at least one of the UEs 331 and 332, for example.
  • 2 can be applied to at least one of eNBs 321 to 323, for example.
  • the receiving node 100 shown in FIG. 1 may be applied to at least one of the eNBs 321 to 323, and the transmitting node 200 shown in FIG. 2 may be applied to at least one of the UEs 331 and 332.
  • the PDCP terminator 130 of the receiving node 100 shown in FIG. 1 is connected to a higher system (for example, S-GW_IF), and the RTP / UDP / IP terminator 140 and the AMR are connected to the transmitting node 200 shown in FIG.
  • the terminal part 150 (refer FIG. 1) is provided.
  • FIG. 4 is a diagram showing a protocol stack in the communication system shown in FIG. In the communication system 300 shown in FIG. 3, for example, the protocol stack 400 shown in FIG. 4 is applied.
  • a protocol stack 400 shown in FIG. 4 is a protocol stack studied in LTE with respect to IP conversion of real-time data such as voice communication.
  • UE411 is UE331,332 shown in FIG.
  • the eNB 412 is the eNBs 321 to 323 illustrated in FIG.
  • the S-GW 413 is the MME / S-GW 311 or 312 shown in FIG.
  • the PDN-GW 414 and the IP network 415 are connected to the MME / S-GWs 311 and 312 shown in FIG.
  • PHY and Ether indicate a physical layer (Physical) and Ethernet (registered trademark), respectively.
  • PHY Physical
  • Ethernet registered trademark
  • IP Internet Protocol
  • UDP User Datagram Protocol
  • RTP Real-time Transport Protocol
  • RTP uses a profile and a payload format according to the application.
  • GTP-U GPRS Tunneling Protocol
  • MAC Medium Access Control
  • RLC Radio Link Control
  • PDCP Packet Data Convergence Protocol
  • ROHC header compression
  • voice data (AMR) transmitted from the IP network 415 via RTP / UDP / IP is transmitted by ROHC, which is a PDCP function terminated at the eNB 412.
  • the RTP / UDP / IP header is compressed.
  • the voice data that has been compressed and transmitted to the UE 411 is decompressed by the ROHC when the PDCP is terminated in the UE 411, and restored to the original voice data.
  • FIG. 5 is a diagram (part 1) illustrating the operation of the ROHC U-mode.
  • the horizontal axis represents time.
  • the uncompressed frame 511 is audio data (including context) transmitted by the transmission node 200 without performing header compression.
  • the compressed frame 512 is audio data (not including context) transmitted by the transmission node 200 with header compression.
  • the lengths of the non-compressed frame 511 and the compressed frame 512 in the direction orthogonal to the horizontal axis indicate the size of each frame. Since the compressed frame 512 is subjected to header compression, the compressed frame 512 is smaller in size than the uncompressed frame 511 not subjected to header compression.
  • the ROHC operation mode of the receiving node 100 and the transmitting node 200 is set to U-mode (Unidirectional Mode).
  • the transmission node 200 transmits each frame in units of 20 [msec].
  • the transmission node 200 sets a frame to be transmitted in units of 180 [msec] among the frames to be transmitted as an uncompressed frame 511 and the other frames as a compressed frame 512.
  • the receiving node 100 receives each frame while expanding (restoring) the header of the compressed frame 512 based on the context included in the previously received uncompressed frame 511. For example, the receiving node 100 expands the header of each compressed frame 512 received in the period T522 immediately after the time t521, based on the context included in the uncompressed frame 511 received at the time t521.
  • the transmission node guarantees communication quality by transmitting a context at a constant cycle.
  • the feedback requesting the context (uncompressed frame 511) from the receiving node 100 is not performed. For this reason, the bandwidth of the link from the receiving node 100 to the transmitting node 200 is not compressed.
  • FIG. 6 is a diagram (part 2) illustrating the operation of the ROHC U-mode.
  • the same parts as those shown in FIG. It is assumed that the uncompressed frame 511 is not normally received by the receiving node 100 at time t611 when the ROHC operation mode is U-mode (see FIG. 5).
  • each compressed frame 512 received in the period T612 immediately after the time t611 is discarded in the PDCP layer, and the header cannot be normally expanded. For this reason, each compressed frame 512 received in the period T612 results in data loss, and voice quality deteriorates. In this case, for example, the voice is temporarily interrupted.
  • each compressed frame 512 causes data loss continues until the receiving node 100 receives the uncompressed frame 511 and the context is recovered. For this reason, the period during which each compressed frame 512 causes data loss depends on the cycle (here, 180 [msec]) at which the transmission node 200 transmits the context (uncompressed frame 511).
  • FIG. 7 is a diagram showing the operation of the ROHC O-mode.
  • the ROHC operation mode of the receiving node 100 and the transmitting node 200 is set to O-mode (Bidirectional Optimistic Mode).
  • the transmission node 200 transmits a frame whose header content is changed from the previous frame among the frames transmitted in units of 20 [msec] as an uncompressed frame 511 and transmits other frames as a compressed frame 512. .
  • the receiving node 100 receives each frame while decompressing (restoring) the header of the compressed frame 512 based on the context included in the previously received uncompressed frame 511.
  • the receiving node 100 transmits Nack to the transmitting node 200 when the uncompressed frame 511 cannot be normally received. For example, it is assumed that the receiving node 100 cannot normally receive the uncompressed frame 511 at time t711 and transmits Nack 701 to the transmitting node 200 at time t712 immediately after time t711.
  • the transmitting node 200 When receiving the Nack 701 from the receiving node 100, the transmitting node 200 retransmits the uncompressed frame 511. Assume that the receiving node 100 receives the uncompressed frame 511 retransmitted from the transmitting node 200 at time t713 after time t712.
  • Each compressed frame 512 received in the period T720 between the time t711 when the uncompressed frame 511 was not received and the time t713 when the uncompressed frame 511 was received is discarded at the PDCP layer, and the header is normally expanded. I can't. For this reason, each compressed frame 512 received in the period T720 results in data loss.
  • each compressed frame 512 causes data loss continues until the receiving node 100 receives the uncompressed frame 511 and the context is recovered. For this reason, the period during which each compressed frame 512 causes data loss depends on the period until the receiving node 100 transmits Nack to the transmitting node 200 and the transmitting node 200 retransmits the uncompressed frame 511 to the receiving node 100.
  • the communication quality is guaranteed by performing feedback from the receiving node 100. Since the context (uncompressed frame 511) is transmitted when the receiving node 100 cannot receive the frame normally, the transmission frequency of the compressed frame 512 is high and the header compression efficiency is excellent.
  • FIG. 8 is a diagram showing the operation of the ROHC R-mode.
  • the operation mode of ROHC of receiving node 100 and transmitting node 200 is set to R-mode (Bidirectional Reliable Mode).
  • the transmission node 200 transmits the uncompressed frame 511 in units of 20 [msec].
  • the transmitting node 200 receives an Ack for the uncompressed frame 511 from the receiving node 100, the transmitting node 200 thereafter transmits the compressed frame 512 until the header content is changed.
  • the receiving node 100 transmits Ack to the transmitting node 200 when the uncompressed frame 511 is normally received. For example, it is assumed that the receiving node 100 normally receives the uncompressed frame 511 and transmits Ack 801 to the transmitting node 200 at time t811. When receiving the Ack 801 from the receiving node 100, the transmitting node 200 transmits the compressed frame 512 until the header contents are changed thereafter.
  • the receiving node 100 cannot normally receive the uncompressed frame 511 at the time t812 after the time t811. Then, it is assumed that the reception node 100 normally receives the uncompressed frame 511 and transmits Ack 802 to the transmission node 200 at time t813 immediately after time t812. The transmission node 200 transmits the uncompressed frame 511 until the Ack 802 is received from the reception node 100, and after receiving the Ack 802 from the reception node 100, transmits the compressed frame 512 until the header contents are changed.
  • ROHC R-mode the transmission node 200 starts header compression when it receives Ack indicating that the context has normally reached the reception node 100. For this reason, ROHC R-mode is inferior in header compression efficiency to U-mode and O-mode, but has excellent context maintenance reliability. Further, there is no data loss time that accompanies the impossible header expansion after the context loss.
  • the switching between the ROHC operation modes shown in FIGS. 5 to 8 is performed by transmitting a switching instruction signal from the receiving node 100 to the transmitting node 200. Specific examples of switching between the operation modes of ROHC will be described later (see FIGS. 34 to 36).
  • FIG. 9 is a diagram illustrating an example of a change in the call state.
  • the horizontal axis represents time.
  • Reference numeral 910 indicates audio data transmitted from the transmission node 200 to the reception node 100.
  • Reference numeral 920 indicates audio data transmitted from the receiving node 100 to the transmitting node 200.
  • a person A indicates a user on the transmission node 200 side.
  • a person B represents a user on the receiving node 100 side.
  • the AMR data 911 is transmitted when voice is transmitted.
  • the SID data 912 is transmitted when there is no voice to be transmitted.
  • the length in the direction orthogonal to the horizontal axis indicates the data size. As shown in FIG. 9, the SID data 912 is smaller in size than the AMR data 911.
  • the sections 931 to 934 are time sections that are continuous in time.
  • the speech state of the voice data (symbol 910) transmitted from the transmission node 200 to the reception node 100 is “sound” in the section 931 and the section 933. Further, the speech state of the voice data (symbol 910) transmitted from the transmission node 200 to the reception node 100 is “silent” in the section 932 and the section 934.
  • the speech state of the voice data (symbol 920) transmitted from the receiving node 100 to the transmitting node 200 is “silent” in the section 931 and the section 933.
  • the speech state of the voice data (symbol 920) transmitted from the receiving node 100 to the transmitting node 200 is “sound” in the section 932 and the section 934.
  • the call state is “sound”
  • the AMR data 911 is discarded by PDCP because the header cannot be expanded
  • the voice quality is deteriorated.
  • the SID data 912 is not data indicating the user's voice in the section where the call state is “silent”, even if the SID data 912 is discarded in PDCP, the call is not affected.
  • the receiving node 100 and the transmitting node 200 determine the voice data call state, and switch the ROHC operation mode according to the determined call state. Thereby, it is possible to improve the sound quality when the call state is “sound”, and to improve the efficiency of header compression when the call state is “silent”.
  • FIG. 10 is a diagram illustrating an example of the MAC_PDU.
  • the frame format of the MAC layer of the audio data transmitted / received between the receiving node 100 and the transmitting node 200 is, for example, MAC_PDU 1000 shown in FIG.
  • the MAC_PDU 1000 is a MAC frame format located in the lower layer of PDCP in the LTE system.
  • the MAC_PDU 1000 includes a MAC_Header 1010 and a MAC_Payload 1020.
  • the MAC_Payload 1020 includes a MAC_Control_Element 1021 (see FIG. 11), a MAC_SDU 1022, and a padding 1023.
  • FIG. 11 is a diagram showing the MAC_Control_Element shown in FIG. A table 1100 illustrated in FIG. 11 indicates various types of the MAC_Control_Element 1021 illustrated in FIG. 10.
  • the type of the MAC_Control_Element 1021 includes “UE Content Resolution Identity”, “Timing Advance”, and “DRX Command”. It is.
  • the types of MAC_Control_Element 1021 include “Power Headroom Report”, “C-RNTI”, “Short_BSR”, “ Long_BSR ".
  • Short_BSR and “Long_BSR” indicate the amount of data retained in the buffer. Therefore, the transmission node 200 can notify the reception node 100 of the amount of data retained in the transmission buffer 211 by “Short_BSR” or “Long_BSR” included in the MAC_Control_Element 1021.
  • FIG. 12 is a diagram showing the Short_BSR shown in FIG.
  • the frame format of “Short_BSR” illustrated in FIG. 11 is, for example, Short_BSR1200.
  • the Short_BSR 1200 includes LCG_ID 1210 (Logical Channel Group) and a buffer size 1220.
  • LCG_ID 1210 is an ID indicating each logical channel group (for example, logical channel groups # 1 to # 4).
  • the buffer size 1220 indicates the total staying data amount of each logical channel group indicated by the LCG_ID 1210. A specific example of the buffer size 1220 will be described later (see FIG. 14).
  • FIG. 13 shows the Long_BSR shown in FIG.
  • the frame format of “Long_BSR” shown in FIG. 11 is, for example, Long_BSR1300.
  • the Long_BSR 1300 includes buffer sizes # 1 to # 4. Each buffer size # 1 to # 4 indicates the total amount of staying data for each UE. Specific examples of the buffer sizes # 1 to # 4 will be described later (see FIG. 14).
  • FIG. 14 is a diagram showing an index of the buffer size.
  • the buffer size 1220 shown in FIG. 12 or the buffer sizes # 1 to # 4 shown in FIG. 13 are indicated by, for example, an index based on the table 1400 shown in FIG.
  • the buffer size (BS) 0 [Bytes] is indicated by the index “0”.
  • a buffer size greater than 0 [Bytes] and less than or equal to 10 [Bytes] is indicated by an index “1”.
  • a buffer size greater than 10 [Bytes] and less than or equal to 12 [Bytes] is indicated by an index “2”.
  • FIG. 15 is a diagram showing an example of the format of the data PDU.
  • the frame format of the PDCP header of the data PDU transmitted / received between the receiving node 100 and the transmitting node 200 is, for example, a PDCP frame 1500 shown in FIG.
  • the PDCP frame 1500 includes D / C 1510, R1520 (Reserved), a PDCP sequence number 1530, and data 1540.
  • D / C 1510 is a value indicating whether the PDCP frame 1500 is a data PDU or a control PDU. In the PDCP frame 1500, the D / C 1510 is “1” indicating a data PDU. R1520 is not used here.
  • the PDCP sequence number 1530 is a sequence number of the PDCP frame 1500.
  • the data 1540 is, for example, the above-described AMR data 911 and SID data 912.
  • FIG. 16 is a diagram showing an example of the format of the control PDU. 16, the same parts as those shown in FIG. 15 are denoted by the same reference numerals, and the description thereof is omitted.
  • the PDCP header of the control PDU transmitted / received between the receiving node 100 and the transmitting node 200 is, for example, a PDCP frame 1600 shown in FIG.
  • the PDCP frame 1600 includes D / C 1510, PDU type 1610, R1520, and Interpersed_ROHC_feedback_packet 1620.
  • the D / C 1510 is “0” indicating a control PDU.
  • the PDU type 1610 indicates the type of control PDU (PDCP status report or header compression feedback information).
  • FIG. 17 is a flowchart illustrating an example of the operation of the receiving node illustrated in FIG.
  • the receiving node 100 shown in FIG. 1 performs each step shown in FIG.
  • the call state determination unit 134 of the reception node 100 determines the call state (“sound” or “silence”) of voice data that the reception node 100 receives from the transmission node 200 (step S1701).
  • the call state determination unit 134 determines whether or not the call state determined in step S1701 has changed from the call state determined last time by the call state determination unit 134 (step S1702). If the call state has not changed (step S1702: NO), the process returns to step S1701 to continue the process.
  • step S1702 If the call state has changed in step S1702 (step S1702: Yes), the ROHC control unit 135 switches the ROHC operation mode according to the call state determined in step S1701 (step S1703), and a series of operations is performed. finish. If the call state is “silent” in step S1703, the ROHC control unit 135 switches the operation mode of the ROHC to, for example, U-mode with a high header compression frequency.
  • step S1703 when the call state is “sound”, the ROHC control unit 135 switches the operation mode of the ROHC to, for example, O-mode or R-mode with a low header compression frequency. Thereby, it is possible to improve the sound quality when the call state is “sound”, and to improve the efficiency of header compression when the call state is “silent”.
  • FIG. 18 is a flowchart showing a specific example of step S1701 shown in FIG.
  • the call state determination unit 134 executes, for example, the following steps. First, it is determined whether or not the elapsed time from the start of this operation has become a monitoring cycle (for example, 20 [msec]) or more (step S1801), and waits until the elapsed time becomes the monitoring cycle or more (step S1801: No loop).
  • a monitoring cycle for example, 20 [msec]
  • step S1801 No loop
  • step S1801 when the elapsed time is equal to or longer than the monitoring cycle (step S1801: Yes), the amount of data retained in the reception buffer 131 is measured (step S1802). Next, it is determined whether or not the call state stored in the memory by the previous determination by the call state determination unit 134 is “sound” (step S1803).
  • step S1803 when the call state is “sound” (step S1803: Yes), it is determined whether or not the amount of staying data measured in step S1802 is equal to or less than a threshold value (step S1804). If the amount of staying data is not less than or equal to the threshold value (step S1804: No), the series of processing ends.
  • step S1804 if the amount of staying data measured in step S1802 is less than or equal to the threshold (step S1804: Yes), the call state stored in the memory is updated to “silence” (step S1805), and a series of processes Exit.
  • step S1803 when the call state is not “sound” (step S1803: No), it is determined whether or not the amount of staying data measured in step S1802 is larger than the threshold (step S1806). When the amount of staying data is not larger than the threshold value (step S1806: No), the series of processes is terminated.
  • step S1806 when the amount of staying data measured in step S1802 is larger than the threshold (step S1806: Yes), the call state stored in the memory is updated to “sound” (step S1807), and a series of processes Exit.
  • the threshold used for comparison in step S1804 and step S1806 is a threshold corresponding to the size of the SID data 912 shown in FIG. 9, for example.
  • FIG. 19 is a diagram illustrating an example of operation mode switching of ROHC.
  • the horizontal axis represents time.
  • Reference numeral 1910 indicates audio data transmitted from the transmission node 200 to the reception node 100.
  • the AMR data 1911 is transmitted when sound is transmitted (sound).
  • the SID data 1912 is transmitted when there is no sound to be transmitted (silence).
  • the sections 1921 to 1924 are time sections that are continuous in time.
  • the call state is “sound”, and the AMR data 1911 is transmitted.
  • the call state is “silent”, and the SID data 1912 is transmitted.
  • Reference numeral 1930 indicates switching of the ROHC operation mode by the receiving node 100.
  • the receiving node 100 determines that the call state is “sound” in the sections 1921 and 1923.
  • Receiving node 100 switches the operation mode of ROHC to R-mode (may be O-mode, for example) in sections 1921 and 1923.
  • the receiving node 100 determines that the call state is “silent” in the sections 1922 and 1924. Then, the receiving node 100 switches the ROHC operation mode to U-mode in the sections 1922 and 1924.
  • the operation mode of the ROHC can be set to U-mode with high header compression frequency, and the utilization efficiency of the radio band can be improved.
  • the voice quality can be improved by setting the ROHC operation mode to R-mode with a low header compression frequency.
  • the receiving node 100 (receiving device) according to the first embodiment, it is possible to determine the call state and switch the operation mode of the ROHC according to the determined call state. Thereby, it is possible to improve the sound quality when the call state is sound, and to improve the efficiency of header compression when the call state is silent. For this reason, it is possible to improve the sound quality and bandwidth utilization efficiency of the sound data.
  • the amount of staying data in the reception buffer 131 can be measured, and the call state can be determined based on the measured amount of staying data.
  • the call state (“sound” or “silence”) can be easily determined by comparing the measured amount of staying data with a threshold value.
  • the call state is determined using the BSR transmitted from the transmitting node 200 to the receiving node 100 in the LTE system.
  • the MAC_Control_Element of the MAC_PDU (see FIG. 10) transmitted from the transmission node 200 to the reception node 100 includes the BSR (see FIGS. 11 to 13) indicating the amount of data remaining in the transmission buffer 211 of the transmission node 200. It is.
  • FIG. 20 is a block diagram of a configuration example of a receiving node according to the second embodiment.
  • the reception processing unit 2011 performs reception processing in the MAC layer.
  • the reception processing unit 2011 outputs each data subjected to the reception processing to the RLC layer termination unit 120 and the MCE termination unit 2012.
  • the MCE termination unit 2012 terminates an MCE (MAC_Control_Element).
  • the MCE termination unit 2012 acquires the BSR (see FIGS. 11 to 13) included in the data output from the reception processing unit 2011.
  • the BSR indicates the amount of data retained in the transmission buffer 211 in the transmission node 200.
  • the MCE termination unit 2012 outputs the acquired BSR to the PDCP termination unit 130 as a staying data amount.
  • the transmission processing unit 2013 performs transmission processing in the MAC layer. The transmission processing unit 2013 transmits each data subjected to the transmission process to the transmission node 200.
  • the call state determination unit 134 of the PDCP termination unit 130 determines the call state based on the amount of staying data output from the MCE termination unit 2012. Specifically, the call state determination unit 134 determines that the call state is “sound” when the amount of staying data output from the MCE termination unit 2012 is larger than the threshold value. The call state determination unit 134 determines that the call state is “silent” when the amount of staying data output from the MCE termination unit 2012 is equal to or less than the threshold value.
  • FIG. 21 is a flowchart of an example of operation of the transmission node according to the second embodiment.
  • the basic operation of the receiving node 100 shown in FIG. 20 is the same as the operation shown in FIG.
  • the call state determination unit 134 of the receiving node 100 illustrated in FIG. 20 performs the following steps in step S1701 illustrated in FIG.
  • step S2101 it is determined whether or not the elapsed time since the start of the operation has become equal to or longer than the monitoring cycle (step S2101), and waits until the elapsed time becomes equal to or longer than the monitoring cycle (step S2101: No loop).
  • step S2101: Yes the data amount information (BSR) transmitted from the transmission node 200 is received via the MCE termination unit 2012 (step S2102).
  • the data amount information received in step S2102 indicates the amount of staying data in the transmission buffer 211 of the transmission node 200.
  • step S2103 it is determined whether or not the call state stored in the memory by the previous determination is “sound” (step S2103).
  • step S2103: Yes it is determined whether or not the staying data amount indicated by the data amount information received in step S2102 is equal to or less than a threshold value (step S2104). If the amount of staying data is not less than or equal to the threshold value (step S2104: No), the series of processing ends.
  • step S2104 If the staying data amount indicated by the received data amount information is equal to or less than the threshold value in step S2104 (step S2104: Yes), the call state stored in the memory is updated to “silent” (step S2105), Terminate the process.
  • step S2103 if the call state is not “sound” (step S2103: No), it is determined whether or not the staying data amount indicated by the data amount information received in step S2102 is larger than the threshold (step S2106). When the amount of staying data is not larger than the threshold value (step S2106: No), the series of processing ends.
  • step S2106 when the staying data amount indicated by the received data amount information is larger than the threshold value (step S2106: Yes), the call state stored in the memory is updated to “sound” (step S2107). Terminate the process. If the BSR buffer size is indexed as shown in FIG. 14, the thresholds used for comparison in step S2104 and step S2106 also use the index shown in FIG.
  • the receiving node 100 (receiving device) according to the second embodiment, it is possible to determine the call state and switch the operation mode of the ROHC according to the determined call state. Thereby, it is possible to improve the sound quality when the call state is sound, and to improve the efficiency of header compression when the call state is silent. For this reason, it is possible to improve the sound quality and bandwidth utilization efficiency of the sound data.
  • the transmission node 200 measures the amount of staying data in the transmission buffer 211 and transmits data amount information indicating the measured amount of staying data to the reception node 100. Thereby, the receiving node 100 can determine the call state based on the staying data amount indicated by the data amount information received from the transmitting node 200. By using the data retention amount on the transmission node 200 side, it is possible to accurately determine the call state regardless of the quality of the wireless section.
  • the data amount information is transmitted using the BSR included in the MAC_Control_Element of the MAC_PDU (see FIG. 10) transmitted from the transmission node 200 to the reception node 100.
  • the data amount information can be transmitted to the receiving node 100 without newly adding a control signal to be transmitted from the transmitting node 200 to the receiving node 100.
  • FIG. 22 is a block diagram of a configuration example of a receiving node according to the third embodiment. 22, the same components as those illustrated in FIG. 1 are denoted by the same reference numerals, and description thereof is omitted.
  • the receiving node 100 according to the third embodiment may be configured such that the call state determination unit 134 illustrated in FIG. 1 is omitted.
  • the reception processing unit 132 outputs the call state information transmitted from the transmission node 200 among the data read from the reception buffer 131 to the ROHC control unit 135.
  • the ROHC control unit 135 switches the operation mode of the ROHC according to the call state determination result (“sound” or “silence”) indicated by the call state information output from the reception processing unit 132.
  • FIG. 23 is a block diagram of a configuration example of a transmission node according to the third embodiment.
  • the PDCP termination unit 210 of the transmission node 200 according to the third embodiment includes a call state determination unit 2310 in addition to the configuration illustrated in FIG.
  • the call state determination unit 2310 determines a call state of voice data transmitted from the transmission node 200 to the reception node 100, and outputs call state information indicating the determination result to the transmission processing unit 213.
  • the call state determined by the call state determination unit 2310 is, for example, a state relating to whether the sound indicated by the sound data is “sound” or “silence”.
  • the call state determination unit 2310 determines the call state based on the amount of staying data in the transmission buffer 211, for example.
  • the call state determination unit 2310 determines that the call state is “sound” when the amount of staying data in the transmission buffer 211 is greater than the threshold, and when the amount of staying data in the transmission buffer 211 is less than or equal to the threshold.
  • the call state is determined as “silent”.
  • the threshold value to be compared with the amount of audio data is, for example, a value corresponding to the amount of SID data that stays in the transmission buffer 211 when the call state is “silent” and the transmission node 200 transmits SID data.
  • the transmission processing unit 213 transmits the call state information output from the call state determination unit 2310 to the receiving node 100 via the RLC layer termination unit 220 and the MAC layer termination unit 230. As a result, the call state information can be transmitted to the receiving node 100.
  • a PDCP frame for transmitting call state information will be described with reference to FIG.
  • FIG. 24 is a diagram illustrating an example of a format of a PDCP frame.
  • the frame format of the PDCP header of the control PDU transmitted from the transmission processing unit 213 to the receiving node 100 is, for example, a PDCP frame 2400 shown in FIG.
  • the PDCP frame 2400 includes D / C 1510, PDU type 1610, R1520, and TSF2410 (Telephone call Status Flag).
  • the D / C 1510 becomes “0” indicating the control PDU.
  • TSF 2410 indicates a call state of voice data transmitted from the transmission node 200 to the reception node 100.
  • the transmission processing unit 213 stores the call state information output from the call state determination unit 2310 in the TSF 2410 of the PDCP frame 2400.
  • the reception processing unit 132 of the reception node 100 outputs the TSF 2410 of the PDCP frame 2400 received from the transmission node 200 to the ROHC control unit 135 as call state information.
  • FIG. 25 is a flowchart illustrating an example of the operation of the transmission node illustrated in FIG.
  • the sending node 200 shown in FIG. 23 performs each step shown in FIG.
  • the call state determination unit 2310 of the transmission node 200 determines the call state of voice data transmitted from the transmission node 200 to the reception node 100 (step S2501).
  • the call state determination unit 2310 determines whether or not the call state determined in step S2501 has changed from the call state determined last time by the call state determination unit 2310 (step S2502). If the call state has not changed (step S2502: NO), the process returns to step S2501 to continue the process.
  • step S2502 If the call state has changed in step S2502 (step S2502: Yes), the transmission processing unit 213 transmits call state information indicating the call state determined in step S2501 to the receiving node 100 (step S2503). Terminate the process.
  • the call state information transmitted in step S2503 is received by the receiving node 100.
  • the receiving node 100 switches the operation mode of the ROHC with the transmitting node 200 according to the call state indicated by the received call state information.
  • FIG. 26 is a flowchart showing a specific example of step S2501 shown in FIG.
  • the call state determination unit 2310 executes, for example, the following steps. First, it is determined whether or not the elapsed time since the start of this operation has become equal to or longer than the monitoring cycle (step S2601), and waits until the elapsed time becomes equal to or longer than the monitoring cycle (step S2601: No loop).
  • step S2601 when the elapsed time becomes equal to or longer than the monitoring cycle (step S2601: Yes), the amount of staying data in the transmission buffer 211 is measured (step S2602).
  • Steps S2603 to S2607 shown in FIG. 26 are the same as steps S1803 to S1807 shown in FIG.
  • the receiving node 100 (receiving apparatus) according to the third embodiment, it is possible to determine the call state and switch the operation mode of the ROHC according to the determined call state. Thereby, it is possible to improve the sound quality when the call state is sound, and to improve the efficiency of header compression when the call state is silent. For this reason, it is possible to improve the sound quality and bandwidth utilization efficiency of the sound data.
  • the call state is determined at the transmission node 200, and the call state information indicating the determination result is transmitted to the reception node 100.
  • the receiving node 100 can switch the operation mode of ROHC according to the call state indicated by the call state information received from the transmission node 200.
  • the call state can be accurately determined regardless of the quality of the wireless section.
  • the processing load on the receiving node 100 side can be reduced by determining the call state on the transmitting node 200 side.
  • the TSF 2410 is provided in the PDCP frame 2400 transmitted from the transmission node 200 to the reception node 100, and the call state information is transmitted using the TSF 2410, whereby the call state information can be transmitted to the reception node 100.
  • FIG. 27 is a block diagram of a configuration example of a receiving node according to the fourth embodiment.
  • the reception processing unit 132 of the reception node 100 according to the fourth embodiment outputs data amount information of the reception processed data to the call state determination unit 134.
  • the data amount information output to the call state determination unit 134 indicates the amount of staying data in the transmission buffer 211 in the transmission node 200.
  • the call state determination unit 134 determines the call state based on the staying data amount indicated by the data amount information output from the reception processing unit 132. Specifically, the call state determination unit 134 determines the call state as “sound” when the amount of staying data is larger than the threshold value, and determines the call state as “silent” when the amount of staying data is equal to or less than the threshold value. To do.
  • FIG. 28 is a block diagram of a configuration example of a transmission node according to the fourth embodiment.
  • the PDCP termination unit 210 of the transmission node 200 according to the third embodiment includes a retained data amount measurement unit 2810 in addition to the configuration illustrated in FIG.
  • the staying data amount measurement unit 2810 measures the staying data amount in the transmission buffer 211 and outputs data amount information indicating the measured staying data amount to the transmission processing unit 213.
  • the transmission processing unit 213 transmits the data amount information output from the staying data amount measurement unit 2810 to the receiving node 100 via the RLC layer termination unit 220 and the MAC layer termination unit 230. Thereby, the data amount information can be transmitted to the receiving node 100.
  • a PDCP frame for transmitting data amount information will be described with reference to FIG.
  • FIG. 29 is a diagram illustrating an example of a format of a PDCP frame. 29, the same parts as those shown in FIG. 16 are denoted by the same reference numerals, and the description thereof is omitted.
  • the frame format of the PDCP header of the control PDU transmitted by the transmission processing unit 213 of the transmission node 200 is, for example, a PDCP frame 2900 shown in FIG.
  • the PDCP frame 2900 includes a D / C 1510, a PDU type 1610, and a BSR 2910.
  • the D / C 1510 is “0” indicating the control PDU.
  • BSR 2910 indicates the amount of data retained in the transmission buffer 211 of the transmission node 200.
  • the transmission processing unit 213 stores the data amount information output from the staying data amount measurement unit 2810 in the BSR 2910 of the PDCP frame 2900 and transmits it to the receiving node 100.
  • the reception processing unit 132 of the reception node 100 outputs the BSR 2910 of the PDCP frame 2900 received from the transmission node 200 as a staying data amount to the call state determination unit 134.
  • the receiving node 100 (receiving device) according to the fourth embodiment, it is possible to determine the call state and switch the operation mode of the ROHC according to the determined call state. Thereby, it is possible to improve the sound quality when the call state is sound, and to improve the efficiency of header compression when the call state is silent.
  • the transmission node 200 measures the amount of staying data in the transmission buffer 211 and transmits data amount information indicating the measured amount of staying data to the reception node 100. Thereby, the receiving node 100 can determine the call state based on the staying data amount indicated by the data amount information received from the transmitting node 200. By using the data retention amount on the transmission node 200 side, it is possible to accurately determine the call state regardless of the quality of the wireless section.
  • the BSR 2910 in the PDCP frame 2900 transmitted from the transmission node 200 to the reception node 100 and transmitting the data amount information using the BSR 2910 the amount of staying data can be transmitted from the transmission node 200 to the reception node 100.
  • the call state determination unit 134 of the reception node 100 determines that the call state is “sound” when the amount of retained data in the reception buffer 131 is greater than a threshold value for a predetermined period or longer. Further, the call state determination unit 134 determines the call state as “silent” when the amount of staying data in the reception buffer 131 is equal to or greater than a threshold value for a predetermined period or more.
  • the configurations of receiving node 100 and transmitting node 200 are the same as those shown in FIGS. 1 and 2, for example.
  • FIG. 30 is a flowchart of an example of operation of the receiving node according to the fifth embodiment.
  • the basic operation of the receiving node 100 according to the fifth embodiment is the same as the operation illustrated in FIG. Further, the call state determination unit 134 of the receiving node 100 according to the fifth embodiment performs the following steps in step S1701 illustrated in FIG.
  • step S3001 the counter k is set to 0 (step S3001).
  • step S3002 it is determined whether or not the elapsed time since the start of the operation has become equal to or longer than the monitoring cycle (step S3002), and waits until the elapsed time becomes equal to or longer than the monitoring cycle (step S3002: No loop).
  • step S3002 when the elapsed time becomes equal to or longer than the monitoring cycle (step S3002: Yes), the amount of staying data in the reception buffer 131 is measured (step S3003). Next, it is determined whether or not the call state stored in the memory by the previous determination is “sound” (step S3004).
  • step S3004 when the call state is “sound” (step S3004: Yes), it is determined whether or not the staying data amount measured in step S3003 is equal to or less than a threshold (step S3005). If the amount of staying data is not less than or equal to the threshold (step S3005: No), the process proceeds to step S3009 and the process is continued.
  • step S3007 when the counter k is not larger than the protection stage number (step S3007: No), the process returns to step S3002 and the processing is continued.
  • step S3007: Yes When the counter k is larger than the protection stage number (step S3007: Yes), the call state stored in the memory is updated to “silence” (step S3008).
  • step S3009 the series of processes is terminated.
  • step S3004 when the call state is not “sound” (step S3004: No), it is determined whether or not the staying data amount measured in step S3003 is larger than the threshold (step S3010). If the amount of staying data is not greater than the threshold (step S3010: No), the process proceeds to step S3014 and the process is continued.
  • step S3012 when the counter k is not larger than the protection stage number (step S3012: No), the process returns to step S3002 to continue the processing.
  • step S3012: Yes When the counter k is larger than the protection stage number (step S3012: Yes), the call state stored in the memory is updated to “sound” (step S3013).
  • step S3014 the counter k is set to 0 (step S3014), and the series of processes is terminated.
  • the call state determination unit 134 ignores the counter k if the value of the counter k does not exceed the number of protection steps even if the amount of staying data is equal to or less than the threshold in step S3005. As a result, the call state determination unit 134 can determine that the call state is “silent” when the amount of staying data in the reception buffer 131 is equal to or greater than a threshold value for a predetermined period or more.
  • the call state determination unit 134 ignores if the value of the counter k does not exceed the protection stage number. Accordingly, the call state determination unit 134 can determine that the call state is “sound” when the amount of staying data in the reception buffer 131 is greater than the threshold value for a predetermined period or longer.
  • FIG. 31 is a diagram showing a specific example of call state determination by the operation shown in FIG.
  • parts that are the same as the parts shown in FIG. 19 are given the same reference numerals, and descriptions thereof will be omitted.
  • the horizontal axis represents time.
  • Reference numeral 3110 indicates audio data transmitted from the transmission node 200 to the reception node 100.
  • the initial value of the call state is “silence”
  • the monitoring period is 20 [ms]
  • the threshold corresponding to the size of the SID data 1912
  • the protection stage number is 3.
  • the receiving node 100 acquires the amount of staying data in the receiving buffer 131 at a monitoring period of 20 [ms], and increments the counter k when the amount of staying data exceeds a threshold value of 10 [bytes].
  • the monitoring periods T1 to T23 are monitoring periods (20 [ms]) in the receiving node 100.
  • the receiving node 100 determines that the call state remains “silent” because the counter k is equal to or less than 3 protection stages. For this reason, in the monitoring periods T1 to T3, the call state is determined to be “silent”.
  • the reception node 100 determines that the call state has changed to “sound” because the counter k exceeds the protection stage number 3 in the monitoring period T4.
  • the receiving node 100 cannot normally receive the AMR data 1911 in the monitoring period T7.
  • the actual call state of the audio data transmitted from the transmission node 200 to the reception node 100 becomes “silence” after the monitoring cycle T12.
  • the receiving node 100 normally receives the SID data 1912 (size 10 [bytes]) in each of the monitoring periods T12, T16, and T20.
  • the receiving node 100 has a “silent” call state stored in the memory, and the staying data amount is 10 [bytes] or 0 [bytes] and is equal to or less than the threshold 10 [bytes].
  • the call state determination unit 134 ignores the value of the counter k when the value of the counter k does not exceed the protection stage number even when the amount of staying data is equal to or less than the threshold value at the time T7. As a result, it is possible to avoid erroneous determination that the call state becomes “silent” when the receiving node 100 cannot normally receive the AMR data 1911.
  • the receiving node 100 (receiving apparatus) according to the fifth embodiment, it is possible to determine the call state and switch the operation mode of the ROHC according to the determined call state. Thereby, it is possible to improve the sound quality when the call state is sound, and to improve the efficiency of header compression when the call state is silent. For this reason, it is possible to improve the sound quality and bandwidth utilization efficiency of the sound data.
  • the call state is determined to be “sound”, so that it is erroneously determined that the call state becomes “sound” due to an instantaneous increase in traffic. The determination can be avoided.
  • the call state is determined to be “silent”, so that the call state is changed to “sound” due to an instantaneous decrease in traffic due to frame loss or the like It is possible to avoid misjudging that it has become.
  • the configurations of the reception node 100 and the transmission node 200 are the same as the configuration (embodiment 1) shown in FIG. 1 and FIG.
  • the configuration of receiving node 100 and transmitting node 200 may be the same as in any of Embodiments 2 to 4.
  • a case will be described in which the configurations of receiving node 100 and transmitting node 200 are the same as those shown in FIGS. 22 and 23 (the third embodiment).
  • the call state determination unit 2310 of the transmission node 200 determines that the call state is “sound” when the amount of staying data in the transmission buffer 211 is greater than the threshold value for a predetermined period or longer. In addition, the call state determination unit 2310 determines that the call state is “silent” when the amount of staying data in the transmission buffer 211 is equal to or greater than a threshold value for a predetermined period or more.
  • FIG. 32 is a block diagram of a configuration example of a receiving node according to the sixth embodiment.
  • the receiving node 100 according to the sixth embodiment may be configured to omit the ROHC control unit 135 and the transmission processing unit 136 shown in FIG.
  • FIG. 33 is a block diagram of a configuration example of a transmission node according to the sixth embodiment.
  • the same components as those shown in FIG. 33 the PDCP termination unit 210 of the transmission node 200 according to the sixth embodiment includes a ROHC control unit 3310 in addition to the configuration illustrated in FIG.
  • the transmission node 200 may be configured to omit the reception processing unit 214 shown in FIG.
  • Call state determination unit 2310 outputs call state information indicating the determination result to ROHC control unit 3310.
  • the ROHC control unit 3310 (control means) switches the operation mode of ROHC in the reception node 100 and the transmission node 200 according to the determination result output from the call state determination unit 2310.
  • the ROHC control unit 3310 notifies the compression unit 212 of the operation mode to be switched in order to switch the operation mode of the ROHC.
  • the ROHC control unit 3310 generates a switching instruction signal indicating an operation mode to be switched. Then, the ROHC control unit 3310 outputs the generated switching instruction signal to the transmission processing unit 213. Thereby, the switching instruction signal is transmitted to the receiving node 100, and the operation mode of the ROHC is switched. Since the switching of the ROHC operation mode by the ROHC control unit 3310 is the same as the switching by the ROHC control unit 135 described above, the description thereof is omitted.
  • the compression unit 212 is a calculation unit such as a CPU.
  • the transmission processing unit 213 reads the audio data written in the memory of the transmission node 200 by the compression unit 212 and transmits the read audio data.
  • the call state determination unit 2310 writes the determination result of the call state in the memory (not shown) of the transmission node 200.
  • Call state determination unit 2310 is a calculation unit such as a CPU.
  • the ROHC control unit 3310 reads the determination result written in the memory of the transmission node 200 by the call state determination unit 2310, and switches the operation mode of the ROHC according to the read determination result.
  • the ROHC control unit 3310 is a calculation unit such as a CPU.
  • the transmission node 200 (transmission apparatus) according to the sixth embodiment, it is possible to determine the call state and switch the operation mode of the ROHC according to the determined call state. Thereby, it is possible to improve the sound quality when the call state is sound, and to improve the efficiency of header compression when the call state is silent. For this reason, it is possible to improve the sound quality and bandwidth utilization efficiency of the sound data.
  • the call state can be accurately determined regardless of the quality of the wireless section. Further, the processing load on the receiving node 100 side can be reduced by determining the call state and switching the operation mode of the ROHC on the transmitting node 200 side.
  • FIG. 34 is a diagram illustrating a specific example of switching from U-mode to O-mode. 34, the same parts as those shown in FIG. 5 are denoted by the same reference numerals and description thereof is omitted.
  • C_MODE 3410 indicates an operation mode of ROHC set in the compression unit 212 of the transmission node 200.
  • C_MODE 3410 takes a value of “U-mode”, “O-mode” or “R-mode”.
  • C_TRANS 3420 is a transition progress state of the operation mode of ROHC set in the compression unit 212 of the transmission node 200.
  • C_TRANS 3420 takes a value of “Pending” or “Done”.
  • D_MODE 3430 is a ROHC operation mode set in the decompression unit 133 of the receiving node 100.
  • the D_MODE 3430 takes a value of “U-mode”, “O-mode”, or “R-mode”.
  • D_TRANS 3440 is a transition progress state of the operation mode of ROHC set in the decompression unit 133 of the receiving node 100.
  • the D_TRANS 3440 takes a value of “Initiated”, “Pending”, or “Done”.
  • Switching from U-mode to O-mode can be performed at an arbitrary timing as long as a feedback channel from the receiving node 100 to the transmitting node 200 is available. For example, it is assumed that the ROHC operation mode of the reception node 100 and the transmission node 200 is U-mode in the period before the time t3411.
  • the receiving node 100 transmits a switching instruction signal 3450 for switching the ROHC operation mode to O-mode to the transmitting node 200 at time t3411.
  • the transmitting node 200 switches the ROHC operation mode in the transmitting node 200 to O-mode.
  • the transmitting node 200 stops transmitting the periodic uncompressed frame 511 and transmits the compressed frame 512 until receiving Nack from the receiving node 100.
  • the receiving node 100 and the transmitting node 200 can perform switching at an arbitrary timing. Therefore, the C_TRANS 3420 and the D_TRANS 3440 can be switched while being “Done”.
  • FIG. 35 is a diagram showing a specific example of switching from U-mode to R-mode. 35, the same parts as those shown in FIG. 34 are denoted by the same reference numerals, and description thereof is omitted. Switching from U-mode to R-mode is performed after at least one uncompressed frame 511 is normally received. For example, in the period before time t3511, it is assumed that the ROHC operation mode of the receiving node 100 and the transmitting node 200 is U-mode.
  • the receiving node 100 transmits a switching instruction signal 3521 for switching the ROHC operation mode to R-mode to the transmitting node 200 at time t3511.
  • the transmitting node 200 switches the operation mode to R-mode and continuously transmits the uncompressed frames 511 to the receiving node 100.
  • the receiving node 100 When receiving the uncompressed frame 511 transmitted from the transmitting node 200, the receiving node 100 switches the ROHC operation mode in the receiving node 100 to R-mode. During a period from time t3511 when the receiving node 100 transmits the switching instruction signal 3521 to time t3512 when the receiving node 100 receives the uncompressed frame 511 transmitted from the transmitting node 200, D_TRANS3440 becomes “Initiated”.
  • receiving node 100 when receiving node 100 normally receives uncompressed frame 511 transmitted from transmitting node 200 at time t3512, receiving node 100 transmits Ack 3522 to transmitting node 200. When receiving the Ack 3522, the transmitting node 200 continuously transmits the compressed frame 512 to the receiving node 100 until receiving the Nack from the receiving node 100.
  • C_TRANS 3420 becomes “Pending” during the period from when the transmission node 200 switches the ROHC operation mode to R-mode until the transmission node 200 receives the Ack 3522. Further, D_TRANS 3440 in the period from the time t3512 when the receiving node 100 transmits Ack 3522 to the time t3513 when the receiving node 100 receives the compressed frame 512 becomes “Pending”.
  • FIG. 36 is a diagram showing a specific example of switching from O-mode to U-mode. 36, the same portions as those shown in FIG. 34 are denoted by the same reference numerals and description thereof is omitted. Switching from O-mode to U-mode can be performed at an arbitrary timing. For example, in the period before time t3611, it is assumed that the ROHC operation mode of the receiving node 100 and the transmitting node 200 is O-mode.
  • the reception node 100 transmits a switching instruction signal 3621 for switching the ROHC operation mode to U-mode to the transmission node 200 at time t3611.
  • the transmitting node 200 switches the ROHC operation mode in the transmitting node 200 to U-mode.
  • the transmission node 200 starts transmission of a periodic uncompressed frame 511. Further, the transmission node 200 transmits the uncompressed frames 511 three times continuously when the ROHC operation mode is switched to the U-mode, and receives the Ack for these uncompressed frames 511 from the reception node 100. May be. As a result, it is possible to confirm that the operation mode has been switched normally (Three-way handshake).
  • the receiving node 100 switches the ROHC operation mode to U-mode at time t3612 when the uncompressed frame 511 is received from the transmitting node 200 after transmitting the switching instruction signal 3621.
  • D_TRANS3440 in the period from the time t3611 when the receiving node 100 transmits the switching instruction signal 3621 to the time t3613 when the receiving node 100 receives the compressed frame 512 from the transmitting node 200 becomes “Initiated”. Switching from the R-mode to the U-mode is the same as the switching from the O-mode to the U-mode, and a description thereof will be omitted.
  • reception device As described above, according to the disclosed reception device, transmission device, reception method, transmission method, communication system, and communication method, it is possible to determine the call state and switch the ROHC operation mode according to the determined call state. it can. Thereby, it is possible to improve the sound quality when the call state is sound, and to improve the efficiency of header compression when the call state is silent. For this reason, it is possible to improve the sound quality and bandwidth utilization efficiency of the sound data.
  • the disclosed reception device, transmission device, reception method, transmission method, communication system, and communication method may be other communication such as WiMAX. It can also be applied to a system.
  • the ROHC operation mode when the call state is “sound”, the ROHC operation mode is switched to O-mode or R-mode, and when the call state is “silence”, the ROHC operation mode is changed.
  • the configuration for switching to the U-mode has been described.
  • the ROHC operation mode when the call state is “sound”, the ROHC operation mode may be switched to R-mode, and when the call state is “silence”, the ROHC operation mode may be switched to O-mode.
  • O-mode has higher header compression efficiency than R-mode, and therefore has higher header compression efficiency. For this reason, when the call state is “silent”, the header compression efficiency can be improved by switching the ROHC operation mode to O-mode.
  • the header compression operation mode is not limited to the ROHC U-mode, O-mode, and R-mode, and various operation modes having different header compression frequencies can be used.

Landscapes

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

Abstract

　受信ノード（１００）は、音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信ノードである。受信ノード（１００）は、受信処理部（１３２）と、通話状態判定部（１３４）と、ＲＯＨＣ制御部（１３５）と、を備えている。受信処理部（１３２）は、ヘッダ圧縮を行う送信装置から送信される音声データを受信する。通話状態判定部（１３４）は、受信処理部（１３２）によって受信される音声データの通話状態を判定する。ＲＯＨＣ制御部（１３５）は、通話状態判定部（１３４）の判定結果に応じて動作モードを切り替える。

Description

受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法
　この発明は、音声通信を行う受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法に関する。
　ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）システムは、３Ｇセルラーシステムからの飛躍的な性能向上を目指し、３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）で国際標準化が進められている。ＬＴＥシステムは、モバイル通信で高速伝送を実現し、高速映像配信など高度なサービス環境を提供するとともに、効率的な周波数利用が図られるシステムとして期待されている。
　また、既存（３Ｇまで）システムにおいては、音声とデータ通信とはそれぞれ別の通信インフラで提供されていたが、ＬＴＥシステムにおいては音声とデータ通信とをＩＰベースに統合する「ａｌｌ　ＩＰ」への移行が意図されている。これにより、従来の回線交換型インフラを含むシステムから、ＬＴＥシステムによって、完全なＩＰ化がなされたシステムが実現されると見込まれている。
　ＬＴＥシステムにおけるリアルタイムデータの伝送は、一般的な有線ＩＰネットワークにおけるＶｏＩＰ（Ｖｏｉｃｅ　ｏｖｅｒ　ＩＰ）と同様にＲＴＰ／ＵＤＰ／ＩＰの各プロトコルによって実現される。このため、ＬＴＥシステムにおけるリアルタイムデータは、各プロトコルのヘッダが付与されることによりオーバヘッドが大きくなる。
　帯域幅の限られる無線区間を含むネットワークにおいては、無線区間の帯域利用効率を向上させるために、オーバヘッドとなる各プロトコルのヘッダを圧縮する機能が求められる。このヘッダ圧縮機能は、ＬＴＥシステムにおいて実現される見込みである。
　具体的には、ｅＮＢ～ＵＥ間で終端されるＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）の機能に含まれるＲＯＨＣ（ＲＯｂｕｓｔ　Ｈｅａｄｅｒ　Ｃｏｍｐｒｅｓｓｉｎｇ）と呼ばれる技術がヘッダ圧縮機能として実現される見込みである。ＲＯＨＣには、ヘッダ圧縮の効率が異なる複数の動作モードが存在する（たとえば、下記特許文献１参照。）。
特開２００２－１３５３６２号公報
　しかしながら、上述した従来技術では、ヘッダ圧縮を頻繁に行うと、フレーム欠落などの場合に音声データを復元できずにデータロスとなり、音声データの音質が劣化するという問題がある。一方、ヘッダ圧縮の頻度を低くすると、データのオーバヘッドが大きくなるため、伝送経路の帯域利用効率が低下するという問題がある。
　開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法は、上述した問題点を解消するものであり、音声データの音質および帯域利用効率の向上を図ることを目的とする。
　上述した課題を解決し、目的を達成するため、この受信装置は、音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信装置において、前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信手段と、前記受信手段によって受信される音声データの通話状態を判定する判定手段と、前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、を備える。
　上記構成によれば、通話状態を判定し、判定した通話状態に応じてヘッダ圧縮の頻度が異なる複数の動作モードを切り替えることができる。
　開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法によれば、音声データの音質および帯域利用効率の向上を図ることができる。
図１は、実施の形態１にかかる受信ノードの構成例を示すブロック図である。 図２は、実施の形態１にかかる送信ノードの構成例を示すブロック図である。 図３は、実施の形態１にかかる通信システムの構成例を示す図である。 図４は、図３に示した通信システムにおけるプロトコルスタックを示す図である。 図５は、ＲＯＨＣのＵ－ｍｏｄｅの動作を示す図（その１）である。 図６は、ＲＯＨＣのＵ－ｍｏｄｅの動作を示す図（その２）である。 図７は、ＲＯＨＣのＯ－ｍｏｄｅの動作を示す図である。 図８は、ＲＯＨＣのＲ－ｍｏｄｅの動作を示す図である。 図９は、通話状態の変化の一例を示す図である。 図１０は、ＭＡＣ＿ＰＤＵの一例を示す図である。 図１１は、図１０に示したＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔを示す図である。 図１２は、図１１に示したＳｈｏｒｔ＿ＢＳＲを示す図である。 図１３は、図１１に示したＬｏｎｇ＿ＢＳＲを示す図である。 図１４は、バッファサイズのインデクスを示す図である。 図１５は、データＰＤＵのフォーマットの一例を示す図である。 図１６は、コントロールＰＤＵのフォーマットの一例を示す図である。 図１７は、図１に示した受信ノードの動作の一例を示すフローチャートである。 図１８は、図１７に示したステップＳ１７０１の具体例を示すフローチャートである。 図１９は、ＲＯＨＣの動作モード切替の一例を示す図である。 図２０は、実施の形態２にかかる受信ノードの構成例を示すブロック図である。 図２１は、実施の形態２にかかる送信ノードの動作の一例を示すフローチャートである。 図２２は、実施の形態３にかかる受信ノードの構成例を示すブロック図である。 図２３は、実施の形態３にかかる送信ノードの構成例を示すブロック図である。 図２４は、ＰＤＣＰフレームのフォーマットの一例を示す図である。 図２５は、図２３に示した送信ノードの動作の一例を示すフローチャートである。 図２６は、図２５に示したステップＳ２５０１の具体例を示すフローチャートである。 図２７は、実施の形態４にかかる受信ノードの構成例を示すブロック図である。 図２８は、実施の形態４にかかる送信ノードの構成例を示すブロック図である。 図２９は、ＰＤＣＰフレームのフォーマットの一例を示す図である。 図３０は、実施の形態５にかかる受信ノードの動作の一例を示すフローチャートである。 図３１は、図３０に示した動作による通話状態判定の具体例を示す図である。 図３２は、実施の形態６にかかる受信ノードの構成例を示すブロック図である。 図３３は、実施の形態６にかかる送信ノードの構成例を示すブロック図である。 図３４は、Ｕ－ｍｏｄｅからＯ－ｍｏｄｅへの切替の具体例を示す図である。 図３５は、Ｕ－ｍｏｄｅからＲ－ｍｏｄｅへの切替の具体例を示す図である。 図３６は、Ｏ－ｍｏｄｅからＵ－ｍｏｄｅへの切替の具体例を示す図である。
符号の説明
　３００　通信システム
　３１１，３１２　ＭＭＥ／Ｓ－ＧＷ
　３２１～３２３　ｅＮＢ
　３３１，３３２　ＵＥ
　４００　プロトコルスタック
　５１１　非圧縮フレーム
　５１２　圧縮フレーム
　８０１，３５２２　Ａｃｋ
　９１１，１９１１　ＡＭＲデータ
　９１２，１９１２　ＳＩＤデータ
　１０００　ＭＡＣ＿ＰＤＵ
　１５００，１６００，２４００，２９００　ＰＤＣＰフレーム
　３４１０　Ｃ＿ＭＯＤＥ
　３４２０　Ｃ＿ＴＲＡＮＳ
　３４３０　Ｄ＿ＭＯＤＥ
　３４４０　Ｄ＿ＴＲＡＮＳ
　３４５０，３５２１，３６２１　切替指示信号
　Ｔ１～Ｔ２３　監視周期
　以下に添付図面を参照して、この受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法の好適な実施の形態を詳細に説明する。
（実施の形態１）
（受信ノードの構成例）
　図１は、実施の形態１にかかる受信ノードの構成例を示すブロック図である。図１に示す受信ノード１００は、実施の形態にかかる受信装置をＬＴＥシステムにおけるＵＥ（Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ：ユーザ端末）に適用した例である。受信ノード１００は、ＭＡＣレイヤ終端部１１０と、ＲＬＣレイヤ終端部１２０と、ＰＤＣＰ終端部１３０と、ＲＴＰ／ＵＤＰ／ＩＰ終端部１４０と、ＡＭＲ終端部１５０と、を備えている。
　ＭＡＣレイヤ終端部１１０は、送信ノード（図２参照）との間の通信におけるＭＡＣレイヤの機能を終端する。たとえば、ＭＡＣレイヤ終端部１１０は、送信ノードから送信された音声データまたは制御データに対する誤り訂正や再送制御を行う。ＲＬＣレイヤ終端部１２０は、送信ノードとの間の通信におけるＲＬＣレイヤの機能を終端する。
　ＰＤＣＰ終端部１３０は、送信ノードとの間の通信におけるＰＤＣＰレイヤの機能を終端する。また、ＰＤＣＰ終端部１３０は、送信ノードとの間の通信におけるＲＯＨＣレイヤの機能を終端する。具体的には、ＰＤＣＰ終端部１３０は、受信バッファ１３１と、受信処理部１３２と、伸張部１３３と、通話状態判定部１３４と、ＲＯＨＣ制御部１３５と、送信処理部１３６と、を備えている。
　受信バッファ１３１は、ＭＡＣレイヤ終端部１１０およびＲＬＣレイヤ終端部１２０を介して受信したＰＤＣＰ＿ＰＤＵを一時格納する。受信処理部１３２（受信手段）は、受信バッファ１３１に格納されたＰＤＣＰ＿ＰＤＵを読み出してヘッダ処理を行い、ヘッダ処理を行ったデータを伸張部１３３へ出力する。受信処理部１３２によって読み出されたＰＤＣＰ＿ＰＤＵは受信バッファ１３１から消去される。
　伸張部１３３は、受信処理部１３２から出力されたデータのＲＯＨＣのヘッダ伸張を行う。そして、伸張部１３３は、ＲＯＨＣのヘッダ伸張を行ったデータをＲＴＰ／ＵＤＰ／ＩＰ終端部１４０へ出力する。また、伸張部１３３は、ＲＯＨＣ制御部１３５によって切り替えられる動作モードに応じてＲＯＨＣのヘッダ伸張を行う。
　通話状態判定部１３４（判定手段）は、受信ノード１００が送信ノードから受信した音声データの通話状態を判定し、判定結果をＲＯＨＣ制御部１３５へ通知する。通話状態判定部１３４が判定する通話状態は、たとえば、音声データが示す音声が「有音」であるか「無音」であるかに関する状態である。通話状態判定部１３４は、たとえば、受信バッファ１３１の滞留データ量に基づいて通話状態を判定する。
　具体的には、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が閾値より大きい場合は通話状態を「有音」と判定し、受信バッファ１３１の滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。音声データの量と比較する閾値は、たとえば、通話状態が「無音」である場合に送信ノードから送信されるＳＩＤデータ（Ｓｉｌｅｎｃｅ　Ｉｎｓｅｒｔｉｏｎ　Ｄｅｓｃｒｉｐｔｏｒ）のサイズに相当する値である。
　ＲＯＨＣ制御部１３５（制御手段）は、通話状態判定部１３４から出力された判定結果に応じて、受信ノード１００および送信ノードにおけるＲＯＨＣの動作モードを切り替える。たとえば、ＲＯＨＣ制御部１３５は、受信ノード１００および送信ノードにおけるＲＯＨＣの動作モードを、Ｕ－ｍｏｄｅ、Ｏ－ｍｏｄｅおよびＲ－ｍｏｄｅのいずれかに切り替える。これらのＲＯＨＣの各動作については後述する（図５～図８参照）。
　ＲＯＨＣ制御部１３５は、ＲＯＨＣの動作モードを切り替えるために、切り替える動作モードを示す切替指示信号を生成する。そして、ＲＯＨＣ制御部１３５は、生成した切替指示信号を送信処理部１３６へ出力する。これにより、切替指示信号が送信ノードへ送信され、ＲＯＨＣの動作モードが切り替わる。
　送信処理部１３６は、ＰＤＣＰ＿ＰＤＵへのヘッダ付与を行う。たとえば、送信処理部１３６は、ＲＯＨＣ制御部１３５から出力された切替指示信号にヘッダを付与する。そして、送信処理部１３６は、ヘッダを付与した切替指示信号を、ＭＡＣレイヤ終端部１１０およびＲＬＣレイヤ終端部１２０を介して送信ノードへ送信する。
　ＲＴＰ／ＵＤＰ／ＩＰ終端部１４０は、送信ノードとの間の通信におけるＲＴＰ／ＵＤＰ／ＩＰレイヤの機能を終端する。ＡＭＲ終端部１５０は、送信ノードとの間の通信におけるＡＭＲレイヤの機能を終端する。たとえば、ＡＭＲ終端部１５０は、送信ノードから受信した音声データの復号を行う。
　図１においては、送信ノード（ｅＮＢ）から送信された音声データを受信ノード１００（ＵＥ）が受信するダウンリンクに関する機能について説明した。ただし、受信ノード１００は、受信ノード１００（ＵＥ）が送信ノード（ｅＮＢ）へ音声データを送信するアップリンクに関する機能を備えていてもよい。
　図１に示した通話状態判定部１３４は、通話状態の判定結果を受信ノード１００のメモリ（不図示）に書き込む。通話状態判定部１３４は、たとえばＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）などの演算手段である。ＲＯＨＣ制御部１３５は、通話状態判定部１３４によって受信ノード１００のメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じてＲＯＨＣの動作モードを切り替える。ＲＯＨＣ制御部１３５は、たとえばＣＰＵなどの演算手段である。
（送信ノードの構成例）
　図２は、実施の形態１にかかる送信ノードの構成例を示すブロック図である。図２に示す送信ノード２００は、実施の形態にかかる送信装置をＬＴＥシステムにおけるｅＮＢに適用した例である。送信ノード２００は、ＰＤＣＰ終端部２１０と、ＲＬＣレイヤ終端部２２０と、ＭＡＣレイヤ終端部２３０と、を備えている。
　ＰＤＣＰ終端部２１０は、受信ノード１００との間の通信におけるＰＤＣＰレイヤの機能を終端する。また、ＰＤＣＰ終端部２１０は、受信ノード１００との間の通信におけるＲＯＨＣレイヤの機能を終端する。具体的には、ＰＤＣＰ終端部２１０は、送信バッファ２１１と、圧縮部２１２と、送信処理部２１３と、受信処理部２１４と、を備えている。
　送信バッファ２１１は、送信ノード２００の上位のシステム（たとえばＳ－ＧＷ＿ＩＦ）から送信されたＰＤＣＰ＿ＳＤＵを一時格納する。圧縮部２１２は、送信バッファ２１１に格納されたＰＤＣＰ＿ＳＤＵを読み出してヘッダ圧縮を行い、ヘッダ圧縮を行ったＰＤＣＰ＿ＳＤＵを送信処理部２１３へ出力する。
　圧縮部２１２によって読み出されたＰＤＣＰ＿ＳＤＵは送信バッファ２１１から消去される。また、圧縮部２１２は、送信ノード２００において設定されているＲＯＨＣの動作モードによってヘッダ圧縮を行う。具体的には、圧縮部２１２は、受信ノード１００から受信したＲＯＨＣの動作モードの切替指示信号を受信処理部２１４から取得する。そして、圧縮部２１２は、取得した切替指示信号が示す動作モードによってヘッダ圧縮を行う。
　送信処理部２１３は、圧縮部２１２から出力されたＰＤＣＰ＿ＳＤＵにＰＤＣＰヘッダを付与しＰＤＣＰ＿ＰＤＵとして、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００へ送信する。受信処理部２１４は、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００から受信したＰＤＣＰ＿ＰＤＵのヘッダ処理を行う。
　たとえば、受信処理部２１４は、受信ノード１００から受信した切替指示信号のヘッダ処理を行って圧縮部２１２へ出力する。ＲＬＣレイヤ終端部２２０は、受信ノード１００との間の通信におけるＲＬＣレイヤの機能を終端する。ＭＡＣレイヤ終端部２３０は、受信ノード１００との間の通信におけるＭＡＣレイヤの機能を終端する。
　図２においては、送信ノード２００（ｅＮＢ）から送信された音声データを受信ノード１００（ＵＥ）が受信するダウンリンクに関する機能について説明した。ただし、送信ノード２００は、受信ノード１００（ＵＥ）が送信ノード２００（ｅＮＢ）へ音声データを送信するアップリンクに関する機能を備えていてもよい。
（通信システムの構成例）
　図３は、実施の形態１にかかる通信システムの構成例を示す図である。図３に示す通信システム３００は、実施の形態にかかる通信システムをＬＴＥシステムに適用した例である。通信システム３００は、ＭＭＥ／Ｓ－ＧＷ３１１，３１２と、ｅＮＢ３２１～３２３と、ＵＥ３３１，３３２と、を含んでいる。
　ＭＭＥ／Ｓ－ＧＷ３１１，３１２のそれぞれは、ＬＴＥシステムにおけるＭＭＥ（Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｅｎｔｉｔｙ）およびＳ－ＧＷ（Ｓｅｒｖｉｎｇ　Ｇａｔｅｗａｙ）の機能を備えている。ＭＭＥ／Ｓ－ＧＷ３１１，３１２のそれぞれは、ｅＮＢ３２１～３２３のそれぞれとＳ１インターフェースによって接続されている。
　ｅＮＢ３２１～３２３のそれぞれは、ＬＴＥシステムのＥ－ＵＴＲＡＮ＿ＮｏｄｅＢである。ｅＮＢ３２１～３２３は、Ｘ２インターフェースによって互いに接続されている。また、ｅＮＢ３２１～３２３のそれぞれは、無線通信によってＵＥ３３１，３３２との間で音声通信を行う。ＵＥ３３１，３３２のそれぞれは、携帯電話などの移動端末である。
　図１に示した受信ノード１００は、たとえばＵＥ３３１，３３２の少なくともいずれかに適用することができる。また、図２に示した送信ノード２００は、たとえばｅＮＢ３２１～３２３の少なくともいずれかに適用することができる。
　また、図１に示した受信ノード１００を、ｅＮＢ３２１～３２３の少なくともいずれかに適用し、図２に示した送信ノード２００をＵＥ３３１，３３２の少なくともいずれかに適用してもよい。この場合は、図１に示した受信ノード１００のＰＤＣＰ終端部１３０を上位のシステム（たとえばＳ－ＧＷ＿ＩＦ）に接続し、図２に示した送信ノード２００にＲＴＰ／ＵＤＰ／ＩＰ終端部１４０およびＡＭＲ終端部１５０（図１参照）を備える。
　図４は、図３に示した通信システムにおけるプロトコルスタックを示す図である。図３に示した通信システム３００において、たとえば図４に示すプロトコルスタック４００を適用する。図４に示すプロトコルスタック４００は、音声通信などのリアルタイムデータのＩＰ化に関してＬＴＥにおいて検討されているプロトコルスタックである。
　図４において、ＵＥ４１１は、図３に示したＵＥ３３１，３３２である。ｅＮＢ４１２は、図３に示したｅＮＢ３２１～３２３である。Ｓ－ＧＷ４１３は、図３に示したＭＭＥ／Ｓ－ＧＷ３１１，３１２である。ＰＤＮ－ＧＷ４１４およびＩＰ網４１５は、図３に示したＭＭＥ／Ｓ－ＧＷ３１１，３１２に接続されている。
　プロトコルスタック４００において、「ＰＨＹ」および「Ｅｔｈｅｒ」は、それぞれ物理レイヤ（Ｐｈｙｓｉｃａｌ）およびイーサネット（登録商標）を示している。「ＰＨＹ」および「Ｅｔｈｅｒ」は、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ：構内通信網）およびＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ：広域通信網）の基本インターフェースとして規定されているものを使用する。
　「ＩＰ」（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）は、インターネットで使用するレイヤ３である。「ＩＰ」は、データのルーティング機能を提供する。「ＵＤＰ」（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）は、コネクションレス型の転送プロトコルである。「ＲＴＰ」（Ｒｅａｌ－ｔｉｍｅＴｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ）は、リアルタイムメディア転送のためのフレームワークを提供する。「ＲＴＰ」は、プロファイルやペイロードフォーマットをアプリケーションに合わせて使用する。
　「ＧＴＰ－Ｕ」（ＧＰＲＳ　Ｔｕｎｎｅｌｉｎｇ　Ｐｒｏｔｏｃｏｌ）は、ＬＴＥ／ＳＡＥ網内においてユーザデータをトンネリングさせる。「ＭＡＣ」（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）は、スケジューリング、プライオリティ制御、ＨＡＲＱ（Ｈｙｂｒｉｄ　Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　Ｒｅｑｕｅｓｔ）によるエラー訂正およびトランスフォーマットの選択などを行う。
　「ＲＬＣ」（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌ）は、ＡＲＱ（Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　Ｒｅｑｕｅｓｔ）によるエラー訂正などを行う。「ＰＤＣＰ」（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）は、ヘッダ圧縮（ＲＯＨＣ）などを行う。
　ダウンリンク（ｅＮＢ→ＵＥ）を例にとると、ＩＰ網４１５側からＲＴＰ／ＵＤＰ／ＩＰを介して送信されてくる音声データ（ＡＭＲ）は、ｅＮＢ４１２において終端されるＰＤＣＰの機能であるＲＯＨＣによって、ＲＴＰ／ＵＤＰ／ＩＰのヘッダが圧縮される。ヘッダが圧縮されＵＥ４１１まで伝送された音声データは、ＵＥ４１１においてＰＤＣＰが終端される際にＲＯＨＣによってヘッダが伸張され、元の音声データに復元される。
（ＲＯＨＣの各動作モード）
　図５は、ＲＯＨＣのＵ－ｍｏｄｅの動作を示す図（その１）である。図５において、横軸は時間を示している。ＲＴＰ／ＵＤＰ／ＩＰのレイヤにおいて、送信ノード２００が２０［ｍｓｅｃ］の周期のフレームによって音声データを受信ノード１００へ送信する場合について説明する。非圧縮フレーム５１１は、送信ノード２００がヘッダ圧縮を行わずに送信した（コンテキストを含む）音声データである。圧縮フレーム５１２は、送信ノード２００がヘッダ圧縮を行って送信した（コンテキストを含まない）音声データである。
　非圧縮フレーム５１１および圧縮フレーム５１２の横軸と直交する方向（図の縦方向）の長さは、各フレームのサイズを示している。圧縮フレーム５１２は、ヘッダ圧縮が行われているため、ヘッダ圧縮が行われていない非圧縮フレーム５１１よりもサイズが小さくなっている。ここでは、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＵ－ｍｏｄｅ（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ　Ｍｏｄｅ）に設定されている。
　具体的には、送信ノード２００は、２０［ｍｓｅｃ］単位で各フレームを送信する。送信ノード２００は、送信する各フレームのうちの、１８０［ｍｓｅｃ］単位で送信するフレームは非圧縮フレーム５１１とし、それ以外のフレームは圧縮フレーム５１２とする。
　受信ノード１００は、圧縮フレーム５１２のヘッダを、以前に受信した非圧縮フレーム５１１に含まれているコンテキストに基づいて伸張（復元）しながら各フレームを受信する。たとえば、受信ノード１００は、時期ｔ５２１において受信した非圧縮フレーム５１１に含まれているコンテキストに基づいて、時期ｔ５２１の直後の期間Ｔ５２２において受信した各圧縮フレーム５１２のヘッダを伸張する。
　このように、ＲＯＨＣのＵ－ｍｏｄｅにおいては、送信ノードが一定周期でコンテキストを送信することにより通信の品質保証を行う。この場合は、受信ノード１００からコンテキスト（非圧縮フレーム５１１）を要求するフィードバックを行わない。このため、受信ノード１００から送信ノード２００へのリンクの帯域を圧迫しない。
　図６は、ＲＯＨＣのＵ－ｍｏｄｅの動作を示す図（その２）である。図６において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。ＲＯＨＣの動作モードがＵ－ｍｏｄｅである場合（図５参照）で、時期ｔ６１１において非圧縮フレーム５１１が正常に受信ノード１００に受信されなかったとする。
　この場合は、時期ｔ６１１の直後の期間Ｔ６１２において受信する各圧縮フレーム５１２については、ＰＤＣＰのレイヤで破棄され、ヘッダの伸張を正常に行うことができない。このため、期間Ｔ６１２において受信する各圧縮フレーム５１２はデータロスとなり、音声品質が劣化する。この場合は、たとえば、一時的に音声が不通になる。
　各圧縮フレーム５１２がデータロスとなる期間は、つぎに受信ノード１００が非圧縮フレーム５１１を受信してコンテキストが回復されるまで継続する。このため、各圧縮フレーム５１２がデータロスとなる期間は、送信ノード２００がコンテキスト（非圧縮フレーム５１１）を送信する周期（ここでは１８０［ｍｓｅｃ］）に依存する。
　図７は、ＲＯＨＣのＯ－ｍｏｄｅの動作を示す図である。図７において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。ここでは、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＯ－ｍｏｄｅ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ　Ｏｐｔｉｍｉｓｔｉｃ　Ｍｏｄｅ）に設定されている。
　送信ノード２００は、２０［ｍｓｅｃ］単位で送信する各フレームのうちの、ヘッダの内容が前のフレームから変更になったフレームは非圧縮フレーム５１１とし、それ以外のフレームは圧縮フレーム５１２として送信する。受信ノード１００は、圧縮フレーム５１２のヘッダを、以前に受信した非圧縮フレーム５１１に含まれているコンテキストに基づいて伸張（復元）しながら各フレームを受信する。
　また、受信ノード１００は、非圧縮フレーム５１１を正常に受信することができなかった場合に、送信ノード２００に対してＮａｃｋを送信する。たとえば、時期ｔ７１１において、受信ノード１００が非圧縮フレーム５１１を正常に受信できず、時期ｔ７１１の直後の時期ｔ７１２において送信ノード２００へＮａｃｋ７０１を送信したとする。
　送信ノード２００は、受信ノード１００からＮａｃｋ７０１を受信すると、非圧縮フレーム５１１を再送する。受信ノード１００は、時期ｔ７１２の後の時期ｔ７１３において、送信ノード２００から再送された非圧縮フレーム５１１を受信したとする。
　非圧縮フレーム５１１が受信できなかった時期ｔ７１１から非圧縮フレーム５１１を受信した時期ｔ７１３の間の期間Ｔ７２０において受信した各圧縮フレーム５１２については、ＰＤＣＰのレイヤで破棄され、ヘッダの伸張を正常に行うことができない。このため、期間Ｔ７２０において受信する各圧縮フレーム５１２はデータロスとなる。
　各圧縮フレーム５１２がデータロスとなる期間は、つぎに受信ノード１００が非圧縮フレーム５１１を受信してコンテキストが回復されるまで継続する。このため、各圧縮フレーム５１２がデータロスとなる期間は、受信ノード１００が送信ノード２００へＮａｃｋを送信し、送信ノード２００が受信ノード１００へ非圧縮フレーム５１１を再送するまでの期間に依存する。
　このように、ＲＯＨＣのＯ－ｍｏｄｅにおいては、受信ノード１００からのフィードバックを行うことにより通信の品質保証を行う。コンテキスト（非圧縮フレーム５１１）は、受信ノード１００がフレームを正常に受信できなかった場合に送信されるため、圧縮フレーム５１２の送信頻度が高く、ヘッダ圧縮効率が優れている。
　図８は、ＲＯＨＣのＲ－ｍｏｄｅの動作を示す図である。図８において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。ここでは、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＲ－ｍｏｄｅ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ　Ｒｅｌｉａｂｌｅ　Ｍｏｄｅ）に設定されている。
　送信ノード２００は、２０［ｍｓｅｃ］単位で非圧縮フレーム５１１を送信する。そして、送信ノード２００は、非圧縮フレーム５１１に対するＡｃｋを受信ノード１００から受信すると、その後はヘッダの内容が変更になるまで圧縮フレーム５１２を送信する。
　受信ノード１００は、非圧縮フレーム５１１を正常に受信した場合に、送信ノード２００に対してＡｃｋを送信する。たとえば、時期ｔ８１１において、受信ノード１００が非圧縮フレーム５１１を正常に受信して送信ノード２００へＡｃｋ８０１を送信したとする。送信ノード２００は、受信ノード１００からＡｃｋ８０１を受信すると、その後はヘッダの内容が変更になるまで圧縮フレーム５１２を送信する。
　また、時期ｔ８１１の後の時期ｔ８１２において、受信ノード１００が非圧縮フレーム５１１を正常に受信できなかったとする。そして、時期ｔ８１２の直後の時期ｔ８１３において、受信ノード１００が非圧縮フレーム５１１を正常に受信して送信ノード２００へＡｃｋ８０２を送信したとする。送信ノード２００は、受信ノード１００からＡｃｋ８０２を受信するまでは非圧縮フレーム５１１を送信し、受信ノード１００からＡｃｋ８０２を受信すると、その後はヘッダの内容が変更になるまで圧縮フレーム５１２を送信する。
　このように、ＲＯＨＣのＲ－ｍｏｄｅにおいては、送信ノード２００は、コンテキストが受信ノード１００へ正常に到達したことを示すＡｃｋを受信するとヘッダ圧縮を開始する。このため、ＲＯＨＣのＲ－ｍｏｄｅは、Ｕ－ｍｏｄｅやＯ－ｍｏｄｅに比べてヘッダ圧縮効率は劣る一方、コンテキスト維持の信頼性が優れている。また、コンテキスト喪失時の以降のヘッダ伸張不可に伴うデータロス時間は発生しない。
　図５～図８に示したＲＯＨＣの各動作モード間の切替は、受信ノード１００から送信ノード２００へ切替指示信号を送信することによって行う。ＲＯＨＣの各動作モード間の切替の具体例については後述する（図３４～図３６参照）。
（通話状態の変化）
　図９は、通話状態の変化の一例を示す図である。図９において、横軸は時間を示している。符号９１０は、送信ノード２００から受信ノード１００へ送信される音声データを示している。符号９２０は、受信ノード１００から送信ノード２００へ送信される音声データを示している。人物Ａは、送信ノード２００側のユーザを示している。人物Ｂは、受信ノード１００側のユーザを示している。
　ＡＭＲデータ９１１は、音声を伝送するときに送信される。ＳＩＤデータ９１２は、伝送する音声がない場合に送信される。ＡＭＲデータ９１１およびＳＩＤデータ９１２において、横軸に直交する方向（図の縦方向）の長さはデータのサイズを示している。図９に示すように、ＳＩＤデータ９１２はＡＭＲデータ９１１よりサイズが小さい。
　区間９３１～９３４は、時間的に連続する時間区間である。送信ノード２００から受信ノード１００へ送信される音声データ（符号９１０）の通話状態は、区間９３１および区間９３３においては「有音」となっている。また、送信ノード２００から受信ノード１００へ送信される音声データ（符号９１０）の通話状態は、区間９３２および区間９３４においては「無音」となっている。
　一方、受信ノード１００から送信ノード２００へ送信される音声データ（符号９２０）の通話状態は、区間９３１および区間９３３においては「無音」となっている。また、受信ノード１００から送信ノード２００へ送信される音声データ（符号９２０）の通話状態は、区間９３２および区間９３４においては「有音」となっている。
　口論のようなケースを例外とすれば、一般的な通話においては人物Ａと人物Ｂとが交互に発言する。このため、送信ノード２００から受信ノード１００へ送信される音声データ（符号９１０）および受信ノード１００から送信ノード２００へ送信される音声データ（符号９２０）において、通話状態が「有音」の区間と「無音」の区間とが存在する。
　通話状態が「有音」の区間においては、ヘッダ伸張不可などによりＰＤＣＰでＡＭＲデータ９１１が破棄されると音声品質の劣化に繋がる。一方で、通話状態が「無音」の区間においては、ＳＩＤデータ９１２はユーザの音声を示すデータではないため、ＰＤＣＰにおいてＳＩＤデータ９１２が破棄されても通話に影響しない。
　このことを利用して、受信ノード１００および送信ノード２００は、音声データの通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替える。これにより、通話状態が「有音」のときは音質の向上を図り、通話状態が「無音」のときはヘッダ圧縮の効率化を図ることができる。
（各データのフレームフォーマット）
　図１０は、ＭＡＣ＿ＰＤＵの一例を示す図である。受信ノード１００と送信ノード２００との間で送受信される音声データのＭＡＣレイヤのフレームフォーマットは、たとえば図１０に示すＭＡＣ＿ＰＤＵ１０００のようにする。ＭＡＣ＿ＰＤＵ１０００は、ＬＴＥシステムにおいてＰＤＣＰの下位レイヤに位置するＭＡＣフレームフォーマットである。
　ＭＡＣ＿ＰＤＵ１０００には、ＭＡＣ＿Ｈｅａｄｅｒ１０１０と、ＭＡＣ＿Ｐａｙｌｏａｄ１０２０と、が含まれている。ＭＡＣ＿Ｐａｙｌｏａｄ１０２０には、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１（図１１参照）と、ＭＡＣ＿ＳＤＵ１０２２と、Ｐａｄｄｉｎｇ１０２３と、が含まれている。
　図１１は、図１０に示したＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔを示す図である。図１１に示すテーブル１１００は、図１０に示したＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１の各種別を示している。
　送信ノード２００から受信ノード１００へ送信される音声データ（ｅＮＢ→ＵＥ）の場合は、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１の種別には、「ＵＥ　Ｃｏｎｔｅｎｔｉｏｎ　Ｒｅｓｏｌｕｔｉｏｎ　Ｉｄｅｎｔｉｔｙ」と、「Ｔｉｍｉｎｇ　Ａｄｖａｎｃｅ」と、「ＤＲＸ　Ｃｏｍｍａｎｄ」と、が含まれている。
　また、受信ノード１００から送信ノード２００へ送信される音声データ（ＵＥ→ｅＮＢ）の場合は、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１の種別には、「Ｐｏｗｅｒ　Ｈｅａｄｒｏｏｍ　Ｒｅｐｏｒｔ」と、「Ｃ－ＲＮＴＩ」と、「Ｓｈｏｒｔ＿ＢＳＲ」と、「Ｌｏｎｇ＿ＢＳＲ」と、が含まれている。
　「Ｓｈｏｒｔ＿ＢＳＲ」および「Ｌｏｎｇ＿ＢＳＲ」は、バッファに滞留したデータ量を示している。したがって、送信ノード２００は、ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ１０２１に含まれる「Ｓｈｏｒｔ＿ＢＳＲ」または「Ｌｏｎｇ＿ＢＳＲ」によって送信バッファ２１１の滞留データ量を受信ノード１００へ通知することができる。
　図１２は、図１１に示したＳｈｏｒｔ＿ＢＳＲを示す図である。図１１に示した「Ｓｈｏｒｔ＿ＢＳＲ」のフレームフォーマットは、たとえばＳｈｏｒｔ＿ＢＳＲ１２００のようにする。Ｓｈｏｒｔ＿ＢＳＲ１２００には、ＬＣＧ＿ＩＤ１２１０（Ｌｏｇｉｃａｌ　Ｃｈａｎｎｅｌ　Ｇｒｏｕｐ）と、バッファサイズ１２２０と、が含まれている。
　ＬＣＧ＿ＩＤ１２１０は、各論理チャネルグループ（たとえば論理チャネルグループ＃１～＃４）を示すＩＤである。バッファサイズ１２２０は、ＬＣＧ＿ＩＤ１２１０が示す各論理チャネルグループの全滞留データ量を示している。バッファサイズ１２２０の具体例については後述する（図１４参照）。
　図１３は、図１１に示したＬｏｎｇ＿ＢＳＲを示す図である。図１１に示した「Ｌｏｎｇ＿ＢＳＲ」のフレームフォーマットは、たとえばＬｏｎｇ＿ＢＳＲ１３００のようにする。Ｌｏｎｇ＿ＢＳＲ１３００には、各バッファサイズ＃１～＃４が含まれている。各バッファサイズ＃１～＃４は、各ＵＥに対する全滞留データ量を示している。各バッファサイズ＃１～＃４の具体例については後述する（図１４参照）。
　図１４は、バッファサイズのインデクスを示す図である。図１２に示したバッファサイズ１２２０または図１３に示した各バッファサイズ＃１～＃４は、たとえば図１４に示すテーブル１４００に基づくインデクスによって示される。たとえば、バッファサイズ（ＢＳ）０［Ｂｙｔｅｓ］は、インデクス「０」によって示される。
　また、０［Ｂｙｔｅｓ］より大きく１０［Ｂｙｔｅｓ］以下のバッファサイズはインデクス「１」によって示される。また、１０［Ｂｙｔｅｓ］より大きく１２［Ｂｙｔｅｓ］以下のバッファサイズはインデクス「２」によって示される。このように、上述したデータ量情報を示すバッファサイズをインデクスによって示すことで、データ量情報のサイズを小さくすることができる。
　図１５は、データＰＤＵのフォーマットの一例を示す図である。受信ノード１００と送信ノード２００との間で送受信されるデータＰＤＵのＰＤＣＰのヘッダのフレームフォーマットは、たとえば図１５に示すＰＤＣＰフレーム１５００のようにする。ＰＤＣＰフレーム１５００には、Ｄ／Ｃ１５１０と、Ｒ１５２０（Ｒｅｓｅｒｖｅｄ）と、ＰＤＣＰシーケンスナンバ１５３０と、データ１５４０と、が含まれている。
　Ｄ／Ｃ１５１０は、ＰＤＣＰフレーム１５００がデータＰＤＵおよびコントロールＰＤＵのいずれであるかを示す値である。ＰＤＣＰフレーム１５００においては、Ｄ／Ｃ１５１０は、データＰＤＵを示す「１」となる。Ｒ１５２０はここでは使用しない。ＰＤＣＰシーケンスナンバ１５３０は、ＰＤＣＰフレーム１５００のシーケンスナンバである。データ１５４０は、たとえば上述したＡＭＲデータ９１１やＳＩＤデータ９１２である。
　図１６は、コントロールＰＤＵのフォーマットの一例を示す図である。図１６において、図１５に示した部分と同様の部分については同一の符号を付して説明を省略する。受信ノード１００と送信ノード２００との間で送受信されるコントロールＰＤＵのＰＤＣＰのヘッダは、たとえば図１６に示すＰＤＣＰフレーム１６００のようにする。
　ＰＤＣＰフレーム１６００には、Ｄ／Ｃ１５１０と、ＰＤＵタイプ１６１０と、Ｒ１５２０と、Ｉｎｔｅｒｓｐｅｒｓｅｄ＿ＲＯＨＣ＿ｆｅｅｄｂａｃｋ＿ｐａｃｋｅｔ１６２０と、が含まれている。ＰＤＣＰフレーム１６００においては、Ｄ／Ｃ１５１０は、コントロールＰＤＵを示す「０」となる。ＰＤＵタイプ１６１０は、コントロールＰＤＵの種別（ＰＤＣＰステータスレポートやヘッダ圧縮フィードバック情報）を示している。
（受信ノードの動作）
　図１７は、図１に示した受信ノードの動作の一例を示すフローチャートである。図１に示した受信ノード１００は、図１７に示す各ステップを行う。まず、受信ノード１００の通話状態判定部１３４が、受信ノード１００が送信ノード２００から受信する音声データの通話状態（「有音」または「無音」）を判定する（ステップＳ１７０１）。
　つぎに、通話状態判定部１３４が、ステップＳ１７０１によって判定された通話状態が、通話状態判定部１３４によって前回判定された通話状態から変化したか否かを判断する（ステップＳ１７０２）。通話状態が変化していない場合（ステップＳ１７０２：Ｎｏ）は、ステップＳ１７０１へ戻って処理を続行する。
　ステップＳ１７０２において、通話状態が変化した場合（ステップＳ１７０２：Ｙｅｓ）は、ＲＯＨＣ制御部１３５が、ステップＳ１７０１によって判定された通話状態に応じてＲＯＨＣの動作モードを切り替え（ステップＳ１７０３）、一連の動作を終了する。ステップＳ１７０３において、通話状態が「無音」である場合は、ＲＯＨＣ制御部１３５は、たとえばＲＯＨＣの動作モードをヘッダ圧縮の頻度が高いＵ－ｍｏｄｅに切り替える。
　ステップＳ１７０３において、通話状態が「有音」である場合は、ＲＯＨＣ制御部１３５は、たとえばＲＯＨＣの動作モードをヘッダ圧縮の頻度が低いＯ－ｍｏｄｅやＲ－ｍｏｄｅに切り替える。これにより、通話状態が「有音」のときは音質の向上を図り、通話状態が「無音」のときはヘッダ圧縮の効率化を図ることができる。
　図１８は、図１７に示したステップＳ１７０１の具体例を示すフローチャートである。図１７に示したステップＳ１７０１において、通話状態判定部１３４は、たとえば以下の各ステップを実行する。まず、この動作を開始してからの経過時間が監視周期（たとえば２０［ｍｓｅｃ］）以上になったか否かを判断し（ステップＳ１８０１）、経過時間が監視周期以上になるまで待つ（ステップＳ１８０１：Ｎｏのループ）。
　ステップＳ１８０１において、経過時間が監視周期以上になると（ステップＳ１８０１：Ｙｅｓ）、受信バッファ１３１の滞留データ量を測定する（ステップＳ１８０２）。つぎに、通話状態判定部１３４による前回の判定によりメモリに記憶されている通話状態が「有音」であるか否かを判断する（ステップＳ１８０３）。
　ステップＳ１８０３において、通話状態が「有音」である場合（ステップＳ１８０３：Ｙｅｓ）は、ステップＳ１８０２によって測定された滞留データ量が閾値以下か否かを判断する（ステップＳ１８０４）。滞留データ量が閾値以下でない場合（ステップＳ１８０４：Ｎｏ）は、一連の処理を終了する。
　ステップＳ１８０４において、ステップＳ１８０２によって測定された滞留データ量が閾値以下である場合（ステップＳ１８０４：Ｙｅｓ）は、メモリに記憶されている通話状態を「無音」に更新し（ステップＳ１８０５）、一連の処理を終了する。
　ステップＳ１８０３において、通話状態が「有音」でない場合（ステップＳ１８０３：Ｎｏ）は、ステップＳ１８０２によって測定された滞留データ量が閾値より大きいか否かを判断する（ステップＳ１８０６）。滞留データ量が閾値より大きくない場合（ステップＳ１８０６：Ｎｏ）は、一連の処理を終了する。
　ステップＳ１８０６において、ステップＳ１８０２によって測定された滞留データ量が閾値より大きい場合（ステップＳ１８０６：Ｙｅｓ）は、メモリに記憶されている通話状態を「有音」に更新し（ステップＳ１８０７）、一連の処理を終了する。ステップＳ１８０４およびステップＳ１８０６において比較に用いる閾値は、たとえば図９に示したＳＩＤデータ９１２のサイズに相当する閾値である。
（ＲＯＨＣの動作モード切替）
　図１９は、ＲＯＨＣの動作モード切替の一例を示す図である。図１９において、横軸は時間を示している。符号１９１０は、送信ノード２００から受信ノード１００へ送信される音声データを示している。ＡＭＲデータ１９１１は、音声を伝送するとき（有音）に送信される。ＳＩＤデータ１９１２は、伝送する音声がないとき（無音）に送信される。
　区間１９２１～１９２４は、時間的に連続する時間区間である。区間１９２１および区間１９２３は、通話状態が「有音」となっており、ＡＭＲデータ１９１１が送信されている。区間１９２２および区間１９２４は、通話状態が「無音」となっており、ＳＩＤデータ１９１２が送信されている。
　符号１９３０は、受信ノード１００によるＲＯＨＣの動作モードの切替を示している。符号１９３０に示すように、受信ノード１００は、区間１９２１および区間１９２３においては通話状態を「有音」と判定する。そして、受信ノード１００は、区間１９２１および区間１９２３においてはＲＯＨＣの動作モードをＲ－ｍｏｄｅ（たとえばＯ－ｍｏｄｅでもよい）に切り替える。また、受信ノード１００は、区間１９２２および区間１９２４においては通話状態を「無音」と判定する。そして、受信ノード１００は、区間１９２２および区間１９２４においてはＲＯＨＣの動作モードをＵ－ｍｏｄｅに切り替える。
　これにより、通話状態が「無音」である区間１９２２および区間１９２４においては、ＲＯＨＣの動作モードをヘッダ圧縮の頻度が高いＵ－ｍｏｄｅにし、無線帯域の利用効率を向上させることができる。一方、通話状態が「有音」である区間１９２１および区間１９２３においては、ＲＯＨＣの動作モードをヘッダ圧縮の頻度が低いＲ－ｍｏｄｅにすることで、音声品質を向上させることができる。
　このように、実施の形態１にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
　また、受信バッファ１３１の滞留データ量を測定し、測定した滞留データ量に基づいて通話状態を判定することができる。たとえば、測定した滞留データ量を閾値と比較することによって通話状態（「有音」または「無音」）を容易に判定することができる。
（実施の形態２）
　実施の形態２においては、ＬＴＥシステムにおいて送信ノード２００が受信ノード１００へ送信するＢＳＲを用いて通話状態の判定を行う。上述したように、送信ノード２００が受信ノード１００へ送信するＭＡＣ＿ＰＤＵ（図１０参照）のＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔには、送信ノード２００の送信バッファ２１１の滞留データ量を示すＢＳＲ（図１１～図１３参照）が含まれている。
（受信ノードの構成例）
　図２０は、実施の形態２にかかる受信ノードの構成例を示すブロック図である。図２０において、図１に示した構成と同様の構成については同一の符号を付して説明を省略する。図２０に示すように、実施の形態２にかかる受信ノード１００のＭＡＣレイヤ終端部１１０は、受信処理部２０１１と、ＭＣＥ終端部２０１２と、送信処理部２０１３と、を備えている。受信処理部２０１１は、ＭＡＣレイヤにおける受信処理を行う。
　受信処理部２０１１は、受信処理を行った各データをＲＬＣレイヤ終端部１２０およびＭＣＥ終端部２０１２へ出力する。ＭＣＥ終端部２０１２は、ＭＣＥ（ＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔ）を終端する。たとえば、ＭＣＥ終端部２０１２は、受信処理部２０１１から出力されたデータに含まれるＢＳＲ（図１１～図１３参照）を取得する。
　ＢＳＲは、送信ノード２００における送信バッファ２１１の滞留データ量を示している。ＭＣＥ終端部２０１２は、取得したＢＳＲを滞留データ量としてＰＤＣＰ終端部１３０へ出力する。送信処理部２０１３は、ＭＡＣレイヤにおける送信処理を行う。送信処理部２０１３は、送信処理を行った各データを送信ノード２００へ送信する。
　ＰＤＣＰ終端部１３０の通話状態判定部１３４は、ＭＣＥ終端部２０１２から出力された滞留データ量に基づいて通話状態を判定する。具体的には、通話状態判定部１３４は、ＭＣＥ終端部２０１２から出力された滞留データ量が閾値より大きい場合は通話状態を「有音」と判定する。また、通話状態判定部１３４は、ＭＣＥ終端部２０１２から出力された滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。
（送信ノードの構成例）
　図２１は、実施の形態２にかかる送信ノードの動作の一例を示すフローチャートである。図２０に示した受信ノード１００の基本的な動作については、図１７に示した動作と同様である。また、図２０に示した受信ノード１００の通話状態判定部１３４は、図１７に示したステップＳ１７０１において、以下の各ステップを行う。
　まず、この動作を開始してからの経過時間が監視周期以上になったか否かを判断し（ステップＳ２１０１）、経過時間が監視周期以上になるまで待つ（ステップＳ２１０１：Ｎｏのループ）。経過時間が監視周期以上になると（ステップＳ２１０１：Ｙｅｓ）、送信ノード２００から送信されたデータ量情報（ＢＳＲ）を、ＭＣＥ終端部２０１２を介して受信する（ステップＳ２１０２）。ステップＳ２１０２において受信されるデータ量情報は、送信ノード２００の送信バッファ２１１の滞留データ量を示している。
　つぎに、前回の判定によりメモリに記憶されている通話状態が「有音」であるか否かを判断する（ステップＳ２１０３）。通話状態が「有音」である場合（ステップＳ２１０３：Ｙｅｓ）は、ステップＳ２１０２によって受信されたデータ量情報が示す滞留データ量が閾値以下か否かを判断する（ステップＳ２１０４）。滞留データ量が閾値以下でない場合（ステップＳ２１０４：Ｎｏ）は、一連の処理を終了する。
　ステップＳ２１０４において、受信されたデータ量情報が示す滞留データ量が閾値以下である場合（ステップＳ２１０４：Ｙｅｓ）は、メモリに記憶されている通話状態を「無音」に更新し（ステップＳ２１０５）、一連の処理を終了する。
　ステップＳ２１０３において、通話状態が「有音」でない場合（ステップＳ２１０３：Ｎｏ）は、ステップＳ２１０２によって受信されたデータ量情報が示す滞留データ量が閾値より大きいか否かを判断する（ステップＳ２１０６）。滞留データ量が閾値より大きくない場合（ステップＳ２１０６：Ｎｏ）は、一連の処理を終了する。
　ステップＳ２１０６において、受信されたデータ量情報が示す滞留データ量が閾値より大きい場合（ステップＳ２１０６：Ｙｅｓ）は、メモリに記憶されている通話状態を「有音」に更新し（ステップＳ２１０７）、一連の処理を終了する。なお、図１４に示したようにＢＳＲのバッファサイズがインデクス化されている場合は、ステップＳ２１０４およびステップＳ２１０６において比較に用いる閾値も図１４に示したインデクスを用いる。
　このように、実施の形態２にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
　また、送信ノード２００において送信バッファ２１１の滞留データ量を測定し、測定した滞留データ量を示すデータ量情報を受信ノード１００へ送信する。これにより、受信ノード１００は、送信ノード２００から受信したデータ量情報が示す滞留データ量に基づいて通話状態を判定することができる。送信ノード２００側のデータ滞留量を用いることにより、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。
　また、送信ノード２００が受信ノード１００へ送信するＭＡＣ＿ＰＤＵ（図１０参照）のＭＡＣ＿Ｃｏｎｔｒｏｌ＿Ｅｌｅｍｅｎｔに含まれるＢＳＲを用いてデータ量情報を送信する。これにより、送信ノード２００から受信ノード１００へ送信する制御信号を新たに追加しなくても、データ量情報を受信ノード１００へ送信することができる。
（実施の形態３）
（受信ノードの構成例）
　図２２は、実施の形態３にかかる受信ノードの構成例を示すブロック図である。図２２において、図１に示した構成と同様の構成については同一の符号を付して説明を省略する。実施の形態３にかかる受信ノード１００においては、図１に示した通話状態判定部１３４を省いた構成にしてもよい。
　受信処理部１３２は、受信バッファ１３１から読み出したデータのうちの、送信ノード２００から送信された通話状態情報をＲＯＨＣ制御部１３５へ出力する。ＲＯＨＣ制御部１３５は、受信処理部１３２から出力された通話状態情報が示す通話状態の判定結果（「有音」または「無音」）に応じてＲＯＨＣの動作モードを切り替える。
（送信ノードの構成例）
　図２３は、実施の形態３にかかる送信ノードの構成例を示すブロック図である。図２３において、図２に示した構成と同様の構成については同一の符号を付して説明を省略する。図２３に示すように、実施の形態３にかかる送信ノード２００のＰＤＣＰ終端部２１０は、図２に示した構成に加えて通話状態判定部２３１０を備えている。
　通話状態判定部２３１０は、送信ノード２００から受信ノード１００へ送信する音声データの通話状態を判定し、判定結果を示す通話状態情報を送信処理部２１３へ出力する。通話状態判定部２３１０が判定する通話状態は、たとえば、音声データが示す音声が「有音」であるか「無音」であるかに関する状態である。通話状態判定部２３１０は、たとえば、送信バッファ２１１の滞留データ量に基づいて通話状態を判定する。
　具体的には、通話状態判定部２３１０は、送信バッファ２１１の滞留データ量が閾値より大きい場合は通話状態を「有音」と判定し、送信バッファ２１１の滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。音声データの量と比較する閾値は、たとえば、通話状態が「無音」であり、送信ノード２００がＳＩＤデータを送信するときに送信バッファ２１１に滞留するＳＩＤデータの量に相当する値である。
　送信処理部２１３は、通話状態判定部２３１０から出力された通話状態情報を、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００へ送信する。これにより、受信ノード１００へ通話状態情報を送信することができる。通話状態情報を送信するためのＰＤＣＰフレームについて、図２４によって説明する。
（データのフレームフォーマット）
　図２４は、ＰＤＣＰフレームのフォーマットの一例を示す図である。図２４において、図１６に示した部分と同様の部分については同一の符号を付して説明を省略する。送信処理部２１３が受信ノード１００へ送信するコントロールＰＤＵのＰＤＣＰのヘッダのフレームフォーマットは、たとえば図２４に示すＰＤＣＰフレーム２４００のようにする。
　ＰＤＣＰフレーム２４００には、Ｄ／Ｃ１５１０と、ＰＤＵタイプ１６１０と、Ｒ１５２０と、ＴＳＦ２４１０（Ｔｅｌｅｐｈｏｎｅ　ｃａｌｌ　Ｓｔａｔｕｓ　Ｆｌａｇ）と、が含まれている。ＰＤＣＰフレーム２４００において、Ｄ／Ｃ１５１０は、コントロールＰＤＵを示す「０」となる。
　ＴＳＦ２４１０は、送信ノード２００から受信ノード１００へ送信する音声データの通話状態を示している。送信処理部２１３は、通話状態判定部２３１０から出力された通話状態情報を、ＰＤＣＰフレーム２４００のＴＳＦ２４１０に格納する。受信ノード１００の受信処理部１３２は、送信ノード２００から受信したＰＤＣＰフレーム２４００のＴＳＦ２４１０を通話状態情報としてＲＯＨＣ制御部１３５へ出力する。
（送信ノードの動作）
　図２５は、図２３に示した送信ノードの動作の一例を示すフローチャートである。図２３に示した送信ノード２００は、図２５に示す各ステップを行う。まず、送信ノード２００の通話状態判定部２３１０が、送信ノード２００から受信ノード１００へ送信する音声データの通話状態を判定する（ステップＳ２５０１）。
　つぎに、通話状態判定部２３１０が、ステップＳ２５０１によって判定された通話状態が、通話状態判定部２３１０によって前回判定された通話状態から変化したか否かを判断する（ステップＳ２５０２）。通話状態が変化していない場合（ステップＳ２５０２：Ｎｏ）は、ステップＳ２５０１へ戻って処理を続行する。
　ステップＳ２５０２において、通話状態が変化した場合（ステップＳ２５０２：Ｙｅｓ）は、送信処理部２１３が、ステップＳ２５０１によって判定された通話状態を示す通話状態情報を受信ノード１００へ送信し（ステップＳ２５０３）、一連の処理を終了する。ステップＳ２５０３によって送信された通話状態情報は受信ノード１００によって受信される。受信ノード１００は、受信した通話状態情報が示す通話状態に応じて送信ノード２００との間のＲＯＨＣの動作モードを切り替える。
　図２６は、図２５に示したステップＳ２５０１の具体例を示すフローチャートである。図２５に示したステップＳ２５０１において、通話状態判定部２３１０は、たとえば以下の各ステップを実行する。まず、この動作を開始してからの経過時間が監視周期以上になったか否かを判断し（ステップＳ２６０１）、経過時間が監視周期以上になるまで待つ（ステップＳ２６０１：Ｎｏのループ）。
　ステップＳ２６０１において、経過時間が監視周期以上になると（ステップＳ２６０１：Ｙｅｓ）、送信バッファ２１１の滞留データ量を測定する（ステップＳ２６０２）。図２６に示すステップＳ２６０３～Ｓ２６０７は、図１８に示したステップＳ１８０３～Ｓ１８０７と同様であるため説明を省略する。
　このように、実施の形態３にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
　また、送信ノード２００において通話状態を判定し、判定結果を示す通話状態情報を受信ノード１００へ送信する。これにより、受信ノード１００は、送信ノード２００から受信した通話状態情報が示す通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。通話状態を送信ノード２００側で判定することにより、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。
　また、通話状態を送信ノード２００側で判定することにより、受信ノード１００側の処理負担を軽減することができる。また、送信ノード２００が受信ノード１００へ送信するＰＤＣＰフレーム２４００にＴＳＦ２４１０を設け、ＴＳＦ２４１０を用いて通話状態情報を送信することにより、通話状態情報を受信ノード１００へ送信することができる。
（実施の形態４）
（受信ノードの構成例）
　図２７は、実施の形態４にかかる受信ノードの構成例を示すブロック図である。図２７において、図１に示した構成と同様の構成については同一の符号を付して説明を省略する。実施の形態４にかかる受信ノード１００の受信処理部１３２は、受信処理したデータのうちのデータ量情報を通話状態判定部１３４へ出力する。
　通話状態判定部１３４へ出力されるデータ量情報は、送信ノード２００における送信バッファ２１１の滞留データ量を示している。通話状態判定部１３４は、受信処理部１３２から出力されたデータ量情報が示す滞留データ量に基づいて通話状態を判定する。具体的には、通話状態判定部１３４は、滞留データ量が閾値より大きい場合は通話状態を「有音」と判定し、滞留データ量が閾値以下である場合は通話状態を「無音」と判定する。
（送信ノードの構成例）
　図２８は、実施の形態４にかかる送信ノードの構成例を示すブロック図である。図２８において、図２に示した構成と同様の構成については同一の符号を付して説明を省略する。図２８に示すように、実施の形態３にかかる送信ノード２００のＰＤＣＰ終端部２１０は、図２に示した構成に加えて滞留データ量測定部２８１０を備えている。
　滞留データ量測定部２８１０は、送信バッファ２１１の滞留データ量を測定し、測定した滞留データ量を示すデータ量情報を送信処理部２１３へ出力する。送信処理部２１３は、滞留データ量測定部２８１０から出力されたデータ量情報を、ＲＬＣレイヤ終端部２２０およびＭＡＣレイヤ終端部２３０を介して受信ノード１００へ送信する。これにより、受信ノード１００へデータ量情報を送信することができる。データ量情報を送信するためのＰＤＣＰフレームについて、図２９において説明する。
（データのフレームフォーマット）
　図２９は、ＰＤＣＰフレームのフォーマットの一例を示す図である。図２９において、図１６に示した部分と同様の部分については同一の符号を付して説明を省略する。送信ノード２００の送信処理部２１３が送信するコントロールＰＤＵのＰＤＣＰのヘッダのフレームフォーマットは、たとえば図２９に示すＰＤＣＰフレーム２９００のようにする。
　ＰＤＣＰフレーム２９００には、Ｄ／Ｃ１５１０と、ＰＤＵタイプ１６１０と、ＢＳＲ２９１０と、が含まれている。ＰＤＣＰフレーム２９００においては、Ｄ／Ｃ１５１０は、コントロールＰＤＵを示す「０」となる。
　ＢＳＲ２９１０は、送信ノード２００の送信バッファ２１１の滞留データ量を示している。送信処理部２１３は、滞留データ量測定部２８１０から出力されたデータ量情報を、ＰＤＣＰフレーム２９００のＢＳＲ２９１０に格納して受信ノード１００へ送信する。受信ノード１００の受信処理部１３２は、送信ノード２００から受信したＰＤＣＰフレーム２９００のＢＳＲ２９１０を滞留データ量として通話状態判定部１３４へ出力する。
　このように、実施の形態４にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。
　また、送信ノード２００において送信バッファ２１１の滞留データ量を測定し、測定した滞留データ量を示すデータ量情報を受信ノード１００へ送信する。これにより、受信ノード１００は、送信ノード２００から受信したデータ量情報が示す滞留データ量に基づいて通話状態を判定することができる。送信ノード２００側のデータ滞留量を用いることにより、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。
　また、送信ノード２００が受信ノード１００へ送信するＰＤＣＰフレーム２９００にＢＳＲ２９１０を設け、ＢＳＲ２９１０を用いてデータ量情報を送信することにより、滞留データ量を送信ノード２００から受信ノード１００へ送信することができる。
（実施の形態５）
　実施の形態５にかかる受信ノード１００の通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定する。また、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定する。受信ノード１００および送信ノード２００の構成は、たとえば図１および図２に示した構成と同様である。
（受信ノードの動作）
　図３０は、実施の形態５にかかる受信ノードの動作の一例を示すフローチャートである。実施の形態５にかかる受信ノード１００の基本的な動作については、図１７に示した動作と同様である。また、実施の形態５にかかる受信ノード１００の通話状態判定部１３４は、図１７に示したステップＳ１７０１において、以下の各ステップを行う。
　まず、カウンタｋを０に設定する（ステップＳ３００１）。つぎに、この動作を開始してからの経過時間が監視周期以上になったか否かを判断し（ステップＳ３００２）、経過時間が監視周期以上になるまで待つ（ステップＳ３００２：Ｎｏのループ）。
　ステップＳ３００２において、経過時間が監視周期以上になると（ステップＳ３００２：Ｙｅｓ）、受信バッファ１３１の滞留データ量を測定する（ステップＳ３００３）。つぎに、前回の判定によりメモリに記憶されている通話状態が「有音」であるか否かを判断する（ステップＳ３００４）。
　ステップＳ３００４において、通話状態が「有音」である場合（ステップＳ３００４：Ｙｅｓ）は、ステップＳ３００３によって測定された滞留データ量が閾値以下か否かを判断する（ステップＳ３００５）。滞留データ量が閾値以下でない場合（ステップＳ３００５：Ｎｏ）は、ステップＳ３００９へ移行して処理を続行する。
　ステップＳ３００５において、ステップＳ３００３によって測定された滞留データ量が閾値以下である場合（ステップＳ３００５：Ｙｅｓ）は、カウンタｋをインクリメント（ｋ＝ｋ＋１）する（ステップＳ３００６）。つぎに、カウンタｋが保護段数より大きいか否かを判断する（ステップＳ３００７）。
　ステップＳ３００７において、カウンタｋが保護段数より大きくない場合（ステップＳ３００７：Ｎｏ）は、ステップＳ３００２へ戻って処理を続行する。カウンタｋが保護段数より大きい場合（ステップＳ３００７：Ｙｅｓ）は、メモリに記憶されている通話状態を「無音」に更新する（ステップＳ３００８）。つぎに、カウンタｋを０に設定し（ステップＳ３００９）、一連の処理を終了する。
　ステップＳ３００４において、通話状態が「有音」でない場合（ステップＳ３００４：Ｎｏ）は、ステップＳ３００３によって測定された滞留データ量が閾値より大きいか否かを判断する（ステップＳ３０１０）。滞留データ量が閾値より大きくない場合（ステップＳ３０１０：Ｎｏ）は、ステップＳ３０１４へ進んで処理を続行する。
　ステップＳ３０１０において、ステップＳ３００３によって測定された滞留データ量が閾値より大きい場合（ステップＳ３０１０：Ｙｅｓ）は、カウンタｋをインクリメント（ｋ＝ｋ＋１）する（ステップＳ３０１１）。つぎに、カウンタｋが保護段数より大きいか否かを判断する（ステップＳ３０１２）。
　ステップＳ３０１２において、カウンタｋが保護段数より大きくない場合（ステップＳ３０１２：Ｎｏ）は、ステップＳ３００２へ戻って処理を続行する。カウンタｋが保護段数より大きい場合（ステップＳ３０１２：Ｙｅｓ）は、メモリに記憶されている通話状態を「有音」に更新する（ステップＳ３０１３）。つぎに、カウンタｋを０に設定し（ステップＳ３０１４）、一連の処理を終了する。
　このように、通話状態判定部１３４は、ステップＳ３００５において滞留データ量が閾値以下であっても、カウンタｋの値が保護段数を超えていない場合は無視する。これにより、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定することができる。
　また、通話状態判定部１３４は、ステップＳ３０１０において滞留データ量が閾値より大きくても、カウンタｋの値が保護段数を超えていない場合は無視する。これにより、通話状態判定部１３４は、受信バッファ１３１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定することができる。
　図３１は、図３０に示した動作による通話状態判定の具体例を示す図である。図３１において、図１９に示した部分と同様の部分については同一の符号を付して説明を省略する。図３１において、横軸は時間を示している。符号３１１０は、送信ノード２００から受信ノード１００へ送信される音声データを示している。
　ここでは、通話状態の初期値を「無音」とし、監視周期を２０［ｍｓ］とし、閾値（ＳＩＤデータ１９１２のサイズ相当）を１０［ｂｙｔｅ］とし、保護段数を３とする。受信ノード１００は、監視周期２０［ｍｓ］で受信バッファ１３１の滞留データ量を取得し、滞留データ量が閾値１０［ｂｙｔｅ］を超えるとカウンタｋをインクリメントする。監視周期Ｔ１～Ｔ２３は、受信ノード１００における監視周期（２０［ｍｓ］）である。
　監視周期Ｔ１～Ｔ６において、受信ノード１００は、ＡＭＲデータ１９１１（サイズ３０［ｂｙｔｅ］）を連続して６回、２０［ｍｓ］周期で正常に受信したとする。受信ノード１００は、監視周期Ｔ１～Ｔ３においては、メモリに記憶された通話状態が「無音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］より大きいため、カウンタｋをインクリメントする（ｋ＝１，２，３）。
　監視周期Ｔ１～Ｔ３において、受信ノード１００は、カウンタｋが保護段数３以下であるため、受信ノード１００は、通話状態を「無音」のままであると判定する。このため、監視周期Ｔ１～Ｔ３においては通話状態が「無音」と判定される。
　監視周期Ｔ４において、受信ノード１００は、通話状態が「無音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］を超えているため、カウンタｋをインクリメントする（ｋ＝４）。受信ノード１００は、監視周期Ｔ４においてはカウンタｋが保護段数３を超えるため、受信ノード１００は、通話状態が「有音」に変化したと判定する。また、カウンタｋは初期化されて０になる（ｋ＝０）。
　監視周期Ｔ５～Ｔ６において、受信ノード１００は、メモリに記憶された通話状態が「有音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下でないため、カウンタｋをインクリメントしない（ｋ＝０）。
　監視周期Ｔ７において、受信ノード１００は、ＡＭＲデータ１９１１を正常に受信できなかったとする。受信ノード１００は、監視周期Ｔ７においてはメモリに記憶された通話状態が「有音」であり、滞留データ量が０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントする（ｋ＝１）。受信ノード１００は、監視周期Ｔ７においてはカウンタｋが保護段数３を超えていない（ｋ＝１）ため、受信ノード１００は、通話状態が「有音」のままであると判定する。
　監視周期Ｔ８～Ｔ１１において、受信ノード１００は、ＡＭＲデータ１９１１を連続して４回、正常に受信したとする。受信ノード１００は、監視周期Ｔ８～Ｔ１１においてはメモリに記憶された通話状態が「有音」であり、滞留データ量が３０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下でないため、カウンタｋをインクリメントしない（ｋ＝０）。
　監視周期Ｔ１２以降、送信ノード２００から受信ノード１００へ送信する音声データの実際の通話状態が「無音」となったとする。監視周期Ｔ１２，Ｔ１６，Ｔ２０のそれぞれにおいて、受信ノード１００は、ＳＩＤデータ１９１２（サイズ１０［ｂｙｔｅ］）を正常に受信したとする。
　監視周期Ｔ１２～Ｔ１５において、受信ノード１００は、メモリに記憶された通話状態が「有音」であり滞留データ量が１０または０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントする（ｋ＝１，２，３）。受信ノード１００は、監視周期Ｔ１２～Ｔ１５の間の期間においてはカウンタｋが保護段数３以下であるため、受信ノード１００は、通話状態を「有音」のままであると判定する。
　監視周期Ｔ１６において、受信ノード１００は、通話状態が「有音」であり、滞留データ量が１０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントする（ｋ＝４）。受信ノード１００は、監視周期Ｔ１６においてはカウンタｋが保護段数３を超えるため、受信ノード１００は、通話状態が「無音」に変化したと判定する。また、カウンタｋは初期化されて０になる（ｋ＝０）。
　監視周期Ｔ１７～Ｔ２３において、受信ノード１００は、メモリに記憶された通話状態が「無音」であり、滞留データ量が１０［ｂｙｔｅ］または０［ｂｙｔｅ］で閾値１０［ｂｙｔｅ］以下であるため、カウンタｋをインクリメントしない（ｋ＝０）。
　このように、通話状態判定部１３４は、時期Ｔ７において滞留データ量が閾値以下であっても、カウンタｋの値が保護段数を超えていない場合は無視する。これにより、受信ノード１００がＡＭＲデータ１９１１を正常に受信できなかった場合に通話状態が「無音」になったと誤判定されることを回避することができる。
　このように、実施の形態５にかかる受信ノード１００（受信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
　また、受信バッファ１３１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定することで、瞬間的なトラヒックの増加によって通話状態が「有音」になったと誤判定することを回避することができる。
　また、受信バッファ１３１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定することで、フレーム欠落などによる瞬間的なトラヒックの減少によって通話状態が「有音」になったと誤判定することを回避することができる。
　実施の形態５においては、受信ノード１００および送信ノード２００の構成が図１および図２に示した構成（実施の形態１）と同様である場合について説明した。ただし、受信ノード１００および送信ノード２００の構成を、実施の形態２～４のいずれかと同様にしてもよい。一例として、受信ノード１００および送信ノード２００の構成を図２２および図２３に示した構成（実施の形態３）と同様にした場合について説明する。
　この場合は、送信ノード２００の通話状態判定部２３１０は、送信バッファ２１１の滞留データ量が所定期間以上において閾値より大きい場合に通話状態を「有音」と判定する。また、通話状態判定部２３１０は、送信バッファ２１１の滞留データ量が所定期間以上において閾値以下の場合に通話状態を「無音」と判定する。
（実施の形態６）
　実施の形態１～５においては、ＲＯＨＣ制御部１３５を受信ノード１００に設け、受信ノード１００によってＲＯＨＣの切替制御を行う構成について説明した。これに対して、実施の形態６は、ＲＯＨＣ制御部１３５に相当する機能を送信ノード２００に設け、送信ノード２００によってＲＯＨＣの切替制御を行う。
（受信ノードの構成例）
　図３２は、実施の形態６にかかる受信ノードの構成例を示すブロック図である。図３２において、図２２に示した構成と同様の構成については同一の符号を付して説明を省略する。実施の形態６にかかる受信ノード１００においては、図２２に示したＲＯＨＣ制御部１３５および送信処理部１３６を省いた構成にしてもよい。
（送信ノードの構成例）
　図３３は、実施の形態６にかかる送信ノードの構成例を示すブロック図である。図３３において、図２３に示した構成と同様の構成については同一の符号を付して説明を省略する。図３３に示すように、実施の形態６にかかる送信ノード２００のＰＤＣＰ終端部２１０は、図２３に示した構成に加えてＲＯＨＣ制御部３３１０を備えている。
　また、実施の形態６にかかる送信ノード２００においては、図２３に示した受信処理部２１４を省いた構成にしてもよい。通話状態判定部２３１０は、判定結果を示す通話状態情報をＲＯＨＣ制御部３３１０へ出力する。
　ＲＯＨＣ制御部３３１０は、（制御手段）は、通話状態判定部２３１０から出力された判定結果に応じて、受信ノード１００および送信ノード２００におけるＲＯＨＣの動作モードを切り替える。ＲＯＨＣ制御部３３１０は、ＲＯＨＣの動作モードを切り替えるために、切り替える動作モードを圧縮部２１２へ通知する。
　また、ＲＯＨＣ制御部３３１０は、切り替える動作モードを示す切替指示信号を生成する。そして、ＲＯＨＣ制御部３３１０は、生成した切替指示信号を送信処理部２１３へ出力する。これにより、切替指示信号が受信ノード１００へ送信され、ＲＯＨＣの動作モードが切り替わる。ＲＯＨＣ制御部３３１０によるＲＯＨＣの動作モードの切替については、上述したＲＯＨＣ制御部１３５による切替と同様であるため説明を省略する。
　図３３に示した圧縮部２１２は、ヘッダ圧縮を行った音声データを送信ノード２００のメモリ（不図示）に書き込む。圧縮部２１２は、たとえばＣＰＵなどの演算手段である。送信処理部２１３は、圧縮部２１２によって送信ノード２００のメモリに書き込まれた音声データを読み出し、読み出した音声データを送信する。
　通話状態判定部２３１０は、通話状態の判定結果を送信ノード２００のメモリ（不図示）に書き込む。通話状態判定部２３１０は、たとえばＣＰＵなどの演算手段である。ＲＯＨＣ制御部３３１０は、通話状態判定部２３１０によって送信ノード２００のメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じてＲＯＨＣの動作モードを切り替える。ＲＯＨＣ制御部３３１０は、たとえばＣＰＵなどの演算手段である。
　このように、実施の形態６にかかる送信ノード２００（送信装置）によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
　また、送信ノード２００において通話状態を判定し、判定結果に基づいてＲＯＨＣの動作モードを切り替えることで、無線区間の品質などにかかわらず精度よく通話状態を判定することができる。また、通話状態の判定およびＲＯＨＣの動作モードの切替を送信ノード２００側で行うことにより、受信ノード１００側の処理負担を軽減することができる。
（ＲＯＨＣの動作モード切替の具体例）
　図３４は、Ｕ－ｍｏｄｅからＯ－ｍｏｄｅへの切替の具体例を示す図である。図３４において、図５に示した部分と同様の部分については同一の符号を付して説明を省略する。Ｃ＿ＭＯＤＥ３４１０は、送信ノード２００の圧縮部２１２に設定されるＲＯＨＣの動作モードを示している。
　Ｃ＿ＭＯＤＥ３４１０は、「Ｕ－ｍｏｄｅ」、「Ｏ－ｍｏｄｅ」または「Ｒ－ｍｏｄｅ」の値をとる。Ｃ＿ＴＲＡＮＳ３４２０は、送信ノード２００の圧縮部２１２に設定される、ＲＯＨＣの動作モードの遷移経過状態である。Ｃ＿ＴＲＡＮＳ３４２０は、「Ｐｅｎｄｉｎｇ」または「Ｄｏｎｅ」の値をとる。
　Ｄ＿ＭＯＤＥ３４３０は、受信ノード１００の伸張部１３３に設定されるＲＯＨＣの動作モードである。Ｄ＿ＭＯＤＥ３４３０は、「Ｕ－ｍｏｄｅ」、「Ｏ－ｍｏｄｅ」または「Ｒ－ｍｏｄｅ」の値をとる。Ｄ＿ＴＲＡＮＳ３４４０は、受信ノード１００の伸張部１３３に設定される、ＲＯＨＣの動作モードの遷移経過状態である。Ｄ＿ＴＲＡＮＳ３４４０は、「Ｉｎｉｔｉａｔｅｄ」、「Ｐｅｎｄｉｎｇ」または「Ｄｏｎｅ」の値をとる。
　Ｕ－ｍｏｄｅからＯ－ｍｏｄｅへ切替は、受信ノード１００から送信ノード２００へのフィードバックチャネルが利用可能であれば任意のタイミングで行うことができる。たとえば、時期ｔ３４１１より前の期間においては、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＵ－ｍｏｄｅであったとする。
　そして、受信ノード１００は、ＲＯＨＣの動作モードをＯ－ｍｏｄｅへ切り替える旨の切替指示信号３４５０を時期ｔ３４１１において送信ノード２００へ送信する。送信ノード２００は、受信ノード１００から切替指示信号３４５０を受信すると、送信ノード２００におけるＲＯＨＣの動作モードをＯ－ｍｏｄｅに切り替える。
　具体的には、送信ノード２００は、周期的な非圧縮フレーム５１１の送信を停止し、受信ノード１００からＮａｃｋを受信するまでは圧縮フレーム５１２を送信する。Ｕ－ｍｏｄｅからＯ－ｍｏｄｅへの切替においては、受信ノード１００および送信ノード２００において任意のタイミングにおいて切替を行うことができるため、Ｃ＿ＴＲＡＮＳ３４２０およびＤ＿ＴＲＡＮＳ３４４０は「Ｄｏｎｅ」のまま切替を行うことができる。
　図３５は、Ｕ－ｍｏｄｅからＲ－ｍｏｄｅへの切替の具体例を示す図である。図３５において、図３４に示した部分と同様の部分については同一の符号を付して説明を省略する。Ｕ－ｍｏｄｅからＲ－ｍｏｄｅへ切替は、少なくとも１つの非圧縮フレーム５１１を正常に受信した後で行う。たとえば、時期ｔ３５１１より前の期間においては、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＵ－ｍｏｄｅであったとする。
　そして、受信ノード１００は、ＲＯＨＣの動作モードをＲ－ｍｏｄｅへ切り替える旨の切替指示信号３５２１を時期ｔ３５１１において送信ノード２００へ送信する。送信ノード２００は、受信ノード１００から切替指示信号３５２１を受信すると、動作モードをＲ－ｍｏｄｅに切り替え、非圧縮フレーム５１１を連続して受信ノード１００へ送信する。
　受信ノード１００は、送信ノード２００から送信された非圧縮フレーム５１１を受信すると、受信ノード１００におけるＲＯＨＣの動作モードをＲ－ｍｏｄｅに切り替える。受信ノード１００が切替指示信号３５２１を送信した時期ｔ３５１１から、送信ノード２００から送信された非圧縮フレーム５１１を受信ノード１００が受信した時期ｔ３５１２までの期間は、Ｄ＿ＴＲＡＮＳ３４４０は「Ｉｎｉｔｉａｔｅｄ」になる。
　また、受信ノード１００は、時期ｔ３５１２において送信ノード２００から送信された非圧縮フレーム５１１を正常に受信すると、送信ノード２００へＡｃｋ３５２２を送信する。送信ノード２００は、Ａｃｋ３５２２を受信すると、受信ノード１００からＮａｃｋを受信するまでは連続して圧縮フレーム５１２を受信ノード１００へ送信する。
　送信ノード２００がＲＯＨＣの動作モードをＲ－ｍｏｄｅに切り替えてから送信ノード２００がＡｃｋ３５２２を受信するまでの期間は、Ｃ＿ＴＲＡＮＳ３４２０は「Ｐｅｎｄｉｎｇ」になる。また、受信ノード１００がＡｃｋ３５２２を送信した時期ｔ３５１２から受信ノード１００が圧縮フレーム５１２を受信する時期ｔ３５１３までの期間のＤ＿ＴＲＡＮＳ３４４０は「Ｐｅｎｄｉｎｇ」になる。
　図３６は、Ｏ－ｍｏｄｅからＵ－ｍｏｄｅへの切替の具体例を示す図である。図３６において、図３４に示した部分と同様の部分については同一の符号を付して説明を省略する。Ｏ－ｍｏｄｅからＵ－ｍｏｄｅへ切替は、任意のタイミングで行うことができる。たとえば、時期ｔ３６１１より前の期間においては、受信ノード１００および送信ノード２００のＲＯＨＣの動作モードはＯ－ｍｏｄｅであったとする。
　そして、受信ノード１００は、ＲＯＨＣの動作モードをＵ－ｍｏｄｅへ切り替える旨の切替指示信号３６２１を時期ｔ３６１１において送信ノード２００へ送信する。送信ノード２００は、受信ノード１００から切替指示信号３６２１を受信すると、送信ノード２００におけるＲＯＨＣの動作モードをＵ－ｍｏｄｅに切り替える。
　具体的には、送信ノード２００は、周期的な非圧縮フレーム５１１の送信を開始する。また、送信ノード２００は、ＲＯＨＣの動作モードのＵ－ｍｏｄｅへの切替時に、非圧縮フレーム５１１を３回連続して送信し、これらの非圧縮フレーム５１１に対するＡｃｋを受信ノード１００から受信するようにしてもよい。これにより、動作モードの切替が正常に行われていることを確認することができる（Ｔｈｒｅｅ－ｗａｙハンドシェイク）。
　受信ノード１００は、切替指示信号３６２１を送信した後に送信ノード２００から非圧縮フレーム５１１を受信した時期ｔ３６１２において、ＲＯＨＣの動作モードをＵ－ｍｏｄｅに切り替える。受信ノード１００が切替指示信号３６２１を送信した時期ｔ３６１１から、受信ノード１００が送信ノード２００から圧縮フレーム５１２を受信する時期ｔ３６１３までの期間のＤ＿ＴＲＡＮＳ３４４０は「Ｉｎｉｔｉａｔｅｄ」になる。Ｒ－ｍｏｄｅからＵ－ｍｏｄｅへの切替は、Ｏ－ｍｏｄｅからＵ－ｍｏｄｅへの切替と同様であるため説明を省略する。
　以上説明したように、開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法によれば、通話状態を判定し、判定した通話状態に応じてＲＯＨＣの動作モードを切り替えることができる。これにより、通話状態が有音のときは音質の向上を図り、通話状態が無音のときはヘッダ圧縮の効率化を図ることができる。このため、音声データの音質および帯域利用効率の向上を図ることができる。
　なお、上述した各実施の形態においては、ＬＴＥシステムを例とする構成について説明したが、開示の受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法は、ＷｉＭＡＸなどの他の通信システムに対しても適用可能である。
　また、上述した各実施の形態においては、通話状態が「有音」の場合はＲＯＨＣの動作モードをＯ－ｍｏｄｅやＲ－ｍｏｄｅに切り替え、通話状態が「無音」の場合はＲＯＨＣの動作モードをＵ－ｍｏｄｅに切り替える構成について説明した。これに対して通話状態が「有音」の場合はＲＯＨＣの動作モードをＲ－ｍｏｄｅに切り替え、通話状態が「無音」の場合はＲＯＨＣの動作モードをＯ－ｍｏｄｅに切り替える構成にしてもよい。
　一般的に、Ｏ－ｍｏｄｅはＲ－ｍｏｄｅよりもヘッダ圧縮の頻度が高いため、ヘッダ圧縮の効率が優れている。このため、通話状態が「無音」の場合はＲＯＨＣの動作モードをＯ－ｍｏｄｅに切り替えることで、ヘッダ圧縮の効率化を図ることができる。その他、ヘッダ圧縮の動作モードについては、ＲＯＨＣのＵ－ｍｏｄｅ、Ｏ－ｍｏｄｅおよびＲ－ｍｏｄｅに限らず、ヘッダ圧縮の頻度が異なる種々の動作モードを用いることができる。

Claims (15)

  1. 　音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信装置において、
    　前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信手段と、
    　前記受信手段によって受信される音声データの通話状態を判定する判定手段と、
    　前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
    　を備えることを特徴とする受信装置。
  2. 　前記判定手段は、前記受信手段によって受信された音声データを格納する受信バッファの滞留データ量に基づいて前記通話状態を判定することを特徴とする請求項１に記載の受信装置。
  3. 　前記受信手段は、前記送信装置の送信バッファに格納されている前記音声データの量を示すデータ量情報を前記送信装置から受信し、
    　前記判定手段は、前記受信手段によって受信されたデータ量情報に基づいて前記通話状態を判定することを特徴とする請求項１に記載の受信装置。
  4. 　前記受信手段は、前記送信装置によって判定された前記通話状態を示す通話状態情報を前記送信装置から受信し、
    　前記制御手段は、前記受信手段によって受信された通話状態情報に応じて前記動作モードを切り替えることを特徴とする請求項１に記載の受信装置。
  5. 　前記判定手段は、前記受信バッファの滞留データ量が閾値より大きい場合は前記通話状態を有音と判定し、前記音声データの量が前記閾値以下の場合は前記通話状態を無音と判定することを特徴とする請求項２に記載の受信装置。
  6. 　前記制御手段は、前記判定手段によって有音と判定された場合は、前記複数の動作モードのうちの前記ヘッダ圧縮の頻度が低い動作モードへ切り替え、前記判定手段によって無音と判定された場合は、前記複数の動作モードのうちの前記ヘッダ圧縮の頻度が高い動作モードへ切り替えることを特徴とする請求項５に記載の受信装置。
  7. 　前記判定手段は、前記受信バッファの滞留データ量が所定期間以上において前記閾値より大きい場合に前記通話状態を有音と判定することを特徴とする請求項５に記載の受信装置。
  8. 　前記判定手段は、前記受信バッファの滞留データ量が所定期間以上において前記閾値以下の場合に前記通話状態を無音と判定することを特徴とする請求項５に記載の受信装置。
  9. 　前記判定手段は、前記判定結果をメモリに書き込む演算手段であり、
    　前記制御手段は、前記判定手段によってメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じて前記動作モードを切り替える演算手段であることを特徴とする請求項１に記載の受信装置。
  10. 　音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける送信装置において、
    　音声データのヘッダ圧縮を行う圧縮手段と、
    　前記圧縮手段によってヘッダ圧縮された音声データを送信する送信手段と、
    　前記送信手段によって送信される音声データの通話状態を判定する判定手段と、
    　前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
    　を備えることを特徴とする送信装置。
  11. 　前記圧縮手段は、ヘッダ圧縮を行った音声データをメモリに書き込む演算手段であり、
    　前記送信手段は、前記圧縮手段によってメモリに書き込まれた音声データを読み出し、読み出した音声データを送信し、
    　前記判定手段は、前記判定結果をメモリに書き込む演算手段であり、
    　前記制御手段は、前記判定手段によってメモリに書き込まれた判定結果を読み出し、読み出した判定結果に応じて前記動作モードを切り替える演算手段であることを特徴とする請求項１０に記載の送信装置。
  12. 　音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける受信方法において、
    　前記ヘッダ圧縮を行う送信装置から送信される音声データを受信する受信工程と、
    　前記受信工程によって受信される音声データの通話状態を判定する判定工程と、
    　前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
    　を含むことを特徴とする受信方法。
  13. 　音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおける送信方法において、
    　音声データのヘッダ圧縮を行う圧縮工程と、
    　前記圧縮工程によってヘッダ圧縮された音声データを送信する送信工程と、
    　前記送信工程によって送信される音声データの通話状態を判定する判定工程と、
    　前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
    　を含むことを特徴とする送信方法。
  14. 　音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムにおいて、
    　音声データのヘッダ圧縮を行う圧縮手段と、
    　前記圧縮手段によってヘッダ圧縮された音声データを送信する送信手段と、
    　前記送信手段によって送信された音声データを受信する受信手段と、
    　前記受信手段によって受信される音声データの通話状態を判定する判定手段と、
    　前記判定手段の判定結果に応じて前記動作モードを切り替える制御手段と、
    　を備えることを特徴とする通信システム。
  15. 　音声データのヘッダ圧縮を行い、ヘッダ圧縮の頻度が異なる複数の動作モードを有する通信システムの通信方法において、
    　音声データのヘッダ圧縮を行う圧縮工程と、
    　前記圧縮工程によってヘッダ圧縮された音声データを送信する送信工程と、
    　前記送信工程によって送信された音声データを受信する受信工程と、
    　前記受信工程によって受信される音声データの通話状態を判定する判定工程と、
    　前記判定工程の判定結果に応じて前記動作モードを切り替える制御工程と、
    　を含むことを特徴とする通信方法。
PCT/JP2009/055451 2009-03-19 2009-03-19 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法 WO2010106663A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP09841868.4A EP2410725A4 (en) 2009-03-19 2009-03-19 RECEIVER, TRANSMITTER, RECEIVER, TRANSMISSION, COMMUNICATION SYSTEM, AND COMMUNICATION METHOD
PCT/JP2009/055451 WO2010106663A1 (ja) 2009-03-19 2009-03-19 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法
CN200980158061.8A CN102349285B (zh) 2009-03-19 2009-03-19 接收装置、发送装置、接收方法、发送方法、通信系统及通信方法
JP2011504677A JP5278532B2 (ja) 2009-03-19 2009-03-19 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法
KR1020117020322A KR20110113649A (ko) 2009-03-19 2009-03-19 수신 장치, 송신 장치, 수신 방법, 송신 방법, 통신 시스템 및 통신 방법
US13/217,900 US8521098B2 (en) 2009-03-19 2011-08-25 Receiving apparatus, transmitting apparatus, receiving method, transmitting method, communications system, and communication method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/055451 WO2010106663A1 (ja) 2009-03-19 2009-03-19 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/217,900 Continuation US8521098B2 (en) 2009-03-19 2011-08-25 Receiving apparatus, transmitting apparatus, receiving method, transmitting method, communications system, and communication method

Publications (1)

Publication Number Publication Date
WO2010106663A1 true WO2010106663A1 (ja) 2010-09-23

Family

ID=42739332

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/055451 WO2010106663A1 (ja) 2009-03-19 2009-03-19 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法

Country Status (6)

Country Link
US (1) US8521098B2 (ja)
EP (1) EP2410725A4 (ja)
JP (1) JP5278532B2 (ja)
KR (1) KR20110113649A (ja)
CN (1) CN102349285B (ja)
WO (1) WO2010106663A1 (ja)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013543352A (ja) * 2010-11-08 2013-11-28 クアルコム，インコーポレイテッド マルチリンクｐｄｃｐサブレイヤを利用するマルチポイントｈｓｄｐａ通信のためのシステムおよび方法
US8891356B2 (en) 2010-06-28 2014-11-18 Qualcomm Incorporated System and method for multi-point HSDPA communication utilizing a multi-link RLC sublayer
US8989140B2 (en) 2010-06-28 2015-03-24 Qualcomm Incorporated System and method for mobility in a multi-point HSDPA communication network
US9125098B2 (en) 2011-08-03 2015-09-01 Qualcomm Incorporated Method and apparatus for flow congestion control in multiflow networks
JP2016527733A (ja) * 2013-06-11 2016-09-08 クアルコム，インコーポレイテッド モデム支援ビデオ電話のための装置および方法
CN109257772A (zh) * 2017-07-13 2019-01-22 普天信息技术有限公司 一种rtp数据的发送、接收方法及用户设备
WO2020145399A1 (ja) * 2019-01-11 2020-07-16 シャープ株式会社 送信装置および受信装置
JP2022501945A (ja) * 2018-09-27 2022-01-06 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 通信方法及びデバイス
WO2022080304A1 (ja) * 2020-10-13 2022-04-21 シャープ株式会社 端末装置、基地局装置、および方法

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101671254B1 (ko) * 2010-03-02 2016-11-01 삼성전자주식회사 이동통신 시스템에서 음성 구간 검출 방법 및 장치
CN102300256B (zh) * 2010-06-22 2014-06-18 电信科学技术研究院 一种头压缩反馈信息的反馈方法和设备
CN106465349B (zh) 2014-05-08 2020-06-09 瑞典爱立信有限公司 用于检测用户设备中的静默时段状态的方法、系统和设备
CN108781461B (zh) * 2016-03-21 2023-04-11 瑞典爱立信有限公司 上行链路数据指示
US9986456B2 (en) * 2016-06-03 2018-05-29 Futurewei Technologies, Inc. System and method for data forwarding in a communications system
US10299163B2 (en) * 2016-07-05 2019-05-21 Mediatek Inc. Enhancement on header compression
WO2018026393A1 (en) * 2016-08-02 2018-02-08 Intel IP Corporation User equipment (ue), evolved node-b (enb) and methods for voice over lte (volte) communication in accordance with robust header compression (rohc)
US10978096B2 (en) * 2017-04-25 2021-04-13 Qualcomm Incorporated Optimized uplink operation for voice over long-term evolution (VoLte) and voice over new radio (VoNR) listen or silent periods
CN113660756B (zh) * 2021-08-04 2024-07-30 深圳市海曼科技股份有限公司 一种基于ZigBee的灯光控制方法、控制系统、智能家居系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002135362A (ja) 2000-08-17 2002-05-10 Matsushita Electric Ind Co Ltd ヘッダ圧縮装置およびヘッダ圧縮方法
JP2004194232A (ja) * 2002-12-13 2004-07-08 Mitsubishi Electric Corp パケット通信装置
JP2005057323A (ja) * 2003-08-01 2005-03-03 Ntt Docomo Inc データ流入量制御方法、基地局及び制御局
JP2005229378A (ja) * 2004-02-13 2005-08-25 Nec Corp 中継装置及びその制御方法
JP2006287284A (ja) * 2005-03-31 2006-10-19 Nec Corp 無線通信システム及びそのヘッダ圧縮制御方法
JP2006333407A (ja) * 2005-05-30 2006-12-07 Ntt Docomo Inc 送信制御装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5754589A (en) * 1993-01-08 1998-05-19 Multi-Tech Systems, Inc. Noncompressed voice and data communication over modem for a computer-based multifunction personal communications system
FR2721784B1 (fr) * 1994-06-24 1996-07-19 Thomson Csf Procédé, émetteur et récepteur pour la transmission d'informations par paquets.
EP1177668A2 (en) * 1999-05-10 2002-02-06 Nokia Corporation Header compression
US7031666B2 (en) * 2001-03-28 2006-04-18 Qualcomm Incorporated. Method and apparatus for header compression in a wireless communication system
FI118244B (fi) * 2001-06-27 2007-08-31 Nokia Corp Otsikkokenttien kompressiotunnisteen välittäminen datapakettiyhteydellä
US7313152B2 (en) * 2002-03-01 2007-12-25 Nokia Corporation IP header compression dependent connection admission control and/or channel allocation
TWI250724B (en) 2002-10-11 2006-03-01 Ericsson Telefon Ab L M Method and communication system for packeting messaging, and header compressor unit
KR100703303B1 (ko) 2005-04-28 2007-04-03 삼성전자주식회사 무선 통신 시스템에서 확장 실시간 폴링 서비스의 상향링크 자원 할당 요청 방법
KR100800878B1 (ko) * 2005-09-23 2008-02-04 삼성전자주식회사 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을포함하는 음성패킷의 송수신 방법 및 장치
US7907609B2 (en) * 2006-01-06 2011-03-15 Qualcomm, Incorporated Method and apparatus for enhancing RoHC performance when encountering silence suppression
JP2007249075A (ja) * 2006-03-17 2007-09-27 Toshiba Corp 音声再生装置および高域補間処理方法
CN101047711B (zh) * 2006-04-27 2010-08-18 华为技术有限公司 Ip报文传输、协商带宽节省能力和节省网络带宽的方法
KR101419287B1 (ko) * 2006-07-07 2014-07-14 삼성전자주식회사 Ｉｐｄｃ 서비스를 제공하는 장치 및 방법 및 ｉｐｄｃ서비스를 처리하는 장치 및 방법
KR100833973B1 (ko) * 2006-08-14 2008-05-30 전남대학교산학협력단 메타 접근통제 시스템
US20080084851A1 (en) * 2006-08-16 2008-04-10 Samsung Electronics Co., Ltd. Method and apparatus for sending state indication of voice packet by user equipment in a mobile communication system
US8289911B2 (en) * 2007-03-21 2012-10-16 Lg Electronics Inc. Method of scheduling of transmitting data in a wireless communication system
US7936695B2 (en) * 2007-05-14 2011-05-03 Cisco Technology, Inc. Tunneling reports for real-time internet protocol media streams
KR101377961B1 (ko) * 2007-07-27 2014-03-25 엘지전자 주식회사 헤더 오버헤드 감소를 위한 패킷 전송 방법
EP2228097B1 (en) * 2009-03-11 2016-01-27 Schiller Medical S.A.S. Defibrillator, rescue kit of parts and process for controlling the quality of chest compressions
US8111704B2 (en) * 2009-06-26 2012-02-07 Intel Corporation Multiple compression techniques for packetized information

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002135362A (ja) 2000-08-17 2002-05-10 Matsushita Electric Ind Co Ltd ヘッダ圧縮装置およびヘッダ圧縮方法
JP2004194232A (ja) * 2002-12-13 2004-07-08 Mitsubishi Electric Corp パケット通信装置
JP2005057323A (ja) * 2003-08-01 2005-03-03 Ntt Docomo Inc データ流入量制御方法、基地局及び制御局
JP2005229378A (ja) * 2004-02-13 2005-08-25 Nec Corp 中継装置及びその制御方法
JP2006287284A (ja) * 2005-03-31 2006-10-19 Nec Corp 無線通信システム及びそのヘッダ圧縮制御方法
JP2006333407A (ja) * 2005-05-30 2006-12-07 Ntt Docomo Inc 送信制御装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2410725A4

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8891356B2 (en) 2010-06-28 2014-11-18 Qualcomm Incorporated System and method for multi-point HSDPA communication utilizing a multi-link RLC sublayer
US8989140B2 (en) 2010-06-28 2015-03-24 Qualcomm Incorporated System and method for mobility in a multi-point HSDPA communication network
JP2013543352A (ja) * 2010-11-08 2013-11-28 クアルコム，インコーポレイテッド マルチリンクｐｄｃｐサブレイヤを利用するマルチポイントｈｓｄｐａ通信のためのシステムおよび方法
US8989004B2 (en) 2010-11-08 2015-03-24 Qualcomm Incorporated System and method for multi-point HSDPA communication utilizing a multi-link PDCP sublayer
US9125098B2 (en) 2011-08-03 2015-09-01 Qualcomm Incorporated Method and apparatus for flow congestion control in multiflow networks
JP2016527733A (ja) * 2013-06-11 2016-09-08 クアルコム，インコーポレイテッド モデム支援ビデオ電話のための装置および方法
CN109257772A (zh) * 2017-07-13 2019-01-22 普天信息技术有限公司 一种rtp数据的发送、接收方法及用户设备
JP2022501945A (ja) * 2018-09-27 2022-01-06 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 通信方法及びデバイス
JP7327831B2 (ja) 2018-09-27 2023-08-16 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 通信方法及びデバイス
US11956667B2 (en) 2018-09-27 2024-04-09 Huawei Technologies Co., Ltd. Communication method and device
WO2020145399A1 (ja) * 2019-01-11 2020-07-16 シャープ株式会社 送信装置および受信装置
WO2022080304A1 (ja) * 2020-10-13 2022-04-21 シャープ株式会社 端末装置、基地局装置、および方法

Also Published As

Publication number Publication date
JPWO2010106663A1 (ja) 2012-09-20
US20110306309A1 (en) 2011-12-15
EP2410725A4 (en) 2015-07-01
CN102349285A (zh) 2012-02-08
EP2410725A1 (en) 2012-01-25
US8521098B2 (en) 2013-08-27
KR20110113649A (ko) 2011-10-17
JP5278532B2 (ja) 2013-09-04
CN102349285B (zh) 2014-04-16

Similar Documents

Publication Publication Date Title
JP5278532B2 (ja) 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法
US7562277B2 (en) Data transmitting/receiving system and method thereof
JP6907444B2 (ja) データ伝送方法、通信デバイス、端末、および基地局
JP5063781B2 (ja) 無線通信システムでアップリンクデータ及びバッファ状態報告を伝送する方法及びこれを具現する無線装置
KR100460970B1 (ko) 데이터 송수신 시스템 및 방법
JP5084842B2 (ja) 無線通信ネットワークにおける改良されたヘッダ圧縮
KR101722719B1 (ko) 역방향의 강력한 헤더 압축 수신기
KR100927941B1 (ko) 사용자 평면 트래픽 제공 방법, 컴퓨터 판독가능 저장 매체, 전송 장치, 통신 제공 시스템, 단말 장치 및 네트워크 제어기 장치
AU2003248437A1 (en) Packet Transmission System and Packet Reception System
JP2003333577A (ja) メディア・ストリーミング配信システム
US8537708B2 (en) Packet transmission method and nodes
US20100067430A1 (en) Relay apparatus and relay method
CN107566330B (zh) 适于维持接收数据质量的装置和用于接收数据的方法
JP4930589B2 (ja) 中継装置および出力制御方法
CN1780296B (zh) 一种快速恢复压缩解压缩上下文的方法
US20170078050A1 (en) Packet retransmission method in a wireless transmitter
WO2010082236A1 (ja) バッファ制御装置及び無線通信端末
EP2534799B1 (en) Enhanced resequencing of data received over a wireless communication system
JP2001197144A (ja) 無線機
Maeder et al. Performance evaluation of ROHC reliable and optimistic mode for voice over LTE
WO2022237279A1 (zh) 一种数据传输方法及装置
Elnashar et al. Performance evaluation of volte based on field measurement data
JP2006333407A (ja) 送信制御装置
Tomoskozi et al. Applying robust header compression version 2 for UDP and RTP broadcasting with field constraints
CN109219079B (zh) 一种ir报文传输方法及通信设备

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980158061.8

Country of ref document: CN

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

Ref document number: 09841868

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011504677

Country of ref document: JP

ENP Entry into the national phase

Ref document number: 20117020322

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2009841868

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE