Managed peer-to-peer (P2P) groups and related access mechanisms

CN122996643APending Publication Date: 2026-10-27MAXLINEAR INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202580024139.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2024-11-25
Filing Date
2025-01-24
Publication Date
2026-10-27

Smart Images

  • Figure CN122996643A_ABST
    Figure CN122996643A_ABST
Patent Text Reader

Abstract

Techniques for an access point (AP) are disclosed. The access point can include a processing device. The processing device can receive, at the AP, a first stream classification service (SCS) request from a first station (STA). The processing device can receive, at the AP, a second SCS request from a second STA. The processing device can generate, at the AP, a point-to-point (P2P) group that includes the first STA and the second STA. The processing device can signal the P2P group from the AP to the first STA and the second STA using a shared obtained transmission opportunity (TXOP).
Need to check novelty before this filing date? Find Prior Art

Description

Cross-reference to related applications

[0001] This application claims priority to U.S. Provisional Application No. 63 / 624,748, filed January 24, 2024, and U.S. Provisional Application No. 63 / 563,186, filed March 8, 2024, the disclosures of which are incorporated herein by reference in their entirety. Technical Field

[0002] The examples discussed in this disclosure relate to managed peer-to-peer (P2P) groups and related access mechanisms for access points (APs) and sites (STAs). Background Technology

[0003] Unless otherwise stated herein, the materials described herein are not prior art to the claims of this application and are not acknowledged as prior art simply because they are included in this section.

[0004] An access point (AP) is a network hardware device that allows other Wi-Fi® devices to connect to a wired network. As a standalone device, an AP can be connected to a router via a wired connection, but in a wireless router, it can also be an integral part of the router itself. Many wireless data standards have been introduced for wireless access point and wireless router technologies, such as 802.11a, 802.11b, 802.11g, 802.11n (Wi-Fi® 4), 802.11ac (Wi-Fi® 5), 802.11ax (Wi-Fi® 6), and many more.

[0005] The subject matter claimed in this disclosure is not limited to addressing any shortcomings or examples that operate only in environments such as those described above. Rather, this background is provided merely to illustrate an example technical field in which some of the examples described in this disclosure can be practiced. Attached Figure Description

[0006] The examples will be described and explained with additional specificity and detail using the accompanying drawings, in which: Figure 1 An example wireless LAN environment is shown for point-to-point (P2P) communication between a first site (e.g., a laptop) and a second site (e.g., a printer) via Transmission Control Protocol (TCP), exchanging data (D) and acknowledgment (A) frames over a P2P link.

[0007] Figure 2 An example timing diagram is shown for packet switching that triggers Transport Opportunity (TXOP) sharing mode 2.

[0008] Figure 3 An example wireless LAN environment for P2P bidirectional data exchange in a P2P group of three devices is shown.

[0009] Figure 4 An example timing diagram of packet sequences for P2P bidirectional data exchange using a triggered access mechanism is shown.

[0010] Figure 5A An example timing diagram is shown, illustrating the packet sequence of P2P bidirectional data exchange (without acknowledgment (ACK)) using a lightweight contention access mechanism.

[0011] Figure 5B An example timing diagram is shown, illustrating the packet sequence of P2P bidirectional data exchange (with ACK) using a lightweight contention access mechanism.

[0012] Figure 6A An example timing diagram is shown, illustrating the packet sequence of P2P bidirectional data exchange using a lightweight contention access mechanism.

[0013] Figure 6B An example timing diagram is shown, illustrating the packet sequence of P2P bidirectional data exchange using a lightweight contention access mechanism.

[0014] Figure 7 An example timing diagram is shown, illustrating the packet sequence of P2P bidirectional data exchange (with ACK) using a token-based access mechanism.

[0015] Figure 8 A block diagram of an example system configured to perform P2P communication is shown.

[0016] Figure 9 An example flow of P2P communication is shown.

[0017] Figure 10 An example flow of P2P communication is shown.

[0018] Figure 11 An example flow of P2P communication is shown.

[0019] Figure 12 An illustration of a machine in an example form of a computing device is shown, in which a set of instructions can be executed to cause the machine to perform any or more of the methods discussed herein. Detailed Implementation

[0020] There are various applications that use two or more (non-AP) devices (e.g., wireless stations (STAs)) to communicate within the same local area network (LAN), such as document printing, file transfer, internal video streaming, photo browsing, and virtual reality. The actual communication can occur directly or through an intermediary device. In the case of Wi-Fi® technology, direct communication between STAs may not be permitted. Therefore, an access point (AP) can act as an intermediary, where the AP can transmit data from one device to another using consecutive uplink (UL) and downlink (DL) data transactions. In other words, the AP can centralize communication within a shared medium.

[0021] This approach may be inefficient for applications where more direct communication between devices can increase throughput and reduce airtime. Therefore, point-to-point (P2P) communication was established, allowing two STAs to communicate directly for a limited time. For example... Figure 1 As shown, the wireless system 100 may include STA1 120 (e.g., a laptop computer) and STA2 130 (e.g., a printer), which may be associated with AP1 110 (i.e., using the first link 115 and the second link 135 respectively), but can communicate directly with each other via P2P link 125. Communication between STA1 120 and STA2 130 may use Transmission Control Protocol (TCP), which can be used to exchange data frames 121a, 121b, 121c and acknowledgment frames 121d, 121e, 121f via P2P link 125.

[0022] The 802.11be amendment defines a Triggered Transmission Opportunity (TXOP) sharing mechanism, allowing an AP to share its acquired TXOP with a specific STA. This allows the STA to use the time to transmit data to the AP (Mode 1) or to another STA (Mode 2). When a TXOP has been granted to a STA, a P2P link can be established without using the AP to transmit data, and in a contention-free environment.

[0023] For P2P applications, the TCP protocol can be used to send data, which provides data transmission through bidirectional exchange of data / (TCP)ACK frames and adapts the protocol to channel conditions (e.g., ...). Figure 1 (As shown). Other applications, even without using TCP, may rely on closed data loops that could utilize bidirectional communication. For example, virtual reality glasses receive video and audio, but can also send back the glasses' position to adapt to the video image in the next frame.

[0024] The triggered TXOP sharing (mode 2) mechanism can be limited to transmitting data in one direction, such as... Figure 2As shown. An authorized STA can send data to another STA, but that STA cannot receive data from another STA because it lacks a mechanism such as trigger frames. The following text from IEEE 802.11be D5.0 discloses: A non-AP EHT STA may use the time allocated by its associated AP in a MU-RTS TXS trigger frame (which addresses to the STA and whose Triggered TXOP Sharing Mode subfield is equal to 2) to transmit one or more non-TB PPDUs addressed to the AP or another STA. A non-AP EHT STA receiving a MU-RTS TXS trigger frame with a TXOP sharing mode subfield equal to 2 may transmit QoS data or a QoS empty frame, including an HE variant HT control field with a CAS control subfield and an RDG / More PPDU subfield equal to 0, to its associated AP (where the STA receives an EHT capability element from the AP, and the TXOP Return Support in the TXOP sharing mode 2 subfield of that element is set to 1) within the allocated time. Otherwise, the STA may not transmit such frames to its associated AP within the allocated time.

[0025] like Figure 2As shown, block diagram 200 provides the functionality of a triggered TXOP sharing (mode 2) mechanism, which can be limited to data transmission in one direction. As shown in operation 212, AP 210 can send a clear-to-send (CTS)-to-self signal to itself. As shown in operation 214, AP 210 can send a multi-user request-to-send (MU-RTS) TXOP sharing (TXS) trigger frame to STA1 220 and STA2 230, which can be a triggered TXOP sharing mode 2. As shown in operation 222, STA1 220 can send a CTS response to AP 210. As shown in operation 224, STA1 220 can send data to AP 210 in a non-triggered physical layer protocol data unit (TB PPDU). As shown in operation 216, AP 210 can send a block ACK to STA1 220. As shown in operation 226, STA1 220 may send data to STA2 230. As shown in operation 232, STA2 230 may send a block ACK to STA1 220. The time allocated in the MU-RTS TXS trigger frame may include the time between (i) after sending the MU-RTS TXS trigger frame and (ii) after sending a block ACK to STA1 220, as shown in box 252. TXOP 254 may include the time between (i) the start of sending a CTS-to-Self transmission as shown in operation 212 and (ii) the end of sending data from the AP to another STA, as shown in box 218.

[0026] In summary, the TXOP sharing (mode 2) mechanism does not provide optimal functionality for direct communication between two (or more) STA devices using bidirectional data exchange.

[0027] This paper discloses a coordination and scheduling mechanism for creating and managing P2P groups of two or more STA devices, reducing access point overhead, and establishing one-way or two-way communication in a controlled environment.

[0028] Several mechanisms allow bidirectional communication among P2P group members, reducing the overhead of MU TXOP sharing mode 2. First, a lightweight contention mechanism allows P2P group devices to communicate directly without AP intervention, thus enabling bidirectional communication between P2P group members. Second, a token-based mechanism allows P2P group devices to communicate directly without AP intervention, also enabling bidirectional communication between P2P group members.

[0029] Examples of this disclosure will be explained with reference to the accompanying drawings.

[0030] P2P group: The triggered TXOP sharing (Mode 2) mechanism allows data to be sent in one direction during an authorized TXOP, but not in the opposite direction. A mechanism can be used to simplify bidirectional data transmission between two (or more) non-AP STAs to cover application service standards. For a given shared TXOP, a group of P2P STAs can participate in the communication service.

[0031] The access point (AP) may include a processing device that can receive a first stream classification service (SCS) request from a first STA at the AP; receive a second SCS request from a second STA at the AP; generate a peer-to-peer (P2P) group at the AP that includes the first and second STAs; and signal the P2P group from the AP to the first and second STAs using a shared acquired transmission opportunity (TXOP). The first SCS request and / or the second SCS request can have extremely high throughput.

[0032] An Access Point (AP) can schedule its execution over time. In one example, AP scheduling can be periodic. In another example, AP scheduling can be aperiodic. An AP can create and announce the creation of P2P groups. P2P groups can be generated based on Quality of Service (QoS) criteria. An AP can allocate P2P time periods (e.g., within a shared TXOP).

[0033] like Figure 3 As shown, an example wireless LAN environment 300 for P2P bidirectional data exchange for a P2P group of three devices can be a home network application for video entertainment, including STA1 320 (e.g., television (TV)), STA2 330 (e.g., speaker), STA3 340 (e.g., network attached storage (NAS)) and AP 310.

[0034] A P2P group can be declared using a direct link EHT SCS request sent from STAs 320, 330, and 340 to AP 310 via direct links 315a, 315b, and 315c. AP 310 can identify the standards of their public application services and establish P2P groups (e.g., including STAs 320, 330, and 340). AP 310 can schedule its execution over time (periodically or non-periodically). The creation of a P2P group ensures that a specific P2P mechanism can be confined to that group, allowing the use of specific P2P group access mechanisms. STA 1 320 can connect to STA2 330 using connection 325a and to STA3 using connection 325b. STA2 330 can connect to STA3 340 using connection 335. In summary, STA 320, 330, and 340 can request the creation of a public P2P group, AP 310 can create and advertise the group based on QoS standards, and AP 310 can signal the start of the P2P group within the shared TXOP obtained by the AP.

[0035] P2P access mechanism Triggered access Triggered TXOP sharing mode 2 may have limitations for typical P2P applications, in which case the AP sequentially creates P2P links in each direction, such as... Figure 4 As shown in Figure 400, the expected efficiency of a P2P link may be lost compared to trigger-based communication managed by the AP, in which case the AP may not process incoming STA frames and redirect them to its peer.

[0036] Figure 4 The diagram illustrates data exchange in two directions within the same AP TXOP (e.g., the acquired TXOP (AP) 405), which can be divided into two independent shared time slots, one for each STA (e.g., time allocated for STA1 405a and time allocated for STA2 405b). This mechanism allows two STAs 420 and 430 from the same P2P group to exchange data in both directions, avoiding channel contention in each direction. The proposed mechanism can have a similar frame switching structure to that provided by the AP using trigger-based frames. In both cases, AP scheduling capabilities can be utilized.

[0037] like Figure 4As shown, AP 410 can send a first MU-RTS TXS trigger frame to the first STA 420, as shown in operation 412. As shown in operation 414, AP 410 can send a second MU-RTS TXS trigger frame to the second STA 430. AP 410 can receive a first CTS frame from the first STA 420 at AP 410, as shown in operation 422, and receive a second CTS frame from the second STA 430 at AP 410, as shown in operation 434. AP 410 can generate a first-direction P2P link and a second-direction P2P link. AP 410 can generate the first-direction P2P link and the second-direction P2P link sequentially.

[0038] STAs 420 and 430 can send data to each other. As shown in operation 424, STA1 420 can send data to STA2 430. As shown in operation 432, STA2 420 can send an ACK message to STA1 420. As shown in operation 436, STA2 430 can send data to STA1 420. As shown in operation 426, STA1 can send an ACK message to STA1.

[0039] Lightweight competition P2P links can reduce the overhead of AP transmitting data between STAs (one-way or two-way), which can increase airtime efficiency and enhance the performance of P2P applications. Triggered access mechanisms based on triggering STAs to share TXOPs utilize AP intervention when exchanging data bidirectionally in P2P applications.

[0040] In the case of a P2P group with three or more devices, AP scheduling can be more complex. As shown in timing diagram 500a in Figure 5, AP 510 can send a MU-RTS TXS trigger frame to the P2P group as shown in operation 512, and the P2P group (e.g., STA1 520, STA2 530, STA3 540) can send back a CTS frame as shown in operations 522, 532, 542 to acknowledge AP 510.

[0041] When a P2P group includes a small number of devices (e.g., at most four devices), it may result in low congestion. That is, the AP 510 can share the TXOP (e.g., acquired TXOP) with the P2P group and create contention time windows for STAs (e.g., STA1 520, STA2 530, STA3 540). Because the communication of these devices is driven by P2P applications, the shared TXOP may be restricted to specific service or traffic priorities. Therefore, there may not be many access conflicts among P2P group members. Thus, channel access fairness within the same P2P group can be achieved.

[0042] Compared to using Distributed Coordination Function (DCF) rules, the lightweight contention mechanism reduces the time spent acquiring the channel. The Contention Window (CW) backoff parameter can be smaller to reduce channel access time and improve efficiency by reducing overhead. In single-service priority, Access Class (AC) distinctions can be omitted; therefore, devices can begin contention after waiting for the DCF inter-frame interval (DIFS) time. DIFS can be omitted when acknowledgment frames are not used because it allows other devices to access the medium with higher priority; therefore, a short inter-frame interval (SIFS) time can be used instead. DIFS can be used when acknowledgment frames are used because frames with different priorities may exist.

[0043] The STA may include a processing device that can (i) receive a MU-RTS TXS trigger frame from the AP at the STA; (ii) send a CTS frame from the STA to the AP; (iii) send first data from the STA to an additional STA during the TXOP of the MU-RTS TXS trigger frame; and (iv) receive second data from the additional STA at the STA during the TXOP of the MU-RTS TXS trigger frame.

[0044] In response to sending the first data to the additional STA, the STA can receive an ACK message from the additional STA at its own location. The STA can receive the ACK message after the SIFS time. The STA can receive the second data from the additional STA at its own location after CW backoff. The STA can receive the second data from the additional STA at its own location after the DIFS time.

[0045] Figure 5A and Figure 5B The contention mechanisms for reducing complexity in three-device P2P groups with and without acknowledgment are illustrated. In the first case, the STA device skips DIFS and backs off a small contention window, expecting a very low collision rate because data traffic is driven by a common application service. With acknowledgment frames, contention can allow these higher-priority frames. Therefore, the STA device waits for the DIFS time before initiating the backoff period.

[0046] like Figure 5AAs shown, timing diagram 500a is provided. The obtained TXOP 505 may include a selected duration. The time allocated to the P2P group may include a selected duration (e.g., from the start of CTS until the end of data transmission, as shown in operation 544). As shown in operation 511, AP 510 may send a self-cleaning transmit signal. As shown in operation 512, AP 510 may send MU-RTS TXS trigger frames to STA1 520, STA2 530, and STA3 540. As shown in operation 522, STA1 520 may send CTS to AP. As shown in operation 532, STA2 530 may send CTS to AP 510. As shown in operation 542, STA3 540 may send CTS to AP 510. As shown in operation 524, STA1 520 may send data to STA2 530. CW backoff may occur after data is sent from STA1 520 to STA2 530. CW backoff can occur without waiting for the DIFS time. As shown in operation 534, STA2 530 can send data to STA1 520. As shown in operation 526, STA1 520 can send additional data to STA2 530. As shown in operation 544, STA3 540 can send data to STA1 520.

[0047] like Figure 5B As shown, timing diagram 500b is provided. Figure 5B The same reference numerals in the figures can have the same Figure 5B The same reference numerals in the accompanying drawings describe the same functions. As shown in operation 524, data sent from STA1 510 to STA2 520 can be acknowledged by STA2 520, as shown in operation 533. As shown in operation 534, data sent from STA2 530 to STA1 520 can be acknowledged by STA1 520, as shown in operation 525. As shown in operation 544, data sent from STA3 540 to STA1 520 can be acknowledged by STA1 520, as shown in operation 527.

[0048] AP 510 can update the network allocation vector (NAV) counter of the network by sending a self-cleaning transmit frame, as shown in operation 511, and reserves a TXOP for itself. When the AP sends a multi-user (MU) trigger frame to establish a P2P link, the AP resets the NAV counter of the P2P group, so the P2P group can begin contention for the channel. This is a lightweight DCF mechanism embedded in the shared TXOP, which can improve the air-time efficiency of a small number of P2P devices.

[0049] like Figure 6AAs shown in timing diagram 600a, the TXOP (e.g., acquired TXOP 605) time window granted to AP 610 can be considered as a local contention period for the P2P group (e.g., STA1 620, STA2 630, STA3 640) under low congestion conditions. AP 610 can grant time to allow data exchange in multiple directions within the group. To improve latency, the MU-RTS TXS trigger frame sent by AP 610 may include a user information field to set the Enhanced Distributed Channel Access (EDCA) parameters of the P2P group (e.g., reducing the Arbitration Inter-Frame Spacing (AISFN) and CW). More than one user information field covering the P2P group can be sent. As shown in operation 611, AP 610 can send a CTS to itself, and as shown in operation 612, an MU-RTS trigger frame is sent from AP to the P2P group.

[0050] The triggered TXOP sharing mode can send a MU-RTS TXS trigger frame to the STA members in the P2P group (e.g., STA1 620, STA2 630, STA3 640). After receiving the MU-RTS TXS trigger frame, the STA members in the P2P group can send a CTS frame to the AP, as shown in operations 622, 632, and 642. After the CTS frame is sent, lightweight contention can begin among the P2P group members (e.g., STA1 620, STA2 630, STA3 640) until the time allocated to that P2P group expires.

[0051] During a lightweight contention, STA1 620 can send data to STA2 630, as shown in operation 624. As shown in operation 634, STA2 630 can send an ACK to STA1 620. SIFS may occur before STA2 630 sends an ACK to STA1 620. After STA2 630 sends an ACK to STA1 620, a lightweight contention may occur. After the lightweight contention, STA2 630 can send data to STA1 620, as shown in operation 636. STA1 620 can send an ACK to STA2 630, as shown in operation 626. Another lightweight contention may occur before STA3 640 sends data to STA1 620, as shown in operation 644. STA1 620 can send an ACK to STA3 640, as shown in operation 628. After operation 628, the lightweight contention period can end. Therefore, the lightweight contention period begins after the CTS frame is transmitted and ends after STA1 620 sends an ACK to STA3. This lightweight contention period is a subset of the time allocated to the P2P group.

[0052] Figure 6BThe timing diagram is shown in the figure. Figure 6B and Figure 6A Similar reference numerals in the diagram can have similar functions. After sending a CTS frame, the NAV counter of the P2P group can be reset, allowing the P2P group to begin competing for the channel using lightweight contention mode. Other STA devices, including Overlapping Basic Service Set (OBSS) devices, may not change the NAV and may consider the channel busy. Another internal timer can count the remaining time of the allocated time. Once the allocated time has ended, the P2P group can restore the BSS NAV.

[0053] Several options exist for achieving lightweight contention during a P2P group contention cycle. For example, high-performance EDCA parameters (AISFN and CW) can be used. Voice access categories can be used to define these values. A small number of devices may be used during contention. Devices can have application-driven Quality of Service (QoS) data traffic and can have transmission ordering.

[0054] In summary, triggered TXOP sharing mode can be used, enabling QoS P2P group members to have lightweight contention cycles. MU-RTS TXS trigger frames can support more than one user information field. P2P group STAs can reset their NAV counters and begin lightweight contention after sending a CTS frame. P2P group STAs can maintain an internal counter for the AP allocation time. After the allocated time expires, P2P group STAs can restore the BSS TXOP NAV counters. Depending on the nature of the application, different lightweight contention options may be available.

[0055] P2P communication links for some QoS time-sensitive applications have been provided, along with current limitations on on-channel P2P mechanisms for bidirectional communication (closed-loop). Based on the P2P group concept, a triggered TXOP sharing mode can be used to allow direct communication with P2P groups. A lightweight contention mechanism can improve transmission efficiency and reduce end-to-end communication latency.

[0056] There are various other ways to implement P2P access mechanisms. In one example, a contention-free approach using a fixed IFS can be provided. Assuming the application has a fixed data transmission order, contention can be eliminated, and a fixed xIFS interval can be set between frames when there are no collisions.

[0057] In another example, token-based arbitration can be used. As an additional mechanism to avoid conflicts, a token-based arbitration mechanism can be used to allow P2P group members to transmit data. Tokens can be passed between members (using different strategies).

[0058] Token-based channel access P2P groups can use a token-based mechanism to allow P2P devices to access the channel, instead of a contention-based mechanism within a shared TXOP window. The token can be signaled in the 802.11 MAC header or 802.11 PHY header (e.g., reserved bits in the Universal Signaling Field (U-SIG)), following a round-robin algorithm. Assuming the P2P group devices are aware of each other, the token can use the STA ID to authorize the next device to access the channel. The token can be passed over the data frame or until the STA transmit buffer is empty.

[0059] A station (STA) may include processing equipment operable to: receive a Multi-User Request Transmission (MU-RTS) TXOP Share (TXS) trigger frame from an access point (AP) at the STA; send a Clear Transmission (CTS) frame from the STA to the AP; receive a channel access token from the AP at the STA; send first data to different STAs at the STA; and send channel access tokens to different STAs at the STA. The channel access token may include a station identifier. The channel access token may be signaled using one or more of an 802.11 Media Access Control (MAC) header or an 802.11 Physical Layer (PHY) header. In response to sending the first data to an additional STA, the STA may receive an acknowledgment (ACK) message from the additional STA at the STA. The ACK message may be received after a Short Interframe Space (SIFS) time.

[0060] Figure 7 Example timing diagram 700 shows a P2P frame exchange using a token-based mechanism. Tokens can be sent on data frames, where the next STA can use the SIFS time after the previously transmitted acknowledgment frame. No collisions occur during the shared TXOP time when tokens arbitrate channel access. Initially, the AP can update the NAV counter of the network devices. Each STA that receives the token can send a frame.

[0061] like Figure 7As shown, AP 710 can send a self-cleaning transmission to itself, as shown in operation 711. As shown in operation 712, AP 710 can send MU-RTS TXS trigger frames to STA1 720, STA2 730, and STA3 740. AP 710 can send a token to STA1 720. As shown in operation 722, STA1 720 can send a CTS to AP 710. As shown in operation 732, STA2 730 can send a CTS to AP 710. As shown in operation 742, STA3 740 can send a CTS to AP 710. As shown in operation 724, STA1 720 can send data to STA2 730 and can also send a token to STA2 730. After operation 724, an SIFS timeout may occur. After the SIFS timeout, as shown in operation 734, STA2 730 can send an ACK to STA1 720. Following the ACK in operation 734, DIFS and CW backoff can occur. As shown in operation 736, STA2 730 can send data to STA1 720 and a token to STA3 740. As shown in operation 726, STA1 720 can send an ACK. As shown in operation 744, STA3 740 can send data to STA1 720 and a token to STA1 720. As shown in operation 728, STA1 720 can send an ACK to STA3 740. The time allocated to the P2P group can begin after operation 712 and end after operation 728.

[0062] Figure 8 A block diagram of an example communication system 800 configured for P2P communication according to at least one example described in this disclosure is shown. The communication system 800 may include a digital transmitter 802, radio frequency circuitry 804, device 814, digital receiver 806, and processing device 808. The digital transmitter 802 and processing device 808 are configured to receive baseband signals via connection 810. Transceiver 816 may include the digital transmitter 802 and radio frequency circuitry 804.

[0063] In some examples, communication system 800 may include device systems configured to communicate with each other via wired or wired connections. For example, a wired connection in communication system 800 may include one or more Ethernet cables, one or more fiber optic cables, and / or other similar wired communication media. Alternatively or additionally, communication system 800 may include device systems configured to communicate via one or more wireless connections. For example, communication system 800 may include one or more devices configured to transmit and / or receive radio waves, microwaves, ultrasound, light waves, electromagnetic induction, and / or similar wireless communications. Alternatively or additionally, communication system 800 may include a combination of wireless and / or wired connections. In these and other examples, communication system 800 may include one or more devices configured to acquire a baseband signal, perform one or more operations on the baseband signal to generate a modified baseband signal, and transmit the modified baseband signal to, for example, one or more loads.

[0064] In some examples, communication system 800 may include one or more communication channels that can communicatively couple systems and / or devices included in communication system 800. For example, transceiver 816 may be communicatively coupled to device 814.

[0065] In some examples, transceiver 816 may be configured to acquire a baseband signal. For example, as described herein, transceiver 816 may be configured to generate a baseband signal and / or receive a baseband signal from another device. In some examples, transceiver 816 may be configured to transmit a baseband signal. For example, after acquiring the baseband signal, transceiver 816 may be configured to transmit the baseband signal to a separate device, such as device 814. Alternatively or additionally, transceiver 816 may be configured to modify, adjust, and / or transform the baseband signal before transmitting it. For example, transceiver 816 may include a quadrature upconverter and / or a digital-to-analog converter (DAC) configured to modify the baseband signal. Alternatively or additionally, transceiver 816 may include a direct radio frequency (RF) sampling converter configured to modify the baseband signal.

[0066] In some examples, digital transmitter 802 may be configured to acquire a baseband signal via connection 810. In some examples, digital transmitter 802 may be configured to up-convert the baseband signal. For example, digital transmitter 802 may include an orthogonal up-converter applied to the baseband signal. In some examples, digital transmitter 802 may include an integrated digital-to-analog converter (DAC). The DAC can convert the baseband signal into an analog signal or a continuous-time signal. In some examples, the DAC architecture may include a direct RF sampling DAC. In some examples, the DAC may be a component separate from digital transmitter 802.

[0067] In some examples, transceiver 816 may include one or more sub-components that can be used to prepare and / or transmit baseband signals. For example, transceiver 816 may include an RF front-end (e.g., in a wireless environment) that may include a power amplifier (PA), a digital transmitter (e.g., 802), a digital front-end, an IEEE 1588v2 device, a Long Term Evolution (LTE) physical layer (L-PHY), an (S-plane) device, a management plane (M-plane) device, an Ethernet Media Access Control (MAC) / Personal Communication Services (PCS), a resource controller / scheduler, etc. In some examples, the radio of transceiver 816 (e.g., RF circuitry 804) may be synchronized with the resource controller via the S-plane device, which facilitates high-precision timing relative to a reference clock.

[0068] In some examples, transceiver 816 may be configured to acquire a baseband signal for transmission. For example, transceiver 816 may receive a baseband signal from a separate device, such as a signal generator. The baseband signal may, for example, originate from the audio signal output of a transducer configured to convert variables into electrical signals, such as a microphone picking up a speaker's speech. Alternatively or additionally, transceiver 816 may be configured to generate a baseband signal for transmission. In these and other examples, transceiver 816 may be configured to transmit a baseband signal to another device, such as device 814.

[0069] In some examples, transceiver 816 can be configured to receive transmissions from transceiver 816. For example, transceiver 816 can be configured to send baseband signals to device 814.

[0070] In some examples, the radio frequency circuit 804 may be configured to transmit digital signals received from the digital transmitter 802. In some examples, the radio frequency circuit 804 may be configured to transmit digital signals to the device 814 and / or the digital receiver 806. In some examples, the digital receiver 806 may be configured to receive digital signals from the RF circuit and / or transmit digital signals to the processing device 808.

[0071] In some examples, as shown, processing device 808 may be a standalone device or system. Alternatively or additionally, processing device 808 may be a component of another device and / or system. For example, in some examples, processing device 808 may be included in transceiver 816. When processing device 808 is a standalone device or system, processing device 808 may be configured to communicate with additional devices and / or systems located remotely from processing device 808, such as transceiver 816 and / or device 814. For example, processing device 808 may be configured to send and / or receive transmissions from transceiver 816 and / or device 814. In some examples, processing device 808 may be integrated with other elements of communication system 800.

[0072] Figure 9 A processing flow of an example method 900 for P2P communication according to at least one example described in this disclosure is shown. Method 900 can be arranged according to at least one example described in this disclosure. Method 900 can be executed by processing logic, which may include hardware (circuit, dedicated logic, etc.), software (e.g., software running on a computer system or dedicated machine), or a combination of both. This processing logic may be included in a processor (e.g., Figure 12 Processing equipment 1202) Figure 8 The communication system 800 or another device, combination of devices or system.

[0073] Method 900 may begin at box 905, where the processing logic may receive a first-stream classification service (SCS) request from the first site (STA) at the AP.

[0074] At box 910, the processing logic can receive the second SCS request from the second STA at the AP.

[0075] At box 915, the processing logic can generate a point-to-point (P2P) group at the AP that includes the first STA and the second STA.

[0076] At box 920, the processing logic can use the shared acquired transmission opportunity (TXOP) to signal the P2P group from the AP to the first STA and the second STA.

[0077] Method 900 may be modified, added to, or omitted without departing from the scope of this disclosure. For example, in some examples, method 900 may include any number of other components that may not be explicitly shown or described.

[0078] Figure 10 The processing flow of an example method 1000 for P2P communication according to at least one example described in this disclosure is shown. Method 1000 can be arranged according to at least one example described in this disclosure.

[0079] Method 1000 can be executed by processing logic, which may include hardware (circuit, special-purpose logic, etc.), software (e.g., software running on a computer system or special machine), or a combination of both. This processing logic may be included in a processor (e.g., Figure 12 Processing equipment 1202) Figure 8 The communication system 800 or another device, combination of devices or system.

[0080] Method 1000 may begin at box 1005, wherein the processing logic may receive a Multi-User Request Transmission (MU-RTS) TXOP Share (TXS) trigger frame from the access point (AP) at the STA.

[0081] In box 1010, the processing logic can send a Clear Transmit (CTS) frame from the STA to the AP.

[0082] In box 1015, the processing logic can send the first data from the STA to the attached STA during MU-RTS TXS.

[0083] At box 1020, the processing logic can receive second data from the additional STA at the STA during MU-RTS-TXS.

[0084] Method 1000 may be modified, added to, or omitted without departing from the scope of this disclosure. For example, in some examples, method 1000 may include any number of other components that may not be explicitly shown or described.

[0085] Figure 11 The processing flow of an example method 1100 for P2P communication according to at least one example described in this disclosure is shown. Method 1100 can be arranged according to at least one example described in this disclosure.

[0086] Method 1100 can be executed by processing logic, which may include hardware (circuit, special-purpose logic, etc.), software (e.g., software running on a computer system or special machine), or a combination of both. This processing logic may be included in a processor (e.g., Figure 12 Processing equipment 1202) Figure 8 The communication system 800 or another device, combination of devices or system.

[0087] Method 1100 may begin at box 1105, wherein the processing logic may receive a Multi-User Request Transmission (MU-RTS) TXOP Share (TXS) trigger frame from the access point (AP) at the STA.

[0088] At box 1110, the processing logic can send a Clear Transmit (CTS) frame from the STA to the AP.

[0089] At box 1115, the processing logic can receive the channel access token from the AP at the STA.

[0090] At box 1120, the processing logic can send the first data to different STAs at the STA.

[0091] At box 1125, the processing logic can send channel access tokens to different STAs at the STA.

[0092] Method 1100 may be modified, added to, or omitted without departing from the scope of this disclosure. For example, in some examples, method 1100 may include any number of other components that may not be explicitly shown or described.

[0093] For the sake of simplicity, the methods and / or processes described herein are depicted and described as a series of actions. However, actions according to this disclosure may occur in various orders and / or simultaneously, and may occur with other actions not presented and described herein. Furthermore, not all actions shown can be used to implement the methods according to the disclosed subject matter. Moreover, those skilled in the art will understand and appreciate that these methods may alternatively be represented by a series of related states through state diagrams or events. Furthermore, the methods disclosed in this specification can be stored on an article of manufacture such as a non-transitory computer-readable medium to facilitate the transfer and assignment of these methods to a computing device. The term "article of manufacture" as used herein is intended to include a computer program accessible from any computer-readable device or storage medium. Although illustrated as discrete boxes, various boxes may be divided into additional boxes, combined into fewer boxes, or eliminated depending on the desired implementation.

[0094] Figure 12 An illustration shows a machine in an example form of computing device 1200, in which a set of instructions can be executed to cause the machine to perform any or more methods discussed herein. Computing device 1200 may include a rack server, router computer, server computer, mainframe computer, laptop computer, tablet computer, desktop computer, or any computing device having at least one processor, etc., in which a set of instructions can be executed to cause the machine to perform any or more methods discussed herein. In alternative examples, the machine may be connected (e.g., networked) to other machines in a local area network (LAN), intranet, extranet, or the Internet. The machine may operate with the capabilities of a server machine in a client-server network environment. Furthermore, although only a single machine is shown, the term "machine" may also include any collection of machines that individually or jointly execute a set (or more) of instructions to perform any or more methods discussed herein.

[0095] Example computing device 1200 includes processing device 1202, main memory 1204 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM)), static memory 1206 (e.g., flash memory, static random access memory (SRAM)) and data storage device 1216, which communicate with each other via bus 1208.

[0096] Processing device 1202 represents one or more general-purpose processing devices, such as microprocessors, central processing units, etc. More specifically, processing device 1202 may include complex instruction set computing (CISC) microprocessors, reduced instruction set computing (RISC) microprocessors, very long instruction word (VLIW) microprocessors, or processors implementing other instruction sets or combinations thereof. Processing device 1202 may also include one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 1202 is configured to execute instructions 1226 for performing the operations and steps discussed herein.

[0097] The computing device 1200 may also include a network interface device 1222 capable of communicating with the network 1218. The computing device 1200 may also include a display device 1210 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 1212 (e.g., a keyboard), a cursor control device 1214 (e.g., a mouse), and a signal generation device 1220 (e.g., a speaker). In at least one example, the display device 1210, the alphanumeric input device 1212, and the cursor control device 1214 may be combined into a single component or device (e.g., an LCD touchscreen).

[0098] Data storage device 1216 may include computer-readable storage medium 1224 on which one or more sets of instructions 1226 are stored, the instructions 1226 embodying any one or more methods or functions described herein. During execution of the instructions 1226 by computing device 1200, the instructions 1226 may also reside wholly or at least partially within main memory 1204 and / or processing device 1202, which also constitute computer-readable media. These instructions may also be transmitted or received on network 1218 via network interface device 1222.

[0099] Although computer-readable storage medium 1224 is shown as a single medium in the example, the term "computer-readable storage medium" can include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) storing one or more sets of instructions. The term "computer-readable storage medium" can also include any medium capable of storing, encoding, or carrying a set of machine-executable instructions and causing the machine to perform any one or more methods of this disclosure. Therefore, the term "computer-readable storage medium" can include, but is not limited to, solid-state memory, optical media, and magnetic media.

[0100] In some examples, the different components, modules, engines, and services described herein can be implemented as objects or processes that execute on a computing system (e.g., as separate threads). While some of the systems and methods described herein are generally described as being implemented in software (stored on and / or executed by hardware), specific hardware implementations or combinations of software and specific hardware implementations are possible and anticipated.

[0101] The terms used herein, and especially those used in the appended claims (e.g., the body of the appended claims), generally refer to “open-ended” terms (e.g., the term “including” should be interpreted as “including, but not limited to”, the term “having” should be interpreted as “having at least”, the term “includes” should be interpreted as “including, but not limited to”, etc.).

[0102] Furthermore, if there is an intention to introduce a specific number of claim statements, this intention will be explicitly stated in the claims, and without such a statement, there is no such intention. For example, to aid understanding, the appended claims may contain the use of introductory phrases “at least one” and “one or more” to introduce the claim statements. However, the use of such phrases should not be construed as implying that a claim statement introduced by the indefinite article “a” or “an” limits any particular claim containing such an introduced claim statement to containing only one instance of such a statement, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and / or “an” should be interpreted as meaning “at least one” or “one or more”); the same applies to the use of definite articles used to introduce claim statements.

[0103] Furthermore, even if the specific number of claims in the introduced claims is explicitly stated, it should be understood that such a statement should be interpreted as indicating at least the number of claims (e.g., the simple statement "two statements" without other modifiers indicates at least two statements, or two or more statements). Additionally, in cases where conventions such as "at least one of A, B, and C" or "one or more of A, B, and C, etc." are used, this structure is generally intended to include a single A, a single B, a single C, A and B together, A and C together, B and C together, or A, B, and C together, etc. For example, the use of the term "and / or" is intended to be interpreted in this manner.

[0104] Furthermore, in the specification, claims, or drawings, any separating word or phrase indicating two or more alternative terms should be understood to include the possibility of including one term, another term, or both terms. For example, the phrase "A or B" should be understood to include the possibility of including "A" or "B" or "A and B".

[0105] Furthermore, the use of terms such as "first," "second," and "third" in this document does not necessarily imply a specific order or number of elements. Generally, the terms "first," "second," and "third" are used to distinguish different elements as general identifiers. Unless it is explicitly stated that the terms "first," "second," and "third" imply a specific order, these terms should not be construed as implying a specific order. Similarly, unless it is explicitly stated that the terms "first," "second," and "third" imply a specific number of elements, these terms should not be construed as implying a specific number of elements. For example, a first component can be described as having a first side, and a second component can be described as having a second side. The use of the term "second side" regarding the second component may be to distinguish this side of the second component from the "first side" of the first component, rather than implying that the second component has two sides.

[0106] All examples and conditional language cited herein are intended as teaching aids to help readers understand the invention and the concepts contributed by the inventors to the field, and should be interpreted as not being limited to these specifically cited examples and conditions. Although examples of this disclosure have been described in detail, it should be understood that various changes, substitutions, and modifications can be made thereto without departing from the spirit and scope of this disclosure.

Claims

1. An access point (AP), comprising: Processing equipment, the processing equipment being operable to: At the AP, a first-stream classification service (SCS) request is received from the first site (STA). Receive the second SCS request from the second STA at the AP; A point-to-point (P2P) group is generated at the AP, the P2P group including the first STA and the second STA; as well as Using the shared acquired transmission opportunity (TXOP), the AP signals the P2P group to the first STA and the second STA.

2. The AP according to claim 1, wherein, AP scheduling can be periodic or aperiodic.

3. The AP according to claim 1, wherein, The P2P group is generated based on the Quality of Service (QoS) standard.

4. The AP according to claim 1, wherein, The processing device can also be operated to allocate P2P time periods.

5. The AP according to claim 1, wherein, The first SCS request and the second SCS request are both high-throughput EHTs.

6. The AP according to claim 1, wherein, The processing device can also be operated to: Send a first multi-user request to the first STA to send a MU-RTS TXOP shared TXS trigger frame; and Send a second multi-user request to the second STA to send a MU-RTS TXOP shared TXS trigger frame.

7. The AP according to claim 1, wherein, The processing device can also be operated to: At the AP, a first clear transmission CTS frame is received from the first STA; and The second clear transmission CTS frame is received from the second STA at the AP.

8. The AP according to claim 1, wherein, The processing device can also be operated to sequentially generate a first-direction P2P link and a second-direction P2P link.

9. A site STA, comprising: Processing equipment, the processing equipment being operable to: At the STA, a multi-user request to send a MU-RTS transmission opportunity TXOP shared TXS trigger frame is received from the access point AP. Send a clear transmission CTS frame from the STA to the AP; During the TXOP of the MU-RTS TXS trigger frame, first data is sent from the STA to the attached STA; as well as During the TXOP of the MU-RTS-TXS trigger frame, second data is received at the STA from the additional STA.

10. The STA according to claim 9, wherein, The processing device can also be operated to: In response to sending the first data to the additional STA, an ACK message is received at the STA from the additional STA.

11. The STA according to claim 10, wherein, The ACK message is received after the short inter-frame interval (SIFS).

12. The STA according to claim 9, wherein, The processing device can also be operated to: After the contention window (CW) is avoided, the second data is received at the STA from the additional STA.

13. The STA according to claim 9, wherein, The processing device can also be operated to: The second data is received at the STA from the additional STA after the Distributed Coordination Function Inter-Frame Interval (DIFS) time.

14. The STA according to claim 9, wherein, The MU-RTS TXS trigger frame includes multiple user fields for setting one or more EDCA parameters for the STA and the additional STA.

15. The STA according to claim 9, wherein, The processing device can also be operated to: Reset the network allocation vector NAV counter at the STA to initiate lightweight contention mode; An internal counter for the allocation time from the AP is maintained at the STA; as well as When the allocation time expires, the Basic Service Set (BSS) TXOP NAV counter for the STA is restored at the STA.

16. A site STA, comprising: Processing equipment, the processing equipment being operable to: At the STA, a multi-user request is received from the access point AP to send a MU-RTS TXOP shared TXS trigger frame; Send a clear transmission CTS frame from the STA to the AP; The STA receives a channel access token from the AP. The first data is sent from the STA to the attached STA. as well as The channel access token is sent from the STA to the additional STA.

17. The STA according to claim 16, wherein, The channel access token includes a site identifier.

18. The STA according to claim 16, wherein, The channel access token is signaled using one or more of the 802.11 Media Access Control (MAC) header or the 802.11 Physical Layer (PHY) header.

19. The STA according to claim 16, wherein, The processing device can also be operated to: In response to sending the first data to the additional STA, an ACK message is received at the STA from the additional STA.

20. The STA according to claim 19, wherein, The ACK message is received after the short inter-frame interval (SIFS).