WO2021027685A1 - Pdcp实体发送端/接收端的执行方法、pdcp实体及通信设备 - Google Patents

Pdcp实体发送端/接收端的执行方法、pdcp实体及通信设备 Download PDF

Info

Publication number
WO2021027685A1
WO2021027685A1 PCT/CN2020/107443 CN2020107443W WO2021027685A1 WO 2021027685 A1 WO2021027685 A1 WO 2021027685A1 CN 2020107443 W CN2020107443 W CN 2020107443W WO 2021027685 A1 WO2021027685 A1 WO 2021027685A1
Authority
WO
WIPO (PCT)
Prior art keywords
pdcp
cid
ethernet
pdcp pdu
ehc
Prior art date
Application number
PCT/CN2020/107443
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 夏普株式会社
Publication of WO2021027685A1 publication Critical patent/WO2021027685A1/zh

Links

Images

Classifications

    • 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
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals

Definitions

  • the present disclosure relates to the field of wireless communication technology, and more specifically, the present disclosure relates to a method for executing a transmitter/receiver of a PDCP entity, a PDCP entity, and a communication device.
  • Ethernet header compression is a method to reduce the overhead caused by Ethernet header transmission. Ethernet frames can be transmitted in the Ethernet PDU session type through the 5G system. In an Ethernet-based industrial Internet of Things network, the payload size is relatively small relative to the overall size of the frame. Therefore, compressing the Ethernet frame header can improve transmission efficiency and reduce delay.
  • Ethernet header compression (EHC) mechanism
  • EHC Ethernet header compression
  • the uplink and downlink of each data radio bearer DRB are separately configured with Ethernet header compression protocols; the compressor and decompressors use context identifiers
  • Context ID associates a context identifier with Ethernet header contents; and EHC is based on the following mechanism: For an Ethernet stream that generates a new context, the compression end sends at least one containing a complete header and a context identifier
  • the message/frame of the decompression terminal can establish the context, and then the compression terminal will transmit the compressed message/frame;
  • the header of the data packet generated by Ethernet header compression includes at least the following fields: context identifier, used to indicate this data packet
  • the indicator of the format of the header that is, it indicates whether the header of the data packet is a complete header or a compressed header).
  • Ethernet header compression discusses related problems and solutions involved in Ethernet header compression, including: the PDCP entity sender (or EHC compression end) sends PDCP PDU for establishing context when the EHC mechanism is used for header compression. After that, how to determine whether to send a compressed packet; when the PDCP entity receiving end receives the PDCP PDU used to establish or update the context information, when does it send feedback? How to decompress PDCP PDUs carrying compressed messages/frames whose sequence number (or COUNT) is less than the sequence number (or COUNT) of the PDCP PDU with updated context information?
  • the present disclosure provides a method for executing a transmitter/receiver of a PDCP entity, a PDCP entity, and a communication device.
  • the method for executing the PDCP entity transmitter includes: sending a first packet data convergence protocol protocol data unit that is used to establish context information, that is, a first PDCP PDU; In the case of an indication of successful delivery of the PDCP PDU, the first packet data convergence protocol service data unit that belongs to the same flow as the first PDCP PDU, that is, the first PDCP SDU, or the first Ethernet frame, or the first Ethernet packet.
  • the packet undergoes Ethernet header compression EHC; the transmission load is the second PDCP SDU after the EHC, or the second Ethernet frame, or the second PDCP PDU of the second Ethernet packet.
  • the performing Ethernet header compression EHC includes: determining the Ethernet of the first PDCP SDU, or the first Ethernet frame, or the first Ethernet packet Whether the header or header compressible field is mapped or assigned a context identifier CID; in the case of determining that the CID has been mapped or assigned, it is determined whether the confirmation that the context corresponding to the CID has been established is received; If it is determined that the confirmation is received, perform the EHC on the first PDCP SDU, or the first Ethernet frame, or the first Ethernet packet.
  • the EHC when it is determined that the CID has been mapped or allocated, but the confirmation has not been received, the EHC is not performed.
  • the judging whether the confirmation that the context corresponding to the CID has been established includes: judging whether the positive feedback or negative feedback of the CID is received, and judging whether or not the response from the lower layer is received. An indication that the first PDCP PDU is successfully delivered.
  • the execution method of the PDCP entity receiving end of the second aspect of the present disclosure when a new packet data convergence protocol protocol data unit PDCP PDU or a packet data convergence protocol service data unit PDCP SDU for establishing context information is received, trigger or generate Corresponding Ethernet header compression EHC feedback, where 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.
  • each CID or each CID that has triggered/generated EHC feedback or each received CID or each CID that has established context information is defined for each CID or each CID that has triggered/generated EHC feedback or each received CID or each CID that has established context information
  • the CID_Flag is used to store the currently received PDCP PDU or the PDCP SDU sequence number or COUNT used to establish context information
  • the CID_Flag is used to store the currently received context information used to establish The smallest sequence number or COUNT of the PDCP PDU or PDCP SDU
  • the CID_Flag is used to store the sequence number or COUNT of the PDCP PDU or PDCP SDU that triggers EHC feedback.
  • the context information carried is the context corresponding to the CID_Flag If the information is the same, update the CID_Flag to the sequence number or COUNT of the current PDCP PDU or the current PDCP SDU.
  • the PDCP PDU contains a compressed PDCP SDU or Ethernet frame or Ethernet packet If the received sequence number or the COUNT is greater than the current CID_Flag of the PDCP PDU, and the PDCP PDU contains the compressed PDCP SDU or Ethernet frame or Ethernet The message is decompressed using the new context information.
  • the PDCP entity according to the third aspect of the present disclosure includes: a sending end and a receiving end, where the sending end executes the method of the first aspect; and/or the receiving end executes the method of the second aspect.
  • the communication device is a communication device with a packet data convergence protocol PDCP entity, and includes: a processor; and a memory storing instructions; wherein the instructions are executed when the processor is running.
  • FIG. 1 is a diagram schematically showing the format of COUNT.
  • Fig. 2 is a brief flowchart schematically showing a method for a PDCP entity transmitter to send a PDCP PDU when the EHC mechanism is adopted according to an embodiment of the present disclosure.
  • Fig. 3 is a brief flowchart schematically showing a method for a PDCP entity receiving end to send EHC feedback according to an embodiment of the present disclosure.
  • Fig. 4 schematically shows a schematic structural block diagram of a PDCP entity according to an embodiment of the present disclosure.
  • Fig. 5 schematically shows a schematic structural block diagram of a communication device according to an embodiment of the present disclosure.
  • EHC Ethernet Header Compression, Ethernet header compression.
  • COUNT The length is 32 bits.
  • the COUNT value is composed of the superframe number HFN and the PDCP sequence number SN (as shown in Figure 1).
  • the size of the HFN is 32 minus the length of the 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, service data adaptation protocol.
  • RLC Radio Link Control, radio link control.
  • the RLC entity can be configured to use one of the following three modes for data transmission: transparent transmission mode TM, unconfirmed mode UM or confirmed mode AM.
  • MAC Medium Access Control, media access control.
  • RLC AM DRB Use RLC AM DRB (a data radio bearer which utilizes RLC AM).
  • SDU Service Data Unit, service data unit.
  • PDU Protocol Data Unit, protocol data unit.
  • data received or delivered from the upper layer is referred to as SDU
  • data submitted or received from the lower layer is referred to as PDU
  • the data received by the PDCP entity from the upper layer or the data transmitted by the upper layer is called PDCP SDU
  • the data received by the PDCP entity from the RLC entity or the data submitted to the RLC entity is called PDCP PDU (that is, RLC SDU).
  • the AM RLC entity sender sends an indication of the successful delivery of the RLC SDU to the upper layer (that is, the PDCP layer) after receiving a positive acknowledgement of an RLC SDU .
  • the PDCP entity expects to receive an indication of successful PDCP PDU delivery from the lower layer (ie, the RLC layer).
  • the following describes the method of sending PDCP PDU by the PDCP entity transmitter when the EHC mechanism is adopted
  • step S1 after the PDCP entity transmitter sends the PDCP PDU carrying the context information for establishing the context, through step S2 and step S3, if the PDCP PDU is received from the lower layer
  • the PDCP entity transmitter starts to send the PDCP PDU carrying the compressed PDCP SDU or Ethernet frame or Ethernet packet (this PDCP PDU and the PDCP PDU that is confirmed to be successfully delivered and carrying the establishment context information)
  • the Ethernet header or header compressible fields are the same, that is, they belong to the same stream).
  • Ethernet frames or Ethernet packets do not perform header compression (that is, they carry CID and complete Ethernet headers).
  • the PDCP PDU or PDCP SDU or Ethernet frame or Ethernet packet for the first one or any one of them here refers to the PDCP PDU or PDCP SDU or Ethernet frame or Ethernet packet belonging to the same flow
  • the PDCP SDU or Ethernet packet or Ethernet frame belonging to the same flow will be compressed after the instruction.
  • the sender of the PDCP entity executes the EHC header on the PDCP SDU or Ethernet frame or Ethernet packet
  • the compression operation can be briefly described as follows:
  • the sender of the PDCP entity judges whether the Ethernet header or compressible field of the PDCP SDU (or Ethernet frame or Ethernet packet) is mapped or assigned a context identifier CID; if the context identifier CID is mapped or assigned, Then determine whether the confirmation that the context corresponding to the CID has been established is received.
  • the PDCP SDU or Ethernet frame or Ethernet packet will not be header compressed, that is, the PDCP SDU or Ethernet frame or Ethernet packet corresponds to The PDCP PDU carries the corresponding CID and the complete Ethernet header; if the context identifier CID has been mapped or assigned, and the confirmation that the context corresponding to the CID has been established is received (for example, the first or Any one of the same flow carries a CID and a complete Ethernet header indicating that the PDCP PDU is delivered successfully, or receives feedback from the CID), then the PDCP SDU or Ethernet frame or Ethernet packet is header compressed, That is, remove the compressible header in the PDCP SDU or Ethernet frame or Ethernet packet,
  • the confirmation that the context corresponding to the CID has been established is one of the following: receiving an indication of successful delivery of the PDCP PDU used to establish context information from the first or the same stream from the lower layer, and receiving the CID Feedback.
  • the PDCP entity can be pre-defined to support only one of the acknowledgments; or the context corresponding to the CID supported by the PDCP entity corresponding to the AM DRB can be pre-defined.
  • the established acknowledgment is the first one received from the lower layer or any one of the same flow is carried for An indication of successful delivery of the PDCP PDU that establishes the context information, and the confirmation that the context corresponding to the CID supported by the PDCP entity of the UM DRB has been established is the feedback of receiving the CID.
  • CID feedback means that the PDCP receiver responds to the received PDCP PDU or PDCP containing the context identifier CID and the complete Ethernet header (that is, used to establish context information)
  • the confirmation generated by the SDU, the confirmation may be a PDCP control PDU, which may include the context identifier CID and/or the sequence number or COUNT of the PDCP PDU or PDCP SDU (or the PDCP PDU or the PDCP SDU that triggers the confirmation).
  • the EHC feedback mentioned in the present disclosure all refers to positive feedback, which represents the context information of the corresponding CID that has been established at the receiving end of the PDCP entity.
  • EHC feedback also includes negative feedback
  • the PDCP control PDU corresponding to EHC feedback includes a field to indicate whether it is positive feedback or negative feedback (that is, positive feedback or negative feedback corresponding to CID or SN or COUNT), for example, the field Occupies 1 bit. When the value of the field is 1, it means positive feedback, and when the value of the field is 0, it means negative feedback, and vice versa.
  • the PDCP entity transmitter receives negative feedback EHC feedback, it needs to be retransmitted PDCP PDU carrying CID and complete Ethernet header to establish context information.
  • a PDCP SDU or Ethernet frame or Ethernet packet with the same Ethernet header or header compressible field that is mapped to a DRB or PDCP entity is called a flow, that is, an Ethernet flow .
  • the PDCP PDU/SDU with a sequence number (or COUNT) of 0, 2, 4, 6, 8 carries the same header or compressible fields in the Ethernet frame or packet (that is, belongs to the same Ethernet Flow), then they will be mapped to the same CID, such as CID1; PDCP with sequence number (or COUNT) of 1, 3, 5, 7, 9 PDCP PDU/SDU carrying Ethernet frame header or header compressible field The same (that is, belong to another Ethernet stream), they will also be mapped to the same CID, such as CID2.
  • the sender of the PDCP entity sends a PDCP PDU with a sequence number (or COUNT) of 0, which carries information used to establish a context, that is, carries CID1 and a complete Ethernet header.
  • the PDCP entity transmitter sends a PDCP PDU with a sequence number (or COUNT) of 1, which carries information for establishing context, that is, carries CID2 and a complete Ethernet header.
  • the PDCP entity sender has not received a PDCP PDU with a sequence number (or COUNT) of 0 from the lower layer when sending a PDCP PDU with a sequence number (or COUNT) of 2 or has not received an EHC feedback from CID1, Then, the PDCP SDU or Ethernet frame or Ethernet packet with the serial number (or COUNT) of 2 is not header compressed, that is, the PDCP PDU with the serial number (or COUNT) of 2 also includes CID1 and a complete Ethernet header.
  • the PDCP entity sender receives a PDCP PDU with a sequence number (or COUNT) of 1 from the lower layer before sending a PDCP PDU with a sequence number (or COUNT) of 1 or a CID2 EHC feedback
  • the sequence number ( Or COUNT) is 3 PDCP SDU or Ethernet frame or Ethernet packet header compression, that is, the PDCP PDU with sequence number (or COUNT) 3 only contains CID2 and/or part of the Ethernet header that does not need to be compressed ( If it exists).
  • the context information in the present disclosure refers to the mapping relationship between the context identifier CID and the Ethernet header or the compressible field of the header.
  • the PDCP PDU used to establish context information means that the PDCP PDU carries a complete Ethernet header and the context identifier CID corresponding to the header or the compressible field of the header.
  • the EHC compression end is included in the PDCP entity sending end, and the EHC decompression end is included in the PDCP entity receiving end. Therefore, in the present disclosure, when the EHC header compression operation is involved, the EHC compression terminal and the PDCP entity sending terminal can be used interchangeably, and when the EHC decompression operation is involved, the EHC decompression terminal and the PDCP entity receiving terminal can be used interchangeably.
  • new fields can be defined in the PDCP header to indicate EHC related information, such as the CID field and the indication field of the load type; a new EHC header can also be defined, when the PDCP entity transmitter is configured with uplink EHC And/or when EHC is downlink, the EHC header is carried in the PDCP PDU, otherwise it is not carried.
  • the EHC header includes at least: a CID field and a load type indication field, 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.
  • the load type indication field is 1 (or 0)
  • the value of the indication field of the load type is 0 (or 1)
  • associating the context identifier CID with the Ethernet header or establishing a mapping relationship refers to combining a CID with a specific value with a compressible field of the Ethernet header (that is, the compressible field of the Ethernet header) A value of the compressed field).
  • the compressible fields of the Ethernet header may include one or more of the following fields: destination address (DESTINATION ADDRESS), source address (SOURCE ADDRESS), type/length (TYPE/ LENGTH), Q-TAGs.
  • the Q-TAGs field may include the following fields: VLAN identification VID field, PRI field indicating the priority of the Ethernet frame, frame type field TPID, and DEI field used to indicate whether it is discardable.
  • the context identifier CID contained in the information used to establish the context described in the present disclosure is not an uncompressed indication.
  • the uncompressed indication may be predefined or configured with a value through an RRC message to indicate that the PDCP PDU carrying the CID value is not compressed.
  • the CID field of the PDCP PDU (also called Ethernet packet or frame or data packet or compressed packet) is set to a predefined value (for example, 0) or a configured value, it means that the Ethernet packet or frame or The data packet or PDCP PDU carries a complete Ethernet header.
  • the PDCP entity receiving end uses EHC for decompression, if the CID field in the received PDCP PDU is set to the predefined or configured value, the PDCP entity receiving end does not store the mapping relationship between the CID and the Ethernet header .
  • This pre-defined or RRC configured value is used when the PDCP entity sender thinks that the Ethernet header does not need to be compressed (or there is no available CID value or all CID values except this value have been established with the Ethernet Header mapping relationship) set the CID field of the PDCP PDU to this predefined or RRC configured value.
  • the load of PDCP PDU in this disclosure is the data field of PDCP PDU, and the data field is one of the following: uncompressed PDCP SDU (for example, user plane data or control plane data), compressed PDCP SDU (currently Only applicable to user plane data).
  • step T1 when the PDCP entity receiving end receives a new PDCP PDU or PDCP SDU for establishing context information, in step T2, trigger or generate the corresponding EHC
  • the feedback includes the context identifier CID carried or associated in this PDCP PDU or PDCP SDU and/or the sequence number or COUNT of this PDCP PDU or PDCP SDU.
  • step T3 for each context identifier or each received context identifier CID or each CID that triggered/generated EHC feedback or each PDCP that generated/triggered EHC feedback PDU/PDCP
  • the SDU (or the CID it carries) or the context identifier CID of each established context information defines a variable CID_Flag
  • the CID_Flag is used to store the currently received context information used to establish the context (that is, the latest context information corresponding to the CID)
  • the sequence number (or COUNT) of the PDCP PDU or PDCP SDU; or the CID_Flag is used to store the minimum value of the PDCP PDU or PDCP SDU currently received for establishing context information (that is, the latest context information corresponding to the CID) Sequence number (or COUNT); or the CID_Flag is used to store the sequence number (or COUNT) of the PDCP PDU or PDCP SDU that triggered EHC feedback; or the CID_Flag is used to store the PD
  • the sequence number (or COUNT) of the received PDCP PDU or PDCP SDU is less than the current CID_Flag but the context information carried is the same as the context information corresponding to the CID_Flag (that is, the Ethernet header or corresponding Ethernet header or corresponding context identifier CID mapped/ The compressible fields of the header are the same)
  • step T4 for the received PDCP PDU with a sequence number (or COUNT) less than CID_Flag and the PDCP PDU contains a compressed PDCP SDU or Ethernet frame or Ethernet packet, the old context is used Information (that is, the old Ethernet header or header compressible field corresponding to the context identifier) is decompressed; if the received sequence number (or COUNT) is greater than the PDCP PDU with CID_Flag and the PDCP PDU contains compressed PDCP The SDU or Ethernet frame or Ethernet message is decompressed using the new context information.
  • the old context information is deleted.
  • the context information is updated.
  • the PDCP entity receiving end receives the PDCP PDU or PDCP SDU that maps the current context identifier CID to the new Ethernet header or header compressible field, assuming that its sequence number (or COUNT) is N, If there is a PDCP PDU or a PDCP SDU with 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.
  • the PDCP status report can also be used as EHC feedback.
  • the PDCP entity receiving end receives a new PDCP PDU or PDCP SDU for establishing context information
  • the PDCP status report is triggered or generated.
  • the context identifier CID associated or defined with the variable CID_Flag is not an uncompressed indication.
  • the PDCP entity receiving end receives a new PDCP PDU or PDCP SDU for context establishment, if all sequence numbers (or COUNT) are less than the sequence number (or COUNT) of this PDCP PDU or PDCP SDU If the PDCP PDU or PDCP SDU has been received and/or successfully decompressed, the corresponding EHC feedback is generated, which contains the context identifier CID carried or associated in the PDCP PDU or PDCP SDU and/or the sequence of the PDCP PDU or PDCP SDU Number or COUNT value. Optionally, submit the generated EHC feedback to the lower layer.
  • CID_Flag can be defined (its meaning is the same as in the previous embodiment).
  • the predefined EHC feedback is only applicable to UM DRB.
  • the PDCP entity sender After receiving the EHC feedback, the PDCP entity sender performs header compression for the PDCP SDU or Ethernet frame or Ethernet packet in the Ethernet stream corresponding to the EHC feedback or its corresponding CID.
  • the base station can configure whether to use EHC feedback for the user equipment UE through RRC messages or signaling (this is for DRB or PDCP entities configured with EHC, and uplink and downlink can be configured separately).
  • the RRC message includes an indication cell ehcFeedback.
  • the PDCP entity receiving end sends EHC feedback or satisfies the conditions described in the embodiment.
  • the cell ehcFeedback_UL for uplink and the cell ehcFeedback_DL for downlink are required.
  • the meaning of the cell is the same as ehcFeedback, but it is only applied to uplink or downlink.
  • the base station may configure the user equipment UE whether to use EHC feedback or to send multiple times through RRC messages or signaling.
  • the RRC message contains an indication cell reliableTransmission, and this cell contains the ehcFeedback cell and the multiTrans cell. The base station can only select one of these two cells when configuring the UE.
  • the PDCP entity receiving end sends EHC feedback or sends EHC feedback when the conditions described in the embodiment are met; when the information element multiTrans appears and The value is n (the value of n is an integer greater than or equal to 1), then for PDCP SDU or PDCP PDU or Ethernet frame or Ethernet packet from the same Ethernet stream, the PDCP entity sending end sends n carry After the context identifier CID and the PDCP PDU (uncompressed) of the complete Ethernet header, the PDCP PDU carrying the compressed PDCP SDU or Ethernet frame or Ethernet packet is sent.
  • the same reliableTransmission and multiTrans can also be configured separately for uplink and downlink.
  • the uplink cells reliableTransmission_UL and multiTrans_UL and the downlink cells reliableTransmission_DL and multiTrans_DL are required.
  • the meaning of the cells is the same as that of reliableTransmission and multiTrans, but only applies to uplink or downlink.
  • the ehcFeedback information element is used to instruct the PDCP entity receiving end to send EHC feedback
  • the multiTrans information element is used to instruct the PDCP entity transmitting end to send a PDCP PDU carrying the context identifier CID and the complete Ethernet header when establishing a context information. quantity.
  • Fig. 4 shows a schematic structural block diagram of a PDCP entity of an embodiment of the present disclosure.
  • 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 may be controlled by the processor to control the receiver 401 to execute the above-mentioned FIG. 1 of the present disclosure and/or the processor to control the transmitter 402 to execute The method described in Figure 2 of the present disclosure.
  • Fig. 5 shows a schematic structural block diagram of a communication device according to an embodiment of the present disclosure.
  • 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, and the like.
  • the memory 502 may include, for example, volatile memory (such as random access memory RAM), hard disk drive (HDD), non-volatile memory (such as flash memory), or other memory systems.
  • the memory 502 stores program instructions. When the instruction is executed by the processor 501, it can execute the method described in FIG. 1 and/or FIG. 2 of the present disclosure.
  • the computer-executable instructions or program running on the device according to the present disclosure may be a program that enables the computer to implement the functions of the embodiments of the present disclosure by controlling a central processing unit (CPU).
  • the program or the information processed by the program can be temporarily stored in volatile memory (such as random access memory RAM), hard disk drive (HDD), non-volatile memory (such as flash memory), or other memory systems.
  • Computer-executable instructions or programs for implementing the functions of various embodiments of the present disclosure may be recorded on a computer-readable storage medium. Corresponding functions can be realized by causing the computer system to read the programs recorded on the recording medium and execute these programs.
  • the so-called “computer system” herein may be a computer system embedded in the device, and may include an operating system or hardware (such as peripheral devices).
  • the "computer-readable storage medium” may be a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a recording medium storing a program dynamically for a short period of time, or any other recording medium readable by a computer.
  • circuits for example, single-chip or multi-chip integrated circuits.
  • Circuits designed to perform the functions described in this specification can include general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete Gate or transistor logic, discrete hardware components, or any combination of the above devices.
  • the general-purpose processor may be a microprocessor, or any existing processor, controller, microcontroller, or state machine.
  • the above circuit can be a digital circuit or an analog circuit. In the case of new integrated circuit technologies that replace existing integrated circuits due to advances in semiconductor technology, one or more embodiments of the present disclosure may also be implemented using these new integrated circuit technologies.
  • the present disclosure is not limited to the above-mentioned embodiment. Although various examples of the embodiment have been described, the present disclosure is not limited thereto.
  • Fixed or non-mobile electronic equipment installed indoors or outdoors can be used as terminal equipment or communication equipment, such as AV equipment, kitchen equipment, cleaning equipment, air conditioning, office equipment, vending machines, and other household appliances.

Landscapes

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

Abstract

本公开提供了一种PDCP实体发送端/接收端的执行方法、PDCP实体及通信设备，所述方法包括：发送携带用于建立上下文信息的第一分组数据汇聚协议协议数据单元即第一PDCP PDU；在接收到来自下层的针对该第一PDCP PDU递送成功的指示的情况下，对与该第一PDCP PDU属于同一个流的第一分组数据汇聚协议服务数据单元即第一PDCP SDU、或第一以太网帧、或第一以太网报文进行以太网头压缩EHC；发送负载为被所述EHC后的第二PDCP SDU、或第二以太网帧、或第二以太网报文的第二PDCP PDU。

Description

PDCP实体发送端/接收端的执行方法、PDCP实体及通信设备 技术领域
本公开涉及无线通信技术领域，更具体地，本公开涉及PDCP实体发送端/接收端的执行方法、PDCP实体及通信设备。
背景技术
2019年3月，在第三代合作伙伴计划(3rd Generation Partnership Project：3GPP)RAN#83次全会上批准了一个支持NR工业物联网的工作项目(参见RP-190728：New WID：Support of NR Industrial Internet of Things(IoT))。该工作项目的目标之一是定义基于结构感知(structure-aware)算法的以太网头压缩协议。以太网头压缩是一种减少以太网头传输带来的开销的方法，以太网帧可以通过5G系统以以太网PDU会话类型传输。在基于以太网的工业物联网网络中，有效负载大小相对于帧的整体大小相对较小，因此对以太网帧头部进行压缩可以提高传输效率、减少延迟。
在2019年4月召开的3GPP RAN2#105bis次会议上达成：将100％的在3GPP定义以太网头压缩(Ethernet Header Compression，EHC)机制。在2019年5月召开的3GPP RAN2 #106次会议上达成：对每个数据无线承载DRB的上行和下行分别单独配置以太网头压缩协议；压缩端(Compressor)和解压端(Decompressor)采用上下文标识(Context ID)的概念将一个上下文标识与以太网头部内容(Ethernet header contents)关联；且EHC基于以下机制：对于产生新上下文的以太网流，压缩端至少发送一个包含完整头部和上下文标识的报文/帧，以便于解压端建立上下文，之后压缩端传输压缩后的报文/帧；以太网头压缩产生的数据包的头部至少包括以下字段：上下文标识，用于指示本数据包的头部格式的指示标识(即指示本数据包的头部是完整头部还是压缩后的头部)。此外，在3GPP RAN2 #106次会议上对EHC解压端在接收到用于建立上下文的PDCP PDU后是否需要反馈(feedback)进行了讨论，但没有达成一致结论。
基于以上结论，本公开讨论以太网头压缩所涉及的相关问题及解决方案，具体包括：PDCP实体发送端(或EHC压缩端)在采用EHC机制进行头压缩时，发送用于建立上下文的PDCP PDU后，如何确定是否发送压缩包；PDCP实体接收端在接收到用于建立或更新上下文信息的PDCP PDU后，何时发送反馈？如何解压序列号(或COUNT)小于更新上下文信息的PDCP PDU的序列号(或COUNT)的携带压缩后的报文/帧的PDCP PDU？
发明内容
为了解决上述问题中的至少一部分，本公开提供了一种PDCP实体发送端/接收端的执行方法、PDCP实体及通信设备。
根据本公开的第一方面的PDCP实体发送端的执行方法，包括：发送携带用于建立上下文信息的第一分组数据汇聚协议协议数据单元即第一PDCP PDU；在接收到来自下层的针对该第一PDCP PDU递送成功的指示的情况下，对与该第一PDCP PDU属于同一个流的第一分组数据汇聚协议服务数据单元即第一PDCP SDU、或第一以太网帧、或第一以太网报文进行以太网头压缩EHC；发送负载为被所述EHC后的第二PDCP SDU、或第二以太网帧、或第二以太网报文的第二PDCP PDU。
根据本公开的第一方面的方法，所述进行以太网头压缩EHC，包括：判断所述第一PDCP SDU、或所述第一以太网帧、或所述第一以太网报文的以太网头部或头部可压缩字段是否映射了或被分配了上下文标识CID；在判断为已映射或已分配了所述CID的情况下，判断是否接收到该CID对应的上下文已建立的确认；在判断为接收到所述确认的情况下，对所述第一PDCP SDU、或所述第一以太网帧、或所述第一以太网报文进行所述EHC。
根据本公开的第一方面的方法，在判断为已映射或已分配了所述CID、但未接收到所述确认的情况下，不进行所述EHC。
根据本公开的第一方面的方法，所述判断是否接收到该CID对应的上下文已建立的确认，包括：判断是否接收到所述CID的正反馈或负反馈、判断是否接收到来自下层的针对该第一PDCP PDU递送成功的指示。
根据本公开的第二方面的PDCP实体接收端的执行方法，在接收到新的用于建立上下文信息的分组数据汇聚协议协议数据单元PDCP PDU或分 组数据汇聚协议服务数据单元PDCP SDU时，触发或生成对应的以太网头压缩EHC反馈，其中，所述EHC反馈包含所述PDCP PDU或所述PDCP SDU中携带或关联的上下文标识CID和/或该PDCP PDU或PDCP SDU的序列号或COUNT。
根据本公开的第二方面的方法，为每个所述CID或每个触发了/生成了EHC反馈的CID或每个接收到的所述CID或每个已建立上下文信息的所述CID定义一个变量CID_Flag，所述CID_Flag用于存储当前接收到的用于建立上下文信息的所述PDCP PDU或所述PDCP SDU的序列号或COUNT；或者所述CID_Flag用于存储当前接收到的用于建立上下文信息的所述PDCP PDU或PDCP SDU的最小序列号或COUNT；或者所述CID_Flag用于存储触发了EHC反馈的PDCP PDU或PDCP SDU的序列号或COUNT。
根据本公开的第二方面的方法，当接收到的所述PDCP PDU或所述PDCP SDU的所述序列号或所述COUNT小于当前CID_Flag、但携带的所述上下文信息与所述CID_Flag对应的上下文信息相同，则更新所述CID_Flag为当前PDCP PDU或当前PDCP SDU的序列号或COUNT。
根据本公开的第二方面的方法，如果对于接收到的所述序列号或所述COUNT小于当前CID_Flag的所述PDCP PDU且所述PDCP PDU包含压缩后的PDCP SDU或以太网帧或以太网报文，则利用旧的上下文信息进行解压；如果对于接收到的所述序列号或所述COUNT大于当前CID_Flag的所述PDCP PDU且所述PDCP PDU包含压缩后的PDCP SDU或以太网帧或以太网报文，则利用新的上下文信息进行解压。
根据本公开的第三方面的PDCP实体，包括：发送端和接收端，所述发送端执行上述第一方面的所述方法；和/或所述接收端执行上述第二方面的所述方法。
根据本公开的第四方面的通信设备，是具有分组数据汇聚协议PDCP实体的通信设备，包括：处理器；以及存储器，存储有指令；其中，所述指令在由所述处理器运行时执行上述第一方面的所述方法和/或上述第二方面的所述方法。
附图说明
通过下文结合附图的详细描述，本公开的上述和其它特征将会变得更加明显，其中：
图1是示意性示出COUNT的格式的示意图。
图2是示意性示出本公开的一个实施例的采用EHC机制时PDCP实体发送端发送PDCP PDU的方法的简要流程图。
图3是示意性示出本公开的一个实施例的PDCP实体接收端发送EHC反馈的方法的简要流程图。
图4示意性示出了本公开的一个实施例的PDCP实体的简要结构框图。
图5示意性示出了本公开的一个实施例的通信设备的简要结构框图。
具体实施方式
下面结合附图和具体实施方式对本公开进行详细阐述。应当注意，本公开不应局限于下文所述的具体实施方式。另外，为了简便起见，省略了对与本公开没有直接关联的公知技术的详细描述，以防止对本公开的理解造成混淆。
下面描述本公开涉及的部分术语，如未特别说明，所述术语与3GPP协议当前最新版本中采用的术语相同，现摘录如下。
EHC：Ethernet Header Compression，以太网头压缩。
COUNT：其长度为32比特，COUNT值由超帧号HFN和PDCP序列号SN组成(如图1所示)，HFN的大小为32减去PDCP序列号SN长度。
DRB：Data Radio Bearer，数据无线承载。
RRC：Radio Resource Control，无线资源控制。
PDCP：Packet Data Convergence Protocol，分组数据汇聚协议。
SDAP：Service Data Adaptation Protocol，服务数据适应协议。
RLC：Radio Link Control，无线链路控制。RLC实体可以配置为采用以下三种模式之一进行数据传输：透传模式TM、非确认模式UM或确认模式AM。
MAC：Medium Access Control，媒体访问控制。
AM DRB：使用RLC AM的DRB(a data radio bearer which utilizes RLC AM)。
UM DRB：使用RLC UM的DRB。
SDU：Service Data Unit，服务数据单元。
PDU：Protocol Data Unit，协议数据单元。
在本公开中，将从上层接收或递送(deliver)上层的数据称为SDU，将提交(submit)下层或从下层接收的数据称为PDU。例如，PDCP实体从上层接收的数据或传送上层的数据称为PDCP SDU；PDCP实体从RLC实体接收到的数据或提交RLC实体的数据称为PDCP PDU(也就是RLC SDU)。
在现有的LTE和/或NR系统中，对于AM DRB，AM RLC实体发送端在接收到一个RLC SDU的肯定确认(positive acknowledgement)后，向上层(即PDCP层)发送RLC SDU成功递送的指示。换言之，对于AM DRB，PDCP实体期望从下层(即RLC层)接收PDCP PDU递送成功的指示。
以下描述采用EHC机制时PDCP实体发送端发送PDCP PDU的方法
下面，参照附图2来描述采用EHC机制时PDCP实体发送端发送PDCP PDU的方法的一个实施例。
在一个实施例中，如图2所示，在步骤S1中，PDCP实体发送端发送携带用于建立上下文信息的PDCP PDU后，经由步骤S2和步骤S3，如果接收到来自下层的针对该PDCP PDU递送成功的指示，则PDCP实体发送端开始发送携带压缩后的PDCP SDU或以太网帧或以太网报文的PDCP PDU(这个PDCP PDU和所述被确认递送成功的携带建立上下文信息的PDCP PDU的以太网头部或头部可压缩字段相同，即它们属于同一个流)。换言之，在接收到来自下层的针对携带用于建立上下文信息的PDCP PDU递送成功的指示之前，所有与该PDCP PDU或其负载的以太网头部或头部可压缩字段相同的PDCP PDU或PDCP SDU或以太网帧或以太网报文都不进行头压缩(即其中携带CID和完整以太网头部)。只有在收到来自下层的针对第一个或其中任意一个(这里是指属于同一个流的PDCP PDU或PDCP SDU或以太网帧或以太网报文)携带用于建立上下文信息的PDCP PDU递送成功的指示之后才对属于同一个流的PDCP SDU或以太网报文或以太网帧进行头压缩。
PDCP实体发送端对PDCP SDU或以太网帧或以太网报文执行EHC头 压缩的操作可以简要描述如下：
PDCP实体发送端判断PDCP SDU(或以太网帧或以太网报文)的以太网头部或头部可压缩字段是否映射或被分配了一个上下文标识CID；如果已映射或分配了上下文标识CID，再判断是否接收到了该CID对应的上下文已建立的确认。如果已映射或分配了上下文标识CID，但还没有接收到该CID对应的上下文已建立的确认(例如，没有收到来自下层的第一个或同一个流中的任意一个携带用于建立上下文信息的PDCP PDU递送成功的指示，或没有收到该CID的反馈)，则不对该PDCP SDU或以太网帧或以太网报文进行头压缩，即在PDCP SDU或以太网帧或以太网报文对应的PDCP PDU中携带对应的CID和完整的以太网头部；如果已映射或分配了上下文标识CID，且接收到了该CID对应的上下文已建立的确认(例如，收到来自下层的第一个或同一个流中的任意一个携带CID和完整以太网头部的PDCP PDU递送成功的指示，或收到该CID的反馈)，则对该PDCP SDU或以太网帧或以太网报文进行头压缩，即移除PDCP SDU或以太网帧或以太网报文中可压缩头部，在其对应的PDCP PDU中携带对应的CID和/或部分不需要压缩的以太网头部(如果存在的话)。所述CID对应的上下文已建立的确认是以下之一：收到来自下层的第一个或同一个流中的任意一个携带用于建立上下文信息的PDCP PDU递送成功的指示、收到该CID的反馈。可以预定义PDCP实体仅支持其中一种确认；或者预定义对应AM DRB的PDCP实体支持的CID对应的上下文已建立的确认为收到来自下层的第一个或同一个流中的任意一个携带用于建立上下文信息的PDCP PDU递送成功的指示，对应UM DRB的PDCP实体支持的CID对应的上下文已建立的确认为收到该CID的反馈。
在本公开中，CID的反馈(也可称为反馈或EHC反馈)是指PDCP接收端针对接收到的包含上下文标识CID和完整以太网头部(即用于建立上下文信息)的PDCP PDU或PDCP SDU生成的确认，所述确认可以是一个PDCP控制PDU，其中可以包含该上下文标识CID和/或该PDCP PDU或PDCP SDU(或触发确认的PDCP PDU或PDCP SDU的)的序列号或COUNT。本公开中所述EHC反馈都是指正反馈，表示PDCP实体接收端已经建立的 对应CID的上下文信息。如果EHC反馈也包含负反馈，例如在EHC反馈对应的PDCP控制PDU中包含一个字段用于指示是正反馈还是负反馈(即对应CID或SN或COUNT的正反馈或负反馈)，例如，所述字段占1比特，当所述字段取值为1时表示正反馈，所示字段取值为0时表示负反馈，反之亦然，当PDCP实体发送端接收到负反馈的EHC反馈时，需要重新发送携带CID和完整以太网头部的PDCP PDU来建立上下文信息。
在本公开中，将映射到一个DRB或PDCP实体的具有相同以太网头部或头部可压缩字段的PDCP SDU或以太网帧或以太网报文称为一个流(flow)，即以太网流。
例如，假设序列号(或COUNT)为0，2，4，6，8的PDCP PDU/SDU中携带的以太网帧或报文的头部或头部可压缩字段相同(即属于同一个以太网流)，那么它们将映射到同一个CID，例如CID1；序列号(或COUNT)为1，3，5，7，9的PDCP PDU/SDU携带的以太网帧的头部或头部可压缩字段相同(即属于另一个以太网流)，它们也将映射到同一个CID，例如CID2。首先，PDCP实体发送端发送序列号(或COUNT)为0的PDCP PDU，其中携带用于建立上下文的信息，即携带CID1和完整的以太网头部。接着，PDCP实体发送端发送序列号(或COUNT)为1的PDCP PDU，其中携带用于建立上下文的信息，即携带CID2和完整的以太网头部。如果PDCP实体发送端在发送序列号(或COUNT)为2的PDCP PDU时还没有收到来自下层的序列号(或COUNT)为0的PDCP PDU递送成功的指示或没有接收到CID1的EHC反馈，则不对序列号(或COUNT)为2的PDCP SDU或以太网帧或以太网报文进行头压缩，即序列号(或COUNT)为2的PDCP PDU中也包含CID1和完整的以太网头部。如果PDCP实体发送端在发送序列号(或COUNT)为3的PDCP PDU前收到了来自下层的序列号(或COUNT)为1的PDCP PDU递送成功的指示或CID2的EHC反馈，则对序列号(或COUNT)为3的PDCP SDU或以太网帧或以太网报文进行头压缩，即序列号(或COUNT)为3的PDCP PDU中仅包含CID2和/或部分不需要压缩的以太网头部(如果存在的话)。
本公开所述上下文信息是指上下文标识CID与以太网头部或头部可压缩字段间的映射关系。携带用于建立上下文信息的PDCP PDU是指该PDCP PDU中携带了完整的以太网头部以及该头部或头部可压缩字段对应的上下 文标识CID。
在本公开中，对于采用EHC头压缩机制的PDCP实体而言，EHC压缩端包含在PDCP实体发送端，EHC解压端包含在PDCP实体接收端。因此，本公开中，涉及EHC头压缩操作时，EHC压缩端和PDCP实体发送端可互换使用，涉及EHC解压缩操作时，EHC解压端和PDCP实体接收端可互换使用。
在本公开中，可以在PDCP头部定义新的字段用于指示EHC相关信息，例如CID字段、负载类型的指示字段；也可以定义新的EHC头部，当PDCP实体发送端被配置了上行EHC和/或下行EHC时，PDCP PDU中携带EHC头部，否则不携带。所述EHC头部至少包括：CID字段和负载类型的指示字段，还可以包括未压缩的以太网头部字段。所述负载类型指示字段用于指示PDCP PDU或其负载是否进行了压缩，例如，如果负载类型的指示字段取值为1(或0)表示对应的PDCP PDU的数据域是未压缩的PDCP SDU；如果负载类型的指示字段取值为0(或1)表示对应的PDCP PDU的数据域是压缩后的PDCP SDU。
需要说明的是，在本公开中，上下文标识CID与以太网头部关联或建立映射关系是指将一个特定取值的CID与一个以太网头部的可压缩字段(即以太网头部的可压缩字段的一个取值)关联起来。所述以太网头部可压缩字段(也称以太网头部需要压缩的字段)可以包括以下一个或多个字段：目的地址(DESTINATION ADDRESS)、源地址(SOURCE ADDRESS)、类型/长度(TYPE/LENGTH)、Q-TAGs。其中Q-TAGs字段可包括以下字段：VLAN标识VID字段、指示以太网帧优先级的PRI字段、帧类型字段TPID、用于指示是否可丢弃的DEI字段。本公开所述用于建立上下文的信息包含的上下文标识CID不是未压缩指示。所述未压缩指示可以预定义或通过RRC消息配置一个值用来表示携带该CID值的PDCP PDU未压缩。换言之，当PDCP PDU(也可称为以太网报文或帧或数据包或压缩包)的CID字段设置为预定义的值(例如，0)或配置的值时表示以太网报文或帧或数据包或PDCP PDU中携带完整的以太网头部。在PDCP实体接收端在采用EHC进行解压缩时，如果接收到的PDCP PDU中的CID字段被设置 为所述预定义或配置的值，PDCP实体接收端不存储CID与以太网头部的映射关系。这个预定义或RRC配置的值用于当PDCP实体发送端认为不需要对这个以太网头部进行压缩(或没有可用的CID值或除这个值之外的所有CID值都已经建立了与以太网头部的映射关系)时将PDCP PDU的CID字段设置为这个预定义或RRC配置的值。
需要说明的是本公开中PDCP PDU的负载是PDCP PDU的数据域，所述数据域是以下之一：未压缩的PDCP SDU(例如用户面数据或控制面数据)、压缩后的PDCP SDU(目前仅适用于用户面数据)。
以下描述PDCP实体接收端发送EHC反馈的方法
下面，参照附图3来描述PDCP实体接收端发送EHC反馈的方法的一个实施例。
在一个实施例中，如图3所示，在步骤T1中，PDCP实体接收端接收到一个新的用于建立上下文信息的PDCP PDU或PDCP SDU时，在步骤T2中，触发或生成对应的EHC反馈，其中包含这个PDCP PDU或PDCP SDU中携带或关联的上下文标识CID和/或这个PDCP PDU或PDCP SDU的序列号或COUNT。
另外，还可以在步骤T3中，为每个上下文标识或每个接收到的上下文标识CID或每个触发了/生成了EHC反馈的CID或每个生成了/触发了EHC反馈的PDCP PDU/PDCP SDU(或其携带的CID)或每个已建立上下文信息的上下文标识CID定义一个变量CID_Flag，所述CID_Flag用于存储当前接收到的用于建立上下文信息(即该CID对应的最新的上下文信息)的PDCP PDU或PDCP SDU的序列号(或COUNT)；或者所述CID_Flag用于存储当前已接收到的用于建立上下文信息(即该CID对应的最新的上下文信息)的PDCP PDU或PDCP SDU的最小序列号(或COUNT)；或者所述CID_Flag用于存储触发了EHC反馈的PDCP PDU或PDCP SDU的序列号(或COUNT)；或者所述CID_Flag用于存储为其产生了EHC反馈的PDCP PDU或PDCP SDU的序列号(或COUNT)。可选的，当接收到的PDCP PDU或PDCP SDU的序列号(或COUNT)小于当前CID_Flag但携带的上下文信息与CID_Flag对应的上下文信息相同(即上下文标识CID所映射/对应的以太网头部或头部可压缩字段相同)，则更新CID_Flag为当前PDCP PDU 或PDCP SDU的序列号(或COUNT)。
另外，还可以在步骤T4中，对于接收到的序列号(或COUNT)小于CID_Flag的PDCP PDU且所述PDCP PDU包含压缩后的PDCP SDU或以太网帧或以太网报文，则利用旧的上下文信息(即该上下文标识对应的旧的以太网头部或头部可压缩字段)进行解压；如果对于接收到的序列号(或COUNT)大于CID_Flag的PDCP PDU且所述PDCP PDU包含压缩后的PDCP SDU或以太网帧或以太网报文，则利用新的上下文信息进行解压。可选的，当所有序列号(或COUNT)小于CID_Flag的PDCP PDU均已收到，则删除旧的上下文信息。可选的，只有当所有序列号(或COUNT)小于CID_Flag的PDCP PDU或PDCP SDU均已收到和/或正确解压，才更新上下文信息。在这种情况下，虽然PDCP实体接收端接收到将当前上下文标识CID映射到新的以太网头部或头部可压缩字段的PDCP PDU或PDCP SDU，假设其序列号(或COUNT)为N，如果存在序列号(或COUNT)小于N的PDCP PDU或PDCP SDU尚未接收到，则PDCP实体接收端并不更新该CID对应的上下文信息。换言之，只有当序列号(或COUNT)小于N的所有PDCP PDU或PDCP SDU均已接收到，才更新该CID对应的上下文信息；或者，只有当序列号(或COUNT)小于N的所有PDCP PDU或PDCP SDU均已接收到，才更新该CID对应的上下文信息，除非该CID尚未映射到任何的以太网头部或头部可压缩字段(即首次为该CID生成对应的上下文)。
此外，PDCP状态报告也可以做为EHC反馈，在这种情况下，当PDCP实体接收端接收到一个新的用于建立上下文信息的PDCP PDU或PDCP SDU时，触发或生成PDCP状态报告。
在本公开实施例中，如未特别说明，所述关联或定义了变量CID_Flag的上下文标识CID不是未压缩指示。
在一个实施例中，PDCP实体接收端在接收到一个新的用于建立上下文的PDCP PDU或PDCP SDU时，如果所有序列号(或COUNT)小于这个PDCP PDU或PDCP SDU的序列号(或COUNT)的PDCP PDU或PDCP SDU均已接收到和/或成功解压，则生成对应的EHC反馈，其中包含这个PDCP PDU或PDCP SDU中携带或关联的上下文标识CID和/或这个PDCP PDU或PDCP SDU的序列号或COUNT值。可选的，将生成的EHC反馈递交给 下层。与前一实施例一样，可以定义CID_Flag(其含义与前一实施例相同)，当所有序列号(或COUNT)小于CID_Flag的PDCP PDU或SDU均已接收到和/或成功解压，生成对应的EHC反馈，可选的，递交给下层。由于UM DRB可能产生丢包，因此，这个方案可以仅应用于AM DRB。
可选的，预定义EHC反馈仅应用于UM DRB。
PDCP实体发送端在接收到该EHC反馈后，针对该EHC反馈或其对应的CID对应的以太网流中的PDCP SDU或以太网帧或以太网报文执行头压缩。
在一个实施例中，基站可以通过RRC消息或信令为用户设备UE配置是否采用EHC反馈(这是对于配置了EHC的DRB或PDCP实体而言，且上行和下行可以分别配置)。具体地，在RRC消息中包含一个指示信元ehcFeedback，当所述信元取值为1或true或真或所述信元出现，则PDCP实体接收端发送EHC反馈或在满足实施例所述条件时发送EHC反馈；当所述信元取值为0或false或假或所述信元不出现，则PDCP实体接收端发送EHC反馈或在满足实施例所述条件时发送EHC反馈；反之亦然。如果上下行分别配置，则需要针对上行的信元ehcFeedback_UL和针对下行的信元ehcFeedback_DL，信元的含义与ehcFeedback相同，但仅应用于上行或下行。
在一个实施例中，基站可以通过RRC消息或信令为用户设备UE配置是采用EHC反馈还是发送多次。具体地，在RRC消息中包含一个指示信元reliableTransmission，这个信元中包含ehcFeedback信元和multiTrans信元。基站为UE配置时只能从这两个信元中选择一个。当所述ehcFeedback信元取值为1或true或真或所述信元出现，则PDCP实体接收端发送EHC反馈或在满足实施例所述条件时发送EHC反馈；当所述信元multiTrans出现且取值为n(n的取值为大于等于1的整数)，则对于来自同一个以太网流中的PDCP SDU或PDCP PDU或以太网帧或以太网报文，PDCP实体发送端发送n个携带上下文标识CID和完整以太网头部的PDCP PDU(未压缩)后发送携带压缩后的PDCP SDU或以太网帧或以太网报文的PDCP PDU。同样的reliableTransmission和multiTrans也可以上行和下行分别配置。如果上下行分别配置，则需要针对上行的信元reliableTransmission_UL和 multiTrans_UL和针对下行的信元reliableTransmission_DL和multiTrans_DL，信元的含义与reliableTransmission和multiTrans相同，但仅应用于上行或下行。
所述ehcFeedback信元用于指示PDCP实体接收端发送EHC反馈，所述multiTrans信元用于指示PDCP实体发送端在建立一个上下文信息时需要发送的携带上下文标识CID和完整以太网头部的PDCP PDU的数量。
图4示出了本公开实施例的PDCP实体的简要结构框图。
如4所示，该PDCP实体400至少包括接收端401和发送端402。而且，该PDCP实体400例如既可以包含于客户端设备，也可以包含于基站设备，且可以由处理器控制接收端401执行本公开的上述图1和/或由处理器控制发送端402来执行本公开的图2所描述的方法。
图5示出了根据本公开实施例的通信设备的简要结构框图。
如图5所示，该通信设备500至少包括处理器501和存储器502。处理器501例如可以包括微处理器、微控制器、嵌入式处理器等。存储器502例如可以包括易失性存储器(如随机存取存储器RAM)、硬盘驱动器(HDD)、非易失性存储器(如闪速存储器)、或其他存储器系统等。存储器502上存储有程序指令。该指令在由处理器501运行时，可以执行本公开的上述图1和/或图2所描述的方法。
运行在根据本公开的设备上的计算机可执行指令或者程序可以是通过控制中央处理单元(CPU)来使计算机实现本公开的实施例功能的程序。该程序或由该程序处理的信息可以临时存储在易失性存储器(如随机存取存储器RAM)、硬盘驱动器(HDD)、非易失性存储器(如闪速存储器)、或其他存储器系统中。
用于实现本公开各实施例功能的计算机可执行指令或程序可以记录在计算机可读存储介质上。可以通过使计算机系统读取记录在所述记录介质上的程序并执行这些程序来实现相应的功能。此处的所谓“计算机系统”可以是嵌入在该设备中的计算机系统，可以包括操作系统或硬件(如外围设备)。“计算机可读存储介质”可以是半导体记录介质、光学记录介质、磁性记录介质、短时动态存储程序的记录介质、或计算机可读的任何其他 记录介质。
用在上述实施例中的设备的各种特征或功能模块可以通过电路(例如，单片或多片集成电路)来实现或执行。设计用于执行本说明书所描述的功能的电路可以包括通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、或其他可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或上述器件的任意组合。通用处理器可以是微处理器，也可以是任何现有的处理器、控制器、微控制器、或状态机。上述电路可以是数字电路，也可以是模拟电路。因半导体技术的进步而出现了替代现有集成电路的新的集成电路技术的情况下，本公开的一个或多个实施例也可以使用这些新的集成电路技术来实现。
此外，本公开并不局限于上述实施例。尽管已经描述了所述实施例的各种示例，但本公开并不局限于此。安装在室内或室外的固定或非移动电子设备可以用作终端设备或通信设备，如AV设备、厨房设备、清洁设备、空调、办公设备、自动贩售机、以及其他家用电器等。
如上，已经参考附图对本公开的实施例进行了详细描述。但是，具体的结构并不局限于上述实施例，本公开也包括不偏离本公开主旨的任何设计改动。另外，可以在权利要求的范围内对本公开进行多种改动，通过适当地组合不同实施例所公开的技术手段所得到的实施例也包含在本公开的技术范围内。此外，上述实施例中所描述的具有相同效果的组件可以相互替代。

Claims (10)

  1. 一种分组数据汇聚协议PDCP实体发送端的执行方法，包括：
    发送携带用于建立上下文信息的第一分组数据汇聚协议协议数据单元即第一PDCP PDU；
    在接收到来自下层的针对该第一PDCP PDU递送成功的指示的情况下，对与该第一PDCP PDU属于同一个流的第一分组数据汇聚协议服务数据单元即第一PDCP SDU、或第一以太网帧、或第一以太网报文进行以太网头压缩EHC；
    发送负载为被所述EHC后的第二PDCP SDU、或第二以太网帧、或第二以太网报文的第二PDCP PDU。
  2. 根据权利要求1所述的方法，其特征在于，
    所述进行以太网头压缩EHC，包括：
    判断所述第一PDCP SDU、或所述第一以太网帧、或所述第一以太网报文的以太网头部或头部可压缩字段是否映射了或被分配了上下文标识CID；
    在判断为已映射或已分配了所述CID的情况下，判断是否接收到该CID对应的上下文已建立的确认；
    在判断为接收到所述确认的情况下，对所述第一PDCP SDU、或所述第一以太网帧、或所述第一以太网报文进行所述EHC。
  3. 根据权利要求2所述的方法，其特征在于，
    在判断为已映射或已分配了所述CID、但未接收到所述确认的情况下，不进行所述EHC。
  4. 根据权利要求2所述的方法，其特征在于，
    所述判断是否接收到该CID对应的上下文已建立的确认，包括：
    判断是否接收到所述CID的正反馈或负反馈、判断是否接收到来自下层的针对该第一PDCP PDU递送成功的指示。
  5. 一种分组数据汇聚协议PDCP实体接收端的执行方法，包括：
    在接收到新的用于建立上下文信息的分组数据汇聚协议协议数据单元PDCP PDU或分组数据汇聚协议服务数据单元PDCP SDU时，触发或生成对应的以太网头压缩EHC反馈，
    其中，所述EHC反馈包含所述PDCP PDU或所述PDCP SDU中携带或关联的上下文标识CID和/或该PDCP PDU或PDCP SDU的序列号或COUNT。
  6. 根据权利要求5所述的方法，还包括：
    为每个所述CID或每个触发了/生成了EHC反馈的CID或每个接收到的所述CID或每个已建立上下文信息的所述CID定义一个变量CID_Flag，
    所述CID_Flag用于存储当前接收到的用于建立上下文信息的所述PDCP PDU或所述PDCP SDU的序列号或COUNT；或者
    所述CID_Flag用于存储当前接收到的用于建立上下文信息的所述PDCP PDU或PDCP SDU的最小序列号或COUNT；或者
    所述CID__lag用于存储触发了EHC反馈的PDCP PDU或PDCP SDU的序列号或COUNT。
  7. 根据权利要求6所述的方法，还包括：
    当接收到的所述PDCP PDU或所述PDCP SDU的所述序列号或所述COUNT小于当前CID_Flag、但携带的所述上下文信息与所述CID_Flag对应的上下文信息相同，则更新所述CID_Flag为当前PDCP PDU或当前PDCPSDU的序列号或COUNT。
  8. 根据权利要求6或7所述的方法，还包括：
    如果对于接收到的所述序列号或所述COUNT小于当前CID_Flag的所述PDCP PDU且所述PDCP PDU包含压缩后的PDCP SDU或以太网帧或以太网报文，则利用旧的上下文信息进行解压；
    如果对于接收到的所述序列号或所述COUNT大于当前CID_Flag的所述PDCP PDU且所述PDCP PDU包含压缩后的PDCP SDU或以太网帧或以太网报文，则利用新的上下文信息进行解压。
  9. 一种分组数据汇聚协议PDCP实体，包括：发送端和接收端，
    所述发送端执行权利要求1至4中任一项所述的方法；和/或
    所述接收端执行权利要求5至8中任一项所述的方法。
  10. 一种通信设备，是具有分组数据汇聚协议PDCP实体的通信设备，包括：
    处理器；以及
    存储器，存储有指令；
    其中，所述指令在由所述处理器运行时执行权利要求1至4中任一项所述的发送方法和/或权利要求5至8中任一项所述的方法。
PCT/CN2020/107443 2019-08-09 2020-08-06 Pdcp实体发送端/接收端的执行方法、pdcp实体及通信设备 WO2021027685A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910738798.2A CN112351459A (zh) 2019-08-09 2019-08-09 Pdcp实体发送端/接收端的执行方法、pdcp实体及通信设备
CN201910738798.2 2019-08-09

Publications (1)

Publication Number Publication Date
WO2021027685A1 true WO2021027685A1 (zh) 2021-02-18

Family

ID=74367768

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/107443 WO2021027685A1 (zh) 2019-08-09 2020-08-06 Pdcp实体发送端/接收端的执行方法、pdcp实体及通信设备

Country Status (2)

Country Link
CN (1) CN112351459A (zh)
WO (1) WO2021027685A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115484312B (zh) * 2021-05-31 2024-05-17 展讯通信（上海）有限公司 以太网包头压缩方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101675611A (zh) * 2007-05-02 2010-03-17 Lg电子株式会社 用于在移动通信系统中传输数据的方法
US20100135216A1 (en) * 2001-11-24 2010-06-03 Seung-June Yi Method for transmitting packet data in communication system
US20190116521A1 (en) * 2017-10-16 2019-04-18 Weihua QIAO Header Compression for Ethernet Frame
WO2020092780A1 (en) * 2018-10-31 2020-05-07 Intel Corporation 5g nr methods for ethernet header compression

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100135216A1 (en) * 2001-11-24 2010-06-03 Seung-June Yi Method for transmitting packet data in communication system
CN101675611A (zh) * 2007-05-02 2010-03-17 Lg电子株式会社 用于在移动通信系统中传输数据的方法
US20190116521A1 (en) * 2017-10-16 2019-04-18 Weihua QIAO Header Compression for Ethernet Frame
WO2020092780A1 (en) * 2018-10-31 2020-05-07 Intel Corporation 5g nr methods for ethernet header compression

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
LG ELECTRONICS INC: "Discussion on Ethernet header compression", 3GPP DRAFT; R2-1907554_DISCUSSION ON ETHERNET HEADER COMPRESSION_R5, vol. RAN WG2, 17 May 2019 (2019-05-17), Reno, USA, pages 1 - 3, XP051711836 *
LG ELECTRONICS INC: "Discussion on performing ROHC", 3GPP DRAFT; R2-1907557_DISCUSSION ON PERFORMING ROHC_R3, vol. RAN WG2, 3 May 2019 (2019-05-03), Reno, USA, pages 1 - 2, XP051711839 *
MEDIATEK INC: "Details of Ethernet Header Compression", 3GPP DRAFT; R2-1907074 - DETAILS OF ETHERNET HEADER COMPRESSION, vol. RAN WG2, 2 May 2019 (2019-05-02), Reno, USA, pages 1 - 8, XP051711371 *
MEDIATEK INC: "Ethernet Header Compression", 3GPP DRAFT; R2-1904423 - ETHERNET HEADER COMPRESSION, vol. RAN WG2, 12 April 2019 (2019-04-12), Xi’an, China, pages 1 - 27, XP051693639 *
SHARP: "Feedback for Ethernet Header Compression", 3GPP DRAFT; R2-1910907 FEEDBACK FOR EHC, vol. RAN WG2, 16 August 2019 (2019-08-16), Prague, CZ, pages 1 - 2, XP051768672 *

Also Published As

Publication number Publication date
CN112351459A (zh) 2021-02-09

Similar Documents

Publication Publication Date Title
US20210219105A1 (en) Communications method and apparatus
TWI672969B (zh) 支援資料預處理之方法及其行動通訊裝置
RU2422999C2 (ru) Способ работы улучшенных модуля управления радиоканалом (rlc) и модуля управления радиосетью (rnc) для множественного доступа с кодовым разделением каналов и система для его осуществления
WO2021017812A1 (zh) 用户设备及其执行的方法和基站及其执行的方法
EP2168270B1 (en) A method for handling correctly received but header compression failed packets
WO2011047621A1 (zh) 基于重传机制的对头压缩数据包进行传输的方法和装置
JP2014064319A (ja) 無線通信システムの状態情報送信方法及び受信装置
JP2023027035A (ja) 無線リンク制御ステータスのレポーティング
WO2020156569A1 (zh) 发送rlc状态报告的方法、设备和存储介质
TW200908614A (en) Method of transmitting data in a wireless communication system
KR101509766B1 (ko) 이동통신시스템에서의 ｒｌｃ ｐｄｕ 전송 방법, 자원할당 방법 및 ｒｌｃ 엔티티
US20140098747A1 (en) Handling Redundant Data in a Communication System
WO2021027685A1 (zh) Pdcp实体发送端/接收端的执行方法、pdcp实体及通信设备
WO2020091047A1 (ja) 端末装置、基地局装置、および方法
TW201921977A (zh) 服務資料單元處理方法、丟棄方法、相應的使用者設備和電腦可讀媒體
WO2022131342A1 (ja) 端末装置、基地局装置、および、方法
WO2021223623A1 (zh) 针对信令无线承载pdcp重复的配置方法及rrc实体
KR102609328B1 (ko) 무선 통신 방법 및 디바이스
WO2024032500A1 (zh) 由用户设备执行的方法以及用户设备
WO2023036173A1 (zh) 状态报告发送方法、无线承载重传执行方法及用户设备
WO2019031217A1 (ja) 端末装置、基地局装置、及び、これらの装置により実行される方法
WO2021185202A1 (zh) 用户设备及其方法、基站及其方法
WO2024032544A1 (zh) 由用户设备执行的处理寻呼消息的方法及用户设备
WO2023036287A1 (zh) 用户设备执行的方法、基站的传输方法及用户设备
WO2022255288A1 (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: 20852728

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20852728

Country of ref document: EP

Kind code of ref document: A1