[0001] This application claims the benefit of priority to U.S. Provisional Patent

Application No. 62/967,464, filed January 29, 2020, entitled “High Speed, Low Cost, Low Power Scalable 4G/5G Uplink MAC Data Plane Design Using In-Line Programmable Hardware Accelerations,” which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

[0002] Embodiments of the present disclosure relate to apparatus and method for wireless communication.

BACKGROUND

[0003] 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 Radio Layer 2 (referred to here as “Layer 2”) as part of the protocol stack structure corresponding to the user plane (also known as the “data plane”), which includes 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. Layer 2 in 5G NR further includes a Service Data Adaptation Protocol (SDAP) layer.

SUMMARY

[0004] Embodiments of apparatus and method for Layer 2 uplink data processing are disclosed herein.

[0005] In one example, a baseband chip includes a plurality of Layer 2 circuits and a microcontroller unit (MCU) operatively coupled to the Layer 2 circuits. The Layer 2 circuits are configured to receive Layer 3 data packets and generate MAC protocol data units (PDUs) from the Layer 3 data packets in an inline manner. The MUC is configured to control the Layer 2 circuits to generate the MAC PDUs from the Layer 3 data packets through a plurality sets of commands.

[0006] In another example, a baseband chip includes a PDCP circuit, an RLC circuit, a flow control buffer, and a MAC circuit. The PDCP circuit is configured to receive Layer 3 data packets and process the Layer 3 data packets to generate PDCP PDUs. The RLC circuit is configured to receive the PDCP PDUs directly from the PDCP circuit and segment or concatenate the PDCP PDUs into RLC PDUs. The flow control buffer is configured to receive the RLC PDUs directly from the RLC circuit and store the RLC PDUs. The MAC circuit is configured to process the RLC PDUs stored in the flow control buffer to generate MAC PDUs. [0007] In still another example, a method for Layer 2 uplink data processing is disclosed. A first set of commands are provided by an MCU to control a PDCP circuit to receive Layer 3 data packets and process the Layer 3 data packets to generate PDCP PDUs. A first set of result statuses based on the processing result of the PDCP circuit are received by the MCU. A second set of commands are provided by the MCU based on the first set of result statuses to control an RLC circuit to process the PDCP PDUs to generate RLC PDUs. A second set of result statuses based on the processing result of the RLC circuit are received by the MCU. A third set of commands are provided by the MCU based on the second set of result statuses to control a MAC circuit to process the RLC PDUs to generate MAC PDUs.

[0008] In yet another example, a method for Layer 2 uplink data processing is disclosed. Layer 3 data packets are processed by a PDCP circuit to generate PDCP PDUs. The PDCP PDUs are directly received by an RLC circuit from the PDCP circuit. The PDCP PDUs are segmented or concatenated by the RLC circuit into RLC PDUs. The RLC PDUs are directly received by a flow control buffer from the RLC circuit. The RLC PDUs are stored by the flow control buffer. The RLC PDUs stored in the flow control buffer are processed by a MAC circuit to generate MAC PDUs.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] 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.

[0010] FIG. 1 illustrates an exemplary wireless network, according to some embodiments of the present disclosure.

[0011] FIG. 2 illustrates a block diagram of an apparatus including a baseband chip, a radio frequency (RF) chip, and a host chip, according to some embodiments of the present disclosure.

[0012] FIG. 3 illustrates a block diagram of an exemplary user plane protocol stack, according to some embodiments of the present disclosure.

[0013] FIG. 4A illustrates a block diagram of a baseband chip implementing Layer 2 uplink data processing using a baseband processor.

[0014] FIG. 4B illustrates a data flow of the baseband chip shown in FIG. 4A.

[0015] FIG. 5A illustrates a detailed block diagram of an exemplary baseband chip implementing Layer 2 uplink data processing using Layer 2 circuits and an MCU, according to some embodiments of the present disclosure.

[0016] FIG. 5B illustrates an exemplary data flow of the baseband chip shown in FIG.

5A, according to some embodiments of the present disclosure.

[0017] FIG. 6 illustrates a flow chart of an exemplary method for Layer 2 uplink data processing, according to some embodiments of the present disclosure.

[0018] FIG. 7 illustrates a block diagram of an exemplary node, 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] In known solutions, Layer 2 data processing, for example, processing the data packages received from Layer 3 in the uplink 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 frequently transferred between the generic baseband processor and external memory (e.g., the system memory), for example, for buffering between each layer. As a result, the known solutions for Layer 2 data processing suffer from high power consumption, large data buffer, and long process delays.

[0026] Various embodiments in accordance with the present disclosure provide an improved solution for implementing Layer 2 uplink data processing in an inline manner using dedicated Layer 2 circuits, such as application-specific integrated circuits (ASICs), thereby achieving high performance, low cost, and low power Layer 2 uplink data processing and transmission. The dedicated Layer 2 circuits can process (e.g., formatting, mapping, error checking, etc.) the data on-the-fly at the real transmission time. That is, the hardware implementation disclosed herein can reduce processing delay, buffer size, and power consumption by processing uplink data in the inline manner through each layer in the Layer 2 protocol stack, not having to access data in system memory frequently. The Layer 2 circuits can also have the flexibility to either send the processed data (e.g., MAC PDUs) to Layer 1 directly or save the processed data in a buffer for re-transmission, further transmission, or debugging.

[0027] In some embodiments, the Layer 2 circuits are controlled by an MCU, making the Layer 2 circuits programmable. For example, the data processing flow and operations may be modified by programming using the MCU. The Layer 2 circuits can also report the processing results back to the MCU, such that the MCU can dynamically generate or update the control commands, for example, by changing the priorities of the commands based on the process results from the higher layer in the Layer 2 protocol stack, i.e., the previous stage in uplink processing. In this a way, the Layer 2 circuits can be very flexible to adapt to any changes in the protocol data flow requirements.

[0028] Moreover, the Layer 2 circuits are scalable based on the number of data flows, the throughput of each data flow, and the total data flows. The Layer 2 circuits can have a scalable number of data buffers and data paths that can be adapted to high-to-low data rate applications. The number of MCUs is scalable as well, by adding or removing MCUs as the system scales. Each MCU can communicate with the Layer 2 circuits through on-chip memory (e.g., for command and status queues), local bus, and interrupts on the baseband chip. Further, the clock frequency of the Layer 2 circuits and MCU is scalable as well. For example, lower clock frequencies may result in less die size, cost, and power consumption.

[0029] FIG. 1 illustrates an exemplary wireless network 100, in which certain aspects of the present disclosure may be implemented, according to some embodiments of the present disclosure. As shown in FIG. 1, wireless network 100 may include a network of nodes, such as a user equipment (UE) 102, an access node 104, and a core network element 106. User equipment 102 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 102 is illustrated as a mobile phone simply by way of illustration and not by way of limitation.

[0030] Access node 104 may be a device that communicates with user equipment 102, 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 104 may have a wired connection to user equipment 102, a wireless connection to user equipment 102, or any combination thereof. Access node 104 may be connected to user equipment 102 by multiple connections, and user equipment 102 may be connected to other access nodes in addition to access node 104. Access node 104 may also be connected to other user equipments. It is understood that access node 104 is illustrated by a radio tower by way of illustration and not by way of limitation.

[0031] Core network element 106 may serve access node 104 and user equipment 102 to provide core network services. Examples of core network element 106 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 106 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 106 is shown as a set of rack-mounted servers by way of illustration and not by way of limitation.

[0032] Core network element 106 may connect with a large network, such as the

Internet 108, or another Internet Protocol (IP) network, to communicate packet data over any distance. In this way, data from user equipment 102 may be communicated to other user equipments connected to other access points, including, for example, a computer 110 connected to Internet 108, for example, using a wired connection or a wireless connection, or to a tablet 112 wirelessly connected to Internet 108 via a router 114. Thus, computer 110 and tablet 112 provide additional examples of possible user equipments, and router 114 provides an example of another possible access node.

[0033] A generic example of a rack-mounted server is provided as an illustration of core network element 106. However, there may be multiple elements in the core network including database servers, such as a database 116, and security and authentication servers, such as an authentication server 118. Database 116 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 118 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 106, authentication server 118, and database 116, may be local connections within a single rack. [0034] Each element in FIG. 1 may be considered a node of wireless network 100.

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. Node 700 may be configured as user equipment 102, access node 104, or core network element 106 in FIG. 1. Similarly, node 700 may also be configured as computer 110, router 114, tablet 112, database 116, or authentication server 118 in FIG. 1. As shown in FIG. 7, node 700 may include a processor 702, a memory 704, and a transceiver 706. These components are shown as connected to one another by a bus, but other connection types are also permitted. When node 700 is user equipment 102, 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 106. Other implementations are also possible.

[0035] 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 708 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 104 may communicate wirelessly to user equipment 102 and may communicate by a wired connection (for example, by optical or coaxial cable) to core network element 106. Other communication hardware, such as a network interface card (NIC), may be included as well.

[0036] 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, microcontroller units (MCUs), digital signal processors (DSPs), application-specific integrated circuits (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 more 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.

[0037] 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), static RAM (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.

[0038] Processor 702, memory 704, and transceiver 706 may be implemented in various forms in node 700 for performing wireless communication functions. In some embodiments, processor 702, memory 704, and transceiver 706 of node 700 are implemented (e.g., integrated) on one or more system-on-chips (SoCs). In one example, processor 702 and memory 704 may be integrated on an application processor (AP) SoC (sometimes known as a “host,” referred to herein as a “host chip”) that handles application processing in an operating system (OS) environment, including generating raw data to be transmitted. In another example, processor 702 and memory 704 may be integrated on a baseband processor (BP) SoC (sometimes known as a “modem,” referred to herein as a “baseband chip”) that converts the raw data, e.g., from the host chip, to signals that can be used to modulate the carrier frequency for transmission, and vice versa, which can run a real-time operating system (RTOS). In still another example, processor 702 and transceiver 706 (and memory 704 in some cases) may be integrated on an RF SoC (sometimes known as a “transceiver,” referred to herein as an “RF chip”) that transmits and receives RF signals with antenna 708. It is understood that in some examples, some or all of the host chip, baseband chip, and RF chip may be integrated as a single SoC. For example, a baseband chip and an RF chip may be integrated into a single SoC that manages all the radio functions for cellular communication.

[0039] Referring back to FIG. 1, in some embodiments, any suitable node of wireless network 100 (e.g., user equipment 102 or access node 104) in transmitting signals to another node, for example, from user equipment 102 to access node 104, or vice versa, via an uplink (UL), may process Layer 2 data in an inline manner using dedicated Layer 2 circuits controlled by an MCU on a baseband chip, as described below in detail. As a result, compared with known solutions in which Layer 2 data is processed using software modules implemented on a generic processor in conjunction with the system memory, the data speed can be improved due to hardware acceleration, the chip cost can be reduced by reducing memory usage, and the power consumption can be decreased as well.

[0040] FIG. 2 illustrates a block diagram of an apparatus 200 including a baseband chip

202, a RF chip 204, and a host chip 206, according to some embodiments of the present disclosure. Apparatus 200 may be an example of any suitable node of wireless network 100 in FIG. 1, such as user equipment 102 or access node 104. As shown in FIG. 2, apparatus 200 may include baseband chip 202, RF chip 204, host chip 206, and one or more antennas 210. In some embodiments, baseband chip 202 is implemented by processor 702 and memory 704, and RF chip 204 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,” e.g., registers, buffers, or caches) on each chip 202, 204, or 206, apparatus 200 may further include an external memory 208 (e.g., the system memory or main memory) that can be shared by each chip 202, 204, or 206 through the system/main bus. Although baseband chip 202 is illustrated as a standalone SoC in FIG. 2, it is understood that in one example, baseband chip 202 and RF chip 204 may be integrated as one SoC; in another example, baseband chip 202 and host chip 206 may be integrated as one SoC; in still another example, baseband chip 202, RF chip 204, and host chip 206 may be integrated as one SoC, as described above.

[0041] In the uplink, host chip 206 may generate raw data and send it to baseband chip

202 for encoding, modulation, and mapping. Baseband chip 202 may also access the raw data generated by host chip 206 and stored in external memory 208, for example, using the direct memory access (DMA). Baseband chip 202 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 202 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 202 may send the modulated signal to RF chip 204. RF chip 204, through the transmitter (Tx), may convert the modulated signal in the digital form into analog signals, i.e., RF signals, and perform any suitable front-end RF functions, such as filtering, up-conversion, or sample-rate conversion. Antenna 210 (e.g., an antenna array) may transmit the RF signals provided by the transmitter of RF chip 204.

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

[0043] FIG. 3 illustrates a block diagram of an exemplary user plane protocol stack, according to some embodiments of the present disclosure. Baseband chip 202 of a node, either user equipment 102 or access node 104, may implement a protocol stack defined in the standards, for example, by the 3 GPP, which includes a set of network protocol layers that work together to provide networking capabilities. According to the 3GPP standards, the radio protocol architecture for both LTE and NR. can be separated into the user plane carrying the user traffic and the control plane carrying the signaling traffic. For example, in the user plane, applications may create data packets that are processed by protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Interconnect Protocol (IP). In the control plane, signaling messages may be generated by the Radio Resource Control (RRC) protocol. As shown in FIG. 3, each of a user equipment 302 (e.g., an example of user equipment 102 in FIG. 1) and a base station 304 (e.g., an example of access node 104 in FIG 1) may implement the protocol stack in the user plane for LTE or NR. Each layer is responsible for processing the user plane data packets in the form of IP data or raw user data, and ensuring that data transmission is secure, on-time, and error-free.

[0044] Layer 3 in LTE or NR user plane may include the IP layer in user equipment 302 for providing user data, for example, in the form of IP data packets. Layer 2 in LTE may include the PDCP layer, the RLC layer, and the MAC layer, from higher to lower in the protocol stack. Layer 2 in NR may further include a Service Data Adaptation Protocol (SDAP) layer. The SDAP layer may map between a Qualify of Service (QoS) flow and a data radio bearer (DRB) due to the new QoS framework. That is, the SDAP layer may classify the data packets in QoS flows into DRBs. The SDAP layer may also mark the QoS flow IDs (QFIs) in downlink data packets due to reflective QoS and in uplink data packets due to the new QoS framework.

[0045] The PDCP layer in the user plane may perform robust header compression

(ROHC) and security functions, such as integrity checking and ciphering, in the uplink, and ROHC decompression and deciphering in the downlink. The PDCP layer may receive the data packets in the form of PDCP service data units (SDUs) from the upper layer, i.e., Layer 3, and pass the processed data in the form of PDCP protocol data units (PDCP PDUs) to the lower layer, e.g., the RLC layer. The PDCP layer may also perform sequence numbering, reordering, duplication detection, PDCP PDU routing, PDCP SDU discard, etc.

[0046] The RLC layer in the user plane may segment or concatenate the data packets received from the upper layer, e.g., the PDCP PDUs/RLC SDUs. into each RLC PDU. That is, the RLC layer may pack small data packets together to form a large data packet (e.g., in LTE) or break down a large data packet into multiple smaller data packets. Depending on the mode of operations (e.g., the transparent mode (TM), the unacknowledged mode (UM), or the acknowledged mode (AM)), the RLC layer may further perform error correction through automatic repeat request (AR.Q) in the AM mode, reassembly of RLC SDUs in the UM and AM modes, duplication detection in the UM and AM modes, and RLC SDU discard in the UM and AM modes. In some embodiments, the RLC layer performs RLC re-transmission by inserting re-transmitted data packets.

[0047] The MAC layer in the user plane may map between logical channels and transport channels. In the uplink, the MAC layer may multiplex MAC SDUs from one or more logical channels onto MAC PDUs in transport blocks (TB) to be delivered to the lower layer, i.e., Layer 3, on transport channels. In the uplink, the MAC layer may de-multiplex MAC SDUs from one or different logical channels from transport blocks delivered from the lower layer on transport channels. The MAC layer may also perform scheduling, information reporting, error correction through hybrid AR.Q (HAR.Q), priority handling between user equipments by dynamic scheduling, priority handling between logical channels by logical channel prioritization, and padding.

[0048] Layer 1 in LTE or NR. includes a physical (PHY) layer, which carries all information received from the MAC layer transport channels, e.g., in the form of MAC PDUs, over the air interface in the uplink, and vice versa in the downlink. Layer 1 may also perform link adaptation, power control, cell search (for initial synchronization and handover purposes), and other measurements (inside the same network or between different networks) for the RRC layer.

[0049] As one example of known solutions implementing Layer 2 uplink data processing using software modules executed by a generic processor, FIG. 4 A illustrates a block diagram of a baseband chip 402 implementing Layer 2 uplink data processing using a baseband processor 408, and FIG. 4B illustrates a data flow of baseband chip 402 shown in FIG. 4 A. An apparatus 400, such as a user equipment or a base station, includes baseband chip 402, a host chip 404, and an external memory 406 operatively coupled to one another through a main bus 424. Baseband chip 402 includes baseband processor 408, a local memory 410, a DMA 412, and a MAC Layer-to-PHY Layer interface (MAC -PHY EF) 414, each of which is operatively coupled to external memory 406 through main bus 424.

[0050] As shown in FIG. 4B, to perform Layer 2 uplink data processing, a plurality of software modules, including an SDAP module 416, a PDCP module 418, an RLC module, and a MAC module 422, are executed by baseband processor 408, which is a generic processor, such as a CPU or DSP, not dedicated to Layer 2 uplink data processing. Baseband processor 408 is also responsible for any other functions of baseband chip 402 and can be interrupted when performing Layer 2 uplink data processing due to other processes with higher priorities. On the other hand, baseband processor 408 does not process the Layer 2 uplink data in an inline manner, meaning that the data passing through each module 416, 418, 420, or 422 is not a continuous data flow/stream. For example, the intermediate data packets during the processing, such as the PDCP SDUs, PDCP PDUs/RLC SDUs, RLC PDUs/MAC SDUs, or MAC PDUs, need to be frequently stored into and accessed from external memory 406 (e.g., a system memory) through main bus 424. The outputs of Layer 2 uplink data processing, i.e., the MAC PDUs in transport blocks, are also first sent by baseband processor 408 to external memory 406 and then accessed by MAC -PHY interface 414 from external memory 406 when Layer 3 (e.g., the PHY Layer) is ready to receive the MAC PDUs. As a result, the software implementation of Layer 2 uplink data processing using a generic processor in conjunction with external memory can reduce the processing speed and increase memory usage and power consumption. [0051] In contrast, FIG. 5A illustrates a detailed block diagram of an exemplary baseband chip 502 implementing Layer 2 uplink data processing using Layer 2 circuits 508 and an MCU 510, according to some embodiments of the present disclosure. FIG. 5B illustrates an exemplary data flow of baseband chip 502 shown in FIG. 5A, according to some embodiments of the present disclosure. In some embodiments, Layer 2 circuits 508 include a SDAP circuit 520, a PDCP circuit 522, an RLC circuit 524, and a MAC circuit 526. As described below in detail, the software modules (e.g., SDAP module 416, PDCP module 418, RLC module 420, and MAC module 422) executed by baseband processor 408 in FIG. 4A may be replaced by dedicated integrated circuits (ICs) (e.g., SDAP circuit 520, PDCP circuit 522, RLC circuit 524, and MAC circuit 526) controlled by MCU 510 to conduct Layer 2 uplink data processing, thereby improving the performance and reducing the cost. In some embodiments, each of SDAP, PDCP, RLC, and MAC circuits 520, 522, 524, or 526 is an IC dedicated to performing the functions of the respective layer in Layer 2 user plane, as described above with respect to FIG. 3. For example, each of SDAP, PDCP, RLC, and MAC circuits 520, 522, 524, or 526 may be an 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.

[0052] Apparatus 500 may be any suitable node of wireless network 100 in FIG. 1, such as user equipment 102 or access node 104 (e.g., a base station including eNB in LTE or gNB in NR). As shown in FIG. 5A, 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. Host chip 504 may be an example of host chip 206 described above in FIG. 2 for generating raw data that has not been coded and modulated yet by the PHY layer of baseband chip 502. In some embodiments, the raw data is formatted into data packets, according to any suitable protocols, such as TCP, UDP, or IP, for example, IP data packets. External memory 506 may be an example of external memory 208 described above in FIG. 2, which can be shared by host chip 504, baseband chip 502, or any other suitable components in apparatus 500, such as a system memory (also known as a “main memory” or “primary memory”) of apparatus 500. In some embodiments, external memory 506 stores the raw data (e.g., IP data packets) to be processed by Layer 2 circuits 508 of baseband chip 502 and stores the data processed by Layer 2 circuits 508 (e.g., MAC PDUs) to be accessed by Layer 3 (e.g., the PHY layer). Different from external memory 406 in FIG. 4A, external memory 506 may not store any intermediate data of Layer 2 circuits 508, for example, PDCP PDUs/RLC SDUs or RLC PDUs/MAC SDUs.

[0053] As shown in FIG. 5 A, baseband chip 502 may also include a plurality of 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 (EO) circuits. As shown in FIG. 5 A, 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. Layer 2 circuits 508 may access local memory 514 through main bus 538 as well. [0054] As shown in FIG. 5 A, 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 one example, a logical partition in local memory 514 may be dedicated to or dynamically allocated to Layer 2 circuits 508 and MCU 510 for exchanging control commands and result statuses. 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. Each pair of corresponding command queue 534 and status queue 536 may be dedicated to one of Layer 2 circuits 508, as described below in detail. [0055] As shown in FIG. 5A, 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. As described below in detail, MCU 510 may be configured to generate a plurality sets of control commands and store each set of the commands into respective command queue 534 in memory 512 through local bus 540 and interrupts. MCU 510 may also receive a plurality sets of result statuses from status queues 536 in memory 512, respectively, through local bus 540 and interrupts. In some embodiments, MCU 510 generates a set of commands based on a set of result statuses from a higher layer in the Layer 2 protocol stack (e.g., the previous stage in Layer 2 uplink processing). Through the control commands in commands queues 534 in memory 512, MCU 510 can be operatively coupled to Layer 2 circuits 508 and control the operations of Layer 2 circuits 508 to process the Layer 2 uplink data. It is understood that although one MCU 510 is shown in FIG. 5 A, the number of MCUs is scalable, such that multiple MCUs may be used in some examples. It is also understood that in some embodiments, memory 512 may be part of MCU 510, e.g., a cache integrated with MCU 510. It is further understood that regardless of the naming, any suitable processing units that can generate control commands to control the operations of Layer 2 circuits 508 and check the result statuses of Layer 2 circuits 508 may be considered as MCU 510 disclosed herein.

[0056] Referring to Layer 2 circuits 508, Layer 2 circuits 508 may be configured to receive Layer 3 data packets (as the inputs of Layer 2 circuits 508) and generate MAC PDUs (as the outputs of Layer 2 circuits 508) from the Layer 3 data packets in an inline 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, as shown in FIG. 5B. The data packets may flow from upper to lower layers in Layer 2 (e.g., PDCP circuit 522, RLC circuit 524, and MAC circuit 526). MCU 510 may be operatively coupled to Layer 2 circuits 508 and configured to control Layer 2 circuits 508 to generate MAC PDUs from the Layer 3 data packets through a plurality sets of commands. In some embodiments, besides SDAP circuit 520, PDCP circuit 522, RLC circuit 524, and MAC circuit 526, each of which corresponds to one layer in Layer 2 user plane in LTE or NR, Layer 2 circuits 508 includes additional hardware components including a flow control buffer 528, a MAC -PHY interface 530, and a buffer management (BM) circuit 532.

[0057] PDCP circuit 522 may be configured to receive the Layer 3 data packets (as

PDCP SDUs) and process the Layer 3 data packets to generate PDCP PDUs. The processing of the Layer 3 data packets may be controlled based on a set of PDCP commands from MCU 510. In some embodiment, MCU 510 is configured to generate the set of PDCP commands and store/write the set of PDCP commands into a PDCP command queue 534 in memory 512, such that PDCP circuit 522 retrieves/reads the set of PDCP commands from PDCP command queue 534 according to the priorities assigned by MCU 510 to the PDCP commands. The PDCP commands may control PDCP circuit 522 first to retrieve Layer 3 data packets (e.g., IP data packets) from extremal memory 506 as PDCP SDUs and then process the Layer 3 data packets to generate PDCP PDUs. In some embodiments, the functions of PDCP circuit 522 in processing the Layer 3 data packets are defined by the 3 GPP standards as described above with respect to the PDCP Layer in FIG. 3, including at least ciphering, integrity protection, and ROHC header compressions. It is understood that in case any update or change being made to the required functions of the PDCP Layer, MCU 510 may reflect the update or change in its PDCP commands to control PDCP circuit 522 to act accordingly. As shown in FIG. 5 A, PDCP circuit 522 may be further configured to obtain the processing result, for example, once the PDCP Layer processing is completed, halted, or interrupted, and store a set of result statuses indicative of the processing result into a PDCP status queue 536 in memory 512.

[0058] In NR, SDAP circuit 520 may be configured to organize the Layer 3 data packets based on QoS. For example, SDAP circuit 520 may function as a lookup table that maps between a QoS flow of the Layer 3 data packets and a DRB. That is, SDAP circuit 520 may classify the Layer 3 data packets in QoS flows into DRBs. The SDAP circuit 520 may also mark the QFIs in the Layer 3 data packets. As shown in FIG. 5B, SDAP circuit 520 may not process the data flow directly, but instead, monitor and organize the data flow being processed by PDCP circuit 522.

[0059] RLC circuit 524 may be operatively coupled to PDCP circuit 522 and configured to segment or concatenate the PDCP PDUs into RLC PDUs. As shown in FIG. 5A, RLC circuit 524 is directly coupled to PDCP circuit 522 without an intermediate buffer to receive the PDCP PDUs directly from PDCP circuit 522, according to some embodiments. As referred to herein, two components may be “operatively coupled” to one another with or without an intermediate component, such as a buffer. For example, MCU 510 may be operatively coupled to Layer 2 circuits 508 with memory 512 in-between. In contrast, as referred to herein, two components may be “directly coupled” to one another without an intermediate component, such as a buffer. As shown in FIG. 5B, since RLC circuit 524 can be directly coupled to PDCP circuit 522, the PDCP PDUs outputted from PDCP circuit 522 can be inputted to RLC circuit 524 as RLC SDUs directly, without being transferred through external memory 506, as shown in FIG. 4B. In some embodiments, first DMA channel 516 is directly coupled to each of PDCP circuit 522 and RLC circuit 524. For example, PDCP circuit 522 may receive the Layer 3 data packets directly from external memory 506 independent of host chip 504 through first DMA channel 516. In some embodiments, RLC circuit 524 is configured to access external memory 506 directly through first DMA channel 516 as well.

[0060] The processing of the PDCP PDUs/RLC SDUs by RLC circuit 524 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 PDCP result statuses (i.e., the result statues from the higher layer - PDCP Layer - in the Layer 2 protocol stack) from PDCP status queue 536, generate the set of RLC commands based on the set of PDCP result statuses, and store/write the set of RLC commands into an RLC command queue 534 in memory 512, such that RLC circuit 524 retrieves/reads 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 higher layer, i.e., the PDCP layer by PDCP circuit 522. In some embodiments, the functions of RLC circuit 524 in processing the PDCP PDUs are defined by the 3GPP standards as described above with respect to the RLC Layer in FIG. 3 including, for example, segmentation or concatenation of the PDCP PDUs to generate the RLC PDUs. In some embodiments, RLC circuit 524 performs RLC re-transmission by inserting re-transmitted data packets controlled by the RLC command from MCU 510. It is understood that in case any update or change being made to the required functions of the RLC Layer, MCU 510 may reflect the update or change in its RLC commands to control RLC circuit 524 to act accordingly. As shown in FIG. 5A, RLC circuit 524 may be further configured to obtain the processing result, for example, once the RLC Layer processing is completed, halted, or interrupted, and store a set of result statuses indicative of the processing result into an RLC status queue 536 in memory 512.

[0061] As shown in FIG. 5A, flow control buffer 528 may be operatively coupled to

RLC circuit 524 and configured to receive the RLC PDUs directly from RLC circuit 524 and store the RLC PDUs. In some embodiments, the data packets in the form of RLC PDUs are delivered to flow control buffer 528 after concatenation or segmentation by RLC circuit 524. Flow 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 uplink data processing below the RLC Layer.

[0062] As shown in FIG. 5A, MAC circuit 526 may be operative coupled to flow control buffer 528 and configured to process the RLC PDUs stored in flow control buffer 528 to generate the MAC PDUs. The processing of the RLC PDUs/MAC SDUs 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 RLC result statuses (i.e., the result statues from the higher layer - RLC Layer - in the Layer 2 protocol stack) from RLC status queue 536, generate the set of MAC commands based on the set of RLC result statuses, and store/write the set of MAC commands into a MAC command queue 534 in memory 512, such that MAC circuit 526 retrieves/reads 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 the higher layer, i.e., the RLC layer by RLC circuit 524.

[0063] In some embodiments, the functions of MAC circuit 526 in processing the

PDCP PDUs are defined by the 3GPP standards as described above with respect to the MAC Layer in FIG. 3. In some embodiments, when writing data to flow control buffer 528, an offset is reserved at the beginning of flow control buffer 528, such that MAC circuit 526 processes the data packet and fills in the MAC header to form a MAC PDU. 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. 5A, MAC circuit 526 may be further configured to obtain the processing result, for example, once the MAC Layer 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.

[0064] In some embodiments, flow control buffer 528 is further configured to buffer the MAC PDUs generated by MAC circuit 526 to be synchronized with Layer 1 data rate. Different from the known solutions (e.g., in FIG. 4B) in which external memory 406 is used for buffering the data in Layer 2 uplink data processing, Layer 2 circuits 508 in baseband chip 502 perform Layer 2 uplink data processing in an inline manner without access to external memory 506. In order to synchronize the different data rates at Layer 2 and Layer 1 (e.g., different duty cycles at the MAC Layer and PHY layer), flow control buffer 528 may perform the MAC -PHY flow control function by buffering the MAC PDUs. In some embodiments, second DMA channel 518 is operatively coupled to flow control buffer 528 and MAC circuit 526 and configured to transmit the MAC PDUs from flow control buffer 528 to external memory 506 for MAC re-transmission. For example, based on the MAC command from MCU 510, MAC circuit 526 may cause flow control buffer 528 and second DMA channel 518 to pass a copy of the buffered MAC PDUs to external memory 506 as the backup if MAC re-transmission is requested.

[0065] As shown in FIG. 5A, MAC -PHY interface 530 may be operatively coupled to flow control buffer 528 and configured to receive/read the MAC PDUs directly from flow control buffer 528 and output the MAC PDUs to 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 retrieve/read the set of MAC result statuses from MAC status queue 536, generate the set of interface commands based on the set of MAC result statuses, 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. For example, the interface commands may need to be adjusted based on the processing result of MAC circuit 526. In some embodiments, MAC -PHY interface 530 may also receive status signals from the PHY layer, such as the PHY Layer ready signals indicating that the PHY Layer is ready to receive data from Layer 2. In response to the PHY Layer ready signal, MAC -PHY interface 530 may pass the MAC PDUs in transport blocks directly from flow control buffer 528 to the PHY Layer, as well as the status signals indicative of, for example, the start, length, and ID of each transport block and the validity of the data, as controlled by MCU 510. In some embodiments, as controlled by MCU 510, MAC -PHY interface 530 retrieves/reads the data from external memory 506 (e.g., the MAC PDUs stored in extremal memory 506) or local memory 514 (e.g., L2 cache) and passes the data to the PHY Layer for re-transmission (e.g., MAC re-transmission or RLC re-transmission), further transmission, or debugging. As shown in FIG. 5A, MAC -PHY interface 530 may be further configured to obtain the processing result, for example, once the uplink transmission 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.

[0066] Moreover, any additional functions of Layer 2 uplink data processing implemented in known solutions using software modules executed by a generic processor may be replaced by a hardware component, such as an ASIC, as part of Layer 2 circuits 508 in baseband chip 502. In some embodiments, buffer management circuit 532 is configured to manage the buffer for re-transmission. For example, buffer management circuit 532 may assign a region in local memory 514 and/or external memory 506 for storing data for MAC re-transmission or RLC re-transmission. In some embodiments, buffer management circuit 532 is also configured to manage the logical partitions of local memory 514 by dynamically dividing, allocating, and releasing local memory 514 into buffers used as, for example, memory 512 or flow control buffer 528.

[0067] FIG. 6 illustrates a flow chart of an exemplary method 600 for Layer 2 uplink data processing, according to some embodiments of the present disclosure. Examples of the apparatus that can perform operations of method 600 include, for example, baseband chip 502 depicted in FIG. 5A or any other suitable apparatus disclosed herein. It is understood that the operations shown in method 600 are not exhaustive and that other operations can be performed as well before, after, or between any of the illustrated operations. Further, some of the operations may be performed simultaneously, or in a different order than shown in FIG. 6. [0068] Referring to FIG. 6, method 600 starts at operation 602, in which a first set of commands are provided by an MCU to control a PDCP circuit to receive Layer 3 data packets and process the Layer 3 data packets to generate PDCP PDUs. In some embodiments, priorities are assigned to each of the commands in the first set of commands. In some embodiments, the first set of commands are stored into a first command queue in a memory. As shown in FIG. 5A, MCU 510 in baseband chip 502 may provide a set of PDCP commands having priorities to control PDCP circuit 522 to receive the Layer 3 data packets and process the Layer 3 data packets to generate the PDCP PDUs. MCU 510 may store/write the PDCP commands into PDCP command queue 534 in memory 512, such that PDCP circuit 522 may retrieve/read and execute the PDCP commands from PDCP command queue 534 based on the priorities of the PDCP commands. That is, MCU 510 may control the operations of PDCP circuit 522 through the set of PDCP commands.

[0069] Method 600 proceeds to operation 604, as illustrated in FIG. 6, in which a first set of result statuses based on the processing result of the PDCP circuit are received by the MCU. In some embodiments, the first set of result statuses are retrieved/read from a corresponding status queue in the memory. As shown in FIG. 5 A, MCU 510 may receive/read the set of PDCP result statuses indicative of the processing result of PDCP circuit 522. For example, MCU 510 may retrieve/read the set of PDCP result statuses from PDCP status queue 536 in memory 512.

[0070] Method 600 proceeds to operation 606, as illustrated in FIG. 6, in which a second set of commands are provided by the MCU based on the first set of result statuses to control an RLC circuit to process the PDCP PDUs to generate RLC PDUs. In some embodiments, priorities are assigned to each of the commands in the second set of commands. In some embodiments, the second set of commands are stored into a second command queue in a memory. In some embodiments, the second set of commands further control the RLC circuit for RLC re-transmission. As shown in FIG. 5A, MCU 510 may provide a set of RLC commands having priorities to control RLC circuit 524 to process the PDCP PDUs to generate the RLC PDUs. MCU 510 may generate the RLC commands based on the PDCP result statuses from PDCP circuit 522 in a higher layer in Layer 2 protocol stack than the RLC layer. MCU 510 may store/write the RLC commands into RLC command queue 534 in memory 512, such that RLC circuit 524 may retrieve/read and execute the RLC commands from RLC command queue 534 based on the priorities of the RLC commands. That is, MCU 510 may control the operations of RLC circuit 524 through the set of RLC commands.

[0071] Method 600 proceeds to operation 608, as illustrated in FIG. 6, in which a second set of result statuses based on the processing result of the RLC circuit are received by the MCU. In some embodiments, the second set of result statuses are retrieved/read from a corresponding status queue in the memory. As shown in FIG. 5 A, MCU 510 may receive the set of RLC result statuses indicative of the processing result of RLC circuit 524. For example, MCU 510 may retrieve/read the set of RLC result statuses from RLC status queue 536 in memory 512.

[0072] Method 600 proceeds to operation 610, as illustrated in FIG. 6, in which a third set of commands are provided by the MCU based on the second set of result statuses to control a MAC circuit to process the RLC PDUs to generate MAC PDUs. In some embodiments, priorities are assigned to each of the commands in the third set of commands. In some embodiments, the third set of commands are stored into a third command queue in a memory. As shown in FIG. 5 A, MCU 510 may provide a set of MAC commands having priorities to control MAC circuit 526 to process the RLC PDUs to generate the MAC PDUs. MCU 510 may generate the MAC commands based on the RLC result statuses from RLC circuit 524 in a higher layer in Layer 2 protocol stack than the MAC layer. MCU 510 may store/write the MAC commands into MAC command queue 534 in memory 512, such that MAC circuit 526 may retrieve/read and execute the MAC commands from MAC command queue 534 based on the priorities of the MAC commands. That is, MCU 510 may control the operations of MAC circuit 526 through the set of MAC commands.

[0073] Method 600 proceeds to operation 612, as illustrated in FIG. 6, in which a third set of result statuses based on the processing result of the MAC circuit are received by the MCU. In some embodiments, the third set of result statuses are retrieved/read from a corresponding status queue in the memory. As shown in FIG 5 A, MCU 510 may receive the set of MAC result statuses indicative of the processing result of MAC circuit 526. For example, MCU 510 may retrieve/read the set of MAC result statuses from MAC status queue 536 in memory 512.

[0074] Method 600 proceeds to operation 614, as illustrated in FIG. 6, in which a fourth set of commands are provided by the MCU based on the third set of result statuses to control an interface circuit to output the MAC PDUs to Layer 1. In some embodiments, priorities are assigned to each of the commands in the fourth set of commands. In some embodiments, the fourth set of commands are stored into a fourth command queue in a memory. As shown in FIG. 5 A, MCU 510 may provide a set of interface commands having priorities to control MAC -PHY interface 530 to output the MAC PDUs. MCU 510 may generate the interface commands based on the MAC result statuses from MAC circuit 526. MCU 510 may store/write the interface commands into interface command queue 534 in memory 512, such that MAC -PHY interface 530 may retrieve/read and execute the interface commands from interface command queue 534 based on the priorities of the interface commands. That is, MCU 510 may control the operations of MAC -PHY interface 530 through the set of interface commands. For example, the interface commands may control MAC -PHY interface 530 to retrieve/read the MAC PDUs directly from flow control buffer 528 or from external memory 506 for re-transmission, further transmission, or debugging.

[0075] 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.

[0076] According to one aspect of the present disclosure, a baseband chip includes a plurality of Layer 2 circuits and an MCU operatively coupled to the Layer 2 circuits. The Layer 2 circuits are configured to receive Layer 3 data packets and generate MAC PDUs from the Layer 3 data packets in an inline manner. The MCU is configured to control the Layer 2 circuits to generate the MAC PDUs from the Layer 3 data packets through a plurality sets of commands.

[0077] In some embodiments, the Layer 2 circuits include a PDCP circuit configured to receive the Layer 3 data packets and process the Layer 3 data packets to generate PDCP PDUs based on a set of PDCP commands from the MCU, and an RLC circuit operatively coupled to the PDCP circuit and configured to segment or concatenate the PDCP PDUs into RLC PDUs based on a set of RLC commands from the MCU.

[0078] In some embodiments, the PDCP circuit is directly coupled to the RLC circuit without an intermediate buffer.

[0079] In some embodiments, the baseband chip further includes a first DMA channel directly coupled to each of the PDCP circuit and the RLC circuit.

[0080] In some embodiments, the Layer 2 circuits further include an SDAP circuit configured to organize the Layer 3 data packets based on QoS.

[0081] In some embodiments, the Layer 2 circuits further include a flow control buffer operatively coupled to the RLC circuit and configured to store the RLC PDUs, and a MAC circuit operatively coupled to the flow control buffer and configured to process the RLC PDUs stored in the flow control buffer to generate the MAC PDUs based on a set of MAC commands from the MCU.

[0082] In some embodiments, the flow control buffer is further configured to buffer the

MAC PDUs to be synchronized with Layer 1 data rate. [0083] In some embodiments, the baseband chip further includes a second DMA channel operatively coupled to the flow control buffer and configured to transmit the MAC PDUs to an external memory for MAC re-transmission.

[0084] In some embodiments, the Layer 2 circuits further include an interface operatively coupled to the flow control buffer and configured to output the MAC PDUs received from the flow control buffer based on a set of interface commands from the MCU. [0085] In some embodiments, each of the SDAP, PDCP, RLC, and MAC circuits is an

ASIC.

[0086] In some embodiments, the baseband chip further includes a memory operatively coupled to the MCU and the Layer 2 circuits and configured to store the plurality sets of commands into a plurality of command queues to be fetched by at least some of the Layer 2 circuits, respectively.

[0087] In some embodiments, the memory is further configured to receive a plurality sets of result statuses from the at least some of the Layer 2 circuits, and store the plurality sets of result statuses into a plurality of status queues, respectively.

[0088] In some embodiments, the MCU is further configured to retrieve the plurality sets of result statuses from the memory, and generate each set of the commands based on a respective set of the result statuses from one of the Layer 2 circuits at a higher in Layer 2 protocol stack.

[0089] In some embodiments, the commands in each of the command queues have priorities, and each of the at least some of the Layer 2 circuits is configured to fetch and execute the commands in a respective command queue based on the priorities.

[0090] In some embodiments, the Layer 2 circuits are configured to pass data through the Layer 2 circuits without storing the data in an external memory.

[0091] According to another aspect of the present disclosure, a baseband chip includes a PDCP circuit, an RLC circuit, a flow control buffer, and a MAC circuit. The PDCP circuit is configured to receive Layer 3 data packets and process the Layer 3 data packets to generate PDCP PDUs. The RLC circuit is configured to receive the PDCP PDUs directly from the PDCP circuit and segment or concatenate the PDCP PDUs into RLC PDUs. The flow control buffer is configured to receive the RLC PDUs directly from the RLC circuit and store the RLC PDUs. The MAC circuit is configured to process the RLC PDUs stored in the flow control buffer to generate MAC PDUs.

[0092] In some embodiments, each of the PDCP, RLC, and MAC circuits is an ASIC.

[0093] In some embodiments, the flow control buffer is further configured to buffer the

MAC PDUs to be synchronized with Layer 1 data rate.

[0094] In some embodiments, the baseband chip further includes a direct DMA channel configured to transmit the MAC PDUs from the flow control buffer to an external memory for MAC re-transmission.

[0095] In some embodiments, the baseband chip further includes an interface configured to receive the MAC PDUs directly from the flow control buffer and output the MAC PDUs to Layer 1.

[0096] In some embodiments, the baseband chip further includes an SDAP circuit configured to organize the Layer 3 data packets based on QoS.

[0097] In some embodiments, the baseband chip further includes a memory configured to receive a plurality sets of result statuses from the PDCP, RLC, and MAC circuits, respectively, and store the plurality sets of result statuses into a plurality of status queues, respectively. In some embodiments, the baseband chip further includes an MCU configured to retrieve the plurality sets of result statuses from the memory, generate a set of commands for each of the PDCP, RLC, and MAC circuits based on a respective set of result statuses from one of the PDCP, RLC, and MAC circuits at a higher layer in Layer 2 protocol stack, and control each of the PDCP, RLC, and MAC circuits through a respective set of the commands.

[0098] In some embodiments, the memory is further configured to store the plurality sets of commands into a plurality of command queues, respectively.

[0099] In some embodiments, the commands in each of the command queues have priorities, and each of the PDCP, RLC, and MAC circuits is configured to fetch and execute the commands in a respective command queue based on the priorities.

[00100] According to still another aspect of the present disclosure, a method for Layer 2 uplink data processing is disclosed. A first set of commands are provided by an MCU to control a PDCP circuit to receive Layer 3 data packets and process the Layer 3 data packets to generate PDCP PDUs. A first set of result statuses based on the processing result of the PDCP circuit are received by the MCU. A second set of commands are provided by the MCU based on the first set of result statuses to control an RLC circuit to process the PDCP PDUs to generate RLC PDUs. A second set of result statuses based on the processing result of the RLC circuit are received by the MCU. A third set of commands are provided by the MCU based on the second set of result statuses to control a MAC circuit to process the RLC PDUs to generate MAC PDUs.

[00101] In some embodiments, a third set of result statuses based on the processing result of the MAC circuit are received by the MCU, and a fourth set of commands are provided by the MCU based on the third set of result statuses to control an interface to output the MAC PDUs to Layer 1.

[00102] In some embodiments, to provide each set of the commands, priorities are assigned to each of the commands.

[00103] In some embodiments, to provide each set of the commands, the respective set of the commands are stored into a corresponding command queue in a memory.

[00104] In some embodiments, to receive each set of the result statuses, the respective set of the result statuses are retrieved from a corresponding status queue in a memory.

[00105] In some embodiments, the second set of commands further control the RLC circuit for RLC re-transmission.

[00106] According to yet another aspect of the present disclosure, a method for Layer 2 uplink data processing is disclosed. Layer 3 data packets are processed by a PDCP circuit to generate PDCP PDUs. The PDCP PDUs are directly received by an RLC circuit from the PDCP circuit. The PDCP PDUs are segmented or concatenated by the RLC circuit into RLC PDUs. The RLC PDUs are directly received by a flow control buffer from the RLC circuit. The RLC PDUs are stored by the flow control buffer. The RLC PDUs stored in the flow control buffer are processed by a MAC circuit to generate MAC PDUs.

[00107] In some embodiments, the MAC PDUs are buffered by the flow control buffer to be synchronized with Layer 1 data rate.

[00108] In some embodiments, the MAC PDUs are transmitted by a DMA channel from the flow control buffer to an external memory for MAC re-transmission.

[00109] In some embodiments, the MAC PDUs are received by an interface directly from the flow control buffer, and the MAC PDUs are outputted by the interface to Layer 1. [00110] In some embodiments, the Layer 3 data packets are organized by a SDAP circuit based on QoS.

[00111] 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.

[00112] 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.

[00113] 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.

[00114] 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.

[00115] 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.