Coordinating operation of multiple communication chips via a local hub device

Abstract

To provide techniques for coordinating the operation of multiple integrated circuit (IC) chips in an electronic device.SOLUTION: Embodiments relate to coordinating operation of subsystems in a communication system of electronic devices in which a coexistence hub device monitors state information sent as coexistence messages over one or more multi-drop buses, processes the monitored coexistence messages, and sends control messages as coexistence messages to other system-on-chips (SOCs). The coexistence hub device may also update the operation of the communication system. The coexistence hub device may receive the operation policy from the central processor and may execute the operation policy without further coordination of the central processor. The coexistence hub device broadcasts the control message as a coexistence message according to the executed operation policy.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to coordinating the operation of multiple integrated circuit (IC) chips within an electronic device. [Background technology]

[0002] An electronic device may contain multiple SOCs (systems-on-chip) for communicating with other devices using various communication protocols. As the size of communication systems within electronic devices decreases while the functionality of the communication systems increases, more SOCs are incorporated into the electronic device, or more subsystems are added to each SOC. These SOCs can communicate and transmit data with a host (e.g., a central processor or application processor) via a dedicated communication path (e.g., Peripheral Component Interconnect express (PCIe)).

[0003] The integration of multiple communication systems and other subsystems within an electronic device can result in a variety of challenges or complications. These challenges or complications include, among others, resource usage conflicts, interference in shared or overlapping communication bands, conflicting operating modes, and isolation between antennas. In conventional electronic devices, such challenges or complications are generally resolved by coordinating the operations of multiple SOCs, with a central processor coordinating the operations among the SOCs to resolve the problematic situation. 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 the other SOCs. The communication hub device receives, stores, and executes an operational policy without further intervention from a central processor or with limited intervention by a central processor. The communication hub device or the other SOCs broadcasts coexistence messages over the multi-drop bus that are received and processed by the communication hub device and the other SOCs to coordinate their operation according to the operational policy. [Brief explanation of the drawings]

[0005] [Figure 1] 1 is a schematic diagram of an electronic device according to one embodiment. [Figure 2] FIG. 2 is a block diagram illustrating components of an electronic device communicating over a multi-drop bus, according to one embodiment. [Figure 3] FIG. 1 is a block diagram illustrating a coexistence hub device according to one embodiment. [Figure 4] FIG. 4 is a block diagram illustrating components of a dispatcher in the coexistence hub device of FIG. 3 according to one embodiment. [Figure 5] FIG. 1 is a block diagram of a SOC according to one embodiment. [Figure 6] FIG. 1 is an interaction diagram illustrating the operation and interaction of components within an electronic device, according to one embodiment. [Figure 7] 10 is a flowchart illustrating a process for applying an operational policy to a detected coexistence event, according to one embodiment. [Figure 8] 1 is a table illustrating requests in a coexistence message and corresponding possible responses made by a coexistence hub device according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0006] For purposes of illustration only, various non-limiting embodiments are shown in the drawings and described in the detailed description.

[0007] Reference will now be made in detail to the embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the various embodiments being described. However, the described embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0008] Embodiments relate to coordinating the operation of subsystems within a communication system of an electronic device, in which a coexistence hub device monitors status information transmitted as coexistence messages over one or more multidrop buses, processes the monitored coexistence messages, and transmits control messages as coexistence messages to other SOCs within the electronic device as well as to 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 operational policies from a central processor (e.g., an application processor) and execute the operational policies without further coordination of the central processor or with reduced central processor operation. The coexistence hub device broadcasts control messages as coexistence messages according to the executed operational policies. The other SOCs receive and filter the control messages associated with their operations and adjust their operations accordingly. The central processor may advantageously remain in a low-power mode or even be turned off while the coexistence hub device executes the operational policies, thereby reducing the power consumption of the electronic device. Furthermore, eliminating the need for central processor intervention allows for faster execution of cooperative operations.

[0009] Coexistence messages, as described herein, refer to messages exchanged between components within an electronic device based on which components' operations are coordinated. Coexistence messages can be status messages indicating the status of the system or control messages for controlling the operation of the system or components within the system. Systems associated with coexistence messages can include, but are not limited to, communication systems and sensor systems. Coexistence messages indicate, for example, the airtime radio status or importance of radio link traffic of a communication subsystem at a particular time, which can be used to coordinate duty cycles between two or more communication subsystems.

[0010] A coexistence hub device, as described herein, refers to a device that can autonomously coordinate the operation of coexisting components within a communication device without further intervention by a central processor or with reduced intervention by a central processor. A coexistence hub device may include its own subsystem that performs communication operations. A coexistence hub device may be embodied as a separate chip or as part of a larger circuit.

[0011] (Exemplary Electronic Devices) Embodiments of electronic devices, user interfaces for such devices, and associated processes for using such devices are described. In some embodiments, the device is a portable communication device, such as a mobile phone, that also includes other functions, such as personal digital assistant (PDA) and / or music player functions. Exemplary embodiments of portable multifunction devices include, but are not limited to, the iPhone®, iPod® Touch®, Apple Watch®, and iPad® devices from Apple Inc. of Cupertino, California. Other portable electronic devices, such as wearable computers, laptop computers, or tablet computers, are optionally used. In some embodiments, the device is not a portable communication device, but is a desktop computer or other computing device not designed for portable use. In some embodiments, electronic devices of the present disclosure can include a touch-sensitive surface (e.g., a touchscreen display and / or a touchpad). An exemplary electronic device (e.g., device 100) described below in connection with FIG. 1 can include a touch-sensitive surface for receiving user input. The electronic device can also include one or more other physical user interface devices, such as a physical keyboard, a mouse, and / or a joystick.

[0012] FIG. 1 is a schematic diagram of an electronic device 100 according to one embodiment. Device 100 may include one or more physical buttons, such as a "home" or menu button 104. Menu button 104 is used, for example, to navigate to any application within a set of applications running on device 100. In some embodiments, menu button 104 includes a fingerprint sensor that identifies a fingerprint on menu button 104. The fingerprint sensor can be used to determine whether a finger on menu button 104 has a fingerprint that matches a stored fingerprint to unlock device 100. Alternatively, in some embodiments, menu button 104 is implemented as a soft key within a graphical user interface (GUI) displayed on a touchscreen.

[0013] In some embodiments, device 100 includes a touchscreen 150, a menu button 104, a pushbutton 106 for turning power to the device on and off and locking the device, a volume control button 108, a Subscriber Identity Module (SIM) card slot 110, a headset jack 112, and an external docking / charging port 124. Pushbutton 106 can be used to turn power on and off on the device by pressing and holding the button down for a predetermined time interval, lock the device by pressing the button and releasing it before the predetermined time interval has elapsed, and / or unlock the device or initiate an unlocking process. In an alternative embodiment, device 100 also accepts verbal input via microphone 113 to activate or deactivate certain functions. Device 100 includes various components, including, but not limited to, memory (which may include one or more computer-readable storage media), a memory controller, one or more central processing units (CPUs), peripheral interfaces, RF circuitry, audio circuitry, 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 two or more types of image sensors 164. Each type may include two or more image sensors 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 may 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 components not shown in FIG. 1, such as an ambient light sensor, a dot projector, and a flood illuminator.

[0014] Device 100 is merely one example of an electronic device, and device 100 may have more or fewer components than those listed above, some of which may be combined into a single component or may have a different configuration or arrangement. The various components of device 100 listed above may be embodied in hardware, software, firmware, or a combination thereof, including one or more signal processing circuits and / or application specific integrated circuits (ASICs). While the components in FIG. 1 are generally shown as being located on the same side as touchscreen 150, one or more components may 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 for the device's front camera. The back side of device 100 may also include an additional image sensor 164 for the device's rear camera.

[0015] (Exemplary Communication System in an Electronic Device) FIG. 2 is a block diagram illustrating components of electronic device 100 communicating via multi-drop buses 220, 224, according to one embodiment. Electronic device 100 may include, among other components, application processor 208 (also referred to herein as a “central processor”), coexistence hub device 212 (also referred to herein as a “coexistence hub device”), SOCs 234A through 234N (collectively referred to herein as “SOCs 234”), sensor devices 216A and 216B (collectively referred to herein as “sensor devices 216”), multi-drop buses 220, 224, and fabrics 222A-222N. The components shown in FIG. 2 may be part of a communication subsystem within electronic device 100. Electronic device 100 may include additional components (e.g., a user interface) not shown in FIG. 2.

[0016] The application processor 208 is a processing circuit within the electronic device 100 for performing various operations. The application processor 208 may include one or more processing cores for executing various software programs, as well as dedicated hardware circuits for performing specific functions, such as image processing, performing security operations, performing machine learning operations, and processing audio signals. The application processor 208 may also perform operations to coordinate the operation of other components within the electronic device 100, including the coexistence hub device 212, the SOC 234, and the sensor device 216. The application processor 208 may operate in multiple power modes, including a low-power mode in which the application processor 208 turns off most of its components to conserve power, 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 be embodied as a separate SOC. In one or more embodiments, the application processor 208 relays data between components connected via the multidrop buses 220, 224 in the 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 coexisting hub device 212) via the multi-drop buses 220, 224, (ii) modify or copy the received signals according to predetermined rules, and (iii) transmit the modified signals via the multi-drop buses 220, 224 to another device (e.g., the SOC 234, the sensor device 216, and the coexisting hub device 212), enabling the SoC 234 to communicate effectively.

[0017] The coexistence hub device 212 is hardware, software firmware, or a combination thereof that coordinates the operation of the communication system (e.g., including the coexistence hub device 212 and the SOC 234) and associated components (e.g., the sensor device 216) in the electronic device 100. To this end, the coexistence hub device 212 stores and executes operational policies for defining and / or coordinating the operation of the communication system and associated components. The coexistence hub device 212 may operate based on the operational policies without further intervention or with reduced intervention by the application processor 208. The operational policies may determine the real-time behavior of components in the communication system (e.g., 234) based on factors such as, for example, the operating conditions of a particular communication system or the configuration of another communication system in the platform that affects it, the amount of time a communication subsystem remains in a standby 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 operational policy, the coexistence hub device 212 proactively performs operations to configure or prepare the communication subsystem for activation or deactivation (or components of the communication subsystem modify their operational state due to external conditions), so that activation or deactivation of other communication subsystems occurs without error or with reduced degradation. The coexistence hub device 212 may also include one or more communication subsystems that perform communication operations over various physical interfaces. By performing such coexistence operations locally in the communication subsystem, the application processor 208 can remain in a low-power mode for longer periods of time despite activity within the communication subsystem, freeing up the application processor 208's resources during its high-power mode and increasing the agility of response between the communication systems to changing conditions. Because some systems may only present coexistence issues for short intervals of time, a multi-drop bus with the coexistence hub device 212 is well-suited for situations where some short-term operations, such as reducing transmit power or changing the state of some externally coupled components, are required to accommodate other communication subsystems during short intervals of coexistence.Details of the coexistence hub device 212 are described in more detail below with reference to Figures 3 and 4. The coexistence hub device 212 may also perform functions other than coordinating operations performed by the application processor 208.

[0018] Each of the SOCs 234 is circuitry that, alone or in conjunction with software or firmware, performs operations to communicate with one or more external networks or devices using communication or security protocols. Each of the SOCs 234 and the coexistence hub device 212 may support different communication protocols and / or be associated with different wireless bands. For example, the SOC 234A may handle long-range communications (e.g., cellular communications), while the SOC 234B or the coexistence hub device 212 supports short-range communications (e.g., Bluetooth communications). The operation of the SOC 234 is controlled at least in part by the coexistence hub device 212. An example of the SOC 234B is described in more detail below with reference to FIG. 5.

[0019] The sensor devices 216 are hardware components that sense various characteristics, either alone or in conjunction with firmware software. These sensor devices 216 generate sensor signals representing the sensed characteristics that can be transmitted to other components (e.g., the SOC 234, the coexistence hub device 212, and the application processor 208) for further processing. Sensor 216A may be, for example, a compass that transmits a sensor signal representing the orientation of the electronic device 100, while sensor 216B may be a Global Positioning System (also referred to as a Global Navigation Subsystem (GNSS)) module to enhance reception of cellular radio or WiFi signals at the SOC 234A. Some of the sensor devices 216 may be simple standalone devices that interact with one or more of the SOCs 234 but nevertheless have coexistence issues with other components of the electronic device 100. Other sensor devices 216 may be complex sensors with embedded processors and memory that transmit or receive a wide range of messages with one or more of the SOCs 234.

[0020] The fabrics 222 are communication channels that allow components within the communication system to communicate with the application processor 208. One or more of the fabrics 222 may be embodied as point-to-point connections, such as Peripheral Component Interconnect Express (PCIe), I2C, or Serial Peripheral Interface (SPI). As shown in FIG. 2, the SOC 234A, the coexisting hub device 212, and the SOCs 234B-234N communicate with the application processor 208 through corresponding fabrics 222A-222N. One or more of the fabrics 222 may have high bandwidth and low latency compared to the multi-drop buses 224, 220. The fabrics 222 are shown in FIG. 2 and may be physically separate communication channels or may be one or more shared physical channels with multiple logical subchannels.

[0021] Each of the multi-drop buses 220, 224 is a communication channel that allows multiple components to communicate over a shared connection. The multi-drop bus 220 may be used primarily to transmit coexistence messages between components in a communication system, while the multi-drop bus 224 may be used primarily to transmit sensor signals from the sensor devices 216A, 216B to other components of the electronic device 100. However, the multi-drop buses 220, 224 may also transmit other types of signals. Furthermore, the multi-drop buses 220, 224 may 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 implement the multi-drop buses 220, 224. Other serial bus interfaces, such as I2C, may be used to implement the multi-drop buses 220, 224 instead of SPMI.

[0022] In addition to or instead of the multi-drop buses 224, 220, general-purpose input / output (GPIO) communications can 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) 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 communication with devices that may experience communication issues over the multi-drop bus due to, for example, exposure to interference, and (v) enabling dual support for GPIO communications as well as communications over the multi-drop bus. These GPIOs may also be coupled together to enforce low-level coexistence policies between two components. As shown in FIG. 2, the sensor device 216B can communicate directly with the SOC 234A via the GPIO 228A, and the coexistence hub device 212 can communicate directly with the SOC 234B via the GPIO 228B. As 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. Although not shown in FIG. 2 , SPI, PCIe, or both SPI and PCIe could also be used to provide alternative or additional communication mechanisms. While FIG. 2 depicts GPIO 228A as interfacing sensor device 216B with SOC 234A, other physical interfaces, such as a serial peripheral interface (SPI), M-PHY, or radio frequency front-end (RFFE) interface, may also be used. In one or more embodiments, sensor device 216B may not have direct access to multi-drop bus 220 and instead rely on SOC 234A to communicate over the multi-drop bus via GPIO 228A.In such an embodiment, the coexistence hub device 212 can control the sensor device 216B via the SOC 234A to address any coexistence issues.

[0023] Although not shown in FIG. 2, the coexistence hub device 212 may also control operation or access to one or more antennas (not shown) associated with the communication system.

[0024] (Example Architecture of a Co-Existing Hub Device) 3 is a block diagram illustrating a coexistence hub device 212, according to one embodiment. The coexistence hub device 212 is part of a communication system that coordinates the operation of components within the communication system. The coexistence hub device 212 may also handle communications over a protocol that is different from or overlaps with the communications performed by the SOC 234.

[0025] To this end, coexistence hub device 212 may include, among other components, processor 304, coexistence control circuitry 314, fabric interface 310, multidrop interfaces 340A, 340B (collectively referred to as "multidrop interfaces 340"), communication subsystems 336A through 336Z (collectively referred to as "communication subsystems 336"), and internal fabric 352. Coexistence hub device 212 may include additional components not shown in Figure 3 or may omit components shown in Figure 3 (e.g., one or more of communication subsystems 336).

[0026] The processor 304, alone or in conjunction with software or firmware, is a circuit that controls the overall operation of the coexistence hub device 212 and the coordination of the operation of other SOCs 234 using coexistence messages. The processor 304 may include memory for storing operational policies 352 for controlling operation. The operational policies 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 operational policies 352, the processor 304 may decode the operational policies 352 and program other components within the coexistence hub device 212 (e.g., the coexistence control circuitry 314) to enforce the operational policies 352, if applicable. Additional information related to the operational policies 352 may also be received from the application processor 208. Such additional information may be stored or processed in the processor 304 to affect how the operational policies 352 are implemented. Additionally, the processor 304 can transmit portions of an operational policy 352 associated with the other SOCs 234 via the multidrop bus 220 to program the SOCs 234 to operate in accordance with the operational policy 352. The processor 304 can make coexistence decisions in accordance with the operational policy 352 by analyzing coexistence messages (e.g., status information or requests) received from the SOCs 234 and the communication subsystem 336 via interface 340A and other messages (e.g., sensor signals) received via interface 340B. The processor 304 can store a current state 354 of the communication subsystem 336 in the coexistence hub device 212 and the other SOCs 234. The current state 354 can include, for example, the radio frequency (RF) bands / channels used by the SOCs 234 and the coexistence hub device 212, the transmit power of the radio signals, and so on. Such information can also be transmitted to the application processor 208 or the other SOCs 234 to enable real-time adjustment of operations in the other SOCs 234. The processor 304 may delegate some coordination operations (eg, coordination for the communication subsystem 336) to an arbiter 322.

[0027] As described herein, an operational policy refers to a scenario that operates a combination of components that have a potentially problematic combination or interworking challenge in a communication system, as well as a set of rules that define the actions taken by the SOC 234 and the coexistence hub device 212 to resolve or address such problematic scenarios. Such rules may be designed to take into account various considerations, including, but not limited to, resource usage, interference in shared or overlapping communication bands, and power usage. In one or more embodiments, the rules may be stored in the form of lookup tables. These lookup tables may be accessed by hardware, software, firmware, or a combination thereof within the processor 304 to implement the operational policy. In other embodiments, the operational policy may include firmware code, allowing for dynamic responses and maintaining balanced operation among multiple communication subsystems. Interference rules or conditions may apply, in some cases, only for a limited time, such that the hub will dynamically activate / deactivate mitigation in response to patterns of behavior that may be transmitted in advance or in response to dynamically received messages from external systems.

[0028] The processor 304 may also communicate with the SOC 234 or other components within the electronic device 100 via GPIOs. While Figures 2 and 3 show the coexistence hub device 212 in communication with the SOC 234B, the GPIOs may be omitted or other additional GPIOs may be provided for communication with other components within the electronic device 100.

[0029] In one embodiment, the processor 304 receives the entire operational policy from the application processor 208 when the coexistence hub device 212 is first initialized. In other embodiments, the processor 304 receives the relevant portions of the operational policy from the application processor 208 when 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, the SoC 234. In this embodiment, the turning on of the communication subsystem 336 and / or the SOC 234 may be communicated to the application processor 208, which causes the application processor 208 to send the relevant portions of the operational policy to the processor 304.

[0030] In another embodiment, the processor 304 is pre-installed with a default operating policy 352. In this embodiment, the processor 304 does not receive an operating policy from the application processor 208. In such a 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 as to satisfy regulatory restrictions within the geographic region.

[0031] Each of the communication subsystems 336 includes circuitry for processing signals received from or to be transmitted to a corresponding physical layer interface 308A-308Z (collectively referred to as the “physical layer interface 308”) external to the coexistence hub device 212. Such circuitry may include local processors 378A-378Z (collectively referred to as the “local processors 378”) that perform one or more of the following operations: (i) execute commands associated with a particular communication protocol; (ii) process incoming communication signals received according to the corresponding protocol, decode the incoming wireless signal, and respond by encoding a specific response within a required time budget on the RF link; (iii) control an associated radio frequency (RF) path, adjusting transmit power or receive gain control; and (iv) configure, disable, or enable components within the communication subsystem 336 based on an operating policy. 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) when the coexistence hub device 212 is turned on. Among other things, the local processors 378 are programmed with portions of operational policies related to the operation of their communications subsystems 336. The operational policies downloaded to the local processors 378 of the communications subsystems 336 may define how the communications subsystems 336 should operate (e.g., the data rate of the communications subsystem, whether components within the communications subsystem 336 should be turned on or off, and changing the number of active transmitters or how those transmitters are configured to reduce interference, such as applying blanking or power backoff for specific periods of time). Policies may be active only for a limited duration that repeats, allowing the communications subsystems 336 to dynamically engage or disengage mitigations in response to messages from external systems to notify them of triggering events.Alternatively, the relevant portions of the operating policy may be downloaded and programmed by the application processor 208 directly via fabric 222B or serially by the processor 304 when each of the communication subsystems 336 is turned on. One or more of the communication subsystems 336 may communicate with a physical layer interface (e.g., an RF device) via, for example, a Radio Frequency Front-End Control Interface (RFFE).

[0032] In some embodiments, the physical layer interface 308 may be merged into a reduced set where the local processor 378 supports two or more communication protocols, or may switch between different communication protocols over time. The local processor 387 may control a fixed set of radio paths, or may control only the front-end switch, or the LNA or PA may be controlled by the physical layer interface 308.

[0033] Interfaces 340A, 340B are hardware circuits or a combination of hardware circuits, software, and firmware for communicating with multidrop buses 220, 224. In one or more embodiments, interfaces 340A, 340B include circuitry for processing data into outgoing datagrams and unpacking incoming datagrams into data for transmission over SPMI. Interfaces 340A, 340B are connected to processor 304 and coexistence control circuit 314 via connections 328, 326, respectively.

[0034] The fabric interface 310 is a hardware circuit or a combination of hardware circuitry, software, and firmware that enables the coexistence hub device 212 to communicate with the application processor 208 over the fabric 222B. In one or more embodiments, the fabric interface 310 performs operations such as buffering, segmenting / combining data, serializing / deserializing, and packaging / unpacking data for communication over a point-to-point communication channel (e.g., PCIe). As shown in FIG. 3, the fabric interface 310 connects to the internal fabric 342 to enable components within the coexistence hub device 212 to communicate with the application processor 208.

[0035] Coexistence control circuitry 314, alone or in conjunction with firmware or hardware, is circuitry that processes coexistence messages transmitted over multi-drop bus 220. Coexistence control circuitry 314 is programmed by processor 304 to enforce operational policy 352 by making real-time decisions on coexistence events, distribute incoming coexistence messages to associated communication subsystems 336, share coexistence messages among communication subsystems 336 in real-time, and send outgoing coexistence messages to other SOCs 234. A coexistence event, as described herein, refers to a state or occurrence defined by an operational policy that promotes coordination of operations among components of electronic device 100.

[0036] Specifically, coexistence control circuitry 314 may include, among other components, a dispatcher 312, a memory 316, an arbiter 322, and a billboard 326. Dispatcher 312 is a programmable circuit or a circuit in combination with software or firmware for filtering and sending messages for each communication subsystem 336 to memory 316. In a multithreaded system, there may be multiple such memories 318A-318Z to allow multiple systems to send or receive coexistence messages in parallel. Details of dispatcher 312 and its functionality are described in more detail below with reference to FIG. 3.

[0037] The memory 316 has multiple buffers 318A-318Z (collectively referred to as "buffers 318"), with each buffer corresponding to one of the communication subsystems 336. Each of the buffers 318 receives and stores incoming coexistence messages (received from components external to the coexistence hub device 212 via the multidrop bus 220) associated with the corresponding communication subsystem 336. The incoming coexistence messages stored in the buffers 318 may be transmitted (as indicated by arrow 372) to the corresponding communication subsystem 336 based on priority (e.g., time-sensitive data has higher priority than time-nonsensitive data) via the internal fabric 342. If one or more communication subsystems 336 are inactive, the buffers 318 store messages until the communication subsystems 336 are turned on and available to receive messages. In one or more embodiments, different buffers 318 may be associated with different priorities. When a buffer assigned a higher priority fills with messages, the communication system 336 may wake up to service to ensure that messages are processed in a timely manner. Each of the buffers 318 also stores outgoing coexistence messages 348 (received from the corresponding communication subsystem 336 via the internal fabric 342). The outgoing coexistence messages are retrieved by the dispatcher 312 and transmitted via the multi-drop bus 220 to components external to the coexistence hub device 212 based in part on priority (e.g., time-sensitive data has higher priority than time-non-sensitive data).

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

[0039] 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 sort activities that use radio resources in advance. By planning a timeline in advance, enhanced coexistence operations can be performed. Planning can also sort activities to provide better immunity to jammers and blockers at the expense of in-band SNR.

[0040] The billboard 326, alone or in conjunction with software or firmware, is a circuit that stores status information for the communications subsystem 336. Status information 346 is received from the communications subsystem 336 and stored for access. The billboard 326 allows communications subsystems within the coexistence hub device 212 or external components to accurately determine the operating context of another system by accessing the status information in the billboard 326. In one or more embodiments, other SoCs 234 may also include billboards that allow the SOCs 234 to simultaneously advertise their contexts. The billboard may include a memory area. An incoming message to the billboard's memory area can trigger the communications subsystem to respond within a predetermined time. In one or more embodiments, the billboard 326 is also used as a ping-pong buffer to exchange signals or data between SOCs 234 over the multidrop buses 220, 224 when the SOCs 234 are unable to perform direct messaging between the SOCs for some reason.

[0041] The arbiter 322 is a circuit that, alone or in conjunction with software or firmware, makes decisions regarding real-time coordination of the operations of the communication subsystems 336 and transmits those decisions to the communication subsystems 336 and memory 316 via the internal fabric 342. Such decisions may include resolving competing needs for a common resource by multiple communication subsystems 336 or conflicting resource requests by different communication subsystems 336. Because the arbiter 322 makes its decisions in real time, they can remain valid for a shorter period of time compared to decisions made by the processor 304 to implement operational policies 352. Additionally, the arbiter 322 can resolve resource requests by external communication subsystems that conflict with local communication subsystems 336 using the same resource. To this end, the arbiter 322 can access utilization information stored in the processor 304 regarding the current state 354 of the communication subsystems 336 and other SOCs 234, as well as the priorities of different competing operations. The algorithms for resolving resource conflicts in the arbiter 322 can be adjusted based on the operational policies 352 executed by the processor 304. The arbiter 322 may be programmed by the processor 304 or the application processor 208. Decisions made by the arbiter 322 may include controlling RFFE transactions associated with the communications subsystems 336, for example, to change the settings of an external RF device. Such actions may include blanking the power amplifier transmission of the corresponding communications subsystem 336. Real-time decisions are transmitted over the shared internal fabric 342 so that a communications subsystem (e.g., communications subsystem 336A) can receive decisions intended for another communications subsystem (e.g., communications subsystem 336B) and adjust its operation accordingly. The arbiter 322 may include a processor 323 that controls the overall operation of the arbiter 322.

[0042] In one or more embodiments, the arbiter 322 can communicate with components external to the coexistence hub device 212 via the GPIO 228B for low-latency data. For example, the arbiter 322 can receive sensor data from one or more of the sensors 216 and make real-time decisions. Alternatively, the arbiter 322 can control communication subsystems and disable other communication subsystems via the GPIO. In another embodiment, the arbiter 322 assists the communication system in managing the response to an asynchronous, unexpected external interrupter and manages the radio response to avoid performance impairments due to the sudden appearance of an external jammer or interrupter by disabling the affected radio path and triggering associated firmware / software to enable a radio path with higher linearity to maintain the link despite the jammer even if it degrades in-band SNR or EVM (Error Vector Magnitude) performance.

[0043] In one or more embodiments, processor 304 determines larger-scale cooperative behavior based on its operational policy 352 and configures coexistence control circuitry 314, communication subsystem 336, and possibly components of SOC 234 to enforce operational policy 352. Meanwhile, arbiter 322 coordinates smaller-scale, real-time coexistence behavior consistent with the larger-scale cooperative behavior defined by operational policy 352.

[0044] (Example architecture of a dispatcher) FIG. 4 is a block diagram of a dispatcher 312 in the coexistence hub device of FIG. 3 , according to one embodiment. The dispatcher 312 is a circuit or combination of circuitry, software, and / or firmware for processing coexistence messages. The dispatcher 312 determines in what order / priority request or coexistence messages from the communication subsystems 336 should be sent to the SOCs 234 and, if so, forwards the request or coexistence messages over the multidrop bus 220. The dispatcher 312 also receives coexistence messages from the SOCs 234 and forwards relevant subsets of all these messages to the communication subsystems 336 so that each of these subsystems 336 receives only the relevant messages. The dispatcher 312 may include, among other components, a processor 436, an interrupt manager 428, a time stamper 440, and a message filter 432. One or more of the interrupt manager 428, the time stamper 440, and the message filter 432 may be embodied as software firmware executed by the processor 436. Additionally, additional components can be added to the dispatcher 312 .

[0045] The processor 436 is circuitry that can perform various operations within the dispatcher 312, such as (i) managing the relative resources within each communication subsystem 336, (ii) controlling external RF control blocks outside the coexistence hub device 212, (iii) supporting the functionality and operation of the arbiter 322, and (iv) coordinating the reporting of results from the arbiter 322 to components on the multi-drop bus 220. The processor 436 may be part of the processor 304 or may be a stand-alone processor. The processor 436 can also update the operation of other components within the dispatcher 312 over time or in response to activity within the electronic device 110.

[0046] Message filter 432 is hardware, software, firmware, or a combination thereof that receives incoming coexistence messages 422 from multidrop bus 220 via interface 340A, filters incoming coexistence messages 422 associated with a communication subsystem 336, and sends filtered incoming coexistence messages 454 to the appropriate buffer 318 and / or shared section 320 of memory 316. Message filter 432 may also redirect incoming 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 incoming coexistence messages. By configuring message filter 432, a communication system (e.g., 336A) may also receive incoming coexistence messages intended for another communication system (e.g., 336B) and take such incoming coexistence messages into account for its operation. The message filter 432 can also operate when the communications subsystem 336 is in radio sleep to receive a limited set of messages from the external SoC to record any significant changes in the state of the external system that may affect the communications subsystem 336 in radio sleep, or to request that a limited set of functions of the communications subsystem 336 be briefly woken up to allow sharing of an external sharing device. The message filter 432 can also perform the same operation on incoming sensor messages received from interface 340B. If the incoming coexistence message contains an interrupt, the message filter 432 sends a corresponding coexistence message 442 to the interrupt manager 428.

[0047] Interrupt manager 428 is hardware, software, firmware, or a combination thereof that manages interrupts. When interrupt manager 428 receives a coexistence message 442 that includes an interrupt, interrupt manager 428 extracts the interrupt and sends an interrupt signal 414 to the corresponding communication subsystem 336. The interrupt signal 414 can cause the corresponding communication subsystem 336 to shut down, power down a subset of its components, wake up from power down, or indicate the real-time status of a component (e.g., SOC 234) on multidrop bus 220. These interrupt signals may include only a simple decoder and no microprocessor, allowing low-cost components to send interrupt signals to communicate simple coexistence messages over multidrop bus 220. One of the characteristics of interrupt signals is that they are sticky, meaning that even if a SOC (e.g., SOC 234B) is asleep when the coexistence hub device 212 sends an 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 other components (e.g., SOC 234A) do not need to stay awake long enough to complete a handshake operation with the external SOC (e.g., SOC 234B), and that the external SOC (e.g., SOC 234B) may unexpectedly enter an inactive / sleep state. Always using interrupt signals can reduce the burden on the outgoing message source.

[0048] Message filter 432 may also receive an interrupt signal 450 from communication subsystem 336. If interrupt signal 450 is intended for SOC 234, message filter 432 sends interrupt 450 to interface 340A as a transmit coexistence message 418 for transmission over multidrop bus 220. Interrupt signals between communication subsystems 336 are transmitted through internal fabric 342 without intervening coexistence control circuit 314.

[0049] The time stamper 440 is a circuit that tracks the time of incoming and outgoing messages on the multidrop bus 220. In some embodiments, two or more SoCs operate from the same reference time. Stamping incoming messages with an internal reference time allows for tighter coordination between SOCs. The arrival time can also be used to determine the approximate time when radio resources will be released (e.g., if an invalidation delay is included in the incoming message). The time stamper 440 tracks the actual time a message is sent or received to account for arbitration delays. The time stamper 440 may also be used to monitor actual link failures by external systems, allowing the local system to modify patterns of behavior previously transmitted to the victim system when anticipating a failure. In systems where coexistence problems are short in duration, it is advantageous for the radio to track the interval of the upcoming failure to avoid scheduling some activity during such times, or to take some mitigating measures, such as repeating transmission packets during this interval, to aid the reliability of the wireless network communicating with the device 100 in managing reduced performance.

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

[0051] SOC 234B is part of a communication system within electronic device 100 and can implement one or more communication protocols using its communication subsystems 536A, 536B (collectively referred to as "communication subsystems 536"). While only two communication subsystems 536A, 536B are shown in FIG. 5, more than two communication subsystems or only a single communication subsystem may be included in SOC 234B. While two communication subsystems 536A and 536B are shown in FIG. 5, there may be a common radio that time-shares and supports both communication subsystems 536A, 536B, or there may be a radio that is reconfigured between different modes to support both communication subsystems 536A and 536B. Communication subsystems 536A, 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 identical to communication subsystem 336, except that coexistence messages associated with communication subsystem 536 are processed by processor 512 instead of coexistence control circuit 314. The communications subsystem 536 can send coexistence messages to the coexistence hub device 212 over the multi-drop bus 220 to coexist with the coexistence hub device and / or communications subsystems in other SOCs. Incoming coexistence messages to SOC 234B are processed locally by the processor 512 and sent to the corresponding communications subsystem 536. Other details regarding the communications subsystems 536 are omitted herein for the sake of brevity.

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

[0053] Bus interface 504 is circuitry that, alone or in conjunction with software or hardware, allows components of SOC 234B to communicate with coexisting hub device 212 and other SOCs over multidrop bus 220.

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

[0055] Processor 512 manages the overall operation of SOC 234B and may include, among other things, as software or hardware components, interrupt manager 516 and message filter 518. Because the function and operation of interrupt manager 516 and message filter 518 are substantially the same as the function and operation of interrupt manager 428 and message filter 432, a detailed description of these components is omitted herein for the sake of brevity.

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

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

[0058] (Exemplary Process for Coordinating Coexistence Behavior) 6 is an interaction diagram illustrating the operation and interaction of components within electronic device 100, according to one embodiment. The application processor 208 operates in a first power mode (e.g., a full power mode) (602). During the first power mode, the application processor 208 transmits an operational policy to the coexistence hub device 212 via fabric 212B (606). The application processor 208 may also transmit an initial operational policy associated with the SOC 234 to the SOC 234 via the corresponding fabric 222 (618). After the application processor 208 transmits the operational policy, the application processor 208 may switch to a second power mode (e.g., a reduced power mode or a sleep mode) (610). The application processor 208 may continue to transmit updates to the coexistence hub device 212 and the other SoCs 234s.

[0059] The coexistence hub device 212 then deploys and begins applying 614 the operational policies. The coexistence hub device 212 can also send the associated operational policies to the SOC 234 to initialize or update the rules that operate the SOC 234. For example, the associated operational policies can be sent to the SOC for initialization when the SOC is turned on.

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

[0061] After the SOC 234 receives the relevant operational policies (either from the application processor 208 or the coexistence hub device 212), the SOC 234 can deploy and apply the relevant policies to those operations (626). The SoC 234 can keep the other SoCs and the application processor 208 informed of configuration changes related to coexistence with other SOCs, allowing the SoC 234 to plan appropriate configurations and reduce impacts resulting from the other SOCs.

[0062] When a coexistence event occurs (630) (e.g., a known trigger event, such as the experience of radio signal interference in one of the SOCs or the use of a particular resource that may impact another SoC), the SOC 234 experiencing the event transmits (634) a coexistence message 634 to the coexistence hub device 212 over the multidrop bus 220. Alternatively, the SoC 234 initiating the trigger event can quickly inform the coexistence hub device 212 and the affected SoC(s) of such a change. The SoC 234 may not be able to fully resolve how to respond to an external trigger event on its own. In such cases, the SOC 234 can cooperate via the application processor 208 for additional data, such as control information, or by changing the clock schedule of associated codependent hardware signals, and the coexistence hub device 212 can respond to the received coexistence message by applying (638) operational policies and taking action to address the coexistence event, as described in more detail below with reference to FIG. 7 . The policy may also mean that a particular SoC 234 is restricted from using a particular mode of operation, while another SoC is operating in a state where its performance is significantly affected by a triggering event. In addition to the coexistence hub device 212, other SOCs 234 may also receive coexistence messages over the shared multi-drop bus 220 and adjust their operation accordingly.

[0063] Actions taken by the coexistence hub device 212 may include coordinating the operation of one or more of the communication subsystems 336 and / or generating and sending (642) other coexistence messages 642 containing commands or interrupts to other SOCs 234 to control their operation.

[0064] In response to receiving a coexistence message containing a command or interrupt, the SOCs 234 associated with the coexistence message update their operations according to the command or interrupt in the coexistence message to address the poor radio conditions 646. The SoCs 234 can monitor the impact of the aggressor and report the impact to the coexistence hub device 212 so that the coexistence hub device 212 can take further action against the aggressor to improve the link conditions of the victim.

[0065] In addition to or instead of sending 642 a coexistence message, the coexistence hub device 212 may update the operation of its communication subsystem 336 to handle the coexistence event according to its operation policy 352 .

[0066] 6 illustrates a scenario in which a coexistence event occurs at a SOC 234, a coexistence event may also occur within the coexistence hub device 212. In such an example, the coexistence hub device 212 may address the coexistence event by updating the operation of its components or sending a coexistence message containing a command (642) to the associated SOC 234. A similar set of responses may occur within the coexistence hub device 212 when two communication subsystems are affected as occurs externally between SoCs 234.

[0067] By having the coexistence hub device 212 process coexistence messages and handle coexistence events without requiring 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) in the application processor 208 can be preserved for other operations even when the application processor 208 is in the first power mode. Furthermore, increased autonomy and faster collaboration within the SoC can be achieved.

[0068] The processes and their sequence shown in Figure 6 are merely exemplary. Additional processes may be added, and some processes in Figure 6 may be omitted. For example, the process of transmitting the associated policies 618 from the coexistence hub device 212 to the SOC may be omitted, and instead, the application processor 208 may be relied upon solely to transmit the associated policies to the SOC 234. Also, the application processor 208 may remain in the first power mode after transmitting 606 to the coexistence hub device 212, without switching to the second power mode.

[0069] 6, the application processor 208 can send an updated operational policy for deployment and application after the initial operational policy is deployed in the coexistence hub device 212. The updated operational policy may be determined by the application processor 208 based on the detection of an event or after reading the current state 354 in the coexistence hub device 212.

[0070] 7 is a flowchart illustrating a process for applying 638 an operational policy to a detected coexistence event, according to one embodiment. A request in a coexistence message from a source SOC (e.g., SOC 234A) is extracted 702 by the coexistence hub device 212.

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

[0072] The coexistence hub device 212 then generates a coexistence message containing a command to send to the SOC 234 over the multidrop bus 220. The command instructs the SOC 234 to coordinate its operations.

[0073] If no collision is detected, a coexistence message containing a command to coordinate the operation of the source SOC (eg, SOC 234A) is generated for transmission over multi-drop bus 220 (722).

[0074] The current state 354 of the SOC 234 and communication subsystem 336 in the coexistence hub device 212 is updated (718).

[0075] The processes and their sequence shown in Figure 7 are merely exemplary. Additional processes may be added, and some processes in Figure 7 may be omitted. For example, the process of updating the current state (718) may be performed after determining the allowed adjustments (710).

[0076] FIG. 8 is a table illustrating requests in a coexistence message and corresponding possible responses made by the coexistence hub device 212, according to one embodiment. The first column of the table includes various requests that may be made by the SOC 234 and the communications subsystem 336 in the coexistence hub device 212. The second column of the table indicates corresponding responses or commands that may be included in the coexistence message, depending on the request. "Accept" indicates that the request made by the SOC 234 and communications subsystem 336 is accepted. "Reject" indicates that the request made by the SOC 234 and communications subsystem 336 is rejected, and the source SOC continues to operate in its current operating mode. "Advertise Alternate Frequency Band," "Allow Less Power Increase," "Allow Less Power Decrease," and "Advertise Alternate Antenna" are actions that are neither accept nor reject, but alternative successive actions taken by the SOC 234 or communications subsystem 336.

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

Claims

1. A coexistence hub device, a first interface circuit connected to a communication chip in the electronic device and configured to communicate over a multi-drop bus; a second interface circuit configured to communicate with a central processor within the electronic device via a point-to-point connection; receiving operational policies representing problem scenarios of operational combinations within the communications chip and rules for resolving the scenarios from the central processor; Expanding the received operational policy; receiving a first coexistence message from at least one communications chip via the first interface and the multi-drop bus; determining whether one or more of the problematic scenarios have occurred by at least processing the received coexistence message; and processor circuitry configured to generate a second coexistence message representing a command to update operation of at least one of the communications chips by applying the operational policy in response to determining that the one or more of the problematic scenarios have occurred.

2. 10. The coexistence hub device of claim 1, further comprising at least one communication subsystem configured to execute a communication protocol, wherein operation of the at least one communication subsystem is updated by the processor circuitry in response to determining that the one or more of the problematic scenarios have occurred.

3. The coexistence hub device of claim 2 , further comprising a coexistence control circuit configured to coordinate operation of the at least one communication subsystem in accordance with the operational policy.

4. the coexistence control circuit filters incoming coexistence messages from the communications chip for transfer to a memory associated with the at least one communications subsystem; The coexistence hub device of claim 2 , further configured to transmit the stored incoming coexistence message to the at least one communication subsystem.

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

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

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. 10. The coexistence hub device of claim 1, further comprising: a third interface configured to communicate with at least one sensor device via another multi-drop bus, wherein the processor circuit determines whether the one or more of the problem scenarios have occurred by further processing sensor messages received from the at least one sensor device.

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

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

12. 1. A method for coordinating the operation of a communications chip in an electronic device, comprising: receiving, by a coexistence hub device, from a central processor, an operational policy representing problematic scenarios of operational combinations within the communication chip and rules for resolving the scenarios; deploying the received operational policy to the coexistence hub device; receiving, by the coexistence hub device, a first coexistence message from at least one communications chip via a multi-drop bus; determining, by the coexistence hub device, whether one or more of the problematic scenarios have occurred by at least processing the received coexistence message; generating, by the coexistence hub device, in response to determining that the one or more of the problematic scenarios have occurred, a second coexistence message representing a command to update operation of at least one of the communications chips by applying the operational policy; transmitting, by the coexistence hub device, the second coexistence message to the communications chip via the multi-drop bus; A method comprising:

13. executing a communication protocol by at least one communication subsystem within the coexisting hub device; updating operation of the at least one communications subsystem in response to determining that the one or more of the problem scenarios has occurred; The method of claim 12 further comprising:

14. The method of claim 13 , further comprising coordinating operation of the at least one communication subsystem in accordance with the operational policy.

15. filtering incoming coexistence messages from the communications chip for transfer to a memory associated with the at least one communications subsystem; transmitting the stored incoming coexistence message to the at least one communication subsystem; The method of claim 13 further comprising:

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

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

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

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

20. a central processor; a plurality of communication chips; a multi-drop bus connected to the communication chip; a coexistence hub device, a first interface circuit configured to communicate over the multi-drop bus; a second interface circuit configured to communicate with the central processor via a point-to-point connection; a processor circuit receiving from the central processor via the point-to-point connection an operational policy representing problematic scenarios of operational combinations within the communications chip and rules for resolving the scenarios; Expanding the received operational policy; receiving a first coexistence message from at least one communications chip via the first interface and the multi-drop bus; determining whether one or more of the problematic scenarios have occurred by at least processing the received coexistence message; and processor circuitry configured to generate, in response to determining that the one or more of the problematic scenarios have occurred, a second coexistence message representing a command to update operation of at least one of the communications chips by applying the operational policy.

Images