Coexistence hub device, method, electronic device and integrated circuit chip

Abstract

Embodiments relate to coordinating the operation of subsystems in a communication system of an electronic device, wherein a coexistence hub device monitors status information transmitted as coexistence messages over one or more multi-point buses, processes the monitored coexistence messages and sends control messages as coexistence messages to other systems on a chip (SOC). The coexistence hub device can also update the operation of the communication system. The coexistence hub device can receive an operating policy from a central processor and can execute the operating policy without further coordination of the central processor. The coexistence hub device broadcasts the control message as a coexistence message according to the executed operating policy.

Description

Technical Field

[0001] The present disclosure relates to coordinated operation of multiple integrated circuit (IC) chips in electronic devices. Background Art

[0002] An electronic device may include multiple systems on a chip (SOCs) for communicating with other devices using various communication protocols. As the size of communication systems in electronic devices decreases while the functionality of communication systems increases, more SOCs are incorporated into electronic devices, or more subsystems are added to each SOC. These SOCs can communicate with a host (e.g., a central processing unit or an application processor) through a dedicated communication path (e.g., a peripheral component express interconnect (PCIe)) to transfer data.

[0003] As a result of integrating multiple communication systems and other subsystems in an electronic device, various problems or complications may arise. These problems or complications include conflicts in resource usage, interference of shared or overlapping communication bands, mutually incompatible operating modes and isolation between antennas, etc. In conventional electronic devices, such problems or complications are usually solved by coordinating operations on the SOCs, and the problem situations are solved by having a central processor coordinate operations across multiple SOCs. Summary of the invention

[0004] Embodiments relate to a communication hub device that autonomously controls the operation of other SOCs in a communication system via a multi-drop bus shared across the communication hub device and other SOCs. The communication hub device receives, stores, and executes an operation policy without further intervention from a central processor or with limited intervention from a central processor. The communication hub device or other SOCs broadcast coexistence messages over the multi-drop bus to coordinate their operations according to the operation policy, which are received and processed at the communication hub device and other SOCs. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is a high-level diagram of an electronic device according to one embodiment.

[0006] Figure 2 is a block diagram illustrating components of an electronic device that communicates via a multi-drop bus according to one embodiment.

[0007] Figure 3 is a block diagram illustrating a coexistence hub device according to one embodiment.

[0008] Figure 4 According to an implementation scheme Figure 3 Block diagram of a scheduler in a coexisting hub device.

[0009] Figure 5is a block diagram of a SOC according to one embodiment.

[0010] Figure 6 is an interaction diagram illustrating the operation and interaction of components in an electronic device according to one embodiment.

[0011] Figure 7 is a flow chart illustrating a process of applying an operational policy to a detected coexistence event according to one embodiment.

[0012] Figure 8 is a table showing requests in a coexistence message and corresponding possible responses by a coexistence hub device according to one embodiment.

[0013] For purposes of illustration only, the Brief Description of the Drawings and the Detailed Description describe various non-limiting embodiments. DETAILED DESCRIPTION

[0014] Reference will now be made in detail to the embodiments, examples of which are illustrated in the accompanying drawings. Many specific details are shown in the following detailed description to provide a full understanding of the various described embodiments. However, the embodiments may be implemented without these specific details. In other cases, well-known methods, processes, components, circuits, and networks are not described in detail, thereby not unnecessarily obscuring various aspects of the embodiments.

[0015] Embodiments relate to coordinating the operation of subsystems in a communication system of an electronic device, wherein a coexistence hub device monitors status information transmitted as a coexistence message via one or more multipoint buses, processes the monitored coexistence messages and sends control messages as coexistence messages to other SOCs in the electronic device and a local communication system within the hub. The coexistence hub device can also update the operation of the communication system. The coexistence hub device can receive an operation 44989 strategy from a central processor (e.g., an application processor) and can execute the operation strategy without further coordination of the central processor or requiring reduced operation of the central processor. The coexistence hub device broadcasts the control message as a coexistence message according to the executed operation strategy. Other SOCs receive and filter control messages related to their operation and adjust their operation accordingly. The central processor can advantageously be kept in a low power mode or turned off while the coexistence hub device executes the operation strategy, thereby reducing the power consumption of the electronic device. In addition, by avoiding intervention by the central processor, coordinated operations can be performed at a faster speed.

[0016] The coexistence message described herein refers to a message exchanged between components in an electronic device, based on which the operation of the components is coordinated. The coexistence message may be a status message indicating the state of the system, a control message for controlling the operation of a system or a component in the system. Systems associated with coexistence messages may include, but are not limited to, communication systems and sensor systems. For example, a coexistence message indicates the time-of-flight radio state or importance of a radio link service of a communication subsystem at a certain time, which is then used for adjustment of the duty cycle between two or more communication subsystems.

[0017] A coexistence hub device as described herein refers to a device that is capable of autonomously coordinating the operation of coexistence components in a communication device without further intervention from a central processor or requiring reduced intervention from a central processor. A coexistence hub device may include its own subsystems that perform communication operations. A coexistence hub device may be embodied as a separate chip or as part of a larger circuit.

[0018] Exemplary Electronic Devices

[0019] Embodiments of electronic devices, user interfaces for such devices, and associated processes for using such devices are described herein. In some embodiments, the device is a portable communication device, such as a mobile phone, that also includes other functions, such as a personal digital assistant (PDA) and / or a music player function. Exemplary embodiments of portable multifunction devices include, but are not limited to, the Apple Watch from Apple Inc. (Cupertino, California). Devices, iPod Devices, Apple Equipment and Device. Other portable electronic devices, such as wearable devices, laptops, or tablet computers may alternatively be used. In some embodiments, the device is not a portable communication device, but rather a desktop computer or other computing device not designed for portable use. In some embodiments, the disclosed electronic device may include a touch-sensitive surface (e.g., a touch screen display and / or a touchpad). Figure 1 The described example electronic device (eg, device 100) may include a touch-sensitive surface for receiving user input. The electronic device may also include one or more other physical user interface devices, such as a physical keyboard, mouse, and / or joystick.

[0020] Figure 1is a high-level diagram of an electronic device 100 according to one embodiment. The device 100 may include one or more physical buttons, such as a "home" button or a menu button 104. The menu button 104 is used, for example, to navigate to any application in a set of applications executing on the device 100. In some embodiments, the menu button 104 includes a fingerprint sensor that recognizes a fingerprint on the menu button 104. The fingerprint sensor can be used to determine whether the finger on the menu button 104 has a fingerprint that matches a fingerprint stored for unlocking the device 100. Alternatively, in some embodiments, the menu button 104 is implemented as a soft key in a graphical user interface (GUI) displayed on a touch screen.

[0021] In some embodiments, the device 100 includes a touch screen 150, a menu button 104, a push button 106 for turning the device on / off and for locking the device, a volume adjustment button 108, a subscriber identity module (SIM) card slot 110, an earphone jack 112, and a docking / charging external port 124. The push button 106 can be used to turn the device on and off by pressing the button and keeping the button pressed for a predefined time interval; lock the device by pressing the button and releasing the button before the predefined time interval passes; and / or unlock the device or initiate an unlocking process. In an alternative embodiment, the device 100 also accepts voice input for activating or deactivating certain functions through a microphone 113. The device 100 includes various components, including but not limited to a memory (which may include one or more computer-readable storage media), a memory controller, one or more central processing units (CPUs), a peripheral device interface, an RF circuit, an audio circuit, a speaker 111, a microphone 113, an input / output (I / O) subsystem, and other input or control devices. Device 100 may include one or more image sensors 164, one or more proximity sensors 166, and one or more accelerometers 168. Device 100 may include more than one type of image sensor 164. Each type may include more than one image sensor 164. For example, one type of image sensor 164 may be a camera and another type of image sensor 164 may be an infrared sensor that can be used for facial recognition. Additionally or alternatively, image sensors 164 may be associated with different lens configurations. For example, device 100 may include rear image sensors, one with a wide-angle lens and another with a telephoto lens. Device 100 may include Figure 1 Components not shown in the figure, such as an ambient light sensor, a dot projector, and a flood illuminator.

[0022] Device 100 is only one example of an electronic device, and device 100 may have more or fewer components than listed above, some of which may be combined into one component or have a different configuration or arrangement. The various components of device 100 listed above are embodied in hardware, software, firmware, or a combination thereof, including one or more signal processing and / or application specific integrated circuits (ASICs). Although Figure 1 The components in FIG. 1 are shown as being generally located on the same side as touch screen 150, but one or more components may also be located on the opposite side of device 100. For example, the front side of device 100 may include an infrared image sensor 164 for facial recognition and another image sensor 164 as a front camera of device 100. The back side of device 100 may also include an additional image sensor 164 as a rear camera of device 100.

[0023] Exemplary communication system in an electronic device

[0024] Figure 2 2 is a block diagram illustrating components of an electronic device 100 that communicate via a multi-drop bus 220, 224 according to one embodiment. The electronic device 100 may include an application processor 208 (also referred to herein as a "central processor"), a coexistence hub device 212 (also referred to herein as a "coexistence hub device"), SOCs 234A to 234N (collectively referred to herein as "SOC 234"), sensor devices 216A and 216B (collectively referred to herein as "sensor devices 216"), multi-drop buses 220, 224, and structures 222A to 222N, among other components. Figure 2 The components shown in the figure may be part of a communication subsystem in the electronic device 100. The electronic device 100 may include Figure 2 Additional components not shown (e.g., user interface).

[0025] The application processor 208 is a processing circuit in the electronic device 100 for performing various operations. The application processor 208 may include one or more processing cores for executing various software programs and dedicated hardware circuits for performing professional functions, such as processing images, performing security operations, performing machine learning operations, and processing audio signals. The application processor 208 may also perform operations to coordinate the operations of other components in the electronic device 100, including the coexistence hub device 212, the SOC 234, and the sensor device 216. The application processor 208 can operate in a variety of power modes, including a low power mode in which the application processor 208 shuts down most of its components to save power consumption and a high power mode in which most of its components are active. The application processor 208 may also incorporate one or more communication components (e.g., a cellular modem), which may also be embodied as a separate SOC. In one or more embodiments, the application processor 208 relays data between components connected by the multi-point bus 220, 224 in a low power mode. To this end, the application processor 208 can (i) receive signals from devices (e.g., the SOC 234, the sensor device 216, and the coexistence hub device 212) via the multi-drop buses 220, 224, (ii) modify or copy the received signals according to predetermined rules, and (iii) send the modified signals to another device (e.g., the SOC 234, the sensor device 216, and the coexistence hub device 212) via the multi-drop buses 220, 224 to enable the SoC 234 to communicate effectively.

[0026] The coexistence hub device 212 is hardware, software firmware, or a combination thereof that coordinates the operation of the communication system (including, for example, the coexistence hub device 212 and the SOC 234) and related components (e.g., the sensor device 216) in the electronic device 100. To this end, the coexistence hub device 212 stores and executes an operation policy for defining and / or coordinating the operation of the communication system and related components. The coexistence hub device 212 can operate based on the operation policy without further intervention or requiring reduced intervention by the application processor 208. The operation policy can determine the real-time operation of the components (e.g., 234) in the communication system based on factors such as the operating conditions of a particular communication system or the configuration of another communication system in the platform that affects it, the length of time that the communication subsystem remains in a waiting state (e.g., denial of service), the power consumption of each communication subsystem, and the conditions of the channels used by the communication subsystems. Based on the operation strategy, the coexistence hub device 212 performs operations in advance to set up or prepare the communication subsystem for activation or deactivation (or the components of the communication subsystem modify their operating states due to external conditions) so that the activation or deactivation of other communication subsystems occurs without any errors or with reduced degradation. The coexistence hub device 212 may also include one or more communication subsystems that perform communication operations through various physical interfaces. By performing such coexistence operations locally at the communication subsystem, the application processor 208 can remain in a low power mode for a longer period of time regardless of the activity in the communication subsystem, and also free up the resources of the application processor 208 during its high power mode, and provide greater flexibility between communication systems in response to changing conditions. Some systems may present coexistence issues only for short time intervals, so the multi-point bus with the coexistence hub device 212 is suitable for these conditions to take some short-term actions, such as reducing the transmission power, or changing the state of some externally coupled components to adapt other communication subsystems to the brief interval of the coexistence condition. Reference is made below Figure 3 and Figure 4 The details of the coexistence hub device 212 are described in detail. The coexistence hub device 212 may also perform functions other than coordinating operations performed by the application processor 208.

[0027] Each of the SOCs 234 is a circuit, alone or in combination with software or firmware, that performs operations for communicating with one or more external networks or devices using a communication protocol or a security protocol. Each of the SOCs 234 and the coexistence hub device 212 may process different communication protocols and / or be associated with different wireless frequency bands. For example, SOC 234A may perform processing for long-range communications (e.g., cellular communications) while SOC 234B or the coexistence hub device 212 processes short-range communications (e.g., Bluetooth communications). The operation of the SOCs 234 is at least partially controlled by the coexistence hub device 212. Figure 5 An example of the SOC 234B is described in detail.

[0028] Sensor devices 216 are hardware components, either alone or in combination with software of firmware, that sense various characteristics. These sensor devices 216 generate sensor signals representing the sensed characteristics, which can be sent to other components (e.g., SOC 234, coexistence hub device 212, and application processor 208) for further processing. Sensor 216A can be, for example, a compass that sends a sensor signal representing the orientation of electronic device 100, while sensor 216B can be a global positioning system (also known as a global navigation subsystem (GNSS)) module for enhancing the reception of cellular wireless signals or WiFi signals at SOC 234A. Some of sensor devices 216 can be simple stand-alone devices that interoperate with one or more of SOC 234, but still have coexistence issues with other components of electronic device 100. Other sensor devices 216 can be complex sensors with embedded processors and memories that send or receive extensive messages with one or more of SOCs in SOC 234.

[0029] Fabric 222 is a communication channel that enables components in the communication system to communicate with application processor 208. One or more of fabrics 222 may be embodied as a point-to-point connection, such as a peripheral component interconnect express (PCIe), I2C, or a serial peripheral interface (SPI). Figure 2 As shown, SOC 234A, coexistence hub device 212, and SOCs 234B through 234N communicate with application processor 208 via corresponding fabrics 222A through 222N. One or more of fabrics 222 may have high bandwidth and low latency compared to multi-drop buses 224, 220. Figure 2 The structure 222 shown in may be physically separate communication channels or one or more shared physical channels with multiple logical sub-channels.

[0030] Each of the multi-point buses 224, 220 is a communication channel that enables multiple components to communicate through a shared connection. The multi-point bus 220 can be primarily used to transmit coexistence messages between components in the communication system, while the multi-point bus 224 can be primarily used to transmit sensor signals from the sensor devices 216A, 216B to other components in the electronic device 100. However, the multi-point buses 220, 224 can also transmit other types of signals. In addition, the multi-point buses 220, 224 can be combined into a single bus or divided into more buses. In one or more embodiments, a system power management interface (SPMI) is used to embody the multi-point buses 220, 224. Other serial bus interfaces such as I2C can be used instead of SPMI to embody the multi-point buses 220, 24.

[0031] In addition to or in lieu of the multi-point buses 224, 220, general purpose input / output (GPIO) communications may be used between components within or external to the communication system. GPIOs may be used for a variety of reasons, including, but not limited to (i) supporting legacy devices, (ii) for providing a separate communication channel for time-sensitive information, (iii) supporting low-cost devices that lack or do not have the processing power to decode coexistence messages, (iv) enabling communications with devices that may encounter problems with transmissions over a multi-point bus due to, for example, exposure to interference, and (v) enabling dual support for GPIO communications as well as communications over a multi-point bus. These GPIOs may be coupled together to implement a low-level coexistence strategy between two components. As Figure 2 As shown, sensor device 216B can communicate directly with SOC 234A via GPIO 228A, and coexistence hub device 212 can communicate directly with SOC 234B via GPIO 228B. Using another example of sensor device 216B, sensor device 216B can send low-latency data to SOC 234A via GPIO 228 while sending latency-tolerant data to SOC 234A or other components via multi-drop bus 220. Figure 2 , but SPI, PCIe, or both SPI and PCIe may also be used to provide an alternative or additional communication mechanism. Figure 2 2, GPIO 228A is described as interfacing sensor device 216B with SOC 234A, but other physical interfaces such as a serial peripheral interface (SPI), M-PHY, or radio frequency front end (RFFE) interface may be used instead. In one or more embodiments, sensor device 216B may not have direct access to multi-drop bus 220, but instead rely on SOC 234A to communicate over the multi-drop bus via GPIO 228A. In such embodiments, coexistence hub device 212 may control sensor device 216B via SOC 234A to resolve any coexistence issues.

[0032] Despite Figure 2 Not shown, the coexistence hub device 212 may also control operation of or access to one or more antennas (not shown) associated with the communication system.

[0033] Example Architecture of Coexisting Hub Devices

[0034] Figure 32 is a block diagram illustrating a coexistence hub device 212 according to one embodiment. The coexistence hub device 212 is a portion of a communication system that coordinates the operation of components in the communication system. The coexistence hub device 212 may also handle communications through protocols that are different from or partially overlap with the communications performed by the SOC 234.

[0035] To this end, the coexistence hub device 212 may include a processor 304, a coexistence control circuit 314, a fabric interface 310, multipoint interfaces 340A, 340B (collectively referred to as "multipoint interfaces 340"), communication subsystems 336A to 336Z (collectively referred to as "communication subsystems 336"), and an internal structure 352, among other components. The coexistence hub device 212 may include Figure 3 Additional components not shown or may be omitted Figure 3 Components shown in (eg, one or more of communication subsystems 336 ).

[0036] The processor 304 is a circuit, alone or in combination with software or firmware, that controls the overall operation of the coexistence hub device 212 and the coordinated operation of other SOCs 234 using coexistence messages. The processor 304 may include memory to store an operating policy 352 for controlling operation. The operating policy 352 may be received from the application processor 208 via the fabric 222B, the fabric interface 310, and the internal fabric 342. After receiving the operating policy 352, the processor 304 may decode the operating policy 352 and, if applicable, program other components in the coexistence hub device 212 (e.g., the coexistence control circuit 314) to execute the operating policy 352. Additional information related to the operating policy 352 may also be received from the application processor 208. Such additional information may be stored or processed at the processor 304 to affect the implementation of the operating policy 352. In addition, the processor 304 may send a portion of the operation policy 352 related to the other SOC 234 via the multi-drop bus 220 to program the SOC 234 to operate according to the operation policy 352. The processor 304 may make coexistence decisions according to the operation policy 352 by analyzing coexistence messages (e.g., status information or requests) received from the SOC 234 and the communication subsystem 336 via the interface 340A and other messages (e.g., sensor signals) received via the interface 340B. The processor 304 may store the current state 354 of the communication subsystem 336 and the other SOC 234 in the coexistence hub device 212. The current state 354 may include, for example, the radio frequency (RF) band / channel used by the SOC 234 and the coexistence hub device 212, the transmission power of the radio signal. Such information may also be sent to the application processor 208 or other SOC 234 to enable real-time adjustment of operations in the other SOC 234. Processor 304 may delegate some coordination operations (eg, coordination of communication subsystem 336 ) to arbitrator 322 .

[0037] As described herein, an operation strategy refers to a scenario of a combination of operations that may be problematic in a communication system or a combination of components with intercommunication problems, and also refers to a set of rules that define the operations to be taken by the SOC 234 and the coexistence hub device 212 to solve or handle such problematic scenarios. Such rules can be designed to take into account various considerations, including but not limited to resource usage, interference of shared or overlapping communication bands, and power usage. In one or more embodiments, the rules can be stored in the form of a lookup table. These lookup tables can be accessed by hardware, software, firmware, or a combination thereof in the processor 304 to implement the operation strategy. In other embodiments, the operation strategy may include firmware code and enable dynamic response to maintain balanced operation between multiple communication subsystems. In some cases, the rules or conditions of interference are only applicable to a limited time, so the hub will dynamically activate / deactivate mitigation in response to a behavior pattern that may be sent in advance or in response to a message dynamically received from an external system.

[0038] The processor 304 may also communicate with the SOC 234 or other components in the electronic device 100 via the GPIO. Figure 2 and Figure 3 A coexistence hub device 212 is shown communicating with the SOC 234B, but the GPIOs may be omitted or other additional GPIOs may be provided for communicating with other components in the electronic device 100 .

[0039] In one embodiment, when the coexistence hub device 212 is first initialized, the processor 304 receives the entire operating policy from the application processor 208. In other embodiments, the processor 304 receives the relevant portion of the operating policy from the application processor 208 as each communication subsystem 336 and / or SOC 234 is turned on. In some embodiments, the application processor 208 may continue to send context information to the coexistence hub device 212 and other devices. The application processor 208 may also receive context information from the coexistence hub device 212, SOC 234. In this embodiment, the turning on of the communication subsystem 336 and / or SOC 234 may be communicated to the application processor 208, which causes the application processor 208 to send the relevant portion of the operating policy to the processor 304.

[0040] In another embodiment, the processor 304 is pre-loaded with a default operating policy 352. In this embodiment, the processor 304 does not receive an operating policy from the application processor 208. In this case, the application processor 208 can send an updated default operating policy 352 to the coexistence hub device 212 for deployment. Such a default operating policy 352 can be based on the geographic region in which the device 100 is operating so that regulatory restrictions in the geographic region can be met.

[0041] Each of the communication subsystems 336 includes circuitry for processing signals received from or sent to a corresponding physical layer interface 308A to 308Z (collectively, “physical layer interface 308”) external to the coexistence hub device 212. Such circuitry may include local processors 378A to 378Z (collectively, “local processors 378”) that perform one or more of the following operations: (i) execute commands associated with certain communication protocols, (ii) process received incoming communication signals according to the corresponding protocols to decode the incoming radio signals and respond by encoding certain responses within a required time budget on the RF link, (iii) control the associated radio frequency (RF) path to adjust transmit power or receive gain control, and (iv) configure, disable, or enable components in the communication subsystem 336 based on an operating policy. When the coexistence hub device 212 is turned on, all of the local processors 378 or at least a subset of these local processors 378 may be initialized (e.g., by the application processor 208 or automatically). Among other things, the local processor 378 is programmed with a portion of the operating policy related to the operation of its communication subsystem 336. The operating policy of the local processor 378 downloaded to the communication subsystem 336 can define how the communication subsystem 336 should operate (e.g., the data rate of the communication subsystem, turning components in the communication subsystem 336 on or off, and changing the number of active transmitters or changing how those transmitters are configured to reduce disruptions, such as applying blanking or power backoff for a specific duration). The policy can be valid only for a repeated limited duration, so the communication subsystem 336 can dynamically engage or disengage mitigation in response to an incoming message from an external system notifying a triggering event. Alternatively, as each of the communication systems 336 is turned on, the relevant portion of the operating policy can be downloaded and programmed directly by the application processor 208 through the structure 222B or by the processor 304 in sequence. One or more of the communication subsystems 336 can communicate with the physical layer interface (e.g., RF device) via, for example, a radio frequency front end control interface (RFFE).

[0042] In some embodiments, the physical layer interface 308 can be consolidated into a reduced set, where the local processor 378 supports more than one communication protocol or switches between different communication protocols over time. The local processor 387 can control a fixed set of radio paths or only the front-end switches, and the LNA or PA can be controlled by the physical layer interface 308.

[0043] The interfaces 340A, 340B are hardware circuits or a combination of hardware circuits, software and firmware for communicating with the multi-drop buses 220, 224. In one or more embodiments, the interfaces 340A, 340B include circuits for processing data into outbound datagrams for transmission over SPMI and unpacking inbound datagrams into data. The interfaces 340A, 340B are connected to the processor 304 and the coexistence control circuit 314 via connections 328, 326, respectively.

[0044] Fabric interface 310 is a hardware circuit or a combination of hardware circuits, software, and firmware that enables coexistence hub device 212 to communicate with application processor 208 via fabric 222B. In one or more embodiments, fabric interface 310 performs operations such as buffering, splitting / assembling data, serializing / deserializing, and packing / unpacking data for communication over a point-to-point communication channel (e.g., PCIe). Figure 3 As shown, the fabric interface 310 is connected to the internal fabric 342 to enable communication between components in the coexistence hub device 212 and the application processor 208 .

[0045] The coexistence control circuit 314 is a circuit, alone or in combination with firmware or hardware, that processes coexistence messages transmitted over the multi-drop bus 220. The coexistence control circuit 314 is programmed by the processor 304 to execute the operating policy 352 by making real-time decisions on coexistence events, publishing inbound coexistence messages to relevant communication subsystems 336, sharing real-time coexistence messages between communication subsystems 336, and sending outbound coexistence messages to other SOCs 234. Coexistence events, as described herein, refer to conditions or occurrences defined by the operating policy that will prompt coordination of operations among the components of the electronic device 100.

[0046] Specifically, the coexistence control circuit 314 may include a scheduler 312, a memory 316, an arbitrator 322, and a notice board 326, among other components. The scheduler 312 is a programmable circuit or a circuit combined with software or firmware that is used to filter and send messages for each communication subsystem 336 to the memory 316. In a multi-threaded system, there may be multiple such memories 318A to 318Z to enable multiple systems to send or receive coexistence messages in parallel. Figure 3 The details of the scheduler 312 and its functions are described in detail.

[0047] The memory 316 has a plurality of buffers 318A to 318Z (collectively referred to as "buffers 318"), each of which corresponds to each of the communication subsystems 336. Each of the buffers 318 receives and stores inbound coexistence messages associated with the corresponding communication subsystem 336 (received from components external to the coexistence hub device 212 via the multipoint bus 220). The inbound coexistence messages stored in the buffers 318 can be sent to the corresponding communication subsystem 336 (as shown by arrow 372) via the internal structure 342 based on priority (e.g., time-sensitive data has a higher priority than time-insensitive data). If one or more communication subsystems 336 are inactive, the buffers 318 store the messages until the communication system 336 is turned on and becomes available to receive the messages. In one or more embodiments, different buffers 318 can be associated with different priorities. When a buffer assigned a high priority is filled with a message, the communication system 336 can wake up to serve to ensure that the message is processed in a timely manner. Each of the buffers 318 also stores outbound coexistence messages 348 (received from the corresponding communication subsystem 336 via the internal structure 342). The outbound coexistence messages are retrieved by the scheduler 312 and are also sent to components external to the coexistence hub device 212 via the multi-drop bus 220 based on priority (e.g., time-sensitive data has a higher priority than time-insensitive data).

[0048] The memory 316 also includes a shared memory portion 320 that is accessible by an arbitrator 322 to resolve conflicting uses of resources and by different local processors 378 to exchange time-sensitive coexistence messages between the communication subsystems 336. The communication subsystems 336 can submit their tasks along with requests from other SOCs 234 to a memory queue to be serviced by the arbitrator 322.

[0049] The memory 316 can also be used to share context information between different communication subsystems 336. For example, the context information can be used to plan and sequence activities that use radio resources in advance. By planning the timeline in advance, enhanced coexistence operations can be performed. The plan can also sequence the activities in a way that provides better immunity to jammers and interceptors at the expense of in-band SNR.

[0050] Notice board 326 is a circuit alone or in combination with software or firmware that stores the status information of communication subsystem 336. Status information 346 is received from communication subsystem 336 and stored for access. Notice board 326 enables the communication subsystem or external components in coexisting hub device 212 to accurately determine the operating context of another system by accessing the status information in notice board 326. In one or more embodiments, other SoC 234 may also include a notice board that enables SOC 234 to simultaneously notify its context. Notice board may include a memory area. Incoming messages in the memory area of ​​the notice board may trigger the communication subsystem to respond within a predetermined time. In one or more embodiments, if SOC 234 cannot perform direct message transfer between itself for some reason, notice board 326 is also used as an alternating buffer to exchange signals or data between SOC 234 via multi-point bus 220, 224.

[0051] The arbitrator 322 is a circuit, alone or in combination with software or firmware, that makes decisions regarding the real-time coordination of the operation of the communication subsystem 336 and sends the decisions to the communication subsystem 336 through the internal structure 342 and the memory 316. Such decisions may include resolving competing demands for common resources by multiple communication subsystems 336 or requests for incompatible resources by different communication subsystems 336. The arbitrator 322 makes decisions in real time and may remain valid for a shorter period of time than decisions made at the processor 304 to implement the operating policy 352. In addition, the arbitrator 322 may resolve requests for resource use by external communication subsystems that compete with the local communication subsystem 336 for the use of the same resources. For this purpose, the arbitrator 322 may access the current state 354 of the communication subsystem 336 and other SOCs 234 stored in the processor 304 and use information about the priority of different competing operations. The algorithm for resolving resource conflicts at the arbitrator 322 may be adjusted based on the operating policy 352 executed by the processor 304. The arbitrator 322 may be programmed by the processor 304 or the application processor 208. Decisions made by the arbitrator 322 may include, for example, controlling RFFE transactions associated with the communication subsystem 336 to change settings of external RF devices. Such operations may include blanking power amplifier transmissions of the corresponding communication subsystem 336. Because real-time decisions are issued through the shared internal structure 342, a communication subsystem (e.g., communication subsystem 336A) can receive decisions intended for another communication subsystem (e.g., communication subsystem 336B) and adjust its operations accordingly. The arbitrator 322 may include a processor 323 to control the overall operation of the arbitrator 322.

[0052] In one or more embodiments, the arbitrator 322 can communicate with components external to the coexistence hub device 212 via GPIO 228B to obtain low-latency data. For example, the arbitrator 322 can receive sensor data from one or more of the sensors 216 and make real-time decisions. Alternatively, the arbitrator 322 can control the communication subsystem through the GPIO and disable other communication subsystems. In another embodiment, the arbitrator 322 assists the communication system to manage the response to asynchronous unexpected external blockers, and manages the radio response in the following manner to avoid impaired performance due to the sudden appearance of external jammers or blockers: disabling the affected radio path and triggering the associated firmware / software to enable the radio path but maintain the link with higher linearity, despite the jammer even having reduced in-band SNR or error vector magnitude (EVM) performance.

[0053] In one or more embodiments, processor 304 determines a larger scale coordinated operation based on its operating policy 352 and configures components of coexistence control circuitry 314, communication subsystem 336, and possibly SOC 234 to implement operating policy 352. Arbiter 322, on the other hand, coordinates smaller scale real-time coexistence operations consistent with the larger scale coordinated operation defined by operating policy 352.

[0054] Example architecture of the scheduler

[0055] Figure 4 According to an implementation scheme Figure 3 2 is a block diagram of a scheduler 312 in a coexistence hub device of FIG. The scheduler 312 is a circuit or a combination of circuits, software and / or firmware for processing coexistence messages. The scheduler 312 determines whether requests or coexistence messages from the communication subsystem 336 should be sent to the SOC 234 in a certain order / priority, and if so, forwards the requests or coexistence messages via the multi-point bus 220. The scheduler 312 also receives coexistence messages from the SOC 234 and forwards a relevant subset of all of these messages to the communication subsystem 336, so that each of these subsystems 336 receives only relevant messages. The scheduler 312 may include a processor 436, an interrupt manager 428, a timestamp 440, and a message filter 432, among other components. One or more of the interrupt manager 428, the timestamp 440, and the message filter 432 may be embodied as firmware of software executed by the processor 436. In addition, additional components may be added to the scheduler 312.

[0056] Processor 436 is a circuit that can perform various operations in scheduler 312, such as (i) managing competing resources within each communication subsystem 336, (ii) controlling external RF control blocks outside of coexistence hub device 212, (iii) supporting the functions and operations of arbitrator 322, and (iv) coordinating the reporting of results from arbitrator 322 to components on multi-drop bus 220. Processor 436 can be part of processor 304, or it can be a separate processor. Processor 436 can also update the operations of other components in scheduler 312 over time or depending on activities in electronic device 110.

[0057] The message filter 432 is hardware, software, firmware, or a combination thereof that receives inbound coexistence messages 422 from the multi-drop bus 220 via the interface 340A, filters the inbound coexistence messages 422 for association with the communication subsystem 336, and sends the filtered inbound coexistence messages 454 to the appropriate buffer 318 and / or shared portion 320 of the memory 316. The message filter 432 may also redirect the inbound coexistence messages 454 to buffers associated with communication subsystems 336 other than the default communication subsystem 336 to ensure that the active communication subsystem 336 receives all relevant inbound coexistence messages. By configuring the message filter 432, a communication system (e.g., 336A) may receive inbound coexistence messages intended for another communication system (e.g., 336B) and consider such inbound coexistence messages for its operation. The message filter may also be operable when the communication subsystem 336 is in radio sleep state to receive a limited set of messages from an external SoC to record some important state changes of the external system that may affect the communication subsystem 336 in radio sleep or to request a limited set of functions on the communication subsystem 336 to wake up briefly to allow sharing of external shared devices. The message filter 432 may also perform the same operation for inbound sensor messages received from the interface 340B. If the inbound coexistence message includes an interrupt, the message filter 432 sends the corresponding coexistence message 442 to the interrupt manager 428.

[0058] The interrupt manager 428 is hardware, software, firmware, or a combination thereof that manages interrupts. When the interrupt manager 428 receives a coexistence message 442 including an interrupt, the interrupt manager 428 extracts the interrupt and sends an interrupt signal 414 to the corresponding communication subsystem 336. The interrupt signal 414 can shut down the corresponding communication subsystem 336, power down a subset of its components, wake up from a power-down mode, or indicate the real-time status of a component (e.g., SOC 234) on the multi-drop bus 220. These interrupt signals can involve only a simple decoder and no microprocessor, which enables low-cost components to send interrupt signals to transmit simple coexistence messages through the multi-drop bus 220. One of the characteristics of interrupt signals is that they are sticky, which means that even if the SOC (e.g., SOC 234B) is in a sleep state when the coexistence hub device 212 sends the interrupt signal, the SOC (e.g., SOC 234B) will respond to the interrupt signal after the SOC (e.g., SOC 234B) wakes up at a later time. These interrupt signals can also be used to ensure that an external SOC (e.g., SOC 234B) can suddenly enter an inactive state / sleep state without requiring other components (e.g., SOC 234A) to stay awake long enough to complete handshake operations with the SOC (e.g., SOC 234B). By using always-on interrupt signals, the burden on the source of the initiating message can be reduced.

[0059] The message filter 432 may also receive an interrupt signal 450 from the communication subsystem 336. If the interrupt signal 450 is intended for the SOC 234, the message filter 432 sends the interrupt 450 as an outbound coexistence message 418 to the interface 340A for transmission via the multi-drop bus 220. Interrupt signals between the communication subsystems 336 are transmitted through the internal structure 342 without intervention by the coexistence control circuit 314.

[0060] Timestamp 440 is a circuit that tracks the time of incoming and outgoing messages on multi-point bus 220. In some embodiments, more than one SoC operates from the same reference time. By imprinting the internal reference time on the incoming message, coordination between the SoCs can be performed more closely. The arrival time can also be used to determine the approximate time to release radio resources (for example, if the delay to be disabled is included in the incoming message). Timestamp 440 tracks the actual time when the message is sent or received to account for arbitration delays. Timestamp 440 can be used to monitor actual damage to the link by external systems so that the local system can modify the behavior pattern sent in advance to the victim system about when to expect damage. In systems where the duration of coexistence problems is actually shorter, it is advantageous to be able to track the interval of upcoming damage so that the radio components can avoid planning certain activities during those times, or take some mitigation actions such as repeating the transmission packet during the interval to help the radio network communicating with device 100 in managing the reliability of reduced performance.

[0061] Example Architecture of a SOC

[0062] Figure 5 is a block diagram of a SOC 234B according to one embodiment. Figure 5 234B is shown as an example in FIG. 234B , but other SOCs 234A, 234C to 234N may have the same or similar architecture as the SOC 234B.

[0063] SOC 234B is part of the communication system in electronic device 100 and can use its communication subsystems 536A, 536B (collectively referred to as "communication subsystem 536") to execute one or more communication protocols. Figure 5 Only two communication subsystems 536A, 536B are shown in FIG. 2 , but more than two communication subsystems or only a single communication subsystem may be included in SOC 234B. Figure 52 and 3. In the embodiment of the present invention, two communication subsystems 536A and 536B are shown, but there may be a common radio device to support both communication subsystems 536A and 536B in a time-sharing manner, or there may be a radio device that is reconfigured between different modes to support both communication subsystems 536A and 536B. Communication subsystems 536A and 536B may each be associated with a different communication protocol, or both may be associated with the same communication protocol. Communication subsystem 536 is substantially the same as communication subsystem 336, except that the coexistence message associated with communication subsystem 536 is processed by processor 512 instead of coexistence control circuit 314. Communication subsystem 536 may send coexistence messages to coexistence hub device 212 via multi-point bus 220 to coexist with the communication subsystem and / or other SOC in the coexistence hub device. Inbound coexistence messages to SOC234B are processed locally by processor 512 and sent to the corresponding communication subsystem 536. For the sake of brevity, other detailed explanations of communication subsystem 536 are omitted herein.

[0064] In addition to the communication subsystem 536, the SOC 234B may also include a fabric interface 502, a bus interface 504, a processor 512, and an internal bus 540 for connecting these components, among other components. The SOC 234B may include additional components, such as memory for buffering coexistence messages associated with each communication subsystem 536.

[0065] The bus interface 504 is circuitry, alone or in combination with software or hardware, that enables components of the SOC 234B to communicate with the coexisting hub device 212 and other SOCs over the multi-drop bus 220 .

[0066] Fabric interface 502 is circuitry, alone or in combination with software or hardware, that enables components of SOC 234B to communicate with application processor 208 over fabric 222C. Communications over fabric interface 502 can transfer data at faster speeds and higher bandwidths than communications over bus interface 504.

[0067] The processor 512 manages the overall operation of the SOC 234B. The processor 512 may include an interrupt manager 516 and a message filter 518, etc., as software or hardware components. The functions and operations of the interrupt manager 516 and the message filter 518 are substantially the same as those of the interrupt manager 428 and the message filter 432, and therefore, for the sake of brevity, a detailed explanation of these components is omitted herein.

[0068] The processor 512 can also communicate with other components of the electronic device 100 via GPIO. Figure 5In the example of , the processor 512 is shown as communicating with the coexistence hub device 212 via the GPIO 228B. However, the GPIO 228B may be omitted, and an SPI bus or another communication link may instead be used for the processor 512 to communicate directly with other components of the electronic device 100 to transfer time-sensitive data.

[0069] The processor 512 and / or the communication subsystem 536 may be programmed by the processor 304 or the application processor 208 of the coexistence hub device 212 to implement the operating policy 352. In one embodiment, such programming may be performed when the SOC 234B is turned on.

[0070] Example Process for Coordinated Coexistence Operations

[0071] Figure 6 6 is an interaction diagram illustrating the operation and interaction of components in the electronic device 100 according to one embodiment. The application processor 208 operates 602 in a first power mode (e.g., a full power mode). When in the first power mode, the application processor 208 sends 606 an operating policy to the coexistence hub device 212 via the structure 212B. The application processor 208 may also send 618 an initial operating policy associated with the SOC 234 to the SOC 234 via the corresponding structure 222. After the application processor 208 issues the operating policy, the application processor 208 may switch 610 to a second power mode (e.g., a reduced power mode or a sleep mode). The application processor 208 may continue to send updates to the coexistence hub device 212 and other SoCs 234.

[0072] The coexistence hub device 212 then deploys and begins applying 614 the operating policy. The coexistence hub device 212 may also send the operating policy associated with the SOC 234 to initialize or update the rules for operating the SOC 234. For example, the associated operating policy may be sent to the SOC for initialization when the SOC is turned on.

[0073] The coexistence hub device 212 coordinates the operation of its communication subsystems according to the operation policy 622. Such operations include programming the coexistence control circuit 314 and the processor 378 of the communication subsystem 336. If one or more of the communication subsystems 336 are turned off, the programming operations may be performed after the communication subsystem 336 is turned on.

[0074] After the SOC 234 receives the relevant operating policy (from the application processor 208 or the coexistence hub device 212), the SOC 234 can deploy and apply 626 the relevant policy to its operation. The SoC 234 can notify other SoCs and the application processor 208 of changes in its configuration related to coexistence with other SOCs. This enables the SoC 234 to plan its appropriate configuration to reduce the impact from other SOCs.

[0075] When a coexistence event occurs 630 (e.g., wireless signal interference is experienced in one of the SOCs or a known triggering event such as the use of a particular resource that may affect another SoC), the SOC 234 experiencing the event sends 634 a coexistence message 634 to the coexistence hub device 212 via the multi-drop bus 220. Alternatively, the SoC 234 that initiated the triggering event may quickly inform the coexistence hub device 212 and the affected SoCs about the change. The SOC 234 may not be able to fully resolve how to respond to the external triggering event by itself. In such cases, the SOC 234 may coordinate for additional data such as regulatory information via the application processor 208 or by changing the clock schedule of relevant coexistence hardware signals, and the coexistence hub device 212 may respond to the received coexistence message by applying 638 an operating policy and taking actions to resolve the coexistence event, as described below with reference to Figure 7 The policy may also mean that certain SoCs 234 are restricted from using certain operating modes, while another SoC operates under conditions where its performance will be significantly affected by the triggering event. In addition to the coexistence hub device 212, other SOCs 234 may also receive coexistence messages through the shared multi-drop bus 220 and adjust their operations responsively.

[0076] Actions taken by the coexistence hub device 212 include adjusting the operation of one or more of its communication subsystems 336 and / or generating and sending 642 another coexistence message 642 including a command or interrupt to the other SOC 234 to control its operation.

[0077] In response to receiving the coexistence message including the command or interrupt, the SOC 234 associated with the coexistence message updates 646 its operation according to the command or interrupt in the coexistence message to adapt to the adverse radio conditions. The SoC 234 can monitor the impact of the interference source and report the impact to the coexistence hub device 212 so that the coexistence hub device 212 can take further action on the interference source to improve the link condition of the victim.

[0078] In addition to or in lieu of sending 642 the coexistence message, the coexistence hub device 212 may update the operation of its communication subsystem 336 according to the operating policy 352 to account for the coexistence event.

[0079] although Figure 6 The scenario of a coexistence event occurring in the SOC 234 is shown, but the coexistence event may also occur within the coexistence hub device 212. In such a case, the coexistence hub device 212 may update the operation of its components or send 642 a coexistence message including a command to the relevant SOC 234 to handle its coexistence event. A similar set of responses may occur within the coexistence hub device 212 when two communication subsystems are affected, such as occurs externally between the SoCs 234.

[0080] By having the coexistence hub device 212 process coexistence messages and resolve coexistence events without involving the application processor 208, the application processor 208 can remain in the second power mode 610 without consuming additional power. Additionally or alternatively, resources (e.g., computing resources) at the application processor 208 can be preserved for other operations even though the application processor 208 is in the first power mode. Furthermore, greater autonomy and faster coordination in the SoC can be achieved.

[0081] Figure 6 The processes and their sequence shown in are illustrative only. Additional processes may be added and may be omitted. Figure 6 For example, the process of sending the relevant policy 618 from the coexistence hub device 212 to the SOC may be omitted, and only the application processor 208 may be relied upon to send the relevant policy to the SOC 234. In addition, after sending 606 to the coexistence hub device 212, the application processor 208 may remain in the first power mode without switching to the second power mode.

[0082] In addition, despite Figure 6 2, but the application processor 208 may send an updated operating policy for deployment and application after the initial operating policy is deployed in the coexistence hub device 212. The updated operating policy may be determined based on the detection of any event by the application processor 208 or after reading the current state 354 in the coexistence hub device 212.

[0083] Figure 7 is a flow chart illustrating a process of applying 638 an operational policy to a detected coexistence event according to one embodiment. A request in a coexistence message from a source SOC (eg, SOC 234A) is extracted 702 by the coexistence hub device 212 .

[0084] The coexistence hub device 212 determines 704 whether a conflict is detected in the request in the coexistence message. If so, the coexistence hub device 212 determines the allowed adjustments to the operation of the SOCs other than the source SOC (SOC 234A) and the communication subsystem 336 in the coexistence hub device 212 according to the operating policy.

[0085] The coexistence hub device 212 then generates a coexistence message that includes a command for issuance to the SOC 234 over the multi-drop bus 220. The command instructs the SOC 234 to adjust its operation.

[0086] If no conflict is detected, a coexistence message including a command for adjusting the operation of the source SOC (eg, SOC 234A) is generated 722 for transmission over the multi-drop bus 220 .

[0087] The current state 354 of the SOC 234 and the communication subsystem 336 in the coexisting hub device 212 is updated 718 .

[0088] Figure 7 The processes and their sequence shown in are illustrative only. Additional processes may be added and may be omitted. Figure 7 For example, the process of updating 718 the current state can be performed after determining 710 the allowed adjustments.

[0089] Figure 8 234 and the communication subsystem 336. The second column of the table indicates the corresponding response or command that may be included in the coexistence message in response to the request. "Accept" indicates that the request made by the SOC 234 and the communication subsystem 336 is accepted. "Reject" indicates that the request made by the SOC 234 and the communication subsystem 336 is rejected, and the source SOC continues to operate in its current operating mode. "Notify alternative frequency band", "Allow small power increase", "Allow small power reduction" and "Notify alternative antenna" are actions that are neither acceptance nor rejection, but are alternative action processes taken by the SOC 234 or the communication subsystem 336.

[0090] While specific embodiments and applications have been illustrated and described, it should be understood that the invention is not limited to the precise construction and components disclosed herein, and that various modifications, changes and variations that will be apparent to those skilled in the art may be made to the arrangement, operation and details of the methods and apparatus disclosed herein without departing from the spirit and scope of the present disclosure.

Claims

1. A coexistence hub device, comprising: a first interface circuit configured to communicate via a multi-drop bus connected to a communication chip in the electronic device; a second interface circuit, the second interface circuit being configured to communicate with a central processor in the electronic device via a point-to-point connection; and A processor circuit, the processor circuit being configured to: receiving an operation strategy from the central processor, the operation strategy representing a problem scenario of an operation combination in the communication chip and a rule for solving the problem scenario, deploy the received operational policy, receiving a first coexistence message from at least one communication chip via the first interface circuit and the multi-point bus, determining whether one or more of the problem scenarios has occurred by processing at least the received first coexistence message, and In response to determining that the one or more of the problem scenarios have occurred, a second coexistence message is generated representing a command to update the operation of at least one of the communication chips by applying the operation policy.

2. The coexistence hub device according to claim 1, further comprising: At least one communication subsystem is configured to implement a communication protocol, wherein in response to determining that the one or more of the problem scenarios have occurred, the operation of the at least one communication subsystem is updated by the processor circuit.

3. The coexistence hub device according to claim 2, further comprising a coexistence control circuit, wherein the coexistence control circuit is configured to: Operation of the at least one communication subsystem is coordinated according to the operating policy.

4. The coexistence hub device of claim 3, wherein the coexistence control circuit is further configured to: filtering inbound coexistence messages from the communication chip for forwarding to be stored in a memory associated with the at least one communication subsystem; and The stored inbound coexistence message is sent to the at least one communication subsystem.

5. The coexistence hub device of claim 4, wherein the at least one communication subsystem, the processor circuit, and the coexistence control circuit are connected to an internal structure.

6. The coexistence hub device of claim 2, wherein the processor circuit is further configured to program the at least one communication subsystem according to the operating policy in response to the at least one communication subsystem being turned on.

7. The coexistence hub device of claim 1, wherein the first coexistence message or the second coexistence message comprises an interrupt.

8. The coexistence hub device of claim 7, wherein the interrupt causes a component in the coexistence hub device to be turned on or off.

9. The coexistence hub device according to claim 1 further includes a third interface, which is configured to communicate with at least one sensor device via another multi-point bus, wherein the processor circuit determines whether one or more of the problem scenarios have occurred by further processing the sensor messages received from the at least one sensor device.

10. The coexistence hub device of claim 1, wherein after sending the operating policy to the coexistence hub device, the central processor switches from a first power mode to a second power mode that consumes less power than the first power mode.

11. The coexistence hub device of claim 1, further comprising a billboard circuit configured to buffer signals on the multi-drop bus between the communication chips.

12. A method for coordinating the operation of a communication chip in an electronic device, comprising: receiving, by the coexistence hub device, an operation strategy from a central processor, the operation strategy representing a problem scenario of an operation combination in the communication chip and a rule for solving the problem scenario; deploying the received operating policy in the coexistence hub device; receiving, by the coexistence hub device, a first coexistence message from at least one communication chip via a multi-drop bus; determining, by the coexistence hub device, whether one or more of the problem scenarios have occurred by at least processing the received first coexistence message; generating, by the coexistence hub device, a second coexistence message representing a command to update operation of at least one of the communication chips by applying the operation policy, in response to determining that the one or more of the problem scenarios have occurred; as well as The second coexistence message is sent by the coexistence hub device to the communication chip via the multi-drop bus.

13. The method according to claim 12, further comprising: implementing a communication protocol by at least one communication subsystem in the coexistence hub device; as well as Operation of updating the at least one communication subsystem is responsive to determining that the one or more of the problem scenarios have occurred.

14. The method of claim 13, further comprising coordinating operation of the at least one communication subsystem according to the operating policy.

15. The method according to claim 13, further comprising: filtering inbound coexistence messages from the communication chip for forwarding to be stored in a memory associated with the at least one communication subsystem; as well as The stored inbound coexistence message is sent to the at least one communication subsystem.

16. The method of claim 12, wherein the first coexistence message or the second coexistence message comprises an interrupt.

17. The method of claim 12, further comprising communicating with at least one sensor device via another multi-drop bus, wherein determining whether the one or more of the problem scenarios has occurred is performed by further processing sensor messages received from the at least one sensor device.

18. The method of claim 12, wherein after sending the operating policy to the coexistence hub device, the central processor switches from a first power mode to a second power mode that consumes less power than the first power mode.

19. The method of claim 12, further comprising buffering signals on the multi-drop bus between the communication chips.

20. An electronic device, comprising: CPU; Multiple communication chips; a multi-drop bus connected to the plurality of communication chips; and A coexistence hub device, the coexistence hub device comprising: a first interface circuit configured to communicate via the multi-drop bus; a second interface circuit configured to communicate with the central processor via a point-to-point connection; and A processor circuit, the processor circuit being configured to: receiving an operation strategy from the central processor via the point-to-point connection, the operation strategy representing a problem scenario of an operation combination in the plurality of communication chips and a rule for solving the problem scenario, deploy the received operational policy, receiving a first coexistence message from at least one communication chip via the first interface circuit and the multi-point bus, determining whether one or more of the problem scenarios has occurred by processing at least the received first coexistence message, and In response to determining that the one or more of the problem scenarios have occurred, a second coexistence message is generated representing a command to update the operation of at least one of the plurality of communication chips by applying the operation policy.

21. An integrated circuit IC chip in an electronic device, comprising: a first interface circuit configured to communicate via a multi-drop bus; a communication subsystem configured to implement a communication protocol with other electronic devices; as well as A processor circuit, the processor circuit being configured to: receiving an operation strategy via the multi-drop bus, the operation strategy representing a problem scenario for an operation combination in the IC chip and one or more other IC chips and rules for solving the problem scenario, deploying the received operation strategy in the communication chip, detecting the occurrence of one or more of the problem scenarios, and The operation of the communication subsystem is modified by applying the deployed operational policy to address the one or more of the problem scenarios.

22. The IC chip of claim 21, wherein the operating policy is received from a coexistence hub device that coordinates operations between the IC chip and the one or more other IC chips via at least the multi-drop bus.

23. The IC chip of claim 22, wherein the operating policy received from the coexistence hub device is a subset of other operating policies received by the coexistence hub device from an application processor.

24. The IC chip of claim 21, wherein the first interface circuit is configured to receive a coexistence message from a coexistence hub device, and Wherein the processor circuit is further configured to filter the received coexistence messages for relevant filtered coexistence messages and forward the relevant filtered coexistence messages to the communication subsystem.

25. The IC chip of claim 21, further comprising a second interface circuit configured to communicate with other IC chips through a point-to-point connection.

26. The IC chip of claim 25, wherein the other IC chip is an application processor.

27. The IC chip of claim 21, wherein the processor circuit is further configured to: receiving, via said first interface circuit, a message comprising an interrupt, extract the interrupt from the message, and The interrupt is sent to the communication subsystem.

28. The IC chip of claim 27, wherein the interrupt causes a component in the IC chip to be turned on or off.

29. The IC chip of claim 21, further comprising a point-to-point connection coupled to a coexistence hub device, the coexistence hub device coordinating operations between IC chips including the IC chip.

30. A method for operating an integrated circuit IC chip in an electronic device, comprising: Use communication protocols to implement communications with other electronic devices; receiving an operation strategy via a multi-drop bus, the operation strategy representing a problem scenario for an operation combination in the IC chip and one or more other IC chips and rules for solving the problem scenario, deploying the received operating strategy in the IC chip; detecting the occurrence of one or more of the problem scenarios, and The operation of the communication subsystem is modified by applying the deployed operational policy to address the one or more of the problem scenarios.

31. The method of claim 30, wherein the operating policy is received from a coexistence hub device that coordinates operations between the IC chip and the one or more other IC chips via at least the multi-drop bus.

32. The method of claim 31, wherein the operating policy received from the coexistence hub device is a subset of other operating policies received by the coexistence hub device from an application processor.

33. The method of claim 30, further comprising: receiving a coexistence message from a coexistence hub device; filtering the received coexistence messages for correlating filtered coexistence messages; as well as The relevant filtered coexistence messages are forwarded to the communication subsystem.

34. The method of claim 30, further comprising communicating with other IC chips via a point-to-point connection.

35. The method of claim 34, wherein the other IC chip is an application processor.

36. The method of claim 30, further comprising: receiving via the multi-drop bus a message comprising an interrupt, extract the interrupt from the message, and The interrupt is sent to the communication subsystem.

37. The method of claim 36, wherein the interrupt causes a component in the IC chip to be turned on or off.

38. The method of claim 30, further comprising communicating via a point-to-point connection with a coexistence hub device that coordinates operations between IC chips including the IC chip.

39. An electronic device comprising: CPU; Multi-point bus; A plurality of integrated circuit chips, i.e., a plurality of IC chips, wherein at least one IC chip of the plurality of IC chips comprises: a first interface circuit configured to communicate via the multi-drop bus; a communication subsystem configured to implement a communication protocol with other electronic devices; and A processor circuit, the processor circuit being configured to: receiving an operation strategy via the multi-drop bus, the operation strategy representing a problem scenario of an operation combination in the at least one IC chip and one or more other IC chips and rules for solving the problem scenario, deploying the received operation strategy in the communication chip, detecting the occurrence of one or more of the problem scenarios, and modifying the operation of the communication subsystem to address the one or more of the problem scenarios by applying the deployed operational policies; and A coexistence hub device is coupled to the plurality of IC chips to coordinate operations of the plurality of IC chips.

40. The electronic device of claim 39, wherein the coexistence hub device is configured to transmit the operating policy to the at least one IC chip of the plurality of IC chips via the multi-drop bus.

Images