P2P-based emlsr

Abstract

The present disclosure relates to P2P-based EMLSR. Systems, methods, and apparatus herein include implementations for peer-to-peer (P2P) based enhanced multi-link single radio (EMLSR). In some implementations, an EMLSR responder can transmit a request to an initiator peer device to enter a peer-to-peer (P2P) based EMLSR session with the initiator peer device. The EMLSR responder can receive a response from the initiator peer device accepting the request to enter the P2P-based EMLSR, and monitor an EMLSR link for an initial control frame (ICF) with padding or a request to send (RTS) from the initiator peer device.

Description

Technical Field

[0001] This application generally relates to wireless communication systems, including configurations for enhanced multi-link single radios (EMLSRs) with peer devices. Background Technology

[0002] Wireless communication technologies use various standards and protocols to transmit data between access points and wireless communication devices. For example, wireless communication system standards and protocols may include, for instance, 3GPP Long Term Evolution (LTE) (e.g., 4G), 3GPP New Radio (NR) (e.g., 5G), and the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Networks (WLANs) (often referred to as Wi-Fi within the industry organization). ® ).

[0003] In the 802.11 standard for WLAN, an access point (AP) is used to create a wireless local area network (WLAN) or Wi-Fi. ® A network device. An access point (AP) can connect to a wired network (such as Ethernet) and provide wireless access to that network for other devices. A station is a device that can wirelessly connect to an AP to join a WLAN network. A station can be a laptop, smartphone, tablet, or any other device with a WLAN adapter.

[0004] APs and stations use Wi-Fi ® The protocols communicate with each other. Various protocols have been established to improve security on wireless communication networks. For example, simultaneous authentication by peer entities is the core authentication protocol of WPA3-Personal, and is used by all Wi-Fi networks. ® All Alliance Certified devices (including both access points (APs) and non-AP stations (STAs) must support this protocol. Attached Figure Description

[0005] To facilitate the identification of any particular element or action in the discussion, one or more of the most significant digits in the figure reference numerals refer to the figure number in which the element was first introduced.

[0006] Figure 1 Example block diagrams are shown for devices using P2P-based EMLSR-based communication according to some implementation schemes.

[0007] Figure 2A Example topologies with a 5GHz link dedicated to P2P and a 6GHz link dedicated to Infra are illustrated according to some implementation schemes.

[0008] Figure 2BAn example topology based on some implementation schemes is illustrated, in which the 5GHz link is shared by P2P and Infra (on / off infra), and the 6GHz link is dedicated to Infra.

[0009] Figure 2C An example topology based on some implementation schemes is illustrated, in which the 5GHz link is dedicated to P2P (frequency hopping) and the 6GHz link is shared by P2P and Infra.

[0010] Figure 2D Example topologies based on some implementation schemes are illustrated, where the 5GHz link is shared by P2P and Infra (on / off Infra), and the 6GHz link is shared by P2P and Infra.

[0011] Figure 3 Example type length values ​​(TLV302) for P2P-based EMLSRs are shown according to some implementation schemes.

[0012] Figure 4 An example signal flow diagram illustrating the entry of an EMLSR responder into a P2P-based EMLSR according to some implementation schemes is shown.

[0013] Figure 5 An example signaling flow diagram illustrating the exit of a P2P-based EMLSR responder according to some implementation schemes is shown.

[0014] Figure 6A Example signaling diagrams are illustrated for downlink transmission (e.g., receiving data from a peer device) using a P2P-based single-link power-saving mode according to some implementation schemes.

[0015] Figure 6B Example signaling diagrams are illustrated for uplink transmission (e.g., data transmission to peer devices) using a P2P-based single-link power-saving mode according to some implementation schemes.

[0016] Figure 7A An example signaling diagram of a unicast frame in a P2P-based EMLSR on Link 1 is illustrated according to some implementation schemes.

[0017] Figure 7B An example signaling diagram of a unicast frame in a P2P-based EMLSR on Link 2 is illustrated according to some implementation schemes.

[0018] Figure 8 Example signaling diagrams of multicast frames in a P2P-based EMLSR are illustrated according to some implementation schemes.

[0019] Figure 9Examples of methods performed by EMLSR responders according to some implementation schemes are provided.

[0020] Figure 10 Examples of methods implemented by the EMLSR initiator according to some implementation schemes are shown.

[0021] Figure 11 An example is illustrated of a system for performing signaling transfer between an EMLSR responder and an EMLSR initiator according to an implementation scheme disclosed herein. Detailed Implementation

[0022] Wireless communication technologies use various standards and protocols to send data between access points and wireless communication devices. One standard used for wireless communication is the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Networks (WLANs) (commonly referred to as Wi-Fi within the industry organization). ® Wi-Fi ® This provides a convenient way to establish a network between devices. Devices (e.g., stations) can connect to Wi-Fi. ® The access point joins the network and connects wirelessly to the internet. (Wi-Fi) ® Security is crucial for protecting data and devices from unauthorized access.

[0023] Various implementations are described regarding Stations (STAs) and Access Points (APs). However, references to STAs and APs are provided for illustrative purposes only. The example implementations can be used with any electronic components that can establish a connection to a network and utilize hardware, software, and / or firmware configurations for exchanging information and data with the network. Therefore, STAs and APs as described herein are used to represent any suitable electronic components.

[0024] As used herein, the following terms shall have the meanings described below. These definitions are intended to clarify the terminology used in this disclosure and are not intended to be restrictive unless expressly stated otherwise.

[0025] “P2P” refers to peer-to-peer direct Wi-Fi communication protocols (e.g., Apple Wireless Direct Link (AWDL) / Neighbor-Aware Networking (NAN)).

[0026] “EMLSR” refers to Enhanced Multilink Single Radio (e.g., as defined in the 802.11be specification).

[0027] “STR” refers to simultaneous Tx / Rx (e.g., as defined in the 802.11be specification).

[0028] "SDB" refers to Dual-band simultaneous operation.

[0029] "ICF" refers to the Initial Control Frame (e.g., a Multi-User Request Transmit (muRTS) frame or a Buffer Status Report Polling (BSRP) frame, which includes the Receiver Associative Identifier (AID) as part of the ICF User Information field, with padding).

[0030] "ICF-Rsp frames" include an immediate response to the Clear Transmission (CTS) / Buffer Status Report (BSR) of muRTS / BSRP triggered frames.

[0031] "EMLSR initiator" refers to the device entity that initiates each TXOP to the EMLSR responder using ICF / ICF-Rsp. For example, an AP device acts as an EMLSR initiator with an EMLSR STA.

[0032] "EMLSR responder" refers to a device entity that supports receiving ICF / ICF-Rsp transactions before each TXOP on one or more EMLSR links or receiving RTS / CTS transactions before each TXOP on a single EMLSR link. For example, an EMLSR STA device acts as an EMLSR responder with an AP.

[0033] "Legacy initiator" refers to the device entity that initiates each TXOP to the EMLSR responder using RTS / CTS (legacy).

[0034] "EMLSR enabled device" refers to a device with WiFi 7+ hardware support for P2P-based EMLSR, including full support for STA EMLSR, and additionally capable of supporting both EMLSR initiators and EMLSR responders, and compliant with EMLSR transition latency.

[0035] "EMLSR-aware device" refers to a device that does not have full WiFi 7 hardware support for P2P-based EMLSR but is aware that it is communicating with an EMLSR-enabled device and can be configured to operate as a legacy initiator or an EMLSR initiator (if it can support initiating each TXOP with ICF / ICF-Rsp).

[0036] "EMLSR non-sensing device" refers to a device that does not have full hardware support for P2P-based EMLSR and does not support EMLSR sensing device or EMLSR enabled device operation mode.

[0037] The key performance indicators (KPIs) that peer-to-peer use cases need to support are becoming increasingly challenging, such as zero failures for 10 hours in some use cases. Since Wi-Fi uses shared channel resources and these resources can be occupied for extended periods (e.g., up to 32ms via CTS-to-self), it may be useful to use more than one channel (link) for those low-latency use cases.

[0038] Specific implementations can leverage SDB capabilities to support multi-channel low-latency P2P use cases, but this requires enabling radio components on two channels. EMLSR utilizes a single master radio component plus an additional low-power scanned radio component (or uses a 1×1+1×1 configuration), which can help improve the following aspects. First, EMLSR can have latency benefits. For example, EMLSR can allow contention on two channels simultaneously and the ability to transmit immediately on the first available channel (based on policy). Second, EMLSR can have power benefits. For example, EMLSR can allow simultaneous listening and contention on two channels with a master radio component plus a low-power scanned radio component, or listening and contention on a single link with a low-power scanned radio component.

[0039] Figure 1 Example block diagram 102 illustrates a device using P2P-based EMLSR-based communication according to some implementation schemes. Figure 1 This illustrates a general concept for using ICF as a means of conducting P2P-based EMLSR-based communication. As shown, device A 104 may have two links with one or more peer devices 106. Device A 104 may send an ICF (e.g., a padded mu-RTS 108) to peer device 106 to initiate a TXOP on link 2. In response, peer device 106 may send an ICF-Rsp frame (e.g., a CTS 110). Following CTS 110, device A 104 may send data packets 112 on link 2.

[0040] This specification defines four types of peer devices 106 that device A 104 may encounter when attempting P2P-based EMLSR-based communication. Different functionalities are expected for different types or modes of peer devices. For example, peer devices may include EMLSR-insensitive peers. Such peer devices do not support P2P-based EMLSR.

[0041] Peer devices may include EMLSR-aware peers. EMLSR-aware peers may have pre-WiFi 7 chipsets and therefore do not include full hardware support. EMLSR-aware peers may support legacy initiator operation modes. EMLSR-aware peers may support EML operation mode notification frames. EMLSR-aware peers may support the in-device coexistence activity subfield of the EML control field. If a legacy initiator does not receive a response to its RTS sent to an EMLSR responder, the legacy initiator may consider the lack of response as a result of in-device coexistence at the EMLSR responder on the link that sent the frame. Such peers support the EMLSR-aware device requirements as defined herein.

[0042] Peer devices may include EMLSR-aware peers with ICF support. EMLSR-aware peers with ICF support may have a pre-WiFi7 chipset and therefore do not include full hardware support. Such peers may support EMLSR initiator operating modes, where EMLSR transition delays may optionally be observed. Such peers may support EML operating mode notification frames. Such peers may support the in-device coexistence activity subfield of the EML control field. If an EMLSR initiator does not receive a response to its ICF sent to an EMLSR responder, the EMLSR initiator may consider the lack of response as a result of in-device coexistence at the EMLSR responder on the link that sent the frame. Furthermore, peer devices may support the EMLSR-aware device requirements with ICF support as defined herein.

[0043] Peer devices may include EMLSR-enabled peers. EMLSR-enabled peers may include WiFi 7+ chipsets. EMLSR-enabled peers may support both EMLSR initiator operation mode and EMLSR responder operation mode. EMLSR-enabled peers may support the in-device coexistence activity subfield of the EML control field. If the EMLSR initiator does not receive a response to its ICF sent to the EMLSR responder, the EMLSR initiator may consider the lack of response as a result of in-device coexistence at the EMLSR responder on the link that sent the frame. EMLSR-enabled peers may support EMLSR transition delays after a P2P-based EMLSR TXOP. Peers may support the EMLSR-enabled device requirements defined herein.

[0044] In WiFi 7, a P2P-based EMLSR can use NAN as a baseline peering protocol to support configurations of more than one channel mapping ID active at any given time. A P2P-based EMLSR is established between a pair of devices, where at least one of these devices is an EMLSR-enabled device. Because a P2P-based EMLSR can use NAN as a baseline, any NAN topology can be used with a P2P-based EMLSR topology. AWDL can also be used when communicating with a P2P-based EMLSR using a single link, as two channel mappings are not required.

[0045] Figure 2A , Figure 2B , Figure 2C and Figure 2D Examples of concurrent P2P-based EMLSR and infrastructure-based EMLSR modes (Infra) are illustrated. The topologies shown are examples to facilitate understanding of some scenarios where P2P-based EMLSR can be utilized. It should be noted that the topologies presented are not exhaustive and are used as illustrative examples rather than a comprehensive representation.

[0046] Specifically, Figure 2A An example topology with a dedicated 5GHz link for P2P and a dedicated 6GHz link for infrastructure is illustrated according to some implementation schemes. As shown, EMLSR-enabled device 202 can connect to EMLSR-sensing device 204 via the 5GHz link. Furthermore, EMLSR-enabled device 202 can also connect to AP 206 via the 6GHz link. The two links in the illustrated implementation scheme are established using EMLSR, which allows EMLSR-enabled device 202 to switch between links with different devices.

[0047] In this topology, a single-link EMLSR can exist with the WiFi7 AP 206. The single-link EMLSR can be a dedicated 6GHz Infra link as shown in the figure. Additionally, as shown in the figure, a single-link legacy P2P link with channel frequency hopping (including social channels) can also exist on the 5GHz link.

[0048] EMLSR enabling device 202 may use two radio components to maintain these links. In some embodiments, EMLSR enabling device 202 may include a main radio component and a scanning radio component. In other embodiments, 202 may include two 1×1 main radio components. The main radio component or the 1×1 main radio component may follow a P2P channel sequence. EMLSR enabling device 202 may perform a fast handover to the 6GHz Infra link upon receiving an ICF from AP 206 or during an uplink transmission to AP 206. The scanning radio component or the 1×1 main radio component may be used to listen for ICFs from AP 206 on the Infra 6GHz link.

[0049] Figure 2B An example topology according to some implementation schemes is illustrated, where the 5GHz link is shared by P2P and Infra (on / off Infra), and the 6GHz link is dedicated to Infra. As shown, EMLSR enabling device 202 may have two links with AP 206 and maintain a P2P link with EMLSR sensing device 204. EMLSR allows EMLSR enabling device 202 to switch between the 5GHz and 6GHz links to quickly transmit information to the AP. Based on the channel sequence of the 5GHz channel, the 5GHz link between EMLSR enabling device 202 and AP 206 may be active at some times and inactive at others.

[0050] In the illustrated implementation, the EMLSR enabling device 202 maintains a dual-link EMLSR with the WiFi 7 AP 206. The dual links between the EMLSR enabling device 202 and the AP 206 may include a dedicated 6GHz Infra link and a 5GHz Infra link shared with the P2P channel sequence. When the P2P channel sequence leaves the 5GHz Infra channel, the 5GHz Infra link can be placed in a power-saving state. Furthermore, as shown, a single-link legacy P2P link with channel frequency hopping (including social channels) may also exist on the 5GHz link.

[0051] EMLSR enabling device 202 may use two radio components to maintain these links. In some embodiments, EMLSR enabling device 202 may include a main radio component and a scanning radio component. In other embodiments, 202 may include two 1×1 main radio components. The main radio component or the 1×1 main radio component may follow a P2P channel sequence. EMLSR enabling device 202 may perform a fast handover to the 6GHz Infra link upon receiving an ICF from AP 206 or during an uplink transmission to AP 206. The scanning radio component or the 1×1 main radio component may be used to listen for ICFs from AP 206 on the Infra 6GHz link.

[0052] Figure 2C An example topology according to some implementation schemes is illustrated, where the 5GHz link is dedicated to P2P (frequency hopping) and the 6GHz link is shared by P2P and Infra. As shown, EMLSR enabled device 202 can use EMLSR to maintain two links (e.g., 5GHz and 6GHz) with a second EMLSR enabled device 208, and the 6GHz link can also be used for the link with AP 206.

[0053] In the illustrated implementation, the EMLSR-enabled device 202 maintains a single-link EMLSR with the WiFi 7 AP 206. For example, a 6GHz Infra link can be shared with a 6GHz P2P. Alternatively, a dual-link EMLSR can be used with the EMLSR-enabled peer device. In some implementations, the 6GHz channel sequence can always be equal to the 6GHz Infra channel. The 5GHz channel sequence can be set to any channel, including social channels.

[0054] EMLSR enabling device 202 may use two radio components to maintain these links. In some embodiments, EMLSR enabling device 202 may include a main radio component and a scanning radio component. In other embodiments, EMLSR enabling device 202 may include two 1×1 main radio components. The main radio component (or 1×1 main radio component) and the scanning radio component (or 1×1 main radio component) may be on either link (channel) as needed. Social channels may require a main radio component on these channels.

[0055] Figure 2DAn example topology according to some implementation schemes is illustrated, where the 5GHz link is shared by P2P and Infra (on / off Infra), and the 6GHz link is shared by P2P and Infra. As shown, EMLSR-enabled device 202 can use EMLSR to maintain two links (e.g., 5GHz and 6GHz) with a second EMLSR-enabled device 208 and two links (e.g., 5GHz and 6GHz) with AP 206. Based on the channel sequence of the 5GHz channel, the 5GHz link between EMLSR-enabled device 202 and AP 206 may be active at some times and inactive at other times.

[0056] In the illustrated implementation, EMLSR-enabled device 202 maintains a dual-link EMLSR with WiFi 7 AP 206. The 6GHz Infra link can be shared with the 6GHz P2P. The 5GHz Infra link can be shared with the 5GHz P2P channel sequence. When the 5GHz P2P channel sequence leaves the 5GHz Infra channel, the 5GHz Infra link can be put into a power-saving state.

[0057] EMLSR enabling device 202 may use two radio components to maintain these links. In some embodiments, EMLSR enabling device 202 may include a main radio component and a scanning radio component. In other embodiments, EMLSR enabling device 202 may include two 1×1 main radio components. The main radio component (or 1×1 main radio component) and the scanning radio component (or 1×1 main radio component) may be on either link (channel) as needed. Social channels may require a main radio component on these channels.

[0058] Table 1 includes information based on... Figures 2A to 2D An overview of the possible Infra and P2P links and the operation of the radio components in the illustrated topology.

[0059] Table 1

[0060]

[0061]

[0062] To support P2P-based EMLSR, certain channel sequence conditions may exist. When operating in P2P-based EMLSR using EMLSR-enabled devices on two or more links, each pair of devices exchanging data in this mode can have the same channel defined for the two links for the time slots used for P2P-based EMLSR communication. The following is a description of multi-link P2P-based EMLSR operation between two EMLSR-enabled devices.

[0063] First, the host can be configured with multiple NAN MAP IDs in the 2.4GHz / 5GHz / 6GHz frequency bands. The host can also be configured with a policy that indicates which NAN MAP ID among these NAN MAP IDs the main radio component should prioritize (relative to the scanning radio component).

[0064] Second, before scheduling TXOP at a specific time slot, the EMLSR initiator can verify that the EMLSR responder's channel sequence (in that time slot) includes the same set of channels being used for multi-link P2P-based EMLSR.

[0065] Third, each device advertises the NAN channel sequence. Devices can advertise the NAN channel sequence via the standard NAN protocol. Devices are allowed to have additional channels, such as channels in the 2.4 GHz band when performing 5 GHz + 6 GHz P2P-based EMLSR. The EMLSR link combinations that can be used for P2P-based EMLSR operation are 2.4 GHz + 5 GHz / 6 GHz, 5 GHz / 6 GHz + 5 GHz / 6 GHz, and 2.4 GHz + 5 GHz / 6 GHz + 5 GHz / 6 GHz combinations.

[0066] Fourth, if the multilink channels used by the EMLSR initiator for P2P-based EMLSR do not match all the multilink channels used by the EMLSR responder for TXOP, the EMLSR initiator may try to use a subset of the matching multilink channels, or if these channels do not match at all, the EMLSR initiator will be unable to transmit packets to the EMLSR responder at this time.

[0067] Fifth, NAN discovery, service discovery, synchronization frames, and other standard NAN protocol operations can be maintained in the 2.4 GHz social channel (channel 6).

[0068] Sixth, if the EMLSR non-aware device has established an active data path with the EMLSR responder device, the EMLSR responder will exit the P2P-based EMLSR with all peer devices that have requested to enter the P2P-based EMLSR until communication with the EMLSR non-aware device is completed (the device cache has been removed / NDP has been removed).

[0069] When operating in a P2P-based EMLSR on a single link, either NAN or AWDL can be used, and the device can follow the usual AWDL / NAN behavior, including the ability to discover and include social channels in the channel sequence as needed.

[0070] Figure 3Example type length values ​​(TLV 302) for P2P-based EMLSRs are illustrated according to some implementations. TLV 302 can be used to exchange P2P-based EMLSR capabilities. For example, a device can transmit information in the TLV to indicate its P2P-based EMLSR capabilities and parameters. TLV 302 can be added to specific frames. For example, in some implementations, TLV 302 can be added to AWDL master indication frames and synchronization frames, as well as NAN discovery frames and synchronization frames.

[0071] TLV 302 may include multiple fields. TLV 302 may include a type / tag number 304. The type / tag number 304 may be a unique value that identifies TLV 302 as including information for P2P-based EMLSR. TLV 302 may also include a length field 306 indicating the length of TLV 302.

[0072] In some implementations, TLV 302 may include a P2P-based EMLSR capability field 308. The P2P-based EMLSR capability field 308 can indicate the capabilities of the device. For example, the P2P-based EMLSR capability field 308 can be used to indicate whether the device is an EMLSR-aware device, an EMLSR-enabled device, or an EMLSR-aware device with ICF support. For example, a bit field can be used, where each bit is associated with a different type of device, and setting a bit to 1 indicates that the device transmitting the TLV is that device type.

[0073] TLV 302 may include an EMLSR link bitmap field 310. The bits in the EMLSR link bitmap field 310 can be used to indicate channels available for or currently being used for P2P-based EMLSR operations. For example, in the illustrated embodiment, the bitmap includes 8 bits (e.g., bits [0-7]). The device transmitting TLV 302 may set bit N to 1 to indicate that the NAN MAP ID [N] is available for or currently being used for P2P-based EMLSR operations. It should be noted that for AWDL, only the value of bit [0] may be relevant.

[0074] TLV 302 may include an EMLSR responder unicast AID field 312. If the device is an EMLSR-enabled device, the EMLSR responder unicast AID field 312 may indicate the AID the device will listen for in the ICF's user information field. In some implementations, the EMLSR responder unicast AID field 312 may have a range from 1 to 4095. A new random AID may be generated each time the P2P MAC address is rotated (and along with the rotation of the P2P MAC address).

[0075] TLV 302 may include an EMLSR parameter field 314. The EMLSR parameter field 314 may include parameters for the device. For example, the EMLSR parameter field 314 may indicate transition timeout, EMLSR fill delay, and whether the EMLSR responder mode is on or off.

[0076] Requests to enter P2P-based EMLSR mode can be initiated by the EMLSR responder (an EMLSR-enabled device) and accepted or rejected by the EMLSR initiator / legacy initiator. The EMLSR responder can indicate the need for an ICF with padding or a legacy RTS, which links it will listen on, and other parameters, as described in more detail below (e.g., Figure 4 and Figure 5 If a pair of devices wants to establish a bidirectional P2P-based EMLSR, both devices can initiate the EMLSR process from their EMLSR responder side.

[0077] Figure 4 Example signaling flow diagram 402 illustrates an EMLSR responder entering a P2P-based EMLSR according to some implementation schemes. As shown, the EMLSR initiator 406 (or legacy initiator) may send an AWDL or NAN beacon 408 to the EMLSR responder 404. The beacon 408 may include a P2P-based EMLSR TLV (e.g., Figure 3 (TLV 302). A P2P-based EMLSR TLV can indicate the P2P-based EMLSR capability of the EMLSR initiator 406.

[0078] The WiFi 7 standard defines the use of EML (Electronic Management Level) operation mode notifications as request / response pairs transmitted from an EMLSR responder (e.g., a STA) to an EMLSR initiator (e.g., an AP). This concept can be maintained for P2P-based EMLSRs, where the EMLSR parameter update control bit can be set to 1 when making a request and to 0 when transmitting a response. Therefore, the EMLSR parameter update control bit can be used by both the EMLSR responder and the EMLSR initiator to indicate whether the EML operation mode notification is a request to enter or exit a P2P-based EMLSR or a response to a request.

[0079] EMLSR responder 404 may initiate a P2P-based EMLSR 410 entry procedure by transmitting an EML operation mode notification frame 412. In some embodiments, EMLSR responder 404 may initiate a P2P-based EMLSR 410 entry procedure with a peer device only after receiving a value in the TLV for the P2P-based EMLSR (e.g., the P2P-based EMLSR TLV in beacon 408) from the peer device. In some embodiments, entry into the P2P-based EMLSR 410 may be solely requested by the EMLSR-enabled device.

[0080] EML Operation Mode Notification Frame 412 may include information for a P2P-based EMLSR. For example, EML Operation Mode Notification Frame 412 may include an EMLSR Mode field, a Parameter Update Control field, an In-Device Coexistence Activity subfield, an EMLSR Link Bitmap, a Fill Delay field, and a Transition Delay field. The EMLSR Mode field may indicate whether the EMLSR responder 404 is requesting to exit or enter a P2P-based EMLSR. For example, in the illustrated embodiment, the EMLSR Mode field is set to 1 to indicate that the EMLSR responder 404 is entering a P2P-based EMLSR, and the EMLSR Mode field may be set to 0 to indicate that the EMLSR responder 404 is exiting a P2P-based EMLSR. The Parameter Update Control field may be used to indicate whether the EML Operation Mode Notification Frame 412 is a request or response to entering / exiting a P2P-based EMLSR. For example, the EMLSR Parameter Update Control bit may be set to 1 when a request is made and to 0 when a response is transmitted. The EML control field's Intra-device Coexistence Activity subfield can be set to 1 to indicate that it can have intra-device coexistence activity on the EMLSR link. This is useful for supporting P2P+Infra topologies. The EMLSR link bitmap can indicate that the NAN MAP ID[N] is available or currently being used for P2P-based EMLSR operation. The Fill Delay field indicates the fill delay, and the Transition Delay field indicates the transition delay.

[0081] Therefore, when EMLSR responder 404 wants to enter into a P2P-based EMLSR 410 with EMLSR initiator 406 or the legacy initiator, the EMLSR responder can transmit an EML operation mode notification frame 412 as follows. When EMLSR responder 404 initiates the process of entering into a P2P-based EMLSR 410, EMLSR responder 404 can transmit an EML operation mode notification frame 412 to EMLSR initiator 406 or the legacy initiator, wherein the EMLSR mode bit is set to 1 and the EMLSR parameter update control bit is set to 1 to provide the requested EMLSR parameters.

[0082] EMLSR responder 404 may transmit an EML operation mode notification frame 412 that is supported by EMLSR initiator 406 or a legacy initiator. For example, EMLSR responder should not transmit a request to use two EMLSR links to an EMLSR sensing device or an EMLSR sensing device with ICF support, because those devices cannot support more than one EMLSR link. EMLSR responder 404 may determine the capabilities of EMLSR initiator 406 or a legacy initiator based on beacon 408 with a P2P-based EMLSR TLV.

[0083] If the EMLSR initiator 406 or the legacy initiator accepts the request, it can reply with an EMLSR EML Operation Mode Notification Frame 416, in which the EMLSR mode bit is set to 1 in the EML control field and the EMLSR parameter update control bit is set to 0, as shown in the figure. The EMLSR mode bit being set to 1 in the EML control field indicates that the EMLSR Operation Mode Notification Frame 416 is a request to enter a P2P-based EMLSR, and the EMLSR parameter update control bit being set to 0 indicates that the EMLSR Operation Mode Notification Frame 416 is a response to the request in the EMLSR Operation Mode Notification Frame 412. The EMLSR initiator 406 or the legacy initiator can copy value 414 from the EMLSR Operation Mode Notification Frame 416 and include them in the EMLSR Operation Mode Notification Frame 412.

[0084] In some implementations, if the EMLSR initiator 406 or the legacy initiator cannot accept the request (e.g., EML operation mode notification frame 412), it can respond with an EMLSR operation mode notification frame in which the EMLSR mode bit is set to 0 in the EML control field and the EMLSR parameter update control bit is set to 0.

[0085] The maximum timeout duration for a request / response can be tracked by monitoring the transition timeout (418). The EMLSR initiator (406) or legacy initiator can announce its monitoring transition timeout value in the TLV used for P2P-based EMLSRs. If no response is received after the timeout value has expired, it can be assumed that the request has failed. If the request is assumed to have failed, the EMLSR responder (404) can halt P2P-based EMLSRs until a successful request is made.

[0086] After receiving the EML Operation Mode Notification Frame 416 from the EMLSR initiator 406, the EMLSR responder 404 may listen for an ICF from the EMLSR initiator 406 on the EMLSR link 422 to initiate a TXOP. For example, in the illustrated embodiment, the EMLSR initiator 406 transmits ICF 420 to initiate a TXOP.

[0087] Figure 5 Example signaling flow diagram 502 illustrates an EMLSR responder 506 exiting a P2P-based EMLSR according to some implementation schemes. When the EMLSR responder 506 wants to exit a P2P-based EMLSR 508 with the EMLSR initiator or legacy initiator, the EMLSR responder 506 may transmit an EMLSR EML operation mode notification frame 510 as follows.

[0088] The EMLSR responder 506 may transmit an EMLSR EML operation mode notification frame 510, wherein the EMLSR mode bit is set to 0 and the EMLSR parameter update control bit is set to 1, as shown in the figure. Setting the EMLSR mode bit to 0 indicates that the EML operation mode notification frame 510 is associated with exiting P2P-based EMLSR, and setting the EMLSR parameter update control bit to 1 indicates that the EML operation mode notification frame 510 is a request rather than a response.

[0089] EMLSR initiator 504 or legacy initiator can respond with EMLSR EML Operation Mode Notification Frame 512, in which the EMLSR mode bit is set to 0 in the EML control field (indicating that the frame is related to exiting P2P-based EMLSR) and the EMLSR parameter update control bit is set to 0 (indicating that the frame is a response).

[0090] The maximum timeout duration for a request / response can be tracked by monitoring the transition timeout (514). The EMLSR initiator (504) or legacy initiator can announce its monitoring transition timeout value in the TLV used for P2P-based EMLSRs. If no response is received after the timeout value has expired, the request should be assumed to have succeeded. Therefore, if the request is assumed to have failed, the EMLSR responder (506) can stop the P2P-based EMLSR.

[0091] An EMLSR responder may wish to update an established P2P-based EMLSR session. To perform this update, a procedure for entering the P2P-based EMLSR (e.g., from...) can be executed. Figure 4 The signal flow diagram 402 shows that the exit process based on P2P EMLSR does not need to be executed first.

[0092] In some implementations, P2P-based EMLSR can be used for power saving. For example, a P2P-based single-link power-saving mode can be used. The EMLSR responder can request access to a P2P-based EMLSR in single-link power-saving mode with an EMLSR initiator, which can be an EMLSR-enabled device or an EMLSR-aware device with ICF support. For this operating mode, compliance with EMLSR transition delays may not be required because the scanning radio unit / auxiliary radio unit (or 1×1 primary radio unit) may continuously listen on the channel.

[0093] This mode may include establishing a single-link P2P-based EMLSR. This will allow the EMLSR responder to listen on a single P2P-based EMLSR channel using an auxiliary radio component / scanning radio component (or a 1×1 master radio component) and quickly switch to full master radio component operation mode after receiving an ICF from the EMLSR initiator or to send uplink frames to peer devices.

[0094] In some implementations, this operating mode (P2P-based EMLSR single-link power-saving mode) can operate over NAN or AWDL because it uses only a single link. The scanning radio unit / auxiliary radio unit (or 1×1 master radio unit) can listen on the P2P channel sequence instead of by the full master radio unit, to reduce listening power consumption. On the social channel slots (used for discovering AWDL / NAN devices and services, and also accepting new NDP connections / subscriptions from EMLSR-unaware devices), the master radio unit can be used to listen on the social channel slots (according to the host-configured policy).

[0095] On the infrastructure channel slot, if the AP is a WiFi 7+ AP, a scanning / secondary (or 1x1 primary) radio can be used to listen for ICFs from both P2P and infrastructure. If the AP is pre-WiFi 7, a full primary radio can be used as long as the infrastructure connection is not in power-saving mode. On any other channel slot (non-social or infrastructure), a secondary / scanning radio (or 1x1 primary radio) can be used to listen for ICFs from the EMLSR initiator.

[0096] Figure 6A Example signaling diagram 602 illustrates downlink transmission (e.g., receiving data from a peer) using a P2P-based single-link power-saving mode according to some embodiments. In the illustrated embodiment, the EMLSR-enabled device uses a P2P-based EMLSR to establish a link with the peer. The EMLSR-enabled device uses scanning radio component 604 and main radio component 606 to maintain the link.

[0097] Initially, scanning radio 604 is used to monitor the link, and main radio 606 is off. When a peer device has something to transmit to an EMLSR-enabled device, the peer device transmits an ICF (e.g., MU-RTS 608). MU-RTS 608 may have sufficient padding to allow the EMLSR-enabled device to turn on its main radio and respond based on SIFS.

[0098] The EMLSR-enabled device turns on the main radio and can use it to respond to the MU-RTS 608 via the MU-CTS 610. The peer device can then transmit downlink data 612, and the EMLSR-enabled device can receive the downlink data 612 using the main radio. After receiving the data, the EMLSR-enabled device can turn off the main radio and return to monitoring the link using the scanning radio.

[0099] Figure 6B Example signaling diagram 616 illustrates uplink transmission (e.g., data transmission to a peer) using a P2P-based single-link power-saving mode according to some implementations. In the illustrated implementation, the EMLSR-enabled device uses a P2P-based EMLSR to establish a link with the peer. The EMLSR-enabled device uses scanning radio component 604 and main radio component 606 to maintain the link.

[0100] The scanning radio component 604 can be used to compete for the channel. Then, when the back-off timer reaches 0, the EMLSR-enabled device can turn on the master radio component 606 and transmit uplink data 614 to the peer device. After transmitting uplink data 614, the EMLSR-enabled device can turn off the master radio component and return to monitoring the link with the scanning radio component.

[0101] In some cases, an EMLSR-enabled device may currently be in a P2P-based EMLSR session, and a new peer (e.g., not involved in the current P2P-based EMLSR session) may need to communicate with the EMLSR-enabled device. The EMLSR-enabled device may use a TLV to announce that it is in a P2P-based EMLSR session, and the new peer may take appropriate actions to initiate communication (e.g., transmit an ICF).

[0102] If an EMLSR-enabled device is currently in a P2P-based EMLSR session and a new device wants to initiate communication with it, the EMLSR-enabled device can enter a P2P-based EMLSR with the new device as quickly as possible after accepting communication with that peer. Entering a P2P-based EMLSR with a new device is possible in the following situations: after the new peer is locally cached (e.g., in AWDL); after receiving a unicast subscription message used to reply to a unicast publish message; and after accepting an NDP establishment from the new peer.

[0103] In implementations of NAN, unicast subscription and NDP establishment messages can be delivered to devices currently in a P2P-based EMLSR session. For EMLSR-aware devices, EMLSR-aware devices with ICF support, and EMLSR-enabled devices, if these devices see a peer device with an enabled EMLSR responder mode, such as in a new TLV for P2P-based EMLSR (e.g., ...), ... Figure 3 As announced in TLV 302, these devices can transmit these unicast messages as either legacy initiators (EMLSR-aware devices) or EMLSR initiators (EMLSR-aware devices with ICF support, EMLSR-enabled devices). In the case of EMLSR initiators, the EMLSR padding delay indicated in the new TLV for P2P-based EMLSR can be used, and the EMLSR transition delay does not need to be observed. This applies to unicast messages transmitted on the NAN MAP ID indicated in the new TLV for P2P-based EMLSR. Broadcast messages (such as broadcast subscriptions) can be transmitted normally.

[0104] In implementations of AWDL, for EMLSR-aware devices, ICF-supported EMLSR-aware devices, and EMLSR-enabled devices, if these devices see that a peer device has an enabled EMLSR responder mode, as announced in the new TLV for P2P-based EMLSR, these devices can transmit the initial unicast frame to the peer as either a legacy initiator (EMLSR-aware device) or an EMLSR initiator (ICF-supported EMLSR-aware device, EMLSR-enabled device). In the case of an EMLSR initiator, the EMLSR padding delay indicated in the new TLV for P2P-based EMLSR can be used, and the EMLSR transition delay does not need to be observed. Broadcast messages can be transmitted normally.

[0105] Figure 7A and Figure 7BThis illustrates an example of an EMLSR initiator transmitting a unicast (non-group-addressed) frame to an EMLSR responder on either of two established P2P-based EMLSR links. The padded muRTS may include the EMLSR responder's AID in the User Information field, and also include the necessary padding duration required by the EMLSR responder. It should be noted that when addressing P2P devices using P2P-based EMLSR, the MLD MAC address can be used. When transmitting unicast frames in a P2P-based EMLSR, the ICF frame can be a unicast frame. The EMLSR responder can check the Receiver Address (RA) and AID fields in the ICF frame as conditions for replying with a CTS.

[0106] Figure 7A Example signaling diagram 702 illustrates a unicast frame in a P2P-based EMLSR on link 1 according to some implementation schemes. In the illustrated implementation, the EMLSR initiator monitors both link 1 and link 2 during the backoff period and first determines that link 1 is functioning. Therefore, the EMLSR initiator can proceed to the next step on link 1.

[0107] As shown in the figure, the EMLSR initiator can send an ICF (e.g., a padded mu-RTS 704) to the EMLSR responder to indicate that it has data to transmit and to give the EMLSR responder sufficient time to power on the main radio components. The padded mu-RTS may include the EMLSR responder's AID in the User Information field and include the necessary padding duration required by the EMLSR responder. It should be noted that when addressing P2P devices using a P2P-based EMLSR, the MLD MAC address can be used.

[0108] The EMLSR responder can use the main radio component with CTS 706 to respond to the filled mu-RTS 704 to indicate that the EMLSR responder is ready to receive. The EMLSR initiator can transmit data packets 708, and the EMLSR responder can transmit BA 710.

[0109] Figure 7B Example signaling diagram 720 illustrates a unicast frame in a P2P-based EMLSR on link 2 according to some implementation schemes. In the illustrated implementation, the EMLSR initiator monitors both link 1 and link 2 during the backoff period and first determines that link 2 is functioning. Therefore, the EMLSR initiator can proceed to the next step on link 2.

[0110] As shown in the figure, the EMLSR initiator can send an ICF (e.g., a padded mu-RTS 712) to the EMLSR responder to indicate that it has data to transmit and to give the EMLSR responder sufficient time to power on the main radio components. The padded mu-RTS can include the EMLSR responder's AID in the user information field and include the necessary padding duration required by the EMLSR responder. It should be noted that when addressing P2P devices using a P2P-based EMLSR, the MLD MAC address can be used.

[0111] The EMLSR responder can use the main radio component to respond to the filled mu-RTS 712 with CTS 714 to indicate that the EMLSR responder is ready to receive. The EMLSR initiator can transmit data packets 716, and the EMLSR responder can transmit BA 718.

[0112] Table 2 provides an overview of the expected initiator behavior when the initiator transmits unicast frames in a P2P-based EMLSR.

[0113] Table 2

[0114]

[0115] As shown in Table 2, in some implementations, the legacy initiator (e.g., the EMLSR-aware initiator (legacy initiator)) may transmit the RTS to the EMLSR responder at the beginning of the TXOP.

[0116] For EMLSR-aware initiators with ICR support, the EMLSR initiator can send an ICF to the EMLSR responder at the beginning of the TXOP. The EMLSR initiator can optionally observe the EMLSR transition delay of the EMLSR responder. This operating mode may be helpful in single-link power-saving modes.

[0117] For the EMLSR initiator, the EMLSR initiator can send an ICF to the EMLSR responder at the beginning of the TXOP. The EMLSR initiator can observe the EMLSR transition delay of the EMLSR responder.

[0118] Figure 8Example signaling diagram 802 illustrates a multicast frame in a P2P-based EMLSR according to some implementation schemes. The illustrated implementation shows an example of an EMLSR initiator transmitting GCR-BA frames (e.g., GCR-BA sequence 804) to multiple EMLSR responders on either of two established P2P-based EMLSR links. In the illustrated implementation, the EMLSR initiator monitors both Link 1 and Link 2 during the backoff period and first determines that Link 1 is active. Therefore, the EMLSR initiator can proceed to the next step on Link 1.

[0119] The EMLSR initiator can perform CCA 808. The EMLSR initiator can send an ICF (e.g., a padded mu-RTS 806) to the EMLSR responder to indicate that it has data to transmit and to give the EMLSR responder sufficient time to power on its main radio components. The padded mu-RTS 806 can include the AID of each EMLSR responder in the user information field, and include the maximum duration required by the EMLSR responder.

[0120] The EMLSR responder receiving the padded mu-RTS 806 can transmit CTS 810 to the EMLSR initiator. The EMLSR responder's CTS 810 can be overlapping identical CTS frames. Upon receiving CTS 810, the initiator can transmit multicast data 812. The EMLSR initiator and EMLSR responders can participate in the Generic Retry Block Acknowledgment (GCR-BA) sequence 804 to confirm which EMLSR responders successfully received the multicast data 812. The EMLSR transition delay provides the radio component with time to transition back to its original state.

[0121] In some implementations, all devices participating in a GCR-BA session with a P2P-based EMLSR are EMLSR enabled. In some implementations, the sequence is aborted if no CTS response (transmitted by any of the receivers) is detected. In some implementations, a P2P-based EMLSR is established pairwise between the source device and each of the destination devices. In some implementations, each destination device may check the RA and AID fields in the ICF frame as conditions for responding with CTS.

[0122] Figure 9A method 900 performed by an EMLSR responder according to some implementation schemes is illustrated. The illustrated method 900 includes: transmitting 902 a request to an initiating peer device to enter a P2P-based EMLSR session with that initiating peer device. Method 900 further includes: receiving 904 a response from the initiating peer device accepting the request to enter the P2P-based EMLSR session. Method 900 further includes: monitoring 906 one or more EMLSR links to obtain at least one of an ICF or RTS with padding from the initiating peer device.

[0123] In some embodiments of method 900, the request includes a first EML operation mode notification frame, the first EML operation mode notification frame including: an EMLSR mode field indicating that the first EML operation mode notification frame corresponds to entry into the P2P-based EMLSR session; an EMLSR parameter update control field set to a first value indicating that the first EML operation mode notification frame includes the request; an intra-device coexistence activity subfield indicating one or more intra-device coexistence activities on the EMLSR link; an EMLSR link bitmap; a padding delay field; and a transition delay field. In some such embodiments, the response includes a second EML operation mode notification frame, the second EML operation mode notification frame including: an EMLSR mode field indicating that the first EML operation mode notification frame corresponds to entry into the P2P-based EMLSR session; and an EMLSR parameter update control field set to a second value indicating that the second EML operation mode notification frame includes the response.

[0124] In some implementations, method 900 further includes: transmitting to the initiating peer device a request to exit the P2P-based EMLSR session, the request including an EML operation mode notification frame, the EML operation mode notification frame including: an EMLSR mode field indicating that the EML operation mode notification frame corresponds to exiting the P2P-based EMLSR session; and an EMLSR parameter update control field set to a first value indicating that the first EML operation mode notification frame includes the request.

[0125] In some implementations, method 900 further includes receiving from the initiating peer device a P2P-based EMLSR TLV comprising at least one of the following: a P2P-based EMLSR capability field indicating one or more capabilities of the initiating peer device; an EMLSR link bitmap indicating one or more links that can be used or are currently being used for P2P-based EMLSR operation; an EMLSR responder unicast AID; or EMLSR parameters.

[0126] In some implementations, method 900 further includes entering the P2P-based EMLSR session using a single-link power-saving mode with the peer device of the initiating party.

[0127] In some implementations, method 900 further includes: notifying the EMLSR responder via TLV that the EMLSR responder is in a P2P-based EMLSR mode, thereby instructing another device to transmit an initial unicast frame to the EMLSR responder before transmitting data packets.

[0128] In some implementations, method 900 further includes: receiving a unicast frame from the initiating peer device, wherein receiving the unicast frame includes: receiving a padded muRTS frame from the initiating peer device, the padded muRTS frame including: the AID of the EMLSR responder in a user information field, and a padded duration associated with the EMLSR responder; transmitting a CTS frame to the initiating peer device in response to the AID being included in the padded muRTS frame; and receiving data of the unicast frame from the initiating peer device.

[0129] In some embodiments of method 900, receiving a multicast frame from the initiating peer device includes: receiving a padded muRTS frame from the initiating peer device, the padded muRTS frame including: multiple AIDs corresponding to multiple EMLSR responders in a user information field; transmitting a CTS frame to the initiating peer device in response to the inclusion of the AID corresponding to the EMLSR responder in the multiple AIDs; and receiving multicast data from the initiating peer device.

[0130] In some embodiments of method 900, the P2P-based EMLSR session is updated by transmitting an EML operation mode notification frame, the EML operation mode notification frame including: an EMLSR mode field indicating that the first EML operation mode notification frame corresponds to entering the P2P-based EMLSR session; an EMLSR parameter update control field set to a first value indicating that the first EML operation mode notification frame is the request; and updated parameters.

[0131] Figure 10 A method 1000 performed by an EMLSR initiator according to some implementation schemes is illustrated. The illustrated method 1000 includes: receiving 1002 a request from a peer EMLSR responder to enter into a P2P-based EMLSR session with that peer EMLSR responder. Method 1000 further includes: transmitting to the peer EMLSR responder a response 1004 accepting the request to enter into the P2P-based EMLSR session. Method 1000 further includes: transmitting to the peer EMLSR responder via one or more EMLSR links 1006 at least one of a padded ICF or a Request Transmission (RTS) to initiate a transmission opportunity.

[0132] In some embodiments of method 1000, the request includes a first EML operation mode notification frame, the first EML operation mode notification frame including: an EMLSR mode field indicating that the first EML operation mode notification frame corresponds to entry into the P2P-based EMLSR session; an EMLSR parameter update control field set to a first value indicating that the first EML operation mode notification frame includes the request; an intra-device coexistence activity subfield indicating intra-device coexistence activity on the EMLSR link; an EMLSR link bitmap; a padding delay field; and a transition delay field. In some such embodiments, the response includes a second EML operation mode notification frame, the second EML operation mode notification frame including: an EMLSR mode field indicating that the first EML operation mode notification frame corresponds to entry into the P2P-based EMLSR session; and an EMLSR parameter update control field set to a second value indicating that the second EML operation mode notification frame includes the response.

[0133] In some implementations, method 1000 further includes: receiving from the peer EMLSR responder a request to exit the P2P-based EMLSR session, the request including an EML operation mode notification frame, the EML operation mode notification frame including: an EMLSR mode field indicating that the EML operation mode notification frame corresponds to exiting the P2P-based EMLSR session; and an EMLSR parameter update control field set to a first value indicating that the first EML operation mode notification frame includes the request.

[0134] In some implementations, method 1000 further includes transmitting to the peer EMLSR responder a P2P-based EMLSR TLV comprising at least one of the following: a P2P-based EMLSR capability field indicating one or more capabilities of the initiating peer device; an EMLSR link bitmap indicating one or more links that can be used or are currently being used for P2P-based EMLSR operation; an EMLSR responder unicast AID; or EMLSR parameters.

[0135] In some implementations, method 1000 further includes entering the P2P-based EMLSR session using a single-link power-saving mode with the peer EMLSR responder.

[0136] In some implementations, method 1000 further includes: notifying the peer EMLSR initiator via TLV that it is in a P2P-based EMLSR mode, thereby instructing another device to transmit an initial unicast frame to the EMLSR responder before transmitting data packets.

[0137] In some implementations, method 1000 further includes: transmitting a unicast frame to the peer EMLSR responder, wherein transmitting the unicast frame includes: transmitting a padded muRTS frame, the padded muRTS frame including: the AID of the EMLSR responder in a user information field, and a padded duration associated with the EMLSR responder; receiving a CTS frame in response to the AID being included in the padded muRTS frame; and transmitting data of the unicast frame.

[0138] In some embodiments of method 1000, a multicast frame is transmitted to the peer EMLSR responder, wherein transmitting the multicast frame includes: transmitting a padded muRTS frame, the padded muRTS frame including: a plurality of AIDs in a user information field corresponding to a plurality of EMLSR responders, the plurality of AIDs including an AID corresponding to the EMLSR responder; receiving a CTS frame from the EMLSR responder; transmitting multicast data; and participating in a GCR-BA sequence with the plurality of EMLSR responders.

[0139] In some embodiments of method 1000, an update to the P2P-based EMLSR session is received in an EML operation mode notification frame, the EML operation mode notification frame including: an EMLSR mode field indicating that the first EML operation mode notification frame corresponds to entering the P2P-based EMLSR session; an EMLSR parameter update control field set to a first value indicating that the first EML operation mode notification frame is the request; and updated parameters.

[0140] Figure 11 A system 1100 for performing signaling transfer 1134 between an EMLSR responder 1102 and an EMLSR initiator 1118, according to an embodiment disclosed herein, is illustrated. System 1100 may be part of a wireless communication system as described herein. EMLSR responder 1102 may be, for example, a UE of a wireless communication system. EMLSR initiator 1118 may be, for example, an access point of a wireless communication system.

[0141] EMLSR responder 1102 may include one or more processors 1104. Processor 1104 may execute instructions to perform various operations of EMLSR responder 1102 as described herein. Processor 1104 may include one or more baseband processors, which may be implemented using, for example, a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), controller, field-programmable gate array (FPGA) device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.

[0142] EMLSR responder 1102 may include memory 1106. Memory 1106 may be a non-transitory computer-readable storage medium that stores instructions 1108, which may include, for example, instructions executed by processor 1104. Instructions 1108 may also be referred to as program code or a computer program. Memory 1106 may also store data used by processor 1104 and results calculated by the processor.

[0143] EMLSR responder 1102 may include one or more transceivers 1110, which may include radio frequency (RF) transmitter circuitry and / or receiver circuitry that uses antenna 1112 of EMLSR responder 1102 to facilitate signaling to and / or from EMLSR responder 1102 and other devices (e.g., EMLSR initiator 1118) (e.g., signaling transmission 1134).

[0144] EMLSR responder 1102 may include one or more antennas 1112 (e.g., one, two, four or more antennas). For implementations with multiple antennas 1112, EMLSR responder 1102 can fully utilize the spatial diversity of such multiple antennas 1112 to transmit and / or receive multiple different data streams on the same time-frequency resource. This behavior can be referred to as, for example, multiple-input multiple-output (MIMO) behavior (referring to multiple antennas used at each of the transmitting and receiving devices to implement this aspect). MIMO transmission by EMLSR responder 1102 can be achieved based on pre-decoding (or digital beamforming) applied at EMLSR responder 1102, which multiplexes the data streams among antennas 1112 according to known or assumed channel characteristics, such that each data stream is received with appropriate signal strength relative to the other streams at a desired location in the spatial domain (e.g., the location of the receiver associated with that data stream). Some implementations may use a single-user MIMO (SU-MIMO) approach (where all data streams are directed to a single receiver) and / or a multi-user MIMO (MU-MIMO) approach (where individual data streams may be directed to individual (different) receivers at different locations in the airspace).

[0145] In some implementations with multiple antennas, EMLSR responder 1102 can implement analog beamforming technology, whereby the phase of the signal transmitted by antenna 1112 is relatively adjusted, enabling (joint) transmission of the directional antenna 1112 (this is sometimes referred to as beam steering).

[0146] EMLSR responder 1102 may include one or more interfaces 1114. Interfaces 1114 can be used to provide input to or from the EMLSR responder 1102. For example, an EMLSR responder 1102 acting as a UE may include interfaces 1114, such as microphones, speakers, touchscreens, and buttons, to allow users of the UE to make inputs and / or outputs to the UE. Other interfaces of such UEs may consist of transmitters, receivers, and other circuitry that allow communication between the UE and other devices (e.g., in addition to the transceiver 1110 / antenna 1112 already described), and may be based on known protocols (e.g., Wi-Fi). ® ,Bluetooth ® (etc.) to perform the operation.

[0147] EMLSR responder 1102 may include a P2P-based EMLSR module 1116. The P2P-based EMLSR module 1116 may be implemented via hardware, software, or a combination thereof. For example, the P2P-based EMLSR module 1116 may be implemented as a processor, circuitry, and / or instructions 1108 stored in memory 1106 and executed by processor 1104. In some examples, the P2P-based EMLSR module 1116 may be integrated within processor 1104 and / or transceiver 1110. For example, the P2P-based EMLSR module 1116 may be implemented via a combination of software components (e.g., software components executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuitry) within processor 1104 or transceiver 1110.

[0148] The P2P-based EMLSR module 1116 can be used in various aspects of this disclosure, for example, Figures 1 to 8 All aspects.

[0149] EMLSR initiator 1118 may include one or more processors 1120. Processor 1120 is executable instructions to perform various operations of EMLSR initiator 1118 as described herein. Processor 1120 may include one or more baseband processors, which are implemented using, for example, a CPU, DSP, ASIC, controller, FPGA device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.

[0150] EMLSR initiator 1118 may include memory 1122. Memory 1122 may be a non-transitory computer-readable storage medium that stores instructions 1124, which may include, for example, instructions executed by processor 1120. Instructions 1124 may also be referred to as program code or computer program. Memory 1122 may also store data used by processor 1120 and results calculated by the processor.

[0151] EMLSR initiator 1118 may include one or more transceivers 1126, which may include RF transmitter circuitry and / or receiver circuitry that uses the antenna 1128 of EMLSR initiator 1118 to facilitate signaling to and / or from EMLSR initiator 1118 and other devices (e.g., EMLSR responder 1102) (e.g., signaling transmission 1134).

[0152] EMLSR initiator 1118 may include one or more antennas 1128 (e.g., one, two, four or more antennas). In embodiments having multiple antennas 1128, EMLSR initiator 1118 may perform MIMO, digital beamforming, analog beamforming, beam steering, etc., as already described.

[0153] EMLSR initiator 1118 may include one or more interfaces 1130. Interface 1130 may be used to provide input to or from EMLSR initiator 1118. For example, EMLSR initiator 1118 may include interface 1130 consisting of transmitters, receivers and other circuitry (e.g., in addition to the transceiver 1126 / antenna 1128 described), which enables the EMLSR initiator to communicate with other equipment in the core network and / or to communicate with external networks, computers, databases, etc., for the purpose of operating, managing and maintaining EMLSR responders or other equipment operable to the EMLSR responder.

[0154] EMLSR initiator 1118 may include a P2P-based EMLSR module 1132. The P2P-based EMLSR module 1132 may be implemented via hardware, software, or a combination thereof. For example, the P2P-based EMLSR module 1132 may be implemented as a processor, circuitry, and / or instructions 1124 stored in memory 1122 and executed by processor 1120. In some examples, the P2P-based EMLSR module 1132 may be integrated within processor 1120 and / or transceiver 1126. For example, the P2P-based EMLSR module 1132 may be implemented via a combination of software components (e.g., software components executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuitry) within processor 1120 or transceiver 1126.

[0155] The P2P-based EMLSR module 1132 can be used in various aspects of this disclosure, for example, Figures 1 to 8 All aspects.

[0156] The embodiments contemplated herein include an apparatus comprising components for performing one or more elements of method 900. This apparatus may be, for example, an EMLSR responder (such as EMLSR responder 1102, as described herein).

[0157] The embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 900. The non-transitory computer-readable medium may be, for example, memory of an STA (such as memory 1306 of STA 1302, as described herein).

[0158] The embodiments contemplated herein include an apparatus comprising logic components, modules, or circuitry for performing one or more elements of method 900. This apparatus may be, for example, an EMLSR responder (such as EMLSR responder 1102, as described herein).

[0159] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of method 900. The apparatus may be, for example, an EMLSR responder (such as EMLSR responder 1102, as described herein).

[0160] The implementation scheme envisioned herein includes a signal as described in or associated with one or more elements of method 900.

[0161] The embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution by a processor will cause the processor to perform one or more elements of method 900. The processor may be a processor of an EMLSR responder (such as processor 1104 of EMLSR responder 1102, as described herein). These instructions may, for example, reside in the processor and / or the memory of the STA (such as memory 1106 of EMLSR responder 1102, as described herein).

[0162] The embodiments contemplated herein include an apparatus comprising components for performing one or more elements of method 1000. This apparatus may be, for example, an EMLSR initiator (such as EMLSR initiator 1118, as described herein).

[0163] The embodiments contemplated herein include one or more non-transitory computer-readable media, the one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 1000. The non-transitory computer-readable media may be, for example, the memory of an EMLSR initiator (such as memory 1122 of EMLSR initiator 1118, as described herein).

[0164] The embodiments contemplated herein include an apparatus comprising logic components, modules, or circuitry for performing one or more elements of method 1000. This apparatus may be, for example, an EMLSR initiator's apparatus (such as EMLSR initiator 1118, as described herein).

[0165] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of method 1000. The apparatus may be, for example, an EMLSR initiator (such as EMLSR initiator 1118, as described herein).

[0166] The implementation scheme envisioned herein includes a signal as described in or associated with one or more elements of method 1000.

[0167] The embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution by a processing element will cause the processing element to perform one or more elements of method 1000. The processor may be a processor of an EMLSR initiator (such as processor 1120 of EMLSR initiator 1118, as described herein). These instructions may, for example, reside in the processor and / or in the memory of the EMLSR initiator (such as memory 1122 of EMLSR initiator 1118, as described herein).

[0168] For one or more 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, and / or methods as set forth herein. For example, a processor described herein in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples set forth herein. Similarly, circuitry associated with a STA or AP described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples set forth herein.

[0169] Unless otherwise expressly stated, any of the embodiments described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustrative and descriptive information, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. In light of the teachings above, modifications and variations are possible, or modifications and variations may be derived from practice with various embodiments.

[0170] Implementations and specific embodiments of the systems and methods described herein may include various operations embodied in machine-executable instructions to be executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components, including specific logical parts for performing the operations; or may include a combination of hardware, software, and / or firmware.

[0171] It should be recognized that the systems described herein include descriptions of specific implementations. These implementations may be combined into a single system, partially integrated into other systems, divided into multiple systems, or otherwise partitioned or combined. Furthermore, it is contemplated that parameters, attributes, aspects, etc., of one implementation may be used in another. For clarity, these parameters, attributes, aspects, etc., are described only in one or more implementations, and it should be recognized that, unless expressly stated herein, these parameters, attributes, aspects, etc., may be combined with or substituted for parameters, attributes, aspects, etc., of another implementation.

[0172] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0173] Although the foregoing has been described in considerable detail for clarity, it will be apparent that certain changes and modifications can be made without departing from the principles of the invention. It should be noted that many alternative ways exist to implement both the processes and apparatus described herein. Therefore, embodiments of the invention should be considered illustrative rather than restrictive, and this specification is not limited to the details given herein, but can be modified within the scope and equivalents of the appended claims.

Claims

1. A method performed by an Enhanced Multi-Link Single Radio (EMLSR) responder, the method comprising: Send a request to the initiating peer device to enter a peer-to-peer (P2P) EMLSR session with the initiating peer device; Receive a response from the initiating peer device to accept the request to enter the P2P-based EMLSR session; as well as Monitor one or more EMLSR links to obtain at least one of an Initial Control Frame (ICF) or a Request Transmission (RTS) with padding from the initiating peer device.

2. The method of claim 1, wherein the request includes a first Enhanced Multi-Link (EML) Operation Mode Notification frame, the first EML Operation Mode Notification frame comprising: The EMLSR mode field indicates that the first EML operation mode notification frame corresponds to entering the P2P-based EMLSR session. The EMLSR parameter update control field is set to a first value, which indicates that the first EML operation mode notification frame includes the request. The intra-device coexistence activity subfield indicates one or more intra-device coexistence activities on the EMLSR link. EMLSR link bitmap Fill the delayed field, and Transformation delay field.

3. The method of claim 2, wherein the response includes a second EML operation mode notification frame, the second EML operation mode notification frame comprising: The EMLSR mode field indicates that the first EML operation mode notification frame corresponds to entering the P2P-based EMLSR session. The EMLSR parameter update control field is set to a second value, which indicates that the second EML operation mode notification frame includes the response.

4. The method according to claim 1, further comprising: A request to exit the P2P-based EMLSR session is sent to the initiating peer device. The request includes an EML operation mode notification frame, which includes: The EMLSR mode field indicates that the EML operation mode notification frame corresponds to exiting the P2P-based EMLSR session. The EMLSR parameter update control field is set to a first value, which indicates that the first EML operation mode notification frame includes a request.

5. The method according to claim 1, further comprising: Receive a P2P-based EMLSR type length value (TLV) from the initiating peer device, including at least one of the following: The P2P-based EMLSR capability field indicates one or more capabilities of the initiating peer device. EMLSR link bitmap, which indicates one or more links that can be used or are currently being used for P2P-based EMLSR operations. EMLSR responder unicast association identifier (AID), or EMLSR parameters.

6. The method according to claim 1, further comprising: Enter the P2P-based EMLSR session using the single-link power-saving mode of the peer device of the initiator.

7. The method according to claim 1, further comprising: The EMLSR responder is notified via a Type Length Value (TLV) that it is in a P2P-based EMLSR mode, thereby instructing another device to transmit an initial unicast frame to the EMLSR responder before transmitting data packets.

8. The method according to claim 1, further comprising: Receiving unicast frames from the initiating peer device, wherein receiving the unicast frames includes: Receive a padded Multi-User Request Transmission (muRTS) frame from the initiating peer device, the padded Multi-User Request Transmission (muRTS) frame comprising: The EMLSR responder's association identifier (AID) in the user information field, and The padding duration associated with the EMLSR responder; In response to the AID being included in the padded muRTS frame, a clear transmission (CTS) frame is transmitted to the initiating peer device; and Data of the unicast frame is received from the initiating peer device.

9. The method of claim 1, wherein receiving a multicast frame from the initiating peer device, wherein receiving the multicast frame comprises: Receive a padded Multi-User Request Transmission (muRTS) frame from the initiating peer device, the padded Multi-User Request Transmission (muRTS) frame comprising: The user information field contains multiple AIDs corresponding to multiple EMLSR responders; In response to the AID corresponding to the EMLSR responder being included in the plurality of AIDs, a Clear Transmission (CTS) frame is transmitted to the initiating peer device; and Receive multicast data from the initiating peer device.

10. The method of claim 1, wherein the P2P-based EMLSR session is updated by transmitting an Enhanced Multilink (EML) Operation Mode Notification Frame, the Enhanced Multilink (EML) Operation Mode Notification Frame comprising: The EMLSR mode field indicates that the first EML operation mode notification frame corresponds to entering the P2P-based EMLSR session. The EMLSR parameter update control field is set to a first value, which indicates that the first EML operation mode notification frame is the request. Updated parameters.

11. A method performed by an Enhanced Multi-Link Single Radio (EMLSR) initiator, the method comprising: Receive a request to enter a peer-to-peer (P2P) EMLSR session with the peer EMLSR responder. Send a response to the peer EMLSR responder accepting the request to enter the P2P-based EMLSR session; as well as Transmit at least one of an Initial Control Frame (ICF) or a Request for Transmission (RTS) with padding to the peer EMLSR responder via one or more EMLSR links to initiate a transmission opportunity.

12. The method of claim 11, wherein the request includes a first Enhanced Multilink (EML) Operation Mode Notification frame, the first EML Operation Mode Notification frame comprising: The EMLSR mode field indicates that the first EML operation mode notification frame corresponds to entering the P2P-based EMLSR session. The EMLSR parameter update control field is set to a first value, which indicates that the first EML operation mode notification frame includes the request. The intra-device coexistence activity subfield indicates one or more intra-device coexistence activities on the EMLSR link. EMLSR link bitmap Fill the delayed field, and Transformation delay field.

13. The method of claim 12, wherein the response includes a second EML operation mode notification frame, the second EML operation mode notification frame comprising: The EMLSR mode field indicates that the first EML operation mode notification frame corresponds to entering the P2P-based EMLSR session. The EMLSR parameter update control field is set to a second value, which indicates that the second EML operation mode notification frame includes the response.

14. The method according to claim 11, further comprising: Receive a request to terminate the P2P-based EMLSR session from the peer EMLSR responder. The request includes an EML operation mode notification frame, which includes: The EMLSR mode field indicates that the EML operation mode notification frame corresponds to exiting the P2P-based EMLSR session. The EMLSR parameter update control field is set to a first value, which indicates that the first EML operation mode notification frame includes a request.

15. The method according to claim 11, further comprising: Transmit a P2P-based EMLSR Type Length Value (TLV) to the peer EMLSR responder, including at least one of the following: The P2P-based EMLSR capability field indicates one or more capabilities of the initiating peer device. EMLSR link bitmap, which indicates one or more links that can be used or are currently being used for P2P-based EMLSR operations. EMLSR responder unicast association identifier (AID), or EMLSR parameters.

16. The method according to claim 11, further comprising: Enter the P2P-based EMLSR session using the single-link power-saving mode of the peer EMLSR responder.

17. The method according to claim 11, further comprising: The peer EMLSR initiator is notified via Type Length Value (TLV) that it is in P2P-based EMLSR mode, thereby instructing another device to transmit an initial unicast frame to the EMLSR responder before transmitting data packets.

18. The method according to claim 11, further comprising: Transmitting a unicast frame to the peer EMLSR responder, wherein transmitting the unicast frame includes: Transmitting a padded Multi-User Request Transmit (muRTS) frame, the padded Multi-User Request Transmit (muRTS) frame comprising: The EMLSR responder's association identifier (AID) in the user information field, and The padding duration associated with the EMLSR responder; In response to the AID being included in the padded muRTS frame to receive a clear transmission (CTS) frame; and Transmit the data of the unicast frame.

19. The method of claim 11, wherein transmitting a multicast frame to the peer EMLSR responder comprises: Transmitting a padded Multi-User Request Transmit (muRTS) frame, the padded Multi-User Request Transmit (muRTS) frame comprising: The user information field contains multiple AIDs corresponding to multiple EMLSR responders, including the AIDs corresponding to the EMLSR responders; Receive a Clear Transmit (CTS) frame from the EMLSR responder; Transmitting multicast data; and Together with the multiple EMLSR responders, participate in the multicast block acknowledgment with retry (GCR-BA) sequence.

20. The method of claim 11, wherein an update to the P2P-based EMLSR session is received in an Enhanced Multilink (EML) Operation Mode Notification Frame, the Enhanced Multilink (EML) Operation Mode Notification Frame comprising: The EMLSR mode field indicates that the first EML operation mode notification frame corresponds to entering the P2P-based EMLSR session. The EMLSR parameter update control field is set to a first value, which indicates that the first EML operation mode notification frame is the request. Updated parameters.

21. An apparatus comprising components for performing the method according to any one of claims 1 to 20.

22. A computer-readable medium comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform the method according to any one of claims 1 to 20.

23. An apparatus comprising a logic component, module, or circuit for performing the method according to any one of claims 1 to 20.

Images