Managing coexistence of communication protocols in user equipment
By implementing arbitration mechanisms and time window management in user equipment, the communication quality and user experience issues when multiple communication protocols coexist are resolved, ensuring efficient resource utilization and prioritizing high-priority sessions, thereby improving the communication quality and user experience of electronic devices.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-29
- Publication Date
- 2026-03-24
AI Technical Summary
In electronic devices, when multiple communication protocols (such as IEEE 802.11, Bluetooth, and IEEE 802.15.4) coexist on the same frequency band, it leads to a decline in communication quality and a poor user experience. Existing technologies struggle to effectively manage and prioritize each communication session.
By implementing an arbitration-based mechanism in user equipment, high-priority communication sessions are identified and executed first, while low-priority sessions are postponed. Coordinated Sampling Listen (CSL) and time windows are used to manage the interaction of different communication protocols, ensuring efficient resource utilization.
It achieves minimal interruption of high-priority communication sessions in environments with multiple communication protocols coexisting, while improving communication quality and user experience.
Smart Images

Figure CN121729975A_ABST
Abstract
Description
Cross-reference to related applications
[0001] This application claims priority to U.S. Patent Application No. 18 / 805,449, filed August 14, 2024, and U.S. Provisional Patent Application No. 63 / 536,031, filed August 31, 2023, the entire contents of which are incorporated herein by reference. Background Technology
[0002] Many electronic devices communicate with each other using wireless local area networks (WLANs)—such as wireless LANs based on communication protocols compatible with Institute of Electrical and Electronics Engineers (IEEE) standards, such as the IEEE 802.11 standard (also known as "Wi-Fi"). A WLAN typically includes an access point that provides access to another network, such as the Internet, for one or more stations (STAs). The IEEE 802.11 standard has several generations, including 802.11ax (Wi-Fi 6) and 802.11be (Wi-Fi 7). IEEE 802.11 communication can utilize the 2.4 GHz band or other bands (e.g., 5 GHz).
[0003] IEEE 802.11 is a packet-based protocol. According to this protocol, a transmitter (e.g., an access point (AP)) sends encapsulated control information or user data (e.g., Protocol Data Units (PDUs)) in a Physical Layer Convergence Protocol (PLCP). A PLCPPDU (PPDU) includes a preamble, data fields, and other fields. After generating the PPDU, the access point can transmit it to a site connected to the access point. Communication from the access point to a site is called a downlink, while communication from a site to the access point is called an uplink.
[0004] In addition to IEEE 802.11, some electronic devices typically support other technologies. These technologies include Bluetooth and IEEE 802.15.4 (often implemented and referred to as "Thread"). Bluetooth and IEEE 802.15.4 communication can also utilize the 2.4 GHz frequency band. Summary of the Invention
[0005] This disclosure relates to the management of multiple coexisting communication protocols in user equipment.
[0006] According to one aspect of this disclosure, a method is provided. The method includes attaching a user equipment to a wireless network via a router using a first communication protocol. The method includes determining a first time window and a second time window based on information about a second session using a second communication protocol. The method includes determining that the first session using the first communication protocol will be executed within the first time window. The method includes performing a first arbitration between the first session and the second session. The method includes determining, based on the first arbitration, that the first session has a higher priority than the second session within the second time window. The method includes performing a second arbitration between the first session and a third session using a third communication protocol. The method includes determining, based on the second arbitration, whether the first session should be executed within the second time window.
[0007] In some implementations, the user equipment is configured with a Coordinated Sample Listening (CSL). The method also includes controlling the CSL timer based on the first time window and the second time window.
[0008] In some implementations, the user equipment is not configured with a CSL. Determining the first and second time windows includes: obtaining information about the second session from the radio manager; and using firmware of the first communication protocol to determine the first and second time windows.
[0009] In some specific implementations, determining that the first session is to be executed in the first time window includes at least one of the following: determining that the user equipment is configured with CSL, determining that the third session is operating on the first frequency band, or determining that the first session has a higher priority than the second session in the first time window.
[0010] In some specific implementations, determining whether to execute the first session in the second time window includes: determining the criticality level of the third session; and in response to determining that the third session is critical, determining that the first session should not be executed in the second time window.
[0011] In some specific implementations, determining whether to execute the first session in the second time window further includes: determining the criticality level of the first session in response to determining that the third session is not critical; and performing at least one of the following: determining that the first session is not executed in the second time window in response to determining that the third session is not critical and the first session is not critical; and determining that the first session is executed in the second time window in response to determining that the third session is not critical and the first session is critical.
[0012] In some specific implementations, determining the criticality level of the first session includes determining the identifier of the first session.
[0013] In some implementations, the method also includes transmitting a request from the firmware of the first session to the firmware of the third session to execute the first session in a second time window.
[0014] In some implementations, the method also includes transmitting an indication from the firmware of the third session to the access point of the third session that a power reduction has occurred in the first time window.
[0015] In some specific implementations, the method further includes: performing a third arbitration between a fourth session using a first communication protocol and a fifth session using a second communication protocol prior to attachment; executing the fourth session in response to determining that the fourth session has a higher priority than the fifth session; and executing the fifth session in response to determining that the fifth session has a higher priority than the fourth session.
[0016] In some specific implementations, the router supports both the first and third communication protocols.
[0017] In some implementations, the router is coupled to a synchronous sleep terminal device.
[0018] In some implementations, user equipment is indirectly connected to the wireless network via a router.
[0019] In some implementations, the wireless network includes one or more sleep terminal devices that support a first communication protocol.
[0020] In some specific implementations, the first communication protocol includes the Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard, the second communication protocol includes the Bluetooth standard, and the third communication protocol includes the Wi-Fi standard.
[0021] According to one aspect of this disclosure, a method is provided. The method includes establishing a link between a user equipment and a peer equipment using a first communication protocol. The method includes determining a first time window and a second time window based on information about a second session using a second communication protocol. The method includes determining that the first session will be executed via the link within the first time window. The method includes performing a first arbitration between the first session and the second session. The method includes determining, based on the first arbitration, that the first session has a higher priority than the second session within the second time window. The method includes performing a second arbitration between the first session and a third session using a third communication protocol. The method includes determining, based on the second arbitration, whether to execute the first session within the second time window. In some embodiments, the peer equipment includes a synchronous sleep terminal device.
[0022] The operations described above can be implemented as program instructions stored in a non-transitory computer-readable medium. The user equipment may have one or more processors that execute the program instructions to perform one or more operations.
[0023] Details of one or more specific embodiments of these systems and methods are set forth in the accompanying drawings and the following description. Other features, objects, and advantages of these systems and methods will be apparent from the specification, the drawings, and the claims. Attached Figure Description
[0024] Figure 1 A block diagram illustrating an example of an electronic device that performs wireless communication according to some specific implementations is shown.
[0025] Figures 2A to 2C Each example illustrates the topology of a Thread communication network based on some specific implementations.
[0026] Figure 3 An example is given of the architecture of multiple coexistence protocols based on some specific implementations.
[0027] Figures 4A to 4B Each example illustrates a two-stage arbitration process based on specific implementations.
[0028] Figure 5A and Figure 5B Each is illustrated with example timing diagrams for managing coexistence of the Thread and Wi-Fi protocols according to some specific implementations.
[0029] Figure 6A and Figure 6B Each example scenario illustrates a coexisting communication session based on specific implementations.
[0030] Figure 7 An example arbitration process for coexisting Wi-Fi and Thread communication sessions on a user device is illustrated according to some specific implementations.
[0031] Figure 8 A flowchart illustrating the arbitration process for coexisting Wi-Fi and Thread communication sessions, based on some specific implementations, is provided.
[0032] Figure 9A and Figure 9B Each example is illustrated with a flowchart based on a specific implementation.
[0033] Figure 10 A block diagram of an example electronic device according to some specific implementations is shown. Detailed Implementation
[0034] Today, an increasing number of electronic devices support all IEEE 802.11, Bluetooth, and IEEE 802.15.4 technologies for various applications. For example, a user might wear wireless headphones paired with their mobile device via Bluetooth. The user could use Wi-Fi to access websites and use the headphones to listen to music from those websites. Simultaneously, the user could use their mobile device to control their door locks or curtains using Thread. These activities can occur at roughly the same time using the same frequency resources. Therefore, managing the coexistence of multiple communication sessions is desirable to improve communication quality and user experience.
[0035] This disclosure provides techniques for addressing these technical challenges. As described in detail below, specific embodiments of this disclosure provide a user equipment with one or more arbitration-based mechanisms to determine whether to execute a communication session. By taking various factors into account, one or more arbitration-based mechanisms minimize disruption to high-priority communication sessions while allowing low-priority communication sessions to be postponed. Therefore, specific embodiments of this disclosure balance communication demands from competing communication sessions and allow for efficient use of communication resources to perform various tasks.
[0036] In the following description, Wi-Fi is used as a representative of IEEE 802.11, and Thread is used as a representative of IEEE 802.15.4. Furthermore, although the specific implementations described below are primarily set in the context of the coexistence of IEEE 802.11, Bluetooth, and IEEE 802.15.4, this disclosure is not limited to these three technologies. In some specific implementations, the coexistence of different technologies is envisioned.
[0037] Figure 1 A block diagram 100 illustrates an example of an electronic device performing wireless communication according to some specific implementation. It is noteworthy that one or more electronic devices 110 (such as a smartphone, laptop computer, notebook computer, tablet computer, or other such electronic device) and access point 112 can wirelessly communicate in a WLAN using the IEEE 802.11 communication protocol. Therefore, electronic device 110 may be associated with or have a connection to access point 112. For example, electronic device 110 and access point 112 can wirelessly communicate by: detecting each other by scanning a wireless channel, sending and receiving beacons or beacon frames on a wireless channel, establishing a connection (e.g., by sending a connection request), and / or sending and receiving packets or frames (packets or frames may include requests and / or additional information such as data as a payload). It should be noted that access point 112 may provide access to a network such as the Internet via the Ethernet protocol and may be a physical access point implemented on a computer or electronic device or a virtual or "software" access point. In this specification, electronic device 110 is sometimes referred to as a "receiving electronic device" or a "receiving site".
[0038] Despite providing Figure 1 The environment shown is for illustrative purposes only, but in alternative embodiments, different numbers and / or types of electronic devices may be present. For example, some embodiments may include more or fewer electronic devices. Also, in some embodiments, different electronic devices may send and / or receive packets or frames. In some embodiments, multiple links may be used during communication between electronic devices 110.
[0039] See below for reference Figure 10 Furthermore, electronic device 110 and access point 112 may include subsystems such as a networking subsystem, a memory subsystem, and a processor subsystem. Additionally, electronic device 110 and access point 112 may include a radio component 114 within the networking subsystem. More generally, electronic device 110 and access point 112 may include any electronic device with a networking subsystem (or may be included within any electronic device with a networking subsystem) that enables electronic device 110 and access point 112 to communicate wirelessly with another electronic device. This may include transmitting beacons on a wireless channel to enable the electronic devices to make initial contact with or detect each other, followed by exchanging subsequent data / management frames (such as connection requests) to establish a connection, configure security options, and send and receive packets or frames via the connection.
[0040] like Figure 1 As shown, wireless signal 116 is transmitted by one or more radio components 114-1 and 114-2 in electronic device 110-1 and access point 112, respectively. For example, as previously mentioned, electronic device 110-1 and access point 112 can exchange packets or frames using Wi-Fi communication protocols in a WLAN. Furthermore, one or more radio components 114-1 can receive wireless signal 116 transmitted by one or more radio components 114-2 via one or more links between electronic device 110-1 and access point 112. Alternatively, one or more radio components 114-1 can transmit wireless signal 116 received by one or more radio components 114-2.
[0041] In some implementations, the wireless signal 116 is transmitted by one or more radio components 114 in electronic device 110 and access point 112, respectively. For example, one or more radio components 114-1 and 114-3 may receive the wireless signal 116 transmitted by one or more radio components 114-2 via one or more links between electronic device 110-1 and 110-2 and access point 112.
[0042] In some specific implementations, access point 112 can group electronic devices 110 into a target site set. The concept of a target site set originates from downlink multi-user transmission, where access point 112 can use Orthogonal Frequency Division Multiple Access (OFDMA) or Multi-User Multiple-Input Multiple-Output (MU-MIMO) to simultaneously transmit to multiple sites within a single PPDU. Here, the target site set is a collection of sites that can be simultaneously served by access point 112. The sites in the set do not need to share the same PHY parameters, such as MCS and the number of flows.
[0043] In some implementations, access point 112 may use multi-user (MU) technologies, such as MU multiple-input multiple-output (MU-MIMO), to communicate simultaneously with multiple electronic devices 110. In some examples, access point 112 uses frequency multiplexing to communicate with electronic devices 110, such that access point 112 allocates a portion of the total bandwidth to each of these electronic devices. For example, to communicate simultaneously with four electronic devices over an 80 MHz bandwidth, access point 112 transmits MU-PPDUs over an 80 MHz bandwidth. MU-PPDUs include sub-PPDUs for each of the four electronic devices, where each sub-PPDU (or sub-channel) is allocated 20 MHz. Access point 112 may use MU-PPDUs to communicate with devices in the same target set, devices in different target sets, or a combination of both.
[0044] In some implementations, access point 112 and one or more electronic devices may be compatible with IEEE 802.11 standards (e.g., IEEE 802.11ax) including triggered channel access. In 802.11ax, Orthogonal Frequency Division Multiple Access (OFDMA) is used to enable simultaneous communication between access point 112 and multiple electronic devices. OFDMA divides the available physical spectrum into multiple orthogonal sub-channels or resource elements (RUs) that can be allocated to different electronic devices (users). According to this standard, access point 112 coordinates multi-user OFDMA by broadcasting a trigger frame, which also allocates an RU to each participating electronic device. Each electronic device responds to the trigger frame by sending a PPDU to access point 112 using its allocated RU. The trigger frame may also include power control information. Access point 112 may instruct all electronic devices 110 when to start and stop transmitting. It should be noted that access point 112 and electronic devices 110 may communicate with one or more legacy electronic devices that are not compatible with the IEEE 802.11 standard (i.e., do not use multi-user triggered channel access).
[0045] In some implementations, processing packets or frames in one of the electronic devices 110, access point 112, or a combination of both includes: receiving a wireless signal 116 that encodes the packets or frames; decoding / extracting packets or frames from the received wireless signal 116 to obtain packets or frames; and processing packets or frames to determine information contained in the packets or frames (such as data in a payload).
[0046] As previously discussed, one or more electronic devices in electronic device 110 and access point 112 can communicate with each other. Notably, access point 112 can transmit PPDUs that include a preamble and a data field. In some implementations, access point 112 can be configured to use cascaded PPDUs (C-PPDUs), for example, for low-latency communication with a receiver site. A C-PPDU comprises multiple component PPDUs, each including a preamble and a data payload. As described in more detail below, a C-PPDU comprises multiple component PPDUs. The first component PPDU is preceded by a first preamble, referred to as the “complete preamble.” Each of the remaining component PPDUs in the C-PPDU is preceded by a corresponding preamble shorter than the first preamble. In some implementations, access point 112 may not perform contention or receive block acknowledgment (BA) before transmitting the multiple component PPDUs.
[0047] Figures 2A to 2C Each example illustrates a topology of Thread communication networks 200A to 200C according to some specific implementations. Each of the communication networks 200A to 200C may have Figure 1 One or more electronic devices 110, which also support IEEE 802.11 and / or Bluetooth communication protocols.
[0048] In communication network 200A, multiple user equipments 201 establish communication sessions with Thread router 202. Each user equipment 202 can exchange Thread packets with one or more Thread Sleep Terminal Devices (SEDs) 203 via Thread router 202. By establishing a communication session with Thread router 202, each user equipment 201 is attached to communication network 200A as, for example, a Synchronous SED (SSED). For example, a Thread-enabled smartphone can be used as a remote control for home appliances (e.g., lights). When a user wants to adjust the lights, the user can activate the Thread communication session and control one or more lights acting as SEDs 203 via Thread router 202. In some implementations, Thread router 202 may be the same as, or included within, a Wi-Fi router connected to one or more devices via a Wi-Fi link.
[0049] In communication network 200B, each user equipment (UE) in user equipment 201 communicates with a peer device (such as its corresponding ThreadSSED 204). Unlike communication network 200A, where UEs can exchange Thread services with multiple Thread SSEDs, each UE 201 in communication network 200B establishes a one-to-one link to its corresponding Thread SSED 204. In this topology, each UE 201 can act as a Thread SSED or as a sleep router that is activated only when triggered. For example, a UE can only be activated when it is within the coverage area of its corresponding Thread SSED 204 (such as within a certain distance from the user's home).
[0050] In the communication network 200C, due to reasons such as network security settings, distance, and physical obstacles, user equipment 201 cannot directly establish a Thread link to Thread router (or border router) 202. However, user equipment 201 can establish a Thread link to Thread SSED 204, and indirectly establish a Thread link to router (or border router) 202 via Thread SSED 204. Therefore, user equipment 201 can still be attached to the Thread network including Thread SED 203. As an example scenario, a user holding user equipment 201 outside the user's home may not be able to directly attach to the user's home Thread network via Thread router 202. However, via the user's Thread-capable door lock, user equipment 201 can indirectly attach to the home Thread network and establish a communication session with Thread SED 203 (such as a light) within the home Thread network.
[0051] Figure 3 A network architecture 300 based on several specific implementations of multiple coexistence protocols is illustrated. Network architecture 300 can be derived from... Figure 1 Electronic devices 110 or Figures 2A to 2C User equipment 201 is adopted.
[0052] The network architecture 300 comprises at least three layers. The physical (PHY) layer is at the bottom. The data link layer or media access control (MAC) layer is above the PHY layer. Furthermore, the network layer is above the MAC layer.
[0053] At the PHY layer, Bluetooth and IEEE 802.15.4 can use the same PHY layer module (e.g., hardware and software) to send and receive physical radio signals on a time-division duplex (TDD) basis, depending on the priority level of the Bluetooth and IEEE 802.15.4 communication session. Furthermore, Wi-Fi can have its own PHY layer module communicatively coupled to the PHY layer module shared by Bluetooth and IEEE 802.15.4. Through the Global Coexistence Interface (GCI), the Wi-Fi PHY module and the Bluetooth / IEEE 802.15.4 PHY module can exchange information about coexistence management. For example, the Wi-Fi PHY module can receive communication requests from the Bluetooth / IEEE 802.15.4 PHY module and determine whether to grant the request. In some implementations, the Bluetooth / IEEE 802.15.4 PHY module only communicates under the Bluetooth or IEEE 802.15.4 protocol in the corresponding communication session when the Wi-Fi PHY module grants permission. The Wi-Fi PHY module can apply the same strategy to Bluetooth and IEEE 802.15.4 communication when determining whether to grant the request.
[0054] Each of the Bluetooth, IEEE 802.15.4, and Wi-Fi protocols may have a corresponding data link layer module or MAC module. The data link layer module or MAC module may include functions for processing data or control signals according to the corresponding protocol. Bluetooth and Wi-Fi protocols may also have corresponding network layer modules, which may include a set of network functions specified by the corresponding protocol. IEEE 802.15.4 may have one or more network layer modules, such as Thread modules and Zigbee modules, both of which are standards based on the IEEE 802.15.4 protocol.
[0055] Figures 4A to 4B Each example illustrates a two-stage arbitration process, 400A, and 400B, based on specific implementation examples. Processes 400A and 400B can be implemented in... Figure 1 Electronic devices 110 or Figures 2A to 2C The user equipment 201 executes between or within function blocks or structure blocks.
[0056] Process 400A can be performed by a user device having a wireless manager 401, a Bluetooth host 402, a Thread host 403, firmware 404 shared by Bluetooth and Thread, a Wi-Fi host (also known as a Wi-Fi manager) 405, and Wi-Fi firmware 406. Within these blocks, the wireless manager 401 can obtain information about Bluetooth communication activity from the Bluetooth host 402 and control the operation of the Thread host 403.
[0057] At operation 1, the Bluetooth host 402 (e.g., from the wireless manager 401) obtains priority information about the Thread task and transmits this priority information to the Bluetooth and Thread firmware 404. Priority information, which can be formatted as a table, can indicate the priority level of different types of Thread services. For example, a Thread service controlling the locking / unlocking of a door may have a higher priority than a Thread service controlling the opening / closing of curtains. The Bluetooth host 402 can obtain the priority information during user equipment initialization.
[0058] At operation 2, the Thread host 403 selects a priority level relative to Bluetooth activity based on the type of Thread service. The Thread host 403 then passes the priority level information to the Bluetooth and Thread firmware 404. The Thread host 403 can obtain the priority level at runtime (e.g., when there is active Bluetooth and Thread service to and from the user device).
[0059] At operation 3, Bluetooth and Thread firmware 404 perform arbitration based on the priority levels of the requested Bluetooth communication session and the requested Thread communication session. For example, if the Thread communication session has a higher priority than the Bluetooth communication session, firmware 404 can determine that the Thread communication session is allowed to execute first, and the Bluetooth communication session is only allowed to execute if the Bluetooth communication session does not interfere with the higher-priority Thread communication session.
[0060] At operation 4, if it is determined that the Thread communication session has a higher priority than Bluetooth, the Thread communication session requests the Wi-Fi firmware 406. For example, even if Bluetooth and Thread firmware 404 allow the Thread communication session to proceed, the Wi-Fi firmware 406 may determine that the Wi-Fi service is critical or has a higher priority than the requested Thread service. In this case, the Wi-Fi firmware 406 rejects the request for the Thread communication session. The Wi-Fi firmware 406 can obtain information related to the Wi-Fi service from the Wi-Fi host 405.
[0061] The process moves to process 400B, which can be performed by a user device having similarly defined blocks 401 to 406 as described in reference process 400A. The user device may additionally have a Thread manager 407 that stores application-related information about Thread services. For example, the Thread manager 407 could be the hub of a Thread home network that wirelessly connects appliances, door locks, curtains, and other devices.
[0062] At operation 5, the Thread host 403 obtains information about the load of the current Bluetooth communication session from the wireless manager 401. The Thread host 403 also obtains application-related information about the Thread service from the Thread manager 407.
[0063] At operation 6 (exemplified as one of 6A and 6B), a first time window and a second time window are determined. Specifically, if Thread host 403 determines that the user equipment is configured with Thread version 1.2 or higher that supports Coordinated Sampling Listen (CSL), then at operation 6A, firmware 404 determines the length of the first time window and the length of the second time window as attributes of the CSL Information Element (IE). Conversely, if Thread host 403 determines that the user equipment is configured with Thread version 1.1 or earlier that does not support CSL, then at operation 6B, Thread host 403 determines the length of the first time window and the length of the second time window, and transmits the determined lengths to firmware 404.
[0064] The lengths of the first and second time windows can be represented by two parameters. In some implementations, the length of the first time window is represented by a value of x milliseconds (ms), while the length of the second time window is represented by a value of (yx) ms (i.e., y minus x). Here, the value of y can indicate the periodicity of the communication request made by firmware 404 to Wi-Fi firmware 406, while the value of x can indicate the duration of the y-period reserved for the requested communication. See later. Figures 5A to 8 Provide a detailed description of the parameters x and y.
[0065] The determinations at operations 6A and 6B can be based on information about the Bluetooth communication session, such as the load of the current Bluetooth communication session. For example, when the load is relatively high, x and y can be relatively small. Conversely, when the load is relatively high, x and y can be relatively large.
[0066] At operation 7, the Thread host 403 determines the criticality level of the requested Thread communication session and transmits the determined criticality level to the firmware 404. This determination may be based on, for example, application-related information about the Thread service. For instance, a Thread communication session may be considered critical when a user equipment transmits a Thread service to unlock the user's home door. On the other hand, a communication session may be considered non-critical when a user equipment receives a routine status update from one of many lights connected to the Thread home network. In some implementations, the criticality level may be represented by a session identifier (ID). For example, a critical Thread session may have a session ID equal to 0, while a non-critical Thread session may have a session ID greater than 0.
[0067] At operation 8, firmware 404 transmits parameters x and y to Wi-Fi firmware 406 via GCI. Knowing x and y, Wi-Fi firmware 406 can predict when a communication request for Thread communication will be made. By making this prediction, Wi-Fi firmware 406 can pre-plan its own Wi-Fi communication session by, for example, notifying the corresponding access point (AP) to reduce the data rate and switch to a power reduction mode, thus freeing up frequency resources for Thread communication sessions.
[0068] At operation 9, firmware 404 performs arbitration between the Bluetooth communication session and the Thread communication session based on their priority levels. Based on the arbitration, firmware 404 can schedule the Bluetooth communication session and / or the Thread communication session on a TDD basis.
[0069] At operation 10, if a Thread communication session is scheduled (e.g., due to a higher priority than a Bluetooth communication session), firmware 404 makes a request to Wi-Fi firmware 406. In some implementations, the request is made in each of the first and second time windows.
[0070] At operation 11, the Wi-Fi firmware 406 performs arbitration between the existing Wi-Fi communication session and the requested Thread communication session based on, for example, a criticality level. The Wi-Fi firmware 406 can grant or deny the requested Thread communication session based on the arbitration result. References will follow below. Figure 7 and Figure 8 Provides detailed information on arbitration between Wi-Fi and Thread.
[0071] It should be noted that operations 1 to 4 of process 400A and operations 5 to 8 of process 400B can be performed before the user equipment is attached to the Thread / Wi-Fi network or when the user equipment is not attached to the Thread / Wi-Fi network. For example, the user equipment can perform these operations to prepare for the upcoming attachment even when the user is outside the coverage area of the Thread / Wi-Fi network in the user's home. On the other hand, operations 9 to 11 can be performed after attachment.
[0072] More generally, in some implementations, the user equipment (UE) is not configured with a first and second time window before attachment. To manage the coexistence of Bluetooth, Thread, and Wi-Fi, the UE can arbitrate between Bluetooth and Thread based on priority levels. If Thread wins the arbitration, the UE can perform Thread communication on a best-effort basis without seeking permission from Wi-Fi. This mechanism does not significantly disrupt Wi-Fi because the UE is not yet attached to the Wi-Fi network.
[0073] Figure 5A Example timing diagram 500A for managing the coexistence of Thread and Wi-Fi protocols according to some specific implementations is illustrated. Timing diagram 500A can be applied to scenarios in which user equipment has been attached to the Thread / Wi-Fi network and has been configured with a first time window and a second time window (shown as time window 1 and time window 2 in timing diagram 500A) lasting for x ms and (yx) ms respectively.
[0074] As shown in timing diagram 500A, time windows 1 and 2 repeat periodically every y ms. Within time window 1, the Thread firmware asserts a request signal 501, which requests the Wi-Fi firmware to grant permission for the Thread communication session. Simultaneously, because the Wi-Fi firmware has already obtained information about time windows 1 and 2 (e.g., in...),... Figure 4B (The operation is performed at 8 points), so the Wi-Fi firmware can predict the assertion of the request signal 501 and grant the requested Thread communication session within the time window 1. That is, the Wi-Fi firmware can assert the grant signal 502 to accommodate the requested Thread communication session. To avoid interference, the Wi-Fi firmware can notify other connected Wi-Fi devices (such as Wi-Fi access points) to switch to power reduction mode before asserting the grant signal 502.
[0075] Continuing with timing diagram 500A, in time window 2, a request signal 501 from the Thread can be sent without notifying the Wi-Fi, and the Wi-Fi firmware can grant the requested Thread communication session on a best-effort basis (e.g., provided that the ongoing Wi-Fi communication session can accommodate the requested Thread communication session). Assuming that request signal 501 is first received by the Wi-Fi in time period P1, the Wi-Fi firmware may take time T. PM This notifies the Wi-Fi access point to switch to power reduction mode. In this case, during period P1, the assertion of the grant signal 502 is compared with the assertion of the request signal 501 with a lag of T. PM Because the Wi-Fi access point has already switched to power reduction mode in time period P1, the assertion of the grant signal 502 can occur approximately simultaneously with the assertion of the request signal 501 in a later time period (e.g., P2).
[0076] Figure 5B Another example timing diagram 500B for managing the coexistence of Thread and Wi-Fi protocols is illustrated according to some specific implementations. Timing diagram 500B can be applied to scenarios where user equipment has been attached to a Thread / Wi-Fi network and has been configured with a first time window and a second time window (shown as time window 1 and time window 2 in timing diagram 500B) lasting x ms and (yx) ms respectively. Unlike timing diagram 500A, the Wi-Fi firmware implementing timing diagram 500B can take into account the criticality level of the requested Thread communication session, as explained below.
[0077] Within time window 1, the Thread firmware asserts a request signal 501, which requests the Wi-Fi firmware to grant permission for the Thread communication session. Similar to timing diagram 500A, the Wi-Fi firmware can assert a permission signal 502 (shown as 502-1 and 502-2) to accommodate the requested Thread communication session, regardless of the criticality level of the requested Thread communication session.
[0078] Within time window 2, a request signal 501 from Thread can be issued without notifying Wi-Fi. If the Wi-Fi firmware determines that the requested Thread communication session is critical (e.g., has a higher priority than Wi-Fi), the Wi-Fi firmware can assert a grant signal 502-1 to allow the requested Thread communication session to continue on a best-effort basis, similar to the grant described in timing diagram 500A. However, if the Wi-Fi firmware determines that the requested Thread communication session is non-critical (e.g., has a lower priority than Wi-Fi), the Wi-Fi firmware can reject the request by not asserting the grant signal 502-2. Compared to the coexistence management mechanism in timing diagram 500A, the mechanism in timing diagram 500B better balances the communication needs between Wi-Fi and Thread, which can advantageously improve communication efficiency and user experience.
[0079] Figure 6A and Figure 6B Example scenarios 600A and 600B, respectively, illustrate coexisting communication sessions on user equipment according to some specific implementations. The thread communication session in scenario 600A can be at least partially critical (e.g., the user equipment controls a door lock), and the thread communication session in scenario 600B can be non-critical (e.g., the user equipment controls a light bulb among many light bulbs). For each scenario, three possible network topologies or roles of the user equipment are illustrated: i) similar to the illustration of communication network 200A, the user equipment communicates with SSED B via a thread router, where the user equipment acts as SSED A; ii) similar to the illustration of communication network 200B, the user equipment communicates with SSED B in a one-to-one link, where the user equipment acts as a sleep router; and iii) also similar to the illustration of communication network 200B, the user equipment communicates with SSED B in a one-to-one link, where the user equipment acts as SSED A.
[0080] In scenario 600A, under topology i), transmission (TX) from the user equipment to the Thread router can be critical, but reception (RX) from the Thread router at the user equipment can be non-critical. Therefore, a request to communicate on the TX link of a Thread communication session can be made and granted at any time during the first and second time windows, but a request to communicate on the RX link can be granted only during the first time window and, due to its non-criticality, can be rejected by the Wi-Fi firmware in the second time window (as described above with reference to timing diagram 502-2). Under ii), the user equipment acting as a sleep router can forward control signaling from another user equipment to control SSED B. Therefore, TX from the sleep router to SSED B can be non-critical, while RX from SSED B to the sleep router can be critical. Therefore, a request to communicate on the TX link can be granted only during the first time window, but a request to communicate on the RX link can be made and granted at any time during the first and second time windows. Under iii), both the TX and RX signals between the user equipment acting as SSED A and the corresponding linked SSED B can be non-critical. Therefore, requests to send or receive can be permitted only during the first time window.
[0081] In scenario 600A, under topologies i) and iii), both the TX and RX signals between the user equipment acting as SSED A and SSED B can be non-critical. Therefore, requests to send or receive can be permitted only during the first time window. Regarding topology ii), it is assumed that this topology is not suitable for scenario 600A where a user equipment acts as a sleep router to allow another user equipment to control the bulb SSED.
[0082] Figure 7 Example process 700 for managing coexisting Bluetooth, Wi-Fi, and Thread communication sessions is illustrated according to some specific implementations. Process 700 includes operations 702 that can be performed before a user device is attached to the Thread / Wi-Fi network and operations 704 to 718 that can be performed after the user device is attached to the Thread / Wi-Fi network. The user device performing process 700 can be similar to... Figure 1 Electronic devices 110 or Figures 2A to 2C User equipment 201.
[0083] At point 702, the user equipment manages the coexisting communication sessions before attaching. During this phase, the user equipment's CSL features are unavailable or inactive, and the user equipment does not determine a first or second time window. Instead, the user equipment performs arbitration between Bluetooth and Thread to schedule Bluetooth and Thread communication sessions on a TDD basis. The Wi-Fi firmware can grant scheduled Thread communication sessions on a best-effort basis. These operations can be similar to... Figure 4A Operations 1 to 4 in the text.
[0084] After the user equipment is attached to the Thread / Wi-Fi network, process 700 proceeds to 704 if the user equipment supports CSL, and to 706 if the user equipment does not support CSL. At 704, the Thread firmware configures the CSL IE with values x and y to indicate a first time window and a second time window. Values x and y can be determined based on Bluetooth (BT) load information. Then, at 708, during the first time window, given or assumed that the Thread communication session has a higher priority than the Bluetooth communication session, priority-based arbitration is performed between Bluetooth and Thread to determine which communication session should be executed during the second time window. In other words, the user equipment is configured to prefer the Thread communication session over the Bluetooth communication session during the first time window, but arbitrates between the two communication sessions based on priority during the second time window.
[0085] At 706, and unlike 704, the Thread host configures values x and y instead of the Thread firmware. Then, if the coexisting Wi-Fi communication session uses the 2.4GHz band (at 710), similar to 708, the user equipment is configured to prefer the Thread communication session over the Bluetooth communication session during a first time window, but arbitrate between the two communication sessions based on priority during a second time window. On the other hand, if the coexisting Wi-Fi communication session uses a different band than the 2.4GHz band (at 712), the Thread and Bluetooth communication sessions do not need to share the 2.4GHz band with Wi-Fi. Therefore, the user equipment is configured to arbitrate between the Thread and Bluetooth communication sessions based on priority, regardless of the time window.
[0086] Following any of steps 708, 710, and 712, the user equipment determines at 714 whether the Thread communication session is critical. If the Thread communication session is critical, at 718, the Wi-Fi firmware grants the Thread communication session in a first time window but rejects it in a second time window. Conversely, if the Thread communication session is critical, at 716, the Wi-Fi firmware grants the Thread communication session with high priority in the first time window and grants it on a best-effort basis in the second time window. The operations at 714 through 716 may involve similar procedures to those described in the reference above. Figure 5B The signals 501 and 502 are described as request and grant signals, respectively.
[0087] Figure 8 A flowchart illustrating an arbitration process 800 for coexisting Wi-Fi and Thread communication sessions, according to some specific implementations, is shown. Process 800 may be derived from a process similar to... Figure 1 Electronic devices 110 or Figures 2A to 2C User equipment 201 executes the procedure. Procedure 800 assumes that the user equipment supports CSL.
[0088] After arbitration performed by the Bluetooth and Thread firmware to determine that Thread has a higher priority than Bluetooth, the arbitration process 800 begins at 802. Therefore, from 804 to 836, another arbitration is performed by the Wi-Fi firmware between Thread and Wi-Fi.
[0089] At 804, the user equipment configures a first time window and a second time window. At 806, the user equipment determines whether its ongoing Wi-Fi communication session is operating on the 2.4 GHz band or a different band. At 808, the determined first and second time windows, along with information about the Wi-Fi band, are provided to the Wi-Fi firmware.
[0090] At 810, the Wi-Fi firmware determines whether the CSL timer is currently active. If the CSL timer is active, the Wi-Fi firmware stops the timer at 812.
[0091] At 814, the Wi-Fi firmware makes a determination based on the frequency band of the Wi-Fi communication session. If the Wi-Fi communication session operates on the 2.4 GHz band, the Wi-Fi firmware restarts the CSL timer according to the determined first and second time windows. If the Wi-Fi communication session does not operate on the 2.4 GHz band, the Wi-Fi firmware can continue with Thread / Wi-Fi arbitration regardless of the time window. In this case, the Wi-Fi firmware does not need to restart the CSL timer and can proceed directly to 818.
[0092] At 818, the Wi-Fi firmware receives a communication request signal from the Thread firmware. This request signal indicates whether the requested communication is for TX or RX and provides the session ID of the requested Thread communication session. As described above, the session ID indicates the criticality level of the requested Thread communication session.
[0093] Between steps 822 and 830, a series of decisions are made to determine whether the requested Thread communication session should be granted at step 832 or denied at step 834. Specifically, at step 822, if the ongoing Wi-Fi communication session is in a critical state (e.g., should not be interrupted), the requested Thread communication session is denied; otherwise, arbitration proceeds to step 824. At step 824, if the ongoing Wi-Fi communication session is not operating on the 2.4 GHz band, the requested Thread communication session is granted; otherwise, arbitration proceeds to step 826. At step 826, if the user equipment is not yet attached to the Thread / Wi-Fi network, the requested Thread communication session is granted; otherwise, arbitration proceeds to step 828. At step 828, if the session ID is greater than 0 (indicating that the requested Thread communication session is critical), the requested Thread communication session is granted; otherwise, arbitration proceeds to step 830. At point 830, if the requested Thread communication session is scheduled to occur within the first time window, the requested Thread communication session is granted; otherwise, the requested Thread communication session is rejected.
[0094] The arbitration process 800, along with the arbitration process between Thread and Bluetooth described above, provides balanced management of coexisting Bluetooth, Wi-Fi, and Thread communication needs. For example, when a Wi-Fi communication session is critical, Thread communication is denied, allowing the Wi-Fi communication session to remain uninterrupted. Otherwise, when a Wi-Fi communication session is non-critical, arbitration considers various factors to determine whether and when to grant the requested Thread communication session. Therefore, the needs for Bluetooth, Wi-Fi, and Thread communication are all taken into account, and user devices can improve overall communication performance without unnecessarily sacrificing the efficiency of individual communication sessions.
[0095] Figure 9A and Figure 9B Flowcharts of example methods 900A and 900B according to some specific implementations are illustrated respectively. For clarity, the following description generally describes methods 900A and 900B within the context of the other figures in this specification. For example, methods 900A and 900B may be derived from... Figure 1 Electronic devices 110 or Figures 2A to 2C User equipment 201 executes the method. It should be understood that methods 900A and 900B can be executed, for example, by any suitable system, environment, software, hardware, or a combination of system, environment, software, and hardware, as appropriate. In some specific implementations, the various steps of each of methods 900A and 900B can be run in parallel, in combination, cyclically, or in any order. Method 900A can be executed in a network with a topology similar to that of communication network 200A or 200C. Method 900B can be executed in a network with a topology similar to that of communication network 200B.
[0096] Starting with method 900A, at 902, the user equipment is attached to the wireless network via a router using a first communication protocol. The first communication protocol may be, for example, Thread.
[0097] At 904, the user equipment determines a first time window and a second time window based on information about a second session using a second communication protocol. The second communication protocol could be, for example, Bluetooth.
[0098] At point 906, the user equipment determines to execute a first session using a first communication protocol within a first time window. The first session could be, for example, a Thread communication session.
[0099] At point 908, the user equipment performs a first arbitration between the first session and the second session. The first arbitration can be performed by firmware shared by the first and second sessions.
[0100] At point 910, the user equipment, based on the first arbitration, determines that the first session has a higher priority than the second session in the second time window. In some specific implementations, the first session may then send a request signal to the firmware of a third session, which may be, for example, a Wi-Fi communication session.
[0101] At point 912, the firmware of the third session performs a second arbitration between the first session and the third session using a third communication protocol (such as Wi-Fi). The second arbitration may take into account various factors, such as the criticality level of the first session, the criticality level of the third session, and the frequency band of the third session. The second arbitration may include... Figure 8 The arbitration process involves one or more operations of 800.
[0102] At point 914, the user equipment, based on the second arbitration, determines whether to execute the first session within the second time window. This determination can be performed by the firmware of the third session, which can grant or deny communication requests for the first communication session.
[0103] Moving to method 900B, at point 932, a link is established between the user equipment and the peer device using a first communication protocol. This link can be a one-to-one link using, for example, the Thread protocol.
[0104] At 934, the user equipment determines a first time window and a second time window based on information about a second session using the second communication protocol. Similar to 904 of method 900A, the second communication protocol in method 900B can be, for example, Bluetooth.
[0105] At point 936, the user equipment determines to execute the first session via the link within the first time window. The first session can be, for example, a thread communication session.
[0106] At point 938, the user equipment performs a first arbitration between the first session and the second session. The first arbitration can be performed by firmware shared by the first and second sessions.
[0107] At point 940, the user equipment, based on the first arbitration, determines that the first session has a higher priority than the second session in the second time window. In some specific implementations, the first session may then send a request signal to the firmware of a third session, which may be, for example, a Wi-Fi communication session.
[0108] At point 942, the user equipment performs a second arbitration between the first session and a third session using a third communication protocol (such as Wi-Fi). The second arbitration may be performed by the firmware of the third session and takes into account various factors such as the criticality level of the first session, the criticality level of the third session, and the frequency band of the third session. The second arbitration may include... Figure 8 The arbitration process involves one or more operations of 800.
[0109] At point 944, the user equipment, based on the second arbitration, determines whether to execute the first session within the second time window. This determination can be performed by the firmware of the third session, which can grant or deny communication requests for the first communication session.
[0110] Figure 10 This is a block diagram of an electronic device 1000 according to some specific implementations. The electronic device 1000 can be a cellular phone, smartwatch, access point, wireless speaker, Internet of Things (IoT) device, etc. The electronic device 1000 includes hardware resources 1002, which include one or more processors (or processor cores) 1010, one or more memory / storage devices 1020, and one or more communication resources 1030, each of which can be communicatively coupled via a bus 1040. According to one or more specific implementations described above, the electronic device 1000 may have hardware, software, and firmware that support and manage the coexistence of multiple communication protocols.
[0111] One or more processors 1010 include one or more devices configured to perform computational operations. For example, one or more processors 1010 may include one or more microprocessors, application-specific integrated circuits (ASICs), microcontrollers, graphics processing units (GPUs), programmable logic devices, and / or one or more digital signal processors (DSPs). Processor 1010 may include, for example, processors 1012 and 1014. Processor 1010 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.
[0112] Memory / storage device 1020 may include main memory, disk storage, or any suitable combination thereof. Memory / storage device 1020 may include, but is not limited to, any type of volatile or non-volatile memory, such as 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 storage devices, etc. In some embodiments, memory / storage device 1020 is coupled to one or more high-capacity mass storage devices (not shown). In some examples, memory / storage device 1020 may be coupled to a disk drive or optical disk drive, a solid-state drive, or another type of mass storage device. In these examples, memory / storage device 1020 may be used by electronic device 1000 as a fast access storage device for frequently used data, while the mass storage device is used to store less frequently used data.
[0113] Communication resource 1030 may include interconnect or network interface components or other suitable devices for communicating with one or more peripheral devices 1004 or one or more databases 1006 via network 1008. For example, communication resource 1030 may include wired communication components (e.g., for coupling via USB), cellular communication components, NFC components, Bluetooth, etc. ® (or Bluetooth) ® Low-power components, Wi-Fi ® Components and other communication components.
[0114] Communication resource 1030 includes one or more devices configured to couple to and communicate (i.e., perform network operations) on wired and / or wireless networks, such as: control logic components, one or more interface circuits, and a set of antennas (or antenna elements) in an adaptive array that can be selectively turned on and / or off by the control logic components to generate a variety of optional antenna patterns or "beam patterns". Alternatively, instead of this set of antennas, in some examples, electronic device 1000 includes one or more nodes, such as pads or connectors, that can be coupled to the set of antennas. Therefore, electronic device 1000 may or may not include the set of antennas. For example, communication resource 1030 may include Bluetooth. ™ Networking systems, cellular networking systems (e.g., 3G / 4G / 5G / 6G networks, such as UMTS, LTE, etc.), Universal Serial Bus (USB) networking systems, and networking systems based on standards described in IEEE 802.11 (such as Wi-Fi). ® Networked systems), Ethernet networked systems and / or another networked system.
[0115] In some implementations, communication resource 1030 includes one or more radio components, such as a wake-up radio component for receiving wake-up frames and wake-up beacons, and a main radio component for transmitting and / or receiving frames or packets during normal operating mode. The wake-up radio component and the main radio component may be implemented separately (e.g., using discrete components or separate integrated circuits) or may be implemented in a common integrated circuit.
[0116] Communication resource 1030 includes processors, controllers, radio components / antennas, sockets / plugs, and / or other devices for coupling to each supported networked system, communicating on each supported networked system, and processing data and events for each supported networked system. It should be noted that the mechanisms for coupling to the network of the network system, communicating on the network of the network system, and processing data and events on the network of the network system are sometimes collectively referred to as the “network interface” of the network system.
[0117] Instructions 1050 may include software, programs, applications, applets, applications, or other executable code for causing at least any processor in processor 1010 to perform one or more of the methods discussed herein. Instructions 1050 may reside wholly or partially within at least one of: processor 1010 (e.g., within the processor's cache memory), memory / storage device 1020, or any suitable combination thereof. In some implementations, any portion of instructions 1050 may be transferred from peripheral device 1004 or database 1006 to hardware resource 1002. Thus, the memory of processor 1010, memory / storage device 1020, peripheral device 1004, and database 1006 are examples of computer-readable and machine-readable media.
[0118] While the foregoing discussion uses the Wi-Fi communication protocol as an illustrative example, a wide variety of communication protocols can be used in other implementations, and more generally, wireless communication technologies can be used. Therefore, communication technologies can be used in a variety of network interfaces. Furthermore, although some operations in the foregoing implementations are implemented in hardware or software, in general, the operations in the foregoing implementations can be implemented in a wide variety of configurations and architectures. Thus, some or all of the operations in the foregoing implementations can be performed in hardware, in software, or a combination of both. For example, at least some operations in the communication technology can be implemented using instructions 1050, an operating system (such as a driver for the interface circuitry in communication resource 1030), or in the firmware of the interface circuitry in communication resource 1030. Additionally or alternatively, at least some operations in the communication technology can be implemented at the physical layer (such as the hardware in the interface circuitry in communication resource 1030). In some implementations, the communication technology is implemented at least partially in the MAC layer and / or physical layer of the interface circuitry in communication resource 1030.
[0119] While the foregoing specific embodiments illustrate the use of wireless signals in one or more frequency bands, in some implementations, electromagnetic signals in one or more different frequency bands are used to determine distance. For example, these signals may be transmitted in one or more frequency bands, including: microwave bands, radar bands, 900 MHz, 2.4 GHz, 5 GHz, 6 GHz, 60 GHz, and / or bands used by Citizens Broadband Radio Service, LTE, 5G, or any other communication system.
[0120] Although specific components are used to describe electronic device 1000, in some specific embodiments, different components and / or subsystems may be present in electronic device 1000. For example, electronic device 1000 may include one or more additional processing subsystems, memory subsystems, networking subsystems, and / or display subsystems. Additionally, one or more subsystems may not be present in electronic device 1000. In some specific embodiments, electronic device 1000 may include Figure 10 One or more additional subsystems not shown. In some embodiments, the electronic device may include an analysis subsystem that performs at least some of the operations in the communication technology. Although Figure 10 Individual subsystems are shown, but in some specific implementations, some or all of a given subsystem or component may be integrated into one or more of other subsystems or components in the electronic device 1000.
[0121] For one or more specific embodiments, at least one of the components illustrated in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the Embodiments section below. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more examples below. As another example, circuitry associated with the UE, base station, network element, etc., described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more embodiments described in the Embodiments section below.
[0122] While the specific embodiments described above have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the disclosure is fully understood. It is intended that the following claims be construed as encompassing all such variations and modifications.
Claims
1. A method, the method comprising: The user equipment is attached to the wireless network via a router that uses the first communication protocol; Based on information about the second session using the second communication protocol, a first time window and a second time window are determined. Determine whether to execute the first session using the first communication protocol within the first time window; A first arbitration is performed between the first session and the second session; Based on the first arbitration, it is determined that the first session has a higher priority than the second session in the second time window; A second arbitration is performed between the first session and a third session using a third communication protocol; as well as Based on the second arbitration, it is determined whether the first session should be executed within the second time window.
2. The method of claim 1, wherein the user equipment is configured with Coordinated Sample Listening (CSL), and wherein the method further comprises controlling a CSL timer according to the time window and the second time window.
3. The method of claim 1 or claim 2, wherein the user equipment is not configured with Coordinated Sampling Listen (CSL), and wherein determining the first time window and the second time window comprises: Obtain the information about the second session from the wireless manager; as well as The firmware of the first communication protocol is used to determine the first time window and the second time window.
4. The method according to any one of claims 1 to 3, wherein determining to execute the first session within the first time window comprises at least one of the following: It is determined that the user equipment is configured with Coordinated Sampling Listen (CSL). It is determined that the third session operates on the first frequency band, or The first session is determined to have a higher priority than the second session within the first time window.
5. The method according to any one of claims 1 to 4, wherein determining whether to execute the first session within the second time window comprises: Determine the criticality level of the third session; as well as In response to determining that the third session is critical, it is determined that the first session will not be executed within the second time window.
6. The method of claim 5, wherein determining whether to execute the first session within the second time window further comprises: In response to determining that the third session is not critical, the criticality level of the first session is determined; as well as Perform at least one of the following: In response to determining that the third session is not critical and the first session is not critical, it is determined that the first session will not be executed within the second time window; as well as In response to determining that the third session is not critical and the first session is critical, it is determined that the first session will be executed within the second time window.
7. The method of claim 6, wherein determining the criticality level of the first session includes determining an identifier for the first session.
8. The method according to any one of claims 1 to 7, further comprising: The firmware of the first session transmits a request to the firmware of the third session to execute the first session within the second time window.
9. The method according to any one of claims 1 to 8, further comprising: The firmware of the third session transmits an indication of a power reduction occurring within the first time window to the access point of the third session.
10. The method according to any one of claims 1 to 9, further comprising: Prior to the attachment, a third arbitration is performed between a fourth session using the first communication protocol and a fifth session using the second communication protocol; In response to determining that the fourth session has a higher priority than the fifth session, the fourth session is executed; as well as In response to determining that the fifth session has a higher priority than the fourth session, the fifth session is executed.
11. The method according to any one of claims 1 to 10, wherein the router supports the first communication protocol and the third communication protocol.
12. The method according to any one of claims 1 to 11, wherein the router is coupled to a synchronous sleep terminal device.
13. The method according to any one of claims 1 to 12, wherein the user equipment is indirectly attached to the wireless network via the router.
14. The method according to any one of claims 1 to 13, wherein the wireless network includes one or more sleep terminal devices supporting the first communication protocol.
15. The method according to any one of claims 1 to 14, wherein the first communication protocol comprises the Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard.
16. The method according to any one of claims 1 to 15, wherein the second communication protocol includes the Bluetooth standard.
17. The method according to any one of claims 1 to 16, wherein the third communication protocol includes the Wi-Fi standard.
18. A method, the method comprising: A link is established between the user equipment and the peer equipment using the first communication protocol; Based on information about the second session using the second communication protocol, a first time window and a second time window are determined. Determine that the first session will be executed via the link within the first time window; A first arbitration is performed between the first session and the second session; Based on the first arbitration, it is determined that the first session has a higher priority than the second session in the second time window; A second arbitration is performed between the first session and a third session using the third communication protocol; as well as Based on the second arbitration, it is determined whether the first session should be executed within the second time window.
19. The method according to claim 18, Determining that the first session is executed within the first time window includes at least one of the following: It is determined that the user equipment is configured with Coordinated Sampling Listen (CSL). It is determined that the third session operates on the first frequency band, or It is determined that the first session has a higher priority than the second session within the first time window, and Determining whether to execute the first session within the second time window includes: Determine the criticality level of the third session; as well as In response to determining that the third session is critical, it is determined that the first session will not be executed within the second time window.
20. A user equipment, the user equipment including one or more processors, the one or more processors configured to execute instructions that cause the user equipment to perform operations, the operations including: The user equipment is attached to the wireless network via a router that uses the first communication protocol; Based on information about the second session using the second communication protocol, a first time window and a second time window are determined. Determine whether to execute the first session using the first communication protocol within the first time window; A first arbitration is performed between the first session and the second session; Based on the first arbitration, it is determined that the first session has a higher priority than the second session in the second time window; A second arbitration is performed between the first session and a third session using a third communication protocol; as well as Based on the second arbitration, it is determined whether the first session should be executed within the second time window.