[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2015139324A1 - 配置指示方法和通信设备 - Google Patents

配置指示方法和通信设备 Download PDF

Info

Publication number
WO2015139324A1
WO2015139324A1 PCT/CN2014/073904 CN2014073904W WO2015139324A1 WO 2015139324 A1 WO2015139324 A1 WO 2015139324A1 CN 2014073904 W CN2014073904 W CN 2014073904W WO 2015139324 A1 WO2015139324 A1 WO 2015139324A1
Authority
WO
WIPO (PCT)
Prior art keywords
pdu
pdcp
snli
mac
compression algorithm
Prior art date
Application number
PCT/CN2014/073904
Other languages
English (en)
French (fr)
Inventor
马洁
曹振臻
王学龙
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2014/073904 priority Critical patent/WO2015139324A1/zh
Priority to CN201480001810.7A priority patent/CN105532059B/zh
Publication of WO2015139324A1 publication Critical patent/WO2015139324A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/002—Transmission of channel access control information
    • H04W74/006—Transmission of channel access control information in the downlink, i.e. towards the terminal

Definitions

  • the present invention relates to communication technologies, and in particular, to a configuration indication method and a communication device. Background technique
  • the Internet Protocol In the mobile communication network, the Internet Protocol (IP) is used as the transmission layer.
  • IP Internet Protocol
  • the header of the IP protocol is very large.
  • IETF Internet Engineering Task Force proposes a robust Robust Header Compression (R0HC) technology.
  • the R0HC consists of a series of header compression protocols.
  • the SP, R0HC framework has A variety of header compression algorithms (Profile).
  • Profile header compression algorithms
  • PDCP Packet Data Convergence Protocol
  • the PDCP layer of the Long Term Evolution (LTE) system adopts the R0HC technology, and the evolved base station (Evolved Node B, hereinafter referred to as eNB) passes the RRC signaling before the data packet of the service is actually transmitted.
  • LTE Long Term Evolution
  • eNB evolved base station
  • the sequence number length indicator (hereinafter referred to as SNLI) of the protocol data unit (hereinafter referred to as PDU) of the protocol data unit (hereinafter referred to as PDU) of the PDCP is configured to User equipment (User Equipment, hereinafter referred to as UE), the profile ID is used to indicate which type of header compression algorithm is used by the service data packet, and the SNLI is used to indicate to the receiving end the PDCP PDU header sent by the sender.
  • the length so that the receiving end knows from which position to start decompressing the Service Data Unit (SDU) of the PDCP, and the IP layer header of the service data packet exists in the PDCP SDU.
  • SDU Service Data Unit
  • the UE at the transmitting end determines the header compression algorithm that it represents according to the profile ID, and performs header compression on the data packet according to the header compression algorithm.
  • the UE at the receiving end first determines the length of the PDCP PDU packet header according to the length of the SNLI, that is, determines the location where the PDCP SDU starts. Then according to the header compression algorithm for PDCP SDU The IP layer header is decompressed to get the correct data.
  • the embodiment of the present invention provides a configuration indication method and a communication device, which are used to solve the problem that the UE at the receiving end cannot correctly receive the data packet sent by the sending end in the prior art.
  • the present invention provides a communication device, including:
  • a transmitter configured to send a media access layer protocol data unit MAC PDU to the receiving end, where the MAC PDU carries a header compression algorithm identifier, and/or a packet data convergence protocol layer protocol data in the MAC PDU
  • the serial number length indicator SNLI of the unit PDCP PDU configured to send a media access layer protocol data unit MAC PDU to the receiving end, where the MAC PDU carries a header compression algorithm identifier, and/or a packet data convergence protocol layer protocol data in the MAC PDU The serial number length indicator SNLI of the unit PDCP PDU.
  • the media access layer control unit MAC CE of the MAC PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU. .
  • the PDCP PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the carrying the header compression algorithm identifier in the PDCP PDU includes:
  • the PDCP PDU periodically carries the header compression algorithm identifier.
  • the present invention provides a communication device, including:
  • a receiver configured to receive a media access layer protocol data unit MAC PDU sent by the sending end, where the MAC PDU carries a header compression algorithm identifier, and/or a packet data convergence protocol layer protocol in the MAC PDU Sequence number length indicator SNLI of the data unit PDCP PDU;
  • a processor configured to decompress a network protocol IP layer header in the packet data convergence protocol layer service data unit PDCP SDU sent by the sending end according to the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the media access layer control unit MAC CE of the MAC PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the PDCP PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the present invention provides a communications device, including:
  • a sending module configured to send a media access layer protocol data unit MAC PDU to the receiving end, where the MAC PDU carries a header compression algorithm identifier, and/or a packet data convergence protocol layer protocol data in the MAC PDU
  • the serial number length indicator SNLI of the unit PDCP PDU configured to send a media access layer protocol data unit MAC PDU to the receiving end, where the MAC PDU carries a header compression algorithm identifier, and/or a packet data convergence protocol layer protocol data in the MAC PDU The serial number length indicator SNLI of the unit PDCP PDU.
  • the media access layer control unit MAC CE of the MAC PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU. .
  • the PDCP PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the carrying the header compression algorithm identifier in the PDCP PDU includes:
  • the PDCP PDU periodically carries the header compression algorithm identifier.
  • the present invention provides a communications device, including:
  • a receiving module configured to receive a media access layer protocol data unit MAC PDU sent by the sending end, where the MAC PDU carries a header compression algorithm identifier, and/or a packet data convergence protocol layer protocol in the MAC PDU Sequence number length indicator SNLI of the data unit PDCP PDU;
  • a decompression module configured to decompress a network protocol IP layer header in a packet data convergence protocol layer service data unit PDCP SDU sent by the sending end according to the header compression algorithm identifier and/or the SNLI of the PDCP PDU .
  • the media access layer control unit MAC CE of the MAC PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU. .
  • the PDCP PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the present invention provides a configuration indication method, including:
  • the sending end sends a media access layer protocol data unit MAC PDU to the receiving end, where the MAC PDU carries a header compression algorithm identifier, and/or a packet data convergence protocol layer protocol data unit PDCP PDU in the MAC PDU Serial number length indicator SNLI.
  • the media access layer control unit MAC CE of the MAC PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU. .
  • the PDCP PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the carrying the header compression algorithm identifier in the PDCP PDU includes:
  • the PDCP PDU periodically carries the header compression algorithm identifier.
  • the present invention provides a configuration indication method, where a receiving end receives a media access layer protocol data unit MAC PDU sent by a sending end, where the MAC PDU carries a header compression algorithm identifier, and/or The serial number length indicator SNLI of the packet data convergence protocol layer protocol data unit PDCP PDU in the MAC PDU;
  • the receiving end decompresses a network protocol IP layer header in the packet data convergence protocol layer service data unit PDCP SDU sent by the sending end according to the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the media access layer control unit MAC CE of the MAC PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU. .
  • the PDCP PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the configuration indication method and the communication device provided by the embodiment of the present invention send a MAC PDU of the SNLI carrying the profi le ID and/or the PDCP PDU to the receiving end by the sender, so that the receiving end according to the profi le ID and/or the SNLI pair of the PDCP PDU
  • the PDCP SDU is decompressed so that the receiving end can correctly receive the data packet sent by the transmitting end.
  • the communication device provided by the embodiment of the present invention can enable the transmitting end and the receiving end to correctly receive data without prior configuration when the control center node is not in use, thereby realizing efficient use of the wireless resource.
  • FIG. 1 is a schematic diagram of a plurality of consecutive data packets carrying a MAC CE provided by the present invention
  • FIG. 2 is a schematic diagram of carrying a MAC CE in a discontinuous data packet according to the present invention
  • Embodiment 2 of a communication device is a schematic structural diagram of Embodiment 2 of a communication device according to the present invention.
  • Embodiment 4 is a schematic structural diagram of Embodiment 4 of a communication device according to the present invention.
  • FIG. 5 is a schematic flowchart diagram of Embodiment 2 of a configuration indication method provided by the present invention.
  • the technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention.
  • the embodiments are a part of the embodiments of the invention, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.
  • the transmitting end and the receiving end in the embodiment of the present invention may be a user equipment, and the user equipment may be a cellular through terminal, and the terminal may be a wireless terminal or a wired terminal.
  • the wireless terminal can be a device that provides voice and/or data connectivity to the user, a handheld device with wireless connectivity, or other processing device that is connected to the wireless modem.
  • the wireless terminal can communicate with one or more core networks via a radio access network (eg, RAN, Radio Access Network), which can be a mobile terminal, such as a mobile phone (or "cellular" phone) and with a mobile terminal
  • RAN Radio Access Network
  • the computers for example, can be portable, pocket-sized, handheld, computer-integrated or in-vehicle mobile devices that exchange language and/or data with the wireless access network.
  • a wireless terminal may also be called a system, a subscriber unit, a subscriber station, a mobile station, a mobile station, a remote station, an access point, or an access point.
  • Remote Terminal Access Terminal, User Terminal, User Agent, User Device, or User Equipment.
  • a first embodiment of the present invention provides a communication device, where the communication device is a communication device at a transmitting end, and the communication device includes a transmitter 10, configured to send a media access control protocol data unit (Media Access Control Protocol Data Unit) to the receiving end.
  • a media access control protocol data unit Media Access Control Protocol Data Unit
  • MAC PDU media access control protocol data unit
  • the MAC PDU carries a profile ID, and/or an SNLI of a PDCP PDU in the MAC PDU.
  • the transmitter 10 sends a service data stream to the receiver, where the service data stream includes at least one data packet.
  • the communication device performs header compression on the data packet.
  • the header compression process uses a certain header compression algorithm, and the header compression algorithm can pass the header compression algorithm identifier (profile ID). ) to indicate that different profi le IDs correspond to different header compression algorithms.
  • the communication device also adds a header of the PDCP layer to the data packet, so that the data packet is converted into a PDCP PDU; when the PDCP PDU is transmitted to the MAC layer of the transmitting end, the communication device also adds a MAC layer header to the PDCP PDU.
  • the MAC PDU is actually a protocol data unit that includes the PDCP PDU.
  • the transmitter 10 sends the MAC PDU to the receiving end, and carries the prof ile ID and/or the SNLI of the PDCP PDU in the MAC PDU.
  • the receiving end receives the MAC PDU, and obtains the profile ID of the MAC PDU and/or the SNLI of the PDCP PDU.
  • the receiving end learns the corresponding header compression algorithm according to the profile ID, and decompresses the IP layer header in the PDCP SDU.
  • Acquiring the data packet sent by the sending end, and/or, the receiving end knows the length of the PDCP PDU packet header according to the SNLI, so as to know the starting position of the PDCP SDU, and then decompress the IP layer header in the PDCP SDU to obtain the sending by the transmitting end. data pack.
  • the communication device and the receiving end compress and decompress the IP layer header in the PDCP SDU according to the length of the header compression algorithm and/or the PDCP PDU header, so that the receiving end It can correctly receive the data packets sent by the sender.
  • the receiving end may determine the length of the header of the PDCP PDU by performing other signaling messages (such as user plane configuration information) with the sending end, or may negotiate through the two operations. Determining the header length of the PDCP PDU, that is, determining the location of the PDCP SDU to ensure the correctness of the IP layer header in the PDCP SDU; the receiving end according to the length of the PDCP PDU header and the header compression algorithm corresponding to the profile ID The IP layer header of the PDCP SDU in the PDCP PDU is decompressed, so that the data sent by the sender can be correctly obtained.
  • the header length of the PDCP PDU that is, determining the location of the PDCP SDU to ensure the correctness of the IP layer header in the PDCP SDU; the receiving end according to the length of the PDCP PDU header and the header compression algorithm corresponding to the profile ID
  • the IP layer header of the PDCP SDU in the PDCP PDU is decompressed, so that the data sent by
  • the receiving end when receiving the MAC PDU, the receiving end reads the SNLI of the PDCP PDU, learns the length of the PDCP PDU header, and learns the location where the PDU SDU starts; Reading the header of the data packet in the PDCP SDU, determining the profile ID according to the content carried in the packet header, and knowing which header compression algorithm should be used; finally, the receiving end according to the header compression algorithm and the length of the PDCP PDU header to the PDCP SDU The IP layer header is decompressed, so that the data packet sent by the sender can be correctly received.
  • the receiving end when the profile ID and the SNLI of the PDCP PDU are carried in the MAC PDU, the receiving end first determines the header length of the PDCP PDU by using the SNLI; and then determines the header compression algorithm according to the profile ID; finally, the receiving end according to the header compression algorithm And the length of the PDCP PDU header is decompressed to the IP layer header of the PDCP SDU, so that the data packet sent by the sender can be correctly received.
  • the communication device provided by the embodiment of the present invention sends a MAC PDU carrying the profile ID and/or the SNLI of the PDCP PDU to the receiving end, so that the receiving end decompresses the PDCP SDU according to the profile ID and/or the SNLI of the PDCP PDU. Therefore, the receiving end can correctly receive the data packet sent by the transmitting end.
  • the communication device provided by the embodiment of the present invention can enable the transmitting end and the receiving end to correctly receive data without prior configuration when the control center node is not in use, thereby realizing efficient use of the wireless resource.
  • the embodiment relates to media access of the MAC PDU by carrying the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • MAC CE MAC Control Element
  • the transmitter 10 sends a service data stream to the receiver, where the service data stream includes at least one data packet.
  • the communication device adds a MAC CE in the first data packet of the service data flow, and the MAC CE carries a profile ID and/or an SNLI of the PDCP PDU, where the MAC CE includes a Logical Channel Identifier (LGID).
  • LGID Logical Channel Identifier
  • the LGID is used to indicate the number of a service data flow
  • the header compression algorithm index is used to indicate the profile ID
  • the SNLI is used to indicate the PDCP.
  • the length of the Serial Number (hereinafter referred to as SN), which is the length of the header of the PDCP PDU.
  • the format of the MAC CE can be referenced. See Table 1.
  • the SNLI is used to indicate the number of bits in the SN field in the PDCP PDU.
  • the SN usually has three types: 7 bits, 12 bits, and 15 bits.
  • the number of bits in the SNLI can be 1 bit or 2 bits. Wherein, when the number of bits of the SNLI is 2 bits (00-11), four types of SN lengths can be indicated; when the number of bits of the SNLI is 1 bit (0 or 1), two types of SN lengths can be indicated. Therefore, when two types of SN lengths are used in D2D communication, the SNLI is indicated by 1 bit; when three types of SN lengths are used in D2D communication, the SNLI is indicated by 2 bits.
  • LGID Profi le index SNLI LGID Profi le index SNLI
  • the device 10 carries the MAC CE (see FIG. 1) in a plurality of consecutive data packets after the service data starts to be transmitted, and may also be periodically inserted during the transmission of the service data for the broadcast mode for the direct communication (D2D).
  • the MAC CE that is, carries the MAC CE in the non-contiguous data packet (see FIG. 2), so that the terminal of the broadcast group that joins the D2D at different times can know the profile ID and/or SNLI corresponding to the service.
  • the receiving end When the receiving end receives the MAC PDU with the MAC CE, the MAC CE is read out and the primitive is sent to the RRC layer of the user; the receiving end configures the PDCP layer of the user plane through its own RRC layer entity, Head compression algorithm in PDCP entity corresponding to the service data flow
  • the RRC layer entity indicates the SN length of the PDCP (ie, the length of the PDCP PDU header) to the PDCP layer of the user plane through the SNLI, and the length may be 7 bits or 12bit or 15bit.
  • the PDCP entity in the receiving end establishes the context of the header compression algorithm according to the profi le ID, so as to decompress the IP layer header of the PDCP SDU later, and/or the receiving end reads the PDCP according to the length indicated by the SNLI.
  • the length of the SN that is, the length of the header of the PDCP PDU is learned, so that the IP layer header of the PDCP SDU is decompressed later.
  • the header compression algorithm and/or SNLI corresponding to the profi le ID of the PDCP layer indicated in the MAC CE are used to compress and decompress the IP layer header of the PDCP SDU so as to correctly receive the data packet sent by the sender.
  • the communication device provided by the embodiment of the present invention sends the bearer to the receiving end through the transmitter.
  • Profile ID and/or MAC PDU of the SNLI of the PDCP PDU, and the profile ID and/or SNLI are carried in the MAC CE of the MAC PDU, so that the receiving end can perform the PDCP SDU according to the profile ID and/or SNLI carried in the MAC CE.
  • the IP layer header is decompressed, so that the receiving end can correctly receive the data packet sent by the transmitting end.
  • the communication device provided by the embodiment of the present invention can enable the transmitting end and the receiving end to correctly receive data without prior configuration when the control center node is not in use, thereby realizing efficient use of the wireless resource.
  • the embodiment relates to sending the SNLI of the profi le ID and/or the PDCP PDU in the PDCP PDU of the MAC PDU. The process to the receiving end.
  • the format of the PDCP PDU of the SNLI carrying the profi le ID and/or the PDCP PDU can be seen in Table 2:
  • D in D/C indicates that this PDU is a data unit
  • C indicates that this PDU is a control unit of PDCP, which is D in this embodiment.
  • the PDU type indicates the type of the PDU.
  • the specific type of the PDU can be indicated by a combination of the corresponding "0" or "1" bits. For details, see Table 3: Table 3
  • SNLI indicates the length indication bit of the PDCP SN, indicating the length of the SN in the header of the PDCP PDU, and can obtain the position where the PDCP SDU starts according to it; the SNLI may have 1 bit or 2 bits long, which is specified in the D2D communication system. If only two SN lengths are used, the SNLI is 1 bit, and if three types of length are used, the SNLI is 2 bits.
  • the SNLI when the SNLI has only 1 bit and the SNLI value is 1, it indicates that the SN is a 7-bit SN; when the SNLI has only 1 bit and the SNLI value is 0, it indicates that the SN is a 12-bit SN; when the SNLI has 2 bits When the bit is 00LI and the value of SNLI is 00, it indicates that the SN is a 7-bit SN; when the SNLI has 2 bits and the SNLI value is 01, it indicates that the SN is a 12-bit SN; when the SNLI has 2 bits and the SNLI A value of 10 indicates that the SN is 15 bits; if the SNLI has 2 bits and the SNLI value is 11, it can be temporarily used, and it is used when there is a new SN length.
  • PID refers to the above profi le ID.
  • the communication device After the above-mentioned communication device performs IP-related header compression for each PDCP SDU (a PDCP PDU corresponds to one SDU), the profi le ID used by itself and/or the SNLI of the PDCP PDU are carried in the PDCP PDU through the transmitter. 10 is sent to the receiving end, D is filled in the D/C bit in the header of the PDCP PDU, and the PDU type is filled in 010 in Table 3. The SNLI is filled in according to the indicator bit value corresponding to the length of the specific SN, in a service flow. In the middle, a SN length should be fixed. Then, the communication device adds the MAC CE to the PDCP PDU at the MAC layer, and forms a MAC PDU to be sent to the receiving end.
  • the receiving end After receiving the MAC PDU, the receiving end acquires the PDCP PDU and reads the D/C bit in the PDCP PDU. When the receiving end detects that the bit is D, it indicates that the data packet carries the PDCP SDU, and then the received PDU is interpreted according to the meaning of each bit in Table 2. After the receiving end reads the profi le ID and/or the SNLI from the PDU, the correct SDU position is obtained according to the header compression algorithm corresponding to the profi le ID and/or the header length of the PDCP PDU, and the PDCP SDU is decompressed. The IP layer header, so that the packet of the sender can be received correctly.
  • the receiving end when the receiving end reads the D/C bit as C, the format of the PDC PPDU is interpreted.
  • the manner is shown in Table 4 and Table 5.
  • the PDU type in Table 4 is 100, and the PDU type in Table 5 is 011.
  • BitmapN (optional) Oct 2+N
  • the first missing PDCP sequence number (First Missing PDCP SN, hereinafter referred to as FMS) is used to indicate the PDCP SN of the first lost PDCP SDU; bitmap (Bitmap) Indicates which PDCP SN is missing.
  • the PID can be periodically carried in the PDCP PDU, which indicates the profile ID of the R0HC. It also saves the head overhead of PDCP.
  • the PDU type will be added one more way. The table after the addition is shown in Table 6:
  • the communication device provided by the embodiment of the present invention sends a MAC PDU carrying the profile ID and/or the SNLI of the PDCP PDU to the receiving end, and the SNLI of the profile ID and/or the PDCP PDU is carried in the PDCP PDU of the MAC PDU.
  • the receiving end can decompress the IP layer header of the PDCP SDU according to the profile ID and/or the SNLI carried in the PDCP PDU, so that the receiving end can correctly receive the data packet sent by the sending end.
  • the communication device provided by the embodiment of the present invention enables the transmitting end and the receiving end to correctly receive data without prior configuration when there is no control center node, thereby realizing efficient use of radio resources.
  • the communication device includes: a receiver 20 and a processor 21.
  • the receiver 20 is configured to receive a MAC PDU sent by the sending end, where the MAC PDU carries a header compression algorithm identifier, and/or an SNLI of the PDCP PDU in the MAC PDU
  • the processor 21 is configured to The header compression algorithm identifier and/or the SNLI of the PDCP PDU decompresses the PDCP SDU sent by the sender.
  • the sending end sends a service data stream to the receiving end, where the service data stream includes at least one data packet.
  • the transmitting end performs header compression on the data packet.
  • the header compression process uses a certain header compression algorithm, and the header compression algorithm can pass the header compression algorithm identifier (profile ID). To indicate that different profile IDs correspond to different header compression algorithms.
  • the sender also adds a header of the PDCP layer to the data packet, so that the data packet is converted into a PDCP PDU.
  • the sender When the PDCP PDU is transmitted to the MAC layer of the sender, the sender also adds a header to the PDCP PDU to make it a MAC PDU. . That is, the MAC PDU is actually a protocol data unit that includes the PDCP PDU. Finally, the sender sends the MAC PDU to the receiving end, and carries the profile ID and/or the SNLI of the PDCP PDU in the MAC PDU.
  • the receiver 20 receives the MAC PDU, and the processor 21 acquires the profile ID of the MAC PDU and/or the SNLI of the PDCP PDU.
  • the processor 21 learns the corresponding header compression algorithm according to the profile ID, and the IP layer in the PDCP SDU.
  • the packet header is decompressed to obtain the data packet sent by the sender, and/or the processor 21 learns the length of the PDCP PDU packet header according to the SNLI, so as to know the location where the PDCP SDU starts, and then solve the IP layer header in the PDCP SDU. Compress to get the packet sent by the sender. Moreover, in the subsequent data packet transmission and reception process, the sender and the receiver compress and decompress the IP layer header in the PDCP SDU according to the length of the header compression algorithm and/or the PDCP PDU header to enable the user to Correctly received the packet sent by the sender.
  • the receiving end may determine the length of the header of the PDCP PDU by performing other signaling messages (such as user plane configuration information) with the sending end, or may negotiate through the two operations. Determining the header length of the PDCP PDU, that is, determining the location of the PDCP SDU, ensuring the correctness of the IP layer header in the PDCP SDU; the processor 21 according to the length of the PDCP PDU header and the header compression algorithm corresponding to the profile ID The PDCP SDU in the PDCP PDU is decompressed, so that the data packet sent by the sender can be correctly obtained.
  • the receiver 20 receives the SNLI.
  • the processor 21 When the MAC PDU is read, the processor 21 reads the SNLI of the PDCP PDU, learns the length of the PDCP PDU header, and learns the location where the PDU SDU starts. The processor 21 reads the packet header of the data packet in the PDCP SDU according to the packet header. The carried content determines the profile ID, and knows which header compression algorithm should be used. Finally, the processor 21 decompresses the IP layer header of the PDCP SDU according to the header compression algorithm and the length of the PDCP PDU header, so that the packet can be correctly received. The packet sent by the sender.
  • the processor 21 when the profile ID and the SNLI of the PDCP PDU are carried in the MAC PDU, the processor 21 first determines the header length of the PDCP PDU by using the SNLI of the PDCP PDU; and then determines a header compression algorithm according to the profile ID; finally, the processor 21 The IP layer header in the PDCP SDU is decompressed according to the header compression algorithm and the length of the PDCP PDU header, so that the data packet sent by the sender can be correctly received.
  • the communication device provided by the embodiment of the present invention receives, by the receiver, the MAC PDU of the SNLI carrying the profile ID and/or the PDCP PDU sent by the sending end, so that the processor according to the profile ID carried in the MAC PDU and/or the SNLI of the PDCP PDU.
  • the IP layer header in the PDCP SDU is decompressed, so that the receiving end can correctly receive the data packet sent by the transmitting end.
  • the communication device provided by the embodiment enables the transmitting end and the receiving end to correctly receive data without prior configuration when there is no control center node, thereby realizing efficient use of radio resources.
  • the embodiment relates to receiving the MAC PDU by the receiver 20, and carrying the header compression algorithm identifier in the MAC CE of the MAC PDU. And/or the SNLI process of the PDCP PDU.
  • a service data stream is sent to the receiving end, where the service data stream includes at least one data packet.
  • the sender adds a MAC CE in the first data packet of the service data flow, where the MAC CE carries a profile ID and/or a SNLI of the PDCP PDU, and the MAC CE includes both a LGID and a header compression algorithm index.
  • the SNLI of the PDCP PDU where the LGID is used to indicate the number of a service data flow, the header compression algorithm index is used to indicate the profi le ID, and the SNLI is used to indicate the length of the PDCP SN, that is, the header of the PDCP PDU. length.
  • the format of the MAC CE can be seen in Table 1 above.
  • the SNLI is used to indicate the number of bits in the SN field in the PDCP PDU.
  • the SN usually has 7 bits, 12 bits, and 15 bits.
  • the number of bits in the SNLI can be lbit or 2bit. Wherein, when the number of bits of the SNLI is 2 bits (00-11), four types of SN lengths can be indicated; when the number of bits of the SNLI is 1 bit (0 or 1), two types of SN lengths can be indicated. Therefore, when two types of SN lengths are used in D2D communication, the SNLI is indicated by lbit; when three types of SN lengths are used in D2D communication, the SNLI is indicated by 2 bits.
  • the MAC CE may perform multiple transmissions at the MAC layer. Therefore, in addition to carrying the MAC CE in the first data packet, the following may also be:
  • the sender starts at the service data. Multiple consecutive data packets after transmission carry MAC CE (see Figure 1), and can also be used for direct-through (D2D) broadcast mode, periodically inserting MAC CE during service data transmission, that is, in non-
  • the continuous data packet carries the MAC CE (see FIG. 2), so that the terminal of the broadcast group that joins the D2D at different times can know the profile ID corresponding to the service and/or the SNLI of the PDCP PDU.
  • the MAC CE When the receiver 20 receives the MAC PDU with the MAC CE, the MAC CE is read out by the processor 21, and the primitive is sent to the RRC layer of the host; the processor 21 provides the user plane through the RRC layer entity of the receiving end.
  • the PDCP layer is configured to configure a header compression algorithm (profi le) in the PDCP entity corresponding to the service data flow as a profi le ID carried in the MAC CE, and/or a PDCP layer of the RRC layer entity to the user plane through the SNLI. Indicates the SN length of the PDCP (ie The length of the PDCP PDU header. This length can be 7bit or 12bit or 15bit.
  • the processor 21 establishes the context of the header compression algorithm according to the profi le ID through the PDCP entity in the receiving end, so as to decompress the IP layer header of the PDCP SDU, and/or the processor 21 follows the length indicated by the SNLI. To read the length of the SN of the PDCP, that is, the length of the header of the PDCP PDU is obtained, so as to decompress the IP layer header of the PDCP SDU later.
  • the sender and the receiver perform data packet header compression and decompression and/or SNLI of the PDCP PDU according to the header compression algorithm corresponding to the PDCP layer's profi le ID indicated in the MAC CE.
  • the IP layer header in the PDCP SDU is compressed and decompressed so that the data packet sent by the sender can be correctly received.
  • the communication device provided by the embodiment of the present invention receives the MAC PDU of the SNLI carrying the profile ID and/or the PDCP PDU sent by the sending end by the receiver, and the profile ID and/or the SNLI are carried in the MAC CE of the MAC PDU, so that the processing is performed.
  • the device can decompress the IP layer header in the PDCP SDU according to the profile ID and/or the SNLI carried in the MAC CE, so that the receiving end can correctly receive the data packet sent by the sending end.
  • the communication device provided by the embodiment of the present invention can enable the transmitting end and the receiving end to correctly receive data without prior configuration when the control center node is not in use, thereby realizing efficient use of the wireless resource.
  • the embodiment relates to that the receiver receives the MAC PDU, and the PDCP PDU in the MAC PDU carries the profi le ID and/or Or the SNLI process of the PDCP PDU.
  • the format of the PDCP PDU of the SNLI carrying the profi le ID and/or the PDCP PDU can be referred to Table 2 and Table 3 above, and the detailed descriptions of Table 2 and Table 3 are not described herein.
  • the sender After the sender performs IP-related header compression for each PDCP SDU (a PDCP PDU corresponds to one SDU), the SNLI of the profi le ID and/or the PDCP PDU used by the transmitting end is carried in the PDCP PDU and sent to the receiving end. Fill in D in the D/C bit in the header of the PDCP PDU, and fill in 010 in Table 3. The SNLI is filled in according to the length of the specific SN. In a service flow, an SN length should be fixed. Afterwards, the sender adds the MAC CE to the PDCP PDU at the MAC layer, and forms a MAC PDU to be sent to the receiving end.
  • the receiver 20 After receiving the MAC PDU, the receiver 20 acquires the PDCP PDU through the processor 21 and reads the D/C bit in the PDCP PDU. When the processor 21 detects that the bit is D, the table This packet carries the SDU of the PDCP, so the received PDU is interpreted according to the meaning of each bit in Table 2. After the processor 21 reads the profi le ID and/or the SNLI from the PDU, according to the header compression algorithm corresponding to the profi le ID and/or the header length of the PDCP PDU, the data packet of the transmitting end can be correctly received.
  • the manner of reading the format of the PDC PPDU is shown in Table 4 and Table 5.
  • the PDU type in Table 4 is 100, and the PDU type in Table 5 is 011.
  • the PID can be periodically carried in the PDCP PDU, which indicates the profi le ID of the R0HC. , which saves the head overhead of PDCP. In this way, the PDU type will be added one more.
  • Table 6 For the table after the addition, refer to Table 6 and its specific description, and details are not described herein again.
  • the communication device provided by the embodiment of the present invention receives the profile ID sent by the sending end and/or the MAC PDU of the SNLI of the PDCP PDU through the receiver, and the SNLI of the profile ID and/or the PDCP PDU is carried in the PDCP PDU of the MAC PDU.
  • the processor is configured to decompress the PDCP SDU according to the profile ID and/or the SNLI carried in the PDCP PDU, so that the receiving end can correctly receive the data packet sent by the sending end.
  • the communication device provided by the embodiment of the present invention can enable the transmitting end and the receiving end to correctly receive data without prior configuration when there is no control center node, thereby realizing efficient use of radio resources.
  • a third embodiment of the present invention provides a communication device, where the communication device is a communication device at the transmitting end, and the communication device includes a sending module 30, configured to send a MAC PDU to the receiving end, where the MAC PDU carries a profile ID, and/or , the SNLI of the PDCP PDU in the MAC PDU.
  • the sending module 30 sends a service data stream to the receiving end, where the service data stream includes at least one data packet.
  • the communication device performs header compression on the data packet.
  • the header compression process uses a certain header compression algorithm (prof i le ), and the header compression algorithm can pass the header compression algorithm identifier ( Prof i le ID) to indicate that different profi le IDs correspond to different header compression algorithms.
  • the communication device also adds a header of the PDCP layer to the data packet, such that the data packet is converted into a PDCP PDU; when the PDCP PDU When transmitting to the MAC layer of the sender, the communication device also adds a header of the MAC layer to the PDCP PDU, making it a MAC PDU. That is, the MAC PDU is actually a protocol data unit including the PDCP PDU.
  • the sending module 30 sends the MAC PDU to the receiving end, and carries the profile ID and/or the SNLI of the PDCP PDU in the MAC PDU.
  • the receiving end receives the MAC PDU, and obtains the prof i le ID and/or the SNLI of the PDCP PDU in the MAC PDU.
  • the receiving end learns the corresponding header compression algorithm according to the profile ID, and decompresses the IP layer header in the PDCP SDU.
  • the receiving end learns the length of the PDCP PDU packet header according to the SNLI, so as to know the location where the PDCP SDU starts, and then decompress the IP layer header in the PDCP SDU to obtain the transmitting end.
  • the packet sent is the MAC PDU, and obtains the prof i le ID and/or the SNLI of the PDCP PDU in the MAC PDU.
  • the receiving end learns the corresponding header compression algorithm according to the profile ID, and decompresses the IP layer header in the PDCP SDU.
  • the receiving end learns the length of the PDCP PDU packet header according to the SNLI, so as to know the location where the
  • the communication device and the receiving end compress and decompress the IP layer header in the PDCP SDU according to the length of the header compression algorithm and/or the PDCP PDU header, so that the receiving end It can correctly receive the data packets sent by the sender.
  • the receiving end may determine the length of the header of the PDCP PDU by performing other signaling messages (such as user plane configuration information) with the sending end, or may negotiate through the two operations. Determining the header length of the PDCP PDU, that is, determining the location of the PDCP SDU to ensure the correctness of the IP layer header in the PDCP SDU; the receiving end according to the length of the PDCP PDU header and the header compression algorithm corresponding to the profile ID The IP layer header of the PDCP SDU in the PDCP PDU is decompressed, so that the data packet sent by the sender can be correctly obtained.
  • the receiving end receives the MAC.
  • the SNLI of the PDCP PDU is read, the length of the header of the PDCP PDU is learned, and the location where the PDU SDU starts is obtained.
  • the profile ID of the packet in the PDCP SDU is read, and the profile ID is determined according to the content carried in the packet header. Which type of header compression algorithm should be used;
  • the receiving end decompresses the IP layer header of the PDCP SDU according to the header compression algorithm and the length of the PDCP PDU header, so that the data packet sent by the transmitting end can be correctly received.
  • the receiving end when the profile ID and the SNLI of the PDCP PDU are carried in the MAC PDU, the receiving end first determines the header length of the PDCP PDU by using the SNLI; and then determines the header compression algorithm according to the profile ID; finally, the receiving end according to the header compression algorithm And the length of the PDCP PDU header is decompressed to the IP layer header of the PDCP SDU, so that the data packet sent by the sender can be correctly received.
  • the communication device provided by the embodiment of the present invention sends a MAC PDU carrying the profile ID and/or the SNLI of the PDCP PDU to the receiving end, so that the receiving end decompresses the PDCP SDU according to the profile ID and/or the SNLI of the PDCP PDU. Therefore, the receiving end can correctly receive the data packet sent by the transmitting end.
  • the communication device provided by the embodiment of the present invention can enable the transmitting end and the receiving end to correctly receive data without prior configuration when the control center node is not in use, thereby realizing efficient use of the wireless resource.
  • the embodiment relates to carrying the foregoing header compression algorithm identifier and/or the SNLI of the PDCP PDU in the MAC CE of the MAC PDU. The process of sending to the receiving end.
  • the sending module 30 sends a service data stream to the receiving end, where the service data stream includes at least one data packet.
  • the communication device adds a MAC CE in the first data packet of the service data flow, the MAC CE carrying the profile ID and/or the SNLI of the PDCP PDU, the MAC CE includes both the LGID and the header compression algorithm index and / SNLI of the PDCP PDU, where the LGID is used to indicate the number of a service data flow, the header compression algorithm index is used to indicate the profile ID, and the SNLI is used to indicate the length of the SN of the PDCP, that is, the length of the header of the PDCP PDU.
  • the format of the MAC CE can be seen in Table 1 above.
  • the SNLI is used to indicate the number of bits in the SN field in the PDCP PDU.
  • the SN usually has three bits: 7 bits, 12 bits, and 15 bits.
  • the number of bits in the SNLI can be lbit or 2bito. When the number of bits in the SNLI is 2 bits (00-11), four SN lengths can be indicated. When the number of bits in the SNLI is 1 bit (0 or 1), it can be indicated. 2 kinds of SN length. Therefore, when two types of SN lengths are used in D2D communication, SNLI is indicated by lbit; when three types of SN lengths are used in D2D communication, SNLI is indicated by 2 bits.
  • the MAC CE may be transmitted multiple times at the MAC layer. Therefore, in addition to carrying the MAC CE in the first data packet, the sending module 30 may be in the service data.
  • the MAC CE (see Figure 1) is carried in multiple consecutive data packets after the start of transmission, and the MAC CE can be periodically inserted during the transmission of the service data for the broadcast mode for the direct communication (D2D).
  • the non-contiguous data packet carries the MAC CE (see Figure 2), so that the terminal of the broadcast group that joins the D2D at different times can know the profile ID and/or SNLI corresponding to the service.
  • the receiving end When the receiving end receives the MAC PDU with the MAC CE, the MAC CE is read out and shaped The primitive is sent to its own RRC layer; the receiving end configures the PDCP layer of the user plane through its own RRC layer entity, and the header compression algorithm in the PDCP entity corresponding to the service data stream
  • the RRC layer entity indicates the SN length of the PDCP (ie, the length of the PDCP PDU header) to the PDCP layer of the user plane through the SNLI, and the length may be 7 bits or 12bit or 15bit.
  • the PDCP entity in the receiving end establishes the context of the header compression algorithm according to the profi le ID, so as to decompress the IP layer header of the PDCP SDU later, and/or the receiving end reads the PDCP according to the length indicated by the SNLI.
  • the length of the SN that is, the length of the header of the PDCP PDU is learned, so that the IP layer header of the PDCP SDU is decompressed later.
  • the header compression algorithm and/or SNLI corresponding to the profi le ID of the PDCP layer indicated in the MAC CE are used to compress and decompress the IP layer header of the PDCP SDU so as to correctly receive the data packet sent by the sender.
  • the communication device provided by the embodiment of the present invention sends a MAC PDU carrying the profile ID and/or the SNLI of the PDCP PDU to the receiving end, and the profile ID and/or the SNLI are carried in the MAC CE of the MAC PDU, so that the receiving end
  • the IP layer header of the PDCP SDU can be decompressed according to the profile ID and/or the SNLI carried in the MAC CE, so that the receiving end can correctly receive the data packet sent by the sending end.
  • the communication device provided by the embodiment of the present invention enables the transmitting end and the receiving end to correctly receive data without prior configuration when the central node is not controlled, thereby realizing efficient use of the wireless resource.
  • the embodiment relates to sending the SNLI of the profi le ID and/or the PDCP PDU in the PDCP PDU of the MAC PDU. The process to the receiving end.
  • the format of the PDCP PDU of the SNLI carrying the profi le ID and/or the PDCP PDU can be seen in Table 2 and Table 3, and the detailed descriptions of Table 2 and Table 3 are omitted here.
  • the communication device After the IP-related header compression (one PDDU PDU corresponds to one SDU), the communication device carries the profi le ID used by itself and/or the SNLI of the PDCP PDU in the PDCP PDU through the sending module. 30 is sent to the receiving end, D is filled in the D/C bit in the header of the PDCP PDU, and the PDU type is filled in 010 in Table 3.
  • the SNLI is filled in according to the indication bit value corresponding to the length of the specific SN, in a service flow. Should be fixed Take a SN length. Then, the communication device adds the MAC CE to the PDCP PDU at the MAC layer, and forms a MAC PDU to be sent to the receiving end.
  • the receiving end After receiving the MAC PDU, the receiving end acquires the PDCP PDU and reads the D/C bit in the PDCP PDU. When the receiving end detects that the bit is D, it indicates that the data packet carries the PDCP SDU, and then the received PDU is interpreted according to the meaning of each bit in Table 2. After the receiving end reads the profi le ID and/or the SNLI from the PDU, the correct SDU position is obtained according to the header compression algorithm corresponding to the profi le ID and/or the header length of the PDCP PDU, and the PDCP SDU is decompressed. The IP layer header, so that the packet of the sender can be received correctly.
  • the manner of interpreting the format of the PDC PPDU is shown in Table 4 and Table 5 above.
  • the PDU type in Table 4 is 100, and the PDU type in Table 5 is 011.
  • the PID can be periodically carried in the PDCP PDU, which indicates the profi le ID of the R0HC. , which saves the head overhead of PDCP. Therefore, the PDU type will be further added.
  • Table 6 For the table after the addition, refer to Table 6 above and its detailed description, and details are not described herein again.
  • the communication device provided by the embodiment of the present invention sends a MAC PDU carrying the profile ID and/or the SNLI of the PDCP PDU to the receiving end, and the SNLI of the profile ID and/or the PDCP PDU is carried in the PDCP PDU of the MAC PDU.
  • the receiving end can decompress the IP layer header of the PDCP SDU according to the profile ID and/or the SNLI carried in the PDCP PDU, so that the receiving end can correctly receive the data packet sent by the sending end.
  • the communication device provided by the embodiment of the present invention can enable the transmitting end and the receiving end to correctly receive data without prior configuration when the control center node is not in use, thereby realizing efficient use of the wireless resource.
  • the communication device includes: a receiving module 40 and a decompression module 41.
  • the receiving module 40 is configured to receive a MAC PDU sent by the sending end, where the MAC PDU carries a header compression algorithm identifier, and/or an SNLI of the PDCP PDU in the MAC PDU, and a decompression module 41, configured to: SNLI based on the header compression algorithm identifier and/or PDCP PDU Decompress the PDCP SDU sent by the sender.
  • the sending end sends a service data stream to the receiving end, where the service data stream includes at least one data packet.
  • the transmitting end performs header compression on the data packet.
  • the header compression process uses a certain header compression algorithm, and the header compression algorithm can pass the header compression algorithm identifier (profile ID). To indicate that different profile IDs correspond to different header compression algorithms.
  • the sender also adds a header of the PDCP layer to the data packet, so that the data packet is converted into a PDCP PDU.
  • the sender When the PDCP PDU is transmitted to the MAC layer of the sender, the sender also adds a header to the PDCP PDU to make it a MAC PDU. . That is, the MAC PDU is actually a protocol data unit that includes the PDCP PDU. Finally, the sender sends the MAC PDU to the receiving end, and carries the profile ID and/or the SNLI of the PDCP PDU in the MAC PDU.
  • the receiving module 40 receives the MAC PDU, and obtains the profile ID and/or the SNLI of the PDCP PDU in the MAC PDU through the decompression module 41.
  • the decompression module 41 learns the corresponding header compression algorithm according to the profi le ID, in the PDCP SDU.
  • the IP layer header is decompressed to obtain the data packet sent by the sender, and/or, the decompression module 41 learns the length of the PDCP PDU header according to the SNLI, so as to know the location where the PDCP SDU starts, and then the IP in the PDCP SDU.
  • the layer header is decompressed to obtain the data packet sent by the sender.
  • the sender and the receiver compress and decompress the IP layer header in the PDCP SDU according to the length of the header compression algorithm and/or the PDCP PDU header to enable the user to Correctly received the packet sent by the sender.
  • the receiving end may determine the length of the header of the PDCP PDU by performing other signaling messages (such as user plane configuration information) with the sending end, or may negotiate through the two operations.
  • the decompression module 41 To determine the header length of the PDCP PDU, that is, to determine the location of the PDCP SDU, to ensure the correctness of the IP layer header in the PDCP SDU; the decompression module 41 according to the length of the PDCP PDU header and the header compression corresponding to the profi le ID The algorithm decompresses the PDCP SDU in the PDCP PDU, so that the data packet sent by the sender can be correctly obtained.
  • the receiving module 40 reads the SNLI of the PDCP PDU by using the decompression module 41, and learns the length of the PDCP PDU header to obtain the PDU SDU. Starting position; and reading the header of the data packet in the PDCP SDU through the decompression module 41, determining the profile ID according to the content carried in the packet header, and knowing that Which type of header compression algorithm is used; Finally, the decompression module 41 decompresses the IP layer header of the PDCP SDU according to the header compression algorithm and the length of the PDCP PDU header, so that the data packet sent by the sender can be correctly received.
  • the decompression module 41 first determines the header length of the PDCP PDU by using the SNLI of the PDCP PDU; and then determines the header compression algorithm according to the profi le ID; The decompression module 41 decompresses the IP layer header in the PDCP SDU according to the header compression algorithm and the length of the PDCP PDU header, so that the data packet sent by the sender can be correctly received.
  • the communication device provided by the embodiment of the present invention receives, by the receiving module, the MAC PDU of the SNLI that carries the profi le ID and/or the PDCP PDU sent by the sending end, so that the decompression module is based on the profi le ID and/or the PDCP carried in the MAC PDU.
  • the SNLI of the PDU decompresses the IP layer header in the PDCP SDU, so that the receiving end can correctly receive the data packet sent by the transmitting end.
  • the communication device provided by the embodiment of the present invention enables the transmitting end and the receiving end to correctly receive data without prior configuration when the central node is not controlled, thereby realizing efficient use of the wireless resource.
  • the embodiment relates to receiving the MAC PDU by the receiving module 40, and carrying the header compression algorithm identifier in the MAC CE of the MAC PDU. And/or the SNLI process of the PDCP PDU.
  • the service data stream is sent to the receiving end, where the service data stream includes at least one data packet.
  • the sender adds a MAC CE in the first data packet of the service data flow, and the MAC CE carries the profi le ID and/or the SNLI of the PDCP PDU, and the MAC CE includes both the LGID and the header compression algorithm index (profi le) Index) and/or SNLI of the PDCP PDU, where the LGID is used to indicate the number of a service data flow, the header compression algorithm index is used to indicate the profi le ID, and the SNLI is used to indicate the length of the PDCP SN, that is, the PDCP PDU. The length of the header.
  • the format of the MAC CE can be seen in Table 1 above.
  • the SNLI is used to indicate the number of bits in the SN field in the PDCP PDU.
  • the SN usually has three types: 7 bits, 12 bits, and 15 bits.
  • the number of bits in the SNLI can be 1 bit or 2 bits. Wherein, when the number of bits of the SNLI is 2 bits (00-11), four types of SN lengths may be indicated; when the number of bits of the SNLI is 1 bit (0 or 1), two types of SN lengths may be indicated. Therefore, when two types of SN lengths are used in D2D communication, the SNLI is indicated by 1 bit; when three types of SN lengths are used in D2D communication, the SNLI is indicated by 2 bits.
  • the MAC CE may perform multiple transmissions at the MAC layer. Therefore, in addition to carrying the MAC CE in the first data packet, the following may also be:
  • the sender starts at the service data. Multiple consecutive data packets after transmission carry MAC CE (see Figure 1), and can also be used for direct-through (D2D) broadcast mode, periodically inserting MAC CE during service data transmission, that is, in non-
  • the continuous data packet carries the MAC CE (see FIG. 2), so that the terminal of the broadcast group that joins the D2D at different times can know the profile ID corresponding to the service and/or the SNLI of the PDCP PDU.
  • the receiving module 40 When the receiving module 40 receives the MAC PDU with the MAC CE, the MAC CE is read out by the decompression module 41, and the primitive is sent to the RRC layer of the original; the decompression module 41 sends the RRC layer entity to the user through the receiving end.
  • the PDCP layer of the interface is configured to configure a header compression algorithm (profi le) in the PDCP entity corresponding to the service data flow as a profi le ID carried in the MAC CE, and/or an RRC layer entity to the user through the SNLI.
  • the PDCP layer indicates the SN length of the PDCP (the length of the gp PDCP PDU header), which may be 7 bits or 12 bits or 15 bits.
  • the decompression module 41 establishes the context of the header compression algorithm according to the profi le ID through the PDCP entity in the receiving end, so as to decompress the IP layer header of the PDCP SDU, and/or, the decompression module 41 will follow the SNLI indication.
  • the length is used to read the length of the SN of the PDCP, that is, the length of the header of the PDCP PDU is learned, so that the IP layer header of the PDCP SDU is decompressed later.
  • the sender and the receiver perform data packet header compression and decompression and/or SNLI of the PDCP PDU according to the header compression algorithm corresponding to the PDCP layer's profi le ID indicated in the MAC CE.
  • the IP layer header in the PDCP SDU is compressed and decompressed so that the data packet sent by the sender can be correctly received.
  • the communication device provided by the embodiment of the present invention receives the MAC PDU of the SNLI carrying the profile ID and/or the PDCP PDU sent by the sending end, and the profile ID and/or the SNLI are carried in the MAC CE of the MAC PDU, so that the solution is obtained.
  • the compression module can decompress the IP layer header in the PDCP SDU according to the profile ID and/or the SNLI carried in the MAC CE, so that the receiving end can correctly receive the data packet sent by the sending end.
  • the communication device provided by the embodiment of the present invention enables the transmitting end and the receiving end to correctly receive data without prior configuration when the control center node is not in use, thereby realizing efficient use of the wireless resource.
  • the embodiment relates to the receiver receiving the MAC PDU, and the PDCP PDU in the MAC PDU.
  • the format of the PDCP PDU of the SNLI carrying the profi le ID and/or the PDCP PDU can be referred to Table 2 and Table 3 above, and the detailed descriptions of Table 2 and Table 3 are not described herein.
  • the sender performs IP-related header compression on each PDCP SDU (a PDCP
  • the PDU corresponds to an SDU), and the SNLI of the profi le ID and/or the PDCP PDU used by the PDU is carried in the PDCP PDU and sent to the receiving end, and the D/C bit in the header of the PDCP PDU is filled in, and the PDU type is filled in.
  • the SNLI is filled according to the length of the specific SN. In a service flow, an SN length should be fixed.
  • the sender adds the MAC CE to the PDCP PDU at the MAC layer, and forms a MAC PDU to be sent to the receiving end.
  • the receiving module 40 After receiving the MAC PDU, the receiving module 40 acquires the PDCP PDU through the decompression module 41, and reads the D/C bit in the PDCP PDU.
  • the decompression module 41 detects that the bit is D, it indicates that the data packet carries the SDU of the PDCP, and then the received PDU is interpreted according to the meaning of each bit in Table 2.
  • the decompression module 41 reads the profi le ID and/or the SNLI from the PDU, according to the header compression algorithm corresponding to the profi le ID and/or the header length of the PDCP PDU, the data packet of the transmitting end can be correctly received.
  • the decompression module 41 reads the D/C bit as C
  • the manner in which the format of the PDC PPDU is interpreted is shown in Table 4 and Table 5.
  • the PDU type in Table 4 is 100
  • the PDU type in Table 5 is 011.
  • the PID can be periodically carried in the PDCP PDU, which indicates the profi le ID of the R0HC. , which saves the head overhead of PDCP. In this way, the PDU type will be added one more.
  • Table 6 For the table after the addition, refer to Table 6 and its specific description, and details are not described herein again.
  • the communication device provided by the embodiment of the present invention receives the profile ID sent by the sending end and/or the MAC PDU of the SNLI of the PDCP PDU through the receiving module, and the SNLI of the profile ID and/or the PDCP PDU is carried in the PDCP PDU of the MAC PDU.
  • the decompression module can decompress the PDCP SDU according to the profile ID and/or the SNLI carried in the PDCP PDU, so that the receiving end can correctly receive the data packet sent by the sending end.
  • the communication device provided by the embodiment of the present invention can enable the transmitting end and the receiving end without passing through the control center node. The correct reception of data is realized in advance configuration, thereby achieving efficient use of wireless resources.
  • Embodiment 1 of the present invention provides a configuration indication method.
  • the execution body of the method may be the communication device as the transmitting end in the above embodiment.
  • the method includes: the sending end sends a MAC PDU to the receiving end; wherein the MAC PDU carries a header compression algorithm identifier, and/or an SNLI of the PDCP PDU in the MAC PDU.
  • the MAC CE of the MAC PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the PDCP PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the carrying the header compression algorithm identifier in the PDCP PDU includes: the PDCP PDU periodically carrying the header compression algorithm identifier.
  • FIG. 5 is a schematic flowchart diagram of Embodiment 2 of a configuration indication method provided by the present invention.
  • the execution subject of the method may be the communication device as the receiving end in the above embodiment. As shown in Figure 5, the method includes:
  • the receiving end receives the MAC PDU sent by the sending end, where the MAC PDU carries a header compression algorithm identifier, and/or an SNLI of the PDCP PDU in the MAC PDU.
  • the receiving end decompresses the IP layer header in the PDCP SDU sent by the sending end according to the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the MAC CE of the MAC PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the PDCP PDU carries the header compression algorithm identifier and/or the SNLI of the PDCP PDU.
  • the configuration indication method provided by the embodiment of the present invention, refer to the implementation process of the receiving end in the foregoing embodiment, and the implementation principle and the technical effect are similar, and details are not described herein again.
  • a person skilled in the art can understand that all or part of the steps of implementing the above method embodiments may be completed by using hardware related to program instructions, and the foregoing program may be stored in a computer readable storage medium, and the program is executed when executed.
  • the steps of the foregoing method embodiments are included; and the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

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

Abstract

本发明提供一种配置指示方法和通信设备。该方法包括：发送端向接收端发送媒体接入层协议数据单元MAC PDU；其中，所述MAC PDU中携带头压缩算法标识符，和/或，所述MAC PDU中的分组数据汇聚协议层协议数据单元PDCP PDU的序列号长度指示符SNLI。本发明实施例提供的方法，能够在没有控制中心节点的时候，使发送端和接收端在不经过预先的配置情况下实现数据的正确接收，从而实现无线资源的高效利用。

Description

配置指示方法和通信设备 技术领域
本发明涉及通信技术， 尤其涉及一种配置指示方法和通信设备。 背景技术
移动通信网络中采用网络协议 （Internet Protocol, 以下简称 IP) 做 为传输层， IP协议的包头十分巨大， 语音数据传输的时候包头甚至大于实际 传输的数据包， 在传输时会造成无线资源的浪费。 因此互联网工程任务组 (Internet Engineering Task Force, 以下简称 IETF) 提出了健壮的信标 头压缩 (Robust Header Compression, 以下简称 R0HC) 技术， R0HC由一系 列的头压缩协议组成， SP， R0HC 框架中有多种头压缩算法 （Profile) 。 在 两个通信设备进行通信时， profile 必须是在通讯之前双方都知道而且达成 一致的。 另外， 收发双方的分组数据汇聚协议 （Packet Data Convergence Protocol, 以下简称 PDCP)层负责将 IP头根据约定好的 profile进行压缩和 解压缩， 即 PDCP层可以采用 R0HC的 profile对 IP头进行压缩和解压缩。
现有技术中， 长期演进系统 （Long Term Evolution, 以下简称 LTE) 的 PDCP 层采用 R0HC 技术， 在业务的数据包真正传输之前， 由演进型基站 (Evolved Node B，以下简称 eNB)通过 RRC信令将头压缩算法标识符（prof ile identifier, 以下简称 profile ID)和 PDCP的协议数据单元 (Protocol Data Unit, 以下简称 PDU) PDU 的序列号长度指示符 （Sequence Number Length Indicator, 以下简称 SNLI) 配置给互相通信的用户设备 （User Equipment, 以下简称 UE) ， 该 profile ID用于指示业务数据包所使用的头压缩算法是 哪一种， 该 SNLI用于向接收端指示发送端发送的 PDCP PDU包头的长度， 使 得接收端知道从哪个位置开始解压缩 PDCP 的业务数据单元 （Service Data Unit, 以下简称 SDU) ， 业务数据包的 IP层包头存在于该 PDCP SDU中。 发 送端的 UE根据该 profile ID确定其代表的头压缩算法， 根据该头压缩算法 对数据包进行头压缩， 接收端的 UE首先根据 SNLI的长度确定 PDCP PDU包头 的长度， 即确定 PDCP SDU开始的位置， 然后根据该头压缩算法对 PDCP SDU 的 IP层包头进行解压缩， 以获取正确的数据。
但是， 在分布式的通信中没有类似 eNB的角色来为每个 UE配置 PDCP层 的 R0HC的 profile ID和 PDCP PDU的 SNLI , 使得接收端无法正确接收到发 送端发送的数据包。 发明内容
本发明实施例提供一种配置指示方法和通信设备， 用以解决现有技术中 接收端的 UE无法正确接收到发送端发送的数据包的问题。
第一方面， 本发明提供一种通信设备， 包括：
发送器， 用于向接收端发送媒体接入层协议数据单元 MAC PDU; 其中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分组数据 汇聚协议层协议数据单元 PDCP PDU的序列号长度指示符 SNLI。
结合第一方面， 在第一方面的第一种可能的实施方式中， 所述 MAC PDU 的媒体接入层控制单元 MAC CE中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
结合第一方面， 在第一方面的第二种可能的实施方式中， 所述 PDCP PDU 中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
结合第一方面的第二种可能的实施方式， 在第一方面的第三种可能的实 施方式中， 所述 PDCP PDU中携带所述头压缩算法标识符， 包括：
所述 PDCP PDU周期性携带所述头压缩算法标识符。
第二方面， 本发明提供一种通信设备， 包括：
接收器， 用于接收发送端发送的媒体接入层协议数据单元 MAC PDU; 其 中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分组 数据汇聚协议层协议数据单元 PDCP PDU的序列号长度指示符 SNLI ;
处理器， 用于根据所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI对 所述发送端发送的分组数据汇聚协议层业务数据单元 PDCP SDU中的网络协议 IP层包头进行解压缩。
结合第二方面， 在第二方面的第一种可能的实施方式中， 所述 MAC PDU 的媒体接入层控制单元 MAC CE中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。 结合第二方面， 在第二方面的第二种可能的实施方式中， 所述 PDCP PDU 中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
第三方面， 本发明提供一种通信设备， 包括：
发送模块， 用于向接收端发送媒体接入层协议数据单元 MAC PDU; 其中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分组数据 汇聚协议层协议数据单元 PDCP PDU的序列号长度指示符 SNLI。
结合第三方面， 在第三方面的第一种可能的实施方式中， 所述 MAC PDU 的媒体接入层控制单元 MAC CE中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
结合第三方面， 在第三方面的第二种可能的实施方式中， 所述 PDCP PDU 中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
结合第三方面的第二种可能的实施方式， 在第三方面的第三种可能的实 施方式中， 所述 PDCP PDU中携带所述头压缩算法标识符， 包括：
所述 PDCP PDU周期性携带所述头压缩算法标识符。
第四方面， 本发明提供一种通信设备， 包括：
接收模块， 用于接收发送端发送的媒体接入层协议数据单元 MAC PDU; 其中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分 组数据汇聚协议层协议数据单元 PDCP PDU的序列号长度指示符 SNLI ;
解压缩模块，用于根据所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI 对所述发送端发送的分组数据汇聚协议层业务数据单元 PDCP SDU中的网络协 议 IP层包头进行解压缩。
结合第四方面， 在第四方面的第一种可能的实施方式中， 所述 MAC PDU 的媒体接入层控制单元 MAC CE中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
结合第四方面， 在第四方面的第二种可能的实施方式中， 所述 PDCP PDU 中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
第五方面， 本发明提供一种配置指示方法， 包括：
发送端向接收端发送媒体接入层协议数据单元 MAC PDU; 其中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分组数据汇聚协议 层协议数据单元 PDCP PDU的序列号长度指示符 SNLI。 结合第五方面， 在第五方面的第一种可能的实施方式中， 所述 MAC PDU 的媒体接入层控制单元 MAC CE中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
结合第五方面， 在第五方面的第二种可能的实施方式中， 所述 PDCP PDU 中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
结合第五方面的第二种可能的实施方式， 在第五方面的第三种可能的实 施方式中， 所述 PDCP PDU中携带所述头压缩算法标识符， 包括：
所述 PDCP PDU周期性携带所述头压缩算法标识符。
第六方面， 本发明提供一种配置指示方法， 接收端接收发送端发送的媒 体接入层协议数据单元 MAC PDU; 其中， 所述 MAC PDU中携带头压缩算法标 识符， 和 /或， 所述 MAC PDU中的分组数据汇聚协议层协议数据单元 PDCP PDU 的序列号长度指示符 SNLI ;
所述接收端根据所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI对所 述发送端发送的分组数据汇聚协议层业务数据单元 PDCP SDU 中的网络协议 IP层包头进行解压缩。
结合第六方面， 在第六方面的第一种可能的实施方式中， 所述 MAC PDU 的媒体接入层控制单元 MAC CE中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
结合第六方面， 在第六方面的第二种可能的实施方式中， 所述 PDCP PDU 中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
本发明实施例提供的配置指示方法和通信设备， 通过发送器向接收端 发送携带 profi le ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 使得接收端根据 profi le ID和 /或 PDCP PDU的 SNLI对 PDCP SDU进行解压缩， 从而使得接 收端能够正确接收到发送端发送的数据包。 本发明实施例提供的通信设 备， 能够在没有控制中心节点的时候， 使发送端和接收端在不经过预先的 配置情况下实现数据的正确接收， 从而实现无线资源的高效利用。 附图说明 为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对 实施例或现有技术描述中所需要使用的附图作一简单地介绍， 显而易见 地， 下面描述中的附图是本发明的一些实施例， 对于本领域普通技术人员 来讲， 在不付出创造性劳动的前提下， 还可以根据这些附图获得其他的附 图。
图 1为本发明提供的多个连续数据包携带 MAC CE的示意图；
图 2为本发明提供的在非连续数据包中携带 MAC CE的示意图；
图 3为本发明提供的通信设备实施例二的结构示意图；
图 4为本发明提供的通信设备实施例四的结构示意图；
图 5为本发明提供的配置指示方法实施例二的流程示意图。 具体实施方式 为使本发明实施例的目的、 技术方案和优点更加清楚， 下面将结合本 发明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整地描 述， 显然，所描述的实施例是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有作出创造性劳动前提 下所获得的所有其他实施例， 都属于本发明保护的范围。
本发明实施例中涉及的发送端和接收端， 可以为用户设备， 该用户设 备可以为蜂窝直通终端， 该终端可以是无线终端， 还可以是有线终端。 无 线终端可以是指向用户提供语音和 /或数据连通性的设备， 具有无线连接 功能的手持式设备、 或连接到无线调制解调器的其他处理设备。 无线终端 可以经无线接入网 （例如， RAN, Radio Access Network) 与一个或多个 核心网进行通信， 无线终端可以是移动终端， 如移动电话（或称为 "蜂窝" 电话）和具有移动终端的计算机， 例如， 可以是便携式、 袖珍式、 手持式、 计算机内置的或者车载的移动装置， 它们与无线接入网交换语言和 /或数 据。 例如， 个人通信业务 （PCS, Personal Communication Service) 电 话、 无绳电话、会话发起协议（SIP)话机、 无线本地环路（WLL， Wireless Local Loop) 站、 个人数字助理 （PDA, Personal Digital Assistant) 等设备。 无线终端也可以称为系统、 订户单元 （Subscriber Unit) 、 订 户站（Subscriber Station)，移动站（Mobile Station)、移动台（Mobile)、 远程站 (Remote Station) 、 接入点 (Access Point) 、 远程终端 (Remote Terminal)、接入终端（Access Terminal )、用户终端（User Terminal )、 用户代理 （User Agent ) 、 用户设备 （User Device ) 、 或用户装备 （User Equipment ) 。
本发明实施例一提供一种通信设备， 该通信设备为发送端的通信设 备， 该通信设备包括发送器 10， 用于向接收端发送媒体接入层协议数据单 元 (Media Access Control Protocol Data Unit, 以下简称 MAC PDU) ； 其 中，该 MAC PDU中携带 profile ID,和 /或，该 MAC PDU中的 PDCP PDU的 SNLI。
具体的， 在上述通信设备开启直通模式后， 通过发送器 10向接收端发送 一个业务数据流，该业务数据流包括至少一个数据包。数据包在发送端的 PDCP 层时， 该通信设备会对该数据包进行头压缩， 该头压缩过程使用的是某一头 压缩算法（profile) ,该头压缩算法可以通过头压缩算法标识符（profile ID) 来指示， 不同的 profi le ID对应不同的头压缩算法。 该通信设备还会对该数 据包添加 PDCP层的包头， 使得该数据包转换为 PDCP PDU; 当 PDCP PDU传输 到发送端的 MAC层时， 该通信设备同样会对该 PDCP PDU添加 MAC层的包头， 使其成为 MAC PDUo 也就是说， MAC PDU实际上是包括 PDCP PDU的一个协议 数据单元。 最后， 发送器 10将 MAC PDU发送给接收端， 并将上述 prof ile ID 和 /或 PDCP PDU的 SNLI携带在 MAC PDU中。
接收端接收该 MAC PDU, 获取该 MAC PDU中的 profile ID和 /或 PDCP PDU 的 SNLI; 接收端根据该 profile ID获知其对应的头压缩算法， 对 PDCP SDU 中的 IP层包头进行解压缩， 以获取发送端发送的数据包， 和 /或， 接收端根 据 SNLI获知 PDCP PDU包头的长度， 从而获知 PDCP SDU开始的位置， 进而对 该 PDCP SDU中的 IP层包头进行解压缩以获取发送端发送的数据包。 并且， 在后续的数据包发送和接收过程中， 该通信设备和接收端就按照这个头压缩 算法和 /或 PDCP PDU包头的长度对 PDCP SDU中的 IP层包头进行压缩和解压 缩， 以使接收端能够正确接收到发送端发送的数据包。
可选的， 当 MAC PDU中仅包括 profile ID时， 接收端可以通过与发送端 交互其他的信令消息（比如用户面配置信息）， 来确定 PDCP PDU的包头长度， 也可以通过二者协商操作来确定 PDCP PDU的包头长度， 即确定 PDCP SDU开 始的位置， 以确保对 PDCP SDU中的 IP层包头解压缩的正确性； 接收端根据 该 PDCP PDU包头的长度以及 profile ID对应的头压缩算法对 PDCP PDU中的 PDCP SDU的 IP层包头进行解压缩， 从而可以正确获取到发送端发送的数据 包。
可选的， 当 MAC PDU中仅包括 PDCP PDU的 SNLI时， 接收端在接收到 MAC PDU时， 读取 PDCP PDU的 SNLI , 获知该 PDCP PDU包头的长度， 从而获知 PDU SDU开始的位置； 并通过读取 PDCP SDU中的数据包的包头， 根据包头中携带 的内容确定 profile ID, 获知应该用哪一种头压缩算法； 最后， 接收端根据 该头压缩算法和该 PDCP PDU包头的长度对 PDCP SDU的 IP层包头进行解压缩， 从而可以正确接收到发送端发送的数据包。
可选的， 当 MAC PDU中同时携带了 profile ID和 PDCP PDU的 SNLI时， 接收端首先通过 SNLI确定 PDCP PDU的包头长度； 然后根据 profile ID确定 头压缩算法； 最后， 接收端根据该头压缩算法和该 PDCP PDU包头的长度对 PDCP SDU的 IP层包头进行解压缩， 从而可以正确接收到发送端发送的数据 包。
本发明实施例提供的通信设备， 通过发送器向接收端发送携带 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 使得接收端根据 profile ID 和 /或 PDCP PDU的 SNLI对 PDCP SDU进行解压缩， 从而使得接收端能够正 确接收到发送端发送的数据包。 本发明实施例提供的通信设备， 能够在没 有控制中心节点的时候， 使发送端和接收端在不经过预先的配置情况下实 现数据的正确接收， 从而实现无线资源的高效利用。
在上述实施例一的基础上， 作为本发明实施例的一种可能的实施方 式， 本实施例涉及的是将上述头压缩算法标识符和 /或 PDCP PDU的 SNLI携 带在 MAC PDU 的媒体接入层控制单元 （MAC Control Element , 以下简称 MAC CE ) 中发送给接收端的过程。
具体的， 在上述通信设备开启直通模式后， 通过发送器 10向接收端发送 一个业务数据流， 该业务数据流包括至少一个数据包。 通信设备在该业务数 据流的第一个数据包中添加 MAC CE,该 MAC CE携带 profile ID和 /或 PDCP PDU 的 SNLI , 该 MAC CE既包括逻辑信道标识符 (Logical Channel Identifier, 以下简称 LGID) ， 也包括头压缩算法索引 （profile index) 和 /或 PDCP PDU 的 SNLI , 其中， 该 LGID是用来指示一个业务数据流的编号的， 头压缩算法 索引用来指示 profile ID, SNLI用于指示 PDCP的序列号 ( Serial Number, 以下简称 SN) 的长度， 即 PDCP PDU的包头的长度。 该 MAC CE的格式可以参 见表 1。其中， SNLI是用来指示 PDCP PDU中 SN域的比特位数， SN通常有 7bit、 12bit和 15bit三种。 SNLI的比特位数可以是 lbit或者 2bit。 其中， SNLI 的比特位数为 2bit时 （00-11 ) ， 可以指示 4种 SN长度； SNLI的比特位数 为 1比特时 （0或 1 ) ， 可以指示 2种 SN长度。 故， 当 D2D通信中使用 2种 SN长度时，则 SNLI用 lbit指示； 当 D2D通信中使用 3种 SN长度时，则 SNLI 用 2bit进行指示。
表 1
LGID Profi le index SNLI 可选的， 为了保证 MAC CE 的接收可靠性， 这个 MAC CE 可以在 MAC 层多次进行传输， 因此， 除了上述在第一个数据包中携带 MAC CE, 还可以 为: 发送器 10在业务数据开始传输之后的多个连续的数据包中携带 MAC CE (参见图 1 所示） ， 还可以为针对直通 （D2D ) 的广播模式， 在业务数 据传输的过程中周期性的插入 MAC CE, 即在非连续的数据包中携带 MAC CE (参见图 2 ) ， 这样可以让在不同时间加入 D2D的广播组的终端都能够 知道这个业务对应的 profile ID和 /或 SNLI。
当接收端接收到该带有 MAC CE的 MAC PDU时， 将 MAC CE读出， 并形 成原语发送给自身的 RRC层； 接收端通过自身的 RRC层实体给用户面的 PDCP层进行配置， 将该业务数据流对应的 PDCP实体中的头压缩算法
( profi le ) 配置为 MAC CE中携带的 profi le ID, 和 /或， RRC层实体通 过 SNLI向用户面的 PDCP层指示 PDCP的 SN长度 （即 PDCP PDU包头的长 度） ， 该长度可以是 7bit或者 12bit或者 15bit。 接收端中的 PDCP实体 会按照这个 profi le ID建立头压缩算法的上下文，以便于之后对 PDCP SDU 的 IP层包头解压缩，和 /或，接收端会按照 SNLI所指示的长度来读取 PDCP 的 SN的长度， 即获知 PDCP PDU的包头的长度， 以便于之后对 PDCP SDU 的 IP层包头解压缩。
在后续的数据包发送和接收过程中， 该通信设备和接收端就按照这个
MAC CE中指示的 PDCP层的 profi le ID 对应的头压缩算法和 /或 SNLI , 来对 PDCP SDU的 IP层包头进行压缩和解压缩， 以便于能够正确接收到发 送端发送的数据包。
本发明实施例提供的通信设备， 通过发送器向接收端发送携带 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 并且该 profile ID和 /或 SNLI携带在 MAC PDU的 MAC CE中， 使得接收端能够根据该 MAC CE中携带 的 profile ID和 /或 SNLI对 PDCP SDU的 IP层包头进行解压缩， 从而使得 接收端能够正确接收到发送端发送的数据包。本发明实施例提供的通信设 备， 能够在没有控制中心节点的时候， 使发送端和接收端在不经过预先的 配置情况下实现数据的正确接收， 从而实现无线资源的高效利用。
在上述实施例一的基础上， 作为本发明实施例的另一种可能的实施方 式， 本实施例的涉及的是将 profi le ID和 /或 PDCP PDU的 SNLI携带在 MAC PDU的 PDCP PDU中发送给接收端的过程。
具体的， 该携带 profi le ID和 /或 PDCP PDU的 SNLI的 PDCP PDU的格 式可以参见表 2所示：
表 2
Figure imgf000010_0001
表 2中， D/C中的 D表明这个 PDU是数据单元， C表明这个 PDU是 PDCP 的控制单元， 在本实施例中该比特位是 D。 PDU type表明这个 PDU的类型， PDU的具体类型可以通过相应的 " 0 "或 " 1 " 比特的组合来指示， 具体可 以参见表 3 : 表 3
Figure imgf000010_0002
100 携带 profi le的分散 ROHC 反馈数据
包
101-111 保留
表 3中， " 000 " 和 " 001 " 指代的 PDU type 目前在 LTE中已经使用 了， 其余的比特是本发明实施例新增的类型， 可以使用 010-111中任意一 个 bit序列来表示该 PDU的类型。
表 2中， SNLI 表示 PDCP SN的长度指示比特， 表示 PDCP PDU的包头 中 SN的长度， 能够根据它得到 PDCP SDU开始的位置； SNLI可能有 1比特 或 2比特长两种， D2D通信系统中规定若只能使用 2种 SN长度时， SNLI 为 lbit , 若使用 3种长度时， SNLI为 2比特。 例如， 当 SNLI只有 1位比 特且 SNLI的值为 1时，表示 SN为 7位的 SN;当 SNLI只有 1位比特且 SNLI 的值为 0时， 表示 SN为 12bit的 SN; 当 SNLI有 2位比特时且 SNLI的值 为 00时， 表示 SN为 7位的 SN; ， 当 SNLI有 2位比特的且 SNLI的值为 01时， 表示 SN为 12bit的 SN; 当 SNLI有 2位比特且 SNLI的值为 10时， 表示 SN为 15位； SNLI有 2位比特且 SNLI的值为 11的情况， 目前可以暂 时不用， 有新的 SN长度时再使用。 PID指代上述的 profi le ID。
上述通信设备对每个 PDCP SDU在进行 IP相关的头压缩之后 （一个 PDCP的 PDU对应一个 SDU)，就将自己使用的 profi le ID和 /或该 PDCP PDU 的 SNLI携带在 PDCP PDU中通过发送器 10发送给接收端， 在 PDCP PDU 包头中的 D/C比特位填写 D， PDU type 则填写表 3中的 010， SNLI则按照 具体的 SN的长度对应的指示比特值来填写， 在一个业务流中， 应该固定 采取一种 SN长度。之后， 该通信设备将该 PDCP PDU在 MAC层添加 MAC CE， 形成 MAC PDU发送给接收端。
接收端在接收到该 MAC PDU之后， 获取 PDCP PDU, 并读取该 PDCP PDU 中的 D/C bit。当接收端检测到该 bit为 D时，表明这个数据包携带了 PDCP SDU, 于是按照表 2中的每个 bit的含义来解读接收到的 PDU。 当接收端从 这个 PDU中读取到了 profi le ID和 /或 SNLI之后， 根据该 profi le ID对 应的头压缩算法和 /或 PDCP PDU的包头长度来获得正确的 SDU位置， 并且 解压缩 PDCP SDU的 IP层包头， 以便能够正确接收到发送端的数据包。
可选的， 当接收端读取 D/C bit 为 C时， 则 PDC PPDU的格式的解读 方式为表 4与表 5所示。 其中， 表 4中的 PDU type 为 100， 表 5中的 PDU type为 011。
4
D/C PDU Type PID Oct 1
PID 分散的 ROHC反馈包 Oct2
…表 5
Ό/C PDU Type PID Oct 1
PID FMS Oct 2
FMS Bitmap! (optional) Oct 3
BitmapN (optional) Oct 2+N 表 5中， 第一个丢失的 PDCP序列号 （First Missing PDCP SN， 以下 简称 FMS) 用于指示第一个丢失的 PDCP SDU的 PDCP SN; 位图 （Bitmap) 用于指示丢失的 PDCP SN究竟是哪些。
进一步地， 由于一个业务流的数据包通常会持续一段时间， 这样这个 头压缩算法的使用就会持续一段时间， 因此可以在 PDCP PDU 中周期性的 携带 PID, 这样既指示了 R0HC的 profile ID, 又节省了 PDCP的头部开销。 这样 PDU type就会又增加一种， 增加之后的表格如表 6所示：
表 6
比特 描述
000 PDCP 状态报告
001 分散的 R0HC 反馈数据包
010 携带 profile的 PDU数据包
011 携带 profile的 PDU状态报告
100 携带 profile的分散 R0HC 反馈数据包
101 不携带 PID 的 PDU数据包 110-111 保留
在表 6中， " 000 " 和 " 001 "指代的 PDU type目前在 LTE中已经使 用了；其余的比特是本发明新增的类型，可以使用 010-111中任意一个 bit 序列来表示该 PDU的类型； " 010 "和 " 101 "这种 PDU类型要求 D/C比特 位必须是 D b i t o
本发明实施例提供的通信设备， 通过发送器向接收端发送携带 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 并且该 profile ID和 /或 PDCP PDU的 SNLI携带在 MAC PDU的 PDCP PDU中， 使得接收端能够根据该 PDCP PDU中携带的 profile ID和 /或 SNLI对 PDCP SDU的 IP层包头进行解 压缩， 从而使得接收端能够正确接收到发送端发送的数据包。 本发明实施 例提供的通信设备， 能够在没有控制中心节点的时候， 使发送端和接收端 在不经过预先的配置情况下实现数据的正确接收， 从而实现无线资源的高 效利用。 图 3为本发明提供的通信设备实施例二的结构示意图， 该通信设备为 接收端的通信设备。 如图 3所示， 该通信设备包括： 接收器 20和处理器 21。 其中， 接收器 20， 用于接收发送端发送的 MAC PDU; 其中， 该 MAC PDU 中携带头压缩算法标识符， 和 /或， 该 MAC PDU中的 PDCP PDU的 SNLI ; 处理 器 21， 用于根据所述头压缩算法标识符和 /或 PDCP PDU的 SNLI对发送端发 送的 PDCP SDU进行解压缩。
具体的， 发送端开启直通模式之后， 向接收端发送一个业务数据流， 该 业务数据流包括至少一个数据包。数据包在发送端的 PDCP层时， 发送端会对 该数据包进行头压缩， 该头压缩过程使用的是某一头压缩算法 （profile) ， 该头压缩算法可以通过头压缩算法标识符 （profile ID ) 来指示， 不同的 profile ID对应不同的头压缩算法。 发送端还会对该数据包添加 PDCP层的 包头， 使得该数据包转换为 PDCP PDU; 当 PDCP PDU传输到发送端的 MAC层 时， 发送端同样会对该 PDCP PDU添加包头， 使其成为 MAC PDU。 也就是说， MAC PDU实际上是包括 PDCP PDU的一个协议数据单元。最后，发送端将 MAC PDU 发送给接收端， 并将上述 profile ID和 /或 PDCP PDU的 SNLI携带在 MAC PDU 中。 接收器 20接收该 MAC PDU, 通过处理器 21获取该 MAC PDU中的 profile ID和 /或 PDCP PDU的 SNLI; 处理器 21根据该 profile ID获知其对应的头压 缩算法， 对 PDCP SDU中的 IP层包头进行解压缩， 以获取发送端发送的数据 包， 和 /或， 处理器 21根据 SNLI获知 PDCP PDU包头的长度， 从而获知 PDCP SDU开始的位置， 进而对该 PDCP SDU中的 IP层包头进行解压缩以获取发送 端发送的数据包。 并且， 在后续的数据包发送和接收过程中， 发送端和接收 端就按照这个头压缩算法和 /或 PDCP PDU包头的长度对该 PDCP SDU中的 IP 层包头进行压缩和解压缩， 以使自身能够正确接收到发送端发送的数据包。
可选的， 当 MAC PDU中仅包括 profile ID时， 接收端可以通过与发送端 交互其他的信令消息（比如用户面配置信息）， 来确定 PDCP PDU的包头长度， 也可以通过二者协商操作来确定 PDCP PDU的包头长度， 即确定 PDCP SDU开 始的位置， 确保对 PDCP SDU中的 IP层包头解压缩的正确性； 处理器 21根据 该 PDCP PDU包头的长度以及 profile ID对应的头压缩算法对 PDCP PDU中的 PDCP SDU进行解压缩， 从而可以正确获取到发送端发送的数据包。
可选的， 当 MAC PDU中仅包括 PDCP PDU的 SNLI时， 接收器 20在接收到
MAC PDU时， 通过处理器 21读取 PDCP PDU的 SNLI , 获知该 PDCP PDU包头的 长度， 从而获知 PDU SDU开始的位置； 并通过处理器 21读取 PDCP SDU中的 数据包的包头， 根据包头中携带的内容确定 profile ID, 获知应该用哪一种 头压缩算法； 最后， 处理器 21根据该头压缩算法和该 PDCP PDU包头的长度 对 PDCP SDU的 IP层包头进行解压缩， 从而可以正确接收到发送端发送的数 据包。
可选的， 当 MAC PDU中同时携带了 profile ID和 PDCP PDU的 SNLI时， 处理器 21首先通过 PDCP PDU的 SNLI确定 PDCP PDU的包头长度； 然后根据 profile ID确定头压缩算法；最后，处理器 21根据该头压缩算法和该 PDCP PDU 包头的长度对 PDCP SDU中的 IP层包头进行解压缩， 从而可以正确接收到发 送端发送的数据包。
本发明实施例提供的通信设备， 通过接收器接收发送端发送的携带 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 使得处理器根据该 MAC PDU 中携带的 profile ID和 /或 PDCP PDU的 SNLI对 PDCP SDU中的 IP层包头进 行解压缩， 从而使得接收端能够正确接收到发送端发送的数据包。 本发明 实施例提供的通信设备， 能够在没有控制中心节点的时候， 使发送端和接 收端在不经过预先的配置情况下实现数据的正确接收， 从而实现无线资源 的高效利用。
在上述实施例二的基础上， 作为本发明实施例的一种可能的实施方 式， 本实施例涉及的是将接收器 20接收 MAC PDU, 且该 MAC PDU的 MAC CE 中携带头压缩算法标识符和 /或 PDCP PDU的 SNLI的过程。
具体的， 在发送端开启直通模式后， 向接收端发送一个业务数据流， 该 业务数据流包括至少一个数据包。 发送端在该业务数据流的第一个数据包中 添加 MAC CE, 该 MAC CE携带 profile ID和 /或 PDCP PDU的 SNLI , 该 MAC CE 包括既包括 LGID, 也包括头压缩算法索引 （profile index) 和 /或 PDCP PDU 的 SNLI , 其中， 该 LGID是用来指示一个业务数据流的编号的， 头压缩算法 索引用来指示 profi le ID, SNLI用于指示 PDCP的 SN的长度， 即 PDCP PDU 的包头的长度。 该 MAC CE的格式可以参见上述表 1所示。 其中， SNLI是用 来指示 PDCP PDU中 SN域的比特位数， SN通常有 7bit、 12bit和 15bit三种。 SNLI的比特位数可以是 lbit或者 2bit。 其中， SNLI的比特位数为 2bit时 (00-11 ) ， 可以指示 4种 SN长度； SNLI的比特位数为 1比特时 （0或 1 ) ， 可以指示 2种 SN长度。 故， 当 D2D通信中使用 2种 SN长度时， 则 SNLI用 lbit指示； 当 D2D通信中使用 3种 SN长度时， 则 SNLI用 2bit进行指示。 可选的， 为了保证 MAC CE的接收可靠性， 这个 MAC CE可以在 MAC层多次 进行传输， 因此， 除了上述在第一个数据包中携带 MAC CE, 还可以为： 发 送端在业务数据开始传输之后的多个连续的数据包中携带 MAC CE (参见 图 1 所示） ， 还可以为针对直通 （D2D ) 的广播模式， 在业务数据传输的 过程中周期性的插入 MAC CE, 即在非连续的数据包中携带 MAC CE (参 见图 2 ) ， 这样可以让在不同时间加入 D2D的广播组的终端都能够知道这 个业务对应的 profile ID和 /或 PDCP PDU的 SNLI。
当接收器 20接收到该带有 MAC CE的 MAC PDU时， 通过处理器 21将 MAC CE读出， 并形成原语发送给自身的 RRC层； 处理器 21通过接收端的 RRC层实体给用户面的 PDCP层进行配置， 将该业务数据流对应的 PDCP实 体中的头压缩算法 （profi le ) 配置为 MAC CE中携带的 profi le ID, 和 / 或， RRC层实体通过上述 SNLI向用户面的 PDCP层指示 PDCP的 SN长度（即 PDCP PDU包头的长度） ， 该长度可以是 7bit或者 12bit或者 15bit。 处 理器 21通过接收端中的 PDCP实体， 按照这个 profi le ID建立头压缩算 法的上下文， 以便于之后对 PDCP SDU的 IP层包头解压缩， 和 /或， 处理 器 21会按照 SNLI所指示的长度来读取 PDCP的 SN的长度，即获知 PDCP PDU 的包头的长度， 以便于之后对 PDCP SDU的 IP层包头解压缩。
在后续的数据包发送和接收过程中， 发送端和接收端就按照这个 MAC CE中指示的 PDCP层的 profi le ID 对应的头压缩算法进行数据包头压缩 和解压缩和 /或 PDCP PDU的 SNLI , 来对 PDCP SDU中的 IP层包头进行压缩 和解压缩， 以便于能够正确接收到发送端发送的数据包。
本发明实施例提供的通信设备， 通过接收器接收发送端发送的携带 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 并且该 profile ID和 /或 SNLI携带在 MAC PDU的 MAC CE中， 使得处理器能够根据该 MAC CE中携带 的 profile ID和 /或 SNLI对 PDCP SDU中的 IP层包头进行解压缩， 从而使 得接收端能够正确接收到发送端发送的数据包。 本发明实施例提供的通信 设备， 能够在没有控制中心节点的时候， 使发送端和接收端在不经过预先 的配置情况下实现数据的正确接收， 从而实现无线资源的高效利用。
在上述实施例二的基础上， 作为本发明实施例的另一种可能的实施方 式， 本实施例的涉及的是接收器接收 MAC PDU, 且该 MAC PDU中的 PDCP PDU 携带 profi le ID和 /或 PDCP PDU的 SNLI的过程。
具体的， 该携带 profi le ID和 /或 PDCP PDU的 SNLI的 PDCP PDU的格 式可以参见上述表 2和表 3， 以及， 表 2和表 3的具体描述， 在此不再赘 述。
发送端对每个 PDCP SDU在进行 IP相关的头压缩之后 （一个 PDCP的 PDU对应一个 SDU) ， 就将自己使用的 profi le ID和 /或 PDCP PDU的 SNLI 携带在 PDCP PDU中发送给接收端， 并在 PDCP PDU包头中的 D/C比特位填 写 D ， PDU type 则填写表 3中的 010， SNLI则按照具体的 SN的长度来填 写，在一个业务流中， 应该固定采取一种 SN长度。之后， 发送端将该 PDCP PDU在 MAC层添加 MAC CE, 形成 MAC PDU发送给接收端。
接收器 20在接收到该 MAC PDU之后， 通过处理器 21获取 PDCP PDU, 并读取该 PDCP PDU中的 D/C bit。 当处理器 21检测到该 bit为 D时， 表 明这个数据包携带了 PDCP的 SDU,于是按照表 2中的每个 bit的含义来解 读接收到的 PDU。 当处理器 21从这个 PDU中读取到了 profi le ID和 /或 SNLI之后， 根据该 profi le ID对应的头压缩算法和 /或 PDCP PDU的包头 长度， 以便能够正确接收到发送端的数据包。
可选的， 当处理器 21读取 D/C bit 为 C时， 则 PDC PPDU的格式的解 读方式参见表 4与表 5所示。 其中， 表 4中的 PDU type 为 100， 表 5中 的 PDU type为 011。
进一步地， 由于一个业务流的数据包通常会持续一段时间， 这样这个 头压缩算法的使用就会持续一段时间， 因此可以在 PDCP PDU 中周期性的 携带 PID, 这样既指示了 R0HC的 profi le ID, 又节省了 PDCP的头部开销。 这样 PDU type就会又增加一种， 增加之后的表格可以参见表 6及其具体 描述， 在此不再赘述。
本发明实施例提供的通信设备， 通过接收器接收发送端发送的 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 并且该 profile ID和 /或 PDCP PDU的 SNLI携带在 MAC PDU的 PDCP PDU中， 使得处理器能够根据该 PDCP PDU中携带的 profile ID和 /或 SNLI对 PDCP SDU进行解压缩， 从而 使得接收端能够正确接收到发送端发送的数据包。本发明实施例提供的通 信设备， 能够在没有控制中心节点的时候， 使发送端和接收端在不经过预 先的配置情况下实现数据的正确接收， 从而实现无线资源的高效利用。
本发明实施例三提供一种通信设备， 该通信设备为发送端的通信设 备， 该通信设备包括发送模块 30， 用于向接收端发送 MAC PDU; 其中， 该 MAC PDU中携带 profile ID, 和 /或， 该 MAC PDU中的 PDCP PDU的 SNLI。
具体的， 在上述通信设备开启直通模式后， 通过发送模块 30向接收端发 送一个业务数据流， 该业务数据流包括至少一个数据包。 数据包在发送端的 PDCP层时， 该通信设备会对该数据包进行头压缩， 该头压缩过程使用的是某 一头压缩算法（ prof i le )，该头压缩算法可以通过头压缩算法标识符（ prof i le ID) 来指示， 不同的 profi le ID对应不同的头压缩算法。 该通信设备还会对 该数据包添加 PDCP层的包头， 使得该数据包转换为 PDCP PDU; 当 PDCP PDU 传输到发送端的 MAC层时， 该通信设备同样会对该 PDCP PDU添加 MAC层的包 头， 使其成为 MAC PDUo 也就是说， MAC PDU实际上是包括 PDCP PDU的一个 协议数据单元。最后，发送模块 30将 MAC PDU发送给接收端，并将上述 profile ID和 /或 PDCP PDU的 SNLI携带在 MAC PDU中。
接收端接收该 MAC PDU, 获取该 MAC PDU中的 prof i le ID和 /或 PDCP PDU 的 SNLI; 接收端根据该 profile ID获知其对应的头压缩算法， 对 PDCP SDU 中的 IP层包头进行解压缩， 以获取发送端发送的数据包， 和 /或， 接收端根 据 SNLI获知 PDCP PDU包头的长度， 从而获知 PDCP SDU开始的位置， 进而对 该 PDCP SDU中的 IP层包头进行解压缩以获取发送端发送的数据包。 并且， 在后续的数据包发送和接收过程中， 该通信设备和接收端就按照这个头压缩 算法和 /或 PDCP PDU包头的长度对 PDCP SDU中的 IP层包头进行压缩和解压 缩， 以使接收端能够正确接收到发送端发送的数据包。
可选的， 当 MAC PDU中仅包括 profile ID时， 接收端可以通过与发送端 交互其他的信令消息（比如用户面配置信息）， 来确定 PDCP PDU的包头长度， 也可以通过二者协商操作来确定 PDCP PDU的包头长度， 即确定 PDCP SDU开 始的位置， 以确保对 PDCP SDU中的 IP层包头解压缩的正确性； 接收端根据 该 PDCP PDU包头的长度以及 profile ID对应的头压缩算法对 PDCP PDU中的 PDCP SDU的 IP层包头进行解压缩， 从而可以正确获取到发送端发送的数据 包。
可选的， 当 MAC PDU中仅包括 PDCP PDU的 SNLI时， 接收端在接收到 MAC
PDU时， 读取 PDCP PDU的 SNLI , 获知该 PDCP PDU包头的长度， 从而获知 PDU SDU开始的位置； 并通过读取 PDCP SDU中的数据包的包头， 根据包头中携带 的内容确定 profile ID, 获知应该用哪一种头压缩算法； 最后， 接收端根据 该头压缩算法和该 PDCP PDU包头的长度对 PDCP SDU的 IP层包头进行解压缩， 从而可以正确接收到发送端发送的数据包。
可选的， 当 MAC PDU中同时携带了 profile ID和 PDCP PDU的 SNLI时， 接收端首先通过 SNLI确定 PDCP PDU的包头长度； 然后根据 profile ID确定 头压缩算法； 最后， 接收端根据该头压缩算法和该 PDCP PDU包头的长度对 PDCP SDU的 IP层包头进行解压缩， 从而可以正确接收到发送端发送的数据 包。 本发明实施例提供的通信设备， 通过发送模块向接收端发送携带 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 使得接收端根据 profile ID 和 /或 PDCP PDU的 SNLI对 PDCP SDU进行解压缩， 从而使得接收端能够正 确接收到发送端发送的数据包。 本发明实施例提供的通信设备， 能够在没 有控制中心节点的时候， 使发送端和接收端在不经过预先的配置情况下实 现数据的正确接收， 从而实现无线资源的高效利用。
在上述实施例三的基础上， 作为本发明实施例的一种可能的实施方 式， 本实施例涉及的是将上述头压缩算法标识符和 /或 PDCP PDU的 SNLI携 带在 MAC PDU的 MAC CE中发送给接收端的过程。
具体的， 在上述通信设备开启直通模式后， 通过发送模块 30向接收端发 送一个业务数据流， 该业务数据流包括至少一个数据包。 通信设备在该业务 数据流的第一个数据包中添加 MAC CE, 该 MAC CE携带 profile ID和 /或 PDCP PDU的 SNLI ,该 MAC CE既包括 LGID)也包括头压缩算法索引（profile index) 和 /或 PDCP PDU的 SNLI , 其中， 该 LGID是用来指示一个业务数据流的编号 的，头压缩算法索引用来指示 profile ID, SNLI用于指示 PDCP的 SN的长度， 即 PDCP PDU的包头的长度。 该 MAC CE的格式可以参见上述表 1所示。 其中， SNLI是用来指示 PDCP PDU中 SN域的比特位数， SN通常有 7bit、 12bit和 15bit三种。 SNLI的比特位数可以是 lbit或者 2bito 其中， SNLI的比特位 数为 2bit时 （00-11 ) ， 可以指示 4种 SN长度； SNLI的比特位数为 1比特 时（0或 1 )， 可以指示 2种 SN长度。故， 当 D2D通信中使用 2种 SN长度时， 则 SNLI用 lbit指示； 当 D2D通信中使用 3种 SN长度时， 则 SNLI用 2bit进 行指示。
可选的， 为了保证 MAC CE 的接收可靠性， 这个 MAC CE 可以在 MAC 层多次进行传输， 因此， 除了上述在第一个数据包中携带 MAC CE, 还可以 为：发送模块 30在业务数据开始传输之后的多个连续的数据包中携带 MAC CE (参见图 1 所示） ， 还可以为针对直通 （D2D ) 的广播模式， 在业务数 据传输的过程中周期性的插入 MAC CE, 即在非连续的数据包中携带 MAC CE (参见图 2 ) ， 这样可以让在不同时间加入 D2D的广播组的终端都能够 知道这个业务对应的 profile ID和 /或 SNLI。
当接收端接收到该带有 MAC CE的 MAC PDU时， 将 MAC CE读出， 并形 成原语发送给自身的 RRC层； 接收端通过自身的 RRC层实体给用户面的 PDCP层进行配置， 将该业务数据流对应的 PDCP实体中的头压缩算法
( profi le ) 配置为 MAC CE中携带的 profi le ID, 和 /或， RRC层实体通 过 SNLI向用户面的 PDCP层指示 PDCP的 SN长度 （即 PDCP PDU包头的长 度） ， 该长度可以是 7bit或者 12bit或者 15bit。 接收端中的 PDCP实体 会按照这个 profi le ID建立头压缩算法的上下文，以便于之后对 PDCP SDU 的 IP层包头解压缩，和 /或，接收端会按照 SNLI所指示的长度来读取 PDCP 的 SN的长度， 即获知 PDCP PDU的包头的长度， 以便于之后对 PDCP SDU 的 IP层包头解压缩。
在后续的数据包发送和接收过程中， 该通信设备和接收端就按照这个
MAC CE中指示的 PDCP层的 profi le ID 对应的头压缩算法和 /或 SNLI , 来对 PDCP SDU的 IP层包头进行压缩和解压缩， 以便于能够正确接收到发 送端发送的数据包。
本发明实施例提供的通信设备， 通过发送模块向接收端发送携带 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 并且该 profile ID和 /或 SNLI携带在 MAC PDU的 MAC CE中， 使得接收端能够根据该 MAC CE中携带 的 profile ID和 /或 SNLI对 PDCP SDU的 IP层包头进行解压缩， 从而使得 接收端能够正确接收到发送端发送的数据包。本发明实施例提供的通信设 备， 能够在没有控制中心节点的时候， 使发送端和接收端在不经过预先的 配置情况下实现数据的正确接收， 从而实现无线资源的高效利用。
在上述实施例三的基础上， 作为本发明实施例的另一种可能的实施方 式， 本实施例的涉及的是将 profi le ID和 /或 PDCP PDU的 SNLI携带在 MAC PDU的 PDCP PDU中发送给接收端的过程。
具体的， 该携带 profi le ID和 /或 PDCP PDU的 SNLI的 PDCP PDU的格 式可以参见表 2和表 3， 以及， 表 2和表 3的具体描述， 在此不再赘述。
上述通信设备对每个 PDCP SDU在进行 IP相关的头压缩之后 （一个 PDCP的 PDU对应一个 SDU)，就将自己使用的 profi le ID和 /或该 PDCP PDU 的 SNLI携带在 PDCP PDU中通过发送模块 30发送给接收端， 在 PDCP PDU 包头中的 D/C比特位填写 D， PDU type 则填写表 3中的 010， SNLI则按照 具体的 SN的长度对应的指示比特值来填写， 在一个业务流中， 应该固定 采取一种 SN长度。之后， 该通信设备将该 PDCP PDU在 MAC层添加 MAC CE， 形成 MAC PDU发送给接收端。
接收端在接收到该 MAC PDU之后， 获取 PDCP PDU, 并读取该 PDCP PDU 中的 D/C bit。当接收端检测到该 bit为 D时，表明这个数据包携带了 PDCP SDU, 于是按照表 2中的每个 bit的含义来解读接收到的 PDU。 当接收端从 这个 PDU中读取到了 profi le ID和 /或 SNLI之后， 根据该 profi le ID对 应的头压缩算法和 /或 PDCP PDU的包头长度来获得正确的 SDU位置， 并且 解压缩 PDCP SDU的 IP层包头， 以便能够正确接收到发送端的数据包。
可选的， 当接收端读取 D/C bit 为 C时， 则 PDC PPDU的格式的解读 方式参见上述表 4与表 5所示。 其中， 表 4中的 PDU type 为 100， 表 5 中的 PDU type为 011。
进一步地， 由于一个业务流的数据包通常会持续一段时间， 这样这个 头压缩算法的使用就会持续一段时间， 因此可以在 PDCP PDU 中周期性的 携带 PID, 这样既指示了 R0HC的 profi le ID, 又节省了 PDCP的头部开销。 这样 PDU type就会又增加一种， 增加之后的表格参见上述表 6所示及其 具体描述， 在此不再赘述。
本发明实施例提供的通信设备， 通过发送模块向接收端发送携带 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 并且该 profile ID和 /或 PDCP PDU的 SNLI携带在 MAC PDU的 PDCP PDU中， 使得接收端能够根据该 PDCP PDU中携带的 profile ID和 /或 SNLI对 PDCP SDU的 IP层包头进行解 压缩， 从而使得接收端能够正确接收到发送端发送的数据包。 本发明实施 例提供的通信设备， 能够在没有控制中心节点的时候， 使发送端和接收端 在不经过预先的配置情况下实现数据的正确接收， 从而实现无线资源的高 效利用。 图 4为本发明提供的通信设备实施例四的结构示意图， 该通信设备为 接收端的通信设备。 如图 4所示， 该通信设备包括： 接收模块 40和解压 缩模块 41。 其中， 接收模块 40， 用于接收发送端发送的 MAC PDU; 其中， 该 MAC PDU中携带头压缩算法标识符， 和 /或， 该 MAC PDU中的 PDCP PDU的 SNLI;解压缩模块 41，用于根据所述头压缩算法标识符和 /或 PDCP PDU的 SNLI 对发送端发送的 PDCP SDU进行解压缩。
具体的， 发送端开启直通模式之后， 向接收端发送一个业务数据流， 该 业务数据流包括至少一个数据包。数据包在发送端的 PDCP层时， 发送端会对 该数据包进行头压缩， 该头压缩过程使用的是某一头压缩算法 （profile) ， 该头压缩算法可以通过头压缩算法标识符 （profile ID ) 来指示， 不同的 profile ID对应不同的头压缩算法。 发送端还会对该数据包添加 PDCP层的 包头， 使得该数据包转换为 PDCP PDU; 当 PDCP PDU传输到发送端的 MAC层 时， 发送端同样会对该 PDCP PDU添加包头， 使其成为 MAC PDU。 也就是说， MAC PDU实际上是包括 PDCP PDU的一个协议数据单元。最后，发送端将 MAC PDU 发送给接收端， 并将上述 profile ID和 /或 PDCP PDU的 SNLI携带在 MAC PDU 中。
接收模块 40接收该 MAC PDU, 通过解压缩模块 41获取该 MAC PDU中的 profile ID和 /或 PDCP PDU的 SNLI ; 解压缩模块 41根据该 profi le ID获知 其对应的头压缩算法， 对 PDCP SDU中的 IP层包头进行解压缩， 以获取发送 端发送的数据包， 和 /或， 解压缩模块 41根据 SNLI获知 PDCP PDU包头的长 度， 从而获知 PDCP SDU开始的位置， 进而对该 PDCP SDU中的 IP层包头进行 解压缩以获取发送端发送的数据包。 并且， 在后续的数据包发送和接收过程 中， 发送端和接收端就按照这个头压缩算法和 /或 PDCP PDU包头的长度对该 PDCP SDU中的 IP层包头进行压缩和解压缩， 以使自身能够正确接收到发送 端发送的数据包。
可选的， 当 MAC PDU中仅包括 profile ID时， 接收端可以通过与发送端 交互其他的信令消息（比如用户面配置信息）， 来确定 PDCP PDU的包头长度， 也可以通过二者协商操作来确定 PDCP PDU的包头长度， 即确定 PDCP SDU开 始的位置， 确保对 PDCP SDU中的 IP层包头解压缩的正确性； 解压缩模块 41 根据该 PDCP PDU包头的长度以及 profi le ID对应的头压缩算法对 PDCP PDU 中的 PDCP SDU进行解压缩， 从而可以正确获取到发送端发送的数据包。
可选的， 当 MAC PDU中仅包括 PDCP PDU的 SNLI时， 接收模块 40在接收 到 MAC PDU时， 通过解压缩模块 41读取 PDCP PDU的 SNLI , 获知该 PDCP PDU 包头的长度， 从而获知 PDU SDU开始的位置； 并通过解压缩模块 41读取 PDCP SDU中的数据包的包头， 根据包头中携带的内容确定 profile ID, 获知应该 用哪一种头压缩算法； 最后， 解压缩模块 41根据该头压缩算法和该 PDCP PDU 包头的长度对 PDCP SDU的 IP层包头进行解压缩， 从而可以正确接收到发送 端发送的数据包。
可选的， 当 MAC PDU中同时携带了 profi le ID和 PDCP PDU的 SNLI时， 解压缩模块 41首先通过 PDCP PDU的 SNLI确定 PDCP PDU的包头长度； 然后 根据 profi le ID确定头压缩算法； 最后， 解压缩模块 41根据该头压缩算法 和该 PDCP PDU包头的长度对 PDCP SDU中的 IP层包头进行解压缩， 从而可以 正确接收到发送端发送的数据包。
本发明实施例提供的通信设备， 通过接收模块接收发送端发送的携带 profi le ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 使得解压缩模块根据该 MAC PDU中携带的 profi le ID和 /或 PDCP PDU的 SNLI对 PDCP SDU中的 IP层包 头进行解压缩， 从而使得接收端能够正确接收到发送端发送的数据包。 本 发明实施例提供的通信设备， 能够在没有控制中心节点的时候， 使发送端 和接收端在不经过预先的配置情况下实现数据的正确接收， 从而实现无线 资源的高效利用。
在上述实施例四的基础上， 作为本发明实施例的一种可能的实施方 式， 本实施例涉及的是将接收模块 40接收 MAC PDU, 且该 MAC PDU的 MAC CE中携带头压缩算法标识符和 /或 PDCP PDU的 SNLI的过程。
具体的， 在发送端开启直通模式后， 向接收端发送一个业务数据流， 该 业务数据流包括至少一个数据包。 发送端在该业务数据流的第一个数据包中 添加 MAC CE, 该 MAC CE携带 profi le ID和 /或 PDCP PDU的 SNLI , 该 MAC CE 包括既包括 LGID, 也包括头压缩算法索引 （profi le index) 和 /或 PDCP PDU 的 SNLI , 其中， 该 LGID是用来指示一个业务数据流的编号的， 头压缩算法 索引用来指示 profi le ID, SNLI用于指示 PDCP的 SN的长度， 即 PDCP PDU 的包头的长度。 该 MAC CE的格式可以参见上述表 1所示。 其中， SNLI是用 来指示 PDCP PDU中 SN域的比特位数， SN通常有 7bit、 12bit和 15bit三种。 SNLI的比特位数可以是 lbit或者 2bit。 其中， SNLI的比特位数为 2bit时 (00-11 ) ， 可以指示 4种 SN长度； SNLI的比特位数为 1比特时 （0或 1 ) ， 可以指示 2种 SN长度。 故， 当 D2D通信中使用 2种 SN长度时， 则 SNLI用 lbit指示； 当 D2D通信中使用 3种 SN长度时， 则 SNLI用 2bit进行指示。 可选的， 为了保证 MAC CE的接收可靠性， 这个 MAC CE可以在 MAC层多次 进行传输， 因此， 除了上述在第一个数据包中携带 MAC CE, 还可以为： 发 送端在业务数据开始传输之后的多个连续的数据包中携带 MAC CE (参见 图 1 所示） ， 还可以为针对直通 （D2D ) 的广播模式， 在业务数据传输的 过程中周期性的插入 MAC CE, 即在非连续的数据包中携带 MAC CE (参 见图 2 ) ， 这样可以让在不同时间加入 D2D的广播组的终端都能够知道这 个业务对应的 profile ID和 /或 PDCP PDU的 SNLI。
当接收模块 40接收到该带有 MAC CE的 MAC PDU时， 通过解压缩模块 41将 MAC CE读出， 并形成原语发送给自身的 RRC层； 解压缩模块 41通过 接收端的 RRC层实体给用户面的 PDCP层进行配置， 将该业务数据流对应 的 PDCP实体中的头压缩算法（profi le )配置为 MAC CE中携带的 profi le ID, 和 /或， RRC层实体通过上述 SNLI向用户面的 PDCP层指示 PDCP的 SN 长度（gp PDCP PDU包头的长度），该长度可以是 7bit或者 12bit或者 15bit。 解压缩模块 41通过接收端中的 PDCP实体， 按照这个 profi le ID建立头 压缩算法的上下文， 以便于之后对 PDCP SDU的 IP层包头解压缩， 和 /或， 解压缩模块 41会按照 SNLI所指示的长度来读取 PDCP的 SN的长度， 即获 知 PDCP PDU的包头的长度， 以便于之后对 PDCP SDU的 IP层包头解压缩。
在后续的数据包发送和接收过程中， 发送端和接收端就按照这个 MAC CE中指示的 PDCP层的 profi le ID 对应的头压缩算法进行数据包头压缩 和解压缩和 /或 PDCP PDU的 SNLI , 来对 PDCP SDU中的 IP层包头进行压缩 和解压缩， 以便于能够正确接收到发送端发送的数据包。
本发明实施例提供的通信设备， 通过接收模块接收发送端发送的携带 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 并且该 profile ID和 /或 SNLI携带在 MAC PDU的 MAC CE中， 使得解压缩模块能够根据该 MAC CE中 携带的 profile ID和 /或 SNLI对 PDCP SDU中的 IP层包头进行解压缩， 从 而使得接收端能够正确接收到发送端发送的数据包。本发明实施例提供的 通信设备， 能够在没有控制中心节点的时候， 使发送端和接收端在不经过 预先的配置情况下实现数据的正确接收， 从而实现无线资源的高效利用。
在上述实施例四的基础上， 作为本发明实施例的另一种可能的实施方 式， 本实施例的涉及的是接收器接收 MAC PDU, 且该 MAC PDU中的 PDCP PDU 携带 profi le ID和 /或 PDCP PDU的 SNLI的过程。
具体的， 该携带 profi le ID和 /或 PDCP PDU的 SNLI的 PDCP PDU的格 式可以参见上述表 2和表 3， 以及， 表 2和表 3的具体描述， 在此不再赘 述。
发送端对每个 PDCP SDU在进行 IP相关的头压缩之后 （一个 PDCP的
PDU对应一个 SDU) ， 就将自己使用的 profi le ID和 /或 PDCP PDU的 SNLI 携带在 PDCP PDU中发送给接收端， 并在 PDCP PDU包头中的 D/C比特位填 写 D ， PDU type 则填写表 3中的 010， SNLI则按照具体的 SN的长度来填 写，在一个业务流中， 应该固定采取一种 SN长度。之后， 发送端将该 PDCP PDU在 MAC层添加 MAC CE， 形成 MAC PDU发送给接收端。
接收模块 40在接收到该 MAC PDU之后， 通过解压缩模块 41获取 PDCP PDU, 并读取该 PDCP PDU中的 D/C bit。 当解压缩模块 41检测到该 bit 为 D时， 表明这个数据包携带了 PDCP的 SDU, 于是按照表 2中的每个 bit 的含义来解读接收到的 PDU。 当解压缩模块 41从这个 PDU中读取到了 profi le ID和 /或 SNLI之后， 根据该 profi le ID对应的头压缩算法和 / 或 PDCP PDU的包头长度， 以便能够正确接收到发送端的数据包。
可选的， 当解压缩模块 41读取 D/C bit 为 C时， 则 PDC PPDU的格式 的解读方式参见表 4与表 5所示。 其中， 表 4中的 PDU type 为 100， 表 5 中的 PDU type为 011。
进一步地， 由于一个业务流的数据包通常会持续一段时间， 这样这个 头压缩算法的使用就会持续一段时间， 因此可以在 PDCP PDU 中周期性的 携带 PID, 这样既指示了 R0HC的 profi le ID, 又节省了 PDCP的头部开销。 这样 PDU type就会又增加一种， 增加之后的表格可以参见表 6及其具体 描述， 在此不再赘述。
本发明实施例提供的通信设备， 通过接收模块接收发送端发送的 profile ID和 /或 PDCP PDU的 SNLI的 MAC PDU, 并且该 profile ID和 /或 PDCP PDU的 SNLI携带在 MAC PDU的 PDCP PDU中， 使得解压缩模块能够根据 该 PDCP PDU中携带的 profile ID和 /或 SNLI对 PDCP SDU进行解压缩， 从 而使得接收端能够正确接收到发送端发送的数据包。本发明实施例提供的 通信设备， 能够在没有控制中心节点的时候， 使发送端和接收端在不经过 预先的配置情况下实现数据的正确接收， 从而实现无线资源的高效利用。 本发明实施例一提供了一种配置指示方法。 该方法的执行主体可以为上 述实施例中作为发送端的通信设备。 该方法包括： 发送端向接收端发送 MAC PDU; 其中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU 中的 PDCP PDU的 SNLI。
本发明实施例提供的配置指示方法， 可以参见上述实施例中的发送端的 执行过程， 其实现原理和技术效果类似， 在此不再赘述。
可选的， 所述 MAC PDU的 MAC CE中携带所述头压缩算法标识符和 /或所 述 PDCP PDU的 SNLI o
可选的，所述 PDCP PDU中携带所述头压缩算法标识符和 /或所述 PDCP PDU 的 SNLI。
可选的， 所述 PDCP PDU中携带所述头压缩算法标识符， 包括： 所述 PDCP PDU周期性携带所述头压缩算法标识符。
本发明实施例提供的配置指示方法， 可以参见上述实施例中的发送端的 执行过程， 其实现原理和技术效果类似， 在此不再赘述。
图 5为本发明提供的配置指示方法实施例二的流程示意图。 该方法的执 行主体可以为上述实施例中的作为接收端的通信设备。 如图 5所示， 该方法 包括：
S101 : 接收端接收发送端发送的 MAC PDU; 其中， 所述 MAC PDU中携带 头压缩算法标识符， 和 /或， 所述 MAC PDU中的 PDCP PDU的 SNLI。
S102 : 接收端根据所述头压缩算法标识符和 /或 PDCP PDU的 SNLI对发送 端发送的 PDCP SDU中的 IP层包头进行解压缩。
本发明实施例提供的配置指示方法， 可以参见上述实施例中的接收端的 执行过程， 其实现原理和技术效果类似， 在此不再赘述。
可选的， 所述 MAC PDU的 MAC CE中携带所述头压缩算法标识符和 /或所 述 PDCP PDU的 SNLI o
可选的，所述 PDCP PDU中携带所述头压缩算法标识符和 /或所述 PDCP PDU 的 SNLI o
本发明实施例提供的配置指示方法， 可以参见上述实施例中的接收端的 执行过程， 其实现原理和技术效果类似， 在此不再赘述。 本领域普通技术人员可以理解： 实现上述方法实施例的全部或部分步骤 可以通过程序指令相关的硬件来完成， 前述的程序可以存储于一计算机可读 取存储介质中， 该程序在执行时， 执行包括上述方法实施例的步骤； 而前述 的存储介质包括： R0M、 RAM, 磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是： 以上各实施例仅用以说明本发明的技术方案， 而非对 其限制； 尽管参照前述各实施例对本发明进行了详细的说明， 本领域的普通 技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改， 或者对其中部分或者全部技术特征进行等同替换； 而这些修改或者替换， 并 不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims

权 利 要 求 书
1、 一种通信设备， 其特征在于， 包括：
发送器， 用于向接收端发送媒体接入层协议数据单元 MAC PDU; 其中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分组数据 汇聚协议层协议数据单元 PDCP PDU的序列号长度指示符 SNLI。
2、 根据权利要求 1所述的通信设备， 其特征在于， 所述 MAC PDU的媒体 接入层控制单元 MAC CE中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI o
3、 根据权利要求 1所述的通信设备， 其特征在于， 所述 PDCP PDU中携 带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
4、 根据权利要求 3所述的通信设备， 其特征在于， 所述 PDCP PDU中携 带所述头压缩算法标识符， 包括：
所述 PDCP PDU周期性携带所述头压缩算法标识符。
5、 一种通信设备， 其特征在于， 包括：
接收器， 用于接收发送端发送的媒体接入层协议数据单元 MAC PDU; 其 中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分组 数据汇聚协议层协议数据单元 PDCP PDU的序列号长度指示符 SNLI ;
处理器， 用于根据所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI对 所述发送端发送的分组数据汇聚协议层业务数据单元 PDCP SDU中的网络协议 IP层包头进行解压缩。
6、 根据权利要求 5所述的通信设备， 其特征在于， 所述 MAC PDU的媒体 接入层控制单元 MAC CE中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI o
7、 根据权利要求 5所述的通信设备， 其特征在于， 所述 PDCP PDU中携 带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
8、 一种通信设备， 其特征在于， 包括：
发送模块， 用于向接收端发送媒体接入层协议数据单元 MAC PDU; 其中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分组数据 汇聚协议层协议数据单元 PDCP PDU的序列号长度指示符 SNLI。
9、 根据权利要求 8所述的通信设备， 其特征在于， 所述 MAC PDU的媒体 接入层控制单元 MAC CE中携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI o
10、 根据权利要求 8所述的通信设备， 其特征在于， 所述 PDCP PDU中携 带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
11、 根据权利要求 10所述的通信设备， 其特征在于， 所述 PDCP PDU中 携带所述头压缩算法标识符， 包括：
所述 PDCP PDU周期性携带所述头压缩算法标识符。
12、 一种通信设备， 其特征在于， 包括：
接收模块， 用于接收发送端发送的媒体接入层协议数据单元 MAC PDU; 其中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分 组数据汇聚协议层协议数据单元 PDCP PDU的序列号长度指示符 SNLI ;
解压缩模块，用于根据所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI 对所述发送端发送的分组数据汇聚协议层业务数据单元 PDCP SDU中的网络协 议 IP层包头进行解压缩。
13、 根据权利要求 12所述的通信设备， 其特征在于， 所述 MAC PDU的媒 体接入层控制单元 MAC CE中携带所述头压缩算法标识符和 /或所述 PDCP PDU 的 SNLI o
14、 根据权利要求 12所述的通信设备， 其特征在于， 所述 PDCP PDU中 携带所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
15、 一种配置指示方法， 其特征在于， 包括：
发送端向接收端发送媒体接入层协议数据单元 MAC PDU; 其中， 所述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分组数据汇聚协议 层协议数据单元 PDCP PDU的序列号长度指示符 SNLI。
16、 根据权利要求 15所述的方法， 其特征在于， 所述 MAC PDU的媒体接 入层控制单元 MAC CE 中携带所述头压缩算法标识符和 /或所述 PDCP PDU的
SNLI o
17、 根据权利要求 15所述的方法， 其特征在于， 所述 PDCP PDU中携带 所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
18、 根据权利要求 17所述的方法， 其特征在于， 所述 PDCP PDU中携带 所述头压缩算法标识符， 包括： 所述 PDCP PDU周期性携带所述头压缩算法标识符。
19、 一种配置指示方法， 其特征在于， 包括：
接收端接收发送端发送的媒体接入层协议数据单元 MAC PDU; 其中， 所 述 MAC PDU中携带头压缩算法标识符， 和 /或， 所述 MAC PDU中的分组数据汇 聚协议层协议数据单元 PDCP PDU的序列号长度指示符 SNLI ;
所述接收端根据所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI对所 述发送端发送的分组数据汇聚协议层业务数据单元 PDCP SDU 中的网络协议 IP层包头进行解压缩。
20、 根据权利要求 19所述的方法， 其特征在于， 所述 MAC PDU的媒体接 入层控制单元 MAC CE 中携带所述头压缩算法标识符和 /或所述 PDCP PDU的
SNLI o
21、 根据权利要求 19所述的方法， 其特征在于， 所述 PDCP PDU中携带 所述头压缩算法标识符和 /或所述 PDCP PDU的 SNLI。
PCT/CN2014/073904 2014-03-21 2014-03-21 配置指示方法和通信设备 WO2015139324A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2014/073904 WO2015139324A1 (zh) 2014-03-21 2014-03-21 配置指示方法和通信设备
CN201480001810.7A CN105532059B (zh) 2014-03-21 2014-03-21 配置指示方法和通信设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2014/073904 WO2015139324A1 (zh) 2014-03-21 2014-03-21 配置指示方法和通信设备

Publications (1)

Publication Number Publication Date
WO2015139324A1 true WO2015139324A1 (zh) 2015-09-24

Family

ID=54143736

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/073904 WO2015139324A1 (zh) 2014-03-21 2014-03-21 配置指示方法和通信设备

Country Status (2)

Country Link
CN (1) CN105532059B (zh)
WO (1) WO2015139324A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017206709A1 (en) * 2016-06-03 2017-12-07 Huawei Technologies Co., Ltd. System and Method for Data Forwarding in a Communications System
CN108632229A (zh) * 2017-03-24 2018-10-09 电信科学技术研究院 一种多连接中的头压缩方法、解头压缩方法及装置
WO2021244176A1 (zh) * 2020-06-01 2021-12-09 中国电信股份有限公司 用户面数据处理方法和基站
US11652911B2 (en) * 2014-09-12 2023-05-16 Samsung Electronics Co., Ltd. Handling different protocol data unit types in a device to device communication system

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018166042A1 (zh) * 2017-03-14 2018-09-20 北京小米移动软件有限公司 数据单元传输方法及装置
CN111918335B (zh) * 2019-05-08 2022-07-22 华为技术有限公司 处理数据包的方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101365158A (zh) * 2007-08-10 2009-02-11 华为技术有限公司 头压缩反馈的参数协商、实现方法和系统
WO2010121410A1 (zh) * 2009-04-20 2010-10-28 华为技术有限公司 一种采用arq机制的头压缩通信方法和装置
CN101932128A (zh) * 2009-06-25 2010-12-29 大唐移动通信设备有限公司 一种数据链路层的数据收发处理方法及设备

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101467750B1 (ko) * 2007-06-04 2014-12-03 엘지전자 주식회사 이동 통신 시스템에서 ｍａｃ 헤더 생성방법 및 데이터전송방법
CN102318282B (zh) * 2009-04-20 2014-03-12 华为技术有限公司 一种压缩数据包的传输方法及装置
US9674311B2 (en) * 2009-08-14 2017-06-06 Qualcomm Incorporated Robust header compression for relay nodes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101365158A (zh) * 2007-08-10 2009-02-11 华为技术有限公司 头压缩反馈的参数协商、实现方法和系统
WO2010121410A1 (zh) * 2009-04-20 2010-10-28 华为技术有限公司 一种采用arq机制的头压缩通信方法和装置
CN101932128A (zh) * 2009-06-25 2010-12-29 大唐移动通信设备有限公司 一种数据链路层的数据收发处理方法及设备

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11652911B2 (en) * 2014-09-12 2023-05-16 Samsung Electronics Co., Ltd. Handling different protocol data unit types in a device to device communication system
WO2017206709A1 (en) * 2016-06-03 2017-12-07 Huawei Technologies Co., Ltd. System and Method for Data Forwarding in a Communications System
US9986456B2 (en) 2016-06-03 2018-05-29 Futurewei Technologies, Inc. System and method for data forwarding in a communications system
US10440602B2 (en) 2016-06-03 2019-10-08 Futurewei Technologies, Inc. System and method for data forwarding in a communications system
CN108632229A (zh) * 2017-03-24 2018-10-09 电信科学技术研究院 一种多连接中的头压缩方法、解头压缩方法及装置
CN108632229B (zh) * 2017-03-24 2020-07-07 电信科学技术研究院 一种多连接中的头压缩方法、解头压缩方法及装置
WO2021244176A1 (zh) * 2020-06-01 2021-12-09 中国电信股份有限公司 用户面数据处理方法和基站

Also Published As

Publication number Publication date
CN105532059B (zh) 2019-06-18
CN105532059A (zh) 2016-04-27

Similar Documents

Publication Publication Date Title
JP7218363B2 (ja) ５ｇシステムにおけるユーザ機器とセッション管理機能との間のｑｏｓ能力ネゴシエーションの方法
CN113055146B (zh) 一种基于反转服务流特性的通信方法及装置
WO2018228126A1 (zh) 一种基于dc的切换方法及设备
WO2014110773A1 (zh) 一种数据包处理方法和装置
WO2015139324A1 (zh) 配置指示方法和通信设备
JP2008507226A (ja) ブロック肯定応答を用いてデータスループットを向上させるためのシステム及び方法
JP2010539784A (ja) ヘッダインジケータを利用した効率的なデータブロック送信方法
CN113133055B (zh) 无线通信的方法和设备
WO2016141793A1 (zh) 一种空口协议栈的配置方法、数据传输方法及设备
WO2014110797A1 (zh) 设备到设备间通信的逻辑信道处理方法、用户设备以及基站
WO2011079785A1 (zh) 一种传输数据包的方法及装置
TWI772688B (zh) 無線電資源控制訊息分段
WO2016112499A1 (zh) 资源指示的方法、接入点和终端
EP3955637A1 (en) Data processing method, communication apparatus, and system
EP3860209B1 (en) Data transmission method and device
KR102179212B1 (ko) 제어 정보에 대한 송신 방법 및 장치
WO2017185368A1 (zh) 一种信令传输方法和设备
WO2018202204A1 (zh) 一种基于反转服务流特性的通信方法及装置
WO2023185450A1 (zh) 数据包处理方法及装置
CN113678501B (zh) 一种以太网数据包头压缩方法、处理方法及其装置
WO2023015420A1 (zh) 数据传输方法及装置
WO2023207555A1 (zh) 一种通信方法及装置
WO2023184552A1 (zh) 一种数据传输方法及装置、通信设备
CN109219079B (zh) 一种ir报文传输方法及通信设备
WO2017147754A1 (zh) 数据包的压缩方法和装置

Legal Events

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

Ref document number: 201480001810.7

Country of ref document: CN

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

Ref document number: 14886175

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: 14886175

Country of ref document: EP

Kind code of ref document: A1