CN112351459A

CN112351459A - Execution method of transmitting end/receiving end of PDCP entity, PDCP entity and communication equipment

Info

Publication number: CN112351459A
Application number: CN201910738798.2A
Authority: CN
Inventors: 肖芳英; 刘仁茂
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2019-08-09
Filing date: 2019-08-09
Publication date: 2021-02-09
Also published as: WO2021027685A1

Abstract

The present disclosure provides a method for executing a sending end/a receiving end of a PDCP entity, the PDCP entity and a communication device, the method comprising: sending a first packet data convergence protocol data unit (PDCP PDU) carrying context information for establishing; under the condition of receiving an indication from a lower layer that the delivery of the first PDCP PDU is successful, carrying out Ethernet Header Compression (EHC) on a first packet data convergence protocol service data unit, namely a first PDCP SDU, or a first Ethernet frame, or a first Ethernet message, which belongs to the same flow as the first PDCP PDU; and sending a second PDCP PDU with the load of the second PDCP SDU, the second Ethernet frame or the second Ethernet message after the EHC.

Description

Execution method of transmitting end/receiving end of PDCP entity, PDCP entity and communication equipment

Technical Field

The present disclosure relates to the field of wireless communication technologies, and in particular, to an execution method for a sending end/a receiving end of a PDCP entity, the PDCP entity, and a communication device.

Background

In 3.2019, a work Project supporting the Internet of Things of the NR industry was approved on the 3rd Generation Partnership Project (3 GPP) RAN #83 symposium (see RP-190728: New WID: Support of NR Industrial Internet of Things (IoT)). One of the goals of this work project is to define an ethernet header compression protocol based on a structure-aware (structure-aware) algorithm. Ethernet header compression is a method to reduce the overhead associated with ethernet header transport, and ethernet frames can be transported in ethernet PDU session types over a 5G system. In the industrial internet of things network based on the Ethernet, the size of the effective load is relatively small relative to the whole size of the frame, so that the transmission efficiency can be improved and the delay can be reduced by compressing the header of the Ethernet frame.

This was achieved over 3GPP RAN2#105bis conferences held in 4 months in 2019: the Ethernet Header Compression (EHC) mechanism will be defined at 3GPP for 100%. This was achieved over 3GPP RAN2#106 conferences held in 5 months in 2019: respectively and independently configuring an Ethernet header compression protocol for the uplink and the downlink of each data radio bearer DRB; the compression end (Compressor) and the decompression end (Decompressor) adopt the concept of Context identification (Context ID) to associate one Context identification with Ethernet header contents (Ethernet header contents); and EHC is based on the following mechanisms: for the Ethernet flow generating new context, the compression end at least sends a message/frame containing a complete header and a context identifier so as to be convenient for the decompression end to establish the context, and then the compression end transmits the compressed message/frame; the header of the data packet generated by Ethernet header compression at least comprises the following fields: a context identifier, which is an indication identifier for indicating the header format of the present data packet (i.e. indicating whether the header of the present data packet is a full header or a compressed header). In addition, whether the EHC decompression side needs feedback (feedback) after receiving the PDCP PDU for establishing the context is discussed on 3GPP RAN2#106 conference, but no agreed conclusion is reached.

Based on the above conclusions, the present disclosure discusses related problems and solutions involved in ethernet header compression, which specifically include: when a sending end (or an EHC compressing end) of a PDCP entity adopts an EHC mechanism to compress a header, after sending a PDCP PDU used for establishing a context, how to determine whether to send a compressed packet; when the receiving end of the PDCP entity transmits feedback after receiving the PDCP PDU for establishing or updating the context information? How to decompress PDCP PDUs carrying compressed messages/frames with sequence numbers (or COUNTs) less than the sequence numbers (or COUNTs) of PDCP PDUs updated with context information?

Disclosure of Invention

In order to solve at least part of the above problems, the present disclosure provides an implementation method of a PDCP entity transmitting/receiving end, a PDCP entity, and a communication device.

The execution method of the PDCP entity transmitting end according to the first aspect of the present disclosure includes: sending a first packet data convergence protocol data unit (PDCP PDU) carrying context information for establishing; under the condition of receiving an indication from a lower layer that the delivery of the first PDCP PDU is successful, carrying out Ethernet Header Compression (EHC) on a first packet data convergence protocol service data unit, namely a first PDCP SDU, or a first Ethernet frame, or a first Ethernet message, which belongs to the same flow as the first PDCP PDU; and sending a second PDCP PDU with the load of the second PDCP SDU, the second Ethernet frame or the second Ethernet message after the EHC.

According to the method of the first aspect of the present disclosure, the performing ethernet header compression EHC includes: judging whether the first PDCP SDU, the first Ethernet frame or the Ethernet header or header compressible field of the first Ethernet message is mapped or distributed with a context identification CID; under the condition that the CID is mapped or allocated, judging whether confirmation that the context corresponding to the CID is established is received; and performing the EHC on the first PDCP SDU, the first Ethernet frame or the first Ethernet message under the condition that the confirmation is received.

According to the method of the first aspect of the present disclosure, the EHC is not performed in a case where it is determined that the CID is mapped or allocated but the acknowledgement is not received.

According to the method of the first aspect of the present disclosure, the determining whether the confirmation that the context corresponding to the CID is established is received includes: and judging whether positive feedback or negative feedback of the CID is received or not, and judging whether an indication that the first PDCP PDU delivery is successful is received or not from a lower layer.

According to the execution method of the PDCP entity receiving end of the second aspect of the present disclosure, when a new packet data convergence protocol data unit PDCP PDU or packet data convergence protocol service data unit PDCP SDU for establishing context information is received, a corresponding ethernet header compression EHC feedback is triggered or generated, where the EHC feedback includes a context identifier CID carried or associated in the PDCP PDU or the PDCP SDU and/or a sequence number or COUNT of the PDCP PDU or PDCP SDU.

According to the method of the second aspect of the present disclosure, a variable CID _ Flag for storing a sequence number or COUNT of the currently received PDCP PDU or PDCP SDU for establishing context information is defined for each said CID or each CID triggering/generating EHC feedback or each received said CID or each said CID having established context information; or the CID _ Flag is used for storing the currently received minimum sequence number or COUNT of the PDCP PDU or PDCP SDU for establishing the context information; or the CID _ Flag is used for storing the sequence number or the COUNT of the PDCP PDU or the PDCP SDU which triggers the EHC feedback.

According to the method of the second aspect of the present disclosure, when the sequence number or the COUNT of the received PDCP PDU or PDCP SDU is smaller than the current CID _ Flag, but the carried context information is the same as the context information corresponding to the CID _ Flag, the CID _ Flag is updated to the sequence number or the COUNT of the current PDCP PDU or the current PDCP SDU.

According to the method of the second aspect of the present disclosure, if the received sequence number or the PDCP PDU whose COUNT is less than the current CID _ Flag contains a compressed PDCP SDU or ethernet frame or ethernet packet, decompression is performed using old context information; and if the received sequence number or the PDCP PDU of which the COUNT is greater than the current CID _ Flag contains the compressed PDCP SDU or Ethernet frame or Ethernet message, decompressing by using new context information.

The PDCP entity according to the third aspect of the present disclosure, comprising: a transmitting end and a receiving end, wherein the transmitting end executes the method of the first aspect; and/or the receiving end performs the method of the second aspect.

A communication device according to a fourth aspect of the present disclosure is a communication device having a packet data convergence protocol PDCP entity, comprising: a processor; and a memory storing instructions; wherein the instructions, when executed by the processor, perform the method of the first aspect above and/or the method of the second aspect above.

Drawings

The above and other features of the present disclosure will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings, in which:

fig. 1 is a diagram schematically showing the format of COUNT.

Fig. 2 is a schematic flow chart illustrating a method for a PDCP entity transmitting end to transmit PDCP PDUs when an EHC mechanism is employed according to an embodiment of the present disclosure.

Fig. 3 is a brief flow chart schematically illustrating a method for a PDCP entity receiving end to transmit EHC feedback according to one embodiment of the present disclosure.

Fig. 4 schematically shows a block diagram of a brief structure of a PDCP entity according to an embodiment of the present disclosure.

Fig. 5 schematically shows a schematic block diagram of a communication apparatus of one embodiment of the present disclosure.

Detailed Description

The present disclosure is described in detail below with reference to the attached drawings and detailed description. It should be noted that the present disclosure should not be limited to the specific embodiments described below. In addition, for the sake of brevity, detailed descriptions of well-known technologies not directly related to the present disclosure are omitted to prevent confusion of understanding of the present disclosure.

Some of the terms to which the present disclosure relates, if not specifically stated, are the same as those used in the current latest version of the 3GPP protocol, and are now extracted as follows.

EHC: ethernet Header Compression, Ethernet Header Compression.

COUNT: the length is 32 bits, the COUNT value is composed of the hyper frame number HFN and the PDCP sequence number SN (as shown in fig. 1), and the size of HFN is 32 minus the length of PDCP sequence number SN.

DRB: data Radio Bearer, Data Radio Bearer.

RRC: radio Resource Control, Radio Resource Control.

PDCP: packet Data Convergence Protocol, Packet Data Convergence Protocol.

SDAP: service Data Adaptation Protocol.

RLC: radio Link Control, Radio Link Control. The RLC entity may be configured to employ one of three modes for data transmission: transparent mode TM, unacknowledged mode UM or acknowledged mode AM.

MAC: medium Access Control, Medium Access Control.

AM DRB: DRB using RLC AM (a data radio bearer whithin RLC AM).

UM DRB: DRB using RLC UM.

SDU: service Data Unit.

PDU: protocol Data Unit, Protocol Data Unit.

In the present disclosure, data received or delivered (delivery) from an upper layer is referred to as SDU, and data submitted (submit) or received from a lower layer is referred to as PDU. For example, data received by the PDCP entity from an upper layer or data transferring the upper layer is referred to as PDCP SDU; data received by the PDCP entity from the RLC entity or data submitted to the RLC entity is referred to as PDCP PDU (i.e., RLC SDU).

In the existing LTE and/or NR system, for AM DRB, after receiving a positive acknowledgement (positive acknowledgement) of an RLC SDU, an AM RLC entity sending end sends an indication that the RLC SDU was successfully delivered to an upper layer (i.e., PDCP layer). In other words, for AM DRB, the PDCP entity expects to receive an indication of successful delivery of PDCP PDUs from the lower layer (i.e., RLC layer).

The following describes a method for transmitting PDCP PDU by a PDCP entity transmitting end when EHC mechanism is adopted

An embodiment of a method for transmitting a PDCP pdu by a transmitting end of a PDCP entity when an EHC mechanism is used is described below with reference to fig. 2.

In an embodiment, as shown in fig. 2, in step S1, after the sending end of the PDCP entity sends the PDCP PDU carrying the establishment context information, if an indication of successful delivery of the PDCP PDU from the lower layer is received, the sending end of the PDCP entity starts sending a PDCP PDU carrying a compressed PDCP SDU or ethernet frame or ethernet packet (the PDCP PDU and the PDCP PDU carrying the establishment context information with successful delivery are the same in ethernet header or header compressible field, that is, they belong to the same flow), via step S2 and step S3. In other words, all PDCP PDUs or PDCP SDUs or ethernet frames or ethernet packets that are identical to the PDCP PDU or payload thereof in the ethernet header or header compressible field are not header compressed (i.e., carry a CID and a full ethernet header therein) until an indication from the lower layer is received that the delivery of the PDCP PDU carrying the context information was successful. Header compression is performed on the PDCP SDUs or Ethernet frames belonging to the same flow only after receiving an indication that the first or any one of the PDCP PDUs (the PDCP PDUs or the PDCP SDUs or the Ethernet frames belonging to the same flow) carrying the PDCP PDUs for establishing the context information from the lower layer is successfully delivered.

The PDCP entity sending end may perform EHC header compression on PDCP SDUs or ethernet frames or ethernet packets Briefly described as follows:

the sending end of the PDCP entity judges whether an Ethernet header or a compressible field of the header of a PDCP SDU (or an Ethernet frame or an Ethernet message) is mapped or distributed with a context identifier CID; if the context identifier CID has been mapped or allocated, then it is determined whether a confirmation that the context corresponding to the CID has been established is received. If the context identifier CID is mapped or allocated, but a confirmation that the context corresponding to the CID is established is not received (for example, an indication that any one of the first or the same stream from the lower layer carries successful delivery of the PDCP PDU for establishing the context information is not received, or feedback of the CID is not received), the PDCP SDU or the ethernet frame or the ethernet packet is not subjected to header compression, that is, the PDCP SDU or the ethernet frame or the PDCP PDU corresponding to the ethernet packet carries the corresponding CID and a complete ethernet header; if a context identification CID is mapped or allocated and a confirmation that the context corresponding to the CID has been established is received (e.g., an indication that delivery of any PDCP PDU carrying the CID and a full ethernet header from the first or the same stream of the lower layer was successful is received, or feedback of the CID is received), header compression is performed on the PDCP SDU or ethernet frame or ethernet packet, i.e., the compressible header in the PDCP SDU or ethernet frame or ethernet packet is removed, and the corresponding CID and/or part of the ethernet header that does not need to be compressed is carried in the PDCP PDU corresponding thereto (if present). The confirmation that the context corresponding to the CID has been established is one of: receiving an indication that the PDCP PDU for establishing the context information is successfully delivered and feedback of the CID from the first flow or any one of the same flows from the lower layer. The PDCP entity may be predefined to support only one of the acknowledgments; or predefining that the context corresponding to the CID supported by the PDCP entity corresponding to the AM DRB is established, confirming that the indication that the delivery of the PDCP PDU carrying the context information established by any one of the first or the same flow from the lower layer is successfully received, and confirming that the feedback of the CID is received when the context corresponding to the CID supported by the PDCP entity corresponding to the UM DRB is established.

In the present disclosure, feedback of CID (also referred to as feedback or EHC feedback) refers to an acknowledgement generated by a PDCP receiving end for a received PDCP PDU or PDCP SDU containing a context identification CID and a full ethernet header (i.e., used for establishing context information), and the acknowledgement may be a PDCP control PDU, which may contain the context identification CID and/or a sequence number or COUNT of the PDCP PDU or PDCP SDU (or of the PDCP PDU or PDCP SDU triggering the acknowledgement). The EHC feedback in this disclosure refers to positive feedback, which indicates context information of a corresponding CID that has been established at the receiving end of the PDCP entity. If the EHC feedback also includes negative feedback, for example, a field is included in the PDCP control PDU corresponding to the EHC feedback to indicate whether positive feedback or negative feedback is provided (i.e., positive feedback or negative feedback corresponding to CID, SN, or COUNT), for example, the field occupies 1 bit, when the field takes a value of 1, positive feedback is indicated, when the field takes a value of 0, negative feedback is indicated, and vice versa, when the sending end of the PDCP entity receives the EHC feedback with negative feedback, the PDCP PDU carrying the CID and the complete ethernet header needs to be retransmitted to establish context information.

In the present disclosure, PDCP SDUs or ethernet frames or ethernet packets having the same ethernet header or header compressible field mapped to one DRB or PDCP entity are referred to as one flow (ethernet flow).

For example, assuming that the headers or compressible fields of the ethernet frames or packets carried in PDCP PDUs/SDUs with sequence numbers (or COUNTs) of 0, 2, 4, 6, 8 are the same (i.e., belong to the same ethernet flow), they will map to the same CID, e.g., CID 1; the header or header compressible fields of the ethernet frames carried by the PDCP PDUs/SDUs with sequence numbers (or COUNTs) of 1, 3, 5, 7, 9 are identical (i.e., belonging to another ethernet flow), and they will also map to the same CID, e.g., CID 2. First, the PDCP entity transmitting end transmits a PDCP PDU with sequence number (or COUNT) of 0, which carries information for setting up a context, i.e., carries CID1 and a full ethernet header. Next, the PDCP entity transmitting end transmits a PDCP PDU with sequence number (or COUNT) of 1, which carries information for setting up a context, i.e., carries CID2 and a full ethernet header. If the PDCP entity transmitting end has not received the successful delivery indication of the PDCP PDU with sequence number (or COUNT) of 0 from the lower layer or has not received the EHC feedback of CID1 when transmitting the PDCP PDU with sequence number (or COUNT) of 2, the PDCP SDU or ethernet frame or ethernet packet with sequence number (or COUNT) of 2 is not header-compressed, i.e. the PDCP PDU with sequence number (or COUNT) of 2 also contains CID1 and a complete ethernet header. If the PDCP entity transmitting end receives an indication of successful delivery of the PDCP PDU with sequence number (or COUNT) of 1 or EHC feedback of CID2 from the lower layer before transmitting the PDCP PDU with sequence number (or COUNT) of 3, header compression is performed on the PDCP SDU with sequence number (or COUNT) of 3 or the ethernet frame or ethernet packet, that is, only the CID2 and/or part of the ethernet header without compression is included in the PDCP PDU with sequence number (or COUNT) of 3 (if present).

The context information refers to a mapping relationship between the context identifier CID and the ethernet header or the header compressible field. The PDCP PDU carrying context information for establishing is that the PDCP PDU carries a complete Ethernet header and a context identification CID corresponding to a compressible field of the header or the header.

In this disclosure, for the PDCP entity that employs the EHC header compression mechanism, the EHC compression end is included in the PDCP entity transmitting end, and the EHC decompression end is included in the PDCP entity receiving end. Therefore, in the present disclosure, the EHC compression end and the PDCP entity transmitting end may be used interchangeably in relation to EHC header compression operation, and the EHC decompression end and the PDCP entity receiving end may be used interchangeably in relation to EHC decompression operation.

In the present disclosure, a new field for indicating EHC-related information, such as a CID field, an indication field of a payload type, may be defined in the PDCP header; a new EHC header may also be defined, and when the sending end of the PDCP entity is configured with an uplink EHC and/or a downlink EHC, the PDCP PDU carries the EHC header, otherwise, the PDCP PDU does not carry the EHC header. The EHC head includes at least: a CID field and an indication of the type of payload, and may also include an uncompressed ethernet header field. The load type indication field is used to indicate whether the PDCP PDU or its load is compressed, for example, if the value of the load type indication field is 1 (or 0), it indicates that the data field of the corresponding PDCP PDU is an uncompressed PDCP SDU; and if the indication field of the load type is 0 (or 1), indicating that the data field of the corresponding PDCP PDU is the compressed PDCP SDU.

It should be noted that, in the present disclosure, associating or mapping a context identifier CID with an ethernet header means associating a CID of a specific value with a compressible field of an ethernet header (i.e., a value of the compressible field of the ethernet header). The ethernet header compressible field (also referred to as the field that the ethernet header needs to be compressed) may include one or more of the following fields: DESTINATION ADDRESS (DESTINATION ADDRESS), SOURCE ADDRESS (SOURCE ADDRESS), TYPE/LENGTH (TYPE/LENGTH), Q-TAGs. Wherein the Q-TAGs field may include the following fields: the VLAN identifies a VID field, a PRI field indicating ethernet frame priority, a frame type field TPID, a DEI field indicating whether it is discardable or not. The information for establishing a context described in this disclosure contains a context identification CID that is not an uncompressed indication. The uncompressed indication may be predefined or may configure a value via an RRC message to indicate that the PDCP PDU carrying the CID value is uncompressed. In other words, when the CID field of a PDCP PDU (which may also be referred to as an ethernet packet or frame or packet or a compressed packet) is set to a predefined value (e.g., 0) or a configured value, it indicates that a complete ethernet header is carried in the ethernet packet or frame or packet or PDCP PDU. When the PDCP entity receiver performs decompression by using EHC, if the CID field in the received PDCP PDU is set to the predefined or configured value, the PDCP entity receiver does not store the mapping relationship between the CID and the ethernet header. This predefined or RRC configured value is used to set the CID field of the PDCP PDU to this predefined or RRC configured value when the PDCP entity sender considers that no compression of this ethernet header is needed (or that no CID value is available or that all CID values except this have established a mapping relationship with the ethernet header).

It should be noted that the payload of the PDCP PDU in this disclosure is the data field of the PDCP PDU, which is one of the following: uncompressed PDCP SDUs (e.g., user plane data or control plane data), compressed PDCP SDUs (currently only applicable to user plane data).

The following describes a method for transmitting EHC feedback at a receiving end of a PDCP entity

An embodiment of a method for transmitting EHC feedback at a receiving end of a PDCP entity will be described with reference to fig. 3.

In an embodiment, as shown in fig. 3, when the receiving end of the PDCP entity receives a new PDCP PDU or PDCP SDU for establishing context information in step T1, in step T2, a corresponding EHC feedback is triggered or generated, where the EHC feedback includes a context identifier CID carried or associated in the PDCP PDU or PDCP SDU and/or a sequence number or COUNT of the PDCP PDU or PDCP SDU.

In addition, in step T3, a variable CID _ Flag may be defined for each context identifier or each received context identifier CID or each CID triggering/generating EHC feedback or each PDCP PDU/PDCP SDU (or CID carried by the same) generating/triggering EHC feedback or each context identifier CID of the established context information, where CID _ Flag is used to store the currently received sequence number (or COUNT) of the PDCP PDU or PDCP SDU used to establish the context information (i.e., the latest context information corresponding to the CID); or the CID _ Flag is used to store the currently received minimum sequence number (or COUNT) of the PDCP PDU or PDCP SDU used to establish the context information (i.e., the latest context information corresponding to the CID); or the CID _ Flag is used for storing a sequence number (or COUNT) of the PDCP PDU or PDCP SDU which triggers the EHC feedback; or the CID _ Flag is used to store a sequence number (or COUNT) of the PDCP pdu or PDCP SDU for which EHC feedback is generated. Optionally, when the sequence number (or COUNT) of the received PDCP PDU or PDCP SDU is smaller than the current CID _ Flag but the carried context information is the same as the context information corresponding to the CID _ Flag (i.e., the ethernet header or header compressible field corresponding to the context identification CID mapped/corresponding to the context identification CID is the same), the CID _ Flag is updated to the sequence number (or COUNT) of the current PDCP PDU or PDCP SDU.

In addition, in step T4, for PDCP PDUs whose received sequence number (or COUNT) is less than CID _ Flag and which contain compressed PDCP SDUs or ethernet frames or ethernet packets, decompression may be performed by using old context information (i.e. the old ethernet header or header compressible field corresponding to the context identifier); and if the received PDCP PDU of which the sequence number (or COUNT) is greater than the CID _ Flag contains the compressed PDCP SDU or Ethernet frame or Ethernet message, decompressing by using new context information. Optionally, when all PDCP PDUs with sequence numbers (or COUNT) less than CID _ Flag are received, the old context information is deleted. Optionally, the context information is updated only when all PDCP PDUs or PDCP SDUs with sequence numbers (or COUNTs) less than CID _ Flag have been received and/or correctly decompressed. In this case, although the PDCP entity receiver receives the PDCP PDU or PDCP SDU mapping the current context identification CID to the new ethernet header or header compressible field, assuming that the sequence number (or COUNT) thereof is N, if there is a PDCP PDU or PDCP SDU having a sequence number (or COUNT) less than N that has not been received, the PDCP entity receiver does not update the context information corresponding to the CID. In other words, only when all PDCP PDUs or PDCP SDUs with sequence numbers (or COUNTs) less than N have been received, the context information corresponding to the CID is updated; alternatively, the context information corresponding to the CID is updated only if all PDCP PDUs or PDCP SDUs with sequence numbers (or COUNTs) less than N have been received, unless the CID has not yet been mapped to any ethernet header or header compressible field (i.e., the corresponding context is first generated for the CID).

In addition, the PDCP status report may also be used as an EHC feedback, in which case, when the receiving end of the PDCP entity receives a new PDCP PDU or PDCP sdu for establishing context information, the PDCP status report is triggered or generated.

In the disclosed embodiment, the context identification CID associated or defining the variable CID _ Flag is not an uncompressed indication, as not specifically illustrated.

In an embodiment, when a PDCP entity receiving end receives a new PDCP PDU or PDCP SDU for establishing a context, if all PDCP PDUs or PDCP SDUs having sequence numbers (or COUNTs) smaller than the sequence number (or COUNT) of the PDCP PDU or PDCP SDU have been received and/or successfully decompressed, a corresponding EHC feedback is generated, where the EHC feedback includes a context identifier CID carried or associated in the PDCP PDU or PDCP SDU and/or a sequence number or COUNT value of the PDCP PDU or PDCP SDU. Optionally, the generated EHC feedback is submitted to the lower layer. As in the previous embodiment, a CID _ Flag (meaning the same as that in the previous embodiment) may be defined, and when all PDCP PDUs or SDUs with sequence numbers (or COUNTs) smaller than CID _ Flag have been received and/or successfully decompressed, corresponding EHC feedback is generated and optionally delivered to the lower layer. Since UM DRB may generate packet loss, this scheme may be applied only to AM DRB.

Optionally, the predefined EHC feedback is applied only to UM DRBs.

After receiving the EHC feedback, the PDCP entity sending end performs header compression on PDCP SDUs or ethernet frames or ethernet packets in the ethernet stream corresponding to the EHC feedback or its corresponding CID.

In one embodiment, the base station may configure whether to employ EHC feedback for the UE through RRC message or signaling (this is for the DRB or PDCP entity configured with EHC, and uplink and downlink may be configured separately). Specifically, the RRC message includes an indication cell ehcFeedback, and when the value of the cell is 1 or true or the cell appears, the receiving end of the PDCP entity sends the EHC feedback or sends the EHC feedback when the condition of the embodiment is met; when the cell value is 0 or false or the cell does not appear, the receiving end of the PDCP entity sends the EHC feedback or sends the EHC feedback when the condition of the embodiment is met; and vice versa. If the uplink and downlink are configured separately, the cell ehcFeedback _ UL for the uplink and the cell ehcFeedback _ DL for the downlink are needed, and the meaning of the cell is the same as ehcFeedback, but only applied to the uplink or the downlink.

In one embodiment, the base station may configure the user equipment UE to employ EHC feedback or transmit multiple times through RRC messages or signaling. Specifically, an indication cell readable transmission is included in the RRC message, and the cell includes an ehcFeedback cell and a multiTrans cell. The base station can only select one of the two cells when it is configured for the UE. When the ehcFeedback cell value is 1 or true or the cell appears, the receiving end of the PDCP entity sends EHC feedback or sends EHC feedback when the condition of the embodiment is satisfied; when the cell multiTrans occurs and the value is n (the value of n is an integer greater than or equal to 1), for PDCP SDUs or PDCP PDUs or ethernet frames or ethernet messages from the same ethernet stream, the sending end of the PDCP entity sends n PDCP PDUs (uncompressed) carrying context identifiers CID and complete ethernet headers and then sends PDCP PDUs carrying compressed PDCP SDUs or ethernet frames or ethernet messages. The same reusable Transmission and MultiTranss can also be configured in both upstream and downstream. If the uplink and downlink are configured separately, then the cells readable transmission _ UL and multiTrans _ UL for the uplink and the cells readable transmission _ DL and multiTrans _ DL for the downlink are needed, and the meaning of the cells is the same as that of readable transmission and multiTrans, but only applied to the uplink or downlink.

The ehcFeedback cell is used for indicating a receiving end of the PDCP entity to send EHC feedback, and the multiTrans cell is used for indicating the number of the PDCP PDUs which carry the context identifier CID and the complete Ethernet header and need to be sent when the sending end of the PDCP entity establishes a context message.

Fig. 4 is a block diagram illustrating a brief structure of a PDCP entity according to an embodiment of the present disclosure.

As shown in fig. 4, the PDCP entity 400 includes at least a receiving end 401 and a transmitting end 402. Moreover, the PDCP entity 400 may be included in a client device or a base station device, for example, and the processor may control the receiving end 401 to perform the method of the present disclosure described in fig. 1 and/or the processor to control the transmitting end 402 to perform the method of the present disclosure described in fig. 2.

Fig. 5 shows a block diagram of a schematic structure of a communication apparatus according to an embodiment of the present disclosure.

As shown in fig. 5, the communication device 500 includes at least a processor 501 and a memory 502. The processor 501 may include, for example, a microprocessor, a microcontroller, an embedded processor, or the like. The memory 502 may include, for example, volatile memory (e.g., random access memory RAM), a Hard Disk Drive (HDD), non-volatile memory (e.g., flash memory), or other memory systems, among others. The memory 502 has stored thereon program instructions. The instructions, when executed by the processor 501, may perform the methods described in fig. 1 and/or fig. 2 above of the present disclosure.

The computer-executable instructions or programs running on the apparatus according to the present disclosure may be programs that cause a computer to implement the functions of the embodiments of the present disclosure by controlling a Central Processing Unit (CPU). The program or information processed by the program may be temporarily stored in a volatile memory (such as a random access memory RAM), a Hard Disk Drive (HDD), a nonvolatile memory (such as a flash memory), or other memory system.

Computer-executable instructions or programs for implementing the functions of embodiments of the present disclosure may be recorded on a computer-readable storage medium. The corresponding functions can be realized by causing a computer system to read the programs recorded on the recording medium and execute the programs. The term "computer system" as used herein may be a computer system embedded in the device and may include an operating system or hardware (e.g., peripheral devices). The "computer-readable storage medium" may be a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a recording medium that stores a program for short-term dynamics, or any other recording medium that is readable by a computer.

Various features or functional blocks of the devices used in the above-described embodiments may be implemented or performed by circuitry (e.g., a single or multiple chip integrated circuits). Circuitry designed to perform the functions described herein may include a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The circuit may be a digital circuit or an analog circuit. Where new integrated circuit technology has emerged as a replacement for existing integrated circuits due to advances in semiconductor technology, one or more embodiments of the present disclosure may also be implemented using such new integrated circuit technology.

Further, the present disclosure is not limited to the above-described embodiments. While various examples of the embodiments have been described, the present disclosure is not so limited. Fixed or non-mobile electronic devices installed indoors or outdoors may be used as terminal devices or communication devices, such as AV devices, kitchen devices, cleaning devices, air conditioners, office devices, vending machines, and other home appliances.

As above, the embodiments of the present disclosure have been described in detail with reference to the accompanying drawings. However, the specific configuration is not limited to the above embodiment, and the present disclosure also includes any design modification without departing from the gist of the present disclosure. In addition, various modifications can be made to the present disclosure within the scope of the claims, and embodiments obtained by appropriately combining technical means disclosed in different embodiments are also included in the technical scope of the present disclosure. Further, components having the same effects described in the above embodiments may be substituted for each other.

Claims

1. An execution method of a packet data convergence protocol PDCP entity sending end comprises the following steps;

sending a first packet data convergence protocol data unit (PDCP PDU) carrying context information for establishing;

under the condition of receiving an indication from a lower layer that the delivery of the first PDCP PDU is successful, carrying out Ethernet Header Compression (EHC) on a first packet data convergence protocol service data unit, namely a first PDCP SDU, or a first Ethernet frame, or a first Ethernet message, which belongs to the same flow as the first PDCP PDU;

and sending a second PDCP PDU with the load of the second PDCP SDU, the second Ethernet frame or the second Ethernet message after the EHC.

2. The method of claim 1,

the EHC for Ethernet header compression comprises:

judging whether the first PDCP SDU, the first Ethernet frame or the Ethernet header or header compressible field of the first Ethernet message is mapped or distributed with a context identification CID;

under the condition that the CID is mapped or allocated, judging whether confirmation that the context corresponding to the CID is established is received;

and performing the EHC on the first PDCP SDU, the first Ethernet frame or the first Ethernet message under the condition that the confirmation is received.

3. The method of claim 2,

and not performing the EHC when the CID is mapped or allocated and the confirmation is not received.

4. The method of claim 2,

the determining whether the confirmation that the context corresponding to the CID is established is received includes:

and judging whether positive feedback or negative feedback of the CID is received or not, and judging whether an indication that the first PDCP PDU delivery is successful is received or not from a lower layer.

5. An execution method of a packet data convergence protocol PDCP entity receiving end comprises the following steps:

triggering or generating a corresponding Ethernet header compression EHC feedback when receiving a new packet data convergence protocol data unit PDCP PDU or packet data convergence protocol service data unit PDCP SDU for establishing context information,

wherein, the EHC feedback includes the context identifier CID carried or associated in the PDCP PDU or the PDCP SDU and/or the sequence number or COUNT of the PDCP PDU or the PDCP SDU.

6. The method of claim 5, further comprising:

defining a variable CID _ Flag for each said CID or each CID triggering/generating EHC feedback or each said CID received or each said CID of established context information,

the CID _ Flag is used for storing a sequence number or a COUNT of the currently received PDCP PDU or PDCP SDU for establishing context information; or

The CID _ Flag is used for storing the currently received minimum sequence number or COUNT of the PDCP PDU or PDCP SDU for establishing context information; or

The CID _ Flag is used for storing a sequence number or a COUNT of the PDCP PDU or the PDCP SDU which triggers the EHC feedback.

7. The method of claim 6, further comprising:

and when the received sequence number or the COUNT of the PDCP PDU or the PDCP SDU is smaller than the current CID _ Flag but the carried context information is the same as the context information corresponding to the CID _ Flag, updating the CID _ Flag to be the sequence number or the COUNT of the current PDCP PDU or the current PDCP SDU.

8. The method of claim 6 or 7, further comprising:

if the received sequence number or the received PDCP PDU of which the COUNT is smaller than the current CID _ Flag contains the compressed PDCP SDU or Ethernet frame or Ethernet message, decompressing by using old context information;

and if the received sequence number or the PDCP PDU of which the COUNT is greater than the current CID _ Flag contains the compressed PDCP SDU or Ethernet frame or Ethernet message, decompressing by using new context information.

9. A packet data convergence protocol, PDCP, entity comprising: a transmitting end and a receiving end,

the transmitting end executing the method of any one of claims 1 to 4; and/or

The receiving end performs the method of any of claims 5 to 8.

10. A communication device, being a communication device having a packet data convergence protocol, PDCP, entity, comprising:

a processor; and

a memory storing instructions;

wherein the instructions, when executed by the processor, perform the transmission method of any of claims 1 to 4 and/or the method of any of claims 5 to 8.