Offloading MAC / link layer functions

Abstract

The present disclosure relates to offloading MAC / link layer functions. A wireless device is disclosed, comprising: a processor circuit; and a hardware circuit configured to implement MAC / LL functions without intervention of the processor circuit during an active steady state of a medium access control / link layer (MAC / LL) with scheduled channel access, wherein the steady state is a state of no control packet transmission for a managed connection in connection-oriented communication, or a continuous broadcast or scanning operation in connectionless communication.

Description

Technical Field

[0001] The present disclosure relates to offloading MAC / link layer functions. Background Art

[0002] A Wireless Sensor / Actrator Network (WSAN) is a set of sensors that collect information about its environment and communicate wirelessly with actuators that interact with the environment. In many cases, WSAN devices are power-constrained, which imposes restrictions on the wireless communication subsystems in such devices. There is a general incompatibility between design flexibility and low power consumption requirements for the implementation of the Medium Access Control / Link Layer (MAC / LL), i.e., Layer 2 of the protocol stack.

[0003] Wireless connection protocols with scheduled channel access are very common in wearable devices and WSANs in the Internet of Things (IoT). In WSANs, slave nodes (sensors or actuators) have a low wireless activity duty cycle; as an example, in some cases, fast connections present a duty cycle of about 2%, while slow connections present a duty cycle of about 0.02%. Therefore, wireless idle time power optimization is an important key performance indicator (KPI) factor. This optimization is inherent in the MAC / LL design because the real-time mechanisms that handle the air interface protocols in wireless connections are related to the MAC / LL. The upper layers of the protocol stack are decoupled from the air interface timing and are coupled to the host application execution time. Therefore, the MAC / LL design is the main focus for optimizing wireless idle time power consumption.

[0004] In order to reduce the Time-To-Market (TTM) of WSAN equipment, conventional systems use a programmable central processing unit (CPU) (e.g., a general purpose processor (GPP), a microcontroller unit (MCU), etc.), and implement most MAC / LL protocols as software that relies on a real-time control environment (e.g., a real-time operating system (RTOS)). In such a system, idle time power consumption is mainly determined by CPU dynamic power consumption (CPU performs processing when the air interface is idle) and leakage power from persistent subsystems (e.g., retained memory) when the CPU is idle.

[0005] While the main power consumption of these conventional systems during radio active periods comes from the physical layer (PHY), during radio idle periods the PHY is turned off and the main power consumption is generated by the MAC / LL, i.e., from CPU execution and power leakage due to programs / data that need to be maintained in memory. For protocols with low radio activity duty cycles, radio idle period power consumption significantly increases the overall power budget. Summary of the invention

[0006] An embodiment of the present disclosure provides a wireless device, comprising: a processor circuit; and a hardware circuit configured to implement a medium access control / link layer (MAC / LL) function without intervention of the processor circuit during an active stable state of the MAC / LL with scheduled channel access, wherein the stable state is a state of no control packet transmission for a managed connection in connection-oriented communication or a continuous broadcast or scanning operation in connectionless communication.

[0007] An embodiment of the present disclosure also provides a method for wireless communication, comprising: implementing MAC / LL functions by hardware circuits without intervention of processor circuits during an active stable state of a medium access control / link layer (MAC / LL) with scheduled channel access, wherein the stable state is a state of no control packet transmission for a managed connection in connection-oriented communication or a continuous broadcast or scanning operation in connectionless communication.

[0008] An embodiment of the present disclosure also provides a wireless device, comprising: a processor circuit; and a hardware device for implementing a medium access control / link layer (MAC / LL) function without intervention of the processor circuit during an active stable state of the MAC / LL with scheduled channel access, wherein the stable state is a state of no control packet transmission for a managed connection in connection-oriented communication or a continuous broadcast or scanning operation in connectionless communication. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A schematic diagram of a medium access control / link layer (MAC / LL) architecture is shown in accordance with aspects of the present disclosure.

[0010] Figure 2 A functional static view of a MAC / LL architecture in accordance with aspects of the present disclosure is shown.

[0011] Figure 3-1 A. Figure 3-1 B and Figure 3-1 C shows a functional dynamic view of the traditional MAC / LL architecture.

[0012] Figure 3-2 A. Figure 3-2 B and Figure 3-2 C shows a generalized dynamic view of the steady state of the MAC / LL architecture according to aspects of the present disclosure.

[0013] Figure 3-3 A. Figure 3-3 B and Figure 3-3 C shows an extended dynamic view of the steady state of the MAC / LL architecture according to aspects of the present disclosure.

[0014] Figure 4 A schematic diagram is shown of an example implementation of Bluetooth Low Energy (BLE) for a MAC / LL architecture in a multi-processor System-on-Chip (SoC) in accordance with aspects of the present disclosure.

[0015] Figure 5 A schematic diagram is shown of an example implementation of Bluetooth Low Energy (BLE) for a MAC / LL architecture in a single processor System on Chip (SoC) in accordance with aspects of the present disclosure.

[0016] Figure 6 A schematic diagram illustrating an overview of a Maximum Offload BLE Controller (MO-BLE Controller) according to aspects of the present disclosure.

[0017] Figure 7 A timeline of the Baseband Resource Manager (BB-RM) timing scheme is shown.

[0018] Figure 8 is a schematic diagram of the general Link Event Sequencing (LES) circuit and Scheduling Data Structure (SDS).

[0019] Fig. 9 This is a schematic diagram of the LES engine.

[0020] Fig. 10A -C shows three different corresponding modes of scheduling data structure (SDS) scheduling.

[0021] Fig.11 A flow chart showing a control sequence of a link event execution sequence controller.

[0022] Fig.12 A timing diagram showing LES engine power saving and wake-up.

[0023] Fig.13 It is a schematic diagram of HCI handler unloading.

[0024] Fig.14 A schematic diagram of the link controller hardware circuit is shown.

[0025] Fig.15A timing diagram showing the Link Controller LE event action sequencing.

[0026] Fig.16 A flow chart showing a Link Control State Machine (LCSM) sequence. DETAILED DESCRIPTION

[0027] The present disclosure relates to a low-power medium access control link layer (MAC / LL) that minimizes central processing unit (CPU) intervention and software memory footprint, thereby maximizing continuous, uninterrupted CPU sleep cycles. The architecture of the MAC / LL protocol according to aspects of the present disclosure relies on generic MAC / LL functionality offloaded from the CPU to hardware circuits.

[0028] For the purpose of description, the architecture in the present disclosure focuses on the Bluetooth Low Energy (LE) protocol. However, the present disclosure is not limited in this regard. The concepts of the present disclosure can be alternatively applied to other wireless connection protocols with scheduled channel access, such as Bluetooth (BT), ANT, Long Range (LoRa), etc.

[0029] I. Architecture Overview

[0030] An important scenario for optimization (as it can extend battery life) is the power consumption during the steady state of communication transmission (because this state may last for a long time, up to several days). The "steady state" of communication transmission is a non-standard term. For connection-oriented communication, it is a "stable state" when all connections have a stable schedule and configuration and the main purpose of the transmission is to exchange upper-layer user traffic payload; the stable state is destroyed when an existing connection must be reconfigured, a new connection needs to be established, or a connection is disconnected at the request of the upper layer (above the MAC / LL) or at the request of the MAC / LL of the peer device. For connectionless communication, it is a "stable state" when there is a continuous broadcast / scanning operation, in which the MAC / LL reports the discovered devices or the scanned packet data units (PDUs) to the upper layer (higher than the MAC / LL); the stable state is destroyed when the upper layer requests to end the stable state, or receives a specific PDU (for example, for a connection request, etc.).

[0031] The architecture of this disclosure is based on at least the following five principles:

[0032] First, hardware circuits implement protocol real-time mechanisms that are common to most wireless connection protocols with scheduled channel access within a limited reconfigurable range. These circuits offload the CPU to reduce CPU active time and software memory usage.

[0033] Second, the software (CPU) executes the strategy in advance to create a stored microcontroller for the hardware circuit, and the hardware circuit executes the microcontroller on the fly. Once created, the stored microcontroller can be executed many times, for example, during a long period of time when the CPU is not active.

[0034] Third, some hardware circuits are always-on (AON domain), while other circuits are power managed (PM domain). The AON domain is responsible for sequencing the power states of the modules in the PM domain; the CPU can remain asleep during this power sequencing.

[0035] Fourth, when all hardware circuits are implemented, the steady-state operation of the MAC / LL protocol can be performed without CPU intervention. As a result, minimal power consumption can be achieved, as if the entire MAC / LL protocol was implemented in hardware, without losing flexibility.

[0036] Fifth, for specific scenarios when portions of the MAC / LL protocol are not implemented (ie, when the wireless device is only an observer or only a broadcaster, etc.), the architecture enables certain functionality to be disabled.

[0037] Figure 1 A schematic diagram of a medium access control / link layer (MAC / LL) architecture 100 is shown in accordance with aspects of the present disclosure.

[0038] The architecture 100 may be referred to as a Maximum Offload MAC / LL (MO-MACLL) architecture. The MO-MACLL architecture 100 is optimized to reduce power consumption (ie, CPU execution time and software memory footprint) during the steady state (defined above) of the MAC / LL.

[0039] The MO-MACLL architecture 100 offloads the MAC / LL functionality from the CPU to two hardware parts - the always-on domain (AON domain) 110 and the power-managed domain (PM domain) 120. The PM domain 120 operates only during the active state of the MAC / LL and offloads the complete air interface protocol; the rest of the time the PM domain 120 is powered off. The AON domain 110 is active throughout the steady-state operation (both the active and idle states of the MAC / LL) and is configured to set up the PM domain 120 while continuously serving the host. The host is defined as an upper layer above the MAC / LL.

[0040] Figure 2A functional static view of MO-MACLL 200 is shown, which represents a detailed view of architecture 100. MO-MACLL 200 can manage multiple communication transmissions simultaneously. For connection-oriented communication, according to various aspects of the present disclosure, MO-MACLL 200 can manage multiple connection-oriented transmissions simultaneously. For connectionless communication, MO-MACLL 200 can manage multiple connectionless transmissions simultaneously, and each connectionless transmission can be used only for broadcasting, announcing acceptance of data requests and supporting data responses, announcing acceptance of connection requests, scanning (sniffing) only, scanning to support data requests and accepting data responses, or scanning to support connection requests. Unless otherwise specified, the features of MO-MACLL 200 described herein are applicable to both connection-oriented transmissions and connectionless transmissions, so the term connection (conn-#, where # represents a connection identifier) ​​will be used to refer to both concepts.

[0041] Each of the two parts (AON domain 210 and PM domain 220) encapsulates multiple MAC / LL common functions. Functions related to the AON domain 212, 214, 216 (corresponding to 110) are depicted in dark grey, while functions related to the PM domain 221, 240 (corresponding to 120) are depicted in light grey.

[0042] The AON domain 210 encapsulates three main functions - a radio access scheduling sequencer 214, a host agent 212, and a PDU queue and context selector (multiplexer) 216 (which is controlled by the radio access scheduling sequencer 214). The AON domain 210 encapsulates multiple persistent data structures for each managed connection-oriented or connectionless transmission (conn-#), that is, these data structures will retain their values ​​even if the PM domain 120 is powered off. The persistent data structures that exist for each managed connection are: the connection's data PDU queue (one incoming and one outgoing) 230-# (where # represents the connection identifier), the connection's control PDU queue (one incoming and one outgoing) 232-# (where # represents the connection identifier), and the connection's context 234-# (where # represents the connection identifier). Each managed connection context 234-# includes the configuration, state, and micro-controls corresponding to the corresponding managed connection (conn-#). For the case of connectionless transfer, the connected context 234-# (where # represents the connectionless transfer identifier) ​​will include a peer device address data structure as part of the configuration.

[0043] The radio access scheduling sequencer 214 is part of the control plane of the MAC / LL and is configured to handle the sequencing of active and idle states of the MAC / LL protocol during steady-state operation. The radio access scheduling sequencer 214 controls the sharing of the transmission sequencer 221 and the address analyzer 240 between multiple connections (connection-#) managed by the device in a time-multiplexed manner according to the software-defined radio access schedule 236. In order to share the transmission sequencer 221 and the address analyzer 240 between multiple managed connections, the radio access scheduling sequencer 214 controls the selector (multiplexer) 216 to select the data PDU queue 230-#, the control PDU queue 232-#, and the connection context 234-# corresponding to the currently served connection (conn-#). The radio access scheduling sequencer 214 handles the power sequencing of the transmission sequencer 221 and the address analyzer 240 according to the radio access schedule 236, selects the currently served connection context and queue, and triggers their execution within the allowed amount of time. The radio access schedule sequencer 214 may also pass other protocol-specific configuration information (which may be encoded in the radio access schedule 236) when triggering the execution of the transmission sequencer 221 and the address analyzer 240. The radio access schedule sequencer 214 may sequence a single radio access schedule, or sequence multiple radio access schedules simultaneously, both of which allow support for multiple simultaneous connections. If multiple simultaneous connections are to be supported in a single radio access schedule 236, the schedule itself must encode information about the number of radio access rejections that each connection will suffer due to the schedule. If there are multiple radio access schedules for simultaneous execution, the radio access schedule sequencer 214 handles conflict resolution between simultaneous radio access schedule executions, while keeping track of the number of radio access rejections that each managed connection has suffered, and updating this information in the corresponding radio access schedule (as needed). The radio access schedule sequencer 214 can be configured to handle timing correction (window widening for connection-oriented transmissions) and time randomization (quasi-periodicity or backoff for connectionless transmissions) on a per-connection basis as part of active / idle sorting, and in such a configuration the radio access schedule sequencer 214 is capable of updating the radio access schedule 236.

[0044] The host agent 212 is part of the data plane of the MAC / LL and is configured to handle data PDU exchanges with the upper layer (i.e., the host). The host agent 212 controls the message transmission to / from the host, handles the message type parsing for all incoming messages from the host (i.e., data messages and command messages), and automatically handles the data message flow control to / from the host, but delegates the CPU to parse / generate command / event messages and their flow control from / to the host. The host agent 212 can also be configured to automatically generate event messages while maintaining a stable state and send event messages to the host to send reports when it is necessary to support connectionless communication (i.e., when managing connectionless transmission).

[0045] The PM domain 220 offloads all real-time transport mechanisms from the CPU which can be reused by all managed connections during their active state according to the MAC / LL protocol. The PM domain 220 encapsulates two main functions - a transport sequencer 221 and an address analyzer 240 .

[0046] The transmit sequencer 221 is responsible for performing all required functions for reliably exchanging packet data units (PDUs) over the air with one or more peer devices in a micro-controllable manner, thereby providing the desired flexibility. In order to reuse the transmit sequencer 221 for different connections, the transmit sequencer 221 needs to be provided with a connection context 234-#, i.e., a set of state updateable variables, configuration variables, and micro-controls specific to the connection that can persist between activity periods (i.e., during power cycles).

[0047] The transmit sequencer 221 encapsulates the data path 222, air interface sequencer 224, flow controller 226, receive flow filter 228, and transmit flow selector 229, which represent functions that are offloaded from the CPU during steady state.

[0048] The data path 222 is configured to perform PDU packetization and bitstream processing via the currently selected connection context 234-#. The data path 222 can be micro-controlled to perform any bitstream processing tasks (e.g., cyclic redundancy check (CRC), forward error correction (FEC), scrambling, encryption, etc.) and packetization of the bitstream for transmission, as well as the reverse operation for reception, with different options for each task (e.g., different polynomials, seeds, keys, etc.). The data path 222 can have state variables stored in the currently selected connection context 234-# to allow it to update bitstream processing related variables (which can evolve over time when the protocol requires (e.g., CRC initialization, scrambling initialization, etc.)

[0049] The air interface sequencer 224 is configured to sequence air send, receive, and wait operations through the currently selected connection context 234-#; waiting is required to implement inter-packet spacing, etc. The air interface sequencer 224 handles all dynamic parameters of the air interface specified by the protocol (e.g., channel hopping rules, inter-packet spacing rules, send and receive alternation rules, etc.). These dynamic parameters represent state variables for the air interface sequencer 224, which are stored in the currently selected connection context 234-#. The air interface sequencer 224 can drive the reconfiguration of the PHY based on the air interface dynamic parameters. Depending on the requirements of the protocol, the air interface sequencer 224 can be programmed to follow different sequences through the currently selected connection context 234-#.

[0050] The flow controller 226 is configured to discard duplicate receive PDUs through the currently selected connection context 234-#, and to track which transmit PDUs have been acknowledged by the peer device in order to remove those transmit PDUs from the corresponding transmit PDU queues. The flow controller 226 is also capable of creating empty packets (no PDUs) to keep packet switching via the air interface going. The flow controller 226 can be programmed to use different flow control mechanisms, such as ACK / NACK, sliding window, sequence number, credit-based, etc., through the currently selected connection context 234-#. The flow controller 226 has state variables stored in the currently selected connection context 234-# for tracking the flow control state between active time periods (i.e., power cycles).

[0051] The transmit stream selector 229 is configured to arbitrate between outstanding transmit data PDUs and control PDUs through the currently selected connection context 234-#. The transmit stream selector 229 can also be programmed to use different rules through the currently selected connection context 234-#, such as priority, polling, deadline-based, first-come-first-served, barriers, etc. The transmit stream selector 229 can also be programmed to filter outgoing data PDUs or control PDUs based on their age, i.e., allowing PDUs to have validity dates.

[0052] The receive flow filter 228 is configured by the currently selected connection context 234-# to separate the receive PDU into a data flow and a control flow, because the control PDU will usually disrupt the stable state, i.e., wake up / interrupt the CPU to delegate control. The receive flow filter 228 can be programmed by the currently selected connection context 234-# to parse the PDU and search for specific field values ​​to perform specific tasks, such as filtering packets during the discovery phase of the WSAN, or for connectionless data exchange.

[0053] The transmit stream selector 229 and the receive stream filter 228 may have a shared state stored in the currently selected connection context 234-# to implement complex flow behaviors related to both the transmit direction and the receive direction. An example of such complex flow behaviors is a barrier mechanism. The barrier mechanism allows the transmit stream selector 229 to create a virtual barrier at any position (e.g., head, tail, or a specific middle position) of the currently selected outgoing data PDU queue or outgoing control PDU queue. Whenever the barrier is reached on the queue, other PDUs in the queue will not be selected for transmission before the barrier is removed. Barriers can be set or removed by a specific type of outgoing control PDU (by programming the transmit stream selector 229 to parse packets and create barriers when such PDUs are found), or by a specific type of incoming control PDU (by programming the receive stream filter 228 to parse packets and create barriers when such PDUs are found). The CPU may also set or remove barriers when a stable state is lost. Barriers are useful for implementing protocol-specific processes and restrictions; for example, link layer encryption processes in Bluetooth low energy. To support connectionless communication, the transmit stream selector 229 and the receive stream filter 228 may interact with the address analyzer 240 to implement PDU flow control operations depending on the peer device address, for example, receive stream blocking depending on the peer device address, transmit stream blocking depending on the peer device address, or transmit stream selection depending on the peer device address.

[0054] The address analyzer 240 is responsible for performing all device address-based analysis, filtering, and reporting decision operations to achieve connectionless communication support. The address analyzer interacts with the transmit stream selector 229 and the receive stream filter 228 to obtain PDU type information and device address information from the PDUs flowing through 229 and 228, and uses this information to evaluate the relevant incoming PDU filtering strategy, outgoing PDU implementation strategy, and peer device (to the host) reporting strategy. In order to reuse the address analyzer 240 for different connectionless transmissions, the address analyzer 240 needs to be provided with a connection context 234-#, that is, a set of state updateable variables, configuration variables, and microcontrols dedicated to connectionless transmission, which can persist between active time periods (i.e., during power cycles). Although the device address data structure (which specifies a set of peer device addresses with similar permissions) can be represented as a configuration variable in the connection context 234-#, the filtering, enabling, and reporting strategies are more flexibly represented as microcontrols in the connection context 234-#.

[0055] The address analyzer 240 is optional. If offloading is not required for connectionless communication, the address analyzer may be omitted.

[0056] The CPU software process (depicted as a circle with a circular arrow inside) is responsible for connection management tasks, including connection creation and setup, connection context initialization, connection context update, and connection teardown. When the CPU performs management tasks, the MO-MACLL 200 is not in steady state operation, and the CPU is responsible for driving the MAC / LL operation, i.e., directly driving the execution of the transmission sequencer 221 and the address analyzer 240 (i.e., replacing the function of at least the radio access scheduling sequencer 214). In contrast, when the MO-MACLL 200 is in steady state operation, it executes autonomously when the CPU is idle, so no software processes are executed. The connection (connection-oriented transmission or connectionless transmission) management process is described in the MO-MACLL 200 with the label conn-#mngt.

[0057] When a condition that ends / destroys the stable state is detected, the AON domain 210 and the PM domain 220 can wake up / interrupt the CPU. For the purpose of accounting for stable state destroying conditions and enabling multiple such conditions to occur while maintaining order and preventing different conditions from masking each other, an event queue 250 can be included in the architecture. The wake-up / interrupt signaling will cause the CPU to wake up and resume management of the device, while the event queue 250 will save the data needed by the CPU to understand what it needs to do. This process is depicted in MO-MACLL 200 as a software process marked with device mngmnt 260.

[0058] Figure 3 (include Figure 3-2 A. Figure 3-2 B. Figure 3-2 C. Figure 3-3 A. Figure 3-3 B. and Figure 3-3 C and tradition Figure 3-1 A. Figure 3-1 B. and Figure 3-1 C) shows a functional dynamic view of the MO-MACLL architecture 200, and its details are distributed over nine figures, the first three of which relate to the traditional MAC / LL architecture.

[0059] In summary, Figure 3 It shows how the CPU generates (or updates) the corresponding configuration and microcontrol for the hardware circuit when entering the steady state operation, which enables the CPU to continue to sleep during the steady state operation. Compared with the traditional architecture, the architecture of the present disclosure significantly increases the power saving of the CPU. Figure 3-1 In contrast to the traditional architecture shown, Figure 3-2 and Figure 3-3 It is also shown how all hard real-time tasks are completely offloaded from the CPU, resulting in simplified software / firmware with a reduced memory footprint, thereby ultimately reducing memory leakage power and CPU dynamic power.

[0060] Figure 3-1 (include Figure 3-1 A. Figure 3-1 B. and Figure 3-1 C) shows a functional dynamic view of a conventional MAC / LL architecture. This is a CPU driven implementation without MAC / LL offloading as disclosed herein.

[0061] Figure 3-2 (include Figure 3-2 A. Figure 3-2 B. and Figure 3-2 C) shows a generalized dynamic view of the steady state of the MO-MACLL architecture 200 according to aspects of the present disclosure. The AON domain 210 is shown as a single component (labeled AON) that controls the power sequencing of the packet transfer sequencer 221 (including 222, 224, 226, 228 and 229) and the single power managed component of the PHY. The braces represent the steady state operating mode, that is, the periodic execution sequence that repeats indefinitely while the device remains in steady state operation. Figure 3-2 In the example, the label cntx_id is used to refer to the connection identifier (conn-#) of the corresponding connection context (234-#).

[0062] Figure 3-3 (include Figure 3-3 A. Figure 3-3 B. and Figure 3-3 C) shows an extended dynamic view of the steady state of the MO-MACLL architecture according to various aspects of the present disclosure. Individual functions and layers are shown in these figures. In these figures, the radio access scheduling sequencer 214 (labeled as ras-seq) (as part of the AON domain 210) is responsible for power sequencing the transmission sequencer 221 (labeled as trns-seq) and the PHY. In these figures, the host agent 212 (labeled as hst-proxy) (as part of the AON domain 210) is responsible for exchanging data messages with the upper layer (host). Again, the curly brackets indicate the steady state operating mode, that is, a periodic execution sequence that is repeated indefinitely while the device remains in steady state operation. In Figure 3-3 In the example, the label cntx_id is used to refer to the connection identifier (conn-#) of the corresponding connection context (234-#).

[0063] exist Figure 3-2 A and Figure 3-3In A, the arrow from the "Configuration Unload" process actually configures the connection context 234-# (a process that should occur once before entering the stable state). The transfer sequencer 221 is not configured when powered off. In other words, the transfer sequencer 221 does not need to be initialized for its context (state, configuration, and microcontroller) when powered up, because the context will be stored elsewhere in persistent storage.

[0064] Figure 4 A schematic diagram of an example implementation of Bluetooth Low Energy (BLE) of the MO-MACLL architecture 200 in a multiprocessor system 400 according to aspects of the present disclosure is shown. Note that the host CPU that processes the upper layers of the protocol stack and / or applications is assumed to exist in another hierarchy of the system but is not depicted in this figure.

[0065] The multiprocessor system 400 includes an interconnect structure 410, a core system 420 (package-specific CPU), a MO-MACLL master device 430 (corresponding to the host agent 212), a MO-MACLL slave device 440, a PHY layer 450, and other peripheral devices 460. The MO-MACLL slave device 440 includes a radio access scheduling sequencer 442 (corresponding to 214) (labeled as RAS-SEQ), a transmission sequencer 444 (corresponding to 221) (labeled as TRNS-SEQ), an optional address analyzer 445 (corresponding to 240) (labeled as ADDR-ANLZR), a context 446 (corresponding to 234-#), and a queue 448 (corresponding to 230-# and 232-#).

[0066] Complete Figure 4 It can represent a chip integrated into a complete platform, or a subsystem of a system on chip (SoC). In both cases, the host CPU communicates with the MO-MACLL through the MO-MACLL master 430. There is a dedicated CPU 420 (e.g., a small GPP or MCU) for MAC / LL for management tasks (non-steady state operation), and during steady state operation, when the dedicated CPU 420 is asleep, the MO-MACLL 200 (including the MO-MACLL master 430 and the MO-MACLL slave 440) handles MAC / LL functions and host PDU exchange.

[0067] Figure 5 A schematic diagram is shown of an example implementation of Bluetooth Low Energy (BLE) of the MO-MACLL architecture 200 in a single processor system on chip (SoC) 500 in accordance with aspects of the present disclosure.

[0068] The single processor SoC 500 includes an interconnect structure 510, a core system 520 (packaged CPU), a MO-MACLL 540, a PHY layer 550, and other peripherals 560. The MO-MACLL 540 includes a radio access scheduling sequencer 542 (corresponding to 214) (labeled as RAS-SEQ), a transmit sequencer 544 (corresponding to 221) (labeled as TRNS-SEQ), an optional address analyzer 545 (corresponding to 240) (labeled as ADDR-ANLZR), a context 546 (corresponding to 234-#), and a queue 548 (corresponding to 230-# and 232-#).

[0069] Figure 5 520 for host applications as well as MAC / LL functions. In this case, because the HCI is implemented in a software application programming interface (API), the host agent 212 (within the AON domain 210) does not need to be offloaded. However, when in steady state operation, the MO-MACLL 540 handles the MAC / LL functions and the CPU is offloaded and can sleep when the application does not need CPU cycles.

[0070] While it is known that hardware offload mechanisms can be used to reduce power consumption during the idle state of the MAC / LL protocol, the MO-MACLL architecture 200 implements CPU offload not only during the idle state of the protocol, but also during the active state of the protocol. Therefore, during the full steady state operation of the device, maximum CPU offload time (i.e., minimum CPU wake-up time) is possible, thereby minimizing dynamic power consumption and leakage power consumption (due to memory occupancy reduction and CPU power off).

[0071] Meanwhile, the MO-MACLL architecture 200 is based on microcontrollable hardware offloads to achieve reconfiguration capabilities for different MAC / LL protocols, different versions of protocols, or just for quality of service (QoS) adjustments in a single protocol.

[0072] II. Example implementation of the proposed BLE link layer architecture

[0073] The following subsections illustrate the above concepts in the setting of a BLE Link Layer (BLE-LL) architecture. In the following description, BLE is used as an example, but the present disclosure is not limited in this regard.

[0074] The BLE-LL mechanisms can be roughly divided into two groups: (1) upper-layer BLE-LL mechanisms, which handle the PDU-level control process, LL state machine state transitions, and baseband access scheduling for all logical transports served by the device; and (2) lower-layer BLE-LL mechanisms, which handle all real-time issues in the air interface protocol, i.e., radio channel access sequencing, PDU depacketization / packetization, and bit stream transmission into / out of the BLE PHY layer.

[0075] As described above, the MO-MACLL architecture 200 can completely offload CPU intervention in the underlying BLE-LL execution and handle the corresponding power sequencing of the BLE device, which helps to achieve longer continuous (uninterrupted) CPU sleep time during the steady state. In the following, the term "LE event" refers to any of the following air interface protocol definitions: connection event, notification event, or scan window.

[0076] Figure 6 A schematic diagram showing an overview of a Maximum Offload BLE Controller (MO-BLE Controller) 600 (corresponding to the MO-MACLL architecture 200 ) according to aspects of the present disclosure is shown.

[0077] The MO-BLE controller 600 includes a CPU 610 (which implements device management, link management, and baseband resource manager (BB-RM) in software), a BLE lower link layer (BLE-LLL) hardware offload 620, an HCI handler hardware offload 630, a queuing system 640, a link controller context memory 650, a device address data structure 660, a scheduling data structure 670, and a BLE physical layer 680. In the MO-BLE controller 600, the upper layer BLE-LL functions are covered by the CPU 610 and the HCI handler hardware offload 630. The BLE-LLL 620 includes a link controller (LC) hardware offload 622, a link event sequencing (LES) hardware offload 624 (which implements the BB-RM real-time mechanism), and a device address analyzer (DAA) hardware offload 626. The queuing system 640 includes an event queue, a receive control PDU queue, a set of send control PDU queues (one for each logical transport being serviced), a receive data PDU queue, and a set of send data PDU queues (one for each logical transport being serviced).

[0078] The MO-BLE controller 600 provides multiple advantages. In general, when all connections are in a stable state, the MO-BLE controller is able to eliminate all CPU 610 interventions until an exception (unstable state) occurs, so the CPU 610 can be powered off indefinitely in a stable state. In addition, the MO-BLE controller 600 also provides a decoupled execution of software in the CPU 610 and the BLE-LLL hardware offload 620; when the BLE-LLL drives the air interface protocol for different links, the software can process the control PDU previously received for one link. Because the control plane operation of the BLE-LLL 620 is driven by a persistent scheduling data structure 670, this decoupling is achieved, and the data plane of the BLE-LLL 620 is decoupled through a queuing system 640. In addition, the MO-BLE-controller 600 implements simplified software / firmware complexity for the CPU 610 because real-time constraints have been offloaded to the BLE-LLL 620. Ultimately, these simplifications produce less software / firmware occupancy and less CPU dynamic power through maximum uninterrupted CPU power saving time periods.

[0079] The following subsections describe individual components of the MO-BLE controller 600 and illustrate the mapping relationship between the individual components and corresponding components of the MO-MACLL architecture 200 .

[0080] A. Link Event Sequencing Hardware Offload

[0081] According to the core system architecture in the specification of the Bluetooth low energy system, the entity responsible for authorizing air interface access for different served logical transports is the Baseband Resource Manager (BB-RM). The different logical transports that can be served are LE Asynchronous Connection Transport (LE-ACL) for each connection state (there is one connection state for each served connection), or LE Advertising Broadcast (ADVB) transport for the advertising, scanning, or initialization states.

[0082] In the MO-BLE-controller 600, the BB-RM is split between the CPU 610 and the Link Event Sequencing (LES) hardware offload 624. The CPU 610 (software) performs the advance scheduling of LE events, while the LES hardware offload 624 performs the immediate sequencing of the software-defined scheduling of LE events. This split allows flexibility in scheduling strategies implemented in software, while the LES hardware circuit 624 offloads the BB-RM's immediate mechanism for sequencing LE event dispatches from the CPU 610. Therefore, the LES hardware circuit 624 decouples the CPU 610 from the real-time requirements of LE event dispatches.

[0083] The main interface between the CPU 610 (performing advance scheduling of BB-RM) and the LES hardware offload 624 (performing just-in-time sequencing of software-defined schedules) is a persistent schedule data structure (SDS) 670. The SDS 670 includes one or more schedules, each of which is an ordered list of LE event descriptors (also known as LE-Event_Actions). Each LE event descriptor in the SDS 670 includes all necessary information for restoring the context of the BLE-LLL 620 to resume the execution of the logical transfer corresponding to the LE event described by the descriptor, and all necessary information for dispatching the execution of the LE event at the appropriate time to comply with the air interface timing requirements. The SDS 670 decouples the execution of the CPU 610 from the execution of the BLE-LLL 620, allowing either of them to enter a power saving mode independently while persistently maintaining the determined schedule in the SDS. The CPU 610 generates the schedule data structure 670, and the LES hardware offload 624 consumes the schedule data structure 670 for its sequencing. In some cases, LES hardware offload 624 may update scheduling data structure 670 .

[0084] LES hardware offload 624 corresponds to the above Figure 2 The radio access scheduling sequencer 214 and the PDU queue and context selector (multiplexer) 216 described above, and the scheduling data structure (SDS) 670 corresponds to the above for Figure 2 Described radio access scheduling 236. Hereinafter, LES hardware offload 624 will be referred to as LES 624.

[0085] While sequencing the software defined schedule of the SDS 670, the LES 624 is responsible for driving the power sequencing (power gating, clock gating, setup sequencing, etc.) for the rest of the BLE controller hardware (BLE-LLL 620 and BLE-PHY 680). The LES operation is based on a dual clock scheme, using the always-on low power sleep clock as the absolute timing reference, and the active clock to drive execution within LE events. By defining the LE event timing relative to the absolute reference (the sleep clock), the LES avoids cumulative errors.

[0086] Next, a description will be given of the timing concepts of the baseband resource manager implemented in the MO-BLE controller 600. The timing concepts presented are used by the CPU 610 when performing advance creation of schedules and by the LES 624 when performing just-in-time sequencing of schedules.

[0087] Figure 7Shown is a timeline of a BB-RM timing scheme 700. The scheme is based on two clocks: a sleep clock (labeled sclk) and an active clock (labeled aclk).

[0088] The sleep clock (sclk) is a low-power, low-frequency (while meeting the sleep clock accuracy required by the Bluetooth system specification), always-on clock that is used to drive the absolute timing reference (abs_time).

[0089] The active clock (aclk) is a high frequency clock used only during BLE-LLL 620 activity (as required by internal circuitry and in accordance with the active clock accuracy required by the Bluetooth system specification) to drive the relative (within LE event) timing reference (actv_time). actv_time is generated in LES 624 and forwarded to LC 622 and DAA 626 for LE event operations.

[0090] The BB-RM in the MO-BLE controller 600 uses the concept of time slots as the minimum time allocation unit for scheduling purposes. A time slot is defined as an integer number of sclk ticks, so the BB-RM scheduling is synchronized with the sleep clock. The BB-RM scheduling process includes allocating an integer number of consecutive time slots to different LE events corresponding to different logical transports in a manner that optimizes the quality of service (QoS) of each logical transport as needed.

[0091] Each scheduled LE event is represented by an LE event_action (also called an LE event descriptor) within the SDS 670. An LE event_action is granted a consecutive number of time slots, called an event_grant_duration, starting from a specific time slot ( Figure 7 ) and ends after the event_authorization_duration slot ( Figure 7 The event_grant_duration assigned to an LE event_action represents the maximum amount of time that an LE event can elapse, but an LE event may not use the full grant and terminate early for a number of reasons, such as lack of user traffic to transmit, explicit termination by a peer device, or for some abnormal reason (e.g., multiple CRC errors). Figure 7 Two consecutive LE event_actions are shown, labeled EA[n] and EA[n+1] respectively.

[0092] Each LE event_action specifies an over-the-air (OTA) start time (in Figure 7aclk). The LE event_action OTA start time may be different from the event authorization start time because the authorization is synchronized with sclk and the sclk resolution may not be sufficient to capture the anchor point of a LE event when the device is used as a peripheral for multiple different central devices. For this reason, the LE event_action OTA start time is specified using a dual clock schedule (i.e., sclk and aclk). At each LE event authorization start time, the actv_time relative timing reference may be synchronized to sclk (preset to a predetermined value, e.g., zero). There are two different timing modes for the LE event_action OTA start time: absolute timing and relative timing.

[0093] Absolute timing is a mode used to specify non-recurring LE events. The LE event OTA start time is specified by the absolute value of abs_time plus the increment of aclk ticks: abs_time(EA[n])+Δaclk.

[0094] Relative timing is a mode used to specify periodically recurring LE events. The LE event OTA start time is specified with an increment of sclk ticks and another increment of aclk ticks: Δsclk + Δaclk. Note that an announcement event can be represented as a periodically recurring LE event by setting the periodically recurring OTA start time equal to advInterval and including the maximum advDelay as part of the event_grant_duration.

[0095] From a synchronization perspective, the dual-clock scheduling scheme guarantees that synchronization errors (between sclk and aclk) are not carried forward or accumulated. Because sclk is used as an absolute reference, scheduling is done based on sclk (using only the fractional correction factor specified based on aclk), and aclk is resynchronized to sclk at each grant start time, then any synchronization error during LE event n (EA[n]) will not affect the synchronization of LE event n+1 (EA[n+1]). Other schemes that base all scheduling on the active clock (which is usually turned off during power saving mode) will suffer from accumulated errors because they switch from the active clock to the sleep clock before entering power saving mode, and from the sleep clock back to the active clock after waking up.

[0096] LES circuit 624 is hardware unloading, and it enables CPU 610 to decouple with instant BB-RM operation when equipment is in stable state.LES circuit 624 can support different BB-RM operating modes (to cover different use scenarios), and each operation imposes different requirements on the advance scheduling operation of CPU 610BB-RM.LES 624 can support these modes (for multi-role devices, for example, the equipment of peripheral device, observer, broadcaster and central device simultaneously) in a configurable mode when running, or LES 624 can only support a kind of operating mode (for single-role devices, for example, only observer or only broadcaster equipment).Four different operating modes supported by LES circuit 624 are: single static cycle scheduling sorting mode, multiple static single event scheduling arbitration sorting modes, single dynamic non-periodic scheduling sorting mode and mixed scheduling arbitration sorting mode.Each operating mode will be described below.

[0097] Single static periodic scheduling ordering mode: This operating mode can be used to service multiple central device role (master device) connections without restriction (i.e., no other roles are being served simultaneously). Alternatively, this operating mode can also be used when serving a single peripheral device role (slave device) connection, a single broadcaster role logical transfer, or a single observer role logical transfer. In this operating mode, the CPU 610 performs an advance schedule of the BB-RM once for all logical transfers being served simultaneously before entering the stable state (and the schedule must be repeated each time the device leaves and re-enters the stable state). Each time the CPU 610 performs an advance schedule of the BB-RM, the CPU 610 creates a single static periodic schedule for all logical transfers being served simultaneously (including multiple LE events_actions); the schedule is considered static because it does not change until the stable state is disrupted. In this operating mode, the SDS 670 includes a single schedule for all logical transfers being served simultaneously. In this mode of operation, the LES circuit 624 continuously performs the immediate execution of the BB-RM of the SDS 670 by cyclically and infinitely iterating the LE Event_Action of the SDS 670 without removing any items from the SDS 670. Because all serviced logical transports are scheduled by the CPU 610 in the same schedule, any software-defined scheduling policy can be used to optimize QoS as needed (all conflicts are resolved in advance). Therefore, this mode of operation is the most power efficient for long-term steady state scenarios and achieves the most efficient scheduling because it allows the CPU 610 to perform a schedule once and transition to a low power mode indefinitely (until the steady state is violated) while the LES 624 dispatches LE events for all simultaneously serviced logical transports in real time. Fig. 10B (multiple central device role connections in a single schedule) or Fig. 10CThe use of SDS 670 in this mode of operation is shown in (single central role connection in scheduling, single peripheral role connection in scheduling, single broadcaster role logical transfer in scheduling, or single observer role logical transfer in scheduling).

[0098] Multiple Static Single Event Schedule Arbitration Ordering Mode: This mode of operation can be used to serve any combination of roles (Observer, Broadcaster, Peripheral, and Central), but may not be as scalable as other modes, i.e., this mode of operation may have capacity limitations on the number of logical transports served simultaneously. In this mode of operation, whenever a logical transport needs to be created or updated, the CPU 610 performs advance scheduling of the BB-RM for each logical transport served separately. Whenever the CPU 610 performs advance scheduling of the BB-RM, the CPU 610 creates or updates a schedule that includes a single static periodic LE event_action corresponding to the logical transport of the particular service; this schedule is considered static because it does not change until the stable state is broken (i.e., the logical transport configuration is updated). In this mode of operation, the SDS 670 includes multiple schedules for simultaneous services, each schedule including a single LE event_action. In this mode of operation, the LES circuit 624 continues to perform just-in-time execution of the BB-RM of the SDS 670 by arbitrating at runtime a single cycle LE event_action for each concurrently serviced schedule without removing any items from the SDS 670. For this mode of operation, the LES circuit 624 needs to support at least one arbitration strategy (and may support multiple different strategies) to arbitrate between all concurrently serviced schedules, and the LES circuit may have a configuration to allow the arbitration strategy to be adjusted as needed by the BB-RM (and to select the arbitration strategy if multiple arbitrations are supported). The CPU 610 can set the LES circuit 624 configuration at any given time when the CPU is active (which often occurs before entering a steady state). This mode of operation is efficient for scenarios requiring multiple simultaneous peripheral device role connections because the CPU 610 is not required to modify the entire SDS 670 each time a new peripheral device role connection is created, and instead will only need to create or update a single schedule. Therefore, for long-term steady state scenarios servicing multiple concurrent logical transfers (at least one of which is a peripheral device role), this operating mode is power efficient because once a steady state is reached, the CPU 610 is allowed to transition to a low power mode indefinitely (until the steady state is violated). The use of the SDS 670 in this operating mode includes multiple independent static single event schedules (such as Fig. 10C As shown), each schedule corresponds to a different served logical transport.

[0099] Single dynamic non-periodic scheduling ordering mode: This is the most common operation mode because it can be used for any role without restrictions on the count of logical transfers served simultaneously. In this operation mode, using a single dynamic schedule, the CPU 610 cyclically performs the advance scheduling of BB-RMs, each time adding more LE events_actions to the single dynamic schedule being used, and the LES circuit 624 continuously performs the immediate execution of the scheduled BB-RMs, removing those LE events_actions that have been executed from the schedule. In this operation mode, the single schedule is dynamically changed (elements are added and elements are deleted therefrom). In this operation mode, the SDS 670 includes a single dynamic schedule. Therefore, this operation mode is the least power efficient because it requires periodic intervention of the CPU 610, and therefore does not allow the CPU to enter a low power mode for a long time. This operation mode can be very useful for transient logical transfers (with a short limited lifespan) (i.e., when announcing for the purpose of quickly creating a connection with a peripheral device role, or when scanning / initializing for the purpose of quickly creating a connection with a central device role). Fig. 10A Use of the SDS 670 in this mode of operation is shown.

[0100] Hybrid Schedule Arbitration Ordering Mode: A combination of the three previous operating modes, where the SDS 670 includes multiple schedules, and each schedule can be of any allowed type: static periodic (covering multiple logical transfers), static single event (covering a single logical transfer), or dynamic aperiodic (covering one or more transient logical transfers). This mode is an extension of the Multiple Static Single Event Schedule Arbitration Ordering mode, as this mode requires the ability to track multiple schedules and arbitrate between them. The use of the SDS 670 in this operating mode includes multiple independent schedules (such as Fig. 10A , Fig. 10B and Fig. 10C Any type of schedule shown).

[0101] LES circuit 624 includes two features for achieving full CPU 610 offloading in either single static cycle scheduling ordering mode or in multiple static single event scheduling arbitration ordering modes: automatic window widening, and automatic notification delay randomization. These two features are described below.

[0102] The automatic window widening feature allows the logical transfer for the connection with the peripheral role to enter a continuous stable state. In other words, the LES circuit 624 handles the timing adjustment during the life of the connection without intervention by the CPU 610. This feature requires the LES circuit 624 to calculate the window widening algorithm to obtain a correction factor for the OTA start time and update the LE event_action within the SDS 670 corresponding to the connection with the peripheral role currently being served.

[0103] The automatic advertisement delay randomization feature allows randomization of the advDelay parameter to be performed for logical transfers of a link in the advertising state during the lifetime of the advertising state without intervention by the CPU 610. In other words, after extracting the OTA start time for the LE event_action descriptor, the LES circuit 624 handles the timing adjustment by calculating a random delay and adding the delay to the OTA start time according to the specification of the Bluetooth system.

[0104] The SDS 670 may store multiple schedules. Each schedule is an ordered list of LE Event_Action Descriptors (EADs). Each EAD specifies at least the following information: an identifier of the link context being served, an absolute or relative timing mode, an OTA start time specification (according to the format of the timing mode), the total authorization time for LE events (in time slots), and the number of connection intervals lost since the most recently scheduled authorization for that context identifier (central or peripheral role only). The EAD may indicate whether automatic window widening can be implemented (peripheral role only), or whether automatic randomization of notification delays can be implemented (notification events only).

[0105] Fig. 10A Dynamic aperiodic scheduling is shown. The CPU 610 dynamically schedules different logical transfers by continuously adding new EADs to the tail of the queue, while the LES continuously reads and removes EADs from the head of the queue. EADs can use any timing mode. This scheduling mode can be effectively implemented in shared memory.

[0106] Fig. 10B Static periodic scheduling is shown. The CPU 610 statically schedules the logical transfers of all services in a periodic scheduling that is implemented as a circular list of EADs (all EADs have a relative timing pattern), while the LES (without removing these EADs) continuously reads these EADs in a circular manner. This is most effective for multiple link contexts (all link contexts have a central device role, when all link contexts reach a stable state) because the same schedule can remain unchanged for a long time. This scheme can also be used for peripheral device roles, at the cost of granting each LE event a longer time than is actually needed, thereby achieving automatic window widening. This scheduling mode can be effectively implemented in a shared memory.

[0107] Fig. 10CStatic single event scheduling is shown. CPU 610 schedules a single EAD (with a relative timing pattern) for a single logical transfer, which loops to itself. The LES continuously executes the single EAD. This scheme is useful for a single logical transfer of any role (broadcaster, scanner, peripheral or central device). This scheduling pattern can be effectively implemented in shared memory, or a small number of persistent registers.

[0108] Figure 8 is a schematic diagram of a general LES circuit 800 that interacts with the CPU 610 (BB-RM ahead scheduling), the SDS 670, and the LC 622. The LES circuit 800 corresponds to the LES hardware offload 624.

[0109] The LES circuit 800 includes one or more LES engines 810 (when there are multiple, they are labeled from 810-0 to 810-N), a baseband access arbiter (BBAA) 820, a LES AON control 830, an active clock timer 840, and a multiplexer 850. The LES AON control 830 includes a sleep clock timer 832, and a power / clock control unit (PCU) 834.

[0110] Fig. 9 yes Figure 8 Schematic diagram of the LES engine 810. The LES engine 810 / 900 includes a sequential scheduling arbitrator 930, a LE event execution sequence controller 910, and a scheduling accessor 920.

[0111] The LES circuit 800 may generate a plurality of different specializations. Any LES specialization may include one or more LES engines 810-# (where # represents a LES engine identifier, i.e., 810-0 to 810-N). Any LES specialization may assign a separate set of one or more schedules within the SDS 670 to each LES engine 810-#.

[0112] In the LES circuit 800 specialization, when there are multiple LES engines 810-#, the BBAA 820 is included to arbitrate between all LES engines 810-# in parallel. The BBAA 820 can be configured by the CPU 610 to select the desired arbitration strategy and adjust the strategy to the current QoS requirements.

[0113] In the LES circuit 800 specialization, when a single LES engine 810 / 900 is coupled to more than one schedule within the SDS 670, a sequential schedule arbitrator 930 is included within the LES engine to arbitrate between all coupled schedules in a sequential manner, i.e., the sequential schedule arbitrator 930 will sequentially access the current EAD on each schedule before arbitrating (in the event of a conflict) and deciding which schedule to service next. The sequential schedule arbitrator 930 can be configured by the CPU 610 to select a desired arbitration strategy and adjust the strategy to the current QoS requirements.

[0114] Fig.11 A flow chart 1100 shows a control sequence of the link event execution sequence controller 910 .

[0115] Fig.12 A timing diagram 1200 of LES engine power saving and wakeup is shown.

[0116] The LES engine 810 / 900 is the core component of the LES 624 that interprets the SDS 670 schedules and executes them accordingly while performing power sequencing of devices to ensure maximum power savings during wireless idle periods. Arbitration between multiple SDS 670 schedules within the LES engine 810 / 900 is handled by the sequence schedule arbitrator 930. The main control machine in the LES engine 810 / 900 is the link event execution sequence controller 910.

[0117] After being triggered for execution, if the LES engine 810 / 900 is required to perform automatic window widening or automatic announcement delay randomization, the LES engine 810 / 900 reads the current EAD from the SDS 670 (the current EAD after arbitration in the case where multiple schedules are assigned to the same LES engine), parses the current EAD, and updates the LE event start time (if necessary). With the updated LE event OTA start time, the LES engine 810 / 900 requests baseband access BBAA 820, and if not granted, the LES engine 810 / 900 updates an internal counter (event_miss_count) (which keeps track of the number of consecutive baseband access denials), discards the current EAD, and advances the SDS 670 to obtain the next EAD. If baseband access is granted, then based on the amount of time remaining until the start time of the current LE event, the LES engine 810 determines whether there is enough time to enter a power saving mode (and which mode), calculates the wake-up time, and requests a power mode transition and wake-up service from the PCU 834 without updating the state of the SDS 670, such as Fig.12As shown. When the LES engine 810 / 900 is awakened, the LES engine 810 / 900 obtains the same EAD and continues the execution of the same EAD by preparing an EA command for LC 622 and dispatching the command to LC 622. The LE engine 810 / 900 waits until LC 610 completes the EA execution. After LC 610 is completed, the LE engine 810 / 900 parses the LE event completion status according to the LE event type (if necessary) to update the internal counter, and advances the SDS 670 to obtain the next EAD, and starts the above process again.

[0118] The LES engine 810 / 900 accesses the SDS 670 schedule through the get_sched interface, which provides the following services: 1) curr_EAD←peek(), which returns the EAD at the currently pointed-to position in the list; 2) advance(), which advances the pointed-to position in the list to the next position without removing the currently pointed-to position from the list; 3) count←remove(), which advances the pointed-to position in the list and removes the currently pointed-to position from the list, while also updating and returning the valid EAD count in the schedule; and 4) schd_sel(), which selects which schedule is being addressed within the SDS 670 and returns the valid EAD count for that schedule.

[0119] When the SDS 670 schedule is in dynamic non-periodic mode, each time the LES engine 810 / 900 executes an EAD, the LES engine 810 / 900 must remove the EAD from the schedule, thus using the remove() service. In contrast, when the SDS 670 schedule is in cyclic mode, the LES engine 810 / 900 will not remove elements from the SDS 670 schedule to continuously read each element in a loop, thus using the advance() service. In order to abstract the link event execution sequence controller 910 from the SDS 670 mechanism, the schedule accessor 920 in the LES engine 810 / 900 encapsulates all mechanisms for accessing the SDS in all possible modes, and the schedule accessor 920 must be configured by the CPU 610 to operate in the correct mode.

[0120] The LES engine 810 / 900 requests baseband access through the bb_access interface, which provides a single service: success←req(cntxt_id,t_start,t_end,event_miss_count), which requests baseband access for a logical transport with context cntxt_id, starting at time slot t_start, ending at time slot t_end, and provides an event_miss_count value for the arbitrator. The return value success indicates whether the baseband access is granted.

[0121] The BBAA 820 is only needed when more than one LES engine 810 / 900 is used inside the LES 624. The purpose of this arbitrator is to arbitrate between competing LES engines that simultaneously request BB access. The LES engines 810 / 900 request BB 610 access to the BBAA 820 through their corresponding bb_access interfaces. Each LES engine 810 / 900 (when not in power saving mode) should request 610BB access for the next upcoming LE event at any time. The BBAA 820 can provide several different arbitration strategies, and one arbitration strategy is selected based on the configuration. Some example strategies are: priority / weight based service, closest timeout based service, and highest event_miss_count priority based service.

[0122] The BBAA 820 also knows the connSlaveLatency of each LES engine 810 / 900 serving the peripheral role logical transfer. This information can be considered during arbitration.

[0123] BBAA 820 multiplexes the interface to LC 622 between all LES engines 810 / 900, allowing only authorized LES engines 810 / 900 to use LC 622. In addition, BBAA 820 receives all power requests from all LES engines 810 / 900 and decides which final power request to forward to PCU 834 based on the arbitration result.

[0124] The PCU 834 acts as a slave device to the baseband access arbiter (BBAA) 820 by handling the power state control sequence for the BLE controller 600 hardware (LL hardware offload and BLE-PHY 680), the generation of the active clock (aclk), and the distribution of the sleep clock (sclk). The PCU operates on sclk when the system is in power save mode, and on aclk when the system is in active state. In addition, this module provides wake-up services for the rest of the LES 624. The BBAA 820 requests services from the PCU 834 through the power_req interface, which provides two services described below: wake-up and set power state.

[0125] Wakeup service: wakeup(down_time, trgt_pwrst, rtrn_pwrst). This service puts the system into a power saving state "trgt_pwrst", turns off aclk generation, waits a specified period of time "down_time", brings the system to a specified active power state "rtrn_pwrst", turns on aclk generation, sets up the system (this may include a reset), and signals wakeup_trigger to trigger execution resumption for the LES.

[0126] Set Power State Service: set_pwrst(trgt_pwrst). This service forces the system to transition to the requested power state "trgt_pwrst".

[0127] The sleep clock timer 832 and the active clock timer 840 are simple counters that provide a time reference abs_time / actv_time with sclk / aclk resolution, respectively. The sleep clock timer 832 never stops counting, while the active clock timer is turned off during power saving mode and can be reset by the BBAA 820.

[0128] B. HCI Data Flow Control Hardware Offload

[0129] Fig.13 A schematic diagram 1300 of the HCI handler hardware offload 630 is shown in FIG. It is assumed that only a small low-power CPU 610 is used for the BLE controller firmware. Therefore, the BLE host firmware is processed elsewhere, ideally in the same processor core that processes the device application because their execution time is coupled to each other. The HCI handler hardware offload 630 belongs to the upper layer BLE-LL (side by side with the CPU 610).

[0130] HCI handler 624 corresponds to Figure 2. Hereinafter, for the sake of brevity, the HCI handler hardware offload 630 will be referred to as the HCI handler 630.

[0131] HCI handler 630 provides three levels of offloading of HCI programs from CPU 610: (1) physical input / output (I / O) protocol data unit level; (2) HCI transport level; and (3) HCI full data flow control level. Different implementations of HCI handler 630 may include offloading only level (1), offloading levels (1) and (2) of all three offloading levels.

[0132] The MO-BLE controller 600 employs two types of persistent data structures to decouple it from the CPU 610 and the BLE-LLL 620. From a control plane perspective, there is an HCI packet buffer 631 in which HCI packets to be generated / consumed by the CPU 610 are stored. From a data plane perspective, there is a transmit / receive data PDU queuing system 640 via which incoming / outgoing BLE data PDUs from / to the BLE-LLL 620 are exchanged.

[0133] The control plane HCI packet buffer 631 is used to decouple the CPU 610 from the HCI handler 630 and can store any type of HCI packet (command, event or data). The state of the HCI packet buffer is maintained by the BLE controller CPU 610.

[0134] The data plane PDU queuing system 640 is located between the BLE-LLL 620 and the HCI handler 630 and allows PDU exchange that is decoupled from the air interface protocol timing. In addition, the PDU queuing system 640 has separate queues for control PDUs (generated or consumed by the BLE controller CPU 610) and data PDUs (received from the BLE host by the HCI handler 630, or relayed to the BLE host), which decouples the protocol control flow from the data flow. For efficiency and consistency, the PDU queues can be implemented as multiple queues dynamically allocated in shared memory.

[0135] In the transmit direction, multiple queues (for both control PDUs or data PDUs) are needed to separate traffic for different peer logical transports (i.e., different connections) and avoid head-of-the-line blocking issues. In the receive direction, only a single data PDU queue and a single control PDU queue are needed because both the BLE controller CPU 610 and the BLE host (through the HCI handler 630) are able to process packets in the order of arrival. The state of the PDU queuing system 640 is maintained by hardware offloads inside the queuing system to decouple the execution time of the lower BLE-LL side from the upper BLE-LL side.

[0136] In the MO-BLE controller 600, the HCI handler 630 is responsible for pushing the transmit PDUs (received from the BLE host) to the corresponding TX data PDU queues 640 (one queue for each LE-ACL logical transport served), popping the received PDUs from the RX data PDU queues 640 (and relaying them to the BLE host), and storing / retrieving HCI command / event packets to / from the HCI packet buffer (for relaying them to the CPU 610 / BLE host), all without the need for CPU 610 intervention.

[0137] When the HCI handler 630 implements all three offload levels, these can be implemented in a runtime configurable manner to accommodate different system requirements at runtime. In this runtime configurable case, the HCI handler 630 operating mode (offload level) is selected at runtime through register configuration. In all operating modes (such as Fig.13 The "HCI Handler CSR and Control Logic" (shown in FIG. 1 ) is responsible for sequencing the operations, as described below. In all modes of operation, all configurable aspects of the HCI handler 630 are encapsulated in (as shown in FIG. Fig.13 The HCI Handler CSR and Control Logic block is shown in the Control and Status Register (CSR).

[0138] The first offload level of the HCI handler 630 is responsible for the physical data unit transmission (e.g., byte or word) of the raw data between the BLE host and the BLE controller 600, which follows a specific flow control protocol for each data unit. The offload is implemented through one or more physical I / O interfaces (e.g., SPI, UART, AHB, etc.) to the BLE host, because to meet the flexibility requirements, each physical I / O interface requires its own hardware interface to follow a specific I / O protocol. Depending on the requirements of the system design (e.g., UART, 3-wire UART, SDIO, AHB, asynchronous parallel port, custom I / O protocol, etc.), the physical I / O interface can be synchronous / asynchronous, serial / parallel, and master-slave / full-duplex. Some physical I / O interfaces may require dedicated lines, while other physical I / O interfaces do not, that is, the master-slave interface requires a BLE host CPU interrupt line.

[0139] The first offload level of the HCI handler 630 decouples the CPU 610 operation from the data unit transfer through the I / O protocol. When operating at this offload level, each correctly sent / received physical data unit will cause the BLE controller CPU to interrupt, and the CPU 610 will be responsible for transferring the data unit between the shared memory and the HCI handler 630. This offload is handled by the physical I / O interface hardware block ( Fig.13 The first line in the box) is processed.

[0140] The second offload level of the HCI handler 630 is responsible for packet level transport flow / error control through the physical I / O interface. The complete transmission of packets (PDU groups) may require additional flow control and error detection (retransmission handling, synchronization loss detection, etc.) through the physical I / O interface. This functionality requires an additional level of packet framing when transmitting packets to the BLE host (because some physical data units carry transmission information (e.g., HCI packet size, i.e., not HCI payload)), as well as corresponding parsing when receiving packets from the BLE host.

[0141] The second unloading level is based on Fig.13The hardware blocks "Physical I / O Flow and Error Control", "Slave Device Status / Command Registers", "HCI Transport Layer Packetizer / Depacketizer and Parser / Filter" and "HCI Packet Buffer Handler" are responsible for: (1) handling the flow and error control of data unit transmission through physical I / O; (2) framing HCI data units into / deframing HCI data units from HCI transport packets when sending to / receiving from the BLE host; (3) packetizing HCI payloads (data, commands, events) into / depacketizing HCI payloads (data, commands, events) from HCI transport packets when sending to / receiving from the BLE host; (4) loading outgoing / incoming HCI payloads from / storing outgoing / incoming HCI payloads to the general HCI packet buffer in the shared memory; (5) signaling events to the BLE controller CPU 610 when the HCI packet send / receive operation is completed.

[0142] This second level of offload can be responsible for the physical I / O interface by including a so-called "physical I / O flow and error control" (see Fig.13 ) to take care of packet level transfer flow / error control in full duplex physical I / O interfaces, e.g. for packets in a 3-wire UART transfer. This level of offloading can be accomplished by including a so-called "slave status / command register" (see Fig.13 ) to implement packet level flow control on the master and slave physical I / O interfaces, which maintains the packet flow control state for the master and slave physical I / O interfaces (mapped to the I / O interface address space on registers, or mapped to GPIO accessible to the BLE host), which allows the BLE host master device to query the status and perform reads / writes as needed, for example, for SPI transfers.

[0143] When operating at the second offload level, the BLE controller CPU 610 must configure an HCI packet buffer slot for each HCI transport packet to be sent / received. Afterwards, each correctly sent / received HCI transport packet (from / to the common HCI packet buffer) will cause the BLE controller CPU to be interrupted, and the CPU 610 will be responsible for providing another HC packet to be sent, or analyzing the received HCI packet and performing operations on the HCI packet as needed (i.e., forwarding a data PDU to a PDU queuing system, or consuming a command packet).

[0144] The third offload level of the HCI handler 630 is responsible for HCI packet parsing and filtering and automatic HCI data flow control. The complete data flow control of the HCI data packets is built on the previous offload level by distinguishing between incoming (from the BLE host) and outgoing (to the BLE host) HCI transmission packets generated / consumed by the BLE controller CPU 610 or BLE-LLL 620. The HCI packets consumed / generated by the CPU 610 are stored / loaded to / from the general HCI packet buffer, while the HCI packets consumed / generated by the BLE-LLL packets are stored / loaded to / from the PDU queuing system 640.

[0145] This offload level requires an extension to the "HCI Transport Layer Packetizer / Depacketizer and Parser / Filter" hardware block to further parse the HCI packets and extract the packet type, packet length, etc. The HCI Event and Command packets are generated / consumed by the CPU 610, while the HCI RX / TX data packets are generated / consumed by the BLE-LLL 620. Another addition to this offload level is the hardware block "HCI Data Flow Control Handler" (see Fig.13 ), which together with the BLE host handles the data flow entering / leaving the PDU queuing system and credit-based flow control (automatic HCI event packet generation for data flow control).

[0146] For this offload level, a dedicated sideband signal can be added that carries the status (full / empty / credits) of the PDU queuing system 640 to avoid polling the queuing system through the interconnect structure. Fig.13 It is shown as "PDU Queuing System Status".

[0147] When operating at this offload level, the control plane and data plane operate in a decoupled manner as described below.

[0148] From the control plane perspective, CPU 610 must configure HCI packet buffer slots for HCI event packets to be sent (except data flow control credit events) and HCI command packets to be received. After each correctly sent / received HCI event / command packet (from / to the general HCI packet buffer), HCI handler 630 will generate an interrupt to CPU 610, and CPU 610 will be responsible for providing another HCI event packet to be sent, or analyzing the received HCI command packet.

[0149] From a data plane perspective, the HCI handler offload 630 will automatically exchange transmit / receive data PDUs between the BLE host and the PDU queuing system 640 (and automatically generate data flow credit HCI event packets), completely decoupled from the BLE-LLL 620 operation, and completely decoupled from the CPU 610 operation.

[0150] Finally, during the steady state of the connection, when only HCI data packets are expected, the BLE controller CPU 610 will not be interrupted for processing HCI interactions.

[0151] C. Link Controller Hardware Offload

[0152] The Link Controller (LC) hardware circuit 622 offloads all real-time mechanisms of the underlying BLE-LL (BLE-LLL 620) air interface protocol from the CPU 610. The LC offload 622 completely abstracts the CPU 610 from the internal LE event operations.

[0153] LC circuit 622 is used as a LE event processing accelerator that is shared / reused between all active contexts (established connection context, advertising context, scanning context, initialization context) of a link or logical transport that is being served simultaneously in the device. A context refers to a collection of state and configuration registers that allow the LC 622 to be reused for different links.

[0154] LC 622 is driven by LE event action commands, which request the processing of a specific type of LE event for a specific link context at a specific start time. When executing LE event commands, LC 622 will handle the following tasks: automatic context switching (save old context, load new context), sequence all packet operations (receive / send / wait) at the correct time within any LE event, perform data plane processing for each packet, perform packet flow control and handle reliability for links in the connected state, and perform BLE-PHY sequencing for each packet (drive power sequencing and configuration sequencing).

[0155] Fig.14 A schematic diagram 1400 of the LC hardware circuit 622 is shown, which interacts with the CPU 610 , the queuing system 640 , the link controller context store (LCCS) 650 , and the BLE-PHY 680 .

[0156] LC 622 corresponds to Figure 2 The transfer sequencer 221 in FIG. 1 and the LCCS 650 correspond to Figure 2 Multiple connection contexts 234-# in.

[0157] Fig.15 A timing diagram 1500 of internal LE event operations performed by the LC is shown (ie, sequencing of LE event_actions).

[0158] LC 622 handles the transfer of PDUs over the air with peer devices within LE events, i.e., drives the low-granularity scheduling of the internal LE event operation sequencing (send, receive, wait, and setup / teardown of BLE-PHY) for each logical transport served in the device. In this context, the LC 622 execution of LE events until completion is called an LE event_action (EA). LC 622 uses the active clock (aclk) for all hard real-time operations.

[0159] like Fig.14 As shown, LC 622 includes four main components: link controller state machine (LCSS) 1410, logical transfer micro-sequencer 1449, logical transfer controller 1420, and LL data path 1430.

[0160] The LCSM 1410 provides the required low-level control to the LC 622 to initiate the execution of LE events for a particular logical transport being serviced at a specific time and during a specific authorized time span. The LCSM 1410 has a leevt_action_cmd interface for accepting dispatched EAs. EAs are dispatched by the LES 624 (during steady state operation) or the CPU 610 (during non-steady state operation). The EA is dispatched through the following service: status←dispatch(cntxt_id,delta_evt,t_ota,t_grant,rx_delay), where cntxt_id is the identifier of the context to be serviced; delta_evt is the number of LE events missed since the last execution of this context; t_ota is the air start time of the LE event; t_grant is the maximum authorized duration of the LE event; rx_delay is the maximum scanning delay for the first received packet in the LE event (an adjustable parameter for window widening and connection establishment), and status indicates the completion status of the LE event action and returns LE event information according to the LE event type.

[0161] Fig.16 A flow chart 1600 is shown of a link control state machine (LCSM) sequence.

[0162] After being dispatched by the EA (step 1610), the LCSM 1410 loads the LC 622 context, logical transport state, and configuration corresponding to the specified logical transport to be serviced (specified by cntxtjd) (step 1620). The logical transport state specifies the type of LE event to be performed (connected slave, connected master, announcement, scan, or initialization). As part of the LC 622 context, the LCSM 1410 also maintains counters, such as packet counters and connection event counters.

[0163] Thereafter, in step 1630, the LCSM 1410 evaluates the adaptive hopping rules (if applicable), and the physical channel for the LE event is selected. With this information, the LCSM 1410 is able to fully configure the LC 622 for operation.

[0164] Thereafter, in step 1640 , the LCSM 1410 calculates the LC 622 trigger time, i.e., the time when the LC 622 must start executing the LE event (t_start) to meet the over-the-air start time (t_ota) of the LE event, taking into account the LC 622 and BLE-PHY 680 setup delays (t_lc_setup).

[0165] At steps 1650 and 1660, when the LC 622 trigger time is reached, the LCSM 1410 requests the operation of the correct logical transport microsequencer (LT-μS) 1440 through the corresponding req / rsp interface, provides appropriate configuration through the corresponding cnfg interface, and thereby delegates the LE event execution to it. During the LE event execution, each packet operation (send or receive) is processed by the corresponding LT-μS 1440 only when the remaining grant time (t_ota+t_grant-actv_time) can fit the maximum length packet (step 1670). When the LE event is completed, at step 1680, the LCSM 1410 saves the updated LC 622 context for the link and signals the dispatched EA to the outside to complete, alternatively, the event closing signaling can be implemented through the event queue in the queuing system 640 (step 1690).

[0166] The LC context is stored in the LCCS 650, and the LCSM 1410 saves and restores the LC context through the LCCS-LCSM interface.

[0167] Finally, to perform LE events for ADVB logical transport, LCSM 1410 delegates the device address filtering / analysis process to DAA 660 and receives an indication of whether to send a turnaround response. This delegation is done through interface devaddr_access_req, which specifies a single service through which ADVB PDUs are transferred for analysis: rsp←result(req_type, src_addr, dst_addr), where req_type is the type of ADVB packet; src_addr is the sender's device address; dst_addr is the destination's device address; rsp is the analysis response, specifying whether the packet is a recipient, whether to close LE events after this packet, and whether BLE host notification is required.

[0168] The logical transport microsequencer (LT-μS) 1440 handles the logical transport real-time sequencing of transmit, receive, and interframe space (IFS) wait operations, keeps track of the authorization time for each LE event, and handles LE event shutdown conditions and internal LE event conditions that require higher-level intervention. Each LT-μS 1440 will typically be implemented as a reconfigurable finite state machine. Different LT-μS 1440s encode the steps in the sequence that require higher-level protocol intervention (e.g., device address filtering) and the different timeouts applied (the timeout during connection establishment is different from the send / receive turnaround timeout). LT-μS 1440 also drives to the control plane of BLE-PHY 680 and triggers the execution of the LC 622 data plane to ensure that it is ready before BLE-PHY 680 executes. There are different LT-μS 1440s for different logical transports (LE-ACL, ADVB, ScanWindow).

[0169] The logical transport controller (LTC) 1420 is responsible for flow control and delivery / reliability guarantees at the PDU level. Reliability applies only to LE-ACL logical transports, as ADVB logical transports do not provide any form of guarantees other than real-time channel access. The PDU level flow control is responsible for interacting with the queuing control block 640 to obtain transmit PDUs from the queuing system 640 and store receive PDUs to the queuing system 640 (through the appropriate queuing system interface).

[0170] LTC 1420 provides additional services for LE-ACL transmission only. LTC 1420 provides arbitration for logical links. Policies can be configured in LTC 1420 to arbitrate (prioritize) between control PDUs or data PDUs when the control queue and data queue for the current link are not empty.

[0171] In addition, LTC 1420 provides interlocking for logical links. Interlocking allows the PDU descriptor of one logical link to lock its own queue or the queue of a complementary logical link. A different PDU must then unlock the queue (for example, a control PDU initiating an encryption process can lock the data PDU queue of the same logical transport, and a control PDU completing the encryption process can then unlock the data PDU queue). This feature corresponds to the barrier mechanism in MO-MACLL 200.

[0172] The LTC 1420 provides a transmit PDU expiration date parsing capability. When the transmit PDU descriptor includes an expiration date, the LTC 1420 omits the packet (and interacts with the LCSM 1410 to generate an error event to the link manager 610) if the expiration date has passed.

[0173] The LL data path (LLDP) 1420 is responsible for bit stream processing, encryption / decryption, packet assembly and disassembly, access address filtering, and BLE-PHY data plane driver.

[0174] D. Queuing System Hardware Offload

[0175] The only hardware offload included in the queuing system 640 is the queue control block (QCB). The state of each queue in the queuing system 640 is maintained by the QCB, thereby ensuring synchronization between decoupled client accesses. Therefore, the CPU 610, BLE-LLL 620, and HCI handler 630 are clients of the queuing system 640 rather than owners. The queue state maintained by the QCB includes, but is not limited to, the following state variables: full indication, empty indication, idle count, use count, head pointer, and tail pointer.

[0176] A secondary (optional) goal of the queuing system is to avoid head-of-line blocking problems, where PDUs from one served logical transport block PDUs from another served logical transport due to ordering within the queue. For this reason, a multi-queue structure is recommended for the PDU queuing system. The QCB 640 provides the following queuing system services to the BLE-LLL 620 through the following instructions: get_txdata_pdu(cntxt_id), get_txctrl_pdu(cntxt_id), put_rxdata_pdu(cntxt_id), and put_rxctrl_pdu(cntxt_id). In all previous cases, cntxt_id identifies the logical transport corresponding to the queue being selected for access.

[0177] A third (optional) goal of the queuing system 640 is to decouple the signaling interface, i.e., to enable ordered persistent storage (until consumed) of notifications of significant BLE-LLL 620 events that occur during hardware-driven LE event execution. To this end, use Fig.14 The event queue shown (located in 640, corresponding to the event queue 250). The interface for the event queue is similar to the PDU queue interface, but instead of carrying PDUs, it carries LC event information. The event queue can only be pushed (or written) by the BLE-LLL 620 and can only be popped (or read) by the CPU 610.

[0178] The following examples relate to further embodiments.

[0179] Example 1 is a wireless device comprising: a processor circuit; and hardware circuitry configured to implement medium access control / link layer (MAC / LL) functions without intervention of the processor circuit during an active steady state of the MAC / LL with scheduled channel access, wherein the steady state is a state of no control packet transmission for a managed connection in connection-oriented communication, or continuous broadcast or scanning operations in connectionless communication.

[0180] In Example 2, the subject matter of Example 1, wherein the processor circuit is configured to store executable microcontrollers used by the hardware circuit to implement the MAC / LL functionality before entering the steady state.

[0181] In Example 3, the subject matter of Example 1, wherein the hardware circuit is configured to implement the MAC / LL functionality without intervention of the processor circuit during an idle steady state of the MAC / LL.

[0182] In Example 4, the subject matter of Example 1, wherein the hardware circuit includes at least one power managed (PM) hardware circuit, the PM hardware circuit being operable during an active state of the MAC / LL and inoperable during an idle state of the MAC / LL.

[0183] In Example 5, the subject matter of Example 1, wherein the hardware circuit comprises at least one always-on (AON) hardware circuit.

[0184] In Example 6, the subject matter of Example 5, wherein the AON hardware circuit is configured to manage a power state of a power managed (PM) hardware circuit, the PM hardware circuit being operable during an active state of the MAC / LL and inoperable during an idle state of the MAC / LL.

[0185] In Example 7, the subject matter of Example 1, wherein the wireless device is a connection-oriented communication device, and the stable state is a state in which a connection schedule or a connection configuration with the second wireless device does not change.

[0186] In Example 8, the subject matter of Example 7, wherein the stable state is terminated when an existing connection with the second wireless device is to be disconnected, a new connection with the second wireless device is to be established, or the existing connection is to be reconfigured according to a request of a higher layer than the MAC / LL or according to a request of the MAC / LL of the second wireless device.

[0187] In Example 9, the subject matter of Example 1, wherein the wireless device is a connectionless oriented wireless device, and the steady state is a state during which the wireless device performs continuous broadcast or scanning operations and the MAC / LL reports any discovered second wireless device to a higher layer than the MAC / LL.

[0188] In Example 10, the subject matter of Example 9, wherein the stable state is terminated when a higher layer requests the stable state to terminate, or when a packet data unit (PDU) is received from the second wireless device causing the continuous broadcast or scanning operation to terminate.

[0189] In Example 11, the subject matter of Example 9, wherein the PDU relates to a connection request.

[0190] In Example 12, the subject matter of Example 1, wherein the wireless device is a wireless sensor / actuator network (WSAN) device.

[0191] In Example 13, the subject matter of Example 1, wherein the wireless device is a Bluetooth (BT), BT Low Energy (LE), ANT, or Long Range (LoRa) device.

[0192] In Example 14, the subject matter of Example 1 further includes a transmit sequencer coupled between the processor circuit and the transceiver and configured to exchange packet data units (PDUs) with the second wireless device via the transceiver.

[0193] In Example 15, the subject matter of Example 14, wherein: the transmit sequencer includes a data path configured to implement MAC / LL functionality, and the MAC / LL functionality includes packetizing PDUs for transmission, depacketizing received PDUs, or performing bitstream processing.

[0194] In Example 16, the subject matter of Example 14, wherein: the transmit sequencer comprises an air interface sequencer configured to implement a MAC / LL function, and the MAC / LL function comprises sequencing transmit, receive, or wait operations.

[0195] In Example 17, the subject matter of Example 14, wherein: the transmit sequencer includes a flow controller configured to implement MAC / LL functions, and the MAC / LL functions include discarding duplicate received PDUs, tracking acknowledgments for transmitted PDUs, flushing acknowledged PDUs from a transmitted PDU queue, or generating null packets to maintain packet exchange with the second wireless device.

[0196] In Example 18, the subject matter of Example 14, wherein: the transmit sequencer includes a receive flow filter configured to implement a MAC / LL function, and the MAC / LL function includes separating a received PDU into a data PDU and a control PDU, or parsing the PDU to obtain field values ​​to perform a task.

[0197] In Example 19, the subject matter of Example 14, wherein: the transmit sequencer includes a transmit flow selector configured to implement a MAC / LL function, and the MAC / LL function includes arbitrating between outgoing transmit data PDUs and transmit control PDUs.

[0198] In Example 20, the subject matter of Example 14 further includes: a radio access scheduling sequencer configured to implement a MAC / LL function, wherein the MAC / LL function includes managing the connection of the transmit sequencer according to the radio access scheduling, managing the power sequence of the transmit sequencer, or triggering the execution of the transmit sequencer.

[0199] In Example 21, the subject matter of Example 14 further includes: an address analyzer configured to analyze an address in a PDU packet received from a second wireless device and determine whether to accept or respond to the PDU packet.

[0200] In Example 22, the subject matter of Example 1 further includes: a host PDU switch configured to implement a MAC / LL function, wherein the MAC / LL function includes controlling transmission / reception of PDUs to / from the host.

[0201] Example 23 is a method of wireless communication, comprising: implementing MAC / LL functions by hardware circuitry without intervention by processor circuitry during an active steady state of a medium access control / link layer (MAC / LL) with scheduled channel access, wherein the steady state is a state of no control packet transmission for a managed connection in connection-oriented communication, or a continuous broadcast or scanning operation in connectionless communication.

[0202] In Example 24, the subject matter of Example 23 further includes: storing by the processor circuit before entering the stable state, wherein implementing the MAC / LL function includes executing an executable microcontroller by the hardware circuit.

[0203] In Example 25, the subject matter of Example 23 further includes: implementing the MAC / LL functionality by hardware circuitry without intervention by processor circuitry during an idle steady state of the MAC / LL.

[0204] Example 26 is a wireless device comprising: a processor circuit; and a hardware device for implementing a medium access control / link layer (MAC / LL) function without intervention of the processor circuit during an active steady state of the MAC / LL with scheduled channel access, wherein the steady state is a state of no control packet transmission for a managed connection in connection-oriented communication, or a continuous broadcast or scanning operation in connectionless communication.

[0205] In Example 27, the subject matter of Example 26, wherein the processor circuit is configured to store executable microcontrollers used by the hardware device to implement the MAC / LL functionality before entering the steady state.

[0206] In Example 28, the subject matter of Example 26, wherein the hardware means is for implementing the MAC / LL functionality without intervention of the processor circuitry during an idle steady state of the MAC / LL.

[0207] In Example 29, the subject matter of Example 26, wherein the hardware device comprises at least one power managed (PM) hardware device, the PM hardware device being operable during an active state of the MAC / LL and inoperable during an idle state of the MAC / LL.

[0208] In Example 30, the subject matter of Example 26, wherein the hardware device comprises at least one always-online (AON) hardware device.

[0209] In Example 31, the subject matter of Example 30, wherein the AON hardware device is configured to manage a power state of a power managed (PM) hardware device, the PM hardware device being operable during an active state of the MAC / LL and inoperable during an idle state of the MAC / LL.

[0210] In Example 32, the subject matter of Example 26, wherein the wireless device is a connection-oriented communication device, and the stable state is a state in which a connection schedule or a connection configuration with the second wireless device does not change.

[0211] In Example 33, the subject matter of Example 32, wherein the stable state is terminated when an existing connection with the second wireless device is to be disconnected, a new connection with the second wireless device is to be established, or the existing connection is to be reconfigured according to a request of a higher layer than the MAC / LL or according to a request of the MAC / LL of the second wireless device.

[0212] In Example 34, the subject matter of Example 26, wherein the wireless device is a connectionless oriented wireless device, and the steady state is a state during which the wireless device performs continuous broadcast or scanning operations and the MAC / LL reports any discovered second wireless device to a higher layer than the MAC / LL.

[0213] In Example 35, the subject matter of Example 34, wherein the stable state is terminated when a higher layer requests the stable state to terminate, or when a packet data unit (PDU) is received from the second wireless device that causes the continuous broadcast or scanning operation to terminate.

[0214] In Example 36, the subject matter of Example 34, wherein the PDU relates to a connection request.

[0215] In Example 37, the subject matter of Example 26, wherein the wireless device is a wireless sensor / actuator network (WSAN) device.

[0216] In Example 38, the subject matter of Example 26, wherein the wireless device is a Bluetooth (BT), BT Low Energy (LE), ANT, or Long Range (LoRa) device.

[0217] In Example 39, the subject matter of any of Examples 26-38 further includes: a transmission sequencing device, coupled between the processor circuit and the transceiver, for exchanging packet data units (PDUs) with a second wireless device via the transceiver.

[0218] In Example 40, the subject matter of Example 39, wherein: the transmit sequencing device includes a data path configured to implement MAC / LL functionality, and the MAC / LL functionality includes packetizing PDUs for transmission, depacketizing received PDUs, or performing bit stream processing.

[0219] In Example 41, the subject matter of Example 39, wherein: the transmit sequencing means comprises an air interface sequencing means for implementing a MAC / LL function, and the MAC / LL function comprises sequencing transmit, receive, or wait operations.

[0220] In Example 42, the subject matter of Example 39, wherein: the transmit sequencing apparatus includes a flow controller configured to implement a MAC / LL function, and the MAC / LL function includes discarding duplicate received PDUs, tracking acknowledgments for transmitted PDUs, flushing acknowledged PDUs from a transmitted PDU queue, or generating null packets to maintain packet exchange with a second wireless device.

[0221] In Example 43, the subject matter of Example 39, wherein: the transmission sorting device includes a receiving flow filter device for implementing a MAC / LL function, and the MAC / LL function includes separating a received PDU into a data PDU and a control PDU, or parsing the PDU to obtain field values ​​to perform a task.

[0222] In Example 44, the subject matter of Example 39, wherein: the transmit ordering apparatus includes a transmit stream selector configured to implement a MAC / LL function, and the MAC / LL function includes arbitrating between outgoing transmit data PDUs and transmit control PDUs.

[0223] In Example 45, the subject matter of Example 39 further includes: a radio access scheduling sequencing device for implementing a MAC / LL function, wherein the MAC / LL function includes managing the connection of a transmission sequencer according to a radio access schedule, managing a power sequence of a transmission sequencer, or triggering the execution of a transmission sequencer.

[0224] In Example 46, the subject matter of Example 39 further includes: an address analyzing device for analyzing an address in a PDU packet received from a second wireless device and determining whether to accept or respond to the PDU packet.

[0225] In Example 47, the subject matter of Example 26 further includes: a host PDU switching device for implementing a MAC / LL function, wherein the MAC / LL function includes controlling transmission / reception of a PDU to / from the host.

[0226] III. Conclusion

[0227] For the purpose of this discussion, the term "processor circuit" should be understood as (one or more) circuits, (one or more) processors, logic, or a combination thereof. For example, the circuit may include analog circuits, digital circuits, state machine logic, other structural electronic hardware, or a combination thereof. The processor may include a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), or other hardware processor. According to the aspects described herein, the processor may be "hard-coded" with instructions to perform corresponding functions. Alternatively, the processor may access internal and / or external memory to obtain instructions stored in the memory, which, when executed by the processor, performs the corresponding (one or more) functions associated with the processor, and / or one or more functions and / or operations related to the operation of the component in which the processor is included. In one or more exemplary aspects described herein, the processor circuit may include a memory for storing data and / or instructions. The memory may be any known volatile and / or non-volatile memory, including, for example, a read-only memory (ROM), a random access memory (RAM), a flash memory, a magnetic storage medium, an optical disk, an erasable programmable read-only memory (EPROM), and a programmable read-only memory (PROM). The memory may be non-removable, removable, or a combination of both.

[0228] Although the foregoing has been described in conjunction with exemplary aspects, it should be understood that the term "exemplary" is intended merely as an example, rather than the best or optimal. Therefore, the present disclosure is intended to cover alternatives, modifications, and equivalents that may be included within the scope of the present disclosure.

[0229] Although specific aspects have been illustrated and described herein, it should be understood by those skilled in the art that various alternatives and / or equivalent embodiments may replace the specific aspects shown and described without departing from the scope of the present application. This application is intended to cover any modifications or variations of the specific aspects discussed herein.

Claims

1. A wireless device comprising: A processor circuit configured to: i) store a hardware configuration separate from a processor circuit configuration prior to entering an active steady state associated with medium access control / link layer (MAC / LL) communication transmission, wherein the hardware configuration is associated with performing MAC / LL functions; and ii) after entering the active steady state, the processor circuit enters a sleep state such that the sleep state of the processor circuit occurs during a portion of a steady state operating mode of the communication transmission; and a hardware circuit separate from the processor circuit, wherein the hardware circuit is configured to implement the MAC / LL functionality according to the stored hardware configuration during the active stable state, when the processor circuit is in the sleep state and without intervention by the processor circuit, The active steady state is a part of the steady state operation mode, which is a state without control packet transmission for a managed connection in connection-oriented communication or continuous broadcast or scanning operation in connectionless communication.

2. The wireless device according to claim 1, wherein: The configuration stored in the hardware circuit includes one or more microcontrollers executable by the hardware circuit to implement the MAC / LL function.

3. The wireless device according to claim 1, wherein: The steady state operating mode includes an idle state, and wherein the hardware circuit is configured to implement the MAC / LL functionality during the idle state while the processor circuit is in the sleep state.

4. The wireless device according to claim 1, wherein: The hardware circuits include at least one power managed (PM) hardware circuit that is operable during an active state of the MAC / LL and inoperable during an idle state of the MAC / LL.

5. The wireless device according to claim 1, wherein: The hardware circuits include at least one always-on (AON) hardware circuit.

6. The wireless device according to claim 5, wherein: The AON hardware circuit is configured to manage a power state of a power managed (PM) hardware circuit that is operable during an active state of the MAC / LL and inoperable during an idle state of the MAC / LL.

7. The wireless device of claim 1, wherein: The wireless device is a connection-oriented communication device, and the stable state is a state in which a connection schedule or a connection configuration with a second wireless device does not change.

8. The wireless device according to claim 7, wherein: The stable state is terminated when, according to a request of a higher layer than the MAC / LL or according to a request of the MAC / LL of the second wireless device, an existing connection with the second wireless device is to be disconnected, a new connection with the second wireless device is to be established, or an existing connection is to be reconfigured.

9. The wireless device of claim 1, wherein: The wireless device is a connectionless-oriented wireless device, and the stable state is a state during which the wireless device performs continuous broadcast or scanning operations and the MAC / LL reports any discovered second wireless device to a higher layer than the MAC / LL.

10. The wireless device of claim 9, wherein: The stable state is terminated when the higher layer requests the stable state to be terminated, or when a packet data unit (PDU) is received from a second wireless device causing the continuous broadcast or scanning operation to be terminated.

11. The wireless device of claim 10, wherein: The PDU relates to a connection request.

12. The wireless device of claim 1, wherein: The wireless device is a Wireless Sensor / Actuator Network (WSAN) device.

13. The wireless device of claim 1, wherein: The wireless device is a Bluetooth (BT), BT Low Energy (LE), ANT, or Long Range (LoRa) device.

14. The wireless device of claim 1, further comprising: A transmit sequencer is coupled between the processor circuit and the transceiver and is configured to exchange packet data units (PDUs) with a second wireless device via the transceiver.

15. The wireless device of claim 14, wherein: The transmit sequencer includes a data path configured to implement the MAC / LL functionality, and The MAC / LL functions include packetizing PDUs for transmission, depacketizing received PDUs, or performing bit stream processing.

16. The wireless device of claim 14, wherein: The transmit sequencer includes an air interface sequencer configured to implement the MAC / LL functionality, and The MAC / LL functions include sequencing send, receive, or wait operations.

17. The wireless device of claim 14, wherein: The transmit sequencer includes a flow controller configured to implement the MAC / LL functionality, and The MAC / LL functions include discarding duplicate received PDUs, tracking acknowledgments for transmitted PDUs, flushing acknowledged PDUs from a transmitted PDU queue, or generating null packets to maintain packet exchange with a second wireless device.

18. The wireless device of claim 14, wherein: The transmit sequencer includes a receive stream filter configured to implement the MAC / LL functionality, and The MAC / LL function includes: separating the received PDU into data PDU and control PDU, or parsing the PDU to obtain field values ​​to perform tasks.

19. The wireless device of claim 14, wherein: The transmit sequencer includes a transmit stream selector configured to implement the MAC / LL functionality, and The MAC / LL functionality includes arbitrating between outgoing transmit data PDUs and transmit control PDUs.

20. The wireless device of claim 14, further comprising: a radio access scheduling sequencer configured to implement said MAC / LL functionality, The MAC / LL functions include: managing the connection of the transmit sequencer according to a radio access schedule, managing the power sequence of the transmit sequencer, or triggering the execution of the transmit sequencer.

21. The wireless device of claim 14, further comprising: An address analyzer is configured to analyze an address in a PDU packet received from a second wireless device and determine whether to accept or respond to the PDU packet.

22. The wireless device of claim 1, further comprising: a host PDU switch configured to implement said MAC / LL functionality, The MAC / LL functionality includes controlling the transmission / reception of PDUs to / from the host.

23. A method of wireless communication, comprising: storing, by the processor circuitry prior to entering an active steady state associated with medium access control / link layer (MAC / LL) communication transmission, a hardware configuration separate from the processor circuitry configuration, wherein the hardware configuration is associated with performing MAC / LL functions; entering a sleep state by the processor circuit after entering the active steady state such that the sleep state of the processor circuit occurs during a portion of a steady state operating mode of the communication transmission; implementing the MAC / LL functionality by hardware circuitry during the active stable state while the processor circuitry is in the sleep state and without intervention by the processor circuitry according to the stored hardware configuration, wherein the hardware circuitry is separate from the processor circuitry, The active steady state is a part of the steady state operation mode, which is a state without control packet transmission for a managed connection in connection-oriented communication or continuous broadcast or scanning operation in connectionless communication.

24. The method of claim 23, storing, by the processor circuit, the hardware configuration before entering the stable state comprises: One or more microcontrollers that can be executed by the hardware circuit to implement the MAC / LL functionality are stored.

25. The method of claim 23, the steady state operating mode comprising an idle state, and the method further comprising: The MAC / LL functionality is implemented by the hardware circuitry during the idle state while the processor circuitry is in the sleep state.

Images