WO2021042089A2

WO2021042089A2 - Packet processing in downlink

Info

Publication number: WO2021042089A2
Application number: PCT/US2020/062386
Authority: WO
Inventors: Tianan MA; Jianzhou Li; Su-Lin Low; Hausting Hong; Chun-I Lee; Xiaoshu Qian; Jian Gu; Chenxi Wang; Hong Kui Yang
Original assignee: Zeku Inc
Current assignee: Zeku Inc
Priority date: 2020-11-25
Filing date: 2020-11-25
Publication date: 2021-03-04
Anticipated expiration: 2023-05-25
Also published as: WO2021042089A8; WO2021042089A3

Abstract

Embodiments of apparatus and method for downlink data processing are disclosed. In an example, a method for downlink data processing can include receiving, at a physical layer of a protocol stack, a code block group belonging to a transport block. The transport block can be composed of a plurality of code block groups including the code block group. The method can further include passing the code block group from the physical layer to a higher layer of processing in the protocol stack without waiting for a determination that the transport block was completely received or a confirmation that the transport block was correctly received or both.

Description

PACKET PROCESSING IN DOWNLINK

BACKGROUND

[0001] Embodiments of the present disclosure relate to apparatuses and methods for wireless communication.

[0002] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. In cellular communication, such as the 4th-generation (4G) Long Term Evolution (LTE) and the 5th- generation (5G) New Radio (NR), the 3rd Generation Partnership Project (3GPP) defines a protocol stack that includes a set of layers collectively referred to as layer 2: a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, and a Medium Access Control (MAC), from higher to lower in the stack. These lie above the physical layer (PHY) in the stack. PHY is also referred to as layer 1.

SUMMARY

[0003] Embodiments of apparatus and method for downlink data processing are disclosed herein.

[0004] In one example, a method can include receiving, at a physical layer of a protocol stack, a code block group belonging to a transport block (TB). The transport block can be composed of a plurality of code block groups including the code block group. The method can also include passing the code block group from the physical layer to a higher layer of processing in the protocol stack without waiting for a determination that the transport block was completely received or a confirmation that the transport block was correctly received or both.

[0005] In another example, a baseband chip includes a layer 2 circuitry implementing a protocol stack that includes a plurality of layers configured to process data packets. The layers can also be referred to as levels. The baseband chip can include physical layer circuitry implementing a physical layer of the protocol stack. The physical layer circuitry can be configured to receive a code block group belonging to a transport block. The transport block can be composed of a plurality of code block groups including the code block group. The physical layer circuitry can be further configured to pass the code block group from the physical layer to circuitry implementing a higher layer of the plurality of layers of the protocol stack without waiting for a determination that the transport block was completely received or a confirmation that the transport block was correctly received or both.

[0006] In a further example, an apparatus for data processing can include circuitry implementing a physical layer and configured to receive a code block group. The apparatus can also include circuitry implementing a medium access control layer and operatively connected to the circuitry implementing the physical layer. The circuitry implementing the physical layer can be further configured to pass the code block group to the circuitry implementing the medium access control layer without waiting for a determination that a transport block comprising the code block group was completely received or a confirmation that the transport block was correctly received or both.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, further serve to explain the principles of the present disclosure and to enable a person skilled in the pertinent art to make and use the present disclosure.

[0008] FIG. 1 illustrates an architecture and data flows in the architecture, according to certain embodiments of the present disclosure.

[0009] FIG. 2 illustrates a transport block holding buffer for the MAC layer, according to certain embodiments of the present disclosure.

[0010] FIG. 3A illustrates a TB holding buffer for data packets for the RLC layer, according to certain embodiments of the present disclosure.

[0011] FIG. 3B illustrates a TB holding buffer for control packets for the RLC layer, according to certain embodiments of the present disclosure.

[0012] FIG. 4A illustrates a TB holding buffer for data packets for the PDCP layer, according to certain embodiments of the present disclosure.

[0013] FIG. 4B illustrates a TB holding buffer for control packets for the PDCP layer, according to certain embodiments of the present disclosure.

[0014] FIG. 5 illustrates a detailed block diagram of an exemplary baseband chip implementing Layer 2 downlink data processing using Layer 2 circuits, according to some embodiments of the present disclosure. [0015] FIG. 6 illustrates a method for data processing, according to certain embodiments of the present disclosure.

[0016] FIG. 7 illustrates an example node, in which some aspects of the present disclosure may be implemented, according to some embodiments of the present disclosure.

[0017] FIG. 8 illustrates a block diagram of an apparatus including a baseband chip, a radio frequency chip, and a host chip, according to some embodiments of the present disclosure.

[0018] FIG. 9 illustrates an example wireless network, in which some aspects of the present disclosure may be implemented, according to some embodiments of the present disclosure.

[0019] Embodiments of the present disclosure will be described with reference to the accompanying drawings.

DETAILED DESCRIPTION

[0020] Although specific configurations and arrangements are discussed, it should be understood that this is done for illustrative purposes only. A person skilled in the pertinent art will recognize that other configurations and arrangements can be used without departing from the spirit and scope of the present disclosure. It will be apparent to a person skilled in the pertinent art that the present disclosure can also be employed in a variety of other applications.

[0021] It is noted that references in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” “some embodiments,” “certain embodiments,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of a person skilled in the pertinent art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0022] In general, terminology may be understood at least in part from usage in context.

For example, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0023] Various aspects of wireless communication systems will now be described with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, units, components, circuits, steps, operations, processes, algorithms, etc. (collectively referred to as “elements”). These elements may be implemented using electronic hardware, firmware, computer software, or any combination thereof. Whether such elements are implemented as hardware, firmware, or software depends upon the particular application and design constraints imposed on the overall system.

[0024] The techniques described herein may be used for various wireless communication networks, such as code division multiple access (CDMA) system, time division multiple access (TDMA) system, frequency division multiple access (FDMA) system, orthogonal frequency division multiple access (OFDMA) system, single-carrier frequency division multiple access (SC- FDMA) system, and other networks. The terms “network” and “system” are often used interchangeably. A CDMA network may implement a radio access technology (RAT), such as Universal Terrestrial Radio Access (UTRA), evolved UTRA (E-UTRA), CDMA 2000, etc. A TDMA network may implement a RAT, such as GSM. An OFDMA network may implement a RAT, such as LTE or NR. The techniques described herein may be used for the wireless networks and RATs mentioned above, as well as other wireless networks and RATs.

[0025] Layer 2 data processing, for example, processing the transport blocks received from

Layer 1 in the downlink user plane, is usually implemented using software modules executed on a generic baseband processor, such as a central processing unit (CPU) or a digital signal processor (DSP). During the processing, data needs to be frequency transferred between the generic baseband processor and external memory (e.g., the system memory), for example, for buffering between each layer. As a result of such transfers, such solutions for Layer 2 data processing suffer from high power consumption, large data buffer, and long process delays.

[0026] For example, code block group (CBG) based hybrid automatic repeat request

(HARQ) re-transmission is one aspect of fifth-generation (5G) new radio (NR) technology. With this technology, transport blocks can be broken up into code block groups. HARQ re-transmission can be done at smaller CBG level granularity. This technology greatly improved spectrum efficiency in 5G NR.

[0027] When CBGs of a transport block (TB) arrive, a PHY decoder will wait until all

CBGs or code blocks (CBs) are received before sending them to the MAC layer. The PHY decoder will, while waiting, store CBGs or CBs into double data rate memory (DDR)or any other suitable types of memory device. The MAC layer will then read the CBG or CB out from the DDR or another device. The MAC layer processes the received packet in one shot after the entire TB is received.

[0028] The approach described above may have high DDR bandwidth (BW) requirements and not just higher power consumption. Such an approach may incur power to save and read back data to/from the intermediate memory. The higher DDR BW may be a bottleneck in a practical downlink (DL) receiving system.

[0029] Additionally, the above approach may have large data delays and long processing delays because of the need to wait for all CBs to be received. Furthermore, the above approach may rely on extra memory space being used to store CBs received. Additionally, the above approach may cause burst and delay in L2 processing, for example, when all CBs/packets of an entire high throughput TB are released for L2 processing. Moreover, the above approach may incur large unwanted on-chip/static random access memory (SRAM) memory for intermediate storage of CBs, if DDR is not used.

[0030] To take advantage of the advanced technology provided in NR, MAC may need to accept and process the CBGs that have already been successfully received without waiting for the entire transport block. To do such fast processing, the MAC layer may start to process CBs before the TB is completely received. This early processing may eliminate the need for PHY layer to store the successfully decoded CBs in memory. Thus, memory access and memory space used may be significantly reduced.

[0031] Certain embodiments may rely on a process with two aspects. According to a first aspect, early processing can be performed immediately, and the processed data packets may be temporarily held in a holding buffer. According to a second aspect, when the entire TB is declared successfully received, the already processed packets may be released.

[0032] This approach may permit early preprocessing of received CBs without having to store them to memory, such as an external memory. The second aspect of committing the early preprocesses and finalizing received status variable updates may be performed sooner than if the processing could only begin upon confirmation that the TB is successfully received.

[0033] Thus, in certain embodiments, no data packet has to be saved to memory before completing the entire receive packet processing through layer 2. Packet data may be saved only once, namely when it has gone through the entire layer 2 receiving processes. In this way, one round trip memory access can be saved. This may result in significantly lower memory access bandwidth requirement and less memory space requirements when the data rate is very high, as in 5G NR technology.

[0034] The approach according to certain embodiments can be used in high-performance, low-cost, low-power 4G/5G modem DL MAC layer design. The use of the two aspects of certain embodiments may result in reduced DDR BW requirements, reduced power consumption, and reduced processing time.

[0035] Certain embodiments of the present disclosure first process packet data as would normally do to the packet according to 4G/5G DL L2 data path protocols. One step is added to hold the preprocessed packets in TB holding buffer. These buffers contain minimum tracking information for each preprocessed packet. This method uses a TB end signal to indicate a TB complete and a TB cyclic redundancy check (CRC) valid signal to indicate successful reception of the entire TB. Once the TB CRC valid is received at the end of the TB, packets held in the TB holding buffer is committed to the receiving queue. DL receive status variables are then updated with the release packet information.

[0036] FIG. 1 illustrates an architecture and data flows in the architecture, according to certain embodiments of the present disclosure. In an approach that does not take advantage of the above-described aspects, data received at physical layer 101 may, at operation 110, first be stored in DDR 103 (or any other suitable types of memory device) using a DDR controller 105 (or any other suitable types of memory device controller). DDR 103 and DDR controller 105 may be an example of external memory 506 in FIG. 5. The physical layer is not shown in FIG. 5, but the MAC-PHY interface (I/F) 530 may serve to interface with the physical layer.

[0037] As shown in FIG. 1, at operation 120, after the entire transport block has been received, the data may be read back to MAC layer 107, via a MAC CB buffer control 109, which can place the data into a MAC DL in-line buffer 111. MAC CB buffer control 109 and MAC DL in-line buffer 111 may be implemented by in-line control (CTL) buffer 528 in FIG. 5. MAC layer 107 may be implemented by MAC circuit 526 in FIG. 5. Software implementations of MAC layer 107 are also permitted, though a hardware approach is provided by way of illustration.

[0038] In this approach, the system may rely on direct memory access (DMA) including logically or physically separate PDCP DMA (PDMA), RLC DMA (RDM A), MAC DMA (MDMA), and input DMA (IDMA), which may, in turn, rely on a network on chip (NoC). The NoC may be implemented by main bus 538 in FIG. 5 The DMA may be provided by, for example, a plurality of direct memory access (DMA) channels including a first DMA channel (DMA CHI) 516 and a second DMA channel (DMA CH2) 518, as shown in FIG. 5.

[0039] As shown in FIG. 1, operations 110 and 120, when used with DDR 103, produce one DDR write and one DDR read, respectively. This DDR read/write can require a significant amount of DDR bandwidth in a high data rate communication system, like 5G NR.

[0040] By contrast, in certain embodiments, data received at physical layer 101 may, at operation 130, be passed directly to MAC CB buffer control 109 and from there to MAC DL in line buffer 111, without waiting for confirmation that the entire transport block has been correctly received. In other words, in certain embodiments, the error correction at the CBG is considered reliable enough to permit the processing of the CBGs to proceed at the higher protocol layers. Moreover, certain embodiments of the present disclosure avoid the need for the read/write at operations 110/120, discussed above.

[0041] MAC layer 107 can preprocess received data and produce preprocessed MAC control elements (CEs) and other control protocol data units (PDUs) and put in a MAC TB holding buffer 113. MAC TB holding buffer 113 may be stored in local memory (also known as internal memory), such as local memory 514 in FIG. 5. MAC layer 107 can also extract header information for processing by RLC layer 115. RLC layer 115 may be implemented by RLC circuit 524 in FIG. 5 or by software.

[0042] As shown in FIG. 1, at operation 140, MAC layer 140 can pass the packet (or a descriptor thereof) to RLC layer 115. RLC layer 115 can also preprocess the packet, now in the form of an RLC PDU, and can put packet information in RLC TB holding buffers: RLC data PDU info can be put in a data packet holding buffer 117, and RLC control PDU can be put in an RLC control PDU holding buffers 119. The RLC TB holding buffers may be maintained in local memory 514 in FIG. 5. An RLC re-ordering window 121, which can also be provided in local memory 514, can be used to sort and organize the packets during processing. RLC layer 115 can also extract information for processing by PDCP layer 123 and, at operation 150, pass them to PDCP layer 123. PDCP layer 123 may be implemented by PDCP circuit 522 in FIG. 5 or by software.

[0043] As shown in FIG. 5, at PDCP layer 123, packet data can be read from MAC DL in line buffer 111 and can undergo PDCP preprocesses: de-cipher, integrity check, or header de compressions. After PDCP processes, each processed packet can be stored in DDR 103, and a packet descriptor can also put in re-order queues, for example, in a PDCP re-ordering window 125. PDCP packet info can be temporarily held in PDCP TB holding buffers: PDCP data packets can be held in PDCP data TB holding buffers 127, and PDCP control packets can be held in PDCP TB control holding buffers 129. The PDCP TB holding buffers can be implemented in local memory 514.

[0044] When the entire TB has been received, and TB CRC valid information is received at MAC layer 107, if TB CRC is indicated as being valid, packets held at each layer can be committed to their destination queues, and the layer’s status variable can be updated. For example, at MAC layer 107, upon TB complete and TB CRC valid, MAC CE and other control PDUs can be delivered to a microcontroller by sending their descriptors from MAC hardware (for example, MAC circuit 526 in FIG. 5) to the microcontroller (for example, MCU 510). The microcontroller can then forward the messages to their destination queues.

[0045] At RLC layer 115, upon TB complete and TB CRC valid, RLC may update its receive bitmap (each bit representing a received packet) and segmentation queues (queues listing each segment belonging to the same sequence number (SN)) and associated RLC status variables. RLC layer 115 may also release its control packet(s) by sending their descriptors to the microcontroller.

[0046] At PDCP layer 123, upon TB complete and TB CRC valid, PDCP layer 123 may commit data packets in its holding buffer to update the logic channel re-order bitmaps, PDCP re order window 125 (a sliding interval that may be marked by Win_start (left edge), Win_size, and Win_end(right edge)), as well as parameter and status variables. PDCP layer 123 may also release the control packets held in the holding buffers.

[0047] If TB is completely received, but TB CRC fails, then each layer (MAC layer 107,

RLC layer 115, and PDCP layer 123) may drop all packets held in the TB holding buffers at the layer. In this case, the system may be configured such that nothing will be delivered, and no status variables will be updated. [0048] The approach according to certain embodiments preprocesses received data without having to store them to wait for the entire TB. This approach may offer significant memory (e.g., DDR) bandwidth saving and power saving. It also offers fast processing speed and less processing delays, which is important for low latency applications.

[0049] One alternative approach is that only control packets are held in TB holding buffers at each layer (MAC/RLC/PDCP). Control packets are released only upon verifying TB CRC valid. Data packets are not held, but continue without waiting for TB CRC validation. Cycle intensive packet related functions including de-ciphering, integrity check, and de-compression can be performed, and data packets can be committed regardless of the TB CRC being valid or invalid. This approach may allow a faster data processing speed, and less hardware logic and less hardware area. There is a small probability of TB CRC being in error even if all CB CRCs are correct. Thus, erroneous data packets could possibly be delivered. This low chance of an occasional erroneous data packet may be tolerable for applications, such as live voice and live video. In file transfers, this approach may result in a high layer retransmit request, which may produce a significant duplication of transmission and reception efforts.

[0050] The information that is held in TB holding buffers, by way of examples thereof, is illustrated in FIGs. 2, 3A, 3B, 4A, and 4B.

[0051] FIG. 2 illustrates a TB holding buffer for the MAC layer, according to certain embodiments. At the MAC layer, the entire descriptor of a MAC CE can be held, as control PDUs can be held until the TB is received completely. In FIG. 2, the control packet statutes can each respectively be a descriptor for the control packet.

[0052] FIG. 3A illustrates a TB holding buffer for data packets for the RLC layer, according to certain embodiments. As to information held at the RLC layer for data packets, only RLC SN and logical channel identifier (LCID) may be needed to be held in TB holding buffers until confirmation of TB CRC, in certain embodiments.

[0053] FIG. 3B illustrates a TB holding buffer for control packets for the RLC layer, according to certain embodiments. For RLC control packets, the entire packet descriptor may be held in TB holding buffers, in certain embodiments, just like with MAC control packets.

[0054] FIG. 4A illustrates a TB holding buffer for data packets for the PDCP layer, according to certain embodiments. As to information held at the PDCP layer for data packets, the PDCP SN, the radio bearer identifier (RBID), and the data packet buffer pointer may need to be held in TB holding buffers until confirmation of TB CRC. If TB CRC failed, the buffer containing the data packet can be released back to a buffer manager (BM).

[0055] FIG. 4B illustrates a TB holding buffer for control packets for the PDCP layer, according to certain embodiments. For PDCP control packets, the entire packet descriptor can be held in TB holding buffers until confirmation of TB CRC, just like RLC control packets.

[0056] Certain embodiments may provide various benefits and/or advantages. For example, certain embodiments may have lower power consumption and lower external memory DDR bandwidth requirements. If an external memory device is a DDR, it could be a major power consumption source of the system. Reduced bandwidth requirements on the external memory interface can lead to a reduction of the associated power consumption.

[0057] Reduced requirements on external memory may also reduce system bus and memory interface congestion, better spread out L2 packet processing loading, mitigate peak DDR usage bottleneck, and improve system performance.

[0058] Furthermore, certain embodiments may provide improved data speed due to the elimination of some of the data transfer to and from memory. This approach could reduce processing delays and improve receiving latencies and round-trip latencies.

[0059] If DDR 103 is not used, certain embodiments may reduce or eliminate large on- chip/SRAM memory for intermediate CB storage. Additionally, in certain embodiments, whether or not DDR is used, the L2 state variables may be more up to date, allowing better overall performance for L2 packet decoding including de-ciphering and integrity check.

[0060] FIG. 5 illustrates a detailed block diagram of an exemplary baseband chip 502 implementing Layer 2 downlink data processing using Layer 2 circuits 508 and an MCU 510, according to some embodiments of the present disclosure. In some embodiments, Layer 2 circuits 508 include a service data adaptation protocol (SDAP) circuit 520, a PDCP circuit 522, an RLC circuit 524, and a MAC circuit 526. As explained above, PDCP circuit 522 may correspond to PDCP layer 123 in FIG. 1, and RLC circuit 524 and MAC circuit 526 may similarly correspond to RLC layer 115 and MAC layer 107 in FIG. 1. In some embodiments, each of SDAP, PDCP, RLC, and MAC circuits 520, 522, 524, or 526 is an integrated circuit (IC) dedicated to performing the functions of the respective layer in Layer 2 user plane. For example, each of SDAP, PDCP, RLC, and MAC circuits 520, 522, 524, or 526 may be an application-specific integrated circuit (ASIC), which is customized for a particular use, rather than intended for general-purpose use, and thus, is known for its high speed, small die size, and low power consumption compared with a generic processor.

[0061] Apparatus 500 may be any suitable node of wireless network 900 in FIG. 9, such as user equipment 902 or access node 904 (e.g., a base station including eNB in LTE or gNB in NR). As shown in FIG. 5, apparatus 500 may include baseband chip 502, a host chip 504, an external memory 506, and a main bus 538 (also known as a “system bus”) operatively coupling baseband chip 502, host chip 504, and external memory 506. That is, baseband chip 502, host chip 504, and external memory 506 may exchange data through main bus 538. The baseband chip 502 may implement the method shown in FIG. 6 and the architecture shown in FIG. 1.

[0062] As shown in FIG. 5, baseband chip 502 may also include a plurality of direct memory access (DMA) channels including a first DMA channel (DMA CHI) 516 and a second DMA channel (DMA CH2) 518. Each DMA channel 516 or 518 can allow certain Layer 2 circuits 508 to access external memory 506 directly independent of host chip 504. In some embodiments, DMA channels 516 and 518 may include a DMA controller and any other suitable input/output (I/O) circuits. The plurality of direct memory access (DMA) channels may correspond to PDMA, RDMA, MDMA, and IDMA in FIG. 1. As shown in FIG. 5, baseband chip 502 may further include a local memory 514, such as an on-chip memory on baseband chip 502, which is distinguished from external memory 506 that is an off-chip memory not on baseband chip 502. In some embodiments, local memory 514 includes one or more LI, L2, L3, or L4 caches. Local memory may also include the re-ordering windows and TB holding buffers, as discussed above. Layer 2 circuits 508 may access local memory 514 through main bus 538 as well.

[0063] As shown in FIG. 5, baseband chip 502 may further include a memory 512 that can be shared by (e.g., both accessed by) Layer 2 circuits 508 and MCU 510. It is understood that although memory 512 is shown as an individual memory separate from local memory 514, in some examples, memory 512 and local memory 514 may be local partitions of the same physical memory structure, for example, an SRAM. In some embodiments, memory 512 includes a plurality of command queues 534 for storing a plurality sets of commands, respectively, and a plurality of status queues 536 for storing a plurality sets of result statuses, respectively.

[0064] As shown in FIG. 5, baseband chip 502 may further include a local bus 540. In some embodiments, MCU 510 is operatively coupled to memory 512 and main bus 538 through local bus 540. [0065] Referring to Layer 2 circuits 508, Layer 2 circuits 508 may be configured to receive

Layer 1 transport blocks (as the inputs of Layer 2 circuits 508) and generate Layer 3 data packets (as the outputs of Layer 2 circuits 508) from the Layer 1 transport blocks in an in-line manner. In some embodiments, Layer 2 circuits 508 are configured to pass data through each layer of Layer 2 circuits 508 without storing the data in external memory 506. The data may flow from lower to upper layers in Layer 2 (e.g., MAC circuit 526, RLC circuit 524, and PDCP circuit 522).

[0066] As shown in FIG. 5, MAC-PHY interface 530 may be operatively coupled to in line control buffer 528 and configured to receive the Layer 1 transport blocks from Layer 1 (e.g., the PHY layer). The operations of MAC-PHY interface 530 may be controlled based on a set of interface commands from MCU 510. In some embodiment, MCU 510 is configured to generate a set of interface commands and store/write the set of interface commands into an interface command queue 534 in memory 512, such that MAC-PHY interface 530 retrieves/reads the set of interface commands from interface command queue 534 according to the priorities assigned by MCU 510 to the interface commands. Each Layer 1 transport block may contain data from the previous radio subframe, having multiple or partial packets, depending on scheduling and modulation. Each Layer 1 transport block may correspond to a MAC PDU and include a payload (e.g., having encrypted data) and multiple headers (e.g., MAC header, RLC header, and PDCP header).

[0067] In some embodiments, each Layer 1 transport block is divided into a plurality of code blocks (CBs), and MAC-PHY interface 530 receives the Layer 1 transport blocks in the unit of each code block through code block-related signals, such as CB_DATA indicative of the data values of a code block, CB_START indicative of the start of a new code block, CB_LENGHT indicative of the length of the code block, and CB_INDEX indicative of the order number of the code block in the received transport block. MAC-PHY interface 530 may also receive status signals, for example, DATA_READY indicative of a valid cycle of received packet data and TB_ID indicative of the index of the transport block. In some embodiments, the interface control commands from MCU 510 are generated based at least in part on one or more of the signals received by MAC-PHY interface 530. MAC-PHY interface 530 may be further configured to obtain the processing result, for example, once the MAC-PHY interface processing is completed, halted, or interrupted, and store a set of result statuses indicative of the processing result into an interface status queue 536 in memory 512. For example, each Layer 1 transport block of each code block of a transport block received by MAC-PHY interface 530 may cause a trigger to MCU 510 to start control SDAP circuit 520, PDCP circuit 522, RLC circuit 524, and/or MAC circuit 526 to perform the corresponding Layer 2 downlink data process function.

[0068] As shown in FIG. 5, in-line control buffer 528 may be operatively coupled to MAC-

PHY interface 530 and configured store the Layer 1 transport blocks received by MAC-PHY interface 530. In-line control buffer 528 may be a separate physical memory component or part of local memory 514 (e.g., a logical partition thereof) dedicated to Layer 2 downlink data processing. In some embodiments, in-line control buffer 528 is further configured to buffer the Layer 1 transport blocks to be adapted to Layer 1 data rate, for example, when the Layer 1 data rate exceeds the peak Layer 2 downlink data processing capability of baseband chip 502. Layer 2 circuits 508 in baseband chip 502 may perform Layer 2 downlink data processing in an in-line manner without access to external memory 506. In order to adapt to the higher Layer 1 data rate, in-line control buffer 528 may perform the MAC-PHY flow control function by buffering the Layer 1 transport blocks. It is understood that in some examples, second DMA channel 518 operatively coupled to in-line control buffer 528 and MAC-PHY interface 530 may be configured to transmit some of the Layer 1 transport blocks from in-line control buffer 528 or directly through MAC-PHY interface 530 to external memory 506 to overflow the Layer 1 transport blocks when the capacity of in-line control buffer 528 is overloaded, for example, by an extremely high Layer 1 data rate.

[0069] Besides Layer 1 data rate adaptation, in-line control buffer 528 can be used for code block re-organization as well when the received code blocks are not in order. Moreover, as described below in detail, the payload and headers of each Layer 1 transport block can be processed separately to reduce the workload and power consumption of baseband chip 502. In some embodiments, the payload of a Layer 1 transport block is stored in-line control buffer 528 until the headers of the Layer 1 transport block have been processed by Layer 2 circuits 508 (e.g., MAC circuit 526, RLC circuit 524, and/or PDCP circuit 522).

[0070] As shown in FIG. 5, MAC circuit 526 may be operatively coupled to in-line contr l buffer 528 and RLC circuit 524 and configured to process the MAC headers of the Layer 1 transport blocks stored in in-line control buffer 528. The processing of the MAC headers by MAC circuit 526 may be controlled based on a set of MAC commands from MCU 510. In some embodiment, MCU 510 is configured to retrieve/read the set of interface result statuses (i.e., the result statues from MAC-PHY interface 530) from interface status queue 536, generate the set of MAC commands based on the set of interface result statuses, and store/write the set of MAC commands into a MAC command queue 534 in memory 512, such that MAC circuit 526 can retrieve/read the set of MAC commands from MAC command queue 534 according to the priorities assigned by MCU 510 to the MAC commands. For example, the MAC commands may need to be adjusted based on the processing result at MAC-PHY interface 530, e.g., wait until all the code blocks of the next Layer 1 transport block have been received and organized in order in in-line control buffer 528. In some embodiments, MAC circuit 526 is configured to process only the MAC header, but not the payload of a Layer 1 transport block stored in in-line control buffer 528. For example, MAC circuit 526 may extract the MAC header from the Layer 1 transport block and read only the MAC header, but not the payload, of the Layer 1 transport block. It is understood that in some examples, MAC circuit 526 may extract and read other headers of the Layer 1 transport block as well, such as RLC header and PDCP header. Nevertheless, MAC circuit 526 does not read the payload of the Layer 1 transport block, and does not process other headers, such as RLC header and PDCP headers, according to some embodiments.

[0071] In some embodiments, the functions of MAC circuit 526 in processing the MAC headers are defined by the 3GPP standards. For example, MAC circuit 526 may perform HARQ, MAC downlink mapping, and/or MAC format selection and measurement by processing the MAC headers of the Layer 1 transport blocks, which are extracted and read from in-line control buffer 528. It is understood that in case any update or change being made to the required functions of the MAC Layer, MCU 510 may reflect the update or change in its MAC commands to control MAC circuit 526 to act accordingly. As shown in FIG. 5, MAC circuit 526 may be further configured to obtain the processing result, for example, once the MAC header processing is completed, halted, or interrupted, and store a set of result statuses indicative of the processing result into a MAC status queue 536 in memory 512.

[0072] As shown in FIG. 5, RLC circuit 524 may be operatively coupled to MAC circuit

526 and PDCP circuit 522 and configured to process the RLC headers of the Layer 1 transport blocks received from MAC circuit 526. The processing of the RLC headers may be controlled based on a set of RLC commands from MCU 510. In some embodiment, MCU 510 is configured to retrieve/read the set of MAC result statuses (i.e., the result statues from the lower layer - MAC Layer - in the Layer 2 protocol stack) from MAC status queue 536, generate the set of RLC commands based on the set of MAC result statuses, and store/write the set of RLC commands into an RLC command queue 534 in memory 512, such that RLC circuit 524 can retrieve/read the set of RLC commands from RLC command queue 534 according to the priorities assigned by MCU 510 to the RLC commands. For example, the RLC commands may need to be adjusted based on the processing result at the lower layer, i.e., the MAC layer by MAC circuit 526, e.g., wait until the MAC header of a Layer 1 transport block has been processed and/or the RLC header of the Layer 1 transport block has been extracted and read from in-line control buffer 528 by MAC circuit 526.

[0073] Similar to MAC circuit 526, in some embodiments, RLC circuit 524 can be configured to process only the RLC header, but not the payload of a Layer 1 transport block stored in in-line control buffer 528. For example, MAC circuit 526 may extract and read the MAC and RLC headers of the Layer 1 transport block stored in in-line control buffer 528, and RLC circuit 524 may receive the RLC header from MAC circuit 526. It is understood that in some examples, RLC circuit 524 may extract and read the RLC header of the Layer 1 transport block from in-line control buffer 528 directly. Nevertheless, RLC circuit 524 does not read the payload of the Layer 1 transport block, and does not process other headers, such as MAC header and PDCP headers, according to some embodiments. That is, in some embodiments, none of MAC circuit 526 and RLC circuit524 processes the payloads of the Layer 1 transport blocks stored in in-line control buffer 528.

[0074] As shown in FIG. 5, PDCP circuit 522 may be operatively coupled to RLC circuit

524 and SDAP circuit 520 and configured to process the PDCP headers of the Layer 1 transport blocks received from RLC circuit 524. The processing of the PDCP headers may be controlled based on a set of PDCP commands from MCU 510. In some embodiment, MCU 510 is configured to retrieve/read the set of RLC result statuses (i.e., the result statues from the lower layer - RLC Layer - in the Layer 2 protocol stack) from RLC status queue 536, generate the set of PDCP commands based on the set of RLC result statuses, and store/write the set of PDCP commands into a PDCP command queue 534 in memory 512, such that PDCP circuit 522 can retrieve/read the set of PDCP commands from PDCP command queue 534 according to the priorities assigned by MCU 510 to the PDCP commands. For example, the PDCP commands may need to be adjusted based on the processing result at the lower layer, i.e., the RLC layer by RLC circuit 524, e.g., wait until the RLC header of a Layer 1 transport block has been processed and/or the PDCP header of the Layer 1 transport block has been extracted and read from in-line control buffer 528 by RLC circuit 524.

[0075] In some embodiments, PDCP circuit 522 is configured to process the PDCP header before reading and processing the payload of a Layer 1 transport block stored in in-line control buffer 528. For example, MAC circuit 526 may extract and read the MAC, RLC, and PDCP headers of the Layer 1 transport block stored in in-line control buffer 528, RLC circuit 524 may receive the RLC and PDCP headers from MAC circuit 526, and PDCP circuit 522 may receive the PDCP header from RLC circuit 524. It is understood that in some examples, PDCP circuit 522 may extract and read the PDCP header of the Layer 1 transport block from in-line control buffer 528 directly.

[0076] After processing the PDCP header, PDCP circuit 522 may be configured to process the payload of the Layer 1 transport block stored in in-line control buffer 528. In some embodiments, the processing of the payload is based, at least in part, on the processed PDCP header of the Layer 1 transport block and thus, is performed after the processing of the PDCP header. In some embodiments, the processing of the payload is based, at least in part, on the processed RLC header and/or the processed MAC header of the Layer 1 transport block as well. It is understood that in some examples, the processing of the PDCP header and the processing of the RLC header may be performed independently and/or simultaneously. Nevertheless, PDCP circuit 524 is the driving stage that start to pull payloads out of in-line control buffer 528 and is the only Layer 2 circuit 508 that processes the payloads of the Layer 1 transport blocks, according to some embodiments. In some embodiments, PDCP circuit 524 may be configured to generate a Layer 3 data packet based on the processed PDCP header and payloads of the Layer 1 transport block. In some embodiments, the Layer 3 data packet is generated based on the processed RLC header and/or MAC header as well.

[0077] The software and hardware methods and systems disclosed herein, such as the method illustrated in FIG. 6, may be implemented by any suitable nodes in a wireless network. For example, FIG. 8 illustrates an apparatus 800, and FIG. 9 illustrates an exemplary wireless network 900, in which some aspects of the present disclosure may be implemented, according to some embodiments of the present disclosure.

[0078] FIG. 6 illustrates a method according to certain embodiments. As shown in Figure

6, a method can include, at 610, receiving, at a physical layer of a protocol stack, a code block or code block group belonging to a transport block. The transport block can be composed of a plurality of code block groups including the code block group. The method can also include, at 620, passing the code block or code block group to a pre-processing stage. This passing at 620 can include passing the code block or code block group from the physical layer to a higher layer of processing in the protocol stack without waiting for a determination that the transport block was completely received at 630 or a confirmation that the transport block was correctly received at 640, or both. [0079] The method can further include, at 650, releasing the code block group from a level of the protocol stack (level of the protocol stack and layer of the protocol stack can be used interchangeably) above the physical layer upon confirmation that the transport block was correctly received at 640. The releasing can include committing a packet obtained from the code block group to a destination queue. After release, the system can, at 670, pass the code block group to a higher layer.

[0080] The method can further include, at 660, updating a status variable of the level of the protocol stack upon confirmation that the transport block was correctly received. The level can include at least one of a medium access control level, a radio link control level, or a packet data convergence protocol level.

[0081] The method can further include releasing, at 650, the code block group from a level of the protocol stack above the physical layer upon confirmation that the transport block was completely received, at 630. The determination or confirmation that the transport block is complete may be performed at the physical layer or at any other layer.

[0082] The method can further include, at 625, determining that the code block group corresponds to a data packet and passing the code block group, at 620, up the protocol stack without waiting for transport block reception completion based on the determination that the code block group corresponds to the data packet.

[0083] In some embodiments, the method can further include determining that a cyclic redundancy check of the transport block failed (see the “no” path from 640). The method can additionally include, at 645, removing the code block group from the protocol stack based on the determination that the cyclic redundancy check of the transport block failed.

[0084] In some embodiments, the processing in the higher layer can include storing a protocol-level-specific descriptor of a control packet in a transport block holding buffer on the internal memory. In some embodiments, the processing in the higher layer can include storing a protocol-level-specific sequence number corresponding to the code block group in a transport block holding buffer on the internal memory. The protocol-level-specific descriptor may be an RLC descriptor or a PDCP descriptor, and the sequence number may similarly be specific to a particular level or layer of the protocol stack.

[0085] As shown in FIG. 7, a node 700 may include a processor 702, a memory 704, a transceiver 706. These components are shown as connected to one another by bus 708, but other connection types are also permitted. When node 700 is user equipment 902, additional components may also be included, such as a user interface (UI), sensors, and the like. Similarly, node 700 may be implemented as a blade in a server system when node 700 is configured as core network element 906. Other implementations are also possible.

[0086] Transceiver 706 may include any suitable device for sending and/or receiving data.

Node 700 may include one or more transceivers, although only one transceiver 706 is shown for simplicity of illustration. An antenna 710 is shown as a possible communication mechanism for node 700. Multiple antennas and/or arrays of antennas may be utilized. Additionally, examples of node 700 may communicate using wired techniques rather than (or in addition to) wireless techniques. For example, access node 904 may communicate wirelessly to user equipment 902 and may communicate by a wired connection (for example, by optical or coaxial cable) to core network element 906. Other communication hardware, such as a network interface card (NIC), may be included as well.

[0087] As shown in FIG. 7, node 700 may include processor 702. Although only one processor is shown, it is understood that multiple processors can be included. Processor 702 may include microprocessors, microcontrollers, DSPs, ASICs, field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout the present disclosure. Processor 702 may be a hardware device having one or many processing cores. Processor 702 may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Software can include computer instructions written in an interpreted language, a compiled language, or machine code. Other techniques for instructing hardware are also permitted under the broad category of software. Processor 702 may be a baseband chip, such as baseband chip 802 in FIG. 8. Node 700 may also include other processors, not shown, such as a central processing unit of the device, a graphics processor, or the like. Processor 702 may include internal memory (also known as local memory, not shown in FIG. 7) that may serve as memory for L2 data. Processor 702 may include a radio frequency chip, for example, integrated into a baseband chip, or a radio frequency chip may be provided separately. Processor 702 may be configured to operate as a modem of node 700, or may be one element or component of a modem. Other arrangements and configurations are also permitted.

[0088] As shown in FIG. 7, node 700 may also include memory 704. Although only one memory is shown, it is understood that multiple memories can be included. Memory 704 can broadly include both memory and storage. For example, memory 704 may include random-access memory (RAM), read-only memory (ROM), SRAM, dynamic RAM (DRAM), ferro-electric RAM (FRAM), electrically erasable programmable ROM (EEPROM), CD-ROM or other optical disk storage, hard disk drive (HDD), such as magnetic disk storage or other magnetic storage devices, Flash drive, solid-state drive (SSD), or any other medium that can be used to carry or store desired program code in the form of instructions that can be accessed and executed by processor 702. Broadly, memory 704 may be embodied by any computer-readable medium, such as a non- transitory computer-readable medium. The memory 704 can be the external memory 808 in FIG. 8. The memory 704 may be shared by processor 702 and other components of node 700, such as the unillustrated graphic processor or central processing unit.

[0089] FIG. 8 illustrates a block diagram of an apparatus 800 including a baseband chip

802, a radio frequency chip 804, and a host chip 806, according to some embodiments of the present disclosure. Apparatus 800 may be an example of any suitable node of wireless network 900 in FIG. 9, such as user equipment 902 or access node 904. As shown in FIG. 8, apparatus 800 may include baseband chip 802, radio frequency chip 804, host chip 806, and one or more antennas 810. In some embodiments, baseband chip 802 is implemented by processor 702 and memory 704, and radio frequency chip 804 is implemented by processor 702, memory 704, and transceiver 706, as described above with respect to FIG. 7. Besides the on-chip memory (also known as “internal memory” or “local memory,” e.g., registers, buffers, or caches) on each chip 802, 804, or 806, apparatus 800 may further include an external memory 808 (e.g., the system memory or main memory) that can be shared by each chip 802, 804, or 806 through the system/main bus. Although baseband chip 802 is illustrated as a standalone SoC in FIG. 8, it is understood that in one example, baseband chip 802 and radio frequency chip 804 may be integrated as one SoC; in another example, baseband chip 802 and host chip 806 may be integrated as one SoC; in still another example, baseband chip 802, radio frequency chip 804, and host chip 806 may be integrated as one SoC, as described above.

[0090] In the uplink, host chip 806 may generate raw data and send it to baseband chip 802 for encoding, modulation, and mapping. Baseband chip 802 may also access the raw data generated by host chip 806 and stored in external memory 808, for example, using the direct memory access (DMA). Baseband chip 802 may first encode (e.g., by source coding and/or channel coding) the raw data and modulate the coded data using any suitable modulation techniques, such as multi-phase pre-shared key (MPSK) modulation or quadrature amplitude modulation (QAM). Baseband chip 802 may perform any other functions, such as symbol or layer mapping, to convert the raw data into a signal that can be used to modulate the carrier frequency for transmission. In the uplink, baseband chip 802 may send the modulated signal to radio frequency chip 804. Radio frequency chip 804, through the transmitter (Tx), may convert the modulated signal in the digital form into analog signals, i.e., radio frequency signals, and perform any suitable front-end radio frequency functions, such as filtering, up-conversion, or sample-rate conversion. Antenna 810 (e.g., an antenna array) may transmit the radio frequency signals provided by the transmitter of radio frequency chip 804.

[0091] In the downlink, antenna 810 may receive radio frequency signals and pass the radio frequency signals to the receiver (Rx) of radio frequency chip 804. Radio frequency chip 804 may perform any suitable front-end radio frequency functions, such as filtering, down-conversion, or sample-rate conversion, and convert the radio frequency signals into low-frequency digital signals (baseband signals) that can be processed by baseband chip 802. In the downlink, baseband chip 802 may demodulate and decode the baseband signals to extract raw data that can be processed by host chip 806. Baseband chip 802 may perform additional functions, such as error checking, de mapping, channel estimation, descrambling, etc. The raw data provided by baseband chip 802 may be sent to host chip 806 directly or stored in external memory 808.

[0092] Baseband chip 802 in FIG. 8 may correspond to baseband chip 502 in FIG. 5.

Baseband chip 802 may implement the protocol stack shown in FIG. 1, including MAC layer 107, RLC layer 115, and PDCP layer 123, as well as providing the various TB buffers (for example, 113, 117, 119, 127, and 29) and re-ordering windows (including RLC re-ordering window 121 and PDCP re-ordering window 125). Similarly, host chip 806 in FIG. 8 may correspond to host chip 504 in FIG. 5. Likewise, external memory 808 in FIG. 8 may correspond to external memory 506 in FIG. 5. The data flow in FIG. 1 corresponds to the decode/demodulate path of baseband chip 802.

[0093] As shown in FIG. 9, wireless network 900 may include a network of nodes, such as a UE 902, an access node 904, and a core network element 906. User equipment 902 may be any terminal device, such as a mobile phone, a desktop computer, a laptop computer, a tablet, a vehicle computer, a gaming console, a printer, a positioning device, a wearable electronic device, a smart sensor, or any other device capable of receiving, processing, and transmitting information, such as any member of a vehicle to everything (V2X) network, a cluster network, a smart grid node, or an Internet-of-Things (IoT) node. It is understood that user equipment 902 is illustrated as a mobile phone simply by way of illustration and not by way of limitation.

[0094] Access node 904 may be a device that communicates with user equipment 902, such as a wireless access point, a base station (BS), a Node B, an enhanced Node B (eNodeB or eNB), a next-generation NodeB (gNodeB or gNB), a cluster master node, or the like. Access node 904 may have a wired connection to user equipment 902, a wireless connection to user equipment 902, or any combination thereof. Access node 904 may be connected to user equipment 902 by multiple connections, and user equipment 902 may be connected to other access nodes in addition to access node 904. Access node 904 may also be connected to other UEs. It is understood that access node 904 is illustrated by a radio tower by way of illustration and not by way of limitation.

[0095] Core network element 906 may serve access node 904 and user equipment 902 to provide core network services. Examples of core network element 906 may include a home subscriber server (HSS), a mobility management entity (MME), a serving gateway (SGW), or a packet data network gateway (PGW). These are examples of core network elements of an evolved packet core (EPC) system, which is a core network for the LTE system. Other core network elements may be used in LTE and in other communication systems. In some embodiments, core network element 906 includes an access and mobility management function (AMF) device, a session management function (SMF) device, or a user plane function (UPF) device, of a core network for the NR system. It is understood that core network element 906 is shown as a set of rack-mounted servers by way of illustration and not by way of limitation.

[0096] Core network element 906 may connect with a large network, such as the Internet

908, or another IP network, to communicate packet data over any distance. In this way, data from user equipment 902 may be communicated to other UEs connected to other access points, including, for example, a computer 910 connected to Internet 908, for example, using a wired connection or a wireless connection, or to a tablet 912 wirelessly connected to Internet 908 via a router 914. Thus, computer 910 and tablet 912 provide additional examples of possible UEs, and router 914 provides an example of another possible access node.

[0097] A generic example of a rack-mounted server is provided as an illustration of core network element 906. However, there may be multiple elements in the core network including database servers, such as a database 916, and security and authentication servers, such as an authentication server 918. Database 916 may, for example, manage data related to user subscription to network services. A home location register (HLR) is an example of a standardized database of subscriber information for a cellular network. Likewise, authentication server 918 may handle authentication of users, sessions, and so on. In the NR system, an authentication server function (AUSF) device may be the specific entity to perform user equipment authentication. In some embodiments, a single server rack may handle multiple such functions, such that the connections between core network element 906, authentication server 918, and database 916, may be local connections within a single rack.

[0098] Although the above-description used uplink and downlink processing of a packet in a UE as examples in various discussions, similar techniques may likewise be used for the other direction of processing and for processing in other devices, such as access nodes, and core network nodes. For example, any device that processes packets through a plurality of layers of a protocol stack may benefit some embodiments of the present disclosure, even if not specifically listed above or illustrated in the example network of FIG. 9.

[0099] Each of the elements of FIG. 9 may be considered a node of wireless network 900.

More detail regarding the possible implementation of a node is provided by way of example in the description of a node 700 in FIG. 7 above. Node 700 may be configured as user equipment 902, access node 904, or core network element 906 in FIG. 9. Similarly, node 700 may also be configured as computer 910, router 914, tablet 912, database 916, or authentication server 918 in FIG. 9.

[0100] In various aspects of the present disclosure, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or encoded as instructions or code on a non-transitory computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computing device, such as node 700 in FIG. 7. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, HDD, such as magnetic disk storage or other magnetic storage devices, Flash drive, SSD, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a processing system, such as a mobile device or a computer. Disk and disc, as used herein, includes CD, laser disc, optical disc, DVD, and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0101] According to one aspect of the present disclosure, a method can include receiving, at a physical layer of a protocol stack, a code block group belonging to a transport block. The transport block can be composed of a plurality of code block groups including the code block group. The method can also include passing the code block group from the physical layer to a higher layer of processing in the protocol stack without waiting for a determination that the transport block was completely received or a confirmation that the transport block was correctly received or both. [0102] In some embodiments, the method can further include releasing the code block group from a level of the protocol stack above the physical layer upon confirmation that the transport block was correctly received.

[0103] In some embodiments, the releasing can include committing a packet obtained from the code block group to a destination queue.

[0104] In some embodiments, the method can further include updating a status variable of the level of the protocol stack upon confirmation that the transport block was correctly received. [0105] In some embodiments, the level can include at least one of a medium access control level, a radio link control level, or a packet data convergence protocol level.

[0106] In some embodiments, the method can further include releasing the code block group from a level of the protocol stack above the physical layer upon confirmation that the transport block was completely received.

[0107] In some embodiments, the method can further include determining that the code block group corresponds to a data packet and passing the code block group up the protocol stack without waiting for transport block reception completion based on the determination that the code block group corresponds to the data packet.

[0108] In some embodiments, the method can further include determining that a cyclic redundancy check of the transport block failed. The method can additionally include removing the code block group from the protocol stack based on the determination that the cyclic redundancy check of the transport block failed.

[0109] In some embodiments, the processing in the higher layer can include storing a protocol-level-specific descriptor of a control packet in a transport block holding buffer on the internal memory. [0110] In some embodiments, the processing in the higher layer can include storing a protocol-level-specific sequence number corresponding to the code block group in a transport block holding buffer on the internal memory.

[0111] According to another aspect of certain embodiments, a baseband chip can include layer 2 circuitry implementing a protocol stack comprising a plurality of layers configured to process data packets. The layers can also be referred to as levels. The baseband chip can include physical layer circuitry implementing a physical layer of the protocol stack. The physical layer circuitry can be configured to receive a code block group belonging to a transport block. The transport block can be composed of a plurality of code block groups including the code block group. The physical layer circuitry can be further configured to pass the code block group from the physical layer to circuitry implementing a higher layer of the plurality of layers of the protocol stack without waiting for a determination that the transport block was completely received or a confirmation that the transport block was correctly received or both.

[0112] In some embodiments, the layer 2 circuitry can be configured to release the code block group from a level of the protocol stack above the physical layer upon confirmation that the transport block was correctly received.

[0113] In some embodiments, the releasing can include committing a packet obtained from the code block group to a destination queue.

[0114] In some embodiments, the layer 2 circuitry can be configured to update a status variable of the level of the protocol stack upon confirmation that the transport block was correctly received.

[0115] In some embodiments, the level can include at least one of a medium access control level, a radio link control level, or a packet data convergence protocol level.

[0116] In some embodiments, the layer 2 circuitry can be configured to release the code block group from a level of the protocol stack above the physical layer upon confirmation that the transport block was completely received.

[0117] In some embodiments, the layer 2 circuitry can be configured to determine that the code block group corresponds to a data packet and to pass the code block group up the protocol stack without waiting for transport block reception completion based on the determination that the code block group corresponds to the data packet.

[0118] In some embodiments, the layer 2 circuitry is configured to determine that a cyclic redundancy check of the transport block failed and to remove the code block group from the protocol stack based on the determination that the cyclic redundancy check of the transport block failed.

[0119] In some embodiments, the layer 2 circuitry is configured to store a protocol-level- specific descriptor of a control packet in a transport block holding buffer on the internal memory. [0120] In some embodiments, the layer 2 circuitry is configured to store a protocol-level- specific sequence number corresponding to the code block group in a transport block holding buffer on the internal memory.

[0121] According to still another aspect of certain embodiments, an apparatus for data processing can include circuitry implementing a physical layer and configured to receive a code block group. The apparatus can also include circuitry implementing a medium access control layer and operatively connected to the circuitry implementing the physical layer. The circuitry implementing the physical layer can be further configured to pass the code block group to the circuitry implementing the medium access control layer without waiting for a determination that a transport block comprising the code block group was completely received or a confirmation that the transport block was correctly received or both

[0122] The foregoing description of the specific embodiments will so reveal the general nature of the present disclosure that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present disclosure. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

[0123] Embodiments of the present disclosure have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.

[0124] The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present disclosure as contemplated by the inventor(s), and thus, are not intended to limit the present disclosure and the appended claims in any way. [0125] Various functional blocks, modules, and steps are disclosed above. The particular arrangements provided are illustrative and without limitation. Accordingly, the functional blocks, modules, and steps may be re-ordered or combined in different ways than in the examples provided above. Likewise, certain embodiments include only a subset of the functional blocks, modules, and steps, and any such subset is permitted.

[0126] The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A method for data processing, comprising: receiving, at a physical layer of a protocol stack, a code block group belonging to a transport block, wherein the transport block is composed of a plurality of code block groups including the code block group; and passing the code block group from the physical layer to a higher layer of processing in the protocol stack without waiting for a determination that the transport block was completely received or a confirmation that the transport block was correctly received or both.

2. The method of claim 1, further comprising: releasing the code block group from a level of the protocol stack above the physical layer upon confirmation that the transport block was correctly received.

3. The method of claim 2, wherein the releasing comprises committing a packet obtained from the code block group to a destination queue.

4. The method of claim 2, further comprising: updating a status variable of the level of the protocol stack upon confirmation that the transport block was correctly received.

5. The method of claim 2, wherein the level comprises at least one of a medium access control level, a radio link control level, or a packet data convergence protocol level.

6. The method of claim 1, further comprising: releasing the code block group from a level of the protocol stack above the physical layer upon confirmation that the transport block was completely received.

7. The method of claim 1, further comprising: determining that the code block group corresponds to a data packet and passing the code block group up the protocol stack without waiting for transport block reception completion based on the determination that the code block group corresponds to the data packet.

8. The method of claim 1, further comprising: determining that a cyclic redundancy check of the transport block failed; and removing the code block group from the protocol stack based on the determination that the cyclic redundancy check of the transport block failed.

9. The method of claim 1 , wherein the processing in the higher layer comprises storing a protocol-level-specific descriptor of a control packet.

10. The method of claim 1 , wherein the processing in the higher layer comprises storing a protocol-level-specific sequence number corresponding to the code block group.

11. A baseband chip, comprising: layer 2 circuitry implementing a protocol stack comprising a plurality of layers configured to process data packets; and physical layer circuitry implementing a physical layer of the protocol stack, wherein the physical layer circuitry is configured to: receive a code block group belonging to a transport block, wherein the transport block is composed of a plurality of code block groups including the code block group; and pass the code block group from the physical layer to circuitry implementing a higher layer of the plurality of layers of the protocol stack without waiting for a determination that the transport block was completely received or a confirmation that the transport block was correctly received or both.

12. The baseband chip of claim 11 , wherein the layer 2 circuitry is configured to release the code block group from a level of the protocol stack above the physical layer upon confirmation that the transport block was correctly received.

13. The baseband chip of claim 12, wherein to release the code block group, the layer 2 circuitry is configured to commit a packet obtained from the code block group to a destination queue.

14. The baseband chip of claim 12, wherein the layer 2 circuitry is configured to update a status variable of the level of the protocol stack upon confirmation that the transport block was correctly received.

15. The baseband chip of claim 12, wherein the level comprises at least one of a medium access control level, a radio link control level, or a packet data convergence protocol level.

16. The baseband chip of claim 11 , wherein the layer 2 circuitry is configured to release the code block group from a level of the protocol stack above the physical layer upon confirmation that the transport block was completely received.

17. The baseband chip of claim 11, wherein the layer 2 circuitry is configured to determine that the code block group corresponds to a data packet and to pass the code block group up the protocol stack without waiting for transport block reception completion based on the determination that the code block group corresponds to the data packet.

18. The baseband chip of claim 11, wherein the layer 2 circuitry is configured to determine that a cyclic redundancy check of the transport block failed and to remove the code block group from the protocol stack based on the determination that the cyclic redundancy check of the transport block failed.

19. The baseband chip of claim 11, further comprising: an internal memory, wherein the layer 2 circuitry is configured to store a protocol-level- specific descriptor of a control packet in a transport block holding buffer on the internal memory.

20. The baseband chip of claim 11, further comprising: an internal memory, wherein the layer 2 circuitry is configured to store a protocol-level- specific sequence number corresponding to the code block group in a transport block holding buffer on the internal memory.

21. An apparatus for data processing, comprising: physical layer circuitry implementing a physical layer and configured to receive a code block group; and circuitry implementing a medium access control layer and operatively connected to the circuitry implementing the physical layer, wherein the circuitry implementing the physical layer is further configured to pass the code block group to the circuitry implementing the medium access control layer without waiting for a determination that a transport block comprising the code block group was completely received or a confirmation that the transport block was correctly received or both.