Dynamic resource cancellation for device-to-device data communication

Abstract

A first device establishes a data path with a second device and agrees with the second device on a set of resource blocks for communication over the data path. The first device sends a message to the second device indicating when the first device cancels a portion of the set of resource blocks, such that the second device refrains from sending data to the first device over the data path during the cancelled portion of the set of resource blocks. The first device cancels a portion of the set of resource blocks for receiving data over the data path. The first device is allowed to not listen over the data path during the cancelled portion of the set of resource blocks.

Description

Technical Field

[0001] This disclosure generally relates to wireless communication systems, and more specifically, to dynamic resource cancellation for, for example, but not limited to, device-to-device data communication in wireless communication systems. Background Technology

[0002] Many device-to-device discovery technologies, or many communication technologies, require two or more devices to agree on a set of time and frequency (channel) resources in which they can communicate. These agreed-upon resources are often referred to as scheduling or shared resource blocks (CRBs) in neighborhood-aware networking (NAN). On a CRB, even when devices are not transmitting or receiving, they remain in a listening state, allowing them to receive transmissions from a peer device if that peer device wishes to transmit on the CRB. However, outside of a CRB, on resources where a device has no other wireless communication operations, it can enter a lower-power state, such as a dozing or sleeping state.

[0003] It may be desirable to allow devices to dynamically cancel some CRBs (Content Buffers) if the link between devices has been inactive for a certain duration. This can prove particularly useful for so-called bursty traffic. For example, Discontinuous Reception (DRX) procedures are defined in Long Term Evolution (LTE) and New Radio (NR). During DRX, while the base station (BS) is expected to remain awake, the BS operating as the master device can configure the user equipment (UE) operating as the follower device to dynamically relinquish its listening state if the link between the BS and the UE has been inactive for a certain duration. Similarly, in infrastructure radio LAN (WLAN) operation, access point (AP) stations (STAs) can indicate the early termination of a service session to non-AP stations based on link inactivity or the duration of the empty media access control (MAC) buffer, allowing non-AP STAs to relinquish their listening state for the remaining duration of the ongoing service session. Summary of the Invention

[0004] This disclosure relates to improvements in wireless communication. In particular, this disclosure relates to reductions in power consumption in wireless communication.

[0005] This disclosure discloses inactive power-saving (PS) operations for data communication between devices in device-to-device networks or mesh networks, such as NAN data path (NDP) connections between devices in a NAN cluster. In some aspects, the operation of devices will be described using an NDP between devices as part of a NAN cluster as an example. In some examples, each device on the NDP may be able to determine its own PS or DRX configuration and may cancel some CRBs independently of the PS or DRX configurations of other devices. This can be particularly useful in mesh networks, where devices may have NDPs established with multiple peers and there may be no central or master entity coordinating harmonious PS or DRX configurations between devices.

[0006] In some examples, an electronic device for facilitating communication in a wireless network includes: a memory; and a processor operatively coupled to the memory. The processor is configured to: establish a data path with a wireless communication device; negotiate a set of resource blocks for communication on the data path with the wireless communication device; send a message to the wireless communication device instructing the electronic device when to cancel a portion of the resource block set, causing the wireless communication device to avoid transmitting data to the electronic device on the data path during the canceled portion of the resource block set; and cancel a portion of the resource block set for receiving data on the data path, wherein the electronic device is permitted not to listen on the data path during the canceled portion of the resource block set.

[0007] In some examples, the message instructs the electronic device to cancel a portion of the resource block set upon receiving a response to the message, and canceling a portion of the resource block set includes canceling a portion of the resource block set upon receiving a response to the message.

[0008] In some examples, the processor is also configured to restore the cancelled portion of the resource block set when a successful data transmission or reception associated with the data path is performed.

[0009] In some examples, the message indicates that the electronic device cancels a portion of the resource block set when the data path is inactive in the device for a period of time.

[0010] The cancellation of a portion of the resource block set includes: determining whether a data path is inactive in the electronic device for a period of time, and canceling a portion of the resource block set based on the determination that the data path is inactive in the electronic device for a period of time.

[0011] In some examples, determining whether a data path is inactive in an electronic device during the duration includes determining that the data path is inactive in the electronic device during the duration if no data transmission or reception associated with the data path is successfully performed during the duration.

[0012] In some examples, the message includes a parameter indicating the duration.

[0013] In some examples, determining whether a data path is inactive in the electronic device for a duration includes: if the duration ends at a time belonging to an active resource block, excluding the observation window located at the beginning of the active resource block, then the data path is determined to be inactive in the electronic device for the duration.

[0014] In some examples, determining whether a data path is inactive in an electronic device for a duration includes: determining that the data path is inactive in an electronic device for a duration if the duration ends at a time that does not belong to any active resource block and if the data path remains inactive for a predetermined time in one or more active resource blocks.

[0015] In some examples, determining whether a data path is inactive in an electronic device for a duration includes: determining that the data path is inactive in an electronic device for a duration if the duration ends at the time of an observation window that is located at the beginning of an active resource block, and if the data path remains inactive for a predetermined time in one or more active resource blocks.

[0016] In some examples, the message includes information indicating which part of the resource block set was cancelled.

[0017] In some examples, a portion of the resource block set is pre-configured.

[0018] In some examples, an electronic device for facilitating communication in a wireless network includes: a memory; and a processor operatively coupled to the memory. The processor is configured to: establish a data path with a wireless communication device; agree with the wireless communication device on a set of resource blocks for communication on the data path; receive from the wireless communication device a message instructing the electronic device when to cancel a portion of the resource block set; and, based on the message, cancel a portion of the resource block set for transmitting data on the data path, wherein during the period when a portion of the resource block set is canceled, the electronic device avoids transmitting data to the wireless communication device on the data path.

[0019] In some examples, the message instructs the wireless communication device to cancel a portion of the resource block set when a response to the message is received, and canceling a portion of the resource block set includes canceling a portion of the resource block set when a response to the message is received.

[0020] In some examples, the processor is also configured to restore the cancelled portion of the resource block set when a successful data transmission or reception associated with the data path is performed.

[0021] In some examples, the message instructs the wireless communication device to cancel a portion of the resource block set when the data path is inactive in the wireless communication device for a duration, and wherein canceling a portion of the resource block set includes: determining that the data path is inactive in the wireless communication device for the duration, and canceling a portion of the resource block set based on determining that the data path is inactive in the wireless communication device for the duration.

[0022] In some examples, determining that a data path is inactive in a wireless communication device during a given duration includes determining that the data path is inactive in the wireless communication device during that duration if no data transmission or reception associated with the data path is successfully performed during that duration.

[0023] In some examples, the message includes a parameter indicating the duration.

[0024] In some examples, determining that a data path is inactive in a wireless communication device for a duration includes: if the duration ends at a time belonging to an active resource block, excluding the observation window located at the beginning of the active resource block, then determining that the data path is inactive in the wireless communication device for that duration.

[0025] In some examples, determining that a data path is inactive in a wireless communication device for a duration includes: determining that the data path is inactive in a wireless communication device for a duration if the duration ends at a time that does not belong to any active resource block, and if the data path remains inactive for a predetermined time in one or more active resource blocks.

[0026] In some examples, determining that a data path is inactive in a wireless communication device for a duration includes: if the duration ends at the end of an observation window that is located at the beginning of an active resource block, and the data path remains inactive for a predetermined time in one or more active resource blocks, then the data path is determined to be inactive in the wireless communication device for the duration.

[0027] One aspect of this disclosure provides a computer-implemented method for facilitating communication of an electronic device in a wireless network. The method includes establishing a data path with a wireless communication device. The method includes agreeing with the wireless communication device on a set of resource blocks for communication on the data path. The method includes sending a message to the wireless communication device instructing the electronic device when to cancel a portion of the resource block set, such that the wireless communication device avoids transmitting data to the electronic device on the data path during the canceled portion of the resource block set. The method includes cancelling a portion of the resource block set for receiving data on the data path, wherein the electronic device is permitted not to listen on the data path during the canceled portion of the resource block set.

[0028] In some examples, the message instructs the electronic device to cancel a portion of the resource block set upon receiving a response to the message. Canceling a portion of the resource block set may include canceling a portion of the resource block set upon receiving a response to the message.

[0029] In some examples, the method includes restoring the cancelled portion of the resource block set when a successful data transmission or reception associated with the data path is performed.

[0030] In some examples, the message instructs the electronic device to cancel a portion of the resource block set when the data path is inactive in the electronic device for a period of time. Canceling a portion of the resource block set may include determining whether the data path is inactive in the electronic device for the period of time, and canceling the portion of the resource block set based on the determination that the data path is inactive in the electronic device for the period of time.

[0031] In some examples, determining whether a data path is inactive in an electronic device during the duration includes determining that the data path is inactive in the electronic device during the duration if no data transmission or reception associated with the data path is successfully performed during the duration.

[0032] In some examples, the message includes a parameter indicating the duration.

[0033] In some examples, determining whether a data path is inactive in the electronic device for a duration includes: if the duration ends at a time belonging to an active resource block, excluding the observation window located at the beginning of the active resource block, then the data path is determined to be inactive in the electronic device for the duration.

[0034] In some examples, determining whether a data path is inactive in an electronic device for a duration includes: determining that the data path is inactive in an electronic device for a duration if the duration ends at a time that does not belong to any active resource block and if the data path remains inactive for a predetermined time in one or more active resource blocks.

[0035] In some examples, determining whether a data path is inactive in an electronic device for a duration includes: if the duration ends at the time of an observation window located at the beginning of an active resource block, and the data path remains inactive for a predetermined time in one or more active resource blocks, then the data path is determined to be inactive in the electronic device for the duration.

[0036] In some examples, the message includes information indicating which part of the resource block set was cancelled.

[0037] In some examples, a portion of the resource block set is pre-configured.

[0038] One aspect of this disclosure provides a computer-implemented method for facilitating communication of an electronic device in a wireless network. The method includes establishing a data path with a wireless communication device. The method includes agreeing with the wireless communication device on a set of resource blocks for communication on the data path. The method includes receiving from the wireless communication device a message indicating when the electronic device cancels a portion of the resource block set. The method includes cancelling a portion of the resource block set for transmitting data on the data path based on the message, wherein during the period of cancellation of the resource block set, the electronic device avoids transmitting data to the wireless communication device on the data path.

[0039] In some examples, the message instructs the wireless communication device to cancel a portion of the resource block set upon receiving a response to the message. Canceling a portion of the resource block set includes canceling a portion of the resource block set upon receiving a response to the message.

[0040] In some examples, the method includes restoring the cancelled portion of the resource block set when a successful data transmission or reception associated with the data path is performed.

[0041] In some examples, the message instructs the wireless communication device to cancel a portion of the resource block set when the data path is inactive in the wireless communication device for a certain period of time. Canceling a portion of the resource block set may include determining that the data path is inactive in the wireless communication device for that period of time, and canceling the portion of the resource block set based on determining that the data path is inactive in the wireless communication device for that period of time.

[0042] In some examples, determining that a data path is inactive in a wireless communication device during a given duration includes determining that the data path is inactive in the wireless communication device during that duration if no data transmission or reception associated with the data path is successfully performed during that duration.

[0043] In some examples, the message includes a parameter indicating the duration.

[0044] In some examples, determining that a data path is inactive in a wireless communication device for a duration includes: if the duration ends at a time belonging to an active resource block, excluding the observation window located at the beginning of the active resource block, then determining that the data path is inactive in the wireless communication device for the duration.

[0045] In some examples, determining that a data path is inactive in a wireless communication device for a duration includes: if the duration ends at the end of an observation window that is located at the beginning of an active resource block, and the data path remains inactive for a predetermined time in one or more active resource blocks, then the data path is determined to be inactive in the wireless communication device for the duration. Attached Figure Description

[0046] Figure 1 An example of a wireless network 100 according to an embodiment is shown.

[0047] Figure 2 An example of AP 101 according to an embodiment is shown.

[0048] Figure 3 An example of STA 111 according to an embodiment is shown.

[0049] Figure 4 The exchange of DRX configurations between two NAN devices according to an embodiment is illustrated.

[0050] Figure 5 The expiration of the NDP inactive countdown timer according to an embodiment is shown.

[0051] Figure 6 The expiration of the NDP inactive countdown timer according to an embodiment is shown.

[0052] Figure 7 The expiration of the NDP inactive countdown timer according to an embodiment is shown.

[0053] Figure 8 The operation of two devices based on explicit signals according to an embodiment is illustrated.

[0054] Figure 9 The operation of two devices according to an embodiment is shown.

[0055] In one or more embodiments, not all of the components depicted in each figure may be required, and one or more embodiments may include additional components not shown in the figures. Variations in the arrangement and type of components may be made without departing from the scope of this subject matter disclosure. Additional components, different components, or fewer components may be utilized within the scope of this subject matter disclosure. Detailed Implementation

[0056] The detailed description set forth below in conjunction with the accompanying drawings is intended to describe various embodiments and is not intended to represent the only embodiments in which the subject matter can be practiced. Rather, this detailed description includes specific details to provide a thorough understanding of the subject matter of the invention. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the scope of this disclosure. Therefore, the drawings and description are to be considered illustrative rather than restrictive in nature. The same reference numerals denote the same elements.

[0057] The following description pertains to certain embodiments for the purpose of describing the innovative aspects of this disclosure. However, those skilled in the art will readily recognize that the teachings herein can be applied in a variety of different ways. The examples in this disclosure are based on WLAN communication according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, including the IEEE 802.11be standard and any future revisions to the IEEE 802.11 standard. However, the described embodiments can be implemented in any device, system, or network capable of transmitting and receiving radio frequency (RF) signals according to the IEEE 802.11 standard, Bluetooth standard, Global System for Mobile Communications (GSM), GSM / General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Terrestrial Trunking Radio (TETRA), Wideband CDMA (W-CDMA), Evolved Data Optimized (EV-DO), 1xEV-DO, EV-DO Rev A, EV-DO Rev B, High-Speed ​​Packet Access (HSPA), High-Speed ​​Downlink Packet Access (HSDPA), High-Speed ​​Uplink Packet Access (HSUPA), Evolved High-Speed ​​Packet Access (HSPA+), Long Term Evolution (LTE), 5G NR (New Radio), AMPS, or other known signals used for communication within wireless, cellular, or Internet of Things (IoT) networks, such as systems utilizing 3G, 4G, 5G, 6G, or further implementations thereof.

[0058] Depending on the network type, other well-known terms may be used instead of "access point" or "AP," such as "router" or "gateway." For convenience, the term "AP" is used in this disclosure to refer to a network infrastructure component that provides wireless access to remote terminals. In a WLAN, assuming that the AP also contends for the wireless channel, the AP may also be referred to as a STA. Furthermore, depending on the network type, other well-known terms may be used instead of "station" or "STA," such as "mobile station," "subscriber station," "remote terminal," "user equipment," "wireless terminal," or "user device." For convenience, the terms "station" and "STA" are used in this disclosure to refer to a remote wireless device that wirelessly accesses an AP or contends for a wireless channel in a WLAN, whether the STA is a mobile device (such as a mobile phone or smartphone) or is generally considered a fixed device (such as a desktop computer, AP, media player, fixed sensor, television, etc.).

[0059] Multilink Operation (MLO) is a key feature currently being developed by the standards body for next-generation Ultra High Throughput (EHT) Wi-Fi systems in IEEE 802.11be. Wi-Fi devices that support MLO are called Multilink Devices (MLDs). Using MLO, a non-AP MLD can discover, authenticate, associate, and establish multiple links with an AP MLD. Channel access and frame switching can occur on each link between the AP MLD and non-AP MLDs.

[0060] Figure 1 An example of a wireless network 100 according to an embodiment is shown. Figure 1 The illustrated embodiment of the wireless network 100 is for illustrative purposes only. Other embodiments of the wireless network 100 may be used without departing from the scope of this disclosure.

[0061] like Figure 1 As shown, wireless network 100 may include multiple wireless communication devices. Each wireless communication device may include one or more stations (STAs). An STA may be a logical entity that is a separate addressable instance of an interface to the Media Access Control (MAC) layer and Physical (PHY) layer of the wireless medium. STAs may be classified as Access Point (AP) STAs and Non-Access Point (Non-AP) STAs. An AP STA may be an entity that provides access to distribution system services to an associated STA via the wireless medium. A Non-AP STA may be a STA that is not included within an AP-STA. For simplicity, an AP STA may be referred to as an AP, and a Non-AP STA may be referred to as a STA. Figure 1In the example, APs 101 and 103 are wireless communication devices, each of which may include one or more AP STAs. In such an embodiment, APs 101 and 103 may be AP multilink devices (MLDs). Similarly, STAs 111-114 are wireless communication devices, each of which may include one or more non-AP STAs. In such an embodiment, STAs 111-114 may be non-AP MLDs.

[0062] APs 101 and 103 communicate with at least one network 130, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network. AP 101 provides wireless access to network 130 to multiple stations 111-114 in the coverage area 120 of AP 101. APs 101 and 103 can communicate with each other and with STAs using Wi-Fi or other WLAN communication technologies.

[0063] Depending on the network type, other well-known terms may be used instead of "access point" or "AP," such as "router" or "gateway." For convenience, the term "AP" is used in this disclosure to refer to a network infrastructure component that provides wireless access to remote terminals. In a WLAN, assuming that the AP also contends for the wireless channel, the AP may also be referred to as a STA. Furthermore, depending on the network type, other well-known terms may be used instead of "station" or "STA," such as "mobile station," "subscriber station," "remote terminal," "user equipment," "wireless terminal," or "user device." For convenience, the terms "station" and "STA" are used in this disclosure to refer to a remote wireless device that wirelessly accesses an AP or contends for a wireless channel in a WLAN, whether the STA is a mobile device (such as a mobile phone or smartphone) or is generally considered a fixed device (such as a desktop computer, AP, media player, fixed sensor, television, etc.).

[0064] exist Figure 1 In the diagram, the dashed lines indicate the approximate extent of the coverage areas 120 and 125 of APs 101 and 103, which are shown as approximately circular for illustrative and explanatory purposes. It should be clearly understood that, depending on the configuration of the APs, the coverage areas associated with the APs (such as coverage areas 120 and 125) may have other shapes, including irregular shapes.

[0065] As described in more detail below, one or more APs in an AP may include circuitry and / or programming for the management of MU-MIMO and OFDMA channel detection in a WLAN. Although Figure 1 An example of a wireless network 100 is shown, but more details can be found on other wireless networks. Figure 1Various modifications can be made. For example, wireless network 100 can include any number of APs and any number of STAs in any suitable arrangement. Furthermore, AP 101 can communicate directly with any number of STAs and provide these STAs with wireless broadband access to network 130. Similarly, each AP 101 and 103 can communicate directly with network 130 and provide STAs with direct wireless broadband access to network 130. Additionally, AP 101 and / or 103 can provide access to other or additional external networks, such as external telephone networks or other types of data networks.

[0066] Figure 2 An example of AP 101 according to an embodiment is shown. Figure 2 The embodiment of AP 101 shown is for illustrative purposes, and Figure 1 AP 103 can have the same or similar configuration. However, APs have a wide variety of configurations, and Figure 2 This disclosure is not intended to limit the scope of any particular implementation of AP.

[0067] like Figure 2 As shown, AP 101 may include multiple antennas 204a-204n, multiple radio frequency (RF) transceivers 209a-209n, transmit (TX) processing circuitry 214, and receive (RX) processing circuitry 219. AP 101 may also include a controller / processor 224, a memory 229, and a backhaul or network interface 234. RF transceivers 209a-209n receive incoming RF signals from antennas 204a-204n, such as signals transmitted by STAs in network 100. RF transceivers 209a-209n down-convert the incoming RF signals to generate intermediate (IF) or baseband signals. The IF or baseband signals are sent to RX processing circuitry 219, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. RX processing circuitry 219 sends the processed baseband signals to controller / processor 224 for further processing.

[0068] TX processing circuit 214 receives analog or digital data (such as voice data, network data, email, or interactive video game data) from controller / processor 224. TX processing circuit 214 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. RF transceivers 209a-209n receive the processed baseband or IF signal from TX processing circuit 214 and up-convert the baseband or IF signal into an RF signal transmitted via antennas 204a-204n.

[0069] The controller / processor 224 may include one or more processors or other processing devices that control the overall operation of the AP 101. For example, the controller / processor 224 may control the RF transceivers 209a-209n, the RX processing circuitry 219, and the TX processing circuitry 214 to receive uplink signals and transmit downlink signals, based on well-known principles. The controller / processor 224 may also support additional functions, such as more advanced wireless communication capabilities. For example, the controller / processor 224 may support beamforming or directional routing operations, where outgoing signals from multiple antennas 204a-204n are weighted differently to effectively direct outgoing signals in a desired direction. The controller / processor 224 may also support OFDMA operations, where outgoing signals are assigned to different subsets of subcarriers for different receivers (e.g., different STAs 111-114). The controller / processor 224 may support any of a variety of other functions in the AP 101, including combining DLMU-MIMO and OFDMA in the same transmission opportunity. In some examples, controller / processor 224 may include at least one microprocessor or microcontroller. Controller / processor 224 is also capable of executing programs and other processes, such as an operating system, residing in memory 229. Controller / processor 224 may move data into or out of memory 229 as needed for the execution process.

[0070] The controller / processor 224 is also coupled to a backhaul or network interface 234. The backhaul or network interface 234 allows the AP 101 to communicate with other devices or systems via a backhaul connection or over a network. Interface 234 can support communication via any suitable wired or wireless connection. For example, interface 234 can allow the AP 101 to communicate with a larger network (such as the Internet) via a wired or wireless local area network or via a wired or wireless connection. Interface 234 can include any suitable structure that supports communication via a wired or wireless connection, such as an Ethernet or RF transceiver. Memory 229 is coupled to the controller / processor 224. A portion of memory 229 can include RAM, and another portion of memory 229 can include flash memory or other ROM.

[0071] As described in more detail below, AP 101 may include circuitry and / or programming for managing the channel detection process in a WLAN. Although Figure 2 An example of AP 101 is shown, but it is possible to compare it with other versions. Figure 2 Various changes can be made. For example, AP101 can include any number of... Figure 2Each component shown. As a specific example, the AP may include multiple interfaces 234, and the controller / processor 224 may support routing functionality to route data between different network addresses. As another example, although shown as a single instance including TX processing circuitry 214 and a single instance including RX processing circuitry 219, AP 101 may include multiple instances of each (e.g., one for each RF transceiver). Alternatively, only one antenna and RF transceiver path may be included, as in a conventional AP. Moreover, Figure 2 The various components can be combined, further subdivided, or omitted, and additional components can be added as needed.

[0072] like Figure 2 As shown, in some embodiments, AP 101 may be an AP MLD comprising multiple APs 202A-202N. Each AP 202a-202n is attached to AP MLD 101 and includes multiple antennas 204a-204n, multiple radio frequency (RF) transceivers 209a-209n, transmit (TX) processing circuitry 214, and receive (RX) processing circuitry 219. Each AP 202a-202n may communicate independently with the controller / processor 224 and other components of AP MLD 101. Figure 2 The diagram shows that each AP 202a-202n has multiple separate antennas, but each AP 202a-202n can share multiple antennas 204a-204n without requiring separate multiple antennas. Each AP 202a-202n can represent the physical (PHY) layer and the lower media access control (MAC) layer.

[0073] Figure 3 An example of STA 111 according to an embodiment is shown. Figure 3 The embodiment of STA 111 shown is for illustrative purposes, and Figure 1 STAs 111-114 can have the same or similar configurations. However, STAs appear in a wide variety of configurations, and Figure 3 This disclosure is not intended to limit the scope of any particular implementation of STA.

[0074] like Figure 3 As shown, STA 111 may include one or more antennas 205, an RF transceiver 210, a TX processing circuit 215, a microphone 220, and an RX processing circuit 225. STA 111 may also include a speaker 230, a controller / processor 240, an input / output (I / O) interface (IF) 245, a touchscreen 250, a display 255, and a memory 260. The memory 260 may include an operating system (OS) 261 and one or more applications 262.

[0075] RF transceiver 210 receives incoming RF signals transmitted by the AP of network 100 from antenna 205. RF transceiver 210 down-converts the incoming RF signals to generate IF or baseband signals. The IF or baseband signals are sent to RX processing circuitry 225, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. RX processing circuitry 225 sends the processed baseband signals to speaker 230 (e.g., for voice data) or to controller / processor 240 for further processing (e.g., for web browsing data).

[0076] TX processing circuitry 215 receives analog or digital voice data from microphone 220, or other outgoing baseband data (such as web data, email, or interactive video game data) from controller / processor 240. TX processing circuitry 215 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. RF transceiver 210 receives the processed outgoing baseband or IF signal from TX processing circuitry 215 and up-converts the baseband or IF signal into an RF signal transmitted via antenna 205.

[0077] The controller / processor 240 may include one or more processors and executes a basic OS program 261 stored in memory 260 to control the overall operation of STA 111. In one such operation, the controller / processor 240 controls the RF transceiver 210, RX processing circuitry 225, and TX processing circuitry 215 to receive downlink signals and transmit uplink signals according to well-known principles. The controller / processor 240 may also include processing circuitry configured to provide management of the channel detection process in the WLAN. In some examples, the controller / processor 240 may include at least one microprocessor or microcontroller.

[0078] The controller / processor 240 is also capable of executing other processes and programs residing in the memory 260, such as operations for managing channel sensing processes in the WLAN. The controller / processor 240 can move data into or out of the memory 260 as needed for the execution of processes. In some examples, the controller / processor 240 is configured to execute multiple applications 262, such as applications for channel sensing, including feedback calculations based on received Null Data Packet Advertisements (NDPA) and Null Data Packets (NDP), and sending beamforming feedback reports in response to Triggered Frames (TF). The controller / processor 240 can operate the multiple applications 262 based on the OS program 261 or in response to signals received from the AP. The controller / processor 240 is also coupled to an I / O interface 245, which provides the STA 111 with the ability to connect to other devices such as laptops and handheld computers. The I / O interface 245 is the communication path between these accessories and the main controller / processor 240.

[0079] The controller / processor 240 is also coupled to an input unit 250 (such as a touchscreen) and a display 255. The operator of STA 111 can use the input unit 250 to input data into STA 111. The display 255 may be a liquid crystal display, a light-emitting diode display, or other display capable of rendering text and / or at least limited graphics (such as from a website). Memory 260 is coupled to the controller / processor 240. A portion of memory 260 may include random access memory (RAM), and another portion of memory 260 may include flash memory or other read-only memory (ROM).

[0080] although Figure 3 An example of STA 111 is shown, but it is possible to compare it with other models. Figure 3 Make various changes. For example, Figure 3 The various components can be combined, further subdivided, or omitted, and additional components can be added as needed. In a specific example, STA 111 may include any number of antennas 205 for MIMO communication with AP 101. In another example, STA 111 may not include voice communication, or the controller / processor 240 may be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Furthermore, although... Figure 3 The STA 111 is shown configured as a mobile phone or smartphone, but the STA can be configured to operate as other types of mobile or fixed devices.

[0081] like Figure 3As shown, in some embodiments, STA 111 may be a non-AP MLD comprising multiple STAs 203A-203N. Each STA 203a-203n is attached to the non-AP MLD 111 and includes an antenna 205, an RF transceiver 210, a TX processing circuit 215, and an RX processing circuit 225. Each STA 203a-203n may independently communicate with the controller / processor 240 and other components of the non-AP MLD 111. Figure 3 It is shown that each STA 203a-203n has a separate antenna, but each STA 203a-203n can share antenna 205 without requiring a separate antenna. Each STA 203a-203n can represent the physical (PHY) layer and the lower media access control (MAC) layer.

[0082] Hereafter, methods for dynamically canceling some NDPRBs based on NDP inactivity will be described according to various embodiments.

[0083] On a cancelled CRB, the NAN device can relinquish its listening state and enter a sleep state, or it can listen on a different channel to perform another concurrent operation. For example, the NAN device can revert to its infrastructure WLAN connection with the AP station.

[0084] As NDP PS configuration parameters, the scheduling management entity of a NAN device can determine its own PS parameters, such as the NDP inactivity countdown timer reset value ndpInactivityTimeout_self and the NDP DRX scheduler ndpDrxCrbs_self. The NDP DRX scheduler can be referred to as the DRX scheduler, NDP PS scheduler, or NDP DRX CRB. The scheduling management entity of a NAN device can receive PS parameters from peer NAN devices, such as the NDP inactivity countdown timer reset value ndpInactivityTimeout_peer and the NDP PS or DRX scheduler ndpDrxCrbs_peer.

[0085] In some examples, the DRX scheduler ndpDrxCrbs_self can be a subset of the original NDP CRB. For instance, the NDPDRX scheduler ndpDrxCrbs_self can be obtained by canceling or removing some slots that are part of the original NDP CRB. The meaning and use of this parameter will be described in more detail later.

[0086] In some examples, the NAN device can maintain an NDP inactivity countdown timer with a reset value of ndpInactivityTimeout_self. For convenience, the reset value of the countdown timer will be referred to as the name of the countdown timer. For example, the timer ndpInactivityTimeout_self can refer to the countdown timer whose reset value is given by the parameter ndpInactivityTimeout_self. This countdown timer ndpInactivityTimeout_self can be used to measure the duration of inactivity on the NDP. The expiration of the timer ndpInactivityTimeout_self can indicate that the NDP has been inactive for a duration equal to or greater than the time indicated by the parameter ndpInactivityTimeout_self. After the timer ndpInactivityTimeout_self expires, the NAN device can enter DRX mode based on the NDP DRX scheduler ndpDrxCrbs_self. DRX mode can also be referred to as power saving (PS) mode or reduced scheduling mode. In some examples, the value of the parameter ndpInactivityTimeout_self can determine how long the NDP inactivity will last before the NAN device enters PS or DRX mode. In some examples, the value of ndpInactivityTimeout_self can be configured in the range of 16 time units (TUs) to 2048 TUs. The operation of the timer ndpInactivityTimeout_self and the operation of NAN devices in DRX mode will be described in more detail later.

[0087] In some examples, the NAN device can determine these DRX parameters ndpInactivityTimeout_self and ndpDrxCrbs_self based on the QoS requirements associated with the NDP. In some examples, the QoS requirements are typically provided to the scheduling entity by a higher layer, such as the service or application layer. Alternatively, in some examples, the scheduling entity can provide an interface to a higher layer to configure these DRX parameters directly within the NAN device.

[0088] In some examples, a peer NAN device can send its DRX configuration, such as the parameters ndpInactivityTimeout_self and ndpDrxCrbs_self, to a NAN device on the NDP. Similarly, a NAN device can receive DRX configuration from a peer NAN device on the NDP. Parameters received from a peer NAN device with the suffix "_peer" will be represented as [parameter name] instead of the previously introduced suffix "_self". In some examples, the NAN device can log the DRX parameters ndpInactivityTimeout_peer and ndpDrxCrbs_peer received from the peer NAN device.

[0089] For example, the MAC entity (also known as L2) in a NAN device can maintain a timer, ndpInactivityTimeout_self, that controls the PS or DRX operations of the NAN device. Additionally, the MAC entity of the NAN device can maintain a timer, ndpInactivityTimeout_peer, with a reset value, that tracks the DRX state of the peer NAN device. In some examples, the timer ndpInactivityTimeout_peer can be described as the timer ndpInactivityTimeout_self that the NAN device attempts to replicate from the peer NAN device.

[0090] In some examples, NAN devices and their peers can exchange PS or DRX configuration parameters using Vendor-Specific Information Elements (VSIEs) or vendor-specific attributes in the NAN Action Frame (NAF). In some examples, DRX parameters can be exchanged after NDP has been established and both devices have agreed on CRB, such as... Figure 4 As described in [the document]. In some examples, DRX configuration parameters may be sent along with the NDP setup message. In some examples, the NDP DRX scheduler ndpDrxCrbs_self is sent along with the NDPRP proposal.

[0091] In the following text, reference will be made to Figure 4 This describes the exchange of DRX configurations between two NAN devices according to an embodiment.

[0092] Figure 4 The exchange of DRX configurations between two NAN devices according to an embodiment is illustrated.

[0093] Reference Figure 4This includes NAN device Dev1, which operates as an NDP responder and NAN device Dev2, which operates as an NDP initiator, including NAN engine 12a and NAN device Dev2, which operates as an NDP initiator.

[0094] In 401, the service / application 11b of NAN device Dev1 sends the publish() event to publish its service to NAN engine 11a.

[0095] In 403, service / application 12b of NAN device Dev2 sends an event subscribe() to NAN engine 12a to subscribe to the service of service / application 11b of NAN device Dev1.

[0096] At 405, NAN Engine 12a of NAN Device Dev2 sends a subscription message to NAN Engine 11a of NAN Device Dev1 to subscribe to the services of NAN Device Dev1's services / applications 11b.

[0097] At 407, NAN engine 11a of NAN device Dev1 sends a publish message to NAN engine 12a of first NAN device 12. In some examples, the publish message can be sent in response to a subscription message. In some examples, NAN device Dev1 can send the publish message as an unsolicited message without receiving subscription messages.

[0098] At 409, the NAN engine 12a of the NAN device Dev2 sends the DiscoveryResult() event to the service / application 12b.

[0099] In some examples, the NAN device Dev2 can receive publish messages to discover services.

[0100] In 411, the NAN engine 11a of NAN device Dev1 and the NAN engine 12a of the first NAN device 12 can perform further service discovery.

[0101] At 413, the service / application 12b of the NAN device Dev2 sends the event DataRequest() to the NAN engine 12a.

[0102] At 415, NAN engine 12a of NAN device Dev2 sends a data path request message to NAN engine 11a of NAN device Dev1.

[0103] At 417, the NAN engine 11a of the second NAN device 11 sends the event DataRequest() to the service / application 11b.

[0104] At 419, the service / application 11b of NAN device Dev1 sends the event DataConfirm() to NAN engine 11a.

[0105] At 421, the NAN engine 11a of NAN device Dev1 sends a data path response message to the NAN engine 12a of the first NAN device 12.

[0106] At 423, the NAN engine 12a of the NAN device Dev2 sends the event DataConfirm() to the service / application 12b.

[0107] At 425, the NAN engine 11a of the second NAN device 11 sends the event DataConfirm() to the service / application 11b.

[0108] In some examples, NAN device Dev1 and NAN device Dev2 can establish an NDP and agree on a set of CRBs for communication on the NDP.

[0109] At 427, the service / application 11b of NAN device Dev1 sends an event to NAN engine 11a that includes the NDPDRX configuration of NAN device Dev1.

[0110] At 429, the service / application 12b of NAN device Dev2 sends an event to NAN engine 12a that includes the NDPDRX configuration of NAN device Dev2.

[0111] At 431, the NAN engine 11a of NAN device Dev1 sends a message including the NDP DRX configuration of NAN device Dev1 to the NAN engine 12a of the first NAN device 12. In some examples, the NDP DRX configuration of NAN device Dev1 may include at least one of the NDP inactivity countdown timer reset value and the NDP DRX schedule of NAN device Dev1.

[0112] At 433, the NAN engine 12a of NAN device Dev2 sends a message including the NDP DRX configuration of NAN device Dev2 to the NAN engine 11a of NAN device Dev1. In some examples, the NDP DRX configuration of the second device 12 may include at least one of an NDP inactivity countdown timer reset value and an NDP DRX schedule for NAN device Dev2.

[0113] like Figure 4As shown, NAN device Dev1 and NAN device Dev2 have an NDP connection between them. Therefore, NAN device Dev1 and NAN device Dev2 have an NDP schedule including a CRB, where the two NAN devices Dev1 and Dev2 can communicate with each other. In some examples, the agreed time and channel resources may be referred to as the CRB.

[0114] The operation of the NDP inactive countdown timer according to various embodiments will be described below.

[0115] The MAC entity in a NAN device can reset the NDP inactivity countdown timer associated with the NDP. For example, a NAN device can reset the timers ndpInactivityTimeout_self and ndpInactivityTimeout_peer on each successful send or receive on the NDP. In some examples, a NAN device can reset the countdown timer by loading a countdown timer with a reset value equal to, but not limited to, the value of the parameter ndpInactivityTimeout_self and starting the timer's countdown.

[0116] In some examples, the NAN device can determine successful transmission or reception when a MAC entity in the NAN device sends an acknowledgment (ACK) frame for a frame received from the NAN Data Interface Address (NDI) of a peer NAN device, for example, but not limited to, during the NDP CRB. In some examples, the moment when the NAN device determines successful reception of a frame can be more precisely defined as the timestamp of the primitive PHY-TXEND.confirm associated with the transmission of the ACK frame, as reported by the PHY layer.

[0117] In some examples, a NAN device can determine successful transmission or reception when it receives an ACK frame for a frame sent to a peer NAN device's NDI during, for example, but not limited to, the NDP CRB. In some examples, the moment can be more precisely defined as the timestamp of the primitive PHY-RXEND.indication associated with the reception of the ACK frame, as reported by the PHY layer.

[0118] For the purpose of resetting the NDP inactivity countdown timer, certain frames may be ignored. For example, frames sent for keep-alive (KA) purposes may be ignored. In some examples, the NDP inactivity timer may not be reset based on KA frames. In some examples, KA frames may be sent by the MAC layer instead of the application layer. In some examples, KA frames may not contain application layer data. In some examples, the purpose of KA frames may be to prevent NDP termination due to inactivity. In some examples, empty data frames may also be ignored for the purpose of resetting the NDP inactivity countdown timer.

[0119] The following will refer to Figure 5 , Figure 6 and Figure 7 The process for determining the expiration of the NDP inactivity countdown timer according to various embodiments is described.

[0120] Figure 5 The expiration of the NDP inactive countdown timer according to an embodiment is shown.

[0121] In some examples, an NDP inactivity countdown timer can be considered expired if the timer value reaches zero. In some examples, such as... Figure 5 As shown, if the value of the NDP inactivity countdown timer reaches 0 during the NDP CRB and after the initial observation window (OW) of the current CRB, the timer can be considered expired. In some examples, the duration of the initial OW can be a fixed or pre-configured value. For example, the duration of the initial OW can be equal to 16 TUs. In some examples, the duration of the OW can be derived or determined based on the duration of the current CRB. In some examples, setting the OW to zero can be equivalent to not having the OW-related conditions required to determine the expiration of the countdown timer. If the OW is greater than 0, it can be advantageous when the peer NAN device may have data in its buffer that it wants to send during a time not belonging to the NDP CRB. For example, the service or application layer can place data in the peer NAN device's MAC buffer during a time when no CRB is available to send the data. Therefore, at the start of the next CRB, the peer NAN device can attempt to acquire the channel and send data on the NDP. An OW greater than 0 can give the peer NAN device the opportunity to send data at the beginning of the CRB. If the peer NAN device still hasn't sent anything and therefore the inactivity timer expires after the initial OW of the current CRB, it can be inferred with greater certainty that the peer indeed has no data, and therefore the NDP remains inactive due to lack of data. Therefore, the expiration of the inactivity timer after the OW likely means that the NDP has been inactive for the duration indicated by the inactivity timer.

[0122] The following text will refer to Figure 6Describes an inactive timer that reaches zero during the initial OW duration of the CRB or outside the CRB.

[0123] Figure 6 The expiration of the NDP inactive countdown timer according to an embodiment is shown.

[0124] In some examples, if the timer reaches zero during the initial OW of the current CRB, the timer may not be considered to have expired during the initial OW of the current CRB. In some examples, if the timer reaches zero during a time not belonging to any CRB, the timer may not be considered to have expired during the initial OW of the next CRB. In some examples, if the timer is not reset during the OW (Long Shift Opportunity) and the timer remains at zero, the timer may be considered to have expired at the end of the OW, or when the total time elapsed in one or more CRBs since the timer reached zero is equal to the total time of the OW (whichever comes first).

[0125] For example, if a timer reaches zero outside of any NDP CRB, the NAN device may not immediately consider the timer to have expired and may continue monitoring another OW during a subsequent NDP CRB. If there is no NDP activity that resets the inactive timer during the OW, the inactive timer may be considered to have expired at the end of the OW.

[0126] In the following text, reference will be made to Figure 7 Describes an inactive timer that reaches zero outside of the CRB according to another embodiment.

[0127] Figure 7 The expiration of the NDP inactive countdown timer according to an embodiment is shown.

[0128] Reference 7: If an inactive countdown timer reaches zero outside of a CRB, the NAN device may not immediately consider the timer to have expired, may continue to monitor subsequent NDP CRBs for another OW, and may reset the timer before it can be considered to have expired after activity is detected on the NDP during the OW.

[0129] As described above, inactive countdown timers can run down naturally and reach zero, but in addition to the timer reaching zero, additional conditions may be needed to account for the timer's expiration. Alternatively, countdown timers can be allowed to run down naturally until they reach a value equal to the duration of OW, which may require additional conditions to allow the timer to continue running down to values ​​below OW, and the inactive timer reaching zero can be considered as having expired. For example, when the value of an NDP inactive countdown timer is less than or equal to the duration of OW, the timer may be required to run only during the NDP CRB and can be paused outside of the NDP CRB.

[0130] The operation of the NAN device in DRX mode will be described below. In particular, the procedure for determining the NDP schedule after the NDP inactivity timer expires will be described.

[0131] After the timer ndpInactivityTimeout_self expires and stops running, the NAN device can enter DRX mode. DRX mode can also be referred to as power saving (PS) mode, reduced scheduling mode, or hibernation. After the timer ndpInactivityTimeout_peer expires and stops running, the NAN device may need to assume that the peer has entered DRX mode.

[0132] After the timer `ndpInactivityTimeout_self` expires and stops running, the NAN device can assume that the peer NAN device will send data to the NAN device on NDP during the CRB period included in the NDP DRX schedule `ndpDrxCrbs_self`. For example, the NAN device can assume that the peer NAN device will only send data to the NAN device on NDP during the CRB period included in the NDP DRX schedule `ndpDrxCrbs_self`. As mentioned above, the DRX schedule `ndpDrxCrbs_self` can be a subset of the original NDP CRB and can be obtained by canceling or deleting some time slots that are part of the original NDP CRB. Since the NAN device does not expect to receive any data from the peer NAN device outside of the NDP DRX schedule `ndpDrxCrbs_self`, the NAN device can enter a sleep state or listen on a different channel to perform another WLAN operation outside of the NDP DRX schedule `ndpDrxCrbs_self`. For example, the NAN device can return to a different channel to connect to the WLAN infrastructure associated with the AP station and can communicate with the AP on a different channel.

[0133] After the timer `ndpInactivityTimeout_peer` expires and is no longer running, the NAN device may need to send frames to the peer NAN device on NDP (e.g., only during the DRX scheduling `ndpDrxCrbs_peer`). Some frames, such as ACK frames, NACK frames, or block ACK (BA) frames, can be exempt from this restriction because these frames are sent in response to frames received from the peer NAN device. For example, the NAN device may need to assume that the peer NAN device is in a dormant state outside of the DRX scheduling `ndpDrxCrbs_peer` in order to send frames to the peer NAN device on NDP.

[0134] In some examples, when a NAN device is in DRX mode after its NDP inactivity timer has expired and it is not running, data transmission may be permitted differently from data reception. In some examples, the expiration of the timer `ndpInactivityTimeout_self` may be irrelevant to when the NAN device can send data to its peer NAN device. For example, when a NAN device is in DRX mode due to the expiration of timer `ndpInactivityTimeout_self` and has data in its MAC egress buffer, if the NAN device is in a sleep state, it can exit sleep mode. Then, assuming the peer NAN device is not in DRX mode, if timer `ndpInactivityTimeout_peer` is running, the NAN device can send data to the peer NAN device on the initial NDP CRB. If the peer NAN device is in DRX mode, the NAN device can send data to the peer NAN device on the DRX scheduler `ndpDrxCrbs_peer`.

[0135] As described above, a NAN device with NDP can operate in either normal or DRX mode based on NDP inactivity. In some examples, DRX mode may have further stages. For example, DRA mode may have a first stage scheduled by the parameter ndpDrxCrbs_stage1_self and a second stage scheduled by the parameter ndpDrxCrbs_stage2_self. In some examples, the NAN device may run an inactivity countdown timer associated with each DRX stage. The expiration of the timer associated with the DRX stage can determine when the associated DRX stage begins. These timers ndpDrxCrbs_stage1_self and ndpDrxCrbs_stage2_self can run in parallel, or one timer can run after the other timer has expired.

[0136] In some examples, the NDP DRX scheduler ndpDrxCrbs_self can be implicitly derived from the NDPCRB based on pre-configured rules. In these scenarios, NAN devices may not need to send this parameter to peer NAN devices, as the peer NAN devices can also derive it themselves without it. For example, the NDP DRX scheduler ndpDrxCrbs_self can be set to equal the NAN Data Cluster (NDC) CRB. In some examples, the resource on which all member devices of the NDC are required to appear can be called the NDC CRB.

[0137] When the timer ndpInactivityTimeout_self expires, the NAN device enters DRX mode. If the NAN device is in DRX mode and detects a successful transmission or reception on NDP, the NAN device can resume activity on NDP, reset the inactivity timer ndpInactivityTimeout_self, exit DRX mode, and resume normal NDP scheduling for any CRBs that were not canceled. Normal NDP scheduling can be referred to as full NDP scheduling. When the timer ndpInactivityTimeout_peer expires, the NAN device can determine that the peer NAN device has entered DRX mode. If the NAN device determines that the peer NAN device is in DRX mode and detects a successful transmission or reception on NDP, the NAN device can resume activity on NDP, reset the inactivity timer ndpInactivityTimeout_peer, assume the peer NAN device has exited DRX mode, and resume normal NDP scheduling. Alternatively, exiting DRX mode can be determined solely based on successful data reception on NDP.

[0138] In the following text, explicit signals indicating the start of DRX mode according to various embodiments will be described.

[0139] As described above, a NAN device can begin operating in DRX mode when the timer ndpInactivityTimeout_self expires, and a NAN device can determine that its peer NAN device has entered DRX mode based on the expiration of the timer ndpInactivityTimeout_peer. In some examples, a NAN device can explicitly indicate to its peer NAN device that it is entering DRX mode. In some examples, a NAN device can explicitly indicate to its peer NAN device that it assumes the peer NAN device has entered DRX mode. In some examples, a NAN device can explicitly indicate to its peer NAN device that it permits the peer NAN device to enter DRX mode.

[0140] For example, a NAN device can send a data frame to a peer NAN device with the Power Management (PM) bit or End of Service Period (EOSP) bit set to 1 in the MAC header to indicate that the NAN device has started DRX mode. Alternatively, the NAN device can send an action frame or management frame to the peer NAN device to indicate that the NAN device has started DRX mode. In some examples, the NAN device can enter DRX mode upon receiving an Ack in response to an action frame, management frame, or data frame indicating the start of DRX mode. In some examples, the NAN device can use the PM bit or EOSP bit in an empty data frame to indicate the start of DRX mode. The NAN device can exit DRX mode upon successfully receiving or sending an NDP associated with it. Messages indicating the start of DRX mode can be ignored for the purpose of resuming normal NDP scheduling or maintaining or resetting NDP inactivity timers. For example, the inactivity timer may not be reset when receiving or sending a message indicating the start of DRX mode.

[0141] When a NAN device receives an indication from its peer NAN device that the peer NAN device is entering DRX mode, the NAN device may assume that the peer NAN device has entered DRX mode. Therefore, as mentioned earlier, the NAN device may need to assume that the peer NAN device is only listening during the DRX scheduling period `ndpDrxCrbs_peer`, and thus the NAN device may only send frames to the peer NAN device on that NDP during the DRX scheduling period `ndpDrxCrbs_peer`. Upon successful transmission or reception associated with the NDP, the NAN device may assume that the peer NAN device has exited DRX mode and resumed normal NDP scheduling.

[0142] A NAN device can indicate the start of DRX mode based on at least one of the following: an inactivity timer (such as timer ndpInactivityTimeout_self), an indication from the application layer to start DRX mode, and the duration during which the MAC buffer associated with the NDP has been empty. The MAC layer at the NAN device can provide an interface to the application layer, through which the application layer can instruct the MAC layer to send a DRX mode start indication to the peer NAN device. If any data exists in the MAC buffer associated with the NDP, the NAN device can complete sending data and clear the queue before indicating the start of DRX mode.

[0143] Figure 8 The operation of two devices based on explicit signals according to an embodiment is illustrated.

[0144] exist Figure 8This involves two NAN devices, Dev1 and Dev2. NAN device Dev2 monitors the timer ndpInactivityTimeout_self to check if the timer has expired. If NAN device Dev2 determines that the timer ndpInactivityTimeout_self has expired, NAN device Dev2 can explicitly indicate the start of its DRX mode and subsequently enter DRX mode by canceling a portion of the original NDP schedule used for listening purposes.

[0145] In some examples, when NAN device Dev2 sends a message including an explicit indication that NAN device Dev2 intends to enter DRX mode, peer NAN device Dev1 may be allowed to accept or reject the request. In some embodiments, NAN device Dev1 may not be granted the right to reject, and may be required to send an acknowledgment of the message only if NAN device Dev1 has correctly decoded the message. Upon receiving the ack, NAN device Dev2 may enter DRX mode.

[0146] In some examples, NAN device Dev2 can wait for a certain duration or time window before entering DRX mode. If NAN device Dev2 receives or transmits on NDP during the time window, it can cancel entering DRX mode. In some examples, if device Dev1 receives or transmits on NDP during the time window, device Dev1 can assume that NAN device Dev2 has canceled DRX mode.

[0147] Upon entering DRX mode, NAN device Dev2 can cancel a portion of the original NDP schedule because NAN device Dev2 stops listening for NDP-related transmissions from NAN device Dev1 on the canceled resources. NAN device Dev2 can continue listening as usual for the resources indicated by the NDP DRX scheduler ndpDrxCrbs_self. In some examples, if NAN device Dev1 needs to send data to NAN device Dev2 on NDP, NAN device Dev1 can send data during the period indicated by the DRX scheduler ndpDrxCrbs_peer, because the resources indicated by the DRX scheduler ndpDrxCrbs_peer in the original NDP schedule have not yet been canceled by NAN device Dev2. Even if NAN device Dev1 does not send to NAN device Dev2 on the canceled resources, NAN device Dev1 can still continue listening for NAN device Dev2 on those canceled resources and the complete NDP schedule because NAN device Dev1 itself has not yet entered its own DRX.

[0148] In some examples, the EOSP bit can be used to convey that the NAN device assumes or permits the peer NAN device to enter DRX mode, rather than conveying the start of DRX mode at the NAN device itself.

[0149] Figure 9 The operation of two devices according to an embodiment is shown.

[0150] In 901, NAN device Dev1 and NAN device Dev2 establish a Neighborhood Aware Network (NAN) data path (NDP).

[0151] In 903, NAN device Dev1 and NAN device Dev2 agree on the CRB set to be used for communication on NDP.

[0152] In step 905, NAN device Dev1 determines the NDP PS configuration parameters ndpInactivityTimeout_self_1 and ndpDrxCrbs_self_1 for NAN device Dev1. In some examples, the NDP PS configuration parameter ndpInactivityTimeout_self_1 can be used to reset the first timer that determines the NDP inactivity of NAN device Dev1. In some examples, when NAN device Dev1 is in DRX mode, the NDP PS configuration parameter NDPDRXCRBself_1 can indicate the canceled portion of the CRB set.

[0153] In 907, the NAN device Dev2 determines the NDP PS configuration parameters ndpInactivityTimeout_self_2 and ndpDrxCrbs_self_2 for the NAN device Dev2. In some examples, the NDP PS configuration parameter ndpInactivityTimeout_self_2 can be used to reset a second timer that determines the NDP inactivity of the NAN device Dev2. In some examples, when the NAN device Dev2 is in DRX mode, the NDP PS configuration parameter NDPDRXCRBself_2 can indicate the canceled portion of the CRB set.

[0154] In some examples, the NDP PS configuration parameter ndpInactivityTimeout_self_2 may be equal to or different from the NDP PS configuration parameter ndpInactivityTimeout_self_1. Similarly, in some examples, the NDP PS configuration parameter ndpDrxCrbs_self_2 may be equal to or different from the NDP PS configuration parameter ndpDrxCrbs_self_1.

[0155] In step 908, NAN device Dev1 determines whether NDP has been inactive in NAN device Dev1 for a first duration. In some examples, the NDP PS configuration parameter ndpInactivityTimeout_self_1 can indicate the first duration, and the elapsed duration can be measured by a first timer. In some examples, NAN device Dev1 can determine that NDP is inactive in NAN device Dev1 for the first duration if it has not successfully transmitted or received data within that first duration.

[0156] In step 909, NAN device Dev2 determines whether NDP has been inactive in NAN device Dev2 for a second duration. In some examples, the NDP PS configuration parameter ndpInactivityTimeout_self_2 can indicate the second duration, and the elapsed duration can be measured by a second timer. In some examples, NAN device Dev2 can determine that NDP is inactive in NAN device Dev2 for the second duration if it has not successfully sent or received data within that second duration.

[0157] In operation 911, NAN device Dev2 sends a first message to NAN device Dev1 indicating when NAN device Dev2 should enter DRX mode. In some examples, the first message may indicate that NAN device Dev2 enters DRX mode when it receives an ACK frame in response to the first message. In some examples, the first message may explicitly indicate that NAN device Dev2 should enter DRX mode immediately. In some examples, the first message may indicate that NAN device Dev2 enters DRX mode when NDP is inactive in NAN device Dev2 for a second duration. In those embodiments, the first message may be sent before operation 909 and after operation 907. In some examples, the first message may include the NDP PS configuration parameter ndpInactivityTimeout_self_2, the NDP PS configuration parameter NDPDRxCRBS_self_2, or both. In those embodiments, the first message may be sent before operation 909 and after operation 907.

[0158] In 913, when NAN device Dev2 determines that NDP is inactive within NAN device Dev2 for a second duration, NAN device Dev2 enters DRX mode. In some examples, when NAN device Dev2 determines that NDP is inactive within NAN device Dev2 for a second duration, NAN device Dev2 may send a first message, and NAN device Dev2 may immediately enter DRX mode. In some examples, when NAN device Dev2 determines that NDP is inactive within NAN device Dev2 for a second duration, NAN device Dev2 may send a first message, and when NAN device Dev2 receives an ACK frame in response to the first message, NAN device Dev2 may enter DRX mode. In some examples, after NAN device Dev2 sends the first message, NAN device Dev2 may continue to monitor whether NDP is inactive within NAN device Dev2 for a second duration. In some examples, if the second duration ends at a time belonging to an active CRB (excluding the observation window (OW) at the start of an active CRB), NAN Device Dev2 can determine that NDP is inactive in NAN Device Dev2 during the second duration. In some examples, if the second duration ends at a time not belonging to any active CRB, and if NDP remains inactive for a predetermined time period within one or more active CRBs, NAN Device Dev2 can determine that NDP is inactive in NAN Device Dev2 during the second duration. In some examples, if the second duration ends at a time belonging to an observation window at the start of an active CRB, and if NDP remains inactive for a predetermined time period within one or more active CRBs, NAN Device Dev2 can determine that NDP is inactive in NAN Device Dev2 during the second duration. In some examples, the predetermined time can be equal to OW. In some examples, NAN Device Dev2 can determine that NDP is inactive in NAN Device Dev2 during the second duration based on a timer reset using a reset value indicated by the NDP PS configuration parameter ndpInactivityTimeout_self_2. In some examples, if NAN device Dev2 enters DRX mode, it can cancel a portion of the CRB set used to receive data on NDP, as indicated by the NDP PS configuration parameter ndpDrxCrbs_self_2. In some examples, it may be permissible for NAN device Dev2 not to listen on NDP during the canceled portion of the CRB set.

[0159] In some examples, NAN Device Dev2 can exit DRX mode when it determines that NDP has become active in NAN Device Dev2. When NAN Device Dev2 exits DRX mode, it can resume the canceled portion of the CRB set and may need to listen for NDP during the CRB set. In some examples, NAN Device Dev2 can determine that NDP has become active in NAN Device Dev2 when it determines that it has successfully sent or received data on NDP. In some examples, NAN Device Dev2 can determine that it has successfully transmitted data on NDP when it sends a data frame to NAN Device Dev1 and receives an ACK frame in response to that data frame from NAN Device Dev1. In some examples, when NAN device Dev2 receives a data frame from NAN device Dev1 and sends an ACK frame to NAN device Dev1 in response to the data frame, NAN device Dev2 can determine that NAN device Dev2 has successfully received data on NDP.

[0160] In 915, NAN device Dev1 can determine that NAN device Dev2 has entered DRX mode based on a first message. In some examples, NAN device Dev1 can determine that NAN device Dev2 enters DRX mode immediately upon sending the first message. In some examples, NAN device Dev1 can determine that NAN device Dev2 has entered DRX mode when NAN device Dev1 sends an ACK frame in response to the first message. In some examples, NAN device Dev1 can determine that NAN device Dev2 has entered DRX mode when NDP is inactive during a second duration. In some examples, NAN device Dev1 can determine that NDP is inactive during the second duration if the second duration ends at a time belonging to an active CRB (excluding the observation window (OW) at the beginning of an active CRB). In some examples, NAN device Dev1 can determine that NDP is inactive during the second duration if the second duration ends at a time not belonging to any active CRB, and if NDP remains inactive for a predetermined time within one or more active CRBs. In some examples, NAN device Dev1 can determine that NDP is inactive during the second duration if the second duration ends at the end of the observation window that belongs to the start of an active CRB, and if NDP remains inactive for a predetermined time in one or more active CRBs. In some examples, the predetermined time can be equal to OW. In some examples, as described above, NAN device Dev1 can determine that NDP is inactive during the second duration based on a timer reset using the reset value indicated by the NDP PS configuration parameter ndpInactivityTimeout_peer_1. The NDP PS configuration parameter ndpInactivityTimeout_peer_1 can be set equal to the received NDP PS configuration parameter ndpInactivityTimeout_self_2. The NDP PS configuration parameter ndpInactivityTimeout_peer_1 can be pre-configured. In some examples, if NAN device Dev2 enters DRX mode, NAN device Dev1 can cancel a portion of the CRB set used to send data on NDP, as indicated by the NDP PS configuration parameter NDPDRxCRB-peer_1. The NDP PS configuration parameter ndpDrxCrbs_peer_1 can be set to be equal to the received NDP PS configuration parameter ndpDrxCrbs_self_2. The NDP PS configuration parameter ndpDrxCrbs_peer_1 can be pre-configured. In some examples, this can prevent NAN device Dev1 from sending data to NAN device Dev2 on NDP during the cancelled portion of the CRB set.

[0161] In some examples, when NAN device Dev1 determines that NDP has become active, NAN device Dev1 can determine that NAN device Dev2 has exited DRX mode. When NAN device Dev2 exits DRX mode, NAN device Dev1 can resume the canceled portion of the CRB set and can be allowed to send data to NAN device Dev2 on NDP during the CRB set. In some examples, when NAN device Dev1 determines that it has successfully sent or received data on NDP, NAN device Dev1 can determine that NDP has become active. In some examples, when NAN device Dev1 sends a data frame to NAN device Dev2 and receives an ACK frame in response to that data frame from NAN device Dev2, NAN device Dev1 can determine that it has successfully transmitted data on NDP. In some examples, when NAN device Dev1 receives a data frame from NAN device Dev2 and sends an ACK frame to NAN device Dev2 in response to the data frame, NAN device Dev1 can determine that NAN device Dev1 has successfully received data on NDP.

[0162] In some examples, when NAN device Dev1 determines that NDP has become active in NAN device Dev2, NAN device Dev1 can determine that NAN device Dev2 has exited DRX mode. When NAN device Dev2 exits DRX mode, NAN device Dev1 can resume the canceled portion of the CRB set and can be allowed to send data to NAN device Dev2 on NDP during the CRB set. In some examples, when NAN device Dev1 determines that NAN device Dev2 has successfully sent or received data on NDP, NAN device Dev1 can determine that NDP has become active in NAN device Dev2. In some examples, when NAN device Dev1 receives a data frame from NAN device Dev2 and sends an ACK frame to NAN device Dev2 in response to the data frame, NAN device Dev1 can determine that NAN device Dev2 has successfully transmitted data on NDP. In some examples, when NAN device Dev1 sends a data frame to NAN device Dev2 and receives an ACK frame in response to that data frame from NAN device Dev2, NAN device Dev1 can determine that NAN device Dev2 has successfully received data on NDP.

[0163] At 921, NAN device Dev1 sends a second message to NAN device Dev2 instructing when NAN device Dev1 should enter DRX mode. In some examples, the second message may explicitly instruct NAN device Dev1 to enter DRX mode immediately. In some examples, the second message may instruct NAN device Dev1 to enter DRX mode when NAN device Dev1 receives an ACK frame in response to the second message. In some examples, the second message may instruct NAN device Dev1 to enter DRX mode when NDP is inactive in NAN device Dev1 for a first duration. In those embodiments, the first message may be sent before operation 908 and after operation 905. In some examples, the second message may include the NDP PS configuration parameter ndpInactivityTimeout_self_1, the NDP PS configuration parameter ndpDrxCrbs_self_1, or both. In those embodiments, the first message may be sent before operation 908 and after operation 905.

[0164] In 923, when NAN device Dev1 determines that NDP is inactive within NAN device Dev1 for a first duration, NAN device Dev1 enters DRX mode. In some examples, when NAN device Dev1 determines that NDP is inactive within NAN device Dev1 for the first duration and NAN device Dev1 can immediately enter DRX mode, NAN device Dev1 may send a second message. In some examples, when NAN device Dev1 determines that NDP is inactive within NAN device Dev1 for the first duration, NAN device Dev1 may send a second message, and when NAN device Dev1 receives an ACK frame in response to the second message, NAN device Dev1 may enter DRX mode. In some examples, after NAN device Dev1 sends the first message, NAN device Dev1 may continue to monitor whether NDP is inactive within NAN device Dev1 for the first duration. In some examples, if the first duration ends at a time belonging to an active CRB (excluding the observation window (OW) at the start of an active CRB), NAN device Dev1 can determine that NDP is inactive in NAN device Dev1 during the first duration. In some examples, if the first duration ends at a time not belonging to any active CRB, and if NDP remains inactive for a predetermined time period within one or more active CRBs, NAN device Dev1 can determine that NDP is inactive in NAN device Dev1 during the first duration. In some examples, if the first duration ends at a time belonging to an observation window at the start of an active CRB, and if NDP remains inactive for a predetermined time period within one or more active CRBs, NAN device Dev1 can determine that NDP is inactive in NAN device Dev1 during the first duration. In some examples, the predetermined time can be equal to OW. In some examples, NAN device Dev1 can determine that NDP is inactive in NAN device Dev1 during the first duration based on a timer reset using a reset value indicated by the NDP PS configuration parameter ndpInactivityTimeout_self_1. In some examples, if NAN device Dev1 enters DRX mode, it can cancel a portion of the CRB set intended for receiving data on NDP, as indicated by the NDP PS configuration parameter ndpDrxCrbs_self_1. In some examples, it may be permissible for NAN device Dev1 not to listen on NDP during the canceled portion of the CRB set.

[0165] In some examples, NAN Device Dev1 can exit DRX mode when it determines that NDP has become active in NAN Device Dev1. When NAN Device Dev1 exits DRX mode, it can resume the canceled portion of the CRB set and may need to listen for NDP during the CRB set. In some examples, NAN Device Dev1 can determine that NDP has become active in NAN Device Dev1 when it determines that it has successfully sent or received data on NDP. In some examples, NAN Device Dev1 can determine that it has successfully transmitted data on NDP when it sends a data frame to NAN Device Dev2 and receives an ACK frame in response to that data frame from NAN Device Dev2. In some examples, when NAN device Dev1 receives a data frame from NAN device Dev2 and sends an ACK frame to NAN device Dev2 in response to the data frame, NAN device Dev1 can determine that NAN device Dev1 has successfully received data on NDP.

[0166] In 925, NAN device Dev2 can determine that NAN device Dev1 has entered DRX mode based on the second message. In some examples, NAN device Dev2 can determine that NAN device Dev1 enters DRX mode immediately upon sending the second message. In some examples, NAN device Dev2 can determine that NAN device Dev1 has entered DRX mode when NAN device Dev2 sends an ACK frame in response to the second message. In some examples, NAN device Dev2 can determine that NAN device Dev1 has entered DRX mode when NDP is inactive for a first duration. In some examples, NAN device Dev2 can determine that NDP is inactive for a first duration if the first duration ends at a time belonging to an active CRB (excluding the observation window (OW) at the beginning of an active CRB). In some examples, NAN device Dev2 can determine that NDP is inactive for a first duration if the first duration ends at a time not belonging to any active CRB, and if NDP remains inactive for a predetermined time within one or more active CRBs. In some examples, NAN device Dev2 can determine that NDP is inactive during the first duration if the first duration ends at the end of the observation window that belongs to the start of an active CRB, and if NDP remains inactive for a predetermined time in one or more active CRBs. In some examples, the predetermined time can be equal to OW. In some examples, as described above, NAN device Dev2 can determine that NDP is inactive during the first duration based on a timer reset using the reset value indicated by the NDP PS configuration parameter ndpInactivityTimeout_peer_2. The NDP PS configuration parameter ndpInactivityTimeout_peer_2 can be set to be equal to the received NDP PS configuration parameter ndpInactivityTimeout_self_1. The NDP PS configuration parameter ndpInactivityTimeout_peer_2 can be pre-configured. In some examples, if NAN device Dev1 enters DRX mode, NAN device Dev2 can cancel a portion of the CRB set used to send data on NDP, as indicated by the NDP PS configuration parameter NDPDRxCRB-peer_2. The NDP PS configuration parameter ndpDrxCrbs_peer_2 can be set to be equal to the received NDP PS configuration parameter ndpDrxCrbs_self_1. The NDP PS configuration parameter ndpDrxCrbs_peer_2 can be pre-configured. In some examples, this can prevent NAN device Dev2 from sending data to NAN device Dev1 on NDP during the cancelled portion of the CRB set.

[0167] In some examples, when NAN device Dev2 determines that NDP has become active, NAN device Dev2 can determine that NAN device Dev1 has exited DRX mode. When NAN device Dev1 exits DRX mode, NAN device Dev2 can resume the canceled portion of the CRB set and can be allowed to send data to NAN device Dev1 on NDP during the CRB set. In some examples, when NAN device Dev2 determines that it has successfully sent or received data on NDP, NAN device Dev2 can determine that NDP has become active. In some examples, when NAN device Dev2 sends a data frame to NAN device Dev1 and receives an ACK frame in response to that data frame from NAN device Dev1, NAN device Dev2 can determine that it has successfully transmitted data on NDP. In some examples, when NAN device Dev2 receives a data frame from NAN device Dev1 and sends an ACK frame to NAN device Dev1 in response to the data frame, NAN device Dev2 can determine that NAN device Dev2 has successfully received data on NDP.

[0168] In some examples, when NAN Device Dev2 determines that NDP has become active in NAN Device Dev1, NAN Device Dev2 can determine that NAN Device Dev1 has exited DRX mode. When NAN Device Dev1 exits DRX mode, NAN Device Dev2 can resume the canceled portion of the CRB set and can be allowed to send data to NAN Device Dev1 on NDP during the CRB set. In some examples, when NAN Device Dev2 determines that NAN Device Dev1 has successfully sent or received data on NDP, NAN Device Dev2 can determine that NDP has become active in NAN Device Dev1. In some examples, when NAN Device Dev2 receives a data frame from NAN Device Dev1 and sends an ACK frame to NAN Device Dev1 in response to the data frame, NAN Device Dev2 can determine that NAN Device Dev1 has successfully transmitted data on NDP. In some examples, when NAN device Dev2 sends a data frame from NAN device Dev1 and receives an ACK frame in response to that data frame from NAN device Dev1, NAN device Dev2 can determine that NAN device Dev1 has successfully received data on NDP.

[0169] Unless otherwise specified, references to elements in the singular form are not intended to refer to one and only one, but rather to one or more. For example, a “one” module can refer to one or more modules. In the absence of further constraints, elements preceded by “a,” “an,” “the,” or “the” do not preclude the presence of additional identical elements.

[0170] Titles and subtitles (if any) are used for convenience only and do not limit this disclosure. Words used exemplarily are intended to serve as examples or illustrations. With regard to the use of terms such as “comprising,” “having,” etc., such terms are intended to be interpreted inclusively in a similar manner to how the term “comprising” is interpreted when used as a transitional word in the claims. Relational terms such as “first” and “second” can be used to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between these entities or actions.

[0171] Phrases such as aspect, that aspect, on the other hand, some aspects, one or more aspects, implementation, that implementation, another implementation, some implementations, one or more implementations, embodiment, that embodiment, another embodiment, some examples, one or more embodiments, configuration, that configuration, another configuration, some configurations, one or more configurations, subject matter, disclosure, this disclosure, other variations thereof, etc., are used for convenience and do not imply that disclosures associated with such phrases are essential to the subject matter, or that such disclosures apply to all configurations of the subject matter. Disclosures associated with such phrases may apply to all configurations or one or more configurations. Disclosures associated with such phrases may provide one or more examples. Phrases such as aspect or some aspects may refer to one or more aspects, and vice versa, and this similarly applies to other foregoing phrases.

[0172] The phrase "at least one" preceding a series of items (where any items are separated by the terms "and" or "or") modifies the list as a whole, not each member of the list. The phrase "at least one of..." does not require the selection of at least one item; rather, it allows for the inclusion of at least one of any one item, and / or at least one of any combination of items, and / or the meaning of at least one of each item. For example, each of the phrases "at least one of A, B, and C" or "at least one of A, B, or C" refers to only A, only B, or only C; any combination of A, B, and C; and / or at least one of each of A, B, and C.

[0173] It should be understood that the specific order or hierarchy of the disclosed steps, operations, or processes is illustrative of exemplary methods. Unless otherwise expressly stated, it should be understood that the specific order or hierarchy of steps, operations, or processes may be performed in a different order. Some steps, operations, or processes may be performed simultaneously, or may be performed as part of one or more other steps, operations, or processes. The appended method claims (if any) present elements of various steps, operations, or processes in a sample order, but this does not imply limitation to the specific order or hierarchy presented. These may be performed serially, linearly, in parallel, or in different orders. It should be understood that the described instructions, operations, and systems can generally be integrated together in a single software / hardware product or packaged into multiple software / hardware products.

[0174] This disclosure is provided to enable any person skilled in the art to practice the various aspects described herein. In some cases, well-known structures and components are shown in block diagram form to avoid obscuring the concept of the subject matter. This disclosure provides numerous examples of the subject matter, and the subject matter is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the principles described herein can be applied to other aspects.

[0175] All structural and functional equivalents of the elements of the various aspects described throughout this disclosure, as known to or hereafter known to those skilled in the art, are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is explicitly stated in the claims. No claim element is to be interpreted pursuant to paragraph 6 of 35 U.S.SC § 112 unless it is explicitly stated using the phrase “means for…” or, in the case of a method claim, using the phrase “steps for…”.

[0176] The title, background art, description of the drawings, abstract, and figures are incorporated herein by reference and are provided as illustrative examples rather than as limiting descriptions. This application is filed on the understanding that they will not be used to limit the scope or meaning of the claims. Furthermore, the detailed description provides illustrative examples, and various features are combined in various embodiments for the purpose of simplifying this disclosure. The approach of this disclosure should not be construed as reflecting an intention to require more features than expressly recited in each claim. Rather, as reflected in the appended claims, the inventive subject matter lies in all features of fewer than those in a single disclosure configuration or operation. The appended claims are incorporated herein by reference, wherein each claim is independently claimed as a separate subject matter.

[0177] The claims are not intended to be limited to the aspects described herein, but rather to conform to the full scope consistent with the language claims and to cover all legal equivalents. Nevertheless, no claim is intended to include subject matter that does not meet the requirements of applicable patent law, nor should they be interpreted in this manner.

Claims

1. An electronic device for facilitating communication in a wireless network, the electronic device comprising: Memory; as well as A processor operatively coupled to the memory, the processor being configured such that: Establish a data path with wireless communication devices; Agree with the wireless communication device on a set of resource blocks for communication on the data path; Send a message to the wireless communication device instructing the electronic device when to cancel a portion of the resource block set, so that the wireless communication device avoids sending data to the electronic device on the data path during the canceled portion of the resource block set; as well as Cancel the portion of the resource block set used for receiving data on the data path, wherein the electronic device is permitted not to listen on the data path during the cancelled portion of the resource block set.

2. The electronic device according to claim 1, wherein, The message indicates that when a response to the message is received, the electronic device cancels the portion of the resource block set. The cancellation of the portion of the resource block set includes: When the response to the message is received, the portion of the resource block set is cancelled.

3. The electronic device according to claim 1 or 2, wherein, The processor is also configured such that: When a successful data transmission or reception associated with the data path is performed, the cancelled portion of the resource block set is restored.

4. The electronic device according to any one of the preceding claims, wherein, The message indicates that when the data path is inactive in the electronic device for a certain period of time, the electronic device cancels the portion of the resource block set. The cancellation of the portion of the resource block set includes: Determine whether the data path is inactive in the electronic device during the duration, and The portion of the resource block set is cancelled based on the determination that the data path is inactive in the electronic device during the duration.

5. The electronic device according to any one of the preceding claims, wherein, Determining whether the data path is inactive in the electronic device during the duration includes: If no successful data transmission or reception associated with the data path occurs during the said duration, it is determined that the data path is inactive in the electronic device during the said duration.

6. The electronic device according to any one of the preceding claims, wherein, The message includes a parameter indicating the duration.

7. The electronic device according to any one of the preceding claims, wherein, Determining whether the data path is inactive in the electronic device during the duration includes: If the duration ends at a time belonging to an active resource block, and the time does not include the observation window located at the beginning of the active resource block, then it is determined that the data path is inactive in the electronic device during the duration.

8. The electronic device according to any one of the preceding claims, wherein, Determining whether the data path is inactive in the electronic device during the duration includes: If the duration ends at a time that does not belong to any active resource block and if the data path remains inactive for a predetermined time in one or more active resource blocks, then the data path is determined to be inactive in the electronic device during the duration.

9. The electronic device according to any one of the preceding claims, wherein, Determining whether the data path is inactive in the electronic device during the duration includes: If the duration ends at the time of an observation window that is located at the beginning of an active resource block, and if the data path remains inactive for a predetermined time in one or more active resource blocks, then it is determined that the data path is inactive in the electronic device during the duration.

10. The electronic device according to any one of the preceding claims, wherein, The message includes information indicating which part of the resource block set was cancelled.

11. The electronic device according to any one of the preceding claims, wherein, The portion of the resource block set is pre-configured.

12. An electronic device for facilitating communication in a wireless network, the electronic device comprising: Memory; as well as A processor operatively coupled to the memory, the processor being configured such that: Establish a data path with wireless communication devices; Agree with the wireless communication device on a set of resource blocks for communication on the data path; Receive from the wireless communication device a message instructing the electronic device when to cancel a portion of the resource block set; as well as Based on the message, the portion of the resource block set used for sending data on the data path is cancelled, wherein during the period of cancellation of the portion of the resource block set, the electronic device avoids sending data to the wireless communication device on the data path.

13. The electronic device according to claim 12, wherein, The message indicates that when a response to the message is received, the wireless communication device cancels the portion of the resource block set. The cancellation of the portion of the resource block set includes: When the response to the message is received, the portion of the resource block set is cancelled.

14. The electronic device according to claim 12 or 13, wherein, The processor is also configured such that: When a successful data transmission or reception associated with the data path is performed, the cancelled portion of the resource block set is restored.

15. The electronic device according to any one of claims 12 to 14, wherein, The message indicates that when the data path is inactive in the wireless communication device for a period of time, the wireless communication device cancels the portion of the resource block set, and The cancellation of the portion of the resource block set includes: Determining that the data path is inactive in the wireless communication device during the duration, and The portion of the resource block set is cancelled based on the determination that the data path is inactive in the wireless communication device during the duration.

Images