Modular 5g ue layer 2 data stack solution for high throughput and low latency data transmission

Abstract

Methods and related devices for providing layer 2 data stack solutions in a data plane are provided. In some embodiments, the method includes (i) determining which of a selectable plurality of data stack solutions to select, and (ii) causing a layer 2 microcontroller to intervene with data plane hardware modules configured to implement particular layer 2 data stack functions in accordance with the selected layer 2 data stack solution. Each of the plurality of data stack solutions represents a unique intervention configuration of the layer 2 microcontroller. The layer 2 microcontroller is coupled to a plurality of data plane hardware modules configured to implement different layer 2 data stack functions. The intervention configuration of the layer 2 microcontroller indicates a level of control of the layer 2 microcontroller over the data plane hardware modules.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 036,736, filed June 9, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of communications, and more specifically, to wireless communication systems, methods, and apparatus. Background Technology

[0004] The rapid development of computing technology has created greater demand for data communications. This increased demand, in turn, drives further development of communication technologies, often requiring additional features, increased processing power, and / or increased resources within a given space. This growth frequently introduces new challenges. The traditional 3GPP Layer 2 data stack is tightly coupled with the protocol stacks of the physical layer, Layer 3 / 4, and control plane. There is no clear distinction between functional areas for packet operations based on their layer or processing requirements. The challenge for 5G (the fifth-generation technology standard for broadband cellular networks) modems is designing data path architectures that support high-throughput and extremely low-latency packet applications. Traditional software packet data processing solutions cannot meet the demands of 5G packet data, and these traditional solutions require high-cost processors with complex software designs. Therefore, an improved approach to meeting this demand is desirable. Summary of the Invention

[0005] This disclosure provides a highly adaptable and programmable 5G User Equipment (UE) Layer 2 data stack solution. The Layer 2 data stack solution is customizable and can be implemented using data plane hardware (DPHW, comprising multiple hardware modules), a data plane microcontroller (μC), a control plane processor, or a combination thereof. This Layer 2 data stack solution can be used in 4G (fourth-generation technology standard for broadband cellular networks), 5G, and / or future communication systems, providing high throughput, low latency, and seamless Quality of Service (QoS) packet operation. For example, this disclosure enables UE manufacturers / vendors to customize and integrate their 4G / 5G Layer 2 data stack offerings to meet customer needs.

[0006] Telecommunications architecture typically comprises three basic components: the data plane (DP), the control plane (CP), and the management plane (MP). The control and management planes serve the data plane. The data plane carries user traffic and can be named the user plane, forwarding plane, carrier plane, or bearer plane. The management plane configures and monitors all layers of the network stack and other parts of the system, providing management, monitoring, and configuration services. The control plane controls routing tasks, which determine which path to use to send packets or frames. For example, the control plane adds data to routing tables, network topology, and forwarding tables to enable data plane functionality. (Reference) Figure 1 Examples of telecommunications architecture are discussed in detail.

[0007] This Layer 2 data stack solution is implemented in the network's data plane. More specifically, this Layer 2 data stack solution provides a microcontroller and data plane hardware configured to implement Layer 2 data stack functionality. The data plane hardware may include multiple hardware components to implement different Layer 2 data stack functions. The microcontroller can be configured to manage and control multiple hardware components of the data plane hardware. Therefore, the microcontroller can verify, monitor, or "intervene" in the implementation of Layer 2 data stack functionality through the data plane hardware. With this arrangement, this disclosure provides flexible Layer 2 data stack design for various types of user equipment. Reference Figure 3 , Figure 4 and Figure 5 An implementation of the Layer 2 data stack solution is discussed in detail.

[0008] This disclosure provides various application programming interfaces (APIs) for communicating with the control plane or other communication layers. For example, this Layer 2 data stack solution includes (i) a Data Path Control (DPC) API configured to communicate with or connect to the DPC layer of the control plane via an interface; (ii) a Layer 3 / Layer 4 API configured to communicate with or connect to the Layer 3 or Layer 4 data stack in the data plane via an interface; and / or (iii) a Physical Layer (PHY) API configured to communicate with or connect to the PHY subsystem via an interface. References Figures 2A-2B An implementation of the Layer 2 data stack solution is discussed in detail.

[0009] One aspect of this disclosure is that it enables UE vendors / manufacturers to customize the performance and control of downlink (DL) and uplink (UL) communications, thereby improving flexibility and system efficiency. (Reference) Figure 3 This paper discusses in detail an embodiment of DL communication in this Layer 2 data stack solution. (Reference) Figure 4 An embodiment of UL communication in this Layer 2 data stack solution is discussed in detail.

[0010] Another aspect of this disclosure is a method for implementing a Layer 2 data stack solution. The method includes, for example, (i) communicating with the DPC layer of the control plane via the DPC API of the Layer 2 data stack solution; (ii) communicating with the Layer 3 or Layer 4 data stack via the Layer 3 / Layer 4 API of the Layer 2 data stack solution; and (iii) communicating with the PHY subsystem via the PHY API of the Layer 2 data stack solution. The method may include storing information associated with the Layer 2 data stack solution in Layer 3 external memory or L2 local memory. The stored information can be accessed via the API.

[0011] In some embodiments, the method may be implemented via a tangible, non-transitory computer-readable medium storing processor instructions that, when executed by one or more processors, cause one or more processors to perform one or more schemes / features of the method described herein. Attached Figure Description

[0012] To more clearly describe the technical solutions in the embodiments of this disclosure, the accompanying drawings are briefly described below. The drawings only illustrate some aspects or embodiments of this disclosure, and those skilled in the art can still derive other drawings from these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of a wireless communication system according to one or more embodiments of the present disclosure.

[0014] Figure 2A This is a schematic diagram illustrating elements of a network architecture according to one or more embodiments of the present disclosure.

[0015] Figure 2B This is a schematic diagram of a network architecture according to one or more embodiments of the present disclosure.

[0016] Figure 3 This is a schematic diagram illustrating a downlink (DL) data transmission process according to an embodiment of the present disclosure.

[0017] Figure 4 This is a schematic diagram illustrating an uplink (UL) data transmission process according to an embodiment of the present disclosure.

[0018] Figure 5 This is a flowchart of a method according to one or more embodiments of the present disclosure.

[0019] Figure 6 This is a schematic block diagram of a terminal device according to one or more embodiments of the present disclosure. Detailed Implementation

[0020] The technical solutions of one or more embodiments of this disclosure are described below. This disclosure provides a Layer 2 data stack solution for a terminal device. This Layer 2 data stack solution is implemented in the data plane of a network. This Layer 2 data stack solution provides: a Data Path Control (DPC) API configured to communicate with or interface with the DPC layer of the control plane; a Layer 3 / Layer 4 API configured to communicate with or interface with the Layer 3 or Layer 4 data stack in the data plane; and / or a Physical Layer (PHY) API configured to communicate with or interface with the PHY subsystem. The Layer 2 data stack solution is customizable and can be implemented using data plane hardware (DPHW), a data plane microcontroller (μC), a control plane processor, or a combination thereof.

[0021] Communication environment

[0022] Figure 1 A wireless communication system 100 for implementing this Layer 2 data stack solution is shown. For example... Figure 1 As shown, the wireless communication system 100 may include network device 101. Examples of network device 110 include base transceiver stations (BTS), Node Bs (NBs), evolved Node Bs (eNBs or eNodeBs), next-generation Node Bs (gNBs or gNode Bs), Wi-Fi access points (APs), etc. In some embodiments, network device 110 may include relay stations, access points, vehicle-mounted devices, wearable devices, etc. Network device 110 may include wireless connectivity devices for communication networks, such as: Global System for Mobile Communications (GSM) networks, Code Division Multiple Access (CDMA) networks, Wideband CDMA (WCDMA) networks, LTE networks, Cloud Radio Access Networks (CRAN), IEEE 802.11-based networks (e.g., Wi-Fi networks), Internet of Things (IoT) networks, Device-to-Device (D2D) networks, next-generation networks (e.g., 5G networks), and Public Land Mobile Networks (PLMNs) for Future Evolution, etc. 5G systems or networks may be referred to as New Radio (NR) systems or networks.

[0023] like Figure 1As shown, the wireless communication system 100 also includes a terminal device 103. The terminal device 103 may be an end-user device configured to facilitate wireless communication. The terminal device 103 may be configured to wirelessly connect to the network device 101 according to one or more corresponding communication protocols / standards (e.g., via wireless channel 105). The terminal device 103 may be mobile or fixed. The terminal device 103 may be a user equipment (UE), access terminal, user unit, user station, mobile site, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user device. Examples of terminal devices 103 include modems, cellular phones, smartphones, cordless phones, Session Initiation Protocol (SIP) phones, Wireless Local Loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, Internet of Things (IoT) devices, terminal devices in future 5G networks, terminal devices in future evolved PLMNs, or similar devices.

[0024] For the purpose of explanation, Figure 1 Only one network device 101 and one terminal device 103 are shown in the wireless communication system 100. However, it will be understood that in some instances, the wireless communication system 10 may include additional / other devices, such as network device 101 and / or terminal device 103, network controllers, mobility management entities / devices, etc.

[0025] Wireless communication architecture

[0026] Figure 2A This is a schematic diagram illustrating elements of a network architecture 20A for a UE protocol stack 200 according to one or more embodiments of the present disclosure. The UE protocol stack 200 is configured to communicate with an application or host layer 22 and a physical layer (PHY) subsystem 24. For example, the UE protocol stack 200 may communicate with the application layer 22 via Internet Protocol (IP) packets. As another example, the UE protocol stack 200 communicates with the PHY subsystem 24 via Media Intervention Control (MAC) Protocol Data Unit (PDU) packets.

[0027] As shown in the figure, the UE protocol stack 200 includes a control plane 201 and a data plane 203. The control plane 201 handles functions such as Non-Access Stratum (NAS) functions and Radio Resource Control (RRC) functions. NAS functions handle network layer control, such as mobility management, session management, security management, and system selection. RRC functions handle radio resource allocation and configuration, radio channel control for radio bearers (and logical channels), and security (such as encryption and integrated configuration).

[0028] Data plane 203 is configured to process layer 2 (L2) and layer 3 / layer 4 (L3 / L4) functions (in Figure 2A This is represented as L3 / L4 data stack 26). Layer 2 functions relate to 3GPP protocols for packet data processing. In the illustrated embodiment, the Layer 2 functions are implemented by Layer 2 data stack solution 205.

[0029] like Figure 2A As shown, the Layer 2 data stack solution 205 can handle functions for the MAC layer, Radio Link Control (RLC) layer, Packet Data Convergence Protocol (PDCP) layer, and Service Data Adaptation Protocol (SDAP) layer. The MAC layer involves network multiplexing and demultiplexing, as well as mapping logical channels to transport channels. The RLC layer involves Automatic Repeat Request (ARQ) at the radio link level and error recovery for each logical channel. The PDCP layer involves packet-level processing for data encryption, integrity, and compression. The SDAP layer involves Quality of Service (QoS) classification (e.g., mapping QoS flows to corresponding data radio bearers). In the data plane 203, Layers 3 and 4 involve IP-related functions such as IP header extraction, IP checksums, IP tracing, IP routing, and classification.

[0030] In the illustrated embodiment, the Layer 2 data stack solution 205 can be implemented by the UE's main processor (e.g., a modem), data plane hardware (DPHW), data plane microcontroller (μC), control plane processor, or a combination thereof. Reference Figure 2B Discuss the details of Layer 2 data stack solution 205.

[0031] Figure 2B This is a schematic diagram of a network architecture 20B for a UE protocol stack 202 according to one or more embodiments of the present disclosure. The UE protocol stack 202 is configured to communicate with the application or host layer 22 and the physical layer (PHY) 24. As shown, the UE protocol stack 202 includes a control plane 201 and a data plane 203. In some embodiments, the UE protocol stack 200 can be used for a UE, such as a modem.

[0032] Control plane 201 is controlled by the UE's main processor 207. Main processor 207 is configured to handle NAS and RRC functions. Main processor 207 is also configured to handle data path control (DPC) via DPC layer 209. Through DPC layer 209, control plane 201 can control and communicate with data plane 203. The UE may include external memory 211, which is configured to store information associated with data plane 203. Application layer 22 and data plane 203 can access the information stored in external memory 211.

[0033] Data plane 203 is configured to process layer 2 (L2) and layer 3 / layer 4 (L3 / L4) functions (in Figure 2B This is represented as L3 / L4 data stack 26). Layer 2 functions relate to 3GPP protocols for packet data processing. In the illustrated embodiment, Layer 2 data stack solution 205 handles Layer 2 functions.

[0034] like Figure 2B As shown, the Layer 2 data stack solution 205 includes a Data Path Control (DPC) API 2051 for communicating with the DPC layer 209 of the control plane 201 (in... Figure 2B (Represented as "C1" in Chinese). The Layer 2 data stack solution 205 also includes L3 / L4 API 2052 for communicating with the L3 / L4 data stack 26 (in... Figure 2B (Represented as "C2" in Chinese). The Layer 2 data stack solution 205 also includes PHY API 2053 for communicating with the PHY subsystem 24 (in... Figure 2B (referred to as "C3" in Chinese). Through these APIs 2051, API 2052, and API 2053, the Layer 2 data stack solution 205 enables UE vendors or manufacturers to customize the functionality of the Layer 2 data stack.

[0035] For example, in some embodiments, the Layer 2 data stack solution 205 may include Layer 2 hardware (L2 HW) 213 configured to handle Layer 2 functions such as SDAP, PDCP, RLC, and MAC functions. In some embodiments, the Layer 2 hardware 213 may be automated hardware that can automatically execute the aforementioned functions based on preset instructions. In some embodiments, the Layer 2 data stack solution 205 may include a Layer 2 microcontroller 215 configured to implement at least a portion of the Layer 2 functions. The Layer 2 data stack solution 205 may also include Layer 2 local memory 216 to store information associated with the Layer 2 data stack solution 205.

[0036] In some embodiments, at least a portion of the Layer 2 functionality can be implemented by the main processor 207. Through APIs 2051, 2052, and 2053, the Layer 2 data stack solution 205 enables Layer 2 functionality to be implemented by Layer 2 hardware 213, microcontroller 215, main processor 207, or a combination thereof. For example, by adjusting the amount of local cache storage on main processor 207, main processor 207 can partially implement Layer 2 functionality.

[0037] Data Path Control (DPC) API

[0038] The Data Path Control (DPC) API 2051 is configured to interface with the DPC layer 209 of the control plane 201 to allow access to the L2 microcontroller 215 or the Layer 2 (L2) local memory. Figures 2A-2B The RRC parameters are configured in the DPCAPI 2051 (not shown in the diagram). The DPCAPI 2051 is also configured to interface with the main processor 207 via the DPC layer 209. The DPC layer 209 can consolidate data plane-related control parameters and route them to the L2 microcontroller 215 or L2 local memory in the data plane 203. For example, these control parameters may include signaling radio bearer queues and parameters, data radio bearer queues and parameters, logical channel queues and parameters, RLC parameters (e.g., window size, sequence bit length, RLC mode (AM / UM / TM), etc.), MAC linkage control packet (LCP) parameters (LCP bucket size, rate, maximum size, etc.), PDCP security key parameters (e.g., encryption and integrity keys for RRC), PDCP robust header compression (RoHC) and uplink data compression (UDC) parameters (e.g., RoHC profile and parameters), and / or other suitable configuration data.

[0039] L3 / L4 Data Stack API

[0040] L3 / L4 API 2052 is configured to interface with L3 / L4 data stack 26. L3 / L4 API 2052 may include downlink (DL) data path interoperability APIs and uplink (UL) data path interoperability APIs. L3 / L4 API 2052 may also include DL packet descriptor information, which can be passed from Layer 2 data stack solution 205 to L3 / L4 data stack 26. L3 / L4 API 2052 may also include UL packet descriptor information, which can be passed from L3 / L4 data stack 26 to Layer 2 data stack solution 205.

[0041] In some embodiments, DL / UL packet descriptor information can be stored in L3 external memory 211, while the corresponding layer 2 and / or layer 3 data queues are stored in L2 microcontroller 215 or L2 local memory. This arrangement allows for flexible allocation of controller / memory storage space to improve overall efficiency.

[0042] In some embodiments, during the UL / DL process, the L3 / L4 API 2052 can be used to transmit logical channel packet descriptors. For example, during the DL process, the L3 / L4 API 2052 may include DL data paths for each component carrier (CC), L2 packet descriptors, L2 radio bearer queues, etc. During the UL process, the L3 / L4 API 2052 may include L3 packet descriptors, L3 IP flow queues, L2 logical channel queues (e.g., RLC status, RLC retransmission queues, etc.), L2 MAC control element (CE) queues, etc.

[0043] PHY API

[0044] PHY API 2053 is configured to interoperate with the UE's PHY layer 24. PHY API 2053 may include handshake signals (e.g., processed by a microcontroller) to control the direct flow of data bytes between local buffers or memories of the layer 2 data stack solution. PHY API 2053 includes a UL PHY API and a DL PHY API. The DL PHY API includes a DL data path (e.g., after successful decoding of the PHY DL from a DL Hybrid Automatic Repeat Request (HARQ)) indicating information such as PHY-to-MAC layer code block data bytes. The UL PHY API includes a UL data path (e.g., when the PHY is ready to pull data for transmission) indicating information such as MAC-to-PHY layer code block data bytes.

[0045] Based on the aforementioned arrangement, the Layer 2 data stack solution 205 can provide a customizable data pattern solution for packet data transmission of both DL and UL, with effective and desired performance and control. These customizable data pattern solutions allow the UE vendor or manufacturer to determine the details regarding how to use various processors / controllers to process Layer 2 functions. For example, Layer 2 functions can be automatically executed by automated data plane hardware (e.g., Layer 2 hardware 213). Figure 3 and Figure 4 The discussion in untie Solution "A" In some cases, the implementation of Layer 2 functionality can be controlled by a microcontroller (e.g., an L2 microcontroller 215). Figure 3 and Figure 4 The discussion in Solution "B" In some embodiments, Layer 2 functionality can be implemented in hybrid mode using Data Path Control (DPC) software and the APIs provided by Layer 2 data stack solution 205. Figure 3 and Figure 4 The discussion in Solution Case "C" ).

[0046] Figure 3 This is a schematic diagram illustrating a downlink (DL) data transmission process 30 of a UE according to one or more embodiments of the present disclosure. Figure 3 In the diagram, data flow is indicated by bold arrows. Dashed arrows indicate processes involving APIs, while solid arrows indicate data processing steps. For example... Figure 3 As shown, in the downlink (DL) data transmission process 30, data is transmitted from the network (NW) 38 to the application program (AP) 32 via the physical layer 34 and L2 / L3 / L4 layers of the UE protocol stack 300. The UE protocol stack 300 includes: (1) a control plane 301 configured to control data transmission; and (2) a data plane 303 configured to transmit / process data transmission.

[0047] Control plane 301 performs NAS, RRC, and DPC functions (as referenced above). Figure 2A and Figure 2B The data plane 305 includes an L2 data plane solution 305 and an L3 / L4 data stack 36. The L2 data plane solution 305 includes data plane hardware (DPHW) configured to perform SDAP, PDCP, RLC, and MAC layer functions (as described above). Figure 3 (represented as SDAPHW, PDCP HW, RLC HW, and MAC HW).

[0048] The L2 data plane solution 305 includes an L2μC microcontroller configured to control the data plane hardware (DPHW) and execute APIs related to the L2 data plane solution 305 (e.g., as described above). Figure 2A and Figure 2B The L3 / L4 API, PHY API, and DPC API discussed in the document have functionalities. The UE may include the main processor ( Figure 3 (not shown in the diagram) and L3 external memory 311. L3 external memory 311 is configured to store information associated with L2 data plane solution 305.

[0049] After establishing an RRC connection (i.e., enabling packet data transmission), the L2 data plane solution 305 begins receiving block data bytes from the PHY layer 34. These data bytes can be streamed into the local L2 buffer within the L2 data plane solution 305. The L2 data plane solution 305 then processes these data bytes, performing MAC decoding and header extraction, and generating packet descriptors for the remaining L2 layers. The processed packets and their descriptors are sent to the L3 / L4 data stack 36 via the L3 / L4 API. Finally, the processed packets and their descriptors are sent to the L3 / L4 data stack via the L3 / L4 API.

[0050] The L2 data plane solution 305 provides configurable and programmable DL mode settings, including various implementation types. For ease of illustration, refer to... Figure 3 Three examples (Solution A, Solution B, and Solution C) and their corresponding processes are discussed.

[0051] Downlink Solution A: Automatic Data Plane Hardware (DPHW)

[0052] In this solution, the L2 data plane solution 305 performs fast processing using a fully automated DPHW layer. During configuration setup, the L2 data plane solution 305 is programmed using semi-static parameters for the radio bearer, logical channel, and MAC layer. Once the PHY code block bytes are received, the MAC layer hardware (MAC HW) decodes the byte stream to extract the "MAC header" and "MAC sub-PDU (sub-protocol data unit)," and then forwards the packet to the RLC layer hardware (RLC HW), which then extracts the "RLC header," such as... Figure 3 In Step 31 As shown. The RLC layer hardware (RLC HW) then performs RLC packet processing, including desegmentation and reassembly, deconcatenation, reordering, and RLC ARQ for radio link recovery.

[0053] Once the RLC packet bytes are extracted, they are forwarded to the PDCP layer hardware (PDCP HW), where PDCP packet processing is performed (e.g., decryption, integrity checks, RoHC header decompression, etc.). Figure 3 In Step 33 As shown.

[0054] Once completed, the data bytes are transferred to L3 external memory 311 (indicated by the bold arrow). Then, the SDAP layer hardware (SDAP HW) takes over, performs QoS classification, and routes the packets to the L3 / L4 data stack 36.

[0055] Downlink Solution B: Microcontroller-Controlled DPHW

[0056] In this solution, the MAC layer hardware (MAC HW) receives data bytes from the PHY layer 34. Then, with the support of the L2μC microcontroller, the remaining DP layer hardware (i.e., RLC HW, PDCP HW, and SDAP HW) processes the data bytes. For example, as... step 35 and step 37 As shown, the process moves between the DPHW and the L2μC microcontroller. This provides greater flexibility in controlling the DPHW at each layer, enabling (1) the addition of additional custom processing at each layer; and / or (2) the control of timing and routing at each layer.

[0057] Downlink Solution C: Hybrid Data Path Control (DPC) Software

[0058] In this solution, the UE's vendor or manufacturer can choose to run their own asynchronous data plane control functions, such as "RLC ARQ status reporting," "radio bearer release and / or pause and rebuild," and "logical channel release and / or pause and rebuild." This can be accomplished by the UE's main processor through the data path control (DPC) functions of control plane 301 and the DPCAPI. When these asynchronous control functions are executed, the corresponding functions of the L2 data plane solution 305 are temporarily disabled.

[0059] It is worth noting that, despite Figure 3 Only solutions A, B, and C are discussed, but these solutions are merely examples and are not intended to be limiting in any way. For example, although in Figure 3 In solutions B and C, the microcontroller interacts with or intervenes in the processes of the RLC HW, but in other embodiments, the microcontroller may interact with or intervene in the processes of other components of the data plane hardware.

[0060] Figure 4 This is a schematic diagram illustrating an uplink (UL) data transmission process 40 according to one or more embodiments of the present disclosure. Figure 4 In the diagram, data flow is indicated by bold arrows. Dashed arrows indicate processes involving APIs, while solid arrows indicate data processing steps. For example... Figure 4 As shown, in the UL data transmission process 40, data is transmitted from the application program (AP) 42 to the network (NW) 48 via the physical layer 44 and L2 / L3 / L4 layers of the UE protocol stack 400. The UE protocol stack 400 includes: (1) a control plane 401 configured to control data transmission; and (2) a data plane 403 configured to transmit / process data transmission.

[0061] Control plane 401 performs NAS, RRC, and DPC functions (as referenced above). Figure 2A and Figure 2B (As discussed). Data plane 405 includes an L2 data plane solution 405 and an L3 / L4 data stack 46. The L2 data plane solution 405 includes data plane hardware (DPHW) configured to perform SDAP, PDCP, RLC, and MAC layer functions (in Figure 4 The L2 data plane solution 405 is represented as SDAP HW, PDCPHW, RLC HW, and MAC HW. The L2 data plane solution 405 includes an L2μC microcontroller configured to control the data plane hardware (DPHW) and execute APIs related to the L2 data plane solution 405 (e.g., as described above). Figure 2A and Figure 2BThe L3 / L4 API, PHY API, and DPC API discussed herein. The UE may include the main processor ( Figure 4 (not shown) and L3 external memory 411. L3 external memory 411 is configured to store information associated with L2 data plane solution 405.

[0062] After establishing an RRC connection (i.e., enabling packet data transmission), the L3 / L4 data stack 46 begins receiving IP packets from the application 42. The IP packets are processed and stored in the L3 external memory 411. L3 packet descriptors can be sent to the L2 data plane solution 405 (e.g., via the L3 / L4 API to the SDAP HW) to perform IP QoS classification on a specified radio bearer queue in the microcontroller L2μC or L2 local memory. Step 41 ).

[0063] The L2 data plane solution 405 provides configurable and programmable UL mode settings, including various implementation types. For ease of illustration, refer to... Figure 4 Three examples (solutions A, B, and C) and their corresponding processes are discussed.

[0064] Uplink: Solution A: Automated Data Plane Hardware (DPHW)

[0065] In this solution, the MAC layer hardware (part of the DPHW) receives the "UL grant," extracts the grant size, and kicks in the MAC LCP process, specifying the layers, functions, and logical channels enabled for this "UL grant." The DPHW autonomously runs the MAC LCP process, including: (i) dequeuing packet descriptors from the logical channel and radio bearer queues in L2 local memory. Step 43 (ii) Transfer data bytes from L3 external memory 411, (iii) Process the data bytes through PDCPROHC, UDC compression, encryption, integrity check, and add PDCP, RLC and MAC headers (step 45), and (iv) When retrieving the data, put the data bytes into a buffer (e.g., in L2 local memory) before streaming the data bytes to PHY layer 44.

[0066] Uplink: Solution B: Microcontroller-controlled DPHW

[0067] In this solution, the microcontroller L2μC receives the "UL authorization" (step 44), and then executes the MAC LCP process to compose a packet list for the MAC PDU packet. It controls the DPHW to perform HW functions at each layer. Steps a and b ), and integrate the results for PHY layer 44 for transmission ( Step 45).

[0068] Uplink: Solution C: Hybrid Data Path Control (DPC) Software

[0069] In this solution, the UE's vendor or manufacturer can choose to run their own asynchronous data plane control functions, such as "UL MAC Random Access," "UL MAC Scheduling Request," and "UL MAC Control Element (CE) Request." This can be accomplished by the UE's main processor through the Data Path Control (DPC) function and DPC API of control plane 301. When these asynchronous control functions are executed, the corresponding functions of L2 data plane solution 305 are temporarily disabled. In these embodiments, the corresponding packet descriptor requests (e.g., for the relevant radio bearer, connectivity control, MAC CE queue, etc.) will be placed in L2 local memory.

[0070] It is worth noting that, despite Figure 4 Only solutions A, B, and C are discussed, but these solutions are merely examples and are not intended to be limiting in any way. For example, although in Figure 4 In Solutions B and C, the microcontroller interacts with or intervenes in the processes of the SDAP HW, but in other embodiments, the microcontroller may interact with or intervene in the processes of other components of the data plane hardware.

[0071] Figure 5 This is a flowchart of a method 500 according to one or more embodiments of the present disclosure. Method 500 is used to implement Layer 2 network communication in the data plane. Method 500 can be used to design a data stack architecture for an L2 data stack used in telecommunications equipment.

[0072] At block 501, method 500 includes determining which Layer 2 data stack solution to select from a plurality of selectable data stack solutions. Each of the plurality of data stack solutions represents a unique intervention configuration of the Layer 2 microcontroller. Examples of Layer 2 functionality include functions related to Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and / or Media Access Control (MAC).

[0073] Each of the multiple data stacks includes a microcontroller, local memory, and data plane hardware to implement layer 2 data stack functionality. Data plane hardware modules may include, for example, SDAP hardware modules, PDCP hardware modules, RLC hardware modules, and MAC hardware modules (e.g., Figure 3 and Figure 4(SDAP HW, PDCP HW, RLC HW, and MAC HW in the context of multiple data stack solutions). Different solutions within multiple data stack solutions can have different types of data plane hardware modules. A microcontroller can be configured to manage or intervene in the processes of the data plane hardware modules (e.g., the implementation of layer 2 data stack functionality). In other words, different data stack solutions can have different levels of control or unique "intervention" capabilities or "intervention" configurations.

[0074] For example, in some embodiments, unique intervention configurations could be "microcontroller intervening in the processes of the RLC hardware module," "microcontroller intervening in the processes of the SDAP hardware module and the RLC hardware module," "microcontroller monitoring the processes of the PDCP hardware module," and "the main processor instructing the microcontroller to intervene in the processes of the RLC hardware module," etc. Multiple data stacks can include uplink and downlink solutions. Examples of downlink solutions can be found in... Figure 3 Examples of uplink solutions can be found there. Figure 4 Found it.

[0075] In some embodiments, data stack solutions with “low” intervention capability allow data plane hardware to automatically implement Layer 2 data stack functions with minimal supervision from the microcontroller. Examples of data stack solutions with low intervention capability include Figure 3 and Figure 4 The discussion in Solution A In some embodiments, the microcontroller may be configured to monitor, verify, or supervise one or more of the Layer 2 data stack functions performed by the data plane hardware, based on instructions stored in the local memory of the Layer 2 data stack solution.

[0076] In some embodiments, a data stack solution with "moderate" intervention capability allows the microcontroller to intervene in at least a portion of the data plane hardware when implementing layer 2 data stack functionality. Examples of data stack solutions with moderate intervention capability include... Figure 3 and Figure 4 The discussion in Solution B In such embodiments, the microcontroller can be configured to intervene in one or more of the layer 2 data stack functions performed by the data plane hardware, based on instructions stored in the local memory of the layer 2 data stack solution.

[0077] In some embodiments, a data stack solution with “high” intervention capability can enable external control of the microcontroller. For example, through the Data Path Control (DPC) layer in the control plane and the DPC API of the data stack solution in the data plane, an external processor (e.g., a modern processor) can instruct the microcontroller to intervene in at least a portion of the data plane hardware when implementing layer 2 data stack functionality. Examples of data stack solutions with medium intervention capability include… Figure 3 and Figure 4 The discussion in Solution C Examples of DPC layers include Figure 2B The DPC layer is shown below. Examples of the DPC API include... Figure 2B The DPC API 2051 shown is provided by the Layer 2 data stack solution. It allows for various communication methods with the DPC layer in the control plane.

[0078] At block 503, method 500 includes, based on a selected layer 2 data stack solution, causing a layer 2 microcontroller to intervene in data plane hardware modules configured to implement specific layer 2 data stack functions. In some embodiments, the layer 2 microcontroller is coupled to multiple data plane hardware modules configured to implement different layer 2 data stack functions. In some embodiments, the intervention configuration of the layer 2 microcontroller indicates the level of control the layer 2 microcontroller exerts over the data plane hardware modules.

[0079] For example, when designing for clients that require high intervention capabilities, one can choose from multiple data stack solutions similar to [the one mentioned above]. Figure 3 and Figure 4 Solution C discussed earlier. Similarly, when designing for clients requiring moderate or low intervention capabilities, a similar solution can be selected from multiple data stack options. Figure 3 and Figure 4 The solution discussed is either solution B or solution C.

[0080] In some embodiments, in addition to the DPC APIs discussed above, the Layer 2 data stack solution may further include: (i) a Layer 3 or Layer 4 API for communicating with the Layer 3 / Layer 4 data stack, and (ii) a physical layer API for communicating with the PHY subsystem. In some embodiments, the microcontroller may be configured to control communication via these APIs.

[0081] Examples of layer 3 / layer 4 data stacks include Figure 2A and Figure 2B The L3 / L4 data stack shown is 26. Figure 3 The L3 / L4 data stack 36 shown is Figure 4 The L3 / L4 data stack 46 is shown in the diagram. Examples of the Layer 3 / Layer 4 API include... Figure 2BThe L3 / L4 API 2052 is shown. The L3 / L4 API provided by the L2 data stack solution allows for various ways of communicating with the L3 / L4 data stack. For example, in downlink (DL) processes (e.g., Figure 3 ) or uplink (UL) process (e.g. Figure 4 In this context, the L3 / L4 API can be used by microcontrollers in Layer 2 data stack solutions to communicate with the L3 / L4 data stack.

[0082] Examples of PHY subsystems include Figure 2A and Figure 2B The PHY subsystem 24 shown is Figure 3 The PHY layer 34 shown is Figure 4 The PHY layer 44 is shown. Examples of PHY APIs include... Figure 2B The PHY API 2053 is shown. The PHY API provided by the Layer 2 data stack solution allows for communication with the PHY subsystem in various ways. For example, in the downlink (DL) process (e.g. Figure 3 In this context, the PHY API can be used by the data plane hardware (e.g., MAC HW) of a Layer 2 data stack solution to communicate with the PHY subsystem. As another example, in the uplink (UL) process (e.g.... Figure 4 In this context, the PHY API can be used for communication between the microcontroller or data plane hardware (e.g., MAC HW) of a Layer 2 data stack solution and the PHY subsystem.

[0083] In some embodiments, information associated with the Layer 2 data stack solution (e.g., signals, parameters, etc.) may be stored in external memory (outside the Layer 2 data stack solution). In some embodiments, the external memory may be the memory of a user device (e.g., a modern device, mobile device, etc.) that communicates using the Layer 2 data stack solution. The information associated with the Layer 2 data stack stored in the external memory may be accessed via the application layer or the host layer. In some embodiments, data plane hardware may also access the information stored in the external memory. In some embodiments, information associated with the Layer 2 data stack is stored in the local memory of the Layer 2 data stack solution (e.g., coupled to and controlled by a microprocessor). In some embodiments, information associated with the Layer 2 data stack may be stored in both local memory and external memory.

[0084] In some embodiments, the microcontroller can send (or receive) parameters to (or from) the data plane hardware to control / verify its execution of Layer 2 data plane functions. This arrangement allows the Layer 2 data stack solution to efficiently manage the data plane hardware, thereby executing customized functions. In some embodiments, the microcontroller can coordinate the processes of the data plane hardware so that they can be executed in a specific order.

[0085] Example devices and systems

[0086] Figure 6 This is a schematic block diagram of a terminal device 600 according to one or more embodiments of the present disclosure (e.g., Figure 1 Example of terminal device 103). Figure 6 As shown, the terminal device 600 includes a processing unit 610 (e.g., DSP, CPU, GPU, etc.) and a memory 620. The processing unit 610 can be configured to implement... Figure 5 Method 500 and / or instructions corresponding to other aspects of the above embodiments.

[0087] It should be understood that the processor in the embodiments of this technology can be an integrated circuit chip and has signal processing capabilities. In the embodiments, the steps in the above methods can be implemented using integrated logic circuits in the processor hardware or instructions existing in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components. The methods, steps, and logic block diagrams disclosed in the embodiments of this technology can be implemented or executed. A general-purpose processor can be a microcontroller, or the processor can be any conventional processor or similar processor. The steps in the methods disclosed with reference to the embodiments of this technology can be directly executed or completed by a decoding processor implemented as hardware, or executed or completed by using a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above methods.

[0088] It is understood that the memory in the embodiments of this technology can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM) and used as an external cache. For illustrative and non-limiting purposes, various forms of RAM can be used, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), dual data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct Rambus random access memory (DR RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these memories and any other suitable types of memory.

[0089] The above detailed description of the disclosed technical examples is not intended to be exhaustive or to limit the disclosed technology to the precise forms disclosed above. Although specific examples of the disclosed technology have been described above for illustrative purposes, various equivalent modifications can be made within the scope of said technology, as will be recognized by those skilled in the art. For example, while processes or blocks are presented in a given order, alternative implementations may execute routines with steps in a different order, or employ systems with blocks, and some processes or blocks may be deleted, moved, added, subdivided, combined, and / or modified to provide alternative implementations or sub-combinations. Each of these processes or blocks can be implemented in a variety of different ways. Furthermore, while processes or blocks are sometimes shown as being executed sequentially, these processes or blocks may be executed or implemented in parallel, or may be executed at different times. Moreover, any specific figures mentioned herein are merely examples; alternative implementations may use different values ​​or ranges.

[0090] In the detailed description, numerous specific details are set forth to provide a thorough understanding of the technology described herein. In other embodiments, the technology described herein can be practiced without these specific details. In other instances, well-known features, such as specific functions or routines, have not been described in detail to avoid unnecessarily obscuring this disclosure. In this specification, references to “implementation / embodiment,” “an embodiment / embodiment,” etc., mean that a particular feature, structure, material, or characteristic described is included in at least one embodiment of the described technology. Therefore, such phrases appearing in this specification do not necessarily refer to the same implementation / embodiment. On the other hand, such references are not necessarily mutually exclusive. Furthermore, particular features, structures, materials, or characteristics can be combined in any suitable manner in one or more implementations / embodiments. It should be understood that the various embodiments shown in the figures are merely illustrative representations and are not necessarily drawn to scale.

[0091] For clarity, this document does not list some details describing the structure or process, which are well-known and generally related to communication systems and subsystems, but may unnecessarily obscure some important aspects of the disclosed technology. Furthermore, although the following disclosure sets forth several embodiments of different aspects of this disclosure, other embodiments may have different configurations or different components than those described in this section. Therefore, the disclosed technology may have other embodiments with additional elements or without several of the elements described below.

[0092] Many embodiments or aspects of the techniques described herein can take the form of computer or processor executable instructions, including routines executed by a programmable computer or processor. Those skilled in the art will understand that the techniques can be practiced on computer or processing systems other than those shown and described below. The techniques described herein can be implemented in special-purpose computers or data processors specifically programmed, configured, or constructed to execute one or more of the computer-executable instructions described below. Therefore, the terms “computer” and “processor” as commonly used herein refer to any data processor. Information processed by these computers and processors can be displayed on any suitable display medium. Instructions for performing computer or processor executable tasks can be stored on or on any suitable computer-readable medium, including hardware, firmware, or a combination of hardware and firmware. Instructions can be contained in any suitable storage device, including flash drives and / or other suitable media.

[0093] This document uses the terms “link” and “connection” and their derivatives to describe structural relationships between components. It should be understood that these terms are not intended to be synonyms. Rather, in specific implementations, “connection” can be used to indicate direct contact between two or more elements. Unless explicitly stated otherwise in the context, the term “link” can be used to indicate direct or indirect contact between two or more elements (and other intermediate elements between them), or that these two or more elements cooperate or interact with each other (e.g., in a causal relationship, such as for signal transmission / reception or for function calls), or both. The term “and / or” in this specification is used only to describe the association relationship between related objects and indicates that three relationships may exist; for example, A and / or B can represent three cases: A exists alone, both A and B exist, and B exists alone.

[0094] These and other modifications can be made to the disclosed technology based on the specific embodiments described above. While the specific embodiments describe certain examples of the disclosed technology and the best modes contemplated, the disclosed technology can be practiced in many ways, no matter how detailed the foregoing description appears in the text. The details of the system may vary considerably in its specific embodiments, but are still included in the technology disclosed herein. As noted above, the specific terminology used when describing certain features or aspects of the disclosed technology should not be construed as implying that the term is redefined herein as limited to any particular characteristic, feature, or aspect of the disclosed technology associated with that term. Therefore, the invention is not limited except by the appended claims. Generally, the terminology used in the following claims should not be construed as limiting the disclosed technology to the specific examples disclosed in the specification, unless these terms are expressly defined in the foregoing specific embodiments section.

[0095] Those skilled in the art will recognize that, in conjunction with the examples described in the embodiments disclosed in this specification, the units and algorithm steps can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether the function is performed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but should not consider that the implementation is beyond the scope of this application.

[0096] While certain aspects of the invention are presented hereinafter in the form of certain claims, the applicant considers all aspects of the invention to be in any number of claims. Therefore, the applicant reserves the right to pursue additional claims after the filing of this application, either in this application or in a continuing application.

Claims

1. A method for implementing Layer 2 network communication in a data plane, the method comprising: determining, among a selectable plurality of data stack solutions, which Layer 2 data stack solution to select, wherein each of the plurality of data stack solutions represents a unique intervention configuration of a Layer 2 microcontroller, the unique intervention configuration comprising the microcontroller intervening in a process of a radio link control (RLC) hardware module, the microcontroller intervening in a process of a service data adaptation protocol (SDAP) hardware module and the RLC hardware module, the microcontroller monitoring a process of a packet data convergence protocol (PDCP) hardware module, and a host processor instructing the microcontroller to intervene in a process of the RLC hardware module; and causing, in accordance with the selected Layer 2 data stack solution, the Layer 2 microcontroller to intervene in data plane hardware modules configured to implement particular Layer 2 data stack functions, wherein the Layer 2 microcontroller is coupled to a plurality of data plane hardware modules configured to implement different Layer 2 data stack functions, and wherein the intervention configuration of the Layer 2 microcontroller indicates a level of control of the Layer 2 microcontroller over the data plane hardware modules; wherein the plurality of data stack solutions comprises a plurality of downlink (DL) solutions; wherein the plurality of DL solutions includes a solution in which the microcontroller is configured to monitor the Layer 2 data stack functions implemented automatically by the data plane hardware.

2. The method of claim 1, wherein, the data plane hardware modules comprise: an SDAP hardware module; a PDCP hardware module; an RLC hardware module; and / or a medium access control (MAC) hardware module.

3. The method of claim 1, wherein, the Layer 2 microcontroller can be configured to intervene in one or more of the Layer 2 data stack functions performed by the data plane hardware modules based on instructions stored in a local memory of the Layer 2 data stack solution.

4. The method of claim 1, wherein, the microcontroller can be configured to intervene in one or more of the Layer 2 data stack functions performed based on instructions received from a host processor of the control plane via a data path control (DPC) layer of the control plane and a DPC application program interface (API) of the Layer 2 data stack solution.

5. The method of claim 1, wherein, the plurality of DL solutions further includes a solution in which the Layer 2 microcontroller is configured to intervene in RLC functions of the Layer 2 data stack functions performed by a radio link control (RLC) hardware module.

6. The method of claim 1, wherein, the plurality of DL solutions further includes a solution in which the Layer 2 microcontroller is configured to intervene in RLC functions of the Layer 2 data stack functions performed by a radio link control (RLC) hardware module in response to instructions received from a host processor of the control plane via a data path control (DPC) layer of the control plane and a DPC application program interface (API) of the Layer 2 data stack solution.

7. The method of claim 1, wherein, the plurality of data stack solutions further includes a plurality of uplink (UL) solutions.

8. The method of claim 7, wherein, the plurality of UL solutions includes a solution in which the microcontroller is configured to monitor the Layer 2 data stack functions implemented automatically by the data plane hardware.

9. The method of claim 7, wherein, The multiple UL solutions include a solution in which the microcontroller is configured to intervene in Radio Link Control (RLC) functions of the Layer 2 data stack functions performed by Radio Link Control (RLC) hardware of the data plane hardware.

10. The method of claim 7, wherein, The multiple UL solutions include a solution in which the microcontroller is configured to intervene in Radio Link Control (RLC) functions of the Layer 2 data stack functions performed by Radio Link Control (RLC) hardware of the data plane hardware in response to instructions received from a master processor of the control plane via a Data Path Control (DPC) layer of the control plane and a DPC Application Program Interface (API) of the Layer 2 data stack solution.

11. The method of claim 1, wherein, The microcontroller can be configured to: coordinate communication with a Layer 3 or Layer 4 data stack via a Layer 3 / Layer 4 Application Program Interface (API); and coordinate communication with a physical layer (PHY) subsystem via a PHY API.

12. The method of claim 1, further comprising: storing information associated with the Layer 2 data stack solution in an external memory.

13. The method of claim 12, further comprising: accessing information associated with the Layer 2 data stack stored in the external memory via an application layer.

14. The method of claim 12, further comprising: accessing information associated with the Layer 2 data stack stored in the external memory by the data plane hardware.

15. The method of claim 1, further comprising: storing information associated with the Layer 2 data stack solution in a local memory coupled to the microcontroller.

16. The method of claim 15, further comprising: accessing information associated with the Layer 2 data stack stored in the local memory by a master processor of the control plane via a Data Path Control (DPC) layer of the control plane and a DPC Application Program Interface (API) of the Layer 2 data stack solution.

17. A terminal device, comprising: a memory; and a processor coupled to the memory and configured to: determine which Layer 2 data stack solution to select among a plurality of selectable data stack solutions, wherein each of the plurality of data stack solutions represents a unique intervention configuration of a Layer 2 microcontroller, the unique intervention configuration comprising the microcontroller intervening in processes of RLC hardware modules, the microcontroller intervening in processes of SDAP hardware modules and RLC hardware modules, the microcontroller monitoring processes of PDCP hardware modules, and a master processor instructing the microcontroller to intervene in processes of RLC hardware modules; and cause the Layer 2 microcontroller to intervene in data plane hardware modules configured to implement particular Layer 2 data stack functions in accordance with the selected Layer 2 data stack solution, wherein the Layer 2 microcontroller is coupled to a plurality of data plane hardware modules configured to implement different Layer 2 data stack functions, and wherein the Layer 2 microcontroller is configured to intervene in processes of the data plane hardware modules in accordance with the selected Layer 2 data stack solution. wherein the intervention configuration of the layer 2 microcontroller indicates a level of control of the layer 2 microcontroller over the data plane hardware modules, and wherein the data plane hardware modules comprise service data adaptation protocol (SDAP) hardware, packet data convergence protocol (PDCP) hardware, radio link control (RLC) hardware, and medium access control (MAC) hardware; wherein the multiple data stack solutions comprise multiple downlink (DL) solutions; and wherein the multiple DL solutions comprise a solution in which the microcontroller is configured to monitor the layer 2 data stack functions that are automatically implemented by the data plane hardware.

18. A non-transitory computer-readable medium having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to implement the instructions to perform a method comprising: determining, among a plurality of selectable data stack solutions, which layer 2 data stack solution to select, wherein each of the plurality of data stack solutions represents a unique intervention configuration of a layer 2 microcontroller, the unique intervention configuration comprising the microcontroller intervening in processes of RLC hardware modules, the microcontroller intervening in processes of SDAP hardware modules and RLC hardware modules, the microcontroller monitoring processes of PDCP hardware modules, and a host processor instructing the microcontroller to intervene in processes of RLC hardware modules; and causing, in accordance with the selected layer 2 data stack solution, the layer 2 microcontroller to intervene in data plane hardware modules configured to implement particular layer 2 data stack functions, wherein the layer 2 microcontroller is coupled to multiple data plane hardware modules configured to implement different layer 2 data stack functions, and wherein the intervention configuration of the layer 2 microcontroller indicates a level of control of the layer 2 microcontroller over the data plane hardware modules; wherein the multiple data stack solutions comprise multiple downlink (DL) solutions; wherein the multiple DL solutions comprise a solution in which the microcontroller is configured to monitor the layer 2 data stack functions that are automatically implemented by the data plane hardware.

Images