Communication devices, methods, and storage media for coexistence of activity-based wireless devices

Abstract

Embodiments of this disclosure provide systems, methods, and computer-readable media for managing coexistence between two wireless communication devices. The method may include obtaining protocol metadata corresponding to one or more communication protocols, each individually associated with a corresponding activity identifier. A request including the activity identifier may be received via a communication channel (e.g., a system power management interface). The protocol metadata corresponding to the activity identifier may be used to identify at least one of actions or thresholds that can be subsequently performed and / or applied.

Description

[0001] Cross-reference to related applications

[0002] This patent application claims U.S. Patent Application No. 17 / 483,369, filed September 23, 2021, entitled “Techniques for Activity-Based Wireless Device Coexistence,” the entire disclosure of which is incorporated herein by reference for all purposes. Background Technology

[0003] Today's wireless devices use multiple radio frequency (RF) wireless technologies (e.g., Bluetooth) on a single platform (e.g., smartphones). ® (BT, WiFi, UWB, cellular, etc.). Many wireless communication standards operate within the same spectrum. These wireless devices may need to work together effectively while sharing a common frequency band and / or due to harmonics. When multiple wireless standards occupy the same frequency band, one standard may interfere with another. Typically, wireless coexistence techniques involve static and globally applied thresholds that fail to account for all aspects of a given wireless technology. This provides suboptimal implementations because the characteristics and uses of these wireless devices vary. Summary of the Invention

[0004] The embodiments of this disclosure may provide systems, methods, and computer-readable media for implementing techniques for managing the coexistence of wireless devices, based at least in part on specific activities performed.

[0005] In some embodiments, a computer-implemented method is disclosed. The method may include obtaining protocol metadata corresponding to one or more communication protocols by a communication device. In some embodiments, one or more communication protocols are individually associated with a corresponding activity identifier. The method may also include receiving a request, including an activity identifier from the corresponding activity identifier, via a communication channel (e.g., a system power management interface, bus, interface, etc.). The method may also include obtaining, by the communication device, the corresponding protocol metadata associated with the activity identifier received in the request. The method may further include identifying one or more operations corresponding to at least one of the following from the corresponding protocol metadata associated with the activity identifier: an action or a threshold. The method may further include performing one or more operations by the communication device, at least in part, based on the identified action or the identified threshold.

[0006] In some embodiments, the system power management interface includes a high-speed bidirectional serial bus. The method may also include receiving an additional request via the system power management interface, including a second activity identifier. In some embodiments, the activity identifier may be a first activity identifier, and the first activity identifier may be different from the second activity identifier. The method may also include obtaining additional protocol metadata corresponding to the second activity identifier received in the additional request from a communication device. The method may further include determining, from a priority mapping, a first priority associated with a first activity corresponding to the first activity identifier and a second priority associated with a second activity corresponding to the second activity identifier. In some embodiments, identification of one or more operations is based at least in part on the protocol metadata, the additional protocol metadata, the first priority, and the second priority.

[0007] In some implementations, the protocol metadata includes at least one of the following: periodic values, retry policies, one or more operation bands, one or more coexistence bands, or one or more reactive policies. The reactive policies in the one or more reactive policies can define one or more corresponding actions to be performed in response to receiving a corresponding request that includes a specific activity identifier corresponding to the protocol metadata.

[0008] In some implementations, the communication device is a communication chip configured to transmit and receive data according to a specific set of communication protocols. The request can be received from a standalone communication device. In some implementations, the communication device and the standalone communication device are part of a user equipment.

[0009] In some embodiments, a communication device is disclosed. The communication device may include one or more processors and a memory storing non-transitory computer-executable instructions that, when executed by the one or more processors, cause the communication device to perform operations. Operations may include obtaining protocol metadata corresponding to one or more communication protocols by the communication device. In some embodiments, the one or more communication protocols are individually associated with a corresponding activity identifier. Operations may also include receiving a request via a system power management interface including an activity identifier from the corresponding activity identifier. Operations may also include obtaining corresponding protocol metadata associated with the activity identifier received in the request by the communication device. Operations may also include identifying one or more operations from the corresponding protocol metadata associated with the activity identifier that correspond to at least one of the following: an action or a threshold. Operations may also include performing one or more operations by the communication device at least in part based on the identified action or the identified threshold.

[0010] In some implementations, the protocol metadata corresponding to one or more communication protocols corresponds to one or more communication devices separate from the communication device. The communication device may be one of multiple communication devices located at the user equipment.

[0011] In some embodiments, executing computer-executable instructions also enables the communication device to identify from protocol metadata corresponding to an activity identifier one or more subsequent operations corresponding to at least one of the following: additional actions or additional thresholds. In some embodiments, the communication device may set a timer associated with one or more subsequent operations and perform one or more subsequent operations at least in part based on the expiration of the timer.

[0012] In some implementations, the protocol metadata identifier corresponds to an action associated with an activity identifier, and this action includes adjusting the power settings of the communication equipment. In some implementations, the protocol metadata identifier corresponds to an action associated with an activity identifier, and this action includes triggering the deactivation of a secondary cell configured to transmit using unlicensed spectrum.

[0013] In some implementations, the protocol metadata identifies a threshold, and this threshold specifies an acceptable level of throughput degradation. In some implementations, the protocol metadata identifies multiple actions, and each of the multiple actions corresponds to either a first transmission attempt or a subsequent transmission attempt.

[0014] In some embodiments, the communication device is a component of the user equipment. The method may also include receiving protocol metadata from a second communication device of the user equipment by the communication device. In some embodiments, the communication device stores the protocol metadata. In some embodiments, the protocol metadata may correspond to the second communication device. The second communication device may be a component of the user equipment separate from the communication device. In some embodiments, the second communication device stores additional protocol metadata corresponding to the communication device. In some embodiments, the computing device and the second computing device operate within the same spectrum range.

[0015] In some embodiments, a computer-readable storage medium is disclosed. The computer-readable storage medium may have computer-executable instructions stored thereon that, when executed by at least one processor, cause at least one processor to perform any of the methods disclosed herein.

[0016] In some embodiments, a non-transitory computer-readable storage medium is disclosed. This non-transitory computer-readable storage medium may have computer-executable instructions stored thereon that, when executed by a processor of a communication device, cause the processor to perform any of the methods disclosed herein.

[0017] The following detailed description, together with the accompanying drawings, will provide a better understanding of the nature and advantages of this disclosure. Attached Figure Description

[0018] Figure 1This is a simplified block diagram illustrating an exemplary process for managing the coexistence of two or more wireless technologies using a coexistence engine according to at least one implementation.

[0019] Figure 2 It is an exemplary computing environment comprising multiple communication devices according to at least one implementation scheme.

[0020] Figure 3 An exemplary set of protocol metadata instances according to at least one implementation scheme is shown.

[0021] Figure 4 This is a schematic diagram of an exemplary computer architecture for a coexistence engine according to at least one embodiment, the exemplary computer architecture including multiple modules capable of performing functions.

[0022] Figure 5 An exemplary use case for managing the coexistence of two or more wireless technologies according to at least one implementation scheme is shown.

[0023] Figure 6 Another exemplary use case for managing the coexistence of two or more wireless technologies is shown according to at least one implementation scheme.

[0024] Figure 7 This is a flowchart illustrating an exemplary method for managing the coexistence of two or more wireless technologies according to at least one embodiment.

[0025] Figure 8 Includes a functional block diagram of an exemplary user equipment according to the implementation scheme. Detailed Implementation

[0026] Specific embodiments of this disclosure relate to various techniques for providing coexistence of activity-based wireless devices. Today, user devices (e.g., smartphones, tablets, laptops, etc.) typically incorporate multiple wireless technologies, such as Bluetooth. ® (BT), WiFi, Ultra-Wideband (UWB), Cellular, etc. When multiple wireless transmitters (e.g., chips sharing a common frequency band) are close together, the likelihood of interference and coexistence problems increases.

[0027] Typically, wireless coexistence technologies include static and globally applied thresholds that fail to account for various aspects of a given wireless technology. For example, a wireless device (e.g., a BT radio component) might request another wireless device (e.g., a cellular radio component) to stop transmitting so that it can perform certain operations without interference. This request can be complied with by the receiving device (e.g., the cellular radio component), as long as complying with the request does not degrade the compliant device's performance below a certain threshold. Current coexistence technologies do not differentiate between the potential activities associated with one request or another. Nor do they consider whether the request is complied with for the specific operation to be performed. This leads to problems because providing the best user experience may require specific activities to take precedence over others, and some wireless protocols may be more sensitive than others, making missed transmission or reception opportunities have a more significant impact on the user compared to other wireless protocols.

[0028] The techniques discussed in this paper utilize activity identifiers for requests between wireless devices. Each wireless device can be configured to store protocol metadata (e.g., data identifying various characteristics of the communication protocol used to transmit data for various activities, such as periodic values, retry policies, one or more operating bands, one or more coexistence bands, one or more reactive policies, etc.) for other nearby wireless devices. When a request is issued, the transmitting device can include an activity identifier in the request indicating the specific activity to be performed. Using this information, the receiving device can differentiate between activities, enabling a better user experience. The receiving device can identify one or more characteristics of the communication protocol to be used by the requesting device for a given activity from the stored protocol metadata. By leveraging this metadata, the receiving device can make more informed decisions about whether to comply with the request and / or how to best manage multiple requests from multiple wireless devices.

[0029] For example, cellular devices (e.g., cellular device 202D) and WiFi devices (e.g., Figure 2 The WiFi ranging operation is a user equipment (202B) of the personal computer. When an accessory device (e.g., a smartwatch) is brought within a certain threshold distance of the personal computer, WiFi ranging allows the user to unlock the personal computer while wearing the accessory device. The WiFi ranging operation is a high-priority activity lasting 0.5 seconds. This activity can operate on frequency bands where cellular devices also perform unlicensed New Radio (NR) operations.

[0030] In older systems, Wi-Fi devices send real-time requests to cellular devices, demanding that the cellular device shut down its transmission. The cellular device is unaware of what the Wi-Fi device is doing, so it complies with the request as long as throughput doesn't degrade by more than 20% (the same threshold applicable to all Wi-Fi requests). Therefore, unlocking is disrupted, and the personal computer remains locked.

[0031] Using the techniques disclosed herein, WiFi sends a real-time request with an activity ID that identifies the activity as a WiFi unlocking activity. A cellular device (running the coexistence engine discussed herein) identifies the activity based on the activity ID and utilizes the corresponding protocol metadata as discussed herein to identify the unlocking activity for only 0.5 seconds. In some implementations, the cellular device can identify different thresholds to utilize from protocol metadata (e.g., predefined data). For example, based on the identification request being related to WiFi unlocking, the cellular coexistence engine may allow more than 20% cellular quality degradation. This is preferred because WiFi activity is significant and transient, and interference with this activity will negatively impact the user. Therefore, the coexistence engine allows a temporary (0.5 seconds) throughput degradation for the cellular device (which can be ignored by the user) to prioritize the WiFi unlocking activity. In some implementations, the coexistence engine may be configured to utilize previously stored priority data identifying the priority among various activities, where the activity may be associated with one or more communication devices (e.g., communication device 202). Using this priority data, the coexistence engine can prioritize various activities of cellular devices and other communication devices based on a predefined priority scheme (e.g., a predefined set of rules that define the priority between activities).

[0032] In previous systems, a BT radio component might request a cellular radio component to stop transmitting for a relatively short period of time. BT radio component requests can be used for BT voice activity that includes multiple transmission retries. In previous systems, the cellular radio component would not differentiate between these multiple transmission attempts. Instead, each request would be treated identically (e.g., the cellular radio component would comply with the request each time, as long as complying with the request would not degrade cellular performance by a certain predefined threshold). However, voice activity can play a significant role in providing a pleasant user experience. Failure to transmit such data can result in the user hearing click sounds, which can be extremely annoying and lead to a poor user experience. Using the techniques discussed herein, the cellular radio component can leverage protocol metadata to determine which voice activity data can be transmitted by the BT radio component multiple times. Using this information, the cellular radio component can assign increased priority to each subsequent retrieval to ensure that the voice activity is transmitted at the expense of activities with minimal impact on the user.

[0033] Therefore, the technology disclosed herein enables a device's wireless technology to gain a clearer understanding of information about the activities to be performed by other wireless technologies within the device. This allows for more informed decision-making, resulting in an overall improved user experience.

[0034] Go to Figure 1 This document illustrates an exemplary process 100 for managing the coexistence of two or more wireless technologies using a coexistence engine according to at least one embodiment. User equipment 102 (e.g., smartphone, laptop, tablet, etc.) may include any suitable number of communication devices (e.g., communication device 104, communication device 106, etc.). Communication devices may be independent integrated circuits (e.g., microchips, also referred to as “chips” or “communication chips”) that integrate hardware and software on top of a chipset to provide various communications corresponding to a specific wireless technology. Each communication device discussed herein may include any suitable combination of onboard microprocessors, memory, power connectors, antenna ports, and / or any suitable components configured to assist in performing wireless communications corresponding to a specific wireless technology. Each communication device may utilize a communication protocol for wireless communication. A “communication protocol” refers to a predefined set of rules specifying how electronic devices communicate wirelessly with each other. For example, a communication protocol may specify message structures, message transmission and / or reception rules, retry requests, etc.

[0035] Process 100 can be... Figure 1 Any of the communication devices depicted performs (e.g., by coexistence engine 108, a corresponding instance of which may execute on each of communication devices 104 and 106). Each communication device may reside at user equipment 102 and be communicatively connected to each other via a serial bus (not depicted). Each communication device performs various activities (corresponding to one or more transmissions and / or receptions in a predefined series), such as, but not limited to: establishing a BT connection, making a voice call, performing a low-latency audio connection, making a voice call using a low-latency audio connection, screen mirroring, streaming content, automatically unlocking a user equipment using another nearby user equipment, etc. At least some of the communication devices operating at user equipment 102 perform one or more activities using a common frequency band. Using a common frequency band increases the likelihood of interference and coexistence problems between those communication devices. For example, a user may make a video call using a Bluetooth headset on 2.4 GHz. In this example, Bluetooth reception may be affected by cellular (e.g., LTE transmission), but cellular reception may not be affected by BT transmission.

[0036] Process 100 may begin at 110, where protocol metadata for a set of communication activities (e.g., cellular chip, Bluetooth (BT) chip, etc.) can be obtained. In some embodiments, instances of the protocol metadata may identify aspects of one or more communications to be performed corresponding to a specific activity (e.g., as identified by an activity identifier). For example, an instance of protocol metadata corresponding to a BT voice activity may indicate that a specific number of messages (e.g., three messages) can be transmitted at a specific frequency / rhythm (e.g., at 7.5 milliseconds (ms) intervals). In some embodiments, the protocol metadata for a BT voice activity may also identify a specific number of retries that may occur. For example, a retry may occur if the transmitting device fails to receive a response indicating that the transmitted message was received by the intended receiver. In some embodiments, the protocol metadata may indicate one or more operations to be performed in response to receiving a request that includes an activity identifier associated with the protocol metadata. Generally, protocol metadata may include any suitable data, such as transmission periodicity, rhythm, pattern, retry policy, operation bands for transmission, one or more coexistence bands, one or more policies for responding to requests with corresponding activity identifiers, or any suitable information relating to any aspect, attribute, or characteristic of a transmission corresponding to a given activity or to be performed due to receiving a request corresponding to that activity. Coexistence engine 108 may store protocol metadata at protocol data repository 112, which is a data repository configured to store such information.

[0037] As a non-limiting example, protocol data repository 112 may store data for activities 1 and 2. The protocol metadata for activity 1 may indicate that messages can be transmitted every 9 ms for five seconds (or until a response is received), as shown at 114. The protocol metadata corresponding to activity 2 may indicate that messages will be transmitted three times, spaced 7.5 ms apart, as depicted at 116.

[0038] At 118, a request corresponding to a specific activity may be received (e.g., from a communication device in communication device 104). In some embodiments, the request may include an activity identifier that uniquely identifies the specific activity. For example, the request may indicate that the activity is a Bluetooth connection activity (e.g., corresponding to one or more messages transmitted and / or received during a connection to the BT device).

[0039] At 120, the coexistence engine 108 can identify the protocol metadata associated with the activity. For example, the coexistence engine 108 can use the activity identifier received in the request to retrieve the corresponding instance of the protocol metadata (e.g., the protocol metadata associated with the same activity identifier).

[0040] At 122, based at least in part on a predefined set of rules, the coexistence engine 108 can identify one or more actions to be performed in response to a request, based at least in part on protocol metadata corresponding to the activity. For example, the coexistence engine 108 can identify from the protocol metadata associated with an activity identifier provided in a given request that a set of operations (e.g., action X as depicted at 124) be performed in response to the first receipt of a request with a specific activity identifier (as depicted at 126). The same operations described above can be performed for subsequent received requests with the same activity identifier (e.g., when attempting a retransmission). The coexistence engine 108 can identify another set of operations (e.g., action X as depicted at 128) to be performed in response to the receipt of another request corresponding to that activity identifier (as depicted at 130).

[0041] Not every operation performed by the coexistence engine 108 needs to be triggered by receiving a request. In some implementations, using protocol metadata, the coexistence engine 108 can anticipate receiving a request (e.g., due to a specific periodicity indicated in the protocol metadata) and can perform any appropriate operation before receiving subsequent requests.

[0042] For example, if the expected packet transmissions of a cellular chip overlap with BT activity, and the start time of the overlap is known, the cellular transmission output power can be limited / capped in advance. Similarly, when BT activity is in progress, link quality measurements can be scheduled during a time that does not conflict with the ongoing BT activity, as such measurements would be subject to interference from BT transmissions. Furthermore, if the expected overlap of cellular packets with BT activity, an antenna with better isolation can be selected for transmission because that antenna is less susceptible to interference. Conventionally, the anticipated actions described above are impossible because the cellular chip (or any chip in the user equipment) does not have access to any protocol information that could be used to anticipate upcoming packets. Instead, the cellular chip always applies the same limitations. By utilizing the techniques described herein, anticipation can be made so that the chip does not need to always apply limitations or apply the same limitations to all activities.

[0043] Figure 2 This is an exemplary computing environment 200 comprising multiple communication devices according to at least one embodiment. The specific number and / or type of the communication devices may vary. For example, such as Figure 2 As described, the communication devices may include Bluetooth (BT) device 202A, WiFi device 202B, Ultra-Wideband (UWB) device 202C, and cellular device 202D, collectively referred to herein as "communication device 202". Although Figure 2 The document shows a specific number and type of communication devices, but Figure 2The examples provided are not intended to limit the scope of this disclosure. Communication device 202 may include any suitable number and / or type of communication devices (e.g., Figure 2 Any suitable combination and / or of the communication devices described herein Figure 2 Other communication devices not depicted in the text). In some embodiments, communication devices 202 may be located near each other on a common device (e.g., user equipment 102).

[0044] Each communication device in communication device 202 may be a separate integrated circuit (e.g., a microchip, also known as a “chip” or “communication chip”) that integrates hardware and software on top of a chipset to provide various communications corresponding to a specific wireless technology. Each communication device in communication device 202 may include an onboard microprocessor, memory, power connector, antenna port, and / or any suitable components configured to assist in performing wireless communications corresponding to a specific wireless technology.

[0045] In some embodiments, environment 200 may include a communication channel (e.g., a system power management interface (SPMI) 204). SPMI 204 may include a serial bus (e.g., a high-speed, low-latency, bidirectional, two-wire serial bus, etc.) that can be used for power management activities and / or for enabling communication between communication devices 202. In some embodiments, SPMI 204 may be used to transfer data between communication devices 202 (e.g., integrated circuits corresponding to different wireless communication technologies). SPMI 204 is used herein for illustrative purposes and is not intended to limit the scope of this disclosure. Any suitable proprietary bus or interface may be similarly used for communication between communication devices 202. In some embodiments, on-chip communication may be used for communication between communication devices 202 (e.g., where all communication devices 202 are integrated on a common chip). In these cases, communication between communication devices 202 will be a shared memory library that does not require a bus.

[0046] In some implementations, the coexistence engine 206 may execute at the cellular device 202D to manage operations at the cellular device 202D. The coexistence engine 206 may be... Figure 1 An example of coexistence engine 108 is provided. It should be understood that any suitable number of communication devices 202 can execute corresponding instances of coexistence engine 206. In some implementations, a single instance of coexistence engine 206 can reside at any suitable communication device and be used to manage the coexistence of any suitable combination of communication devices 202.

[0047] In some implementations, environment 200 may include coexistence manager 208. Coexistence manager 208 may be configured to acquire, store, and / or maintain any suitable number of instances of protocol metadata corresponding to any suitable number of activity identifiers and / or communication devices. For example, coexistence manager 208 (e.g., Figure 1 The user device 102's operating system components can be configured to obtain from the data repository 210 any appropriate number of protocol metadata instances corresponding to any appropriate number of activities associated with the communication device 202. In some embodiments, the data repository 210 may reside at a server device or in the local memory of the device on which the communication device 202 is executed (e.g., user device 102, etc.). In some embodiments, the coexistence manager 208 can be configured to provide each coexistence engine 206 with protocol metadata instances describing aspects of activities associated with other communication devices.

[0048] For example, coexistence manager 208 can be configured to retrieve any suitable number of protocol metadata instances (e.g., from data repository 210, which in this example resides at user equipment 102), these protocol metadata instances corresponding to various activities that can be performed by communication devices 202A, 202B, and 202C. Cellular device 202D may include one or more memories (e.g., memory 212) in which the provided protocol metadata instances can be stored. In some embodiments, these operations enable each communication device in communication device 202 to access data identifying various characteristics that identify actions that can be performed by other communication devices in environment 200.

[0049] In some implementations, data repository 210 may include priority data (e.g., one or more mappings) indicating the priority assigned to one or more activity identifiers. For example, priority data may indicate that one activity identifier (e.g., activity identifier 4) has a higher priority than another activity identifier (e.g., activity identifier 3). Generally, priority data can specify any suitable data that can identify the priority used to transmit messages in a given situation. If the coexistence engine receives multiple requests from one or more communication devices, the coexistence engine can identify which activity (or activities) takes precedence over the others. Coexistence manager 208 may be configured to similarly distribute such data among communication devices, such that each communication device can locally store priority data and use such data to identify the priorities of activities that may conflict.

[0050] Figure 3An exemplary set of protocol metadata instances (e.g., protocol metadata instances 300A-300D, collectively referred to as "protocol metadata instances 300") according to at least one embodiment is shown. In some embodiments, protocol metadata instances 300A and 300B may correspond to... Figure 2 The activities associated with BT device 202A. Protocol metadata instances 300C and 300D can correspond to the activities associated with... Figure 2 The activities associated with the WiFi device 202B. Protocol metadata instance 300 may include activities individually associated with... Figure 2 Any suitable combination of communication devices 202 and any suitable number of data instances associated therewith. In some implementations, protocol metadata instances 300 may be stored in a data repository 304 (e.g., Figure 2 (Example of a data repository within data repository 210 and / or storage 212).

[0051] In some implementations, each protocol metadata instance in protocol metadata instance 300 may include any suitable data identifying aspects or characteristics of the activity corresponding to that instance. For example, protocol metadata instance 300A may correspond to a Bluetooth voice activity associated with a unique identifier (e.g., Activity ID: 1). In some implementations, the identifier associated with each protocol metadata instance may be an identifier of any suitable length, including alphanumeric characters, configured to uniquely distinguish a particular protocol metadata instance from other protocol metadata instances.

[0052] like Figure 3 As depicted, protocol metadata instance 300A may include one or more periodic values. Periodic values ​​indicate one or more attributes of the periodicity of message transmissions associated with a given activity. For example, protocol metadata instance 300A may include a set of periodic values ​​(e.g., {yes, cadence: 7.5ms}) indicating one or more aspects of the periodicity of message transmissions corresponding to a Bluetooth voice activity. For instance, this set of periodic values ​​may indicate the existence of a periodicity associated with message transmissions corresponding to a Bluetooth voice activity (e.g., “Yes”), and the periodicity of the transmitted messages corresponds to 7.5ms between messages (e.g., “cadence: 7.5ms”). Protocol metadata instance 300A may include any suitable data identifying whether a retry will be attempted when the transmitting communication device does not receive a response; and / or the number of retries the transmitting device can attempt. In some embodiments, protocol metadata instance 300A may indicate one or more operating bands (e.g., 2.4 GHz). A band is an interval in the frequency domain corresponding to lower and higher frequencies. For example, a 2.4 MHz band could include frequencies between approximately 2,400 MHz and 2,483.5 MHz.

[0053] In some implementations, protocol metadata instance 300A may indicate one or more coexistence bands (e.g., B40, B41, B7, etc.). In some implementations, coexistence bands may identify frequency ranges shared by communication devices and at least one other communication device of a system performing activities corresponding to protocol metadata instance 300A. For example, protocol metadata instance 300A may indicate communication devices transmitting BT voice activities (e.g., Figure 2 The BT device (202A) must coexist with at least one other communication device in each of the frequency bands B40, B41 and B7.

[0054] In some implementations, protocol metadata instance 300A includes one or more reactive policies. A "reactive policy" can identify one or more actions / operations to be performed in response to receiving a request corresponding to an activity ID. The reactive policies of protocol metadata instance 300A can instruct: by the receiving device (e.g., Figure 2 The actions / operations performed by the cellular device 202D may include capping the output power to 10 dBm and applying a threshold that indicates compliance with a request corresponding to the Activity ID, provided that a performance indicator (e.g., a Cellular Quality Indicator (CQI)) indicates that the cellular activity quality exceeds the threshold (indicated by the value "X"). Protocol metadata instance 300A may indicate that this policy can be executed in response to receiving a first request including the Activity ID from a given device.

[0055] In some implementations, protocol metadata instance 300A includes one or more thresholds. In some implementations, at least one such threshold specifies an acceptable level of throughput degradation (e.g., throughput degradation corresponding to a device that modifies its performance in response to the activity of another device).

[0056] The reactive policy of protocol metadata instance 300A can indicate: by the receiving device (e.g., Figure 2 The actions / operations performed by the cellular device 202D may include shutting down the transmitting equipment (e.g., the radio transmitter of the cellular device 202D) unless a performance indicator (e.g., CQI) indicates that the cellular activity quality exceeds a threshold (indicated by the value "Y"). Protocol metadata instance 300A may indicate that this policy can be executed in response to a second request, including an activity ID, received from a given device. Executing this policy causes the cellular device 202D to shut down its transmitter, provided that the cellular quality does not degrade beyond a certain predefined amount.

[0057] The reactive policy of protocol metadata instance 300A can indicate: by the receiving device (e.g., Figure 2The actions / operations performed by the cellular device 202D may include shutting down a transmitting device (e.g., the radio transmitter of the cellular device 202D) regardless of quality or any other factors. Protocol metadata instance 300A may indicate that this policy can be executed in response to a third request, including an activity ID, received from a given device. Executing this policy causes the cellular device 202D to shut down its transmitter.

[0058] In some implementations, protocol metadata instance 300A may include an indication identifier indicating whether to deactivate a Licensed Secondary Access Secondary Cell (LAA S-cell). In some implementations, LAA is a feature of cellular device 202D that utilizes unlicensed frequency bands (e.g., 5 GHz) combined with licensed spectrum to provide performance enhancements for mobile device users. In some implementations, the indication identifier may indicate whether to deactivate the LAA S-cell of cellular device 202D.

[0059] In some implementations, protocol metadata instance 300 (or Figure 2 The data repository (304 and / or 210) may include any suitable protocol metadata instance that describes any suitable aspect of the communication protocol corresponding to a specific activity.

[0060] return Figure 2 The memory 212 can be configured to store Figure 3 The data repository 304 contains protocol metadata instances (such as those received from the coexistence manager 208). The coexistence manager 208 can operate on it. Figure 2 The coexistence manager 208 is a component of the operating system of the device (e.g., user equipment 102). In some embodiments, the coexistence manager 208 may be configured to obtain and provide each communication device with a set of protocol metadata instances corresponding to the other communication devices 202. Each communication device 202 may be configured with one or more memories where the protocol metadata provided by the coexistence manager 208 is stored. In some embodiments, an independent coexistence engine executing at each of these communication devices may utilize this data to drive its operation, as described herein with respect to coexistence engine 206. In some embodiments, the coexistence engine may be shared by two or more communication devices (e.g., communication devices 202A-202C). The coexistence engine may be executed from any of those devices (e.g., WiFi device 202B) and may be configured to manage various operations performed by communication devices 202A-202C in response to requests received from cellular device 202D.

[0061] Figure 4This is a schematic diagram of an exemplary computer architecture 400 for a coexistence engine 402 according to at least one embodiment, the exemplary computer architecture including multiple modules (e.g., module 404) capable of performing functions. The coexistence engine 402 is a coexistence engine (206 and / or Figure 1 Examples of coexistence engines 108. These modules 404 may be software modules, hardware modules, or combinations thereof. If module 404 is a software module, then module 404 may be specifically implemented on a non-transitory computer-readable medium and processed by a processor in any computer system described herein. Any suitable combination of modules 404 may be implemented in a user device (e.g., Figure 1 The system operates at user equipment 102. It should be noted that in some embodiments, any module or data repository described herein may be a service responsible for providing the functions corresponding to module 404 as described below. Module 404 may exist as part of coexistence engine 402, or it may exist as a separate module or service external to coexistence engine 402. In some embodiments, coexistence engine 402 may be connected to one or more baseband components (e.g., a baseband processor that converts digital data to radio frequency signals or vice versa). In some embodiments, coexistence engine 402 may be connected to a communication channel (e.g., SPMI or another suitable bus) to receive and / or send requests to other wireless technologies (e.g., other chips operating at user equipment 102).

[0062] exist Figure 4 The illustrated implementation shows data storage areas such as Activity ID data repository 406 and Protocol data repository 408, but data can be maintained, exported, or otherwise accessed from various data repositories located remotely or locally on the coexistence engine 402 to achieve the functionality described herein. Figure 4 As shown, the coexistence engine 402 includes various modules (e.g., sub-components), such as the data processing module 416, the protocol manager 414, and the expectation engine 418, but different functions can be assigned among the sub-components of the coexistence engine 402. Some functions of module 404 are described below. However, for the reader's benefit, a brief, non-limiting description of each of these modules is provided in the following paragraphs.

[0063] Data processing module 416 can be configured to process data from any suitable computing device (e.g., from...). Figure 2 The coexistence manager 208 and / or any communication device in the communication device 202 may receive and / or transmit any suitable data to it. In some embodiments, the data processing module 416 may be configured to receive data from the coexistence manager 208 and / or any communication device in the communication device 202. Figure 2The coexistence manager 208 receives any suitable data. For example, the data processing module 416 can be configured to receive priority data (e.g., one or more mappings identifying priorities between activities, also referred to as "priority mappings"). The data processing module 416 can be configured to store such priority data in an activity ID data repository 406 (a data repository configured to store such information). Similarly, the data processing module 416 can be configured to receive protocol metadata corresponding to any suitable number of communication devices. This information can be received from any suitable source (e.g., the coexistence manager 208) and stored in any suitable location (e.g., the protocol data repository 408 (a data repository configured to store such information)). In some embodiments, the received priority data and / or protocol metadata can be stored in a corresponding data repository as if associated with a corresponding activity identifier, such that the activity identifier can be used to retrieve the corresponding instance of the protocol metadata and / or priority data.

[0064] In some implementations, data processing module 416 may be configured to receive a request including an activity identifier (referred to herein as an "Activity ID"). Data processing module 416 may be configured to identify the Activity ID from the received request and use the Activity ID to retrieve any suitable combination of priority data and / or protocol metadata corresponding to the Activity ID. In some implementations, priority data does not need to be associated with a specific Activity ID. In these cases, priority data may be globally applicable (e.g., providing priority rules for multiple activities corresponding to multiple communication protocols). Data processing module 416 may be configured to provide protocol manager 414 with any suitable combination of the request, priority data, and / or protocol metadata.

[0065] The coexistence engine 402 may include a protocol manager 414. The protocol manager 414 may be configured to receive and / or obtain priority data and / or protocol metadata from the data processing module 416 and / or data repositories 406 and / or 408. The protocol manager 414 may be configured with instructions that, when executed, cause a received request to be evaluated at least in part based on the protocol metadata. For example, the protocol manager 414 may determine a specific operation to be performed in response to a request based on one or more reactive policies of the protocol metadata. In some embodiments, the protocol manager 414 may be configured to identify and perform a specific operation identified within the protocol metadata corresponding to the request. In some embodiments, the protocol manager 414 may be configured to identify which operations to be performed in response to a request based at least in part on priority data received from the data processing module 416. That is, the protocol manager 414 may utilize the priority data to identify whether to perform an action corresponding to the request or a previously received request. In some implementations, the protocol manager 414 can execute instructions that, at least in part, invalidate or reverse previous actions (e.g., shutting down a transmitter performed due to a previous request) based on identifying from priority data a different set of actions (e.g., applying a threshold) corresponding to a recently received request (e.g., when the priority of the activity corresponding to the recently received request exceeds the priority of the activity corresponding to a previously received request). Generally, the protocol manager 414 can be configured to manage the execution of any suitable operation corresponding to a request. These operations may include, but are not limited to: applying a threshold power setting (referred to as "power capping" or "capped output power") to the transmission of a particular communication device (e.g., cellular device 202D); shutting down a radio transmitter; deactivating a component of a particular communication device (e.g., the LAA S-cell of cellular device 202D); discarding message transmissions; adding / removing antennas participating in antenna selection logic (e.g., causing an antenna with poor coexistence significance to be removed from the selection logic), etc.

[0066] In some implementations, the protocol manager 414 may maintain any suitable records corresponding to any suitable number of requests, indicating the time when the request was received, one or more actions performed in response to the request, one or more thresholds for identifying the actions (or operations) to be performed in response to the request, the time when the corresponding message was transmitted by another communication device, or any suitable data associated with the request, action / operation, or threshold. This data may be stored in the activity ID data repository 406, allowing the protocol manager 414 to track actions / operations performed and message transmissions by one or more communication devices.

[0067] In some implementations, the anticipation engine 418 may be configured to receive protocol metadata corresponding to a given request from the data processing module 416 and / or the protocol manager 414. In some implementations, the anticipation engine 418 may obtain protocol data directly from the protocol data repository 408. The anticipation engine 418 may be configured with instructions that, when executed, cause one or more timers to be set at least in part based on the protocol metadata. As a non-limiting example, if the anticipation engine 418 recognizes that a specific request may be received at a later time, the anticipation engine 418 may be configured to set a timer to expire just before the request is received (e.g., within a threshold time period of the expected request time). When the time expires, the anticipation engine 418 (and / or the protocol manager 414) may be configured to perform any appropriate action based on the knowledge that a request is about to be received. Thus, operation between communicating devices can be optimized based on anticipating future requests.

[0068] For example, anticipating engine 418 can: identify one or more subsequent operations corresponding to at least one of an action or a threshold from protocol metadata corresponding to an activity identifier; set a timer associated with one or more subsequent operations; and cause the communication device to perform one or more subsequent operations at least in part based on the expiration of the timer. For example, anticipating engine 418 can set a timer set to elapse at the time corresponding to the start of the LTE time slot closest to the start of the ongoing BT activity. When the timer expires, the output power can be reduced from the start of the time slot until the known end time of the BT activity. Therefore, it is not necessary to abruptly shut down LTE transmissions with high output power at the start of BT operation; instead, LTE will take measures (e.g., reduce output power) in the time slot when overlapping BT activity is anticipated.

[0069] Figure 5 An exemplary use case 500 for managing the coexistence of two or more wireless technologies is shown according to at least one implementation. Figure 5 At position 502, a protocol corresponding to a specific activity ID is described (e.g., a protocol associated with a BT voice activity). For example, the protocol described at position 502 indicates that for a BT voice activity, messages should be transmitted up to three times at 7.5ms intervals, and two transmission retries can be attempted. The protocol described at position 502 can correspond to... Figure 3 Protocol metadata 300A.

[0070] Figure 5 It also describes the process via SPMI (e.g., Figure 2 SPMI 204) is powered by a coexistence engine (e.g., Figure 4The coexistence engine (402) receives the data. For example, a request with an activity ID="1" can be received at each of the times indicated at 504, 506, 508, and 510. Figure 5 The reactive strategies applied based on corresponding requests are also described. At points 512, 514, 516, and 518, the coexistence engine (and...) is described. Figure 2 One or more actions and / or thresholds applied by the coexistence engine corresponding to the cellular device 202D.

[0071] For example, in cellular devices (e.g., Figure 2 The coexistence engine (e.g., in the cellular device 202D) is executed at the location of the cellular device. Figure 4 The coexistence engine 402) can be accessed at 504 from another communication device (e.g., Figure 2 The BT device 202A receives a request (referred to as the "first request"). In some implementations, the received request includes an Activity ID equal to the value "1". Using the Activity ID, the coexistence engine can retrieve protocol metadata corresponding to the first request. For example, the coexistence engine can look up the protocol metadata at least in part based on the Activity ID. Figure 3 The metadata instance 300A is used to retrieve the protocol metadata instance.

[0072] In some implementations, the coexistence engine may be configured with instructions that, when executed, include identifying one or more reactive policies that, based on a set of conditions, identify one or more actions to be performed and / or one or more thresholds to be applied. As a non-limiting example, a first reactive policy may instruct that, upon receiving a request corresponding to a first transmission attempt, the coexistence engine may cap the output power of the cellular device to a specific amount (e.g., 10 dBm), provided that the quality of cellular communication does not degrade beyond a certain threshold level (e.g., identified at least in part based on a threshold provided in the protocol metadata corresponding to the activity ID). Therefore, in response to receiving a first request, in some implementations, the coexistence engine performs operations corresponding to the first reactive policy as depicted at 512. In some implementations, this may include performing any suitable number of actions and / or applying any suitable number of thresholds.

[0073] A coexistence engine can store any suitable data indicating when and what specific operations were performed and / or when and what specific transmissions or receptions occurred at independent communication devices. For example, a coexistence engine (e.g., Figure 4The protocol manager 414 can store data indicating that the output power of the cellular device's power supply is capped to a specific value at a specific time and / or that a specific threshold (e.g., threshold X) is used when determining whether to cap that power. In some embodiments, the coexistence engine can store the time when a first request is received and / or the time when a transmission or reception corresponding to the first request and another communication device is performed. In some embodiments, the coexistence engine (e.g., Figure 4 The expected engine 418 can set one or more timers (e.g., timers that indicate the time when the next message is expected and / or timers that indicate the time period when message transmission and / or reception by other communication devices is completed when the time expires).

[0074] At 514, the coexistence engine can receive a second request. Similarly, the coexistence engine can obtain protocol metadata associated with the activity ID. Based on the protocol metadata and previously stored data associated with the first request, the coexistence engine can identify that the second request is a retransmission attempt. The coexistence engine can determine that the same operation should be performed in response to the second request. The coexistence engine can perform those operations (e.g., capping the output power of the cellular device according to a threshold X) and can update data indicating that the output power of the cellular device's power supply was capped to a specific value at a specific time and / or that a specific threshold (e.g., threshold X) was used when determining whether to cap that power. In some embodiments, the coexistence engine can store the time when the second request was received and / or the time when a transmission or reception corresponding to the second request and another communication device was performed. Upon receiving a third request with the same activity ID, the same operation described in conjunction with 514 can be performed again at 516.

[0075] Subsequently, the coexistence engine may receive another request (e.g., a fourth request corresponding to the activity ID and received after the first, second, and third requests). The coexistence engine may again identify one or more reactive policies corresponding to the activity ID. At this point, the coexistence engine may identify a second reactive policy that instructs the coexistence engine to shut down transmitting components (e.g., the radio transmitter of a cellular device) upon receiving a request corresponding to a second transmission attempt (e.g., the fourth request), provided that the quality of cellular communication does not degrade beyond a certain threshold level (threshold Y, identified at least in part based on a threshold provided in the protocol metadata corresponding to the activity ID). Therefore, in response to receiving the second request, in use case 500, the coexistence engine performs the operation corresponding to the second reactive policy as described in 518.

[0076] In some implementations, the coexistence engine (e.g., protocol manager 414) can recognize the completion of message transmission and / or reception and can delete any previously stored data used for tracking purposes. For example, if no other request corresponding to an activity ID is received (e.g., based on a timer set by protocol manager 414 and according to protocol metadata), the coexistence engine can delete previously stored data used to track transmissions and / or receptions at another communication device.

[0077] Figure 6 The diagram illustrates a method for managing two or more wireless technologies (e.g., BT device 202A and) according to at least one embodiment. Figure 2 Another exemplary use case 600 is the coexistence between cellular devices (202D). In some implementations, communication devices (e.g., BT device 202A) may implement one or more communication protocols. Figure 6 Two exemplary communication protocols are described (communication protocol 600A corresponding to BT connection activities and communication protocol 600B corresponding to BT voice activities).

[0078] Figure 6 It also describes the process via SPMI (e.g., Figure 2 SPMI 204) is powered by a coexistence engine (e.g., Figure 4 The coexistence engine (402) receives the data. For example, a request with activity ID "1" can be received at each of the times indicated at 604, 608, 610, and 612, while a request including activity ID "2" can be received at 606, 614, 618, and 620. Because the coexistence engine maintains protocol data corresponding to each activity ID, the coexistence engine can differentiate requests and apply different thresholds and / or perform different actions / operations based on the received requests. For example, actions and / or operations and / or thresholds corresponding to protocol metadata associated with BT connection activity can be used by the coexistence engine at 622, 626, 628, and 630, while different protocol metadata associated with BT voice activity can be used at 624, 632, 634, and 636.

[0079] although Figure 6 The various requests shown originate from a single communication device (e.g., BT device 202A), but it should be understood that requests received via SPMI can originate from any suitable number of communication devices (e.g., Figure 2 Communication equipment 202).

[0080] Figure 7This is a flowchart illustrating an exemplary method for managing the coexistence of two or more wireless technologies according to at least one embodiment. Method 700 may be performed by a communication device having at least one processor and at least one memory storing computer-readable instructions (e.g., Figure 2 The operation of method 700 is performed by any one of the communication devices 202. The operation is executed by a configurable computing device using computer-readable instructions executed by at least one processor. It should be understood that the operations of method 700 can be performed in any suitable order. In some embodiments, additional operations may be included, or at least one operation of method 700 may be excluded.

[0081] The process can begin at 702, where the communication device (e.g., Figure 4 The protocol manager 414 obtains protocol metadata corresponding to one or more communication protocols. In some embodiments, the communication device may be a cellular communication device operating adjacent to the WiFi communication device, both residing in a user equipment, such as a smartphone. In some embodiments, one or more communication protocols are individually associated with a corresponding activity identifier. For example, the protocol manager 414 may obtain a protocol metadata instance that specifies various aspects of the communication protocol used by the WiFi communication device for a specific activity (e.g., WiFi ranging, WiFi peering activities, etc.). Figure 3 Some exemplary instances of such protocol metadata are provided (e.g., protocol metadata instances 300C and 300D).

[0082] At 704, communication channels (e.g., Figure 2 SPMI 204 receives a request including an activity identifier from the corresponding activity identifier. The activity identifier can uniquely identify the activity to be performed by the requesting device (e.g., a WiFi communication device).

[0083] At 706, the corresponding protocol metadata associated with the activity identifier received in the request can be obtained. For example, the activity identifier can be used by the protocol manager 414 to retrieve... Figure 4 The protocol metadata repository in protocol data repository 408.

[0084] At 708, one or more operations corresponding to at least one of the actions or thresholds are identified from the corresponding protocol metadata associated with the activity identifier. In some implementations, the action or threshold depends on the activity identifier. For example, a threshold corresponding to a BT connection activity (e.g., a threshold for output power and / or antenna selection, etc.) may be different from a threshold for a BT voice activity. This may be because an activity (e.g., a BT connection activity) is less affected by transmissions from other wireless technologies with higher output power compared to other activities (e.g., BT voice activity).

[0085] At 710, one or more operations may be performed by a communication device (e.g., cellular device 202D) based at least in part on the identified action or the identified threshold.

[0086] Compared to previously provided techniques, the techniques described herein achieve better coordination between wireless communication devices. As a non-limiting example, a user can use a Bluetooth headset that wirelessly connects to a phone and operates in the 2.4 GHz band to make video calls on their phone. In this particular example, it can be assumed that Bluetooth reception is affected by cellular transmission, but cellular reception is not affected by Bluetooth transmission.

[0087] In previous systems, before any receiving activity, the BT device (e.g., BT device 202A) sent a real-time SPMI request to the cellular device (e.g., cellular device 202D) to shut down its transmitter. The cellular device did not differentiate between requests; therefore, the cellular device would apply the same threshold (e.g., complying with X% for all requests, as long as the overall cellular traffic did not degrade by more than 20%) for each received request.

[0088] In contrast, by utilizing the techniques disclosed herein, the BT device sends a request including an activity ID indicating that the activity is a BT voice activity (this would be the case for each receive window during a voice session). The coexistence engine, executing at the cellular device, utilizes protocol metadata associated with the BT voice activity to identify that the BT voice activity has a specific periodicity and that retrying is critical after a baseline attempt. Therefore, the coexistence engine executing at cellular device 202D can anticipate retransmissions of the baseline attempt (according to a 7.5ms rhythm specified in the corresponding protocol metadata) and reduce output power on any overlapping packet transmissions and / or react to retry indications from BT device 202A, and shut down the cellular transmitter if necessary. The coexistence engine can utilize protocol metadata to ensure an increased likelihood of receiving a response to the BT activity on each attempt. For example, for the first retry, the coexistence engine can only shut down the transmitter of the cellular device if the cellular quality of the cellular device does not degrade beyond a certain predefined threshold. For the second retry, the coexistence engine can still shut down the transmitter despite any quality considerations to ensure that BT voice data can be received.

[0089] As another non-limiting example, a cellular device (e.g., a cellular device utilizing Licensed Assisted Access (LAA) and / or New Radio Unlicensed (NR-u) protocols). Cellular devices (e.g., Cellular Device 202D) and WiFi devices (e.g., Figure 2 The WiFi device 202B can provide network connectivity (e.g., to the Internet). Both can operate on the same frequency band.

[0090] In legacy systems, WiFi devices send real-time indicator flags when transmitting. Cellular devices count these flags, and if the count exceeds a predefined threshold, the cellular device shuts down its LAA / NR-u secondary cell. Cellular devices then monitor these counts, and if the count falls below a threshold, they can then turn on their LAA / NR-u secondary cell.

[0091] Using the techniques disclosed herein, a cellular coexistence engine (e.g., coexistence engine 402 operating at cellular device 202D) monitors activity performed by communication devices 202 (e.g., BT device 202A, WiFi device 202B, and UWB device 202C). The cellular coexistence engine can consider the amount and type of activity along with transmission indication identifiers to determine whether to turn the LAA / NR-u secondary cell on or off. For example, computationally intensive but relatively short-lived activities (e.g., UWB ranging) will not cause the LAA / NR-u secondary cell to be turned off.

[0092] Figure 8 An exemplary user equipment 800 according to some embodiments is shown. User equipment 800 may be similar to... Figure 1 The user equipment 102 is basically interchangeable with it.

[0093] User equipment 800 can be any mobile or non-mobile computing device, such as mobile phones, computers, tablets, industrial wireless sensors (e.g., microphones, carbon dioxide sensors, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, laser scanners, fluid level sensors, stock sensors, voltmeters / ammeters, actuators, etc.), video surveillance / monitoring equipment (e.g., cameras, camcorders, etc.), wearable devices, or loosely coupled IoT devices.

[0094] User equipment 800 may include a processor 804, an RF interface circuit 808, a memory / storage device 812, a user interface circuit 816, a sensor 820, a drive circuit 822, a power management integrated circuit (PMIC) 824, and a battery 828. Components of user equipment 800 may be implemented as integrated circuits (ICs), portions of integrated circuits, discrete electronic devices or other modules, logic components, hardware, software, firmware, or combinations thereof. Figure 8 The block diagram is intended to show a high-level view of some of the components of the user equipment 800. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other specific embodiments.

[0095] Components of user equipment 800 can be coupled to various other components via one or more interconnects 832, which can represent any type of interface, input / output, bus (local, system, or extension), transmit line, trace, optical connector, etc., allowing various circuit components (on common or different chips or chipsets) to interact with each other.

[0096] Processor 804 may include processor circuitry such as baseband processor circuitry (BB) 804A, central processing unit circuitry (CPU) 804B, and graphics processing unit circuitry (GPU) 804C. Processor 804 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage device 812, to cause user device 800 to perform the operations described herein.

[0097] In some implementations, the baseband processor circuit 804A can access the communication protocol stack 836 in the memory / storage device 812 to communicate over a 3GPP-compliant network. Generally, the baseband processor circuit 804A can access the communication protocol stack to perform user plane functions at the PHY, MAC, RLC, PDCP, SDAP, and PDU layers; and control plane functions at the PHY, MAC, RLC, PDCP, RRC, and Non-Access Stratum (NAS) layers. In some implementations, PHY layer operations may additionally / optionally be performed by components of the RF interface circuit 808.

[0098] The baseband processor circuit 804A can generate or process baseband signals or waveforms carrying information in a 3GPP-compliant network. In some implementations, the waveforms used for NR can be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and Discrete Fourier Transform Extended OFDM (DFT-S-OFDM) in the uplink.

[0099] The baseband processor circuit 804A can also access group information from the memory / storage device 812 to determine multiple repeated search space groups in which PDCCHs can be emitted.

[0100] The memory / storage device 812 may include any type of volatile or non-volatile memory that can be distributed throughout the user equipment 800. In some embodiments, some of the memory / storage devices 812 may be located on the processor 804 itself, while other memory / storage devices 812 may be located external to the processor 804 but accessible via a memory interface. The memory / storage device 812 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0101] Although not depicted, memory / storage device 812 may store instructions for an operating system executed by user equipment 800. In some embodiments, the operating system may include components for managing protocol metadata and / or assigning it to one or more communication devices of RF interface circuitry 808 (e.g., Figure 2 The coexistence manager 208). RF interface circuitry 808 may include... Figure 2 Any suitable combination of communication devices 202. In some embodiments, memory / storage device 812 may include... Figure 2 Data repository 210.

[0102] RF interface circuitry 808 may include transceiver circuitry and a radio frequency front-end module (RFEM) that allows user device 800 to communicate with other devices via a radio access network. RF interface circuitry 808 may include various components arranged in the transmit or receive path. These components may include, for example, switching devices, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc. In some embodiments, RF interface circuitry 808 may include communication device 202 (or... Figure 2 (Any suitable component of environment 200). In some embodiments, interconnect 832 may include Figure 2 The SPMI 204 enables various devices of the RF interface circuit 808 to communicate with each other. In various implementations, the RF interface circuit 808 can be configured to transmit / receive signals in a manner compatible with New Radio (NR) access technologies.

[0103] In the receiving path, the RFEM can receive the radiated signal from the air interface via antenna 826 and continue to filter and amplify the signal (using a low-noise amplifier). This signal can be provided to the receiver of the transceiver, which downconverts the RF signal into a baseband signal that is provided to the baseband processor of processor 804.

[0104] In the transmission path, the transceiver's transmitter upconverts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM amplifies the RF signal using a power amplifier before it is radiated across the air interface via antenna 826.

[0105] Antenna 826 may include multiple antenna elements, each of which converts electrical signals into radio waves to travel through the air and converts received radio waves back into electrical signals. These antenna elements may be arranged in one or more antenna panels. Antenna 826 may have omnidirectional, directional, or combinations thereof antenna panels to enable beamforming and multiple-input / multiple-output communication. Antenna 826 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. Antenna 826 may have one or more panels designed for one or more specific frequency bands.

[0106] User interface circuitry 816 includes various input / output (I / O) devices designed to enable a user to interact with user equipment 800. User interface circuitry 816 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, a headset, etc. Output device circuitry includes any physical or virtual means for displaying information or otherwise conveying information, such as sensor readings, actuator positions, or other similar information. Output device circuitry may include any number or combination of audio or visual displays, particularly including one or more simple visual outputs / indicators (e.g., binary status indicators such as light-emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as display devices or touchscreens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.), wherein the output of characters, graphics, multimedia objects, etc., is generated or produced by the operation of user equipment 800.

[0107] Sensor 820 may include devices, modules, or subsystems designed to detect events or changes in its environment and transmit information about the detected events (sensor data) to other devices, modules, subsystems, etc. Examples of such sensors include, in particular,: inertial measurement units including accelerometers; gyroscopes; or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEM) including: triaxial accelerometers; triaxial gyroscopes; or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless aperture sensors); light detection and ranging sensors; proximity sensors (e.g., infrared radiation detectors, etc.); depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other similar audio capture devices; etc.

[0108] The driving circuit 822 may include software and hardware elements for controlling a specific device embedded in, attached to, or otherwise communicatively coupled to the user equipment 800. The driving circuit 822 may include various drivers that allow other components to interact with or control various input / output (I / O) devices that may exist within or be connected to the user equipment 900. For example, the driving circuit 822 may include: a display driver for controlling and allowing access to a display device; a touchscreen driver for controlling and allowing access to a touchscreen interface; a sensor driver for acquiring sensor readings of a sensor 820 and controlling and allowing access to the sensor 820; a driver for acquiring actuator positions of electromechanical components or controlling and allowing access to electromechanical components; a camera driver for controlling and allowing access to an embedded image capture device; and / or an audio driver for controlling and allowing access to one or more audio devices.

[0109] The PMIC 824 manages the power supplied to various components of the user equipment 900. Specifically, relative to the processor 804, the PMIC 824 controls power selection, voltage scaling, battery charging, or DC-DC conversion.

[0110] In some implementations, the PMIC 824 can control or otherwise become part of various power-saving mechanisms of the user equipment 800. For example, if the platform user equipment is in the RRC_Connected state, in which the platform remains connected to the RAN node because it expects to receive traffic soon, after a period of inactivity, the platform can enter a state known as Discontinuous Receive Mode (DRX). During this state, the user equipment 800 can power down for short intervals to save power. If there is no data traffic activity during an extended period, the user equipment 800 can transition to the RRC_Idle state, in which the device disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The user equipment 800 enters a very low-power state and performs paging, in which the device periodically wakes up again to listen to the network and then power down again. The user equipment 800 may not receive data in this state; to receive data, the user equipment must transition back to the RRC_Connected state. Additional power-saving modes can allow the device to be unable to use the network for longer than the paging interval (ranging from a few seconds to several hours). During this period, the device is completely unable to connect to the network and can be completely powered off. Any data sent during this time will result in significant latency, which is assumed to be acceptable.

[0111] Battery 828 can power user equipment 800, but in some examples, user equipment 800 may be installed and / or deployed in a fixed location and may have a power source coupled to the power grid. Battery 828 may be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, battery 828 may be a typical lead-acid automotive battery.

[0112] The foregoing describes exemplary methods, computer-readable media, and systems for providing various technologies for pairing proximity devices. Some or all of these systems, media, and methods may, but do not necessarily, be at least partially constituted by architectures and processes (such as those described above). Figures 1 to 8 The above-described techniques can be implemented using the architectures and processes shown herein. It should be understood that any of the techniques described can be used within any type of application operating on a user device. For illustrative purposes, numerous specific configurations and details have been presented to provide a thorough understanding of the examples. However, it will also be apparent to those skilled in the art that some examples can be implemented without these specific details. Furthermore, well-known features have sometimes been omitted or simplified to prevent confusion with the examples described herein.

[0113] Various implementation schemes can be implemented in a variety of operating environments. In some cases, the operating environment may include one or more user computers, peripheral devices, and / or host devices that can be used to operate any of many applications. Peripheral devices or host devices may include any of a number of general-purpose personal computers, such as desktop or laptop computers running standard operating systems, and cellular, wireless, and handheld devices running mobile software and capable of supporting multiple networking and instant messaging protocols. Such systems may also include multiple workstations running a variety of commercially available operating systems and any of other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and other devices capable of communicating via a network.

[0114] Most implementations utilize at least one network familiar to those skilled in the art to support communication using any of the various commercial protocols, such as TCP / IP, OSI, FTP, UPnP, NFS, CIFS, and AppleTalk. The network can be, for example, a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), the Internet, an intranet, an extranet, the public switched telephone network (PSTN), an infrared network, a wireless network, or any combination thereof.

[0115] The environment may include various data repositories and other storage media, as described above. These may reside in various locations, such as on storage media local to one or more computers or on storage media of any or all computers on a network (and / or reside within one or more computers). In a particular set of embodiments, information may reside in a storage area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing functions belonging to a computer, server, or other network device may be stored locally and / or remotely as needed. When the system includes computerized devices, each such device may include hardware elements electrically coupled via a bus, including, for example, at least one central processing unit (CPU), at least one input device (e.g., mouse, keyboard, controller, touchscreen, or keypad), and at least one output device (e.g., display device, printer, or speaker). Such systems may also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as RAM or ROM, as well as removable media devices, memory cards, flash memory cards, and so on.

[0116] Such devices may also include computer-readable storage medium readers, communication devices (e.g., modems, network interface cards (wireless or wired), infrared communication devices, etc.), and working memory as described above. Computer-readable storage medium readers may be connected to or configured to receive non-transitory computer-readable storage media representing remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information. Systems and various devices will also typically include multiple software applications, modules, services, or other elements residing within at least one working memory device, including operating systems and applications such as client applications or browsers. It should be understood that alternative embodiments may have many variations as described above. For example, custom hardware may also be used, and / or specific elements may be implemented in hardware, software (including portable software such as applets), or both. Furthermore, connections to other computing devices such as network input / output devices may be used.

[0117] Non-transitory storage media and computer-readable storage media used for containing code or portions thereof may include any suitable media known or used in the art (except transient media such as carrier waves), such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data, including RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, DVD or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other media that can be used to store the desired information and is accessible by system devices. Based on the disclosure and teachings provided herein, those skilled in the art will understand other ways and / or methods for implementing various embodiments. However, as stated above, computer-readable storage media do not include transient media such as carrier waves.

[0118] Other variations are within the scope of this disclosure. Therefore, although the disclosed technology is susceptible to various modifications and alternative constructions, certain exemplary embodiments are shown in the accompanying drawings and have been described in detail above. However, it should be understood that this disclosure is not intended to be limited to the specific forms disclosed, but rather is intended to cover all modifications, alternative constructions, and equivalents falling within the scope and spirit of this disclosure as defined by the appended claims.

[0119] In the context of describing the disclosed embodiments (particularly in the context of the claims below), the terms “a,” “an,” and “the,” as well as similar indicator words, shall be construed to cover both singular and plural forms unless otherwise stated or clearly contradicted by the context. Unless otherwise stated, the terms “comprising,” “having,” “including,” and “containing” shall be construed as open-ended terms (i.e., meaning “including but not limited to”). The term “connected” is construed as including, attaching, or joining together, even if there is interference. The phrase “based on” shall be understood as open-ended and not in any way limiting, and is intended to be construed or otherwise understood as “at least partially based on” where appropriate. Unless otherwise stated herein, the description of numerical ranges herein is intended merely as a simple way of referring separately to each individual value falling within that range, and each individual value is incorporated into the specification as if separately referenced herein. All methods described herein can be performed in any suitable order unless otherwise stated or clearly contradicted by the context. Unless otherwise stated, the use of any and all examples or exemplary language (e.g., “such as”) provided herein is intended merely to better illustrate embodiments of this disclosure and does not limit the scope of this disclosure. No language in the specification should be construed as indicating that any unstated element is essential to the practice of this disclosure.

[0120] Unless otherwise specifically stated, parse languages ​​such as the phrase “at least one of X, Y, or Z” are understood in the context to generally refer to items, terms, etc., which can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such parse languages ​​are generally not intended and should not imply that certain embodiments require the existence of at least one of X, at least one of Y, or at least one of Z. Additionally, unless otherwise specifically stated, union languages ​​such as the phrase “at least one of X, Y, and Z” should also be understood to mean X, Y, Z, or any combination thereof, including “X, Y, and / or Z”.

[0121] This disclosure assumes that entities responsible for collecting, analyzing, disclosing, transmitting, storing, or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, such entities should implement and adhere to privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy and security of personal information data. Such policies should be easily accessible to users and should be updated as data collection and / or use change. Personal information from users should be collected for the entity's lawful and reasonable purposes and not shared or sold outside of these lawful uses. Furthermore, such collection / sharing should be conducted only after obtaining informed consent from users. In addition, such entities should consider taking any necessary steps to protect and safeguard access to such personal information data and ensure that others with access to such personal information data comply with their privacy policies and processes. Additionally, such entities may be subject to third-party assessments to demonstrate their compliance with widely accepted privacy policies and practices. Furthermore, policies and practices should be adapted to the specific types of personal information data collected and / or accessed, and to applicable laws and standards, including specific considerations regarding jurisdiction. Therefore, different privacy practices should be maintained for different types of personal information data in each country.

[0122] Regardless of the foregoing, this disclosure also contemplates implementation schemes for users to selectively block the use or access to personal information data. That is, this disclosure contemplates providing hardware and / or software components to prevent or block access to such personal information data. For example, the technology of this invention can be configured to allow users to opt-in or opt-out at any time during or after registration for the service to participate in the collection of personal information data (or a portion thereof). As another example, users can choose not to provide personal information data for the purpose of receiving proactive reminders and / or notifications. Furthermore, users can choose to limit the duration of retention of personal information or completely prohibit proactive reminders and / or notifications. In addition to providing "opt-in" and "opt-out" options, this disclosure envisions providing notifications related to access to or use of personal information. For example, users can be notified when downloading an application that their personal information data will be accessed, and then reminded again just before the application accesses the personal information data.

[0123] Furthermore, the purpose of this disclosure is to manage and process personal information data to minimize the risk of unintentional or unauthorized access or use. Once data is no longer needed, this risk can be minimized by limiting data collection and deleting data. Additionally, and where applicable, data deidentification can be used to protect user privacy. Deidentification can be facilitated, where appropriate, by removing specific identifiers (e.g., date of birth, etc.), controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than the address level), controlling how data is stored (e.g., aggregating data among users), and / or other methods.

[0124] Therefore, in light of the broad coverage of this disclosure of using personal information data to implement one or more of the various disclosed embodiments, this disclosure also contemplates that various embodiments can also be implemented without accessing such personal information data. That is, various embodiments of the present invention will not be unable to function properly due to the absence of all or part of such personal information data.

[0125] Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive. However, it will be apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of this disclosure as set forth in the claims.

[0126] Other variations are within the scope of this disclosure. Therefore, although the disclosed technology is susceptible to various modifications and alternative constructions, certain exemplary embodiments are shown in the accompanying drawings and have been described in detail above. However, it should be understood that this disclosure is not intended to be limited to the specific forms disclosed, but rather is intended to cover all modifications, alternative constructions, and equivalents falling within the scope and spirit of this disclosure as defined by the appended claims.

[0127] This document describes exemplary embodiments of the present disclosure, including the best mode known to the inventors for carrying out the present disclosure. After reading the foregoing description, variations of those exemplary embodiments will become apparent to those skilled in the art. The inventors expect those skilled in the art to appropriately employ such variations, and the inventors intend to practice the present disclosure in ways different from those specifically described herein. Therefore, this disclosure includes all modifications and equivalents of the subject matter recited in the appended claims, as permitted by applicable law. Furthermore, unless otherwise indicated herein or clearly contradicted by the context, this disclosure encompasses any combination of all possible variations of the foregoing elements.

[0128] All references cited in this article, including publications, patent applications and patents, are incorporated herein by reference, as each reference is individually and specifically indicated to be incorporated by reference and elaborated in the entire text.

Claims

1. A computer-implemented method, comprising: The communication device obtains protocol metadata corresponding to one or more communication protocols, each of which is individually associated with a corresponding activity identifier; Receive a request, including the activity identifier from the corresponding activity identifier, via a communication channel; The communication device obtains the corresponding protocol metadata associated with the activity identifier received in the request; Identify one or more operations corresponding to at least one of the following from the corresponding protocol metadata associated with the activity identifier: an action or a threshold; and The communication device performs one or more operations, at least in part, based on the identified action or the identified threshold. The protocol metadata corresponding to the one or more communication protocols is obtained from an independent communication device.

2. The computer-implemented method according to claim 1, wherein the communication channel comprises a high-speed bidirectional serial bus.

3. The computer-implemented method according to claim 1 or 2 further includes: Receive an additional request via the communication channel, including a second activity identifier, wherein the activity identifier is a first activity identifier and the first activity identifier is different from the second activity identifier; The communication device obtains additional protocol metadata corresponding to the second activity identifier received in the additional request; as well as A first priority associated with a first activity corresponding to the first activity identifier and a second priority associated with a second activity corresponding to the second activity identifier are determined from the priority mapping, wherein the identification of the one or more operations is based at least in part on the protocol metadata, the additional protocol metadata, the first priority, and the second priority.

4. The computer-implemented method according to claim 1 or 2, wherein the protocol metadata includes at least one of the following: periodic values, retry policies, one or more operating bands, one or more coexistence bands, or one or more reactive policies.

5. The computer-implemented method of claim 4, wherein the reactive policy in the one or more reactive policies defines one or more corresponding operations to be performed in response to receiving a corresponding request including a specific activity identifier corresponding to the protocol metadata.

6. The computer-implemented method according to any one of claims 1, 2 and 5, wherein the communication device is a communication chip configured to transmit and receive data according to a specific set of communication protocols.

7. The computer-implemented method according to any one of claims 1, 2 and 5, wherein the request is received from an independent communication device, the communication device and the independent communication device being part of a user equipment.

8. A communication device, comprising: One or more processors; and The memory stores non-transitory computer-executable instructions that, when executed by the one or more processors, cause the communication device to: Obtain protocol metadata corresponding to one or more communication protocols, each of which is individually associated with a corresponding activity identifier; Receive a request including the activity identifier from the corresponding activity identifier via a communication channel connected to the communication device; Obtain the corresponding protocol metadata associated with the activity identifier received in the request; Identify one or more operations corresponding to at least one of the following from the corresponding protocol metadata associated with the activity identifier: an action or a threshold; and The communication device performs one or more operations, at least in part, based on the identified action or the identified threshold. The protocol metadata corresponding to the one or more communication protocols is obtained from an independent communication device.

9. The communication device according to claim 8, wherein the communication device is one of a plurality of communication devices located at a user equipment.

10. The communication device according to claim 8 or 9, wherein executing the computer-executable instructions further causes the communication device to: Identify one or more subsequent operations corresponding to at least one of the following from the protocol metadata corresponding to the activity identifier: additional action or additional threshold; Set a timer associated with the one or more subsequent operations; and The communication device performs one or more subsequent operations, at least in part, based on the expiration of the timer.

11. The communication device of claim 8 or 9, wherein the protocol metadata identifies the action corresponding to the activity identifier, and wherein the action includes adjusting the power settings of the communication device.

12. The communication device of claim 8 or 9, wherein the protocol metadata identifies the action corresponding to the activity identifier, and wherein the action includes triggering the deactivation of a secondary cell configured to transmit using unlicensed spectrum.

13. A non-transitory computer-readable storage medium having computer-executable instructions stored thereon, the computer-executable instructions, when executed by a processor of a computing device, causing the processor to perform operations including: Obtain protocol metadata corresponding to multiple communication protocols, each of which is individually associated with a corresponding activity identifier; Receive a request, including the activity identifier from the corresponding activity identifier, via a communication channel; Obtain the corresponding protocol metadata associated with the activity identifier received in the request; Identify one or more operations corresponding to at least one of the following from the corresponding protocol metadata associated with the activity identifier: an action or a threshold; and The one or more operations are performed at least in part based on the identified action or the identified threshold. The protocol metadata corresponding to the plurality of communication protocols is obtained from independent communication devices.

14. The non-transitory computer-readable storage medium of claim 13, wherein the protocol metadata identification threshold is specified, and wherein the threshold specifies an acceptable level of throughput degradation.

15. The non-transitory computer-readable storage medium of claim 13 or 14, wherein the protocol metadata identifies a plurality of actions, each of the plurality of actions corresponding to either a first transmission attempt or a subsequent transmission attempt.

16. The non-transitory computer-readable storage medium of claim 13 or 14, wherein the computing device is a component of a user equipment, and wherein executing the computer-executable instructions further causes the computing device to receive the protocol metadata from a second component of the user equipment.

17. The non-transitory computer-readable storage medium of claim 13 or 14, wherein the computing device is a first computing device communicating with a second computing device, wherein the first computing device stores the protocol metadata, the protocol metadata corresponding to the second computing device.

18. The non-transitory computer-readable storage medium of claim 17, wherein the second computing device stores additional protocol metadata corresponding to the first computing device.

19. The non-transitory computer-readable storage medium of claim 17, wherein the first computing device and the second computing device operate within the same spectrum.

Images