WO2015006896A1 - 数据处理装置和方法 - Google Patents

数据处理装置和方法 Download PDF

Info

Publication number
WO2015006896A1
WO2015006896A1 PCT/CN2013/079357 CN2013079357W WO2015006896A1 WO 2015006896 A1 WO2015006896 A1 WO 2015006896A1 CN 2013079357 W CN2013079357 W CN 2013079357W WO 2015006896 A1 WO2015006896 A1 WO 2015006896A1
Authority
WO
WIPO (PCT)
Prior art keywords
rlc
mac
pdu
pdcp
lcid
Prior art date
Application number
PCT/CN2013/079357
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/CN2013/079357 priority Critical patent/WO2015006896A1/zh
Priority to CN201380002316.8A priority patent/CN103782569B/zh
Publication of WO2015006896A1 publication Critical patent/WO2015006896A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02Data link layer protocols

Definitions

  • Embodiments of the present invention relate to the field of mobile communications technologies, and in particular, to a data processing apparatus and method. Background technique
  • the Layer 2 (L2) protocol stack defined in the 3rd Generation Partnership Project (3GPP) protocol includes a packet data convergence protocol (PDCP radio link control (RLC)).
  • PDCP radio link control (RLC) Protocol and medium access control (MAC) protocol have three logical levels.
  • the PDCP layer and the RLC layer all use radio bearers (RBs) as the minimum working object, and the MAC layer has one or more RBs.
  • RBs radio bearers
  • the current L2 protocol lacks flexibility. In the process of processing data, if the minimum working object RB needs to be further logically split, the current L2 protocol encounters difficulties.
  • embodiments of the present invention provide a data processing apparatus and method to improve flexibility of the L2 protocol when processing data.
  • a first aspect provides a data processing apparatus, including a packet convergence protocol PDCP unit, a radio link control RLC unit, and a medium access control MAC unit, where the RLC unit includes: a plurality of mutually independent RLC sub-units corresponding to the same logical channel, wherein: when the apparatus is located at the transmitting end, each RLC sub-unit is configured to transmit the PDCP unit to a PDCP protocol data unit PDU of the RLC sub-unit Converting to an RLC PDU, transmitting to the MAC unit, and the PDCP PDU transmitted by the PDCP unit to the plurality of RLC sub-units corresponds to the same radio bearer RB; or each of the devices when the device is located at the receiving end
  • the RLC subunit is configured to convert the MAC service data unit SDU transmitted by the MAC unit to the RLC subunit into an RLC SDU, and transmit the same to the PDCP unit.
  • the configuration parameters of the plurality of RLC subunits are independent of each other.
  • the MAC unit when the device is located at a transmitting end, the MAC unit is configured to:
  • the RLC PDUs transmitted by the RLC sub-units are configured with corresponding MAC sub-headers, and each MAC sub-header includes a virtual logical channel identifier V-LCID, which is used to identify the RLC sub-segment from which the RLC PDU associated with the MAC sub-header is derived. unit.
  • the MAC unit is used when the device is located at a receiving end Receiving a MAC PDU sent by the peer device, where the MAC PDU includes a MAC header and a MAC payload, the MAC payload includes at least one peer RLC PDU, and the MAC header includes at least one MAC subheader corresponding to the at least one a peer RLC PDU, where The peer RLC PDU includes a first peer RLC PDU, and the MAC subhead corresponding to the first peer RLC PDU includes a V-LCID, where the V-LCID is used to identify one of the multiple RLC subunits; Transmitting the received MAC PDU into the at least one peer RLC PDU; transmitting the first peer RLC PDU to the RLC subunit identified by the V-LCID.
  • the V-LCID is formed by a reserved bit of the MAC subheader; or It is formed by the reserved LCID.
  • the device when the device is located at the sending end, the device further includes And a distribution unit, configured to distribute the PDCP PDUs corresponding to the same RB from the PDCP unit to the plurality of RLC sub-units.
  • the sending unit is specifically configured to: each PDCP PDU according to a service type corresponding to each PDCP PDU Distributing to the RLC sub-units of the plurality of RLC sub-units adapted to the service type data transmission; or distributing, in a polling manner, the PDCP PDUs corresponding to the same RB from the PDCP unit to the plurality of RLC subunit.
  • a data transmission method is provided, which is applied to a radio link control RLC layer in a transmitting device, where the RLC layer includes a plurality of independent RLC sub-units, and the plurality of RLC sub-units correspond to the same Logical channel, the method comprising: receiving, by each RLC subunit a PDCP layer transmitted by the PDCP layer of the RLC sub-unit to the PDCP protocol data unit PDU of the RLC sub-unit, where the PDCP layer transmitted by the PDCP layer to the multiple RLC sub-units corresponds to the same radio bearer RB;
  • the RLC sub-unit converts the received PDCP PDU into an RLC PDU and transmits it to the medium access control MAC layer in the sender device.
  • the configuration parameters of the plurality of RLC subunits are independent of each other.
  • the method further includes: the RLC that the MAC layer transmits for each RLC subunit
  • the PDU configures a corresponding MAC sub-header
  • each MAC sub-header includes a virtual logical channel identifier V-LCID, which is used to identify an RLC sub-unit from which the RLC PDU associated with the MAC sub-header is derived.
  • the V-LCID is formed by a reserved bit of the MAC sub-header; or Formed by LCID.
  • each RLC subunit receives the Before the PDCP layer is transmitted to the PDCP PDU of the RLC sub-unit, the method further includes: the PDCP layer generates the PDCP PDU corresponding to the same RB; and distributes the PDCP PDU corresponding to the same RB to the multiple RLC sub-units .
  • the distributing the PDCP PDU corresponding to the same RB to the multiple RLC sub-units includes: pressing a service type corresponding to each PDCP PDU, each PDCP PDU is distributed to an RLC sub-unit of the plurality of RLC sub-units adapted to the service type data transmission; or, the polling is performed to correspond to the same RB The PDCP PDU is distributed to the plurality of RLC subunits.
  • a third aspect provides a data transmission method, which is applied to a radio link control RLC layer in a receiving end device, where the RLC layer includes a plurality of independent RLC sub-units, and the plurality of RLC sub-units correspond to the same a logical channel, comprising: each RLC subunit receiving a MAC SDU transmitted by the medium access control MAC layer in the receiving end device to the RLC subunit; each RLC subunit converting the received MAC SDU into an RLC SDU, Transmitted to the packet aggregation protocol PDCP layer in the receiving device.
  • the configuration parameters of the plurality of RLC subunits are independent of each other.
  • each RLC subunit receives the MAC layer in the receiving end device and transmits the information to the RLC. Before the MAC SDU of the subunit, it also includes:
  • the MAC layer in the receiving end device receives a MAC PDU sent by the peer device, where the MAC PDU includes a MAC header and a MAC load, and the MAC load includes at least one peer end.
  • the RLC PDU, the MAC header includes at least one MAC sub-header corresponding to the at least one peer RLC PDU, where the peer RLC PDU includes a first peer RLC PDU, the first peer RLC PDU
  • Corresponding MAC subheader includes a virtual logical channel identifier V-LCID, where the V-LCID is used to identify one of the multiple RLC subunits; and the MAC layer converts the received MAC PDU into the at least one peer RLC PDU; the MAC layer transmits the first peer RLC PDU to the RLC subunit identified by the V-LCID.
  • the V-LCID is formed by a reserved bit of the MAC sub-header; or Formed by LCID.
  • a fourth aspect a computer program product comprising a computer readable medium, the computer readable medium comprising a set of program code for performing the method of any of the second aspect or the second aspect.
  • a computer program product comprising a computer readable medium, the computer readable medium comprising a set of program code for performing the method of any of the third aspect or the third aspect.
  • 1 is a protocol block diagram of a conventional communication system
  • FIG. 2 is a schematic diagram of a data flow in the protocol architecture shown in FIG. 1;
  • FIG. 3 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present invention
  • FIG. 4 is a schematic structural diagram of a conventional MAC PDU
  • FIG. 5 is a schematic diagram of a V-LCID according to an embodiment of the present invention.
  • FIG. 6 is a schematic diagram of another V-LCID according to an embodiment of the present invention.
  • FIG. 7 is a schematic structural diagram of a MAC PDU according to an embodiment of the present invention
  • FIG. 8 is a schematic structural diagram of another MAC PDU according to an embodiment of the present invention
  • FIG. 9 is another data processing apparatus according to an embodiment of the present invention
  • FIG. 10 is a flowchart of a data processing method according to an embodiment of the present invention
  • FIG. 11 is a flowchart of still another data processing method according to an embodiment of the present invention
  • FIG. 12 is a flowchart of still another data processing method according to an embodiment of the present invention
  • FIG. 14 is a flowchart of still another data processing method according to an embodiment of the present invention
  • FIG. 15 is a schematic structural diagram of a communication system according to an embodiment of the present invention
  • FIG. 16 is a schematic structural diagram of another communication system according to an embodiment of the present invention
  • FIG. 17 is a schematic structural diagram of a base station according to an embodiment of the present invention
  • FIG. 18 is a schematic structural diagram of a terminal according to an embodiment of the present invention. detailed description
  • FIG. 1 is a protocol block diagram of an existing communication system.
  • the Layer 2 (L2) protocol stack defined in the 3GPP protocol includes a packet data convergence protocol (PDCP), a radio link control (RLC) protocol, and a medium access control (medium access).
  • Control, MAC three logical levels of protocol.
  • Layer 1 (LI) mainly refers to the physical (PHY) layer. The functions of each logical level are briefly described below, which are well known to those skilled in the art, and are not described here. .
  • the PDCP layer is mainly used for header compression of service packets (for example, Internet Protocol (IP) packets) of the application (APP) layer to reduce the overhead caused by the packet header;
  • IP Internet Protocol
  • APP application
  • the PDCP layer can also be used for control plane encryption, integrity protection of transmitted data, and in-sequence or replica deletion for handover;
  • the PDCP layer is used to perform operations such as decryption and decompression.
  • the RLC layer is mainly used for data splitting and/or cascading. In addition, it can also be used for automatic repeat request (ARQ) related operations, such as retransmission detection, or sequence transmission to higher layers.
  • ARQ automatic repeat request
  • the RLC layer is mainly used for data recombination, ARQ related operations, and the like.
  • the MAC layer is mainly used to control multiplexing of logical channels, hybrid automatic repeat request (HQQ) retransmission, uplink and downlink scheduling, etc.; correspondingly, at the receiving end
  • the MAC layer is mainly used for demultiplexing, HARQ retransmission, and the like.
  • the PHY layer is mainly used for operations such as encoding/decoding, modulation/demodulation, antenna/resource mapping/de-mapping.
  • FIG. 2 is a schematic diagram of a data flow in the protocol architecture shown in FIG. 1 .
  • the PDCP layer performs encryption after performing header compression, and adds a PDCP header to carry information required for terminal decryption.
  • the RLC layer performs cascading and/or splitting of PDCP service data units (SDUs), and adds an RLC header for sequential transmission of the terminal and RLC protocol data unit (PDU) in case of retransmission. Identification.
  • SDUs PDCP service data units
  • PDU RLC protocol data unit
  • the RLC PDU is forwarded to the MAC layer, multiplexes one or more RLC PDUs, and adds a MAC header to form a MAC PDU, or transport block (TB)b
  • TB transport block
  • the RLC layer provides services to the PDCP in the form of a radio bearer (RB).
  • RB radio bearer
  • the PDCP layer and the RLC layer all use RB as the minimum working object, and the MAC uses one or more RBs as the minimum working object.
  • the current L2 protocol lacks flexibility. In the process of processing data, if the minimum working object RB needs to be further logically split, the current L2 protocol encounters difficulties.
  • the following embodiment adjusts the RLC layer, configures multiple RLC entities for one logical channel, and performs multiple independent RLC processing on the data on the same RB, which is equivalent to splitting one RB into multiple Virtual RB makes the L2 protocol more flexible in processing data.
  • the following is described in detail in conjunction with FIG. 3.
  • FIG. 3 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present invention.
  • the data processing apparatus 300 may be located at the transmitting end for performing L2 protocol processing on downlink data or uplink data to be sent, or may be located at the receiving end for performing L2 protocol processing on the received uplink data or downlink data; for example, the data
  • the processing device 300 can be located in an access network element (e.g., a base station) or in a terminal.
  • the data processing apparatus 300 includes a PDCP unit 310, an RLC unit 320, and a MAC unit 330.
  • the RLC unit 320 includes a plurality of RLC sub-units 321 to 32n, where ⁇ is a positive integer greater than or equal to 2. These RLC sub-units correspond to the same logical channel and they are independent of one another, for example configuration parameters are independent of one another.
  • the RLC sub-units 321 to 32n are used to share the PDCP PDUs corresponding to the same RB from the PDCP unit 310, and respectively The respective shared PDCP PDUs are converted into RLC PDUs for transmission to the MAC unit 330. That is, each RLC sub-unit is used to convert the PDCP PDU transmitted to the PDCP unit 310 to its own into an RLC PDU, and is transmitted to the MAC unit 330, and the PDCP PDU transmitted by the PDCP unit 310 to the RLC sub-units 321 to 32n corresponds to the same RB.
  • the RLC sub-units 321 to 32n are respectively used to convert the SDUs from the MAC unit 330 into RLC SDUs to the PDCP unit 310. That is, each RLC subunit is used to convert the MAC SDU transmitted to the MAC unit 330 to its own into an RLC SDU, which is transmitted to the PDCP unit 310.
  • the above transmitting end and receiving end may be a base station or a terminal.
  • the transmitting end can also serve as the receiving end.
  • the receiving end can also serve as the transmitting end. Therefore, the RLC sub-units 321 to 32n can be used to share the PDCP PDUs corresponding to the same RB from the PDCP unit 310, and The respective shared PDCP PDUs are separately converted into RLC PDUs and transmitted to the MAC unit 330.
  • the SDUs from the MAC unit 330 can also be converted into RLC SDUs and aggregated to the PDCP unit 310.
  • the configuration parameters of the foregoing RLC sub-units refer to the parameters of the RLC sub-unit that complete the RLC layer function, and may be configured, for example, parameters such as a transmission mode and a transmission window.
  • Those skilled in the art are familiar with the composition of the configuration parameters of the RLC entity, and are not described here again, and the introduction of the configuration parameters of each RLC sub-unit (virtual RLC entity) in the above embodiments is mainly to emphasize that their configuration parameters are independent of each other. , further indicating that these RLC subunits are each other A separate RLC entity without any restrictions on the configuration parameters themselves. That is to say, the configuration parameters of the above multiple RLC sub-units are independent of each other, indicating that these RLC sub-units are independent RLC entities, having the same functions as the existing RLC entities.
  • V-RLC virtual RLC entities
  • V-RLC virtual RLC entities
  • the PDCP PDUs corresponding to the same RB can be distributed to multiple V-RLC entities for independent RLC processing, so that the processing of the RBs is further logically split, so that the processing of the data by L2 is more flexible.
  • each logical layer for example, PDCP protocol processing, RLC protocol processing, and MAC protocol processing, with the definition of these protocol layers by 3GPP, and the processing of each logical layer can be jointly evolved with the standard protocol, the present invention
  • the improvement is not limited thereto, and the specific operation thereof does not constitute a limitation of the present invention.
  • a unit, a subunit, an entity, or a virtual entity in various embodiments of the present invention refers to a functional entity or a logical entity. It can be in the form of software, and the program code is executed by the processor to implement its function; or it can be in the form of hardware, and the invention does not impose any limitation.
  • the transmitting LC entity converts the PDCP PDU into an RLC PDU and sends it to the MAC entity
  • the MAC entity multiplexes one or more RLC PDUs, adds a MAC header to form a TB, and maps the transport block to the transport channel through the PHY.
  • the processing of the layer is sent to the receiving end.
  • the MAC entity performs demultiplexing according to the MAC header to obtain one or more MAC SDUs (ie, one or more RLC PDUs multiplexed by the transmitting end), and according to the information of each sub-header in the MAC header, Each MAC SDU is transmitted to a corresponding RLC entity for processing.
  • MAC SDUs ie, one or more RLC PDUs multiplexed by the transmitting end
  • FIG. 4 is a schematic structural diagram of an existing MAC PDU (ie, TB ).
  • the MAC PDU usually includes a MAC header, 0 or more MAC SDUs, 0 or more MAC control elements, and optionally, a padding b.
  • MAC SDU ie, multiplexed RLC PDU
  • a normal MAC PDU subheader consists of six ii (R/R/E/LCID/F/L), which can have L-fields of 7-bit and 15-bit; for the last sub-header, fixed-length MAC control
  • R is a reserved bit (referred to as reserved bit) and is set to “0
  • multiple logical channels (where each logical channel has its own RLC entity) can be To be multiplexed into a transport channel by the MAC layer.
  • the MAC layer processes the corresponding demultiplexing and forwards the RLC PDUs to their respective RLC entities.
  • the LCID is used to identify the logical channel. Since one logical channel corresponds to one RLC entity, it can be understood that the LCID can identify the RLC entity corresponding to the logical channel.
  • multiple logical V-RLC entities can be configured for one logical channel.
  • the MAC sub-header needs to be reconfigured so that the MAC entity can transmit the demultiplexed MAC SDU to the correct V-RLC entity.
  • a corresponding virtual LCID V-LCID
  • V-LCID virtual LCID
  • the subsequent MAC SDU is delivered to the correct V-RLC entity.
  • V-LCID The design of the V-LCID is described below. It should be noted that the following design of the V-LCID is for example only, and the scope of protection of the present invention is not limited to the following limited number of design examples, and those skilled in the art can accordingly obtain the design of the same principle and function. The solutions are all within the scope of the present invention.
  • V-LCID When designing V-LCID, considering the compatibility of the protocol, V-LCID can be designed to meet the following principles:
  • the receiving end can parse the V-LCID from the MAC PDU, and no other objects that carry V-LCID information are needed.
  • V-LCID Capacity principle: The value range of V-LCID must meet the requirements of the scenario.
  • the binding of multiple V-LCIDs of the V-RLC entity corresponding to the same logical channel to the LCID corresponding to the logical channel can be implemented in the MAC subheader or through a constraint relationship, which will be described in detail in the following examples.
  • Solution 1 Please refer to Figure 4 and Figure 5, using the two reserved bits "R" in the MAC header of the MAC PDU as compatible with the protocol. V-LCID.
  • Option 2 Please refer to Table 1, which is a table of existing LCID values.
  • N is a natural number. As shown in Fig. 6, it gives an example where N is 10 or 8.
  • V-LCID is 1, that is, there is a V-LCID corresponding to one LCID.
  • the V-RLC entity can be bound to the LCID.
  • the cost is that N NLCs that are currently reserved are required.
  • V-RLC entity is generally created only for a data radio bearer (DRB), and the 3GPP protocol specifies that the number of DRBs of a terminal is at most 8, "01011 - 10010" is enabled as a fixed DR of 8 DRBs.
  • both scenario 1 and scenario 2 can be applied simultaneously, and the capacity of the V-LCID is 5.
  • the MAC entity can resolve the MAC PDU to the MAC SDU according to the V-LCID, and then find the correct V-RLC entity, so as to complete the RLC PDU to the RLC SDU, and then multiple The SDU of the virtual RLC entity is transmitted to the correct PDCP entity to complete the PDCP protocol processing.
  • the above design of the V-LCID takes into consideration the compatibility with the existing protocol, and the V-LCID compatible with the prior art is obtained.
  • the present invention is not limited thereto, and may also be used for each V. -
  • the RLC redesigns the format of the MAC sub-header as long as the MAC entity transmits the associated MAC SDU to the corresponding RLC entity according to the information of the MAC sub-header.
  • the MAC layer at the transmitting end adds the function of filling the V-LCID into the MAC PDU.
  • the virtual package (vPack) function the MAC layer at the receiving end adds the function of submitting the MAC SDU to the correct V-RLC entity according to the V-LCID, referred to as the virtual delivery (vDeliver) function.
  • the MAC unit 330 is specifically configured to multiplex the RLC PDUs transmitted by the multiple logical channels into at least one MAC PDU.
  • the RLC PDUs corresponding to the logical channels of the RLC sub-units 321-32n may be all multiplexed into one MAC PDU, or may be partially multiplexed to generate multiple MAC PDUs, and the generated MAC PDU may further include other logics.
  • RLC PDU of the channel; IP does not limit which PDUs of the RLC sub-unit are in the multiplexing process of the MAC unit 330
  • each MAC PDU is specifically the same structure as shown in Figure 4, including the MAC header and MAC payload.
  • the V-LCID is constructed by using two reserved bits R" in the MAC header
  • each subheader in the MAC header includes a V-LCID (ie, two reserved bits "R"), E, LCID
  • the MAC PDU (or TB) includes a MAC header and a MAC payload
  • the MAC header includes at least one MAC subheader
  • the MAC payload includes at least one RLC PDU.
  • each MAC subheader corresponds to one RLC PDU.
  • the MAC can multiplex RLC PDUs of different V-RLC entities of the same logical channel, or RLC PDUs of different logical channels are multiplexed; and RLC PDUs of different V-RLC entities of the same logical channel may be multiplexed in one MAC PDU or may be multiplexed in different MAC PDUs. Therefore, the RLC PDUs included in the MAC payload in the MAC PDU may all come from the V-RLC entity, or may be partially from the V-RLC entity. Of course, the RLC PDU from the V-RLC entity may not be included, for example, from the present.
  • RLC PDUs of the RLC entity There are RLC PDUs of the RLC entity (ie, whose corresponding logical channel is only provided with one RLC entity).
  • the subheader associated with the RLC PDU from the existing RLC entity is the same as the prior art and will not be discussed here.
  • the MAC bearer includes the RLC PDU from the V-RLC entity
  • the "RR" field is replaced by the "V-LCID” field, that is, with the V-RLC.
  • the MAC sub-header corresponding to the RLC PDU sent by the entity includes a V-LCID.
  • the "LCID” field is replaced by the "V-LCID” field bound to it, and V-RLC.
  • the MAC sub-header corresponding to the RLC PDU sent by the entity includes a V-LCID.
  • the MAC unit 330 when the foregoing apparatus 300 is located at the transmitting end, the MAC unit 330 may be configured to: configure a corresponding MAC sub-header for each RLC PDU transmitted by each RLC sub-unit, and configure each MAC The subheader includes a V-LCID, which is used to identify the RLC subunit from which the RLC PDU to which the MAC subheader is associated.
  • the MAC unit 330 when the device 300 is located at the receiving end, the MAC unit 330 may be configured to receive a MAC PDU sent by the peer device, where the MAC PDU has the structure shown in FIG. 3, including a MAC header and a MAC payload.
  • the MAC payload includes at least one peer RLC PDU
  • the MAC header includes at least one MAC subheader corresponding to at least one peer RLC PDU, respectively.
  • the MAC header includes at least one MAC subheader different from the prior art, that is, a MAC subheader including a V-LCID (for example, a MAC subheader as shown in FIG. 7 or FIG. 8).
  • the V-LCID is used to identify one of the plurality of RLC sub-units 321-32n.
  • the peer RLC PDU corresponding to the MAC sub-header including the V-LCID is referred to as the first peer RLC PDU.
  • the MAC unit 330 is further configured to convert the received MAC PDU into at least one peer RLC PDU; transmit the first peer RLC PDU to a corresponding RLC subunit, where the corresponding RLC subunit refers to the first peer RLC PDU The RLC subunit identified by the V-LCID in the corresponding MAC subheader.
  • the V-LCID in this embodiment may be formed by the reserved bits of the MAC subheader; or may be formed by the reserved LCID.
  • the V-LCID in this embodiment may be formed by the reserved bits of the MAC subheader; or may be formed by the reserved LCID.
  • FIG. 7 and FIG. 8 omits fields such as F and L with respect to FIG. 4, and various types of sub-heads are not embodied, but this is only for highlighting the improvement point of the embodiment. It is omitted and is not intended to limit the invention.
  • the MAC layer can receive the air interface. After the MAC PDU is parsed into a MAC SDU, the corresponding V-RLC entity can be found, and other methods can be used for processing. For example, processing with other flag bits has a relatively large impact on the protocol relative to the above V-LCID.
  • the apparatus may further include a distributing unit 340, configured to distribute PDCP PDUs corresponding to the same RB from the PDCP unit 310.
  • the RLC subunits 321-32n are given. That is, the PDCP unit 310 transmits the PDCP PDU to each RLC sub-unit through the distribution unit 340.
  • the function of the distribution unit 340 can be embedded in the PDCP unit 310, that is, the PDCP PDU generated by the PDCP unit 310 is directly distributed.
  • the distribution unit 340 can also exist independently, and can be located at the PDCP layer or at the PDCP layer.
  • the generated PDCP PDU is transmitted by the PDCP unit 310 to the distribution unit 340 and then distributed by the distribution unit 340.
  • RLC subunit 321-32n the function of the distribution unit 340 can be embedded in the PDCP unit 310, that is, the PDCP PDU generated by the PDCP unit 310 is directly distributed.
  • the distribution unit 340 can also exist independently, and can be located at the PDCP layer or at the PDCP layer.
  • the generated PDCP PDU is transmitted by the PDCP unit 310 to the distribution unit 340 and then distributed by the distribution unit 340.
  • RLC subunit 321-32n the function of the distribution unit 340 can be embedded in the PDCP unit 310,
  • the distribution unit 340 can be distributed in various manners, for example, can be simply polled and distributed among multiple RLC sub-units, and can also introduce complex sub-functions that improve robustness, such as in combination with a negotiation process. If the performance of a certain RLC sub-unit is not good, the RLC sub-unit is deleted or modified; for example, the PDCP PDUs of different service types may be distributed to different RLC sub-units according to the service type corresponding to the PDCP PDU, that is, each The service type corresponding to the PDCP PDU, and each PDCP PDU is distributed to the RLC sub-units of the plurality of RLC sub-units 321-32n adapted to the service type data transmission.
  • an embodiment of the present invention further provides a data processing method.
  • This method is used by the sender to perform L2 processing on the data.
  • the sending end may be an access network element (for example, a base station), or may be a terminal.
  • the method is applied to an RLC layer in a transmitting device, where the RLC layer has the structure provided by the foregoing device embodiment, and includes multiple RLC sub-units that are independent of each other, and the RLC sub-units correspond to the same logical channel.
  • the method includes at least the following steps:
  • Each RLC sub-unit receives a PDCP PDU that is sent by the PDCP layer to the RLC sub-unit, and the PDCP PDU that the PDCP layer transmits to the multiple RLC sub-units corresponds to the same RB;
  • Each RLC sub-unit converts the received PDCP PDU into an RLC PDU, and transmits the signal to the MAC layer in the sending end device.
  • the MAC layer may further perform multiplexing processing on the RLC PDUs transmitted by the RLC layer, and configure a managed sub-header for each RLC PDU in the multiplexing process, including configuring a sub-header for the RLC PDU transmitted by each RLC sub-unit.
  • each RLC subunit may transmit one or more RLC PDUs.
  • FIG. 11 is a flowchart of another data processing method according to an embodiment of the present invention. The method includes the following steps in addition to steps S101 and S102 shown in FIG. 10 :
  • the MAC layer configures a corresponding MAC sub-header for each RLC PDU transmitted by the RLC sub-unit, and each MAC sub-head includes a V-LCID, where the V-LCID is used to identify that the RLC PDU associated with the MAC sub-header is from RLC subunit.
  • FIG. 12 is a flowchart of still another data processing method according to an embodiment of the present invention. The method is the same as the method shown in FIG. 10 and FIG. 11 for performing L2 processing on the data at the transmitting end.
  • the sending end may be an access network element (for example, a base station) or a terminal. As shown in FIG. 12, the method includes the following steps:
  • the PDCP layer generates multiple PDCP PDUs, where the multiple PDCP PDUs correspond to the same RB;
  • 5122 distribute the multiple PDCP PDUs to multiple RLC sub-units of the RLC layer, the multiple RLC sub-units being independent of each other and corresponding to the same logical channel;
  • the multiple RLC sub-units independently convert the respective allocated PDCP PDUs into RLC PDUs and transmit them to the MAC layer.
  • the PDCP layer generates a PDCP PDU, wherein the generated PDCP PDU includes a plurality of PDCP PDUs corresponding to the same radio bearer; for example, two PDCP PDUs corresponding to the RBI shown in FIG. 2 (hereinafter referred to as a first PDCP PDU) And the second PDCP PDU)b
  • the RLC layer includes a plurality of RLC sub-units corresponding to the same logical channel and independent of each other, and the step further includes Distributing the plurality of PDCP PDUs corresponding to the same RB to the plurality of RLC sub-units; for example, the first PDCP PDU and the corresponding one corresponding to RB1
  • the second PDCP PDU is distributed to the first RLC subunit and the second RLC subunit of the plurality of RLC subunits.
  • the RLC layer receives the transmitted PDCP PDU and converts the received PDCP PDU into an RLC PDU and transmits the same to the MAC layer.
  • the method further includes: the multiple RLC sub-units independently converting the respective PDCP PDUs into RLC PDUs and transmitting them to the RLC PDUs.
  • a MAC layer for example, the first RLC sub-unit and the second RLC sub-unit independently perform RLC protocol processing (eg, concatenation and/or splitting) on the first PDCP PDU and the second PDCP PDU, each obtaining at least one RLC PDU transmission Give the MAC layer.
  • the number of the above RLC subunits and the number of PDCP PDUs corresponding to the same RB are all expressed by multiple, they may be the same or different. Specifically, it can be configured according to actual needs.
  • the number of RLC subunits is configured according to the type of service in the same RB.
  • the PDCP PDUs in the same RB may be divided into groups requiring UM transmission according to the requirements of the different types of services for the transmission mode, and groups for performing AM transmission are required.
  • the PDCP PDU of each group is assigned to the RLC subunit corresponding to the transmission mode.
  • a group of data is relatively large, a plurality of RLC sub-units may be established corresponding to the group, and no limitation is imposed herein, and those skilled in the art may set as needed.
  • the distribution manners in the foregoing S102 may be multiple, for example, the polling may be simply performed between multiple RLC sub-units, and a complex sub-function that enhances robustness may also be introduced, such as a negotiation process. Combine, delete or modify the RLC when the performance of an RLC subunit is not good.
  • the multiple PDCP PDUs may be distributed to multiple RLC sub-units of the RLC layer according to the service type corresponding to the multiple PDCP PDUs.
  • PDCP PDUs of the same service type may be distributed to one RLC sub-unit, or PDCP PDUs of different service types but with the same transmission mode requirement may be distributed to one RLC sub-unit.
  • the present invention does not impose any limitation on the form of distribution.
  • the embodiment may further include the step S111 shown in FIG. 11, that is, the process in which the MAC layer configures a MAC subheader for each RLC PDU.
  • an embodiment of the present invention provides another data processing method.
  • the method is used for L2 processing of data at the receiving end.
  • the receiving end may be a terminal, or may be an access network element (for example, a base station), and the method is applied to an RLC layer in the receiving end device, where the RLC layer has the structure provided by the foregoing device embodiment, including multiple RLC sub-units that are independent of each other, and the plurality of RLC sub-units correspond to the same logical channel.
  • the method includes the following steps:
  • each RLC subunit receives a MAC SDU that is sent by the MAC layer in the receiving end device to the RLC subunit;
  • Each RLC sub-unit converts the received MAC SDU into an RLC SDU, and sends the signal to the PDCP layer in the receiving device.
  • Each RLC subunit receives a MAC SDU, which is obtained by the MAC layer demultiplexing and sent to the RLC subunit.
  • FIG. 14 which is still another embodiment of the present invention. Flow chart of the data processing method. As shown in FIG. 14, before step S131 shown in FIG. 13, the following steps are further included:
  • the MAC layer receives a MAC PDU sent by the peer device, where the MAC PDU includes a MAC header and a MAC payload, the MAC payload includes at least one peer RLC PDU, and the MAC header includes at least one MAC sub-head, respectively corresponding to the at least one pair.
  • the RLC PDU, where the peer RLC PDU includes a first peer RLC PDU, and the MAC subhead corresponding to the first peer RLC PDU includes a V-LCID, where the V-LCID is used to identify the multiple RLC subunits.
  • the MAC layer converts the received MAC PDU into at least one peer RLC PDU therein;
  • the MAC layer transmits the first peer RLC PDU to the RLC subunit identified by the V-LCID.
  • V-LCID in the above various method embodiments is the same as that in the above device embodiment, and details are not described herein again.
  • multiple RLC sub-units may perform independent RLC processing, so that the processing of the RB is further logically split, so that L2 handles data more flexibly.
  • FIG. 15 is a schematic structural diagram of a communication system according to an embodiment of the present invention.
  • a base station is used as a transmitting end, and its PDCP layer is connected.
  • the service packet of the APP layer is received, and the PDCP protocol such as packet header compression is performed on the service packet to generate a PDCP PDU. Since each service packet has its corresponding RB, the generated PDCP PDU has its corresponding RB, and there may be multiple PDCP PDUs corresponding to the same RB.
  • the RLC receives the PDCP PDU and caches it.
  • the PDCP SDU is cascaded and/or split, and a protocol such as an RLC header is added to generate an RLC PDU.
  • the PDCP PDUs corresponding to the same RB are transmitted to one RLC entity corresponding to the same logical channel for processing.
  • multiple V-RLC entities are configured for one logical channel, and the multiple V-RLC entities can be shared.
  • PDCP PDUs corresponding to the same RB, and each V-RLC entity performs RLC protocol processing on the respective shared PDCP PDUs, generates at least one RLC PDU to be transmitted to the MAC layer, and the MAC layer multiplexes one or more RLC PDUs, and adds a MAC header.
  • To form TB To form TB.
  • the MAC layer maps the TB to the transport channel and transmits it to the terminal through the air interface (UU) through the PHY layer processing.
  • the PHY layer of the terminal receives the data sent by the base station, and is processed by the PHY protocol and transmitted to the MAC layer.
  • the MAC layer demultiplexes the received TB, obtains multiple SDUs, and transmits them to the corresponding RLC subunits, where the RLC subunits are aggregated to PDCP layer.
  • a plurality of mutually independent V-RLC entities are configured for one logical channel, so that PDCP PDUs corresponding to the same RB can be distributed to multiple V-RLC entities for independent RLC processing, thereby processing the RBs.
  • Further logical splitting makes L2 more flexible in processing data. This further logical splitting of the processing of RBs will bring more beneficial effects in different application scenarios.
  • QoS Quality of Service
  • the basic granularity of QoS control is RB, that is, the data flow on the same RB will obtain the same QoS guarantee, such as scheduling policy, buffer queue management, and link. Layer configuration, etc.
  • LTE long term evolution
  • a bearer with a QoS class identifier (QCI) of 9 may have video buffer streaming media and a transmission control protocol (TCP) based service such as the World Wide Web (www e-mail). And the chart service, etc.
  • TCP transmission control protocol
  • These services may have different transmission delays and bit error rates, and thus have different requirements on the transmission mode. For example, services that are sensitive to delay and have low bit error rate requirements. It is more suitable to use non-acknowledgment (UM) mode to complete the transmission; for services with low latency requirements, but bit error rate sensitive, it is more suitable to use the acknowledgement (AM) mode to complete the transmission.
  • UM non-acknowledgment
  • AM acknowledgement
  • the existing L2 protocol cannot differentiate the transmission modes of the services, and the services of different transmission requirements are mapped to the QoS problem at the same bearer.
  • the base station processing resources are wasted. For example, two PDCP PDUs corresponding to RB1 in Figure 2 are transmitted to the same RLC entity for processing.
  • the two PDCP PDUs correspond to different service types and the requirements for the transmission mode are different, For example, a service that is sensitive to delay and has a low bit error rate (for example, Skype-type VOIP service or real-time network video service); one is a service that is not demanding in delay but is sensitive to bit error rate (for example) , e-mail service) o
  • the RLC entity cannot differentiate the PDCP PDUs of the two types of services.
  • the transmission mode supported by each V-RLC entity is one or more of the following transmission modes: acknowledgement mode (AM), un-acknowledgement mode (UM), and transparent mode (TM mode)
  • acknowledgement mode AM
  • UM un-acknowledgement mode
  • TM mode transparent mode
  • each virtual RLC entity may configure its supported transmission mode according to the service type at the time of establishment.
  • each component carrier CC
  • PCC primary carrier carrier
  • SCC Secondary Component Carrier
  • the spatial distribution of the baseband processing locations of the CCs is different, especially when the distance is relatively long, for example, it belongs to different boards (for example, different boards in the same base station, or boards in different chassis under the same base station, Or the boards in different base stations), the waiting delay before the RLC processing and the transmission delay of the PDU are long, and it is difficult to meet the current real-time requirements for the base station.
  • V-RLC entities can be configured for one logical channel, independent RLC processing can be performed on data corresponding to different CCs, so that each V-RLC entity can It is not necessary to wait for the MAC scheduling result of other CCs, but only initiates the RLC processing according to the scheduling result of its corresponding CC, so that the real-time requirement is satisfied.
  • each CC is visible at the MAC layer, different service flows can be handled by different CCs in the scenario of the CA, thereby satisfying the requirements for differentiating processing of different types of service data in the same RB in the previous scenario. .
  • the MAC layer can distinguish each CC, it can also be understood that the MAC entity exists independently for each CC. Therefore, the V-LCID may not be introduced, that is, the MAC layer does not need to do any work relative to the prior art. Change, the receiving end can directly send data to the correct V-RLC, RLC and PDCP entities through each MAC entity.
  • the base station can distribute different service packets to different CCs for transmission. For example, a data stream (message) with a higher real-time requirement such as VOIP is distributed from the PDCP to a corresponding V-RLC entity, and is transmitted using the RLC UM mode; the data stream with a higher bit error rate such as e-mail is transmitted. Distribute from PDCP to another V-RLC entity, use RLC AM mode for transmission.
  • the above method and device can be applied to a cross-board CA, that is, CC is deployed across a baseband board; or can be applied to a CA that does not span the board, that is, the CC is deployed on the same baseband board.
  • the processing requirements for inter-board or inter-station bandwidth and processing speed are greatly reduced, because the PDCP of the base station can immediately send the message to each V-RLC entity after generating the PDCP PDU. Waiting for scheduling, without waiting for the scheduling of each CC to complete, returning the scheduling result and then performing RLC protocol processing.
  • the real-time performance of VOIP and other real-time business flows is effectively guaranteed.
  • an RB can also virtualize traffic flows of both UM and AM RLC modes, where UM is used for real-time traffic (such as VOIP or real-time video), and AM is used for AM. Transmission of services with higher bit error rate (such as ordinary TCP services).
  • a V-RLC entity may be established through negotiation between the transmitting end and the receiving end, for example, the base station and the terminal initiate and complete the negotiation.
  • the timing of the negotiation may be selected at any reasonable time.
  • a negotiation process may be triggered to establish a virtual RLC entity; the virtual RLC entity may also be deleted at any time. Or change the protocol parameters of the virtual RLC entity.
  • the negotiation process may be triggered; When a virtual RLC entity performs poorly, delete the virtual RLC entity, or change the The parameters of the RLC entity.
  • the negotiation process can be divided into terminal capability acquisition process (process 1) and virtual RLC entity management.
  • Process 1 The terminal reports the terminal capability to the base station during initial access (whether the virtual RLC is supported, which solution is supported, such as supporting the first scheme or the second scheme, or both schemes) b or the base station needs Initiate a capability query to the terminal.
  • This process can borrow the existing terminal capability reporting and query process, and add virtual RLC capability related information in the terminal capability cell, for example, adding "terminal support V-LCID scheme one (Scheme)" and “terminal support V-LCID scheme two ( Scheme2)' Two capability indicators, or only one flag, indicating that the terminal supports both V-LCID schemes.
  • Process 2 Establish, modify, or delete a virtual RLC entity at the base station and the terminal. That is, the binding relationship between LCID and V-LCID is clarified, and the scheme selection of V-LCID is clarified. This process can borrow the current radio resource control (RRC) reconfiguration process. After the virtual RLC entity is established, the base station and the terminal can set a flag to indicate that a bearer has a virtual RLC entity.
  • RRC radio resource control
  • each of the above units or entities may be separately set in hardware form independently of the base station or the processor of the terminal.
  • the setting form may be in the form of a microprocessor, and may be separately set, or may be partially or fully integrated. Set together.
  • each of the above units or entities may be embedded in a certain processor of the base station or the terminal in hardware, or may be stored in a memory of the base station or the terminal in software, so as to facilitate the corresponding processor of the base station or the terminal.
  • Tune The software performs the operations corresponding to the above units or entities.
  • the above processor can be a central processing unit (CPU microprocessor, microcontroller, etc.).
  • FIG. 17 is a schematic structural diagram of a base station according to an embodiment of the present invention.
  • the base station 170 includes a transmitter 172, a receiver 171, a memory 173, and a processor 174 coupled to the transmitter 172, the receiver 171, and the memory 173, respectively.
  • the base station may also include a common component such as an antenna, a baseband processing component, a medium-frequency processing component, and an input/output device.
  • transmitter 172 and receiver 171 can be integrated to form a transceiver.
  • the memory code stores a set of program codes
  • the processor 174 is configured to call the program code stored in the memory 173 for executing the data processing method according to any one of the above method embodiments.
  • the base station 170 is a transmitting end, it is used to perform the method of the corresponding embodiment of Fig. 10, Fig. 11, or Fig. 12 above.
  • the base station is a receiving end, it is used to execute the method of the corresponding embodiment of Fig. 13 or Fig. 14 above.
  • FIG. 18 is a schematic structural diagram of a terminal according to an embodiment of the present invention.
  • the terminal 180 includes a transmitter 182, a receiver 181, a memory 183, and a processor 184 coupled to the transmitter 182, the receiver 181, and the memory 183, respectively.
  • the terminal may further include a common component such as an antenna, a baseband processing component, a medium-frequency processing component, and an input/output device, and the embodiment of the present invention is not limited thereto.
  • transmitter 182 and receiver 181 can be integrated to form a transceiver.
  • the memory code stores a set of program codes
  • the processor 184 is configured to call the program code stored in the memory 183 for executing the data processing method according to any one of the above method embodiments.
  • the terminal 180 is a transmitting end, the method for executing the corresponding embodiment of FIG. 10, FIG. 11, or FIG. 12 above is used.
  • the terminal is a receiving end, it is used to execute the method of the corresponding embodiment of FIG. 13 or FIG. 14 above.
  • Computer readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one location to another.
  • a storage medium may be any available media that can be accessed by a computer.
  • computer readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage media or other magnetic storage device, or can be used for carrying or storing in the form of an instruction or data structure.
  • Any connection may suitably be a computer readable medium.
  • the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave
  • coaxial cable , fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, wireless, and microwaves are included in the fixing of the associated media.
  • Disks and discs include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy discs, and Blu-ray discs, where discs are usually magnetically replicated, while discs are optically replicated using lasers. data. Combinations of the above should also be included within the scope of the computer readable media.

Abstract

本发明实施例提供一种数据处理装置和方法,针对一个逻辑信道配置多个RLC子单元,进而将同一个RB上的数据进行多个独立的RLC处理,从而相当于将一个RB拆分为多个虚拟RB,使得L2协议对数据的处理更加灵活。

Description

数据处理装置和方法 技术领域
本发明实施例涉及移动通信技术领域,尤其涉及数据处理装置和方法。 背景技术
第三代合作伙伴计划 ( The 3rd generation partnership project , 3 GPP )协 议中定义的层 2 ( L2 )协议栈包括报文汇聚协议( packet data convergence protocol , PDCP 无线链路控制( radio link control , RLC )协议和媒体接 入控制( medium access control , MAC )协议三个逻辑层次。 其中 , PDCP 层和 RLC层都是以无线承载( radio bear , RB )为最小工作对象, MAC层 以一个或多个 RB为最小工作对象。 然而,当前的 L2协议缺乏灵活性,在 处理数据的过程中 ,如果需要将此最小工作对象 RB再做进一步的逻辑拆分 时,当前的 L2协议就遇到了困难。 发明内容
有鉴于此,本发明实施例提供一种数据处理装置和方法,以提高 L2 协议在处理数据时的灵活性。
第一方面,提供一种数据处理装置,包括报文汇聚协议 PDCP单元、 无线链路控制 RLC单元和媒体接入控制 MAC单元,所述 RLC单元包括: 多个彼此独立的 RLC子单元,对应于同一逻辑信道,其中 :当所述装置位 于发送端时,每个 RLC子单元用于将所述 PDCP单元传送给该 RLC子单元 的 PDCP协议数据单元 PDU转换为 RLC PDU ,传送给所述 MAC单元,且 所述 PDCP单元传送给所述多个 RLC子单元的 PDCP PDU对应于同一无线 承载 RB;或当所述装置位于接收端时,所述每个 RLC子单元用于将所述 MAC单元传送给该 RLC子单元的 MAC业务数据单元 SDU转换为 RLC SDU ,传送给所述 PDCP单元。
在第一方面的第一种可能的实现方式中 ,所述多个 RLC子单元的配置 参数彼此独立。
结合第一方面或第一方面的第一种可能的实现方式,在第一方面的第 二种可能的实现方式中 ,当所述装置位于发送端时,所述 MAC单元用于: 为每个 RLC子单元传送的 RLC PDU配置相应的 MAC子头,且每个 MAC 子头包括虚拟逻辑信道标识 V-LCID ,该 V-LCID用于标识该 MAC子头所 关联的 RLC PDU所来自的 RLC子单元。
结合第一方面或第一方面的第一种或第二种可能的实现方式,在第一 方面的第三种可能的实现方式中 ,当所述装置位于接收端时,所述 MAC单 元用于:接收对端设备发送的 MAC PDU ,所述 MAC PDU包括 MAC头和 MAC负载,所述 MAC负载包括至少一个对端 RLC PDU ,所述 MAC头包 括至少一个 MAC子头,分别对应于所述至少一个对端 RLC PDU ,其中 , 所述对端 RLC PDU中包括第一对端 RLC PDU,该第一对端 RLC PDU对应 的 MAC子头包括 V-LCID,该 V-LCID用于标识所述多个 RLC子单元之一; 将接收的 MAC PDU转换为所述至少一个对端 RLC PDU;将所述第一对端 RLC PDU传送至所述 V-LCID所标识的 RLC子单元。
结合第一方面的第二种或第三种可能的实现方式之一,在第一方面的 第四种可能的实现方式中 所述 V-LCID是通过 MAC子头的预留位形成的; 或者是通过预留的 LCID形成的。
结合第一方面或第一方面的第一种至第四种可能的实现方式之一,在 第一方面的第五种可能的实现方式中 , 当所述装置位于发送端时,该装置 还包括:分发单元,用于将所述来自 PDCP单元的、对应于同一 RB的 PDCP PDU ,分发给所述多个 RLC子单元。
结合第一方面的第五种可能的实现方式,在第一方面的第六种可能的 实现方式中 ,所述分发单元具体用于:按每个 PDCP PDU对应的业务类型, 将每个 PDCP PDU分发给所述多个 RLC子单元中适应于该业务类型数据传 输的 RLC子单元;或者,以轮询的方式将所述来自 PDCP单元的、 对应于 同一 RB的 PDCP PDU分发给所述多个 RLC子单元。
第二方面,提供一种数据传输方法,应用于发送端设备中的无线链路 控制 RLC层 ,所述 RLC层包括多个彼此独立的 RLC子单元,且所述多个 RLC子单元对应于同一逻辑信道,该方法包括:每个 RLC子单元接收所述 发送端设备中的报文汇聚协议 PDCP层传送给该 RLC子单元的 PDCP协议 数据单元 PDU ,其中 ,所述 PDCP层传送给所述多个 RLC子单元的 PDCP PDU对应于同一无线承载 RB;每个 RLC子单元将所接收到的 PDCP PDU 转换为 RLC PDU ,传送给所述发送端设备中的媒体接入控制 MAC层。
在第二方面的第一种可能的实现方式中 ,所述多个 RLC子单元的配置 参数彼此独立。
结合第二方面或第二方面的第一种可能的实现方式,在第二方面的第 二种可能的实现方式中 ,所述方法还包括:所述 MAC层为每个 RLC子单 元传送的 RLC PDU配置相应的 MAC子头,且每个 MAC子头包括虚拟逻 辑信道标识 V-LCID ,该 V-LCID用于标识该 MAC子头所关联的 RLC PDU 所来自的 RLC子单元。
结合第二方面的第二种可能的实现方式,在第二方面的第三种可能的 实现方式中 ,所述 V-LCID是通过 MAC子头的预留位形成的;或者是通过 预留的 LCID形成的。
结合第二方面或第二方面的第一种至第三种可能的实现方式之一,在 第二方面的第四种可能的实现方式中 ,每个 RLC子单元接收所述发送端设 备中的 PDCP层传送给该 RLC子单元的 PDCP PDU之前,还包括:所述 PDCP层生成所述对应于同一 RB的 PDCP PDU;将所述对应于同一 RB的 PDCP PDU分发给所述多个 RLC子单元。 结合第二方面的第四种可能的实现方式,在第二方面的第五种可能的 实现方式中 ,将所述对应于同一 RB的 PDCP PDU分发给所述多个 RLC子 单元,包括:按每个 PDCP PDU对应的业务类型,将每个 PDCP PDU分发 给所述多个 RLC子单元中适应于该业务类型数据传输的 RLC子单元;或者, 以轮询的方式将所述对应于同一 RB的 PDCP PDU分发给所述多个 RLC子 单元。
第三方面,提供一种数据传输方法,应用于接收端设备中的无线链路 控制 RLC层 ,所述 RLC层包括多个彼此独立的 RLC子单元,且所述多个 RLC子单元对应于同一逻辑信道,包括:每个 RLC子单元接收所述接收端 设备中的媒体接入控制 MAC层传送给该 RLC子单元的 MAC SDU;每个 RLC子单元将所接收的 MAC SDU转换为 RLC SDU,传送给所述接收端设 备中的报文汇聚协议 PDCP层。
在第三方面的第一种可能的实现方式中 ,所述多个 RLC子单元的配置 参数彼此独立。
结合第三方面或第三方面的第一种可能的实现方式,在第三方面的第 二种可能的实现方式中 ,每个 RLC子单元接收所述接收端设备中的 MAC 层传送给该 RLC子单元的 MAC SDU之前,还包括:
所述接收端设备中的 MAC层接收对端设备发送的 MAC PDU ,所述 MAC PDU包括 MAC头和 MAC负载,所述 MAC负载包括至少一个对端 RLC PDU ,所述 MAC头包括至少一个 MAC子头,分别对应于所述至少一 个对端 RLC PDU ,其中 ,所述对端 RLC PDU中包括第一对端 RLC PDU , 该第一对端 RLC PDU对应的 MAC子头包括虚拟逻辑信道标识 V-LCID , 该 V-LCID用于标识所述多个 RLC子单元之一;所述 MAC层将所接收的 MAC PDU转换为所述至少一个对端 RLC PDU;所述 MAC层将所述第一 对端 RLC PDU传送至所述 V-LCID所标识的 RLC子单元。
结合第三方面的第二种可能的实现方式,在第三方面的第三种可能的 实现方式中 ,所述 V-LCID是通过 MAC子头的预留位形成的;或者是通过 预留的 LCID形成的。
第四方面,提供一种计算机程序产品 ,包括计算机可读介质,所述计 算机可读介质包括一组程序代码,用于执行如第二方面或第二方面任一种 实现方式所述的方法。
第五方面,提供一种计算机程序产品 ,包括计算机可读介质,所述计 算机可读介质包括一组程序代码,用于执行如第三方面或第三方面任一种 实现方式所述的方法。
可见,在以上装置和方法中 ,针对一个逻辑信道配置多个 RLC子单元 , 进而将同一个 RB上的数据进行多个独立的 RLC处理,从而相当于将一个 RB拆分为多个虚拟 RB ,使得 L2协议对数据的处理更加灵活。 附圉说明 为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中 所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本 发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动 的前提下,还可以根据这些附图获得其他的附图。
图 1为一种现有的通信系统的协议框图 ;
图 2为一种图 1所示协议架构下数据流的示意图 ;
图 3为本发明实施例提供的一种数据处理装置的结构示意图 ; 图 4为现有的 MAC PDU的结构示意图 ;
图 5为本发明实施例提供的一种 V-LCID的示意图 ;
图 6为本发明实施例提供的另一种 V-LCID的示意图 ;
图 7为本发明实施例提供的一种 MAC PDU的结构示意图 ; 图 8为本发明实施例提供的另一种 MAC PDU的结构示意图 ; 图 9为本发明实施例提供的另一种数据处理装置的结构示意图 ; 图 10为本发明实施例提供的一种数据处理方法的流程图 ;
图 11为本发明实施例提供的另一种数据处理方法的流程图 ; 图 12为本发明实施例提供的又一种数据处理方法的流程图 ; 图 13为本发明实施例提供的又一种数据处理方法的流程图 ; 图 14为本发明实施例提供的又一种数据处理方法的流程图 ; 图 15为本发明实施例提供的一种通信系统的结构示意图 ; 图 16为本发明实施例提供的另一种通信系统的结构示意图 ; 图 17为本发明实施例提供的一种基站的结构示意图 ;
图 18为本发明实施例提供的一种终端的结构示意图。 具体实施方式
为使本发明实施例的目的、 技术方案和优点更加清楚,下面将结合本 发明实施例中的附图 ,对本发明实施例中的技术方案进行清楚、 完整地描 述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。 基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动的前 提下所获得的所有其他实施例,都属于本发明保护的范围。
请参考图 1,其为一种现有的通信系统的协议框图。如图 1所示, 3GPP 协议中定义的层 2 ( L2 )协议栈包括报文汇聚协议( packet data convergence protocol , PDCP 无线链路控制( radio link control , RLC )协议和媒体接 入控制( medium access control , MAC )协议三个逻辑层次。 层 1 ( LI )主 要是指物理( PHY )层。 关于各个逻辑层次的功能,以下做简单说明 ,其 为本领域技术人员所熟知,在此不详加说明。
在发送端, PDCP层主要用于对应用( APP )层的业务包(例如,因特 网协议( internet protocol , IP )包)进行包头压缩,以减少报文头引起的无 效开销( overhead ) ;另外, PDCP 层还可以用于控制平面的加密,传输数 据的完整性保护 ,以及针对切换的按序发送或复本删除等;相应的 ,在接 收端, PDCP层用于执行相应的解密和解压缩等操作。 在发送端, RLC层 主要用于数据分割和 /或级联,此外,还可以用于自动重传请求( automatic repeat request , ARQ )相关的操作,例如重传检测,或序列传送到更上层等 操作;相应的 ,在接收端,RLC层主要用于数据重组、 ARQ相关的操作等。 在发送端, MAC 层主要用于控制逻辑信道的复用、 混合自动重传请求 ( hybrid automatic repeat request , HARQ )重传、 上行链路和下行链路的调 度等操作;相应的 ,在接收端, MAC层主要用于解复用 , HARQ重传等操 作。 PHY层主要用于编码 /解码、 调制 /解调、 天线及资源的映射 /反映射等 操作。
需要说明的是,在以上和以下内容中 ,关于各个逻辑层的功能,同 3GPP 对这些协议层的定义,且可随标准协议共同演进,本发明的改进不在于此, 其具体操作内容不构成对本发明的限制。
请继续参考图 2 ,其为一种图 1所示协议架构下数据流的示意图。如图 2所示, PDCP层执行包头压缩之后进行加密,增加 PDCP头用来携带终端 解密所需的信息。 RLC层执行 PDCP 业务数据单元( service data unit ,SDU ) 的级联和 /或分割,并添加 RLC 头,用于终端的按序发送以及重传情况下 RLC 协议数据单元( protocol data unit , PDU )鉴定。 RLC PDU被转发到 MAC层,复用一个或多个 RLC PDU ,并添加 MAC头以形成 MAC PDU , 或称之为传输块 ( transport block , TB )b 可见, RLC层以无线承载( radio bear , RB )的形式向 PDCP提供服务, PDCP层和 RLC层都是以 RB为最小工作对象的 , MAC以一个或多个 RB 为最小工作对象。然而,当前的 L2协议缺乏灵活性,在处理数据的过程中 , 如果需要将此最小工作对象 RB再做进一步的逻辑拆分时,当前的 L2协议 就遇到了困难。
为此,以下实施例对 RLC层做出调整,针对一个逻辑信道配置多个 RLC 实体,进而将同一个 RB上的数据进行多个独立的 RLC处理,从而相当于 将一个 RB拆分为多个虚拟 RB ,使得 L2协议对数据的处理更加灵活。 以 下结合图 3进行详细说明。
请参考图 3 ,其为本发明实施例提供的一种数据处理装置的结构示意 图。 该数据处理装置 300 可以位于发送端,用于对待发送的下行数据或上 行数据进行 L2协议处理;也可以位于接收端,用于对接收的上行数据或下 行数据进行 L2协议处理;例如,该数据处理装置 300可以位于接入网网元 (例如,基站),也可以位于终端。 如图 3所示,该数据处理装置 300包括 PDCP单元 310 , RLC单元 320和 MAC单元 330。 其中 , RLC单元 320包 括多个 RLC子单元 321至 32η ,其中 ,η为大于等于 2的正整数。这些 RLC 子单元对应于同一逻辑信道,且它们彼此独立,例如配置参数彼此独立。
当该数据处理装置 300位于发送端时, RLC子单元 321至 32η用于分 担来自 PDCP单元 310的、对应于同一 RB的 PDCP PDU ,且分别独立的将 各自分担的 PDCP PDU转换为 RLC PDU传送给 MAC单元 330。 即,每个 RLC子单元用于将 PDCP单元 310传送给自身的 PDCP PDU转换为 RLC PDU ,传送给 MAC单元 330 ,且 PDCP单元 310传送给 RLC子单元 321 至 32η的 PDCP PDU对应于同一 RB。
当该数据处理装置 300位于接收端时, RLC子单元 321至 32η分别用 于将来自 MAC单元 330的 SDU转换为 RLC SDU ^聚给 PDCP单元 310。 即,每个 RLC子单元用于将 MAC单元 330传送给自身的 MAC SDU转换 为 RLC SDU ,传送给 PDCP单元 310。
以上发送端和接收端即可以是基站,也可以终端。 此外,发送端同时 也可以作为接收端,相应的 ,接收端同时也可以作为发送端, 因此, RLC 子单元 321至 32η既可以用于分担来自 PDCP单元 310的对应于同一 RB的 PDCP PDU,且分别独立的将各自分担的 PDCP PDU转换为 RLC PDU传送 给 MAC单元 330;也可以用于将来自 MAC单元 330的 SDU转换为 RLC SDU ,汇聚给 PDCP单元 310。
需要说明的是,以上 RLC子单元的配置参数是指该 RLC子单元完成 RLC层功能,所需配置的参数,例如,可以包括:传输模式、 传输窗口等 参数。 本领域技术人员对于 RLC实体的配置参数的组成所熟知,在此不再 赘述,且以上实施例中各 RLC子单元(虚拟 RLC实体)的配置参数的引入, 主要为了强调它们的配置参数彼此独立,进而说明这些 RLC子单元是彼此 独立的 RLC实体,而并未对配置参数本身做出任何限制。 也就是说,以上 多个 RLC子单元的配置参数彼此独立,表明了这些 RLC子单元是独立的 RLC实体,具有现有 RLC实体的一样的功能。
在现有技术中 ,针对一个逻辑信道仅配置一个 RLC实体;而在本发明 实施例中 ,为一个逻辑信道配置了多个 RLC实 即,以上所述的多个 RLC 子单元),为了和现有技术中的 RLC 实体区分,以下称为虚拟 RLC 实体 ( V-RLC ),如附图中的 V-RLC Χ0至 Χη;然而,这个" 虚拟" 仅仅是用于 区分使用的,并非这些虚拟 RLC实体与现有的 RLC实体有区别,这些虚拟 RLC实体是针对同一个逻辑信道的独立的多个 RLC实体,也就是说,这些 虚拟 RLC实体彼此独立,且具有各自的一套配置参数。 如此, 同一 RB对 应的 PDCP PDU可以分发给多个 V-RLC实体进行独立的 RLC处理,从而 对 RB的处理得到了进一步的逻辑拆分,使得 L2对数据的处理更加灵活。
需要说明的是,关于各个逻辑层的处理,例如, PDCP协议处理, RLC 协议处理和 MAC协议处理,同 3GPP对这些协议层的定义,且各个逻辑层 的处理可随标准协议共同演进,本发明的改进不在于此,其具体操作内容 不构成对本发明的限制。
另外,本发明各个实施例中的单元、 子单元、 实体、 或虚拟实体是指 功能实体或逻辑实体。 其可以为软件形式,通过处理器执行程序代码来实 现其功能;也可以为硬件形式,本发明不做任何限制。 目前,在发送端 LC实体将 PDCP PDU转换为 RLC PDU发送给 MAC 实体以后, MAC实体复用一个或多个 RLC PDU ,并添加 MAC头以形成 TB ,并将传输块映射到传输信道,通过 PHY层的处理发送给接收端。 在接 收端,MAC实体根据 MAC头进行解复用 ,得到一个或多个 MAC SDU(即, 发送端复用的一个或多个 RLC PDU ) ,并根据 MAC头中的各个子头的信息, 将每个 MAC SDU传送给对应 RLC实体进行处理。
请参考图 4 ,其为现有的 MAC PDU (即, TB )的结构示意图。 如图 4 所示, MAC PDU通常包括 MAC头, 0个或者更多个 MAC SDU , 0个或者 更多个 MAC 控制元( MAC control element ) ,可选的 ,还可以包括补丁 ( padding )b 对于每个 MAC SDU (即复用的 RLC PDU ) ,在 MAC头中存 在一个关联的子头。一个普通的 MAC PDU子头由六个 ii( R/R/E/LCID/F/L ) 组成,可以有 L字段为 7bit和 15bit的两种形式;对于最后一个子头、 固定 长度的 MAC控制元以及补丁对应的子头,包括四个域( R/R/E/LCID )b 其中 , R是预留比特位(简称预留位),设为" 0" ; E用于指示 MAC 头是否有多个域,例如当 E=l时,意味着接下来存在另外一组 R/R/E/LCID" 域,当 Ε=0 ,意味着接下来是 MAC负载了 ; 逻辑信道标识( logical channel ID , LCID )用于标识对应的 RLC PDU起源于哪个逻辑信道; F用于指示 L 字段的长度; L用于指示 MAC SDU或者控制消息的长度。
可见,多个逻辑信道(其中 ,每个逻辑信道都有自己的 RLC实体)可 以被 MAC层复用到一个传输信道。在接收端, MAC层处理相应的解复用 , 并转发 RLC PDU到其各自的 RLC实体。
现有技术中 ,采用 LCID 标识逻辑信道, 由于一个逻辑信道对应一个 RLC实体,进而可以理解为 LCID可以标识该逻辑信道对应的 RLC实体。 而采用以上技术方案以后,一个逻辑信道可以配置多个 V-RLC实体,此时 需要重新配置 MAC子头,以使得 MAC实体可以将解复用后的 MAC SDU 传送到正确的 V-RLC实体。具体,可以针对每个 V-RLC实体,为其设计其 对应的虚拟 LCID ( V-LCID ) ,并将这个标识打包到 MAC子头中 ,如此, MAC 实体便可以根据 V-LCID 将解复用后的 MAC SDU 传送到正确的 V-RLC实体。
下面介绍 V-LCID的设计。 要注意的是,以下对 V-LCID的设计仅仅用 于举例,本发明的保护范围不限于下述几个数量有限的设计举例,本领域 技术人员可以据此提示,得到相同原理和功能的设计方案,均在本发明保 护范围之内。
在设计 V-LCID时,考虑到协议的兼容性, V-LCID的设计可以满足如 下的原则 :
1、 随包原则:即接收端从 MAC PDU中可解析 V-LCID ,无需其他运 载 V-LCID信息的对象。
2、 容量原则:即 V-LCID的取值范围必须能满足场景需求。 另外,在设计 V-LCID 时,同一逻辑信道对应的 V-RLC 实体的多个 V-LCID与该逻辑信道对应的 LCID的绑定。 该绑定关系,可以在 MAC子 头中实现,也可以通过约束关系实现,具体将在以下例子中详细描述。
从随包原则出发,以下描述两种基本的 V-LCID设计方案实例: 方案一:请参考图 4和图 5,使用 MAC PDU的 MAC头中的两个预留 位" R" 作为与协议兼容的 V-LCID。
这种形式 V-LCID的容量为 4 ,即一个 LCID下有 V- LCID = 0/1/2/3对 应的四个 V-RLC实体可与 LCID绑定。
方案二:请参考表 1 ,其为一种现有的 LCID取值的表格。 采用" N" 个预留的 LCID作为 V-LCID ,且规定 V-LCID 固定对应于 LCID+N ,即 V-LCID = LCID+N。 其中 , N为自然数。 如图 6所示,其给出了 N为 10或 8的例子。
表 1
Figure imgf000016_0001
此方案 V-LCID的容量为 1 ,即一个 LCID下有一个 V-LCID对应的 V-RLC实体可与 LCID绑定。 代价为需要 N个目前被预留的 LCID。
考虑到一般只会对数据无线承载( data radio bearer , DRB )创建 V-RLC 实体,而 3GPP协议规定一个终端的 DRB数量最大为 8 ,则启用" 01011 - 10010"作为 8个 DRB固定对应的 V-LCID即可满足要求 V-LCID = LCID 需要说明的是,本方案的 V-LCID = LCID + 8只是一种较为简单实现方 法。 实际上,只要有明确且高效的 V-LCID和 LCID的映射关系,都可以构 成适合虚拟 RLC技术的方案,并在本方案的保护之下。
如果上面两个方案的容量都不满足场景需求,那么可以将方案一和方 案二同时应用 ,这时 V-LCID的容量是 5。
采用以上构造 V-LCID的方案以后, MAC实体可以根据 V-LCID ,将 MAC PDU解析为 MAC SDU后,找到正确的 V-RLC实体,以便完成 RLC PDU到 RLC SDU的解析,然后再将多个虚拟 RLC实体的 SDU传送到正确 的 PDCP实体完成 PDCP协议处理。
需要说明的是,以上对 V-LCID的设计考虑到了与现有协议的兼容性, 得到了与现有技术兼容的 V-LCID ,然而,本发明并不限制于此,也可以对 每个 V-RLC重新设计 MAC子头的格式,只要 MAC实体根据该 MAC子头 的信息,将关联的 MAC SDU传送到对应的 RLC实体即可。
此时,在发送端的 MAC层增加了将 V-LCID填入 MAC PDU的功能, 简称虚拟打包( vPack )功能;在接收端的 MAC层增加了根据 V-LCID将 MAC SDU提交到正确的 V-RLC实体的功能,简称虚拟投递( vDeliver )功 能。
下面结合图 3进行详细说明 ,在图 3所示的实施例中 , 当该装置 300 位于发送端时 MAC单元 330具体用于将多个逻辑信道传送来的 RLC PDU 复用为至少一个 MAC PDU。 其中 ,对应于 RLC子单元 321-32n的逻辑信 道的 RLC PDU可以被全部复用为一个 MAC PDU ,也可以被部分复用 ,生 成多个 MAC PDU,且生成的 MAC PDU中还可以包括其它逻辑信道的 RLC PDU ;IP在 MAC单元 330的复用过程中 ,并不限制哪些 RLC子单元的 PDU
(例如,所有的还是部分的 RLC子单元的 PDU )复用在一起,也不限制是 否将该多个 RLC 子单元对应的逻辑信道的 RLC PDU 与其它逻辑信道的 RLC PDU复用在一起。 每个 MAC PDU具体与图 4所示的相同的结构,包 括 MAC头和 MAC负载。
当采用以上方案一,即利用 MAC头中的两个预留位 R"构造 V-LCID , MAC头中的每个子头包括 V-LCID (即两个预留位" R" ) , E , LCID等。 此时,请参考图 7 , MAC PDU (或 TB )包括 MAC头和 MAC负载,所述 MAC头包括至少一个 MAC子头,所述 MAC负载包括至少一个 RLC PDU
(即 MAC SDU ) ,每个 MAC子头对应一个 RLC PDU。 通过以上描述可以 知道, MAC可以复用同一逻辑信道不同 V-RLC实体的 RLC PDU ,也可以 复用不同逻辑信道的 RLC PDU;且同一逻辑信道不同 V-RLC实体的 RLC PDU可以复用在一个 MAC PDU中 ,也可以复用在不同的 MAC PDU中。 因此,该 MAC PDU中的 MAC负载所包括的 RLC PDU可以均来自 V-RLC 实体,也可以部分来自 V-RLC实体,当然,也可以不包括来自 V-RLC实体 的 RLC PDU ,例如,来自现有 RLC实体(即,其对应逻辑信道仅设置有一 个 RLC实体)的 RLC PDU。 其中 ,与来自现有 RLC实体的 RLC PDU所 关联的子头与现有技术相同,在此不讨论。 当 MAC负载包括来自 V-RLC 实体的 RLC PDU时,在与 V-RLC实体发送来的 RLC PDU对应的 MAC子 头中 ," RR" 字段由" V-LCID" 字段取代,即与 V-RLC实体发送来的 RLC PDU对应的 MAC子头包括 V-LCID。
当采用以上方案二,即采用" N" 个预留的 LCID作为 V-LCID ,且规 定 V-LCID固定对应于 LCID+N,即 V-LCID = LCID+N。此时,请参考图 8 , 在与 V-RLC实体发送来的 RLC PDU对应的 MAC子头中 ," LCID"字段由 与之绑定的" V-LCID" 字段所取代即,与 V-RLC实体发送来的 RLC PDU 对应的 MAC子头包括 V-LCID。
可见,在本发明一实施例中 ,当以上装置 300位于发送端时, MAC单 元 330可以用于:为每个 RLC子单元传送的 RLC PDU配置相应的 MAC 子头,且所配置的每个 MAC子头包括 V-LCID,该 V-LCID用于标识该 MAC 子头所关联的 RLC PDU所来自的 RLC子单元。 在本发明又一实施例中 ,当以上装置 300位于接收端时,MAC单元 330 可以用于接收对端设备发送的 MAC PDU,该 MAC PDU具有图 3所示的结 构 包括 MAC头和 MAC负载, MAC负载包括至少一个对端 RLC PDU , MAC头包括至少一个 MAC子头,分别对应于至少一个对端 RLC PDU。与 现有技术不同的是,MAC头中包括至少一个与现有技术不同的 MAC子头, 即包括 V-LCID的 MAC子头(例如,如图 7或图 8所示的 MAC子头),且 该 V-LCID用于标识以上多个 RLC 子单元 321-32n之一。 在此,称包括 V-LCID的 MAC子头对应的对端 RLC PDU为第一对端 RLC PDU。 MAC 单元 330进一步可以用于将接收的 MAC PDU转换为至少一个对端 RLC PDU;将第一对端 RLC PDU传送至对应的 RLC子单元,该对应的 RLC子 单元是指第一对端 RLC PDU对应的 MAC子头中 V-LCID所标识的 RLC子 单元。
可以参照图 7和图 8对应的两种设计方案,本实施例中的 V-LCID可以 通过 MAC子头的预留位形成;也可以通过预留的 LCID形成。 具体请参照 以上描述,在此不再赘述。
需要说明的是,为了清楚起见,图 7和图 8相对于图 4省略了 F , L等 字段,且关于子头的多种类型也没有体现,但这仅是为了凸显本实施例的 改进点而省略,并非用于限制本发明。
另外,除了采用以上 V-LCID 的方式可以使得 MAC层将空口收到的 MAC PDU解析为 MAC SDU后,能找到对应的 V-RLC实体,还可以采用 其它的方式进行处理。 例如,采用其它标志位的方式进行处理,相对于以 上 V-LCID的方式对于协议的影响相对较大。
请继续参考图 9 ,在本发明又一实施例中 ,当以上装置 300位于发送端 时,该装置还可以包括分发单元 340,用于将来自 PDCP单元 310的、 对应 于同一 RB的 PDCP PDU分发给 RLC子单元 321-32η。 即, PDCP单元 310 通过分发单元 340向每个 RLC子单元传送 PDCP PDU。
需要说明的是,分发单元 340的功能可以内嵌于 PDCP单元 310 ,即直 接由 PDCP单元 310将其产生的 PDCP PDU进行分发;分发单元 340也可 以独立存在,且可以位于 PDCP层,也可以位于 RLC层,由 PDCP单元 310 将产生的 PDCP PDU传送给分发单元 340 ,而后由分发单元 340分发给。 RLC子单元 321-32n。
另外,分发单元 340 的分发方式可以有多种,例如,可简单地在多个 RLC 子单元之间轮询发放,也可引入复杂的提升鲁棒性的子功能,如与协 商流程结合,在某个 RLC子单元性能不佳时,删除或修改该 RLC子单元; 再如,还可以按 PDCP PDU对应的业务类型,将不同业务类型的 PDCP PDU 分发给不同的 RLC子单元,即按每个 PDCP PDU对应的业务类型,将每个 PDCP PDU分发给以上多个 RLC子单元 321-32n中适应于该业务类型数据 传输的 RLC子单元。 总之,本发明对分发的形式不做任何限制。 请继续参考图 10 ,本发明实施例还提供一种数据处理方法。 该方法用 于发送端对数据进行 L2处理。 该发送端可以为接入网网元(例如,基站), 也可以为终端。具体,该方法应用于发送端设备中的 RLC层,该 RLC层具 有以上装置实施例提供的结构,包括多个彼此独立的 RLC子单元,且这些 RLC子单元对应于同一逻辑信道。如图 10所示,该方法至少包括如下步骤:
5101:每个 RLC子单元接收所述发送端设备中 PDCP层传送给该 RLC 子单元的 PDCP PDU ,其中 ,所述 PDCP层传送给所述多个 RLC子单元的 PDCP PDU对应于同一 RB;
5102:每个 RLC子单元将所接收到的 PDCP PDU转换为 RLC PDU , 传送给所述发送端设备中的 MAC层。
MAC层进一步可以对 RLC层传送的 RLC PDU进行复用处理,且在复 用处理过程中 ,为每个 RLC PDU配置管理的子头,包括对每个 RLC子单 元所传送的 RLC PDU配置子头。 需要说明的是,每个 RLC子单元传送的 RLC PDU可以为一个,也可以为多个。 具体,请继续参考图 11 ,其为本发 明实施例提供的另一种数据处理方法的流程图 ,该方法除了包括图 10所示 的步骤 S101和 S102 ,还包括如下步骤:
S111: MAC层为每个 RLC子单元传送的 RLC PDU配置相应的 MAC 子头,且每个 MAC子头包括 V-LCID ,该 V-LCID用于标识该 MAC子头 所关联的 RLC PDU所来自的 RLC子单元。 请继续参考图 12 ,其为本发明实施例提供的又一种数据处理方法的流 程图。该方法同图 10和图 11所示的方法,用于发送端对数据进行 L2处理。 该发送端可以为接入网网元(例如,基站),也可以为终端。 如图 12所示, 该方法包括如下步骤:
5121: PDCP层生成多个 PDCP PDU ,所述多个 PDCP PDU对应于同 ― RB;
5122:将所述多个 PDCP PDU分发给 RLC层的多个 RLC子单元,所 述多个 RLC子单元彼此独立且对应于同一逻辑信道;
5123:所述多个 RLC子单元分别独立的将各自分得的 PDCP PDU转 换为 RLC PDU传送给 MAC层。
为了更加清楚的理解以上过程,现结合图 2进行详细描述以上过程, 包括如下步骤:
PDCP层生成 PDCP PDU ,其中 ,所生成的 PDCP PDU包括对应于同 一无线承载的多个 PDCP PDU;例如,图 2中所示的对应于 RBI的两个 PDCP PDU (以下称之为第一 PDCP PDU和第二 PDCP PDU )b
将所生成的 PDCP PDU传送给 RLC层;与现有技术不同的是,该 RLC 层包括多个 RLC子单元,所述多个 RLC子单元对应于同一逻辑信道,且彼 此独立,该步骤进一步包括:将所述对应于同一 RB的多个 PDCP PDU分 发给所述多个 RLC子单元;例如,将对应于 RB1的第一 PDCP PDU和第 二 PDCP PDU分发给所述多个 RLC 子单元中的第一 RLC子单元和第二 RLC子单元。
RLC层接收传送的 PDCP PDU ,并将所接收的 PDCP PDU转换为 RLC PDU传送给 MAC层,进一步包括:所述多个 RLC子单元分别独立的将各 自分得的 PDCP PDU转换为 RLC PDU传送给 MAC层;例如,第一 RLC 子单元和第二 RLC子单元独立的对第一 PDCP PDU和第二 PDCP PDU进行 RLC协议处理(例如,级联和 /或分割),各自得到至少一个 RLC PDU传送 给 MAC层。
需要说明的是,以上 RLC子单元的数量和对应于同一 RB的 PDCP PDU 的数量虽然都用多个表述,但是其可以相同 ,也可以不同。 具体,可以根 据实际需要进行配置。 例如,根据同一 RB中业务的种类配置 RLC子单元 的个数。 进一步,可以根据不同于种类的业务对于传输模式的要求而将同 一 RB中的 PDCP PDU划分为需要进行 UM传输的组,需要进行 AM传输 的组。 每个组的 PDCP PDU分给对应传输模式的 RLC子单元。 当然,如果 一个组的数据比较多,也可以对应于该组建立多个 RLC子单元,在此不做 任何限制,本领域技术人员可以根据需要进行设定。
需要说明的是,以上 S102中的分发方式可以有多种,例如,可简单地 在多个 RLC子单元之间轮询发放,也可引入复杂的提升鲁棒性的子功能, 如与协商流程结合,在某个 RLC 子单元性能不佳时,删除或修改该 RLC 子单元;再如,还可以按所述多个 PDCP PDU对应的业务类型,将所述多 个 PDCP PDU分发给 RLC层的多个 RLC子单元。 举例而言,可以将同一 业务类型的 PDCP PDU分发给一个 RLC子单元,也可以将不同业务类型但 对传输模式要求相同的 PDCP PDU分发给一个 RLC子单元。总之,本发明 对分发的形式不做任何限制。
另外,本实施例还可以进一步包括图 11所示的步骤 S111 ,即 MAC层 为每个 RLC PDU配置 MAC子头的过程。
请继续参考图 13 ,本发明实施例还提供另一种数据处理方法。 该方法 用于接收端对数据进行 L2处理。 该接收端可以为终端,也可以为接入网网 元(例如,基站 )o具体,该方法应用于接收端设备中的 RLC层,所述 RLC 层具有以上装置实施例提供的结构,包括多个彼此独立的 RLC子单元,且 所述多个 RLC子单元对应于同一逻辑信道。 如图 13所示,该方法包括如 下步骤:
S131每个 RLC子单元接收所述接收端设备中的 MAC层传送给该 RLC 子单元的 MAC SDU;
S132:每个 RLC子单元将所接收的 MAC SDU转换为 RLC SDU ,传 送给所述接收端设备中的 PDCP层。
每个 RLC子单元接收到 MAC SDU ,是 MAC层解复用获得并发送给 该 RLC子单元的。 具体,请参考图 14 ,其为本发明实施例所提供的又一种 数据处理方法的流程图。 如图 14所示,在图 13所示的步骤 S131之前,还 包括如下步骤:
5141: MAC层接收对端设备发送的 MAC PDU ,该 MAC PDU包括 MAC头和 MAC负载, MAC负载包括至少一个对端 RLC PDU , MAC头包 括至少一个 MAC子头,分别对应于所述至少一个对端 RLC PDU ,其中 , 对端 RLC PDU中包括第一对端 RLC PDU ,该第一对端 RLC PDU对应的 MAC子头包括 V-LCID ,该 V-LCID用于标识以上多个 RLC子单元之一;
5142: MAC层将所接收的 MAC PDU转换为其中的至少一个对端 RLC PDU;
5143: MAC层将第一对端 RLC PDU传送至 V-LCID所标识的 RLC子 单元。
以上各个方法实施例中的 V-LCID与以上装置实施例中的描述一致,在 此不再赘述。
以上各方法实施例中 ,对于同一个 RB上的数据,可以有多个 RLC子 单元( V-RLC实体)对其进行独立的 RLC处理,从而对 RB的处理得到了 进一步的逻辑拆分,使得 L2对数据的处理更加灵活。
请参考图 15 ,其为本发明实施例提供的一种通信系统的结构示意图。 在本实施例中 ,以下行数据传输为例进行说明 ,上行传输与之类似,在此 不再赘述。 如图 15所示,在本实施例中 ,基站作为发送端,其 PDCP层接 收 APP层的业务包,对业务包执行包头压缩等 PDCP协议处理,生成 PDCP PDU。由于每个业务包都有其对应的 RB,则生成的 PDCP PDU都有其对应 的 RB,而对应于同一 RB的 PDCP PDU可以有多个。 RLC接收 PDCP PDU , 并进行缓存。 且对 PDCP SDU进行级联和 /或分割,并添加 RLC头等协议 处理,生成 RLC PDU。 现有技术中 ,同一个 RB对应的 PDCP PDU传送给 同一逻辑信道对应的一个 RLC实体进行处理,而本实施例对一个逻辑信道 配置多个 V-RLC实体,该多个 V-RLC实体可以分担同一 RB对应的 PDCP PDU ,且每个 V-RLC实体对各自分担的 PDCP PDU进行 RLC协议处理, 生成至少一个 RLC PDU传送到 MAC层, MAC层复用一个或多个 RLC PDU ,并添加 MAC头以形成 TB。 且 MAC层将 TB映射到传输信道后经 PHY层处理通过空口 ( UU )传输给终端。 终端的 PHY层接收到基站发送 的数据,经过 PHY协议处理,传送给 MAC层, MAC层将接收到 TB解复 用 ,得到多个 SDU,传送给对应的 RLC子单元,由 RLC子单元汇聚至 PDCP 层。
以上实施例中 ,为一个逻辑信道配置了多个彼此独立的 V-RLC实体, 如此,同一 RB对应的 PDCP PDU可以分发给多个 V-RLC实体进行独立的 RLC处理,从而对 RB的处理得到了进一步的逻辑拆分,使得 L2对数据的 处理更加灵活。这种对 RB的处理进行进一步的逻辑拆分,在不同的应用场 景中 ,将带来更多的有益效果。 例如,在服务质量( Quality of Service , QoS )控制机制中 , 目前, QoS 控制的基本粒度是 RB ,即相同 RB上的数据流将获得相同的 QoS保障,如 调度策略,缓冲队列管理,链路层配置等。虽然长期演 long term evolution , LTE )无线接入网络根据 QoS需求为 IP数据包提供一个或多个 RB ,但是 同一个 RB中仍可能存在对传输模式要求不同的多种业务数据,而无法对这 些业务数据进行差异化处理。 例如, QoS等级标识( QoS class identifier , QCI ) 为 9 的承载上可以有视频缓冲流媒体和基于传输控制协议 ( transmission control protocol , TCP )的业务,例如万维网( www 电子 邮件( e-mail )、 和聊天( chart )业务等。 且这些业务对传输时延和误码率 的要求可能不同 ,从而对传输模式的要求也就不同。 例如,对于时延敏感, 且误码率要求较低的业务,更适合使用非确认( UM )模式来完成传输;对 于时延要求不高,但误码率敏感的业务,更适合使用确认( AM )模式来完 成传输。
当这些不同传输模式要求的业务被被映射在同一 RB中时,现有的 L2 协议无法对这些业务在传输模式上进行差异化处理,导致不同传输要求的 业务映射于同一承载时的 QoS问题,用户体验不佳,以及本应采用 UM而 实际采用了 AM模式的情况下,基站处理资源上产生了浪费。 例如, 图 2 中对应于 RB1的两个 PDCP PDU会被传送给同一个 RLC实体进行处理。 如果这两个 PDCP PDU对应于不同的业务类型,且对传输模式的要求不同 , 例如一个是对于时延敏感,且误码率要求较低的业务(例如, Skype 类的 VOIP 业务或实时网络视频业务);一个是对于时延要求不高,但误码率敏 感的业务(例如, e-mail业务 )o此时,RLC实体无法对这两类业务的 PDCP PDU进行差异化处理。
而采用以上实施例所提供的技术方案以后, 由于一个逻辑信道可以配 置多个 V-RLC实体,针对同一个 RB的 PDCP PDU可以进行多个独立的 RLC 处理,从而相当于将 RB拆分为虚拟 RB ,实现了对同一承载上不同业务在 传输模式上的差异化处理。
各个 V-RLC实体支持的传输模式为以下传输模式中的一种或多种:确 认模式 ( acknowledgement mode , AM ) ,非确认模式 ( un-acknowledgement mode , UM )和透明模式( transport mode , TM 其中 ,对于时延敏感,且 误码率要求较低的业务,更适合使用非确认模式来完成传输;对于时延要 求不高,但误码率敏感的业务,更适合使用确认模式来完成传输。 具体, 各个虚拟 RLC实体可以在建立时根据业务类型来配置其支持的传输模式。
再如, 引入载波聚合( Carrier Aggregation , CA )技术后,各个分量载 波( Component Carrier , CC )只在 MAC层可见, PDCP层和 RLC层不区 分主载波( Primary Component Carrier ,PCC )ί口辅载 Secondary Component Carrier , SCC ) , 因此,对于某个终端的业务包经过 PDCP处理后,并不立 即开始对其进行 RLC处理,而是等待该终端的各个 CC的 MAC调度结果 来启动 RLC处理,生成 RLC PDU ,而后送 MAC层进行分发给各 CC。 当 各 CC的基带处理位置空间分布不同时,特别是距离较远时,例如,分属于 不同单板(例如, 同一基站下的不同单板,或同一基站下的不同机框下的 单板,或不同基站内的单板), RLC处理前的等待时延以及 PDU的传输时 延较长,难以满足目前对基站的实时性要求。
而采用以上实施例所提供的技术方案以后, 由于一个逻辑信道可以配 置多个 V-RLC实体, 因此,可以对不同的 CC对应的数据可以进行独立的 RLC处理,从而每个 V-RLC实体可以不必等待其它 CC的 MAC调度结果, 而只根据其对应 CC的调度结果启动 RLC处理,使得实时性要求得到满足。
另外,由于各个 CC在 MAC层可见,在 CA的场景下,可以将不同的 业务流交由不同的 CC来处理,从而满足上一个场景中对同一个 RB中不同 类型业务数据的差异化处理要求。 此时, 由于 MAC层可以区分各个 CC , 也可以理解为 MAC实体是针对每个 CC独立存在的 , 因此,可以不引入 V-LCID ,也就是说 MAC层相对于现有技术也不需要做任何改变,接收端 可以直接通过各个 MAC实体将数据到正确的 V-RLC、 RLC和 PDCP实体。
以图 16所示的场景为例,当终端接入后,基站可以将不同业务报文分 发到不同的 CC完成传输。例如,将 VOIP等实时要求较高的数据流(报文) 从 PDCP分发到某个对应的 V-RLC实体,使用 RLC UM模式进行传输;将 e-mail等对误码率较高的数据流从 PDCP分发到另一个 V-RLC实体,使用 RLC AM模式进行传输。
以上方法和装置可以适用于跨板 CA ,即 CC跨基带板部署;也可以适 用于不跨板的 CA,即 CC部署在同一个基带板上。当应用于在跨板 CA时, 处理对板间或站间带宽和处理速度的要求大为降低, 因为基站的 PDCP在 生成 PDCP PDU之后,就可以立刻将报文发往各 V-RLC实体缓存起来等待 调度,而无需等待每个 CC对应的调度完成,返回调度结果后在进行 RLC 协议处理。 另外, VOIP及其他实时业务流的业务实时性得到了有效保证。
另外,在非 CA场景下的单个小区内 ,某个 RB也可虚拟出 UM和 AM 两种 RLC工作模式的业务流,其中 UM用于实时业务(如 VOIP或实时视 频)的传输, AM用于对误码率较高的业务(如普通的 TCP业务)的传输 等。
在以上实施例中个 V-RLC实体可以通过发送端与接收端进行协商而建 立,例如,基站和终端对此发起并完成协商。
协商发起的时机可选择任意合理的时刻,比如,在业务差异化场景下, 当 VOIP或实时视频业务出现时,可触发协商流程,建立虚拟 RLC实体; 也可在任何时刻删除该虚拟 RLC实体,或改变虚拟 RLC实体的协议参数。 再如,在 CA场景下,当 UE新增了一个辅小区( SCell ) ,且这个 SCell由 主小区( PCell )所在单板之外的另一块单板提供时,可触发协商流程;也 可以在某个虚拟 RLC实体性能不佳时,删除该虚拟 RLC实体,或者改变该 RLC实体的参数。
协商流程可以分为终端能力获取流程(流程一)和虚拟 RLC实体管理
(流程一 )流程:
流程一:在初始接入时终端向基站上报终端能力(是否支持虚拟 RLC , 支持哪种方案 __比如支持前文的方案一还是方案二,或者两个方案都支 持) b 或者,基站在需要时向终端发起能力查询。 此流程可借用现有终端能 力上报、 查询流程,在终端能力信元中增加虚拟 RLC能力相关信息,例如 增加" 终端支持 V-LCID方案一( Schemel )' 和" 终端支持 V-LCID方案二 ( Scheme2 )' 两个能力指示标志,也可以仅使用一个标志,表示终端同时 支持两种 V-LCID方案。
流程二:在基站和终端建立、修改或删除虚拟 RLC实体。即,明确 LCID 与 V-LCID的绑定关系、 明确 V-LCID的方案选择。此流程可借用现行无线 资源控制( radio resource control , RRC )重配流程。 虚拟 RLC实体建立之 后,基站和终端均可以设置标志,表示某承载有虚拟 RLC实体。
需要说明的是,以上各个单元或实体可以以硬件的形式独立于基站或 终端的处理器单独设置,例如,设置形式可以是微处理器的形式,且可以 单独设置,也可以部分或全部集成在一起设置。 此外,以上各个单元或实 体也可以以硬件形式内嵌于基站或终端的某个处理器中 ,还可以以软件形 式存储于基站或终端的某个存储器中 ,以便于基站或终端的相应处理器调 用该软件执行以上各个单元或实体对应的操作。 以上处理器可以为中央处 理单元( CPU 微处理器、 单片机等。
请继续参考图 17 ,其为本发明实施例提供的一种基站的结构示意图。 如图 17所示,该基站 170包括包括发射机 172、 接收机 171、 存储器 173 以及分别与发射机 172、接收机 171和存储器 173连接的处理器 174。当然, 基站还可以包括天线、 基带处理部件、 中射频处理部件、 输入输出装置等 通用部件,本发明实施例在此不再任何限制。 此外,发射机 172和接收机 171可以集成在一起构成收发机。
其中 ,存储器中存储一组程序代码,且处理器 174用于调用存储器 173 中存储的程序代码,用于执行以上方法实施例任一项所述的数据处理方法。 例如,当该基站 170为发送端时,用于执行以上图 10、 图 11或图 12对应 实施例的方法。 当该基站为接收端时,用于执行以上图 13或图 14对应实 施例的方法。
请继续参考图 18 ,其为本发明实施例提供的一种终端的结构示意图。 如图 18所示,该终端 180包括包括发射机 182、 接收机 181、 存储器 183 以及分别与发射机 182、接收机 181和存储器 183连接的处理器 184。当然, 终端还可以包括天线、 基带处理部件、 中射频处理部件、 输入输出装置等 通用部件,本发明实施例在此不再任何限制。 此外,发射机 182和接收机 181可以集成在一起构成收发机。 其中 ,存储器中存储一组程序代码,且处理器 184用于调用存储器 183 中存储的程序代码 ,用于执行以上方法实施例任一项所述的数据处理方 法。 例如,当该终端 180为发送端时,用于执行以上图 10、 图 11或图 12 对应实施例的方法。 当该终端为接收端时,用于执行以上图 13或图 14对 应实施例的方法。
通过以上的实施方式的描述,所属领域的技术人员可以清楚地了解到 本发明可以用硬件实现,或固件实现,或它们的组合方式来实现。 当使用 软件实现时,可以将上述功能存储在计算机可读介质中或作为计算机可读 介质上的一个或多个指令或代码进行传输。 计算机可读介质包括计算机存 储介质和通信介质,其中通信介质包括便于从一个地方向另一个地方传送 计算机程序的任何介质。存储介质可以是计算机能够存取的任何可用介质。 以此为例但不限于:计算机可读介质可以包括 RAM、 ROM, EEPROM, CD-ROM或其他光盘存储、 磁盘存储介质或者其他磁存储设备、 或者能够 用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算 机存取的任何其他介质。 此外。 任何连接可以适当的成为计算机可读介质。 例如,如果软件是使用同轴电缆、 光纤光缆、 双绞线、 数字用户线( DSL ) 或者诸如红外线、 无线电和微波之类的无线技术从网站、 服务器或者其他 远程源传输的,那么同轴电缆、 光纤光缆、 双绞线、 DSL或者诸如红外线、 无线和微波之类的无线技术包括在所属介质的定影中。 如本发明所使用的 , 盘( Disk )和碟( disc )包括压缩光碟( CD )、 激光碟、 光碟、 数字通用光 碟( DVD )、 软盘和蓝光光碟,其中盘通常磁性的复制数据,而碟则用激 光来光学的复制数据。 上面的组合也应当包括在计算机可读介质的保护范 围之内。
总之,以上所述仅为本发明技术方案的较佳实施例而已,并非用于限 定本发明的保护范围。 凡在本发明的原则之内 ,所作的任何修改、 等同替 换、 改进等,均应包含在本发明的保护范围之内。

Claims

权利要求
1、 一种数据处理装置,其特征在于,包括报文汇聚协议 PDCP单元、 无线链路控制 RLC单元和媒体接入控制 MAC单元,所述 RLC单元包括: 多个彼此独立的 RLC子单元,对应于同一逻辑信道,其中 : 当所述装置位于发送端时,每个 RLC子单元用于将所述 PDCP单元 传送给该 RLC子单元的 PDCP协议数据单元 PDU转换为 RLC PDU,传送 给所述 MAC单元,且所述 PDCP单元传送给所述多个 RLC子单元的 PDCP
PDU对应于同一无线承载 RB;或
当所述装置位于接收端时,所述每个 RLC子单元用于将所述 MAC单 元传送给该 RLC子单元的 MAC业务数据单元 SDU转换为 RLC SDU,传 送给所述 PDCP单元。
2、 根据权利要求 1所述的装置,其特征在于,所述多个 RLC子单元 的配置参数彼此独立。
3、 根据权利要求 1或 2所述的装置,其特征在于, 当所述装置位于 发送端时,所述 MAC单元用于:
为每个 RLC子单元传送的 RLC PDU配置相应的 MAC子头,且每个 MAC子头包括虚拟逻辑信道标识 V-LCID ,该 V-LCID用于标识该 MAC 子头所关联的 RLC PDU所来自的 RLC子单元。
4、 根据权利要求 1至 3任一项所述的装置,其特征在于, 当所述装 置位于接收端时,所述 MAC单元用于:
接收对端设备发送的 MAC PDU所述 MAC PDU包括 MAC头和 MAC 负载,所述 MAC负载包括至少一个对端 RLC PDU ,所述 MAC头包括至 少一个 MAC子头,分别对应于所述至少一个对端 RLC PDU ,其中 ,所述 对端 RLC PDU中包括第一对端 RLC PDU ,该第一对端 RLC PDU对应的 MAC子头包括 V-LCID ,该 V-LCID用于标识所述多个 RLC子单元之一; 将接收的 MAC PDU转换为所述至少一个对端 RLC PDU;
将所述第一对端 RLC PDU传送至所述 V-LCID所标识的 RLC子单元。
5、 根据权利要求 3或 4所述的装置,其特征在于,所述 V-LCID是通 过 MAC子头的预留位形成的 ;或者是通过预留的 LCID形成的。
6、 根据权利要求 1至 5任一项所述的装置,其特征在于, 当所述装 置位于发送端时,该装置还包括:
分发单元,用于将所述来自 PDCP单元的、 对应于同一 RB的 PDCP PDU ,分发给所述多个 RLC子单元。
7、 根据权利要求 6所述的装置,其特征在于,所述分发单元具体用 于:
按每个 PDCP PDU对应的业务类型,将每个 PDCP PDU分发给所述多 个 RLC子单元中适应于该业务类型数据传输的 RLC子单元;或者,
以轮询的方式将所述来自 PDCP单元的、对应于同一 RB的 PDCP PDU 分发给所述多个 RLC子单元。
8、 一种数据处理方法,其特征在于,应用于发送端设备中的无线链 路控制 RLC层,所述 RLC层包括多个彼此独立的 RLC子单元,且所述多 个 RLC子单元对应于同一逻辑信道,该方法包括:
每个 RLC子单元接收所述发送端设备中的报文汇聚协议 PDCP层传 送给该 RLC子单元的 PDCP协议数据单元 PDU ,其中 ,所述 PDCP层传 送给所述多个 RLC子单元的 PDCP PDU对应于同一无线承载 RB;
每个 RLC子单元将所接收到的 PDCP PDU转换为 RLC PDU ,传送给 所述发送端设备中的媒体接入控制 MAC层。
9、 根据权利要求 8所述的方法,其特征在于,所述多个 RLC子单元 的配置参数彼此独立。
10、 根据权利要求 8或 9所述的方法,其特征在于,还包括: 所述 MAC层为每个 RLC子单元传送的 RLC PDU配置相应的 MAC 子头,且每个 MAC子头包括虚拟逻辑信道标识 V-LCID ,该 V-LCID用于 标识该 MAC子头所关联的 RLC PDU所来自的 RLC子单元。
11、 根据权利要求 10所述的方法,其特征在于,所述 V-LCID是通过 MAC子头的预留位形成的 ;或者是通过预留的 LCID形成的。
12、根据权利要求 8至 11任一项所述的方法,其特征在于,每个 RLC 子单元接收所述发送端设备中的 PDCP层传送给该 RLC子单元的 PDCP PDU之前,还包括:
所述 PDCP层生成所述对应于同一 RB的 PDCP PDU;
将所述对应于同一 RB的 PDCP PDU分发给所述多个 RLC子单元。
13、 根据权利要求 12所述的方法,其特征在于,将所述对应于同一 RB的 PDCP PDU分发给所述多个 RLC子单元,包括:
按每个 PDCP PDU对应的业务类型,将每个 PDCP PDU分发给所述 多个 RLC子单元中适应于该业务类型数据传输的 RLC子单元;或者, 以轮询的方式将所述对应于同一 RB的 PDCP PDU分发给所述多个 RLC子单元。
14、 一种数据处理方法,其特征在于,应用于接收端设备中的无线链 路控制 RLC层,所述 RLC层包括多个彼此独立的 RLC子单元,且所述多 个 RLC子单元对应于同一逻辑信道,包括:
每个 RLC子单元接收所述接收端设备中的媒体接入控制 MAC层传送 给该 RLC子单元的 MAC SDU;
每个 RLC子单元将所接收的 MAC SDU转换为 RLC SDU ,传送给所 述接收端设备中的报文汇聚协议 PDCP层。
15、 根据权利要求 14所述的方法,其特征在于,所述多个 RLC子单 元的配置参数彼此独立。
16、 根据权利要求 14或 15所述的方法,其特征在于,每个 RLC子 单元接收所述接收端设备中的 MAC层传送给该 RLC子单元的 MAC SDU 之前,还包括:
所述接收端设备中的 MAC层接收对端设备发送的 MAC PDU ,所述 MAC PDU包括 MAC头和 MAC负载,所述 MAC负载包括至少一个对端 RLC PDU ,所述 MAC头包括至少一个 MAC子头,分别对应于所述至少 一个对端 RLC PDU其中 所述对端 RLC PDU中包括第一对端 RLC PDU , 该第一对端 RLC PDU对应的 MAC子头包括虚拟逻辑信道标识 V-LCID , 该 V-LCID用于标识所述多个 RLC子单元之一;
所述 MAC层将所接收的 MAC PDU转换为所述至少一个对端 RLC PDU;
所述 MAC层将所述第一对端 RLC PDU传送至所述 V-LCID所标识的 RLC子单元。
17、 根据权利要求 16所述的方法,其特征在于,所述 V-LCID是通过 MAC子头的预留位形成的 ;或者是通过预留的 LCID形成的。
18、 一种计算机程序产品 ,包括计算机可读介质,所述计算机可读介 质包括一组程序代码,用于执行如权利要求 8-13中任意一项所述的方法。
19、 一种计算机程序产品 ,包括计算机可读介质,所述计算机可读介 质包括一组程序代码,用于执行如权利要求 14-17中任意一项所述的方法。
PCT/CN2013/079357 2013-07-15 2013-07-15 数据处理装置和方法 WO2015006896A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2013/079357 WO2015006896A1 (zh) 2013-07-15 2013-07-15 数据处理装置和方法
CN201380002316.8A CN103782569B (zh) 2013-07-15 2013-07-15 数据处理装置和方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2013/079357 WO2015006896A1 (zh) 2013-07-15 2013-07-15 数据处理装置和方法

Publications (1)

Publication Number Publication Date
WO2015006896A1 true WO2015006896A1 (zh) 2015-01-22

Family

ID=50573012

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/079357 WO2015006896A1 (zh) 2013-07-15 2013-07-15 数据处理装置和方法

Country Status (2)

Country Link
CN (1) CN103782569B (zh)
WO (1) WO2015006896A1 (zh)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9755726B2 (en) * 2014-04-21 2017-09-05 Alcatel Lucent Method and apparatus for improved multi-carrier communication
CN106469168B (zh) * 2015-08-19 2019-11-26 阿里巴巴集团控股有限公司 数据集成系统中多类型数据处理的方法及装置
CN105246106B (zh) * 2015-09-02 2019-02-12 北京星河亮点技术股份有限公司 Lte-a终端测试仪表在载波聚合下mac层数据调度方法
CN107426776A (zh) * 2016-05-24 2017-12-01 华为技术有限公司 QoS控制方法及设备
CN107809771B (zh) * 2016-09-08 2021-08-06 中国移动通信有限公司研究院 数据传输方法、c-rlc实体、d-rlc实体及小区间mac实体
CN108282248B (zh) * 2017-01-05 2020-11-27 电信科学技术研究院 一种数据传输方法、网络侧设备及用户设备
MX2019008381A (es) 2017-01-13 2019-09-09 Samsung Electronics Co Ltd Metodo y dispositivo para transmitir un paquete de datos en un sistema de comunicacion inalambrica.
CN108809563B (zh) * 2017-05-03 2021-01-01 普天信息技术有限公司 一种业务数据预处理方法和系统
RU2740161C1 (ru) 2017-06-16 2021-01-12 Гуандун Оппо Мобайл Телекоммьюникейшнс Корп., Лтд. Способ передачи данных, оконечное устройство и сетевое устройство
WO2019024105A1 (zh) 2017-08-04 2019-02-07 Oppo广东移动通信有限公司 支持数据重复的方法、发射端设备和接收端设备
US10531359B2 (en) * 2017-08-10 2020-01-07 Htc Corporation Device and method for handling a packet data convergence protocol operation
CN109547168B (zh) * 2017-09-21 2021-07-20 华为技术有限公司 数据传输方法、终端设备和网络设备
CN109691170A (zh) * 2017-12-28 2019-04-26 Oppo广东移动通信有限公司 传输数据的方法和终端设备
CN109996261B (zh) * 2018-12-30 2021-04-09 北京邮电大学 基于mac层数据包复制的数据传输方法及装置
CN113841441B (zh) * 2021-03-23 2022-11-18 华为技术有限公司 一种通信方法与装置
CN116506893A (zh) * 2022-01-18 2023-07-28 中国移动通信有限公司研究院 一种数据传输方法及网络设备
CN115997464A (zh) * 2022-10-28 2023-04-21 北京小米移动软件有限公司 一种传输配置信息的方法、装置及可读存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101867871A (zh) * 2009-04-17 2010-10-20 大唐移动通信设备有限公司 一种选择逻辑信道进行数据处理的方法、系统和设备
CN101932128A (zh) * 2009-06-25 2010-12-29 大唐移动通信设备有限公司 一种数据链路层的数据收发处理方法及设备
CN102098725A (zh) * 2009-12-15 2011-06-15 中兴通讯股份有限公司 一种服务网关与中继终端间传输数据的系统及方法
US20120250631A1 (en) * 2011-03-31 2012-10-04 Renesas Mobile Corporation Multiplexing Logical Channels in Mixed Licensed and Unlicensed Spectrum Carrier Aggregation
CN102958102A (zh) * 2011-08-22 2013-03-06 中兴通讯股份有限公司 一种rlc分流传输方法及系统
CN103201977A (zh) * 2010-11-08 2013-07-10 高通股份有限公司 用于使用多链路pdcp 子层进行多点hsdpa 通信的系统和方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101867871A (zh) * 2009-04-17 2010-10-20 大唐移动通信设备有限公司 一种选择逻辑信道进行数据处理的方法、系统和设备
CN101932128A (zh) * 2009-06-25 2010-12-29 大唐移动通信设备有限公司 一种数据链路层的数据收发处理方法及设备
CN102098725A (zh) * 2009-12-15 2011-06-15 中兴通讯股份有限公司 一种服务网关与中继终端间传输数据的系统及方法
CN103201977A (zh) * 2010-11-08 2013-07-10 高通股份有限公司 用于使用多链路pdcp 子层进行多点hsdpa 通信的系统和方法
US20120250631A1 (en) * 2011-03-31 2012-10-04 Renesas Mobile Corporation Multiplexing Logical Channels in Mixed Licensed and Unlicensed Spectrum Carrier Aggregation
CN102958102A (zh) * 2011-08-22 2013-03-06 中兴通讯股份有限公司 一种rlc分流传输方法及系统

Also Published As

Publication number Publication date
CN103782569A (zh) 2014-05-07
CN103782569B (zh) 2016-09-28

Similar Documents

Publication Publication Date Title
WO2015006896A1 (zh) 数据处理装置和方法
US20210219105A1 (en) Communications method and apparatus
WO2018130034A1 (zh) 数据处理方法、装置和系统
US8437291B2 (en) Method for configuring different data block formats for downlink and uplink
EP2130387B1 (en) Cross-layer error recovery optimisation in wireless systems
JP6687750B2 (ja) データユニットを送信する方法及び装置
KR101216100B1 (ko) 단편화 패킹 확장헤더를 수반하는 mac pdu를 전송하는 방법 및 장치
US10735334B2 (en) Data sending method, data receiving method, and related device
CN111757513B (zh) 通信方法及设备
TWI657708B (zh) 用於新型無線電系統的分段與級聯方法及使用者設備
US8619760B2 (en) Method of providing circuit switched (SC) service using high-speed downlink packet access (HSDPA) or high-speed uplink packet access (HSUPA)
US20190230682A1 (en) Data transmission method, apparatus, and system
US20120033563A1 (en) Packet classification and prioritization using an ip header in a mobile wireless device
WO2019149248A1 (zh) 通信的方法和装置
WO2014026370A1 (zh) 数据传输方法及装置
JP2019516319A (ja) データユニットを受信する方法及び装置
TWI513258B (zh) 交織音頻和視頻資料包
WO2013152743A1 (zh) 传输信号的方法和装置
WO2010108353A1 (zh) Pdu的发送/接收方法和装置
WO2013155846A1 (zh) 数据分流配置方法、基站系统和用户终端
WO2016161594A1 (zh) 一种数据传输的方法及装置
US8942104B2 (en) Packet classification and prioritization using a UDP checksum in a mobile wireless device
KR20190075111A (ko) 5g nr 통신 시스템 내의 비대칭 업-링크/다운-링크 프로토콜 스택 및 프레임 구조를 위한 방법 및 장치
WO2010102453A1 (zh) 提高中继网络系统性能的方法、通信系统及协议实体
US20220368782A1 (en) Baseband chip and method for layer 2 downlink data processing

Legal Events

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

Ref document number: 13889417

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

Country of ref document: EP

Kind code of ref document: A1