[go: up one dir, main page]

WO2018167858A1 - 無線通信装置及び無線通信方法 - Google Patents

無線通信装置及び無線通信方法 Download PDF

Info

Publication number
WO2018167858A1
WO2018167858A1 PCT/JP2017/010280 JP2017010280W WO2018167858A1 WO 2018167858 A1 WO2018167858 A1 WO 2018167858A1 JP 2017010280 W JP2017010280 W JP 2017010280W WO 2018167858 A1 WO2018167858 A1 WO 2018167858A1
Authority
WO
WIPO (PCT)
Prior art keywords
header compression
wireless communication
rohc
asymmetric
communication device
Prior art date
Application number
PCT/JP2017/010280
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 EP17900550.9A priority Critical patent/EP3598793A4/en
Priority to JP2019505574A priority patent/JP7149258B2/ja
Priority to PCT/JP2017/010280 priority patent/WO2018167858A1/ja
Priority to CN201780088301.6A priority patent/CN110402596B/zh
Priority to US16/493,406 priority patent/US11246058B2/en
Publication of WO2018167858A1 publication Critical patent/WO2018167858A1/ja

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
    • 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
    • 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
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

Definitions

  • the present invention relates to a wireless communication apparatus and a wireless communication method that apply header compression in a packet data convergence protocol layer (PDCP layer).
  • PDCP layer packet data convergence protocol layer
  • LTE Long Term Evolution
  • LTE-Advanced LTE-Advanced
  • 5G 5th generation mobile mobile communication systems
  • ROHC profiles are specified according to the type of header to be compressed, etc.
  • user equipment UE
  • can support ROHC profiles (supported ROHC-Profiles), and the number of sessions that can be used for ROHC.
  • UE-EUTRA-Capability the capability information (UE-EUTRA-Capability) of the UE including the field of the number of memories (maxNumberROHC-ContextSessions) that can be used for ROHC is notified to the radio base station (eNB).
  • LTE Release-14 applies header compression by ROHC only for uplink (UL) or only for downlink (DL) to reduce UE memory and power consumption (for convenience, Asymmetric ⁇ ⁇ ROHC ( (Referred to as non-patent document 1).
  • ROHC asymmetric header compression
  • Symmetric ⁇ ⁇ ROHC symmetric header compression
  • the present invention has been made in view of such a situation, a radio base station that supports asymmetric header compression in which header compression by ROHC is applied to either the uplink or the downlink, and an existing
  • An object of the present invention is to provide a wireless communication apparatus and a wireless communication method such as a user apparatus that can appropriately set asymmetric header compression even when wireless base stations that support only symmetric header compression coexist.
  • One aspect of the present invention is a radio communication apparatus that performs asymmetric header compression that applies header compression in a packet data convergence protocol layer to either an uplink or a downlink, and is a counter radio communication apparatus
  • a support notification receiving unit for receiving a support notification indicating that the asymmetric header compression is supported; and when the support notification receiving unit receives the support notification, the profile of the asymmetric header compression is A capability notification unit that notifies the opposite wireless communication device of information used for setting the asymmetric header compression by including it in the capability information.
  • One aspect of the present invention is a wireless communication apparatus that performs asymmetric header compression in which header compression in a packet data convergence protocol layer is applied to either an uplink or a downlink, wherein the header compression is performed.
  • asymmetric header compression not applying the header compression in the reception direction of the wireless communication device when the packet reception unit receives the compressed packet when the packet reception unit receives the compressed packet applied.
  • a negative response transmission unit that transmits a negative response indicating that the compressed packet could not be received to the opposite wireless communication apparatus.
  • One aspect of the present invention is a wireless communication apparatus that performs asymmetric header compression in which header compression in a packet data convergence protocol layer is applied to either an uplink or a downlink, and the wireless communication apparatus
  • a capability notification unit that notifies the opposite wireless communication device of the capability information of, wherein the capability notification unit is a field that indicates the content of symmetric header compression that applies the header compression to both the uplink and the downlink,
  • the capability information including the field indicating the content of the asymmetric header compression that is separate from the field indicating the content of the symmetric header compression is notified.
  • One aspect of the present invention is a wireless communication method in a wireless communication apparatus that performs asymmetric header compression in which header compression in a packet data convergence protocol layer is applied to either an uplink or a downlink, Receiving a support notification indicating that the asymmetric header compression is supported from the opposite wireless communication device; and, when receiving the support notification, including the asymmetric header compression profile in the capability information of the wireless communication device To notify the opposite wireless communication apparatus of information used for setting the asymmetric header compression.
  • One aspect of the present invention is a wireless communication method in a wireless communication apparatus that performs asymmetric header compression in which header compression in a packet data convergence protocol layer is applied to either an uplink or a downlink, Receiving the compressed packet to which the header compression is applied; and when the compressed packet is received, the asymmetric header compression is applied in the reception direction of the wireless communication device, so that the compressed packet cannot be received. Transmitting a negative acknowledgment to the opposite wireless communication device.
  • One aspect of the present invention is a wireless communication method in a wireless communication apparatus that performs asymmetric header compression in which header compression in a packet data convergence protocol layer is applied to either an uplink or a downlink, A field indicating the content of symmetric header compression that applies the header compression to both the uplink and the downlink, and a field indicating the content of the asymmetric header compression that is separate from the field indicating the content of the symmetric header compression; In the capability information of the wireless communication device, and notifying the opposite wireless communication device of the capability information.
  • FIG. 1 is an overall schematic configuration diagram of a wireless communication system 10.
  • FIG. 2 is a functional block configuration diagram of UE 200.
  • FIG. 3 is a functional block configuration diagram of the eNB 100A.
  • 4A and 4B are conceptual diagrams of SymmetricSROHC and Asymmetric ROHC.
  • FIG. 5 is an operation flow diagram of UE 200 (operation example 1).
  • 6A and 6B are diagrams showing a configuration example of a field indicating the contents of existing Symmetric ROHC and a field indicating the contents of Asymmetric ROHC.
  • FIGS. 7A and 7B are diagrams showing configuration examples of capability information including information indicating that Asymmetric ROHC is supported in a field indicating the contents of existing Symmetric ROHC.
  • FIG. 1 is an overall schematic configuration diagram of a wireless communication system 10.
  • FIG. 2 is a functional block configuration diagram of UE 200.
  • FIG. 3 is a functional block configuration diagram of the eNB 100A.
  • 4A and 4B are conceptual diagrams of Sy
  • FIGS. 8 is a diagram illustrating an application operation sequence (operation example 2) of Asymmetric ROHC by the eNB 100A and the UE 200.
  • FIG. 9 is an operation flow diagram of UE 200 (operation example 2).
  • FIG. 10 is an operation flow diagram of UE 200 (operation example 3).
  • FIGS. 11A and 11B are application operation flow charts of Asymmetric ROHC in eNB100A and eNB100B.
  • 12A, 12B, and 12C are diagrams illustrating a configuration example of a field (CapabilityCapfield) included in UE-EUTRA-Capability.
  • FIGS. 13A to 13D are diagrams showing an example of setting ROHC when Symmetric ROHC and Asymmetric ROHC can coexist.
  • FIG. 14 is a diagram illustrating an example of an allocation pattern designated by the UE 200 when Symmetric ROHC and Asymmetric ROHC coexist.
  • FIGS. 15A, 15B, and 15C are diagrams illustrating examples of notification of the allocation pattern when Symmetric ROHC and Asymmetric ROHC coexist.
  • FIG. 16 is a diagram illustrating an example of a hardware configuration of the eNB 100A, the bag 100B, and the UE 200.
  • FIG. 1 is an overall schematic configuration diagram of a radio communication system 10 according to the present embodiment.
  • the radio communication system 10 is a radio communication system according to Long Term Evolution (LTE), and includes a radio access network 20 and a user apparatus 200 (hereinafter, UE 200).
  • LTE Long Term Evolution
  • UE 200 user apparatus 200
  • the radio access network 20 is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) defined in 3GPP, and includes a radio base station 100A and a radio base station 100B (hereinafter, eNB100A, eNB100B).
  • E-UTRAN Evolved Universal Terrestrial Radio Access Network
  • the radio communication system 10 is not necessarily limited to LTE (E-UTRAN).
  • the radio access network 20 may be a radio access network including a radio base station that performs radio communication with the UE 200 (user apparatus) defined as 5G.
  • ENB100A, 100B, and UE200 perform wireless communication in accordance with LTE specifications. Specifically, eNB100A and UE200 perform radio
  • VoLTE voice packet transmission
  • UE 200 constitutes a radio communication device
  • eNB 100A constitutes an opposite radio communication device that performs radio communication opposite to UE 200.
  • UE 200 sets eNB 100A, 100B and a data radio bearer (DRB) that is a radio bearer for user data. Specifically, UE200 sets eNB100A and DRB31. Moreover, UE200 sets eNB100B and DRB32. UE 200 sets eNB 100A and eNB 100B and a radio bearer for signaling (SRB, not shown).
  • DRB data radio bearer
  • the eNB100A and UE200 are used for header compression (specifically, ROHC (RTP / UDP / IP) in the packet data convergence protocol layer (PDCP layer) in either uplink (UL) or downlink (DL). Perform asymmetric header compression.
  • the eNB 100A and the UE 200 support Asymmetric ROHC that applies header compression by RObust Header Compression (ROHC) only in UL or DL only.
  • ROHC RObust Header Compression
  • FIG. 2 is a functional block configuration diagram of UE 200.
  • the UE 200 includes a radio communication unit 210, a data transmission / reception unit 220, a header compression processing unit 230, a capability notification unit 240, and an ACK / NACK processing unit 250.
  • the wireless communication unit 210 performs wireless communication according to LTE with the eNB 100A and the eNB 100B. Specifically, the radio communication unit 210 can set the eNB 100A and the DRB 31 (see FIG. 1). Further, the radio communication unit 210 can set the eNB 100B and the DRB 32 (see FIG. 1). Furthermore, the radio communication unit 210 can set eNB 100A and eNB 100B and a radio bearer for signaling (SRB, not shown).
  • SRB radio bearer for signaling
  • the data transmission / reception unit 220 transmits / receives a packet including user data and a packet including control data.
  • the data transmitting / receiving unit 220 receives broadcast information (MIB (Master Information Block) and SIB (System Information Block)) from the radio access network 20 (specifically, eNB 100A or eNB 100B). Further, the data transmitting / receiving unit 220 receives information by individual signaling, particularly UE capability enquiry or RRC Connection Reconfiguration in this embodiment.
  • the broadcast information and / or signaling will be described later. In the following description, the types and means described later may be applied as appropriate to the broadcast information and / or signaling.
  • the data transmission / reception unit 220 receives a support notification indicating that Asymmetric ROHC (asymmetric header compression) is supported from the eNB 100A (opposite wireless communication device).
  • the data transmitting / receiving unit 220 constitutes a support notification receiving unit.
  • the data transmission / reception unit 220 receives the support notification by the above-described broadcast information or individual signaling.
  • the data transmitting / receiving unit 220 receives a compressed packet to which ROHC is applied.
  • the data transmitter / receiver 220 constitutes a packet receiver. Specifically, after receiving an uncompressed packet to which ROHC (header compression) is not applied, the data transmitting / receiving unit 220 receives a compressed packet following the uncompressed packet.
  • the header compression processing unit 230 executes compression and decompression processing of the header of the packet transmitted and received by the data transmitting / receiving unit 220. Specifically, the header compression processing unit 230 executes compression (compress) and decompression (decompress) of the RTP / UDP / IP header and the like according to ROHC.
  • the header compression processing unit 230 includes a memory corresponding to the number of sessions (maxNumberROHC-ContextSessions) that can be used for header compression.
  • ROHC in the case of RTP packets such as voice packets, the number of bits that are actually transmitted is reduced by transmitting only the portion of the RTP / UDP / IP header field that changes between packets.
  • ROHC can compress the header to a minimum of 3 bytes.
  • Static part examples include SSRC (RTP layer identifier) and IP address.
  • Fields that change (dynamic part) include RTP timestamp, RTP-Sequence Number, and UDP checksum.
  • RTP / RTCP sessions may be set with respect to one bearer (DRB), UE200 and eNB100A (eNB100B) depends on the ability.
  • DRB bearer
  • UE200 eNB100A
  • eNB100B eNB100B
  • the UE 200 that is, the header compression processing unit 230 supports Asymmetric ROHC.
  • FIG. 4 (a) and 4 (b) are conceptual diagrams of Symmetric ROHC and Asymmetric ROHC. Specifically, FIG. 4A shows a conceptual diagram of Symmetric ROHC (symmetric header compression), and FIG. 4B shows a conceptual diagram of Asymmetric ROHC (asymmetric header compression).
  • Symmetric ROHC performs header compression / decompression by ROHC for both UL data and DL data (packets), but Asymmetric ROHC uses only UL data. , ROHC header compression / decompression is executed. In other words, ROHC is not applied to DL data.
  • Asymmetric ROHC is based on the assumption that when DL and UL radio resources are asymmetric, such as TDD (Time Division Duplex), the benefits (transmission efficiency improvement) of ROHC are large only in one of the links. Yes.
  • TDD Time Division Duplex
  • the advantage of ROHC is greater than in UL with a small number of radio resources (number of subframes).
  • ROHC non-applicable in one link
  • a method of bypassing ROHC (Compressor) or a method of allocating the data only to Uncompressed session can be considered.
  • the capability notification unit 240 notifies the capability information of the UE 200 (wireless communication device) to the eNB 100A (opposite wireless communication device). Note that the capability notification unit 240 can also notify the eNB 100B of the capability information. Here, notification to eNB 100A will be described as an example.
  • the capability notification unit 240 notifies UE-EUTRA-Capability to the eNB 100A as UE 200 capability information.
  • the capability notification unit 240 includes information on the setting of AsymmetricHCROHC by including the AsymmetricAROHC profile in the UE200 capability information. (Herein referred to as ROHC Capability) is notified to the eNB 100A.
  • the existing Symmetric ROHC profile is defined in Chapter 5.5.1 (Supported header, compression, protocols, and profiles) of 3GPP TS 36.323 Packet Data Convergence Protocol (PDCP) specification, but in this embodiment Asymmetric ROHC Profile (ROHC Profile) has been added.
  • PDCP Packet Data Convergence Protocol
  • ROHC Profile Asymmetric ROHC Profile
  • the capability notification unit 240 when the data transmission / reception unit 220 (support notification reception unit) receives a support notification, the capability notification unit 240 includes a field indicating the content of Symmetric ROHC that applies ROHC to both UL and DL, and Symmetric
  • the eNB 100A can be notified of the capability information (UE-EUTRA-Capability) including a field indicating the content of AsymmetricAROHC, which is separate from the field indicating the content of ROHC.
  • the capability notification unit 240 includes capability information including information indicating that Asymmetric® ROHC is supported in the field indicating the content of Symmetric® ROHC.
  • the eNB 100A can also be notified.
  • the capability notification unit 240 can notify the eNB 100A of information used for setting the Asymmetric ROHC by including the Asymmetric ROHC profile (ROHC Profile) in the UE-EUTRA-Capability.
  • Asymmetric ROHC profile ROHC Profile
  • the capability notification unit 240 separates the field indicating the content of Symmetric ROHC from the field indicating the content of Symmetric ROHC regardless of whether the data transmission / reception unit 220 (support notification receiving unit) has received the support notification. It is also possible to notify the eNB 100A of capability information including a field indicating the contents of Asymmetric ROHC.
  • the field indicating the contents of Asymmetric ROHC and the field showing the contents of Symmetric ROHC include supported header compression profiles (supportedROHC-Profiles) and the number of sessions that can be used for header compression (maxNumberROHC-ContextSessions). .
  • the capability notification unit 240 may share a field (supported ROHC-Profiles) indicating a Symmetric ROHC profile at least for an Asymmetric ROHC profile. Further, the capability notification unit 240 may share a field (maxNumberROHC-ContextSessions) indicating the number of sessions that can be used for Symmetric ⁇ ROHC header compression for the number of sessions that can be used for Asymmetric ROHC header compression.
  • a field supported ROHC-Profiles
  • maximumNumberROHC-ContextSessions indicating the number of sessions that can be used for Symmetric ⁇ ROHC header compression for the number of sessions that can be used for Asymmetric ROHC header compression.
  • the ACK / NACK processing unit 250 executes ACK (acknowledgment) and NACK (negative acknowledgment) transmission processing for the packet received by the data transmitting / receiving unit 220.
  • the ACK / NACK processing unit 250 does not apply ROHC in the reception direction of the UE 200 (wireless communication device) when the data transmission / reception unit 220 (packet reception unit) receives a compressed packet by ROHC.
  • NACK negative acknowledgment
  • the eNB 100A opposite wireless communication device
  • the ACK / NACK processing unit 250 constitutes a negative response transmission unit.
  • ACK / NACK processing unit 250 receives a compressed packet by ROHC following an uncompressed packet. Return STATIC-NACK. Thereby, header compression by ROHC is stopped, and the data transmitting / receiving unit 220 can continuously receive uncompressed packets.
  • FIG. 3 is a functional block configuration diagram of the eNB 100A. As illustrated in FIG. 3, the eNB 100A includes a wireless communication unit 110, a data transmission / reception unit 120, a header compression processing unit 130, and a UE capability acquisition unit 140.
  • the wireless communication unit 110 performs wireless communication according to the UE 200 and LTE. Specifically, the radio communication unit 110 can set the UE 200 and the DRB 31 (see FIG. 1). Further, radio communication section 110 can set UE 200 and a radio bearer for signaling (SRB, not shown).
  • SRB radio bearer for signaling
  • the data transmission / reception unit 120 transmits / receives a packet including user data and a packet including control data, similar to the data transmission / reception unit 220 described above.
  • the data transmitting / receiving unit 120 transmits broadcast information (MIB (Master Information Block) and SIB (System Information Block)). Further, the data transmitting / receiving unit 120 transmits information by individual signaling, particularly UE capability enquiry or RRC Connection Reconfiguration in this embodiment.
  • MIB Master Information Block
  • SIB System Information Block
  • the data transmitter / receiver 120 transmits a support notification indicating that the eNB 100A supports Asymmetric ROHC (asymmetric header compression) to the UE 200. Specifically, the data transmitting / receiving unit 120 transmits the support notification by the above-described broadcast information or individual signaling.
  • the header compression processing unit 130 executes the header compression processing of the packet transmitted and received by the data transmission / reception unit 120, similarly to the header compression processing unit 230 described above. Specifically, the header compression processing unit 130 executes header compression processing based on the UE 200 capability information acquired by the UE capability acquisition unit 140.
  • the header compression processing unit 130 performs compression and decompression (decompress) of the RTP / UDP / IP header and the like according to ROHC.
  • the eNB 100A that is, the header compression processing unit 130 supports Asymmetric ROHC.
  • UE capability acquisition unit 140 acquires capability information of UE 200. Specifically, UE capability acquisition section 140 acquires various capabilities of UE 200 based on the content of UE-EUTRA-Capability notified from UE 200.
  • the UE capability acquisition unit 140 calculates the supported header compression profiles (supportedROHC-Profiles) and the number of sessions (maxNumberROHC-ContextSessions) that can be used for header compression for Symmetric ROHC and Asymmetric ROHC. get.
  • the UE capability acquisition unit 140 provides the acquired information to the header compression processing unit 130 and the like.
  • the UE 200 notifies the Asymmetric ROHC capability information only when the radio access network 20 (eNB100A) supports Asymmetric ROHC.
  • UE200 transmits NACK to the compressed packet by ROHC transmitted from eNB100A.
  • UE200 transmits capability information of both Symmetric ROHC and Asymmetric ROHC.
  • FIG. 5 is an operation flow diagram of UE 200 (operation example 1). As illustrated in FIG. 5, the UE 200 determines whether a support notification indicating that the radio access network 20 (eNB 100A) supports Asymmetric ROHC is received from the eNB 100A (S10). Thereby, UE200 can recognize that eNB100A supports Asymmetric ROHC.
  • eNB 100A the radio access network 20
  • S10 the eNB 100A
  • the eNB100A does not directly indicate that it supports Asymmetric ROHC, but sends a support notification indicating that it supports the version of RRC (Radio Resource Control) in which Asymmetric ROHC is introduced. Also good.
  • RRC Radio Resource Control
  • the UE 200 When receiving the support notification, the UE 200 notifies the eNB 100A of information (ROHC Capability) used for setting the Asymmetric ROHC (S20).
  • the UE 200 includes, as ROHC Capability, capability information (UE-EUTRA) of UE 200 including header compression profiles that can be supported (supported ROHC-Profiles) and the number of sessions that can be used for header compression (maxNumberROHC-ContextSessions). -Capability) to eNB100A.
  • UE-EUTRA capability information
  • UE-EUTRA capability information
  • maximumNumberROHC-ContextSessions maximum number of sessions that can be used for header compression
  • -Capability to eNB100A.
  • FIGS. 6A and 6B show a configuration example of a field indicating the contents of existing Symmetric ROHC and a field indicating the contents of Asymmetric ROHC.
  • the field indicating the contents of existing Symmetric ROHC (Capability field (Conventional)) and the field indicating the contents of Asymmetric ROHC (Capability field (New)) are included in the UE 200 capability information (UE-EUTRA-Capability).
  • the eNB 100A transmits a support notification for Asymmetric ROHC to the UE 200.
  • UE 200 notifies Capability field (Conventional is not included, and capability information including Capability field (New only) to eNB 100A. That is, UE 200 does not use Capability field (Conventional.
  • eNB100B since eNB100B does not support Asymmetric ROHC, it does not transmit a support notification of Asymmetric ROHC. In this case, UE 200 does not use Capability field (Conventional and Capability field (New) and does not transmit to eNB 100B.
  • Capability field Conventional and Capability field (New)
  • UE200 Since eNB100B does not receive Capability field (Conventional information including Conventional), UE200 simply determines that it does not support ROHC, and does not perform header compression by ROHC. That is, eNB100B is a UE that does not support ROHC. UE200 will be handled.
  • FIGS. 7A and 7B show configuration examples of capability information including information indicating that Asymmetric ROHC is supported in a field indicating the contents of existing Symmetric ROHC.
  • the eNB 100A transmits a support notification for Asymmetric ROHC to the UE 200.
  • UE 200 notifies the profile of Asymmetric ROHC by diverting existing supported ROHC-Profiles.
  • Profile0x0001 is set to True.
  • the number of sessions maxNumberROHC-ContextSessions that can be used for header compression is set to 2. This number only means the number of sessions applicable to UL. In other words, it is the value when Asymmetric ROHC is applied.
  • the UE 200 uses the existing supported ROHC-Profiles to notify that it supports Asymmetric ROHC.
  • FIG. 7A shows that Asymmetric ROHC is supported as PDCP-parameters-14 (PDCP parameter for Release-14).
  • Capability field recognizes that the UE200 supports Asymmetric ROHC, and for the number of maxNumberROHC-ContextSessions, both UL and DL directions like the existing Symmetric ROHC are used. Replace with numerical values that apply only to one-way (UL), not numerical values.
  • the eNB 100B since the eNB 100B does not support Asymmetric ROHC, the eNB 100B does not transmit a support notification for Asymmetric ROHC.
  • the UE 200 sets the supported ROHC-Profiles indicating that the capability information itself including Capability field is transmitted but does not support ROHC. Specifically, in FIG. 7B, both Profile0x0001 and Profile0x0002 are set to False.
  • the eNB 100B that has received the capability information including such Capability field determines that the UE 200 simply does not support ROHC, and does not perform header compression by ROHC.
  • FIG. 8 shows an application operation sequence (operation example 2) of Asymmetric ROHC between the eNB 100A and the UE 200.
  • the eNB 100A starts communication with the UE 200, and does not perform header compression by ROHC, that is, transmits a predetermined number of IR packets including a full header (S110 to S130).
  • the IR packet is a type of packet (Initiation and Refresh state) defined in RFC3095, and is used on the Decompressor side to establish a ROHC context.
  • the IP packet is transmitted as a full header without being compressed, and the Decompressor side can establish a context based on the content and change pattern of the header.
  • Other information necessary for ROHC for example, Context ID is further notified using the ROHC header.
  • the eNB 100A transmits a predetermined number of IR packets including a full header, and then transmits a UO-0 packet (compressed packet) that has been subjected to header compression by ROHC (S140).
  • UO-0 packets are also specified in RFC3095.
  • the UE 200 determines to apply Asymmetric ROHC so as not to apply ROHC in the reception direction of the UE 200, that is, the DL direction (S150). That is, UE 200 applies ROHC only in the UL direction.
  • UE 200 returns NACK (STATIC-NACK) indicating that the UO-0 packet could not be received to eNB 100A so as not to apply ROHC in the DL direction (S160).
  • NACK STATIC-NACK
  • the eNB 100A transmits an IR packet (uncompressed packet) including a full header instead of a compressed packet (S170, S180).
  • the eNB 100A may transmit an uncompressed packet by an IR packet, or may allocate the packet (IP flow data) only to the uncompressed session.
  • FIG. 9 is an operation flow diagram of UE 200 (operation example 2). Specifically, FIG. 9 shows an operation flow inside the UE 200 after the processing of S140 shown in FIG.
  • the UE 200 determines whether or not a compressed packet (UO-0 packet) subjected to header compression by ROHC has been received (S210).
  • UE 200 determines whether to apply Asymmetric ROHC that does not apply ROHC in the DL direction (S220). Note that the process of S220 may be executed in advance before the process of S210.
  • UE200 decompresses the header of the compressed packet when Asymmetric ROHC is not applied (S230).
  • UE 200 When applying Asymmetric ROHC, UE 200 returns a NACK (STATIC-NACK) indicating that the UO-0 packet has not been received to eNB 100A (S240).
  • NACK STATIC-NACK
  • eNB 100A When UE 200 returns NACK to eNB 100A, as shown in FIG. 8, eNB 100A transmits an IR packet (uncompressed packet) including a full header, not a compressed packet. The UE 200 receives the uncompressed packet (S250).
  • the UE 200 performs packet reception processing (S260). Specifically, UE 200 reconfigures PDU / SDU based on the contents of the header and outputs the PDU / SDU to the upper layer.
  • the UE 200 may notify the eNB 100A of the capability information of the UE 200 regarding Asymmetric ROHC as described above.
  • Operation example 3 In operation example 3, as described above, UE 200 transmits capability information of both Symmetric ROHC and Asymmetric ROHC.
  • a basic operation flow in this operation example a notification example of application of Asymmetric ROHC, and a modification will be described.
  • FIG. 10 is an operation flow diagram (operation example 3) of the UE 200. 10, UE200 notifies Capability field (Conventional is notified to eNB100A (or eNB100B) (S310). Although Capability field (Conventional is the same as the content (refer FIG. 6) demonstrated in the operation example 1). Furthermore, it mentions later.
  • the UE 200 notifies the Capability field (New to the eNB 100A (or eNB 100B) (S320).
  • the Capability field (New is the same as the content described in the operation example 1 (see FIG. 6)), but will be described later.
  • S310 and S320 may be interchanged.
  • the Capability field (Conventional, i.e., the field indicating the content of Symmetric ROHC
  • the Capability field New, That is, the capability information including the field indicating the contents of Asymmetric ⁇ ⁇ ⁇ ⁇ ⁇ ROHC is notified to the eNB 100A.
  • FIG. 11 (a) and 11 (b) are application operation flow charts of Asymmetric ROHC in eNB100A and eNB100B. Specifically, Fig.11 (a) shows the application operation
  • the eNB 100B receives the capability information including Capability field (Conventional and Capability field (New) (S410).
  • Capability field Conventional and Capability field (New) (S410).
  • ENB100B that does not support Asymmetric ROHC determines whether or not header compression by ROHC is necessary based on Capability field (Conventional (S420). Here, header compression is necessary, that is, it is determined that ROHC is applied. And
  • ENB100B transmits a compressed packet to UE200 based on the determination result (S430).
  • the eNB 100A also receives the capability information including Capability field (Conventional and Capability field (New) (S510).
  • Capability field Conventional and Capability field (New) (S510).
  • the eNB100A supporting Asymmetric ROHC determines whether or not header compression by ROHC is necessary based on either Capability field (Conventional or Capability field (New (S520).
  • Capability field (Based on New Assume that it is determined that header compression is unnecessary, that is, ROHC is not applied.
  • ENB100A transmits an uncompressed packet to UE200 based on the determination result (S530).
  • eNB100B (AsymmetricHCROHC not supported) applies existing Capability field (conventional content, Symmetric ROHC is applied.
  • ENB100A (Asymmetric ROHC supported) either Symmetric ⁇ ⁇ ⁇ ⁇ ROHC or Asymmetric ROHC. Apply.
  • UE200 header compression processing unit 230 notifies ROHCabilityCapability to eNB100A (eNB100B) for each of Symmetric ROHC and Asymmetric ROHC, based on the size of memory to be installed (the number of memories according to maxNumberROHC-ContextSessions). . If the number of memories allocated to SymmetricSROHC is insufficient, ROHC Capability may be notified only for Asymmetric ROHC. Or UE200 applies Asymmetric ROHC (or Symmetric ROHC) according to the memory condition by returning NACK as appropriate, when the number of memory and processing capacity applicable to ROHC is insufficient. You may do it.
  • Asymmetric ROHC or Symmetric ROHC
  • FIGS. 12A, 12B, and 12C show configuration examples of fields (Capability fields) included in UE-EUTRA-Capability. As shown in FIGS. 12A, 12B, and 12C, in this operation example, Capability field (UE-EUTRA-Capability including both Conventional and Capability field (New is notified).
  • Capability field UE-EUTRA-Capability including both Conventional and Capability field (New is notified).
  • FIG. 12 (a) shows an example in which all the contents necessary for setting AsymmetricHCROHC are notified using Capability field (New.
  • ROHC is applied in UL
  • Asymmetric ROHC profiles (supportedROHC-Profiles)
  • the number of sessions that can be used for Asymmetric ROHC maxNumberROHC-ContextSessions) are notified using Capability field (New).
  • FIGS. 12B and 12C show an example in which a part of the contents related to Asymmetric ROHC is notified using Capability field (New).
  • Asymmetric ROHC profiles (supported ROHC-Profiles) are notified using Capability field (Conventional, and the number of sessions that can be used for Asymmetric ROHC (maxNumberROHC-ContextSessions) Notification is made using Capability field (New. That is, for supported ROHC-Profiles, a field indicating a Symmetric ROHC profile is shared.
  • the AsymmetricHCROHC profile (supportedROHC-Profiles) and the number of sessions that can be used for Asymmetric ROHC (maxNumberROHC-ContextSessions) are notified using Capability field (Conventional. That is, supportedROHC-Profiles and maxNumberROHC- For ContextSessions, the corresponding field of Symmetric ROHC is shared.
  • Capability field (New is used for notification that ROHC is applied in UL (AsymROHC-UL in FIG. 12C)).
  • CapabilityCapfield (see the hatched portion below New)
  • how many times for example, twice
  • the number of existing regions specifically, the number of sessions (memory)
  • FIGS. 13 (a) to (d) show examples of ROHC settings when Symmetric ROHC and Asymmetric ROHC can coexist.
  • two DRBs (# 1, # 2) are set between the eNB 100A and the UE 200.
  • the UE 200 is assumed to be equipped with five ROHC memories # 1 to # 5.
  • examples of setting of Symmetric ROHC and Asymmetric ROHC for each DRB include patterns shown in FIGS. 13B to 13D.
  • FIG. 13B SymmetricSROHC for one session is set in each DRB.
  • 4 memories ((UL 1 + DL 1) ⁇ 2) of the UE 200 are consumed.
  • the eNB 100A may recognize in advance the memory allocation patterns that can be supported in the UE 200 and set Symmetric ROHC and Asymmetric ROHC based on the allocation patterns.
  • the UE 200 designates a memory allocation pattern that can be supported, and notifies the eNB 100A of the designated allocation pattern in advance.
  • FIG. 14 shows an example of an allocation pattern designated by the UE 200 when Symmetric ROHC and Asymmetric ROHC coexist.
  • a corresponding allocation pattern is designated according to the number of memories (here, 5 memories) installed in the UE 200. Note that the allocation pattern may be determined in consideration of the set number of DRBs.
  • the assigned pattern may include the priority of each pattern.
  • the priority may be changed during communication execution (specifically, the RRC-CONNECTED state).
  • the UE 200 may notify the change of the priority by a message in any of the RRC / PDCP / RLC / MAC layers.
  • ENB100A sets at least one of Symmetric ROHC and Asymmetric ROHC so as not to exceed the capability (number of memories) of UE200 based on the notified contents. Moreover, eNB100A may update the content (priority) of an allocation pattern based on the notified content.
  • the UE 200 even if the UE 200 notifies the allocation pattern including the maximum number of memories that can be allocated, that is, maxNumberROHC-ContextSessions and either ROHC Capability of Symmetric ROHC or Asymmetric ROHC Good.
  • the ROHC allocation that is not notified can be implicitly indicated by the maximum memory number (15) and the number of Asymmetric ROHC allocations.
  • an allocation pattern is defined in the 3GPP specification, and only an index for identifying the allocation pattern may be notified.
  • each index may indicate True (corresponding) or False (not supporting).
  • the following action / effect can be obtained.
  • the UE 200 when receiving the support notification of Asymmetric ROHC from the eNB, the UE 200 includes the Asymmetric ROHC profile in the capability information (UE-EUTRA-Capability) of the UE 200, Notify eNB100A of information used for Asymmetric ROHC settings.
  • the profile of Asymmetric ROHC is not notified to eNB100B that does not support Asymmetric ROHC. For this reason, eNB100B handles UE200 as UE which does not support ROHC, and does not perform header compression by ROHC in DL direction.
  • the UE 200 uses the eNB100A (eNB100B) to display capability information including a field indicating the content of Symmetric ROHC and a field indicating the content of Asymmetric ROHC that is different from the field indicating the content of Symmetric ROHC. Can be notified. Further, according to the operation example 1, the UE 200 can also notify the eNB 100A (eNB 100B) of capability information including information indicating that Asymmetric ROHC is supported in the field indicating the content of Symmetric ROHC.
  • eNB100A Asymmetric ROHC support
  • eNB100B Asymmetric ROHC not supported
  • AsymmetricAROHC can be introduced while ensuring backward compatibility with eNB100B (not supported by Asymmetric ⁇ ROHC).
  • the UE 200 when receiving a compressed packet by ROHC following the uncompressed packet, the UE 200 transmits a NACK (negative acknowledgment) indicating that the compressed packet could not be received to the eNB 100A. For this reason, transmission of the compressed packet by eNB100A is stopped, and an uncompressed packet is transmitted. Thereby, it is possible to set AsymmetricAROHC that does not apply ROHC in the reception direction of UE 200 (that is, DL direction).
  • the eNB 100B that does not support Asymmetric ROHC only recognizes that the UE 200 has insufficient memory by returning the NACK. As a result, ROHC is not applied in packet transmission / reception with the eNB 100B.
  • the UE 200 may notify the capability information of the UE 200 to the eNB 100A.
  • the eNB 100A can avoid transmitting unnecessary compressed packets to the UE 200.
  • the UE 200 notifies the eNB 100A of capability information including a field indicating the content of Symmetric ROHC and a field indicating the content of Asymmetric ROHC which is different from the field indicating the content of Symmetric ROHC. .
  • UE200 can notify ROHC Capability that both eNB100A (Asymmetric ROHC support) and eNB100B (Asymmetric ROHC not supported) can recognize.
  • AsymmetricAROHC can be introduced while ensuring backward compatibility with eNB100B (not supported by Asymmetric ⁇ ROHC).
  • the field indicating the Symmetric ROHC profile can be shared for at least the Asymmetric ROHC profile. For this reason, Asymmetric ⁇ ROHC can be introduced while suppressing the amount of information required for setting Asymmetric ROHC.
  • Asymmetric ROHC can be appropriately set.
  • the above-described ROHC Capability regarding Asymmetric ROHC may be used as the Capability of the TCP ACKless function.
  • the TCP ACKless function is intended to reduce the radio bandwidth required for acknowledgment (TCP ACK) transmission in the TCP layer.
  • the packet receiver discards the packet without sending a TCP ACK.
  • the packet transmitting side receives an ACK (for example, RLC-ACK) in layer 2 for PDCP SDU (IP packet), it generates TCP ACK by itself and transmits it to the upper layer.
  • an ACK for example, RLC-ACK
  • PDCP SDU IP packet
  • TCP ACKless function has been proposed to solve this problem.
  • Capability of Asymmetric ROHC and TCP ACKless functions it becomes possible to prioritize the allocation of radio resources to DL / UL, and the combination of Asymmetric ROHC and TCP ACKless functions is DL / UL. It is also very effective from the viewpoint of more efficient use of the UL band.
  • the TCP ACKless function needs to be aware of the contents of the PDCP SDU, but ROHC already has a mechanism to grasp the contents of the PDCP SDU, so there is a part that can be shared with the TCP-ACK Sless function. There is also a merit from the viewpoint of mounting the UE 200 and the eNB 100A.
  • ROHC is used as a header compression protocol, but it is not necessarily limited to ROHC. That is, any protocol other than ROHC may be used as long as it has the same header compression function as ROHC.
  • ROHC is not applied in the DL direction and ROHC is applied only in the UL direction
  • ROHC may be applied only in the DL direction
  • the UE 200 has notified the eNB100A (eNB100B) of the capability related to Asymmetric ROHC, but the eNB100A (eNB100B) may have the same function. That is, eNB100A (eNB100B) may notify UE200 of the capability regarding Asymmetric ROHC, and UE200 may set Asymmetric ROHC based on the notified capability.
  • eNB100A eNB100B
  • UE200 may set Asymmetric ROHC based on the notified capability.
  • each functional block may be realized by one device physically and / or logically coupled, and two or more devices physically and / or logically separated may be directly and / or indirectly. (For example, wired and / or wireless) and may be realized by the plurality of devices.
  • FIG. 16 is a diagram illustrating an example of a hardware configuration of the apparatus.
  • the device may be configured as a computer device including a processor 1001, a memory 1002, a storage 1003, a communication device 1004, an input device 1005, an output device 1006, a bus 1007, and the like.
  • Each functional block (see FIGS. 2 and 3) of the device is realized by any hardware element of the computer device or a combination of the hardware elements.
  • the processor 1001 controls the entire computer by operating an operating system, for example.
  • the processor 1001 may be configured by a central processing unit (CPU) including an interface with peripheral devices, a control device, an arithmetic device, a register, and the like.
  • CPU central processing unit
  • the memory 1002 is a computer-readable recording medium and includes, for example, at least one of ROM (Read Only Memory), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), RAM (Random Access Memory), and the like. May be.
  • the memory 1002 may be called a register, a cache, a main memory (main storage device), or the like.
  • the memory 1002 can store a program (program code) that can execute the method according to the above-described embodiment, a software module, and the like.
  • the storage 1003 is a computer-readable recording medium such as an optical disc such as a CD-ROM (Compact Disc ROM), a hard disk drive, a flexible disc, a magneto-optical disc (eg a compact disc, a digital versatile disc, a Blu-ray). (Registered trademark) disk, smart card, flash memory (for example, card, stick, key drive), floppy (registered trademark) disk, magnetic strip, and the like.
  • the storage 1003 may be referred to as an auxiliary storage device.
  • the recording medium described above may be, for example, a database including a memory 1002 and / or a storage 1003, a server, or other suitable medium.
  • the communication device 1004 is hardware (transmission / reception device) for performing communication between computers via a wired and / or wireless network, and is also referred to as a network device, a network controller, a network card, a communication module, or the like.
  • the input device 1005 is an input device (for example, a keyboard, a mouse, a microphone, a switch, a button, a sensor, etc.) that accepts an input from the outside.
  • the output device 1006 is an output device (for example, a display, a speaker, an LED lamp, or the like) that performs output to the outside. Note that the input device 1005 and the output device 1006 may have an integrated configuration (for example, a touch panel).
  • each device such as the processor 1001 and the memory 1002 is connected by a bus 1007 for communicating information.
  • the bus 1007 may be configured with a single bus or may be configured with different buses between apparatuses.
  • notification of information includes physical layer signaling (eg, DCI (Downlink Control Information), UCI (Uplink Control Information)), upper layer signaling (eg, RRC signaling, MAC (Medium Access Control) signaling, broadcast information (MIB ( Master (Information Block), SIB (System Information Block)), other signals, or combinations thereof, and RRC signaling may also be referred to as RRC messages, eg, RRC Connection Connection message, RRC It may be a Connection ⁇ ⁇ Reconfiguration message.
  • RRC messages eg, RRC Connection Connection message, RRC It may be a Connection ⁇ ⁇ Reconfiguration message.
  • input / output information may be stored in a specific location (for example, a memory) or may be managed by a management table.
  • the input / output information can be overwritten, updated, or appended.
  • the output information may be deleted.
  • the input information may be transmitted to other devices.
  • the specific operation that is performed by the eNB 100A may be performed by another network node (device). Further, the function of the eNB 100A may be provided by a combination of a plurality of other network nodes.
  • a channel and / or symbol may be a signal (signal) if there is a corresponding description.
  • the signal may be a message.
  • system and “network” may be used interchangeably.
  • the parameter or the like may be represented by an absolute value, may be represented by a relative value from a predetermined value, or may be represented by other corresponding information.
  • the radio resource may be indicated by an index.
  • ENB100A base station
  • base station can accommodate one or a plurality of (for example, three) cells (also referred to as sectors).
  • a base station accommodates multiple cells, the entire coverage area of the base station can be partitioned into multiple smaller areas, each smaller area being a base station subsystem (eg, indoor small base station RRH: Remote Radio Head) can also provide communication services.
  • RRH Remote Radio Head
  • cell refers to part or all of the coverage area of a base station and / or base station subsystem that provides communication services in this coverage.
  • base station eNB
  • cell ector
  • a base station may also be referred to in terms such as a fixed station (fixed station), NodeB, eNodeB (eNB), access point (access point), femto cell, small cell, and the like.
  • UE 200 is a subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal by those skilled in the art. , Remote terminal, handset, user agent, mobile client, client, or some other appropriate terminology.
  • the phrase “based on” does not mean “based only on”, unless expressly specified otherwise. In other words, the phrase “based on” means both “based only on” and “based at least on.”
  • any reference to elements using designations such as “first”, “second”, etc. as used herein does not generally limit the amount or order of those elements. These designations can be used herein as a convenient way to distinguish between two or more elements. Thus, a reference to the first and second elements does not mean that only two elements can be employed there, or that in some way the first element must precede the second element.
  • a radio base station that supports asymmetric header compression in which ROHC header compression is applied to either the uplink or the downlink, and a radio that supports only existing symmetric header compression. Even when base stations are mixed, asymmetric header compression can be set appropriately.
  • Radio communication system 20 Radio access network 31, 32 DRB 100A, 100B eNB 110 Wireless communication unit 120 Data transmission / reception unit 130 Header compression processing unit 140 UE capability acquisition unit 200 UE 210 Wireless communication unit 220 Data transmission / reception unit 230 Header compression processing unit 240 Capability notification unit 250 ACK / NACK processing unit 1001 Processor 1002 Memory 1003 Storage 1004 Communication device 1005 Input device 1006 Output device 1007 Bus

Landscapes

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

Abstract

UE（200）は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用するAsymmetric ROHCを実行する。UE（200）は、eNBから、Asymmetric ROHCをサポートしていることを示すサポート通知を受信するデータ送受信部（220）と、データ送受信部（220）がサポート通知を受信した場合、Asymmetric ROHCのプロファイルをUE（200）の能力情報に含めることによって、Asymmetric ROHCの設定に用いる情報をeNBに通知する能力通知部（240）とを備える。

Description

無線通信装置及び無線通信方法
　本発明は、パケット・データ・コンバージェンス・プロトコル・レイヤ（PDCPレイヤ）におけるヘッダ圧縮を適用する無線通信装置及び無線通信方法に関する。
　3rd Generation Partnership Project（3GPP）は、Long Term Evolution（LTE）を仕様化し、LTEのさらなる高速化を目的としてLTE-Advanced（以下、LTE-Advancedを含めてLTEという）を仕様化している。また、3GPPでは、さらに、5G（5th generation mobile communication system）などと呼ばれるLTEの後継システムの仕様が検討されている。
　LTEでは、音声パケットを伝送することが可能（VoLTE）だが、音声パケットは、ペイロードに対するヘッダ（RTP/UDP/IP）の比率が高いため、当該ヘッダを圧縮することが規定されている。具体的には、LTEのパケット・データ・コンバージェンス・プロトコル・レイヤ（PDCPレイヤ）では、RFC3095などで規定されるRObust Header Compression（ROHC）に従って、RTP/UDP/IPなどのヘッダが圧縮される。これにより、音声パケットの伝送効率を高めている。
　LTEでは、圧縮対象のヘッダの種類などに応じた複数のROHC Profileが規定されており、ユーザ装置（UE）は、サポート可能なROHC Profile（supportedROHC-Profiles）、及びROHCに用い得るセッション数、具体的には、ROHCに用い得るメモリ数（maxNumberROHC-ContextSessions）のフィールドを含む、当該UEの能力情報（UE-EUTRA-Capability）を無線基地局（eNB）に通知する。
　一方、LTEのRelease-14では、主にUEのメモリ及び消費電力削減のため、上りリンク（UL）のみ、或いは下りリンク（DL）のみ、ROHCによるヘッダ圧縮を適用すること（便宜上、Asymmetric ROHC（非対称ヘッダ圧縮）という）が検討されている（例えば、非特許文献１参照）。
"RoHC Symmetric DL/UL Parameters Limitation in LTE", 3GPP TSG-RAN WG2 #97, 3R2-1701761, 2017年2月
　上述したAsymmetric ROHC（非対称ヘッダ圧縮）は、UL及びDLの両方にROHCを適用する既存のヘッダ圧縮（便宜上、Symmetric ROHC（対称ヘッダ圧縮）という）に対して制約を設ける制御となるため、単にAsymmetric ROHCを導入しても、バックワードコンパチビリティーを確保できない問題がある。
　具体的には、UE能力（UE-EUTRA-Capability）を示す既存のフィールド（supportedROHC-Profiles）にAsymmetric ROHCに対応可能なことを示す内容を単に追加しても、Asymmetric ROHCに対応していない非対応eNBは、Asymmetric ROHCに関連する当該フィールドの内容を認識することができない。このため、非対応eNBは、Asymmetric ROHCに対応しているUEと、Symmetric ROHCの設定を試みてしまい、Asymmetric ROHCを正しく設定できないことが懸念される。
　そこで、本発明は、このような状況に鑑みてなされたものであり、上りリンクまたは下りリンクの何れか一方にROHCによるヘッダ圧縮が適用される非対称ヘッダ圧縮をサポートする無線基地局と、既存の対称ヘッダ圧縮のみをサポートする無線基地局とが混在する場合でも、適切に非対称ヘッダ圧縮を設定することができるユーザ装置などの無線通信装置及び無線通信方法の提供を目的とする。
　本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置であって、対向無線通信装置から、前記非対称ヘッダ圧縮をサポートしていることを示すサポート通知を受信するサポート通知受信部と、前記サポート通知受信部が前記サポート通知を受信した場合、前記非対称ヘッダ圧縮のプロファイルを無線通信装置の能力情報に含めることによって、前記非対称ヘッダ圧縮の設定に用いる情報を前記対向無線通信装置に通知する能力通知部とを備える。
　本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置であって、前記ヘッダ圧縮が適用された圧縮パケットを受信するパケット受信部と、前記パケット受信部が前記圧縮パケットを受信した場合、前記無線通信装置の受信方向において前記ヘッダ圧縮を適用しない前記非対称ヘッダ圧縮を適用するため、前記圧縮パケットを受信できなかったことを示す否定応答を対向無線通信装置に送信する否定応答送信部とを備える。
　本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置であって、前記無線通信装置の能力情報を対向無線通信装置に通知する能力通知部を備え、前記能力通知部は、前記上りリンク及び前記下りリンクの両方に前記ヘッダ圧縮を適用する対称ヘッダ圧縮の内容を示すフィールドと、前記対称ヘッダ圧縮の内容を示すフィールドとは別個である前記非対称ヘッダ圧縮の内容を示すフィールドとを含む前記能力情報を通知する。
　本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置における無線通信方法であって、対向無線通信装置から、前記非対称ヘッダ圧縮をサポートしていることを示すサポート通知を受信するステップと、前記サポート通知を受信した場合、前記非対称ヘッダ圧縮のプロファイルを無線通信装置の能力情報に含めることによって、前記非対称ヘッダ圧縮の設定に用いる情報を前記対向無線通信装置に通知するステップとを含む。
　本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置における無線通信方法であって、前記ヘッダ圧縮が適用された圧縮パケットを受信するステップと、前記圧縮パケットを受信した場合、前記無線通信装置の受信方向において前記非対称ヘッダ圧縮を適用するため、前記圧縮パケットを受信できなかったことを示す否定応答を対向無線通信装置に送信するステップとを含む。
　本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置における無線通信方法であって、前記上りリンク及び前記下りリンクの両方に前記ヘッダ圧縮を適用する対称ヘッダ圧縮の内容を示すフィールドと、前記対称ヘッダ圧縮の内容を示すフィールドとは別個である前記非対称ヘッダ圧縮の内容を示すフィールドとを、前記無線通信装置の能力情報に含めるステップと、前記能力情報を対向無線通信装置に通知するステップとを含む。
図１は、無線通信システム10の全体概略構成図である。 図２は、UE200の機能ブロック構成図である。 図３は、eNB100Aの機能ブロック構成図である。 図４（ａ）及び（ｂ）は、Symmetric ROHC及びAsymmetric ROHCの概念図である。 図５は、UE200の動作フロー図（動作例１）である。 図６（ａ）及び（ｂ）は、既存のSymmetric ROHCの内容を示すフィールド及びAsymmetric ROHCの内容を示すフィールドの構成例を示す図である。 図７は（ａ）及び（ｂ）は、既存のSymmetric ROHCの内容を示すフィールドにAsymmetric ROHCをサポートすることを示す情報を含めた能力情報の構成例を示す図である。 図８は、eNB100AとUE200とによるAsymmetric ROHCの適用動作シーケンス（動作例２）を示す図である。 図９は、UE200の動作フロー図（動作例２）である。 図１０は、UE200の動作フロー図（動作例３）である。 図１１（ａ）及び（ｂ）は、eNB100A及びeNB100BにおけるAsymmetric ROHCの適用動作フロー図である。 図１２（ａ）、（ｂ）及び（ｃ）は、UE-EUTRA-Capabilityに含まれるフィールド（Capability field）の構成例を示す図である。 図１３（ａ）～（ｄ）は、Symmetric ROHC及びAsymmetric ROHCが混在し得る場合におけるROHCの設定例を示す図である。 図１４は、Symmetric ROHC及びAsymmetric ROHCが混在する場合において、UE200が指定する割り当てパタン例を示す図である。 図１５（ａ）、（ｂ）及び（ｃ）は、Symmetric ROHC及びAsymmetric ROHCが混在する場合における割り当てパタンの通知例を示す図である。 図１６は、eNB100A, 100B、及びUE200のハードウェア構成の一例を示す図である。
　以下、実施形態を図面に基づいて説明する。なお、同一の機能や構成には、同一または類似の符号を付して、その説明を適宜省略する。
　（１）無線通信システムの全体概略構成
　図１は、本実施形態に係る無線通信システム10の全体概略構成図である。無線通信システム10は、Long Term Evolution（LTE）に従った無線通信システムであり、無線アクセスネットワーク20及びユーザ装置200（以下、UE200）を含む。
　無線アクセスネットワーク20は、3GPPにおいて規定されるEvolved Universal Terrestrial Radio Access Network（E-UTRAN）であり、無線基地局100A, 無線基地局100B（以下、eNB100A, eNB100B）を含む。なお、無線通信システム10は、必ずしもLTE（E-UTRAN）に限定されない。例えば、無線アクセスネットワーク20は、5Gとして規定されるUE200（ユーザ装置）と無線通信を実行する無線基地局を含む無線アクセスネットワークであってもよい。
　eNB100A, 100B及びUE200は、LTEの仕様に従った無線通信を実行する。具体的には、eNB100A及びUE200は、LTE Release-14に従った無線通信を実行する。一方、eNB100Bは、LTE Release-14には対応しておらず、Release-14よりも前のRelease（例えば、Release-13）に対応している。また、eNB100A, 100B及びUE200は、音声パケットの伝送（VoLTE）に対応している。
　本実施形態において、UE200は、無線通信装置を構成し、eNB100Aは、UE200と対向して無線通信を実行する対向無線通信装置を構成する。
　UE200は、eNB100A, 100Bと、ユーザデータ用の無線ベアラであるデータ無線ベアラ（DRB）を設定する。具体的には、UE200は、eNB100AとDRB31を設定する。また、UE200は、eNB100BとDRB32を設定する。なお、UE200は、eNB100A及びeNB100Bとシグナリング用の無線ベアラ（SRB、不図示）を設定する。
　eNB100A及びUE200は、上りリンク（UL）または下りリンク（DL）の何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤ（PDCPレイヤ）におけるヘッダ圧縮（具体的には、ROHC RTP/UDP/IPなど）を適用する非対称ヘッダ圧縮を実行する。具体的には、eNB100A及びUE200は、ULのみ、或いはDLのみ、RObust Header Compression（ROHC）によるヘッダ圧縮を適用するAsymmetric ROHCをサポートしている。なお、本実施形態では、ULのみにROHCを適用し、DLにはROHCが適用されないケースを例として説明する。
　（２）無線通信システムの機能ブロック構成
　次に、無線通信システム10の機能ブロック構成について説明する。具体的には、eNB100A及びUE200の機能ブロック構成について説明する。
　（２．１）UE200
　図２は、UE200の機能ブロック構成図である。図２に示すように、UE200は、無線通信部210、データ送受信部220、ヘッダ圧縮処理部230、能力通知部240及びACK/NACK処理部250を備える。
　無線通信部210は、eNB100A及びeNB100BとLTEに従った無線通信を実行する。具体的には、無線通信部210は、eNB100AとDRB31（図１参照）を設定することができる。また、無線通信部210は、eNB100BとDRB32（図１参照）を設定することができる。さらに、無線通信部210は、eNB100A及びeNB100Bと、シグナリング用の無線ベアラ（SRB、不図示）を設定することができる。
　データ送受信部220は、ユーザデータを含むパケット、及び制御データを含むパケットを送受信する。
　また、データ送受信部220は、無線アクセスネットワーク20（具体的には、eNB100AまたはeNB100B）から報知情報（MIB（Master Information Block）及びSIB（System Information Block））を受信する。さらに、データ送受信部220は、個別シグナリングによる情報、特に、本実施形態では、UE capability enquiry、或いはRRC Connection Reconfigurationを受信する。なお、報知情報及び／又はシグナリングについては、後述する。以降の説明においても、報知情報及び／又はシグナリングは後述の種類・手段などを適宜適用してもよい。
　データ送受信部220は、eNB100A（対向無線通信装置）から、Asymmetric ROHC（非対称ヘッダ圧縮）をサポートしていることを示すサポート通知を受信する。本実施形態において、データ送受信部220は、サポート通知受信部を構成する。
　具体的には、データ送受信部220は、上述した報知情報、或いは個別シグナリングによって、当該サポート通知を受信する。
　また、データ送受信部220は、ROHCが適用された圧縮パケットを受信する。本実施形態において、データ送受信部220は、パケット受信部を構成する。具体的には、データ送受信部220は、ROHC（ヘッダ圧縮）が適用されていない非圧縮パケットを受信した後、当該非圧縮パケットに続けて、圧縮パケットを受信する。
　ヘッダ圧縮処理部230は、データ送受信部220が送受信するパケットのヘッダの圧縮及び伸張処理を実行する。具体的には、ヘッダ圧縮処理部230は、ROHCに従って、RTP/UDP/IPヘッダなどの圧縮（compress）及び伸張（decompress）を実行する。ヘッダ圧縮処理部230は、ヘッダ圧縮に用いることができるセッション数（maxNumberROHC-ContextSessions）に応じたメモリを搭載する。
　ROHCでは、音声パケットのようなRTPパケットの場合、RTP/UDP/IPヘッダフィールドのうち、パケット間で変化のある部分のみを送信することによって、実際に送信するビット数を低減する。ROHCでは、当該ヘッダを最小３バイトまで圧縮できる。
　変化しないフィールド（Static part）として、は、SSRC（RTPレイヤの識別子）及びIPアドレスなどが挙げられる。変化するフィールド（dynamic part）としては、RTP timestamp、RTP-Sequence Number及びUDP checksumなどが挙げられる。
　なお、一つのベアラ（DRB）に対して、複数のRTP/RTCPセッションが設定されることがあるが、当該複数セッションのうち、幾つのセッションに対してヘッダ圧縮が可能かは、UE200及びeNB100A（eNB100B）の能力に依存する。
　上述したように、UE200、つまり、ヘッダ圧縮処理部230は、Asymmetric ROHCをサポートしている。
　図４（ａ）及び（ｂ）は、Symmetric ROHC及びAsymmetric ROHCの概念図である。具体的には、図４（ａ）は、Symmetric ROHC（対称ヘッダ圧縮）の概念図を示し、図４（ｂ）は、Asymmetric ROHC（非対称ヘッダ圧縮）の概念図を示す。
　図４（ａ）及び（ｂ）に示すように、Symmetric ROHCでは、ULデータ及びDLデータ（パケット）の両方において、ROHCによるヘッダ圧縮・伸張が実行されるが、Asymmetric ROHCでは、ULデータのみにおいて、ROHCによるヘッダ圧縮・伸張が実行される。つまり、DLデータについては、ROHCが適用されない。
　Asymmetric ROHC導入のモチベーションは、TDD（Time Division Duplex）のようにDL及びULの無線リソースが非対称である場合、ROHCによる利点（伝送効率化）は、何れかのリンクのみで大きいという想定に基づいている。例えば、DLにおけるサブフレーム数が、ULにおけるサブフレーム数よりもかなり多くなるようなTDDの構成では、ROHCによる利点は、無線リソース（サブフレーム数）が少ないULに対して、より大きくなる。
　なお、一方のリンクにおいてROHC非適用とする方法としては、ROHC（Compressor）をバイパスする方法、或いは当該データをUncompressed sessionにのみ割り当てる方法が考えられる。
　能力通知部240は、UE200（無線通信装置）の能力情報をeNB100A（対向無線通信装置）に通知する。なお、能力通知部240は、当該能力情報をeNB100Bにも通知することができる。ここでは、eNB100Aへの通知を例として説明する。
　能力通知部240は、UE200の能力情報として、UE-EUTRA-CapabilityをeNB100Aに通知する。
　具体的には、能力通知部240は、データ送受信部220（サポート通知受信部）がサポート通知を受信した場合、Asymmetric ROHCのプロファイルをUE200の能力情報に含めることによって、Asymmetric ROHCの設定に用いる情報（ここでは、ROHC Capabilityという）をeNB100Aに通知する。
　なお、既存のSymmetric ROHCのプロファイルについては、3GPP TS 36.323 Packet Data Convergence Protocol (PDCP) specificationの5.5.1章（Supported header compression protocols and profiles）に規定されているが、本実施形態では、Asymmetric ROHCのプロファイル（ROHC Profile）が追加されている。
　より具体的には、能力通知部240は、データ送受信部220（サポート通知受信部）がサポート通知を受信した場合、UL及びDLの両方にROHCを適用するSymmetric ROHCの内容を示すフィールドと、Symmetric ROHCの内容を示すフィールドとは別個であるAsymmetric ROHCの内容を示すフィールドとを含む当該能力情報（UE-EUTRA-Capability）をeNB100Aに通知することができる。
　また、能力通知部240は、データ送受信部220（サポート通知受信部）がサポート通知を受信した場合、Symmetric ROHCの内容を示すフィールドに、Asymmetric ROHCをサポートすることを示す情報を含めた能力情報をeNB100Aに通知することもできる。
　つまり、能力通知部240は、Asymmetric ROHCのプロファイル（ROHC Profile）をUE-EUTRA-Capabilityに含めることによって、Asymmetric ROHCの設定に用いる情報をeNB100Aに通知することができる。
　また、能力通知部240は、データ送受信部220（サポート通知受信部）がサポート通知を受信したか否かに関わらず、Symmetric ROHCの内容を示すフィールドと、Symmetric ROHCの内容を示すフィールドとは別個であるAsymmetric ROHCの内容を示すフィールドとを含む能力情報をeNB100Aに通知することもできる。
　Asymmetric ROHCの内容を示すフィールド、及びSymmetric ROHCの内容を示すフィールドは、サポート可能なヘッダ圧縮のプロファイル（supportedROHC-Profiles）と、ヘッダ圧縮に用いることができるセッション数（maxNumberROHC-ContextSessions）と含んでいる。
　なお、能力通知部240は、少なくともAsymmetric ROHCのプロファイルについて、Symmetric ROHCのプロファイルを示すフィールド（supportedROHC-Profiles）を共用してもよい。さらに、能力通知部240は、Asymmetric ROHCのヘッダ圧縮に用いることができるセッション数について、Symmetric ROHCのヘッダ圧縮に用いることができるセッション数を示すフィールド（maxNumberROHC-ContextSessions）を共用してもよい。
　ACK/NACK処理部250は、データ送受信部220が受信したパケットに対するACK（肯定応答）及びNACK（否定応答）の送信処理を実行する。
　特に、本実施形態では、ACK/NACK処理部250は、データ送受信部220（パケット受信部）がROHCによる圧縮パケットを受信した場合、UE200（無線通信装置）の受信方向においてROHCを適用しないAsymmetric ROHCを適用するため、つまり、Asymmetric ROHCの適用を目的として、当該圧縮パケットを受信できなかったことを示すNACK（否定応答）をeNB100A（対向無線通信装置）に送信する。
　なお、NACKは、圧縮パケットを受信できなかった場合だけでなく、当該圧縮パケットのヘッダを伸張できなかった場合にも送信される。本実施形態において、ACK/NACK処理部250は、否定応答送信部を構成する。
　具体的には、Asymmetric ROHCにより、DLに対してROHC非適用とする場合、ACK/NACK処理部250は、非圧縮パケットに引き続いて、ROHCによる圧縮パケットを受信した場合、当該圧縮パケットに対するNACKまたはSTATIC-NACKを返送する。これにより、ROHCによるヘッダ圧縮が中止され、データ送受信部220は、非圧縮パケットを連続して受信することができる。
　（２．２）eNB100A
　図３は、eNB100Aの機能ブロック構成図である。図３に示すように、eNB100Aは、無線通信部110、データ送受信部120、ヘッダ圧縮処理部130及びUE能力取得部140を備える。
　無線通信部110は、上述した無線通信部210と同様に、UE200とLTEに従った無線通信を実行する。
具体的には、無線通信部110は、UE200とDRB31（図１参照）を設定することができる。さらに、無線通信部110は、UE200とシグナリング用の無線ベアラ（SRB、不図示）を設定することができる。
　データ送受信部120は、上述したデータ送受信部220と同様に、ユーザデータを含むパケット、及び制御データを含むパケットを送受信する。
　また、データ送受信部120は、報知情報（MIB（Master Information Block）及びSIB（System Information Block））を送信する。さらに、データ送受信部120は、個別シグナリングによる情報、特に、本実施形態では、UE capability enquiry、或いはRRC Connection Reconfigurationを送信する。
　データ送受信部120は、eNB100AがAsymmetric ROHC（非対称ヘッダ圧縮）をサポートしていることを示すサポート通知をUE200に送信する。具体的には、データ送受信部120は、上述した報知情報、或いは個別シグナリングによって、当該サポート通知を送信する。
　ヘッダ圧縮処理部130は、上述したヘッダ圧縮処理部230と同様に、データ送受信部120が送受信するパケットのヘッダ圧縮処理を実行する。具体的には、ヘッダ圧縮処理部130は、UE能力取得部140によって取得されたUE200の能力情報に基づいて、ヘッダ圧縮処理を実行する。
　より具体的には、ヘッダ圧縮処理部130は、ROHCに従って、RTP/UDP/IPヘッダなどの圧縮（compress）及び伸張（decompress）を実行する。
　また、上述したように、eNB100A、つまり、ヘッダ圧縮処理部130は、Asymmetric ROHCをサポートしている。
　UE能力取得部140は、UE200の能力情報を取得する。具体的には、UE能力取得部140は、UE200から通知されたUE-EUTRA-Capabilityの内容に基づいて、UE200の各種能力を取得する。
　特に、本実施形態では、UE能力取得部140は、Symmetric ROHC及びAsymmetric ROHCについて、サポート可能なヘッダ圧縮のプロファイル（supportedROHC-Profiles）と、ヘッダ圧縮に用いることができるセッション数（maxNumberROHC-ContextSessions）を取得する。
　UE能力取得部140は、取得した当該情報をヘッダ圧縮処理部130などに提供する。
　（３）無線通信システムの動作
　次に、無線通信システム10の動作について説明する。具体的には、eNB100AとUE200とにおけるAsymmetric ROHCの適用動作について説明する。
　より具体的には、以下の３つの動作例について説明する。
　　(i)　UE200は、無線アクセスネットワーク20（eNB100A）がAsymmetric ROHCに対応している場合にのみ、Asymmetric ROHCの能力情報を通知する。
　　(ii)　UE200は、eNB100Aから送信されたROHCによる圧縮パケットに対してNACKを送信する。
　　(iii)　UE200は、Symmetric ROHC及びAsymmetric ROHCの両方の能力情報を送信する。
　（３．１）動作例１
　図５は、UE200の動作フロー図（動作例１）である。図５に示すように、UE200は、eNB100Aから、無線アクセスネットワーク20（eNB100A）がAsymmetric ROHCをサポートしていることを示すサポート通知を受信したか否かを判定する（S10）。これにより、UE200は、eNB100AがAsymmetric ROHCをサポートしていることを認識し得る。
　なお、eNB100Aは、Asymmetric ROHCをサポートしていることを直接的に示すのではなく、Asymmetric ROHCが導入されたRRC（Radio Resource Control）のバージョンに対応していることを示すサポート通知を送信してもよい。
　UE200は、当該サポート通知を受信した場合、Asymmetric ROHCの設定に用いる情報（ROHC Capability）をeNB100Aに通知する（S20）。
　具体的には、UE200は、ROHC Capabilityとして、サポート可能なヘッダ圧縮のプロファイル（supportedROHC-Profiles）、及びヘッダ圧縮に用いることができるセッション数（maxNumberROHC-ContextSessions）を含むUE200の能力情報（UE-EUTRA-Capability）をeNB100Aに通知する。
　図６（ａ）及び（ｂ）は、既存のSymmetric ROHCの内容を示すフィールド及びAsymmetric ROHCの内容を示すフィールドの構成例を示す。
　既存のSymmetric ROHCの内容を示すフィールド（Capability field(Conventional)）及びAsymmetric ROHCの内容を示すフィールド（Capability field(New)）は、UE200の能力情報（UE-EUTRA-Capability）に含まれる。
　図６（ａ）に示すように、eNB100Aは、Asymmetric ROHCのサポート通知をUE200に送信する。この場合、UE200は、Capability field(Conventionalを含めず、Capability field(Newのみを含む能力情報をeNB100Aに通知する。つまり、UE200は、Capability field(Conventionalを利用しない。
　一方、図６（ｂ）に示すように、eNB100Bは、Asymmetric ROHCをサポートしていないため、Asymmetric ROHCのサポート通知を送信しない。この場合、UE200は、Capability field(Conventional及びCapability field(Newの何れも利用せず、eNB100Bに送信しない。
　eNB100Bは、Capability field(Conventionalを含む能力情報も受信しないため、UE200が単にROHCをサポートしていないと判定し、ROHCによるヘッダ圧縮を実行しない。つまり、eNB100Bは、ROHCをサポートしていないUEとしてUE200を取り扱うことになる。
　図７（ａ）及び（ｂ）は、既存のSymmetric ROHCの内容を示すフィールドにAsymmetric ROHCをサポートすることを示す情報を含めた能力情報の構成例を示す。
　図７（ａ）及び（ｂ）に示す能力情報の構成例では、既存のSymmetric ROHCの内容を示すフィールド（Capability field）を流用し、eNBがAsymmetric ROHCをサポートしている場合にのみ、Asymmetric ROHCの内容を含める。
　図７（ａ）に示すように、eNB100Aは、Asymmetric ROHCのサポート通知をUE200に送信する。この場合、UE200は、既存のsupportedROHC-Profilesを流用して、Asymmetric ROHCのプロファイルを通知する。図７（ａ）では、Profile0x0001がTrueに設定されている。また、ヘッダ圧縮に用いることができるセッション数maxNumberROHC-ContextSessionsが2に設定されている。この数値は、ULに適用される当該セッション数のみを意味する。つまり、Asymmetric ROHC適用時の数値である。
　また、図７（ａ）に示すように、UE200は、既存のsupportedROHC-Profilesを流用して、Asymmetric ROHCをサポートしていることを通知する。図７（ａ）では、PDCP-parameters-14（Release-14用のPDCPパラメータ）として、Asymmetric ROHCがサポートされることが示されている。
　このようなCapability fieldを含む能力情報を受信したeNB100Aは、UE200がAsymmetric ROHCをサポートしていることを認識するとともに、maxNumberROHC-ContextSessionsの数値については、既存のSymmetric ROHCのようなUL及びDL両方向を含む数値ではなく、片方向（UL）のみに適用される数値に読み替える。
　一方、図７（ｂ）に示すように、eNB100Bは、Asymmetric ROHCをサポートしていないため、Asymmetric ROHCのサポート通知を送信しない。この場合、UE200は、Capability fieldを含む能力情報自体は送信するが、ROHCをサポートしていないことを示すsupportedROHC-Profilesを設定する。具体的には、図７（ｂ）では、Profile0x0001及びProfile0x0002の何れもがFalseに設定されている。
　このようなCapability fieldを含む能力情報を受信したeNB100Bは、UE200が単にROHCをサポートしていないと判定し、ROHCによるヘッダ圧縮を実行しない。
　（３．２）動作例２
　図８は、eNB100AとUE200とによるAsymmetric ROHCの適用動作シーケンス（動作例２）を示す。
　図８に示すように、eNB100Aは、UE200との通信を開始し、ROHCによるヘッダ圧縮が実行されていない、つまり、フルヘッダを含むIRパケットを所定数送信する（S110～S130）。
　なお、IRパケットとは、RFC3095において規定されているパケットの一種（Initiation and Refresh state）であり、Decompressor側において、ROHC Contextを確立するために用いられる。
　より具体的には、IRパケットでは、IPパケットは圧縮されずにフルヘッダで送信され、Decompressor側は、当該ヘッダの内容や変化パターンを基にコンテキストを確立することが可能である。なお、ROHCに必要なその他の情報（例えば、Context ID）は、ROHCヘッダを用いてさらに通知される。
　次いで、eNB100Aは、フルヘッダを含むIRパケットを所定数送信した後、ROHCによるヘッダ圧縮が実行されたUO-0パケット（圧縮パケット）を送信する（S140）。UO-0パケットもRFC3095において規定されている。
　UE200は、UO-0パケットを受信すると、UE200の受信方向、つまり、DL方向においてROHCを適用しないようにAsymmetric ROHCを適用することを決定する（S150）。すなわち、UE200は、UL方向のみにROHCを適用する。
　UE200は、DL方向においてROHCを適用しないようにするため、当該UO-0パケットを受信できなかったことを示すNACK（STATIC-NACK）をeNB100Aに返送する（S160）。
　当該NACKを受信したeNB100Aは、UE200が圧縮パケットを処理できないと判定する。そこで、eNB100Aは、圧縮パケットではなく、フルヘッダを含むIRパケット（非圧縮パケット）を送信する（S170, S180）。
　なお、eNB100Aは、IRパケットによって非圧縮パケットを送信してもよいし、当該パケット（IPフローデータ）をUncompressed sessionにのみ割り当ててもよい。
　図９は、UE200の動作フロー図（動作例２）である。具体的には、図９は、図８に示したS140の処理以降におけるUE200内部の動作フローを示す。
　図９に示すように、UE200は、ROHCによるヘッダ圧縮が実行された圧縮パケット（UO-0パケット）を受信したか否かを判定する（S210）。
　UE200は、圧縮パケットを受信した場合、DL方向においてROHCを適用しないAsymmetric ROHCを適用するか否かを判定する（S220）。なお、S220の処理は、S210の処理よりも前に予め実行されても構わない。
　UE200は、Asymmetric ROHCを適用しない場合、圧縮パケットのヘッダを伸張（Decompress）する（S230）。
　UE200は、Asymmetric ROHCを適用する場合、当該UO-0パケットを受信できなかったことを示すNACK（STATIC-NACK）をeNB100Aに返送する（S240）。
　UE200がNACKをeNB100Aに返送すると、図８に示したように、eNB100Aは、圧縮パケットではなく、フルヘッダを含むIRパケット（非圧縮パケット）を送信する。UE200は、当該非圧縮パケットを受信する（S250）。
　その後、UE200は、パケットの受信処理を実行する（S260）。具体的には、UE200は、ヘッダの内容に基づいてPDU/SDUを再構成し、上位レイヤに出力する。
　なお、UE200は、動作例２の場合においても、上述したように、Asymmetric ROHCに関するUE200の能力情報をeNB100Aに通知してもよい。
　動作例２において、UE200がUE200の能力情報をeNB100Aに通知した場合、eNB100Aは、UE200に対して不要な圧縮パケットを送信することを回避できる。一方、Asymmetric ROHCをサポートしていないeNB100Bは、当該NACKが返送されることによって、UE200のメモリが不足していると認識するに過ぎない。
　（３．３）動作例３
　動作例３では、上述したように、UE200は、Symmetric ROHC及びAsymmetric ROHCの両方の能力情報を送信する。以下、本動作例における基本動作フロー、Asymmetric ROHC適用の通知例及び変形例について説明する。
　（３．３．１）基本動作フロー
　図１０は、UE200の動作フロー図（動作例３）である。図１０に示すように、UE200は、Capability field(ConventionalをeNB100A（またはeNB100B）に通知する（S310）。Capability field(Conventionalは、動作例１において説明した内容（図６参照）と同様であるが、さらに後述する。
　また、UE200は、Capability field(NewをeNB100A（またはeNB100B）に通知する（S320）。Capability field(Newも動作例１において説明した内容（図６参照）と同様であるが、さらに後述する。
　なお、S310とS320とは、入れ替えても構わない。このように、UE200は、Asymmetric ROHCをサポートしていることを示すサポート通知を受信したか否かに関わらず、Capability field(Conventional、つまり、Symmetric ROHCの内容を示すフィールドと、Capability field(New、つまり、Asymmetric ROHCの内容を示すフィールドとを含む能力情報をeNB100Aに通知する。
　図１１（ａ）及び（ｂ）は、eNB100A及びeNB100BにおけるAsymmetric ROHCの適用動作フロー図である。具体的には、図１１（ａ）は、eNB100BにおけるAsymmetric ROHCの適用動作フローを示す。図１１（ｂ）は、eNB100AにおけるAsymmetric ROHCの適用動作フローを示す。
　図１１（ａ）に示すように、eNB100Bは、Capability field(Conventional及びCapability field(Newを含む能力情報を受信する（S410）。
　Asymmetric ROHCをサポートしていないeNB100Bは、Capability field(Conventionalに基づいて、ROHCによるヘッダ圧縮の要否について判定する（S420）。ここでは、ヘッダ圧縮が必要、つまり、ROHCを適用すると判定されたものとする。
　eNB100Bは、当該判定結果に基づいて、圧縮パケットをUE200に送信する（S430）。
　一方、図１１（ｂ）に示すように、eNB100Aも、Capability field(Conventional及びCapability field(Newを含む能力情報を受信する（S510）。
　Asymmetric ROHCをサポートしているeNB100Aは、Capability field(ConventionalまたはCapability field(Newの何れかに基づいて、ROHCによるヘッダ圧縮の要否について判定する（S520）。ここでは、Capability field(Newに基づいてヘッダ圧縮が不要、つまり、ROHCを適用しないと判定されたものとする。
　eNB100Aは、当該判定結果に基づいて、非圧縮パケットをUE200に送信する（S530）。
　このように、eNB100B（Asymmetric ROHC非サポート）は、既存のCapability field(Conventionalの内容を参照し、Symmetric ROHCを適用する。一方、eNB100A（Asymmetric ROHCサポート）は、Symmetric ROHCまたはAsymmetric ROHCの何れかを適用する。
　なお、UE200（ヘッダ圧縮処理部230）は、搭載するメモリの規模（maxNumberROHC-ContextSessionsに応じたメモリ数）に基づいて、Symmetric ROHC及びAsymmetric ROHCのそれぞれについて、ROHC CapabilityをeNB100A（eNB100B）に通知する。仮に、Symmetric ROHCに割り当てるメモリ数が不足する場合には、Asymmetric ROHCのみについて、ROHC Capabilityを通知してもよい。或いは、UE200は、ROHCに適用できるメモリ数や処理能力が不足する場合、上述した動作例２、つまり、適宜NACKを返送することによって、メモリ状況に応じてAsymmetric ROHC（またはSymmetric ROHC）を適用するようにしてもよい。
　（３．３．２）Asymmetric ROHC適用の通知例
　図１２（ａ）、（ｂ）及び（ｃ）は、UE-EUTRA-Capabilityに含まれるフィールド（Capability field）の構成例を示す。図１２（ａ）、（ｂ）及び（ｃ）に示すように、本動作例では、Capability field(Conventional及びCapability field(Newの両方を含むUE-EUTRA-Capabilityが通知される。
　図１２（ａ）は、Asymmetric ROHCの設定に必要な内容の全てをCapability field(Newを用いて通知する例を示す。図１２（ａ）に示すように、ULにおいてROHCが適用されること、Asymmetric ROHCのプロファイル（supportedROHC-Profiles）及びAsymmetric ROHCに用い得るセッション数（maxNumberROHC-ContextSessions）がCapability field(Newを用いて通知される。
　図１２（ｂ）及び（ｃ）は、Asymmetric ROHCに関する内容の一部をCapability field(Newを用いて通知する例を示す。
　具体的には、図１２（ｂ）に示すように、Asymmetric ROHCのプロファイル（supportedROHC-Profiles）が、Capability field(Conventionalを用いて通知され、Asymmetric ROHCに用い得るセッション数（maxNumberROHC-ContextSessions）が、Capability field(Newを用いて通知される。つまり、supportedROHC-Profilesについては、Symmetric ROHCのプロファイルを示すフィールドが共用される。
　図１２（ｃ）では、Asymmetric ROHCのプロファイル（supportedROHC-Profiles）及びAsymmetric ROHCに用い得るセッション数（maxNumberROHC-ContextSessions）が、Capability field(Conventionalを用いて通知される。つまり、supportedROHC-Profiles及びmaxNumberROHC-ContextSessionsについて、Symmetric ROHCの当該フィールドが共用される。
　この場合、Capability field(Newは、ULにおいてROHCが適用されることのみの通知（図１２（ｃ）のAsymROHC-UL）に用いられる。
　また、この場合、図１２（ｃ）に示す（Capability field(New下方の斜線部分参照）ように、既存領域の何倍（例えば、２倍）の領域（具体的には、セッション（メモリ）数）がAsymmetric ROHCとしてサポート可能などが、別途、3GPPの仕様で決定されてもよい。
　（３．３．３）変形例
　次に、本動作例の変形例について説明する。Asymmetric ROHCの適用可否、及びROHC用のセッション数（メモリ数）は、ベアラ（DRB）毎に設定することが可能である。しかしながら、本動作例のように、Symmetric ROHC及びAsymmetric ROHCのROHC Capabilityが別個に通知される場合、例えば、特に、eNB100AとUE200との間に複数のDRBが設定されていると、eNB100Aは、Symmetric ROHC及びAsymmetric ROHCをどのように各DRBに設定するかを判定することができない。
　この結果、eNB100Aは、UE200の能力（搭載されているメモリ数）を最大限活用したROHCの利点（伝送効率化）を得ることが難しくなる。
　図１３（ａ）～（ｄ）は、Symmetric ROHC及びAsymmetric ROHCが混在し得る場合におけるROHCの設定例を示す。
　図１３（ａ）に示すように、ここでは、eNB100AとUE200との間に２本のDRB（#1, #2）が設定されている。また、UE200は、#1～5までの５つのROHC用のメモリを搭載しているものとする。
　この場合、DRB毎のSymmetric ROHC及びAsymmetric ROHCの設定例としては、例えば、図１３（ｂ）～（ｄ）に示すようなパタンが挙げられる。図１３（ｂ）では、１セッション分のSymmetric ROHCが各DRBに設定される。この結果、UE200の４メモリ（(UL用1+DL用1)×2）を消費する。
　図１３（ｃ）では、３セッション分のAsymmetric ROHCがDRB#1に設定され、２セッション分のAsymmetric ROHCがDRB#2に設定される。この結果、UE200の５メモリ（UL用3+UL用2）を消費する。
　図１３（ｄ）では、１セッション分のSymmetric ROHCがDRB#1に設定され、３セッション分のAsymmetric ROHCがDRB#2に設定される。この結果、UE200の５メモリ（UL用1+DL用1)+UL用3）を消費する。
　このように、複数のDRBが設定され、Symmetric ROHC及びAsymmetric ROHCが混在し得る場合、様々な割り当てパタンが存在する。そこで、eNB100Aは、UE200内部において対応可能なメモリの割り当てパタンを予め認識しておき、当該割り当てパタンに基づいて、Symmetric ROHC及びAsymmetric ROHCを設定してもよい。
　この場合、UE200は、対応可能なメモリの割り当てパタンを指定し、指定した割り当てパタンをeNB100Aに予め通知する。図１４は、Symmetric ROHC及びAsymmetric ROHCが混在する場合において、UE200が指定する割り当てパタン例を示す。
　図１４に示すように、UE200が搭載するメモリ数（ここでは、５メモリ）に応じて、対応可能な割り当てパタンが指定される。なお、割り当てパタンは、設定されるDRB数を考慮して決定されてもよい。
　また、当該割り当てパタンは、各パタンの優先度を含んでもよい。当該優先度は、通信実行中（具体的には、RRC-CONNECTED状態）に変更されてもよい。さらに、通信実行中に当該優先度が変更された場合、UE200は、当該優先度を変更したことを、RRC/PDCP/RLC/MACレイヤの何れかのメッセージによって通知すればよい。
　eNB100Aは、通知された内容に基づいて、UE200の能力（メモリ数）を超過しないように、Symmetric ROHC及びAsymmetric ROHCの少なくとも何れかを設定する。また、eNB100Aは、通知された内容に基づいて、割り当てパタンの内容（優先度）を更新してもよい。
　図１５（ａ）、（ｂ）及び（ｃ）は、Symmetric ROHC及びAsymmetric ROHCが混在する場合における割り当てパタンの通知例を示す。
　図１５（ａ）に示すように、Symmetric ROHC及びAsymmetric ROHCが混在する場合、Symmetric ROHCのROHC Capabilityと、Asymmetric ROHCのROHC Capabilityとによって構成される複数のリスト（図１５（ａ）の外枠は、各リストを示す）によって、割り当てパタンを通知してもよい。
　或いは、図１５（ｂ）に示すように、UE200が割り当て可能な最大のメモリ数、つまり、maxNumberROHC-ContextSessionsと、Symmetric ROHCまたはAsymmetric ROHCの何れかのROHC Capabilityとを含む割り当てパタンを通知してもよい。この場合、通知されないROHCの割り当て（図１５（ｂ）では、Symmetric ROHC）については、最大のメモリ数（１５）とAsymmetric ROHCの割り当て数とによって暗黙的に示すことが可能である。
　さらに、図１５（ｃ）に示すように、3GPPの仕様において割り当てパタンが規定されており、当該割り当てパタンを識別するインデックスのみを通知してもよい。或いは、各インデックスについて、True（対応可）またはFalse（対応不可）を示してもよい。
　（４）作用・効果
　上述した実施形態によれば、以下の作用効果が得られる。具体的には、上述した動作例１によれば、eNBからAsymmetric ROHCのサポート通知を受信した場合、UE200は、Asymmetric ROHCのプロファイルをUE200の能力情報（UE-EUTRA-Capability）に含めることによって、Asymmetric ROHCの設定に用いる情報をeNB100Aに通知する。一方、Asymmetric ROHCをサポートしていないeNB100Bに対しては、Asymmetric ROHCのプロファイルは通知されない。このため、eNB100Bは、ROHCをサポートしていないUEとしてUE200を取り扱い、DL方向において、ROHCによるヘッダ圧縮を実行しない。
　また、動作例１によれば、UE200は、Symmetric ROHCの内容を示すフィールドと、Symmetric ROHCの内容を示すフィールドとは別個であるAsymmetric ROHCの内容を示すフィールドとを含む能力情報をeNB100A（eNB100B）に通知することができる。さらに、動作例１によれば、UE200は、Symmetric ROHCの内容を示すフィールドに、Asymmetric ROHCをサポートすることを示す情報を含めた能力情報をeNB100A（eNB100B）に通知することもできる。
　このため、eNB100B（Asymmetric ROHC非サポート）によるROHC設定に悪影響を与えることなく、Asymmetric ROHCの設定に必要な情報をeNB100A（Asymmetric ROHCサポート）に通知できる。これにより、eNB100B（Asymmetric ROHC非サポート）とのバックワードコンパチビリティーを確保しつつ、Asymmetric ROHCを導入できる。
　上述した動作例２によれば、UE200は、非圧縮パケットに続けて、ROHCによる圧縮パケットを受信した場合、当該圧縮パケットを受信できなかったことを示すNACK（否定応答）をeNB100Aに送信する。このため、eNB100Aによる圧縮パケットの送信が中止され、非圧縮パケットが送信される。これにより、UE200の受信方向（つまり、DL方向）においてROHCを適用しないAsymmetric ROHCを設定することができる。
　一方、Asymmetric ROHCをサポートしていないeNB100Bは、当該NACKが返送されることによって、UE200のメモリが不足していると認識するに過ぎない。この結果、eNB100Bとのパケット送受信では、ROHCが適用されない。
　これにより、eNB100B（Asymmetric ROHC非サポート）とのバックワードコンパチビリティーを確保しつつ、Asymmetric ROHCを導入できる。
　また、動作例２では、動作例１と同様に、UE200がUE200の能力情報をeNB100Aに通知してもよい。この場合、eNB100Aは、UE200に対して不要な圧縮パケットを送信することを回避できる。
　上述した動作例３によれば、UE200は、Symmetric ROHCの内容を示すフィールドと、Symmetric ROHCの内容を示すフィールドとは別個であるAsymmetric ROHCの内容を示すフィールドとを含む能力情報をeNB100Aに通知する。このため、UE200は、eNB100A（Asymmetric ROHCサポート）及びeNB100B（Asymmetric ROHC非サポート）の両方が認識可能なROHC Capabilityを通知することができる。これにより、eNB100B（Asymmetric ROHC非サポート）とのバックワードコンパチビリティーを確保しつつ、Asymmetric ROHCを導入できる。
　また、動作例３では、少なくともAsymmetric ROHCのプロファイルについて、Symmetric ROHCのプロファイルを示すフィールドを共用することができる。このため、Asymmetric ROHCの設定に必要な情報量を抑制しつつ、Asymmetric ROHCを導入できる。
　すなわち、上述した実施形態によれば、Asymmetric ROHCをサポートするeNB100Aと、既存のSymmetric ROHCのみをサポートするeNB100Bとが混在する場合でも、適切にAsymmetric ROHCを設定することができる。
　さらに、Asymmetric ROHCの設定に必要な情報をeNB100Aに通知することによって、UE200が搭載するROHC用メモリを最大限に活用したAsymmetric ROHCによるヘッダ圧縮を実現し得る。
　（５）その他の実施形態
　以上、実施形態に沿って本発明の内容を説明したが、本発明はこれらの記載に限定されるものではなく、種々の変形及び改良が可能であることは、当業者には自明である。
　例えば、上述したAsymmetric ROHCに関するROHC Capabilityは、TCP ACK less機能のCapabilityとして流用されてもよい。TCP ACK less機能とは、TCPレイヤにおける肯定応答（TCP ACK）送信に必要となる無線帯域削減を図るものである。
　具体的には、パケットの受信側は、TCP ACKを送信せずに破棄する。パケットの送信側は、PDCP SDU（IPパケット）に対するレイヤ２でのACK（例えば、RLC-ACK）を受信した場合、TCP ACKを自身で生成して上位レイヤへ送信する。
　つまり、TCPによるトラフィックフローを用いて、DLにおけるピークスループットを達成するためには、TCP ACK送信のためのUL帯域をも確保する必要が生じるが、TDDシステムでは、DL/ULの無線リソースの非対称性（DL帯域がUL帯域よりも広帯域）に起因する制限が生じ得る。
　この問題を解決するためTCP ACK less機能が提案されている。Asymmetric ROHC及びTCP ACK less機能のCapabilityを合わせて適用することによって、DL/ULへの無線リソース配分を、さらにDL優先とすることが可能となり、Asymmetric ROHC及びTCP ACK less機能の組み合わせは、DL/UL帯域のさらに効率的な利用の観点からも非常に効果的である。
　また、TCP ACK less機能は、PDCP SDUの内容を意識する必要があるが、ROHCでは既にPDCP SDUの内容を把握する機構が存在しているため、TCP-ACK less機能と共通化できる部分もあり、UE200及びeNB100Aの実装の観点からもメリットがある。
　また、上述した実施形態では、ヘッダ圧縮のプロトコルとしてROHCが用いられていたが、必ずしもROHCに限定されるものではない。つまり、ROHCと同様のヘッダ圧縮機能を有するプロトコルであれば、ROHC以外でも構わない。
　上述した実施形態では、DL方向においてROHCが適用されず、UL方向のみにROHCが適用される例について説明したが、UE200が送受信するデータの特性などによっては、UL方向においてROHCが適用されず、DL方向のみにROHCが適用されてもよい。
　さらに、上述した実施形態では、UE200がAsymmetric ROHCに関する能力をeNB100A（eNB100B）に通知していたが、eNB100A（eNB100B）が、同様の機能を備えてもよい。つまり、eNB100A（eNB100B）が、Asymmetric ROHCに関する能力をUE200に通知し、UE200が、通知された能力に基づいてAsymmetric ROHCを設定してもよい。
　また、上述した実施形態の説明に用いたブロック図（図２，３）は、機能ブロック図を示している。これらの機能ブロック（構成部）は、ハードウェア及び／またはソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／または論理的に結合した１つの装置により実現されてもよいし、物理的及び／または論理的に分離した２つ以上の装置を直接的及び／または間接的に（例えば、有線及び／または無線）で接続し、これら複数の装置により実現されてもよい。
　さらに、上述したeNB100A, 100B、及びUE200（当該装置）は、本発明の送信電力制御の処理を行うコンピュータとして機能してもよい。図１６は、当該装置のハードウェア構成の一例を示す図である。図１６に示すように、当該装置は、プロセッサ1001、メモリ1002、ストレージ1003、通信装置1004、入力装置1005、出力装置1006及びバス1007などを含むコンピュータ装置として構成されてもよい。
　当該装置の各機能ブロック（図２，３参照）は、当該コンピュータ装置の何れかのハードウェア要素、または当該ハードウェア要素の組み合わせによって実現される。
　プロセッサ1001は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ1001は、周辺装置とのインタフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（CPU）で構成されてもよい。
　メモリ1002は、コンピュータ読み取り可能な記録媒体であり、例えば、ROM（Read Only Memory）、EPROM（Erasable Programmable ROM）、EEPROM（Electrically Erasable Programmable ROM）、RAM（Random Access Memory）などの少なくとも１つで構成されてもよい。メモリ1002は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ1002は、上述した実施形態に係る方法を実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。
　ストレージ1003は、コンピュータ読み取り可能な記録媒体であり、例えば、CD-ROM（Compact Disc ROM）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Blu-ray（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ1003は、補助記憶装置と呼ばれてもよい。上述の記録媒体は、例えば、メモリ1002及び／またはストレージ1003を含むデータベース、サーバその他の適切な媒体であってもよい。
　通信装置1004は、有線及び／または無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。
　入力装置1005は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置1006は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置1005及び出力装置1006は、一体となった構成（例えば、タッチパネル）であってもよい。
　また、プロセッサ1001及びメモリ1002などの各装置は、情報を通信するためのバス1007で接続される。バス1007は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。
　また、情報の通知は、上述した実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、DCI（Downlink Control Information）、UCI（Uplink Control Information））、上位レイヤシグナリング（例えば、RRCシグナリング、MAC（Medium Access Control）シグナリング、報知情報（MIB（Master Information Block）、SIB（System Information Block））、その他の信号またはこれらの組み合わせによって実施されてもよい。また、RRCシグナリングは、RRCメッセージと呼ばれてもよく、例えば、RRC Connection Setupメッセージ、RRC Connection Reconfigurationメッセージなどであってもよい。
　さらに、入出力された情報は、特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報は、上書き、更新、または追記され得る。出力された情報は削除されてもよい。入力された情報は他の装置へ送信されてもよい。
　上述した実施形態におけるシーケンス及びフローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。
　また、上述した実施形態において、eNB100A（eNB100B、以下同）によって行われるとした特定動作は、他のネットワークノード（装置）によって行われることもある。また、複数の他のネットワークノードの組み合わせによってeNB100Aの機能が提供されても構わない。
　なお、本明細書で説明した用語及び／または本明細書の理解に必要な用語については、同一のまたは類似する意味を有する用語と置き換えてもよい。例えば、該当する記載がある場合、チャネル及び／またはシンボルは信号（シグナル）であってもよい。また、信号はメッセージであってもよい。また、「システム」及び「ネットワーク」という用語は、互換的に使用されてもよい。
　さらに、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。例えば、無線リソースはインデックスで指示されるものであってもよい。
　eNB100A（基地局）は、１つまたは複数（例えば、３つ）のセル（セクタとも呼ばれる）を収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局RRH：Remote Radio Head）によって通信サービスを提供することもできる。
　「セル」または「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局、及び／または基地局サブシステムのカバレッジエリアの一部または全体を指す。さらに、「基地局」「eNB」、「セル」、及び「セクタ」という用語は、本明細書では互換的に使用され得る。基地局は、固定局（fixed station）、NodeB、eNodeB（eNB）、アクセスポイント（access point）、フェムトセル、スモールセルなどの用語で呼ばれる場合もある。
　UE200は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。
　本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
　また、「含む（including）」、「含んでいる（comprising）」、及びそれらの変形の用語は、「備える」と同様に、包括的であることが意図される。さらに、本明細書或いは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。
　本明細書で使用した「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量または順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、または何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。
　本明細書の全体において、例えば、英語でのa, an, 及びtheのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
　上記のように、本発明の実施形態を記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。
　上述したように、本発明によれば、上りリンクまたは下りリンクの何れか一方にROHCによるヘッダ圧縮が適用される非対称ヘッダ圧縮をサポートする無線基地局と、既存の対称ヘッダ圧縮のみをサポートする無線基地局とが混在する場合でも、適切に非対称ヘッダ圧縮を設定することができる。
　10　無線通信システム
　20　無線アクセスネットワーク
　31, 32　DRB
　100A, 100B　eNB
　110　無線通信部
　120　データ送受信部
　130　ヘッダ圧縮処理部
　140　UE能力取得部
　200　UE
　210　無線通信部
　220　データ送受信部
　230　ヘッダ圧縮処理部
　240　能力通知部
　250　ACK/NACK処理部
　1001　プロセッサ
　1002　メモリ
　1003　ストレージ
　1004　通信装置
　1005　入力装置
　1006　出力装置
　1007　バス

Claims (10)

  1. 　上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置であって、
    　対向無線通信装置から、前記非対称ヘッダ圧縮をサポートしていることを示すサポート通知を受信するサポート通知受信部と、
    　前記サポート通知受信部が前記サポート通知を受信した場合、前記非対称ヘッダ圧縮のプロファイルを無線通信装置の能力情報に含めることによって、前記非対称ヘッダ圧縮の設定に用いる情報を前記対向無線通信装置に通知する能力通知部と
    を備える無線通信装置。
  2. 　前記能力通知部は、前記上りリンク及び前記下りリンクの両方に前記ヘッダ圧縮を適用する対称ヘッダ圧縮の内容を示すフィールドと、前記対称ヘッダ圧縮の内容を示すフィールドとは別個である前記非対称ヘッダ圧縮の内容を示すフィールドとを含む前記能力情報を前記対向無線通信装置に通知する請求項１に記載の無線通信装置。
  3. 　前記能力通知部は、前記上りリンク及び前記下りリンクの両方に前記ヘッダ圧縮を適用する対称ヘッダ圧縮の内容を示すフィールドに、前記非対称ヘッダ圧縮をサポートすることを示す情報を含めた前記能力情報を前記対向無線通信装置に通知する請求項１に記載の無線通信装置。
  4. 　上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置であって、
    　前記ヘッダ圧縮が適用された圧縮パケットを受信するパケット受信部と、
    　前記パケット受信部が前記圧縮パケットを受信した場合、前記無線通信装置の受信方向において前記ヘッダ圧縮を適用しない前記非対称ヘッダ圧縮を適用するため、前記圧縮パケットを受信できなかったことを示す否定応答を対向無線通信装置に送信する否定応答送信部と
    を備える無線通信装置。
  5. 　前記非対称ヘッダ圧縮のプロファイルを無線通信装置の能力情報に含めることによって、前記非対称ヘッダ圧縮の設定に用いる情報を前記対向無線通信装置に通知する能力通知部を備える請求項４に記載の無線通信装置。
  6. 　上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置であって、
    　前記無線通信装置の能力情報を対向無線通信装置に通知する能力通知部を備え、
    　前記能力通知部は、前記上りリンク及び前記下りリンクの両方に前記ヘッダ圧縮を適用する対称ヘッダ圧縮の内容を示すフィールドと、前記対称ヘッダ圧縮の内容を示すフィールドとは別個である前記非対称ヘッダ圧縮の内容を示すフィールドとを含む前記能力情報を通知する無線通信装置。
  7. 　前記非対称ヘッダ圧縮の内容を示すフィールド、及び前記対称ヘッダ圧縮の内容を示すフィールドは、サポート可能な前記ヘッダ圧縮のプロファイルと、前記ヘッダ圧縮に用いることができるセッション数と含み、
    　前記能力通知部は、少なくとも前記非対称ヘッダ圧縮のプロファイルについて、前記対称ヘッダ圧縮のプロファイルを示すフィールドを共用する請求項６に記載の無線通信装置。
  8. 　上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置における無線通信方法であって、
    　対向無線通信装置から、前記非対称ヘッダ圧縮をサポートしていることを示すサポート通知を受信するステップと、
    　前記サポート通知を受信した場合、前記非対称ヘッダ圧縮のプロファイルを無線通信装置の能力情報に含めることによって、前記非対称ヘッダ圧縮の設定に用いる情報を前記対向無線通信装置に通知するステップと
    を含む無線通信方法。
  9. 　上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置における無線通信方法であって、
    　前記ヘッダ圧縮が適用された圧縮パケットを受信するステップと、
    　前記圧縮パケットを受信した場合、前記無線通信装置の受信方向において前記非対称ヘッダ圧縮を適用するため、前記圧縮パケットを受信できなかったことを示す否定応答を対向無線通信装置に送信するステップと
    を含む無線通信方法。
  10. 　上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置における無線通信方法であって、
    　前記上りリンク及び前記下りリンクの両方に前記ヘッダ圧縮を適用する対称ヘッダ圧縮の内容を示すフィールドと、前記対称ヘッダ圧縮の内容を示すフィールドとは別個である前記非対称ヘッダ圧縮の内容を示すフィールドとを、前記無線通信装置の能力情報に含めるステップと、
    　前記能力情報を対向無線通信装置に通知するステップと
    を含む無線通信方法。
PCT/JP2017/010280 2017-03-14 2017-03-14 無線通信装置及び無線通信方法 WO2018167858A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP17900550.9A EP3598793A4 (en) 2017-03-14 2017-03-14 WIRELESS COMMUNICATION DEVICE AND WIRELESS COMMUNICATION METHOD
JP2019505574A JP7149258B2 (ja) 2017-03-14 2017-03-14 無線通信装置及び無線通信方法
PCT/JP2017/010280 WO2018167858A1 (ja) 2017-03-14 2017-03-14 無線通信装置及び無線通信方法
CN201780088301.6A CN110402596B (zh) 2017-03-14 2017-03-14 无线通信装置及无线通信方法
US16/493,406 US11246058B2 (en) 2017-03-14 2017-03-14 Radio communication device and radio communication method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/010280 WO2018167858A1 (ja) 2017-03-14 2017-03-14 無線通信装置及び無線通信方法

Publications (1)

Publication Number Publication Date
WO2018167858A1 true WO2018167858A1 (ja) 2018-09-20

Family

ID=63522298

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/010280 WO2018167858A1 (ja) 2017-03-14 2017-03-14 無線通信装置及び無線通信方法

Country Status (5)

Country Link
US (1) US11246058B2 (ja)
EP (1) EP3598793A4 (ja)
JP (1) JP7149258B2 (ja)
CN (1) CN110402596B (ja)
WO (1) WO2018167858A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020147436A1 (zh) * 2019-01-16 2020-07-23 维沃移动通信有限公司 上报能力信息的方法、设备及系统
CN113615242A (zh) * 2019-03-28 2021-11-05 株式会社Ntt都科摩 无线基站和用户装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020222436A1 (en) * 2019-04-30 2020-11-05 Lg Electronics Inc. Method and apparatus for transmitting packets based on receiving a handover command in wireless communication system
US11523301B2 (en) * 2020-04-20 2022-12-06 Qualcomm Incorporated Physical uplink control channel with buffer status report
US11758513B2 (en) * 2020-04-20 2023-09-12 Qualcomm Incorporated Physical uplink control channel with uplink message short data field

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000196668A (ja) * 1998-12-25 2000-07-14 Toshiba Corp ル―タ装置、無線端末及び無線通信システム並びに通信方法
JP2009267843A (ja) * 2008-04-25 2009-11-12 Kyocera Corp 無線通信システム、無線基地局および無線通信方法
JP2014525698A (ja) * 2011-08-12 2014-09-29 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ユーザ装置、ネットワークノード、その中の第２のネットワークノード、および方法
JP2015012403A (ja) * 2013-06-27 2015-01-19 京セラ株式会社 移動通信システム及びユーザ端末

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100884956B1 (ko) * 2002-08-14 2009-02-23 엘지전자 주식회사 비대칭 양방향 패킷데이터 송수신 방법 및 시스템
US20040120357A1 (en) * 2002-12-23 2004-06-24 Sami Kekki On-demand header compression
US8406212B2 (en) * 2006-02-22 2013-03-26 Apple Inc. Service flow with robust header compression (ROHC) in a WiMAX wireless network
US8559463B2 (en) * 2008-02-20 2013-10-15 General Dynamics C4 Systems, Inc. Systems and methods for providing efficient bandwidth utilization in packet switched networks
US20100260109A1 (en) * 2009-04-10 2010-10-14 Qualcomm Incorporated Optimized inter-access point packet routing for ip relay nodes
JP4704482B2 (ja) * 2009-06-08 2011-06-15 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム、リレーノード、無線基地局及びゲートウェイ装置
CN101998511B (zh) * 2009-08-26 2013-04-24 华为技术有限公司 网络中继场景下的头压缩方法及装置
CN104067667A (zh) * 2012-01-23 2014-09-24 英特尔公司 用于集成的多rat异类网络的网络辅助的用户关联和卸载技术
JP6174343B2 (ja) * 2013-03-15 2017-08-02 株式会社Ｎｔｔドコモ ネットワーク装置及び移動局
WO2015163625A1 (en) * 2014-04-24 2015-10-29 Lg Electronics Inc. Method for establishing layer-2 entities for d2d communication system and device therefor
KR101835340B1 (ko) * 2014-04-30 2018-03-07 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
JP2016046652A (ja) 2014-08-21 2016-04-04 株式会社Ｎｔｔドコモ 通信装置
US10341466B2 (en) * 2014-11-14 2019-07-02 Qualcomm Incorporated Evolved data compression scheme signaling
KR102254396B1 (ko) 2014-12-17 2021-05-24 삼성전자주식회사 통신 시스템에서 단말의 헤더 압축 기능을 제어하는 방법 및 장치
US20170257796A1 (en) * 2016-03-07 2017-09-07 Mediatek Inc. Selective Uplink Only Header Compression Mechanism
US10623989B2 (en) * 2016-10-27 2020-04-14 Qualcomm Incorporated Techniques and apparatuses for unidirectional robust header compression
CN108023623B (zh) * 2016-11-04 2022-05-27 维沃移动通信有限公司 一种终端信息上报、获取方法、终端及基站
US20180242192A1 (en) * 2017-02-23 2018-08-23 Apple Inc. Dynamic Header Compression for Uplink Data for Improving Uplink Link Budget

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000196668A (ja) * 1998-12-25 2000-07-14 Toshiba Corp ル―タ装置、無線端末及び無線通信システム並びに通信方法
JP2009267843A (ja) * 2008-04-25 2009-11-12 Kyocera Corp 無線通信システム、無線基地局および無線通信方法
JP2014525698A (ja) * 2011-08-12 2014-09-29 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ユーザ装置、ネットワークノード、その中の第２のネットワークノード、および方法
JP2015012403A (ja) * 2013-06-27 2015-01-19 京セラ株式会社 移動通信システム及びユーザ端末

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"RoHC Symmetric DL/UL Parameters Limitation in LTE", 3GPP TSG-RAN WG2 #97, R2-1701761, February 2017 (2017-02-01)
APPLE: "Enable eNB to configure ROHC for uplink or Downlink channels in same PDCP entity", 3GPP TSG-RAN WG2 R2-1701763, 4 February 2017 (2017-02-04), XP051223664, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_97/Docs/R2-1701763.zip> *
See also references of EP3598793A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020147436A1 (zh) * 2019-01-16 2020-07-23 维沃移动通信有限公司 上报能力信息的方法、设备及系统
CN113615242A (zh) * 2019-03-28 2021-11-05 株式会社Ntt都科摩 无线基站和用户装置

Also Published As

Publication number Publication date
CN110402596B (zh) 2023-04-28
US20200022023A1 (en) 2020-01-16
JPWO2018167858A1 (ja) 2020-01-23
US11246058B2 (en) 2022-02-08
CN110402596A (zh) 2019-11-01
EP3598793A1 (en) 2020-01-22
EP3598793A4 (en) 2020-09-23
JP7149258B2 (ja) 2022-10-06

Similar Documents

Publication Publication Date Title
US9420533B2 (en) Discontinuous reception
WO2018167858A1 (ja) 無線通信装置及び無線通信方法
US20150109965A1 (en) User equipment (ue) supporting packet-switched emergency calls over ip multimedia subsystem (ims)
WO2017169835A1 (ja) ユーザ装置及び送信方法
JP2011515928A (ja) Ｐｄｃｐ状態報告の送信方法
US10111210B2 (en) Method for implementing radio resource control protocol function, macro base station, and micro cell node
CN104837163A (zh) 用于删除无线链路控制服务数据单元的方法和基站
WO2022052851A1 (zh) 一种服务质量QoS的监测方法
WO2018127219A1 (zh) 一种减少中断时延的方法、装置及用户设备
CN118199970A (zh) 下一代移动通信系统中标识安全密钥的方法和装置
JP7645333B2 (ja) 端末装置、通信方法、および基地局装置
US20250015932A1 (en) Data packet processing method and apparatus
EP3955637B1 (en) Data processing method, communication apparatus, and system
US10172036B2 (en) User equipment, base station, and communication method
WO2014175090A1 (ja) 無線通信装置、プロセッサ、及び通信制御方法
US10171544B2 (en) Radio base station
CN112368976A (zh) 用于执行组通信的终端和方法
KR102465999B1 (ko) 공공 안전 모드를 위한 사용자 단말기의 동작 방법 및 이를 이용한 무선 통신 방법
CN112740731B (zh) 下一代移动通信系统中标识安全密钥的方法和装置
JP2020077928A (ja) 端末装置、基地局装置、方法、および、集積回路
CN113767671B (zh) 下一代移动通信系统中用于无数据发送和接收中断的切换的方法和设备
WO2018132232A1 (en) Robust header compression (rohc) techniques for a dynamically changing extension bit
CN113678501B (zh) 一种以太网数据包头压缩方法、处理方法及其装置
US20250324316A1 (en) Communication method, communication device, and computer-readable storage medium
JP2018056856A (ja) ユーザ装置、基地局及び通信方法

Legal Events

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

Ref document number: 17900550

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019505574

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017900550

Country of ref document: EP

Effective date: 20191014