Communication apparatus and communication method for transmission opportunity allocation

Abstract

The present disclosure relates generally to a first access point (AP) comprising: circuitry, which in operation, generates a frame for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for a second AP to transmit data in a basic service set (BSS) of the second AP; and a transmitter, which in operation, transmits the frame to the second AP.

Description

COMMUNICATION APPARATUS AND COMMUNICATION METHOD FOR TRANSMISSION OPPORTUNITY ALLOCATIONTECHNICAL FIELD

[0001] The present disclosure relates generally to communication apparatuses and communication methods, and more particularly, access points and communication methods for transmission opportunity allocation.BACKGROUND

[0002] Enhancements to technical standards for wireless communication are studied in groups within IEEE 802. The Ultra High Reliability (UHR) Study Group (SG), which is one of the Study Groups working on amendments to the wireless LAN standard for the next generation, was approved with objectives to: (i) increase throughput at different Signal to Interference and Noise Ratio (SINR) level; (ii) reduce latency; and (iii) improve reliability. In UHR, multi-access point (M-AP) coordination is considered an important feature to increase throughput and reliability. Current M-AP coordination schemes include coordinated timedivision multiple access (C-TDMA), coordinated orthogonal frequency division multiple access (C-OFDMA), coordinated spatial reuse (C-SR), and coordinated beamforming (C-BF), among others. Of these, C-TDMA primarily involves a sharing access point (AP) that allocates time resources to one or more shared APs within its obtained transmission opportunity (TXOP).

[0003] However, one challenge is the inefficient allocation of TXOP. For example, when TXOP is shared among multiple shared APs (e.g., a first shared AP followed by a second shared AP), there may unused time in the TXOP allocated to the first shared AP. If low latency (LL) data arrives at the second shared AP, this can result in a longer delay in transmitting the LL data.

[0004] Accordingly, there exists a need to provide a novel communication apparatus and communication method for TXOP allocation that can address the above issues.

[0005] Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background of the disclosure.SUMMARY

[0006] Non-limiting and exemplary embodiments facilitate providing access points and communication methods for transmission opportunity allocation.

[0007] In a first aspect, the present disclosure provides a first access point (AP) comprising: circuitry, which in operation, generates a frame for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for a second AP to transmit data in a basic service set (BSS) of the second AP; and a transmitter, which in operation, transmits the frame to the second AP.

[0008] In a second aspect, the present disclosure provides a second access point (AP) comprising: a receiver, which in operation, receives a frame from a first AP for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for the second AP to transmit data in a basic service set (BSS) of the second AP; and circuitry, which in operation, processes the frame to perform a clear-to-send (CTS) procedure.

[0009] In a third aspect, the present disclosure provides a communication method implemented by a first access point (AP) comprising: generating a frame for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for a second AP to transmit data in a basic service set (BSS) of the second AP; and transmitting the frame to the second AP.

[0010] In a fourth aspect, the present disclosure provides a communication method implemented by a second access point (AP) comprising: receiving a frame from a first AP for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for the second AP to transmit data in a basic service set (BSS) of the second AP; and processing the frame to perform a clear-to-send (CTS) procedure.

[0011] It should be noted that general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any selective combination thereof. Additional benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. The benefits and / or advantages may be individually obtained by the various embodiments and features of the specification and drawings, which need not all be provided in order to obtain one or more of such benefits and / or advantages.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying figures where like reference numerals refer to identical or functionally similar elements throughout the separate views and which together with the detailed description below are incorporated in and form part of the specification, serve to illustrate various embodiments and to explain various principles and advantages in accordance with present embodiments.

[0013] Figure 1 shows a schematic diagram illustrating a TXOP sharing procedure involving a sharing AP and a single shared AP.

[0014] Figure 2 shows a schematic diagram illustrating a TXOP sharing procedure involving a sharing AP and multiple shared APs.

[0015] Figure 3 shows an exemplary TXOP sharing procedure with LL data transmission involving a sharing AP and multiple shared APs.

[0016] Figure 4 shows a schematic diagram illustrating a TXOP sharing procedure involving a sharing AP and multiple shared APs according to an embodiment of the present disclosure.

[0017] Figure 5 shows an exemplary format of a multi-user request-to-send (MU-RTS) triggered TXOP sharing (TXS) frame according to an embodiment of the present disclosure.

[0018] Figure 6 shows a schematic diagram illustrating a TXOP sharing procedure according to various embodiments of the present disclosure.

[0019] Figure 7 shows a schematic diagram illustrating a TXOP sharing procedure involving a sharing AP and a single shared AP, according to a first embodiment of the present disclosure.

[0020] Figures 8 and 9 respectively show an exemplary format of a field of a RTRP frame according to the first embodiment of the present disclosure.

[0021] Figure 10 show an exemplary format of a RTR frame according to the first embodiment of the present disclosure.

[0022] Figure 11 shows an exemplary control information subfield format of a RTR frame according to the first embodiment of the present disclosure.

[0023] Figure 12A shows another exemplary format of a RTRP frame according to the first embodiment of the present disclosure.

[0024] Figure 12B shows another exemplary format of a RTR frame according to the first embodiment of the present disclosure.

[0025] Figure 13 shows an exemplary format of a MU-RTS TXS frame according to the first embodiment of the present disclosure.

[0026] Figure 14A shows a flow chart illustrating a phase of a process implemented by a sharing AP according to the first embodiment of the present disclosure.

[0027] Figure 14B shows a flow chart illustrating another phase of a process implemented by a sharing AP according to the first embodiment of the present disclosure.

[0028] Figure 15A shows a flow chart illustrating a phase of a process implemented by a shared AP according to the first embodiment of the present disclosure.

[0029] Figure 15B shows a flow chart illustrating another phase of a process implemented by a shared AP according to the first embodiment of the present disclosure.

[0030] Figure 16 shows a schematic diagram illustrating a TXOP sharing procedure involving a sharing AP and a single shared AP, according to a second embodiment of the present disclosure.

[0031] Figure 17 shows an exemplary format of a RTR element according to the second embodiment of the present disclosure.

[0032] Figure 18 shows a flow chart illustrating a process implemented by a sharing AP according to the second embodiment of the present disclosure.

[0033] Figure 19 shows a flow chart illustrating a process implemented by a shared AP according to the second embodiment of the present disclosure.

[0034] Figures 20 to 23 show schematic diagrams illustrating TXOP sharing procedures involving a sharing AP and multiple shared APs, according to a third embodiment of the present disclosure.

[0035] Figure 24 shows an exemplary format of a RTRP frame according to the third embodiment of the present disclosure.

[0036] Figure 25 shows an exemplary format of a MU-RTS TXS frame according to the third embodiment of the present disclosure.

[0037] Figure 26A shows a flow chart illustrating a phase of a process implemented by a sharing AP according to the third embodiment of the present disclosure.

[0038] Figure 26B shows a flow chart illustrating another phase of a process implemented by a sharing AP according to the third embodiment of the present disclosure.

[0039] Figure 27A shows a flow chart illustrating a phase of a process implemented by a shared AP according to the third embodiment of the present disclosure.

[0040] Figure 27B shows a flow chart illustrating another phase of a process implemented by a shared AP according to the third embodiment of the present disclosure.

[0041] Figure 28 shows a schematic diagram illustrating a TXOP sharing procedure involving a sharing AP and multiple shared APs, according to a fourth embodiment of the present disclosure.

[0042] Figure 29 shows a flow chart illustrating a process implemented by a sharing AP according to the fourth embodiment of the present disclosure.

[0043] Figure 30 shows a flow chart illustrating a process implemented by a shared AP according to the fourth embodiment of the present disclosure.

[0044] Figure 31A shows a schematic diagram illustrating a TXOP sharing procedure involving a sharing AP and a single shared AP, according to a fifth embodiment of the present disclosure.

[0045] Figure 31 B shows another schematic diagram illustrating a TXOP sharing procedure involving a sharing AP and a single shared AP, according to the fifth embodiment of the present disclosure.

[0046] Figure 32A shows a schematic diagram illustrating a TXOP sharing procedure involving a sharing AP and multiple shared APs, according to the fifth embodiment of the present disclosure.

[0047] Figure 32B shows a schematic diagram illustrating a TXOP sharing procedure involving a sharing AP and multiple shared APs, according to the fifth embodiment of the present disclosure.

[0048] Figure 33 shows a schematic diagram illustrating a TXOP sharing procedure involving capability exchange between APs, according to a sixth embodiment of the present disclosure.

[0049] Figure 34A shows a schematic diagram illustrating a TXOP sharing procedure involving capability exchange between a sharing AP and a shared AP, according to a sixth embodiment of the present disclosure.

[0050] Figure 34B shows another schematic diagram illustrating a TXOP sharing procedure involving capability exchange between a sharing AP and a shared AP, according to a sixth embodiment of the present disclosure.

[0051] Figures 35 to 38 respectively show an exemplary format of a UHR Capabilities element according to the sixth embodiment of the present disclosure.

[0052] Figure 39 shows a flow chart illustrating a communication method according to various embodiments of the present disclosure.

[0053] Figure 40 shows a flow chart illustrating another communication method according to various embodiments of the present disclosure.

[0054] Figure 41 shows a schematic view of a communication apparatus according to various embodiments of the present disclosure.

[0055] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been depicted to scale.DETAILED DESCRIPTION

[0056] The following detailed description is merely exemplary in nature and is not intended to limit the invention or the application and uses of the invention. Furthermore, there is no intention to be bound by any theory presented in the preceding background of the invention or the following detailed description.

[0057] Some embodiments of the present disclosure will be described, by way of example only, with reference to the drawings. Like reference numerals and characters in the drawings refer to like elements or equivalents.

[0058] In the following paragraphs, certain exemplifying embodiments are explained with reference to one or more access points (APs), which may operate as a sharing AP or a shared AP, for transmission opportunity (TXOP) allocation in multi-AP (M-AP) coordination schemes, especially in coordinated time-division multiple access (C-TDMA).

[0059] In the context of IEEE 802.11 (Wi-Fi) technologies, a station, which is interchangeably referred to as a STA, is a communication apparatus that has the capability to use the IEEE 802.11 protocol. Based on the IEEE 802.11-2020 definition, a STA can be any device that contains an IEEE 802.11-conformant media access control (MAC) and physical layer (PHY) interface to the wireless medium (WM).

[0060] For example, a STA may be a laptop, a desktop personal computer (PC), a personal digital assistant (PDA), either an access point or not (e.g., either an AP STA or a non-AP STA), or a Wi-Fi phone in a wireless local area network (WLAN) environment. The station may be fixed or mobile. In the WLAN environment, the terms "STA", "non-AP STA", "client", "wireless client", "user", "user device", and "mobile terminal" are often used interchangeably.

[0061] Likewise, an AP, which may be interchangeably referred to as a wireless access point (WAP) in the context of IEEE 802.11 (Wi-Fi) technologies, is a communication apparatus that allows STAs in a WLAN to connect to a wired network. The AP usually connects to a router (via a wired network) as a standalone device, but it can also be integrated with or employed in the router. The AP may be a part of a basic service set (BSS), which consists of the AP and one or more STAs, facilitating communication between the STAs in the BSS. A sharing AP is used herein to describe an AP that obtains a transmission opportunity (TXOP) and shares the TXOP with another AP (e.g., a shared AP), while a shared AP is used herein to describe an AP that is shared the TXOP by the sharing AP.

[0062] As mentioned above, a STA in a WLAN may work as an AP at different occasions, and vice versa. This is because communication apparatuses in the context of IEEE 802.11 (Wi-Fi) technologies may include both STA hardware components and AP hardware components. In this manner, the communication apparatuses may switch between a STA mode and an AP mode, based on actual WLAN conditions and / or requirements.

[0063] In various embodiments below, the term "shared AP" may be used interchangeable with "scheduled AP". The term "circuitry" may be used interchangeably with "module".

[0064] Figure 1 shows a schematic diagram illustrating a TXOP sharing (TXS) procedure 100 in C-TDMA involving a sharing AP 102 and a single shared AP 104. For example, sharing AP 102 uses a multi-user request-to-send (MU-RTS) TXS frame 110 to allocate TXOP 108 to shared AP 104, initiating the TXS procedure. Upon receiving the MU-RTS TXS frame 110 from sharing AP 102, shared AP 104 transmits a clear-to-send (CTS) frame 112 to sharing AP 102, and facilitates frame exchange 114 during its allocated time 116 (e.g., allowing shared AP 104 to transmit data to non-AP STA 106 in its BSS).

[0065] Figure 2 shows a schematic diagram illustrating a TXOP sharing procedure 200 in C- TDMA involving a sharing AP 202 and multiple shared APs 204, 206. For example, sharing AP 202 uses MU-RTS TXS frame 210, 218 to allocate TXOP 208 to shared AP 204 and shared AP 206, initiating the TXS procedure. Upon receiving the MU-RTS TXS 210, 218 from sharing AP 202, each shared AP 204, 206 transmits a CTS frame 212, 220 to sharing AP 202, enabling frame exchange 214, 222 during their respective allocated times 216, 224.

[0066] Figure 3 shows an exemplary TXOP sharing procedure 300 with low latency (LL) data 314 transmission involving a sharing AP 302 and multiple shared APs 304, 306. LL data used herein refers to data that is sensitive to latency and may require transmission within a specific threshold delay. As shown in Figure 3, inefficient allocation of TXOP 308 may result in unused time 312 in the TXOP 310 allocated to shared AP 302. Consequently, if LL data 314 arrives at shared AP 306, there may be a longer time delay 316 in transmitting the LL data 314.

[0067] Figure 4 shows a schematic diagram illustrating a TXOP sharing procedure 400 involving a sharing AP 402 and multiple shared APs 404, 406 according to an embodiment of the present disclosure. For example, the shared AP 404 may transmit a CF-End frame 408 to indicate the end of a contention-free period, and return the remaining unused TXOP 410. This in turn reduces the time delay 414 for transmitting LL data 412 arriving at shared AP 406.

[0068] Figure 5 shows an exemplary format of a MU-RTS TXS frame 500 according to an embodiment of the present disclosure. The MU-RTS TXS frame 500 may be used in the TXOP sharing procedure 400 shown in Figure 4 to share TXOP. The MU-RTS TXS frame 500 comprises a Frame Control field, a Duration field, an RA field, a TA field, a Common Info field 510, a User Info field 520, a Padding field, and an FCS field. Apart from a Reserved subfield(s), the User Info field 520 may comprise an AID12 subfield 522, an RU Allocation subfield, an Allocation Duration subfield, and a PS160 subfield. The Common Info field 510 may comprise a Triggered TXOP Sharing Mode subfield 512. The value of the Triggered TXOP Sharing Mode subfield 512 may be set to: 'O' to indicate a MU-RTS that does not initiate TXS procedure; 'T to indicate a MU-RTS that initiates TXS procedure wherein a scheduled STA can only transmit MPDU(s) addressed to its associated AP; '2' to indicate a MU-RTS that initiates TXS procedure wherein a scheduled STA can transmit MPDU(s) addressed to its associated AP or addressed to another STA; or '3', which was Reserved in IEEE 802.11 be Standard, to indicate a MU-RTS that initiates TXS procedure wherein a scheduled STA can transmit MPDU(s) addressed to its associated STAs or addressed to other APs. The AID12 subfield 522 may indicate an APID, which is an identifier to uniquely identify an AP among multiple APs.

[0069] Alternatively, the reserved value '3' may not be used, and instead, the description for Triggered TXOP Sharing Mode subfield 512 value '2' may be changed to: a MU-RTS that initiates TXS procedure wherein a scheduled STA can transmit MPDU(s) addressed to its associated AP or addressed to another STA, or a scheduled AP can transmit MPDU(s) addressed to its associated STAs or other APs.

[0070] Figure 6 shows a schematic diagram illustrating a TXOP sharing procedure 600 according to various embodiments of the present disclosure, wherein prior to a TXS Phase 620, APs may exchange information to help in scheduling TXOP allocation during the TXS Phase 620. For example, a shared AP 604 may transmit a required TXOP report (RTR) frame 610 to a sharing AP 602. The RTR frame 610 may contain information of a required TXOP duration in the TXS Phase 620 and LL related information. During the TXS Phase 620, the sharing AP 602 utilises the information in RTR 610 for TXOP allocation.

[0071] Advantageously, this approach provides a sharing AP with prior knowledge of resource requirements of shared AP(s), thereby improving the efficiency of TXOP allocation.First Embodiment

[0072] Figure 7 shows a schematic diagram illustrating a TXOP sharing procedure 700 involving a sharing AP 702 and a single shared AP 704, according to a first embodiment of the present disclosure. In a pre-TXS Phase 710 of the procedure 700, the sharing AP 702 may solicit a required TXOP report (RTR) frame 714 from the shared AP 704 by sending a required TXOP report poll (RTRP) frame 712 to the shared AP 704.

[0073] In a TXS phase 720, the sharing AP 702 may share TXOP according to the RTR frame 714 sent by the shared AP 704. For example, in the TXS phase 720, the sharing AP 702 may generate a frame (e.g., MU-RTS TXS frame 722) for allocating a TXOP (e.g., TXOP 730) obtained by the sharing AP 702, the frame allocating a portion (e.g., TXOP 732) of the TXOP for the shared AP 704 to transmit data 726 in a BSS of the shared AP 704 (e g., the data 726 may be transmitted to one or more communication apparatuses in the BSS of the shared AP 704, such as a STA, another AP, or other similar communication apparatus). The sharing AP 702 may then transmit the frame to the shared AP 704, to allocate the portion of the TXOP 730 based on information (e.g., required TXOP duration and LL requirements information) received from the shared AP 704. After receiving the frame, the shared AP 704 may process the frame to perform a CTS procedure (e.g., transmitting a CTS frame 724 to the sharing AP 702) and then transmits the data 726 in its BSS during its allocated TXOP (e.g., TXOP 732).

[0074] There may be a pre-TXS phase 710 before the TXS phase 720, where prior to the generation of the frame (e.g., MU-RTS TXS frame 722), the sharing AP 702 may transmit a trigger frame (e.g., RTRP frame 712) to the shared AP 704 to solicit another frame (e.g., RTR frame 714) from the shared AP 704. The RTR frame 714 may comprise the information (e.g., required TXOP duration and LL requirements information) for allocating the TXOP (e.g., TXOP 730). The shared AP 704 may then transmit the RTR frame 714 to the sharing AP 702. The RTR frame 714 frame may be transmitted via unicast or broadcast.

[0075] Advantageously, this approach allows a sharing AP to get new resource requirements from a shared AP helpful for allocating TXOP, and thus improves the efficiency of TXOP allocation.

[0076] Figures 8 and 9 respectively show an exemplary format of a field of a RTRP frame 800 according to the first embodiment of the present disclosure. The RTRP frame 800 in Figures 8 and 9 may be an example of the RTRP frame 712 in Figure 7. As shown in Figure 8, the RTRP frame 800 may comprise a Frame Control field, a Duration field, an RA field, a TA field,a Common Info field 810, a User Info field 820, a Padding field, and an FCS field. Apart from a Reserved subfield(s), the User Info field 820 may comprise an AID12 subfield 822, an RU Allocation subfield, a UL FEC Coding Type subfield, a UL UHR-MCS subfield, an SS Allocation subfield, a UL Target Receive Power subfield, and a PS160 subfield. As shown in Figure 9, the Common Info field 810 may comprise a Trigger Type subfield 812, a UL Length subfield, a More TF subfield, a CS Required subfield, a UL BW subfield, a Gl And HE / EHT-LTF Type / Triggered TXOP Sharing Mode subfield, a Number Of HE / EHT-LTF Symbols subfield, an LDPC Extra Symbol Segment subfield, an AP Tx Power subfield, a Pre-FEC Padding Factor subfield, a PE Disambiguity subfield, a UL Spatial Reuse subfield, a HE / EHT P160 subfield, a Special User Info Field Flag subfield, an EHT Reserved subfield, in addition to the Reserved subfield(s). The AID12 subfield 822 in Figure 8 may indicate an APID, which is an identifier to uniquely identify an AP among multiple APs.

[0077] Table 1 shows a list of Trigger Type subfield values and the corresponding trigger frame variant for the Trigger Type subfield 812 in Figure 9.Table 1

[0078] The Trigger Type subfield 812 may be set to value '9', which was previously Reserved, to indicate the RTRP frame in the present disclosure. It will be appreciated that the value need not be restricted to '9', and other values may also be defined orset for the Trigger Type subfield 812 to indicate the RTRP frame.

[0079] Figure 10 shows an exemplary format of a RTR frame 1000 according to the first embodiment of the present disclosure. The RTR frame 1000 in Figure 10 may be an example of the RTR frame 714 in Figure 7. The RTR frame 1000 may comprises a Frame Control field, a Duration / ID field, three Address fields (Address 1 field, Address 2 field, and Address 3 field), a Sequence Control field, another Address field (Address 4 field), a Quality of Service (QoS) Control field, a HT Control field 1010, Frame Body field, and FCS field. The length of each field in units of octets is shown above the corresponding field in Figure 10. In HT Control field 1010, there are three variants: HT, VHT, and HE. The three variants are differentiated by the value of B0 and B1. RTR Control is added in an A-Control subfield 1012 of HE variant in HT Control field 1010. If RTR is broadcasted, the Receiver Address (RA) (i.e., content of Address 1 field 1020) will be set as a broadcast address. The A-Control subfield 1012 may comprise a Control List subfield 1014 and a Padding subfield. The Control List subfield 1014 may comprise a Control ID subfield 1016 and a Control Information subfield 1018.

[0080] Table 2 shows a list of Control ID subfield 1016 values, the corresponding meaning, and length of the Control Information subfield 1018.Table 2

[0081] The Control ID subfield 1016 indicates the type of information carried in the Control Information subfield 1018. The values of the Control ID subfield 1016 are defined in Table 2. The Control ID subfield 1016 may be set to value '10', which was previously Reserved, to indicate the RTR frame in the present disclosure. It will be appreciated that the value need not be restricted to '10', and other values may also be defined or set for the Control ID subfield 1016 to indicate the RTR frame.

[0082] Figure 11 shows an exemplary Control Information subfield 1100 format of a RTR frame according to the first embodiment of the present disclosure. The Control Information subfield 1100 in Figure 11 may be an example of the Control Information subfield 1018 in Figure 10.

[0083] The Control Information subfield 1100 in an RTR (e.g., RTR frame 1000) may comprise BW subfield 1110, Required TXOP Duration subfield 1120, and LL Requirements Info subfield 1130 for TXOP sharing in C-TDMA. The LL Requirements Info subfield 1130 may comprise LL Presence subfield 1132 and ACI Bitmap subfield 1134.

[0084] The BW subfield 1110 is optionally present, and indicates the bandwidth for which the medium resource is requested (e.g., the bandwidth for transmitting the data 726 by the shared AP 704, and the shared AP 704 transmits the data 726 within the indicated bandwidth).

[0085] Table 3 shows the BW subfield encoding.Table 3

[0086] The Required TXOP Duration subfield 1120 indicates the duration of each shared AP's required allocated time (e.g., an amount of time required for a shared AP to transmit data in its BSS, such as to one or more communication apparatuses in the BSS of the shared AP). The required time may be calculated based on the bandwidth specified in the BW subfield. Alternatively, the required time may be calculated based on a predetermined bandwidth (e.g., 20 MHz). Alternatively, the bandwidth to be used for the calculation may be indicated by the sharing AP within the RTRP frame. If the shared AP does not require any TXOP, for example, the Required TXOP Duration subfield 1120 may be set to 'O'.

[0087] The LL Presence subfield 1132 indicates whether the data to be transmitted by a shared AP is LL data (e.g., a traffic type of the data to be transmitted by a shared AP). For example, if LL data arrives at shared AP, the LL Presence subfield 1132 may be set to T, otherwise it may be set to 'O'.

[0088] The ACI Bitmap subfield 1134 indicates the priority level of the traffic (e.g., a traffic priority level of the data to be transmitted by a shared AP). For example, based on the value indicated in ACI Bitmap subfield 1134, sharing AP may share TXOP with a shared AP with more urgent LL data first.

[0089] The Control Information subfield 1100 may also comprise other information in the Reserved field 1140, for example, the number of STAs in its BSS (e.g., BSS of shared AP 704).

[0090] Figures 12A and 12B show another exemplary format of a RTRP frame 1210 and another exemplary format of a RTR frame 1220, respectively, according to the first embodiment of the present disclosure. For example, the bandwidth may alternatively be included in a RTR BWsubfield 1212 in a RTRP frame 1210, as shown in Figure 12A.

[0091] The RTR BW subfield 1212 indicates the bandwidth for which the medium resource can be requested (e.g., the bandwidth for transmitting the data 726 by the shared AP 704, and the shared AP 704 transmits the data 726 within the indicated bandwidth). The RTR BW field 1212 uses EHT Reserved subfield bits, and the RTR BW subfield encoding may be the same as the BW subfield encoding shown in Table 3.

[0092] The Required TXOP Duration subfield 1222, LL Requirements Info subfield 1224, and Reserved field 1226 in Figure 12B may be the same as the Required TXOP Duration subfield 1120, LL Requirements Info subfield 1130, and Reserved field 1140 in Figure 11.

[0093] Figure 13 shows an exemplary format of a MU-RTS TXS frame 1300 according to the first embodiment of the present disclosure. The MU-RTS TXS frame 1300 in Figure 13 may be an example of the MU-RTS TXS frame 722 in Figure 7. The MU-RTS TXS frame 1300 may be used in the TXOP sharing procedure 700 illustrated in Figure 7 to share TXOP. The MU- RTS TXS frame 1300 comprises a Frame Control field, a Duration field, an RA field, a TA field, a Common Info field 1310, a User Info field 1320, a Padding field, and an FCS field. Apart from a Reserved subfield(s), the User Info field 1320 may comprise an AID12 subfield 1322, an RU Allocation subfield, an Allocation Duration subfield, and a PS160 subfield. The Common Info field 1310 may comprise a Triggered TXOP Sharing Mode subfield 1312. The value of the Triggered TXOP Sharing Mode subfield 1312 may be set to: 'O' to indicate a MU-RTS that does not initiate TXS procedure; T to indicate a MU-RTS that initiates TXS procedure wherein a scheduled STA can only transmit MPDU(s) addressed to its associated AP; '2' to indicate a MU-RTS that initiates TXS procedure wherein a scheduled STA can transmit MPDU(s) addressed to its associated AP or addressed to another STA; or '3', which was Reserved, to indicate a MU-RTS (e.g., MU-RTS TXS 722) that initiates TXS procedure wherein a scheduled AP (e.g., shared AP 704) can transmit MPDU(s) addressed to its associated STAs or addressed to other APs). The AID12 subfield 1322 may indicate an API D, which is an identifier to uniquely identify an AP among multiple APs.

[0094] Alternatively, the reserved value '3' may not be used, and instead the description for Triggered TXOP Sharing Mode subfield 1312 value '2' may be changed to: a MU-RTS (e g., MU-RTS TXS 722) that initiates TXS procedure wherein a scheduled STA can transmit MPDU(s) addressed to its associated AP or addressed to another STA, or a scheduled AP (e.g., shared AP 704) can transmit data in its BSS (e.g., transmit MPDU(s) addressed to its associated STAs or other APs).

[0095] Figures 14A and 14B show flow charts illustrating two phases of a process implemented by a sharing AP according to the first embodiment of the present disclosure. In pre- TXS phase 1410 shown in Figure 14A, in response to obtaining a TXOP in step 1412, a sharing AP (e.g., sharing AP 702) may carry out step 1414, sending a RTRP (e.g., RTRP frame 712) to shared APs (e.g., shared AP 704) to solicit a RTR (e.g., RTR frame 714). In TXS phase 1420 shown in Figure 14B, after receiving RTR from the shared AP in step 1422, the sharing AP may then carry out step 1424, sending MU-RTS TXS (e.g., MU-RTS TXS frame 722) to the shared AP to share the TXOP (e.g., TXOP 730) based on information in the received RTR. The two phases 1410, 1420 may be executed as two separate methods or the phase 1420 may be carried out as a continuation of the phase 1410, forming a single method.

[0096] Figures 15A and 15B show flow charts illustrating two phases of a process implemented by a shared AP according to the first embodiment of the present disclosure. In pre-TXS phase 1510 shown in Figure 15A, in response to receiving a RTRP (e.g., RTRP frame 712) from a sharing AP (e.g., sharing AP 702) in step 1512, a shared AP (e g., shared AP 704) may carry out step 1514, sending a RTR (e.g., RTR frame 714) to the sharing AP, the RTR comprising required TXOP duration (e.g., Required TXOP Duration subfield 1120, 1222) and LL information (e.g., LL Requirements Info subfield 1130, 1224). In TXS phase 1520 shown in Figure 15B, after receiving a MU-RTS TXS (e g., MU-RTS TXS frame 722) from the sharing AP in step 1522, the shared AP may carry out step 1524, responding with a CTS (e.g., transmitting a CTS frame 724 to the sharing AP 702) and then in step 1526, starts data transmission during its allocated time in its own BSS (e.g., transmitting data 726 in a BSS of the shared AP 704 during allocated TXOP 732) . The two phases 1510, 1520 may be executed as two separate methods or the phase 1520 may be carried out as a continuation of the phase 1510, forming a single method.Second Embodiment

[0097] Figure 16 shows a schematic diagram illustrating a TXOP sharing procedure 1600 involving a sharing AP 1602 and a single shared AP 1604, according to a second embodiment of the present disclosure.

[0098] For example, in TXS phase 1620, the sharing AP 1602 may generate a frame (e.g., MU-RTS TXS frame 1622) for allocating a TXOP (e.g., TXOP 1630) obtained by the sharing AP 1602, the frame allocating a portion (e.g., TXOP 1632) of the TXOP for the shared AP 1604 to transmit data 1626 in a BSS of the shared AP 1604 (e.g., the data 1626 may be transmitted to one or more communication apparatuses in the BSS of the shared AP 1604, such as a STA, another AP, the sharing AP 1602, or other similar communication apparatus). The sharing AP 1602 may then transmit the frame to the shared AP 1604. The frame may allocate the TXOP based on information (e.g., required TXOP duration and LL requirements information) received from the shared AP 1604 in a previous TXOP or TXS (e.g., TXOP or TXS 1610). The shared AP 1604 may transmit another frame (e.g., RTR 1612) comprising the information (e.g., broadcast unsolicited RTR 1612) within its allocated TXOP (e.g., in the previous TXS or TXOP 1610) to help the next round of TXOP sharing (e.g., to allocate the TXOP 1630 in TXS phase 1620).

[0099] After receiving the frame, the shared AP 1604 may process the frame to perform a CTS procedure (e.g., transmitting a CTS frame 1624 to the sharing AP 1602) and thentransmits the data 1626 in its BSS during its allocated TXOP 1632). Additionally, each AP 1602, 1604 may broadcast another RTR 1628, 1629 during its allocated TXOP 1630, 1632, to help in the next TXOP sharing (e.g., in future TXS 1640).

[0100] In a next TXOP (e.g., future TXS 1640), the sharing AP may share TXOP according to RTR (e.g., RTR 1628, 1629) broadcasted by the APs (e.g., sharing AP 1602 and shared AP 1604).

[0101] Advantageously, this approach enhances the efficiency of the sharing AP in gathering information of resource request from shared AP, thereby improving the efficiency of TXOP allocation.

[0102] The RTR 1612 may be a frame having the same format as described in the first embodiment (Figures 10, 11 , and 12B), with the Address 1 field 1020 being set to broadcast address.

[0103] Alternatively, RTR 1612 may also be an element included in a beacon frame, and broadcasted.

[0104] Figure 17 shows an exemplary format of a RTR element 1700 according to the second embodiment of the present disclosure. The RTR element 1700 in Figure 17 may be an example of the RTR 1612 in Figure 16. The RTR element 1700 comprises an Element ID field 1710, a Length field, an Element ID Extension field 1720, and a RTR Information field 1730. Similar to the Control Information subfield 1100 in the first embodiment, the RTR Information field 1730 may comprise BW subfield 1732, Required TXOP Duration subfield 1734, and LL Requirements Info subfield 1736. The LL Requirements Info subfield 1736 comprises LL Presence subfield 1742 and ACI Bitmap subfield 1744.

[0105] The Element ID field 1710 may be set to '255', and the Element ID Extension field 1720 may be set to '117', which were previously Reserved, to indicate the RTR element in the present disclosure. Similarly, the BW subfield 1732 is optionally present, and indicates the bandwidth for which the medium resource is requested (e.g., the bandwidth for transmitting the data 1626 by the shared AP 1604, and the shared AP 1604 transmits the data 1626 within the indicated bandwidth).

[0106] Similar to the Required TXOP Duration subfield 1120 in the first embodiment, the Required TXOP Duration subfield 1734 may indicate the duration of each shared AP'srequired allocated time (e.g., an amount of time required for a shared AP to transmit data in its BSS, such as to one or more communication apparatuses in the BSS of the shared AP). The required time may be calculated based on the bandwidth specified in the BW subfield. Alternatively, the required time may be calculated based on a predetermined bandwidth (e g., 20 MHz). Alternatively, the bandwidth to be used for the calculation may be indicated by the sharing AP within the RTRP frame. If the shared AP does not require any TXOP, for example, the Required TXOP Duration subfield 1732 may be set to 'O'.

[0107] Figure 18 shows a flow chart illustrating a process implemented by a sharing AP according to the second embodiment of the present disclosure. In step 1802, a sharing AP (e.g., sharing AP 1602) receives broadcast / unsolicited RTR (e.g., RTR 1612) from other AP (e.g., shared AP 1604). Subsequently, the sharing AP may carry out step 1804 during TXOP (e.g., during TXS phase 1620), sending MU-RTS TXS (e.g., MU-RTS TXS frame 1622) to share TXOP (e.g., TXOP 1630) based on information in the received RTR.

[0108] Figure 19 shows a flow chart illustrating a process implemented by a shared AP according to the second embodiment of the present disclosure. In step 1902, a shared AP (e.g., shared AP 1604) broadcasts unsolicited RTR (e.g., RTR 1612) to other AP (e g., sharing AP 1602) in a first TXOP (e.g., TXS or TXOP 1610). Then, in response to receiving MU-RTS TXS (e.g., MU-RTS TXS frame 1622) from a sharing AP (e.g., sharing AP 1602) in step 1904, the shared AP may carry out step 1906, responding with CTS (e.g., transmitting a GTS frame 1624 to the sharing AP 1602) and then in step 1908, starts data transmission during its allocated time in its own BSS (e.g., transmitting data 1626 in a BSS of the shared AP 1604 during allocated TXOP 1632).Third Embodiment

[0109] Figures 20 to 23 show schematic diagrams illustrating TXOP sharing procedures 2000, 2100, 2200, 2300 involving a sharing AP 2002 and multiple shared APs 2004, 2006, according to a third embodiment of the present disclosure.

[0110] For example, referring to Figure 20, in a TXS phase 2020, the sharing AP 2002 may generate a frame (e.g., MU-RTS TXS frame 2022) for allocating a TXOP (e.g., TXOP 2030) obtained by the sharing AP 2002, the frame allocating (i) a portion (e.g., TXOP 2032) of the TXOP for the shared AP 2004 to transmit data 2026 in a BSS of the shared AP 2004 (e.g., the data 2026 may be transmitted to one or more communication apparatuses in the BSS of the shared AP 2004, such as a STA, another AP, the sharing AP 2002, or other similarcommunication apparatus) and (ii) another portion (e.g., TXOP 2033) of the TXOP for the shared AP 2006 to transmit data 2027 in a BSS of the shared AP 2006 (e g., the data 2027 may be transmitted to one or more communication apparatuses in the BSS of the shared AP 2006, such as a STA, another AP, the sharing AP 2002, or other similar communication apparatus). The sharing AP 2002 may then transmit the frame to the shared AP 2004, to allocate the portion of the TXOP based on information (e.g., required TXOP duration and LL requirements information) received from the shared APs 2004, 2006. After receiving the frame, the shared APs 2004, 2006 may process the frame to perform a CTS procedure (e.g., transmitting CTS frames 2024, 2025 to the sharing AP 2002) and then transmits the data 2026, 2027 in their respective BSS during their allocated TXOP (e.g., TXOP 2032, 2033).

[0111] Similar to the first embodiment, there may be a pre-TXS phase 2010 before the TXS phase 2020, where prior to the generation of the frame, the sharing AP 2002 may transmit a trigger frame (e.g., RTRP frame 2012) to the shared APs 2004, 2006 to solicit another frame (e.g., RTR frames 2014, 2015) from the shared APs 2004, 2006. The another frame may comprise the information (e.g., required TXOP duration and LL requirements information) for allocating the TXOP (e.g., TXOP 2030). The shared APs 2004, 2006 may then transmit the another frame to the sharing AP 2002. The format of the RTR frames in the third embodiment may be the same as the RTR frames in the first embodiment. As an example, each of the RTR frames 2014, 2015 may have the same format as the RTR frame 1000 in Figure 10 (including the exemplary Control Information subfield 1100 in Figure 11). RTR Control information may be included in HT Control field 1010.

[0112] In the third embodiment, the order of allocation of the TXOP may be based on the information (e.g., LL requirements information) received from the shared APs 2004, 2006, and may be indicated in the frame (e.g., MU-RTS TXS frame 2022). The APs (e.g., shared APs 2004, 2006) may use full bandwidth for the data transmission (e.g., data 2026, 2027), instead of using part of Resource Units (RU) for other data transmission. For example, if only information from shared AP 2006 indicates arrival of data 2027 of a certain traffic type (e.g., LL data) in pre-TXS phase 2010 as shown in Figure 21 , the sharing AP 2002 may share the TXOP 2030 with the shared AP 2006 first (e.g., by allocating the TXOP 2030 such that TXOP 2033 allocated to shared AP 2006 is before TXOP 2032 allocated to shared AP 2004).

[0113] In another example shown in Figure 22, if both information from shared AP 2004 and shared AP 2006 indicate arrival of data 2026, 2027 of the certain traffic type (e.g., LL data), but information from shared AP 2006 indicates that data 2027 has a higher traffic priority level(e.g., shared AP 2006 has more urgent LL data to send), the sharing AP 2002 may share TXOP 2030 to shared AP 2006 first.

[0114] In yet another example as shown in Figure 23, if neither information from shared AP 2004 nor shared AP 2006 indicates arrival of data 2027, 2027 of the of the certain traffic type (e.g., LL data), the sharing AP 2002 may determine which shared AP to share the TXOP 2030 first (e g., by allocating the TXOP 2030 such that TXOP 2032 allocated to shared AP 2004 is before TXOP 2033 allocated to shared AP 2006). The determination of the order of allocation may be based on other information included in RTR Reserved field.

[0115] Alternatively or additionally, if any of the shared APs 2004, 2006 does not require TXOP, it may not send RTR 2014, 2015, or indicate 'O' in the Required TXOP Duration subfield 1120.

[0116] Advantageously, this approach allows a sharing AP to get new resource requirements from a shared AP helpful for allocating TXOP, and thus improves the efficiency of TXOP allocation.

[0117] The format of the RTRP frame in the third embodiment may be similar to the format of the RTRP frame in the first embodiment, with the only difference being that the RTRP frame in the third embodiment includes multiple User Info fields - each User Info field for each shared AP.

[0118] Figure 24 shows an exemplary format of a RTRP frame 2400 according to the third embodiment of the present disclosure. The RTRP frame 2400 in Figure 24 may be an example of the RTRP frame 2012 in Figures 20 to 23. The RTRP frame 2400 comprises a Frame Control field, a Duration field, an RA field, a TA field, a Common Info field 2410, two User Info field (User Info 1 field 2420 and User Info 2 field 2430), a Padding field, and an FCS field. The User Info 1 field 2420 comprises an AID12 subfield 2422, an RU Allocation subfield, a UL FEC Coding Type subfield, a UL UHR-MCS subfield, an SS Allocation subfield, a UL Target Receive Power subfield, and a PS160 subfield. The format of the Common Info field 2410 may be the same as the format of the Common Info field 810 shown in Figure 9. The AID12 subfield 2422 may indicate an APID, which is an identifier to uniquely identify an AP among multiple APs.

[0119] The format of the MU-RTS TXS frame in the third embodiment may be similar to the format of the MU-RTS TXS frame in the first embodiment, with the only difference being thatthe RTRP frame in the third embodiment includes multiple User Info fields - each User Info field for each shared AP.

[0120] Figure 25 shows an exemplary format of a MU-RTS TXS frame 2500 according to the third embodiment of the present disclosure. The MU-RTS TXS frame 2500 in Figure 25 may be an example of the MU-RTS TXS frame 2022 in Figures 20 to 23. The MU-RTS TXS frame 2500 may be used in the TXOP sharing procedures 2000, 2100, 2200, 2300 illustrated in Figure 20 to 23 to share TXOP. The MU-RTS TXS frame 2500 comprises a Frame Control field, a Duration field, an RA field, a TA field, a Common Info field 2510, two User Info fields (User Info 1 field 2520 and User Info 2 field 2530), a Padding field, and an FCS field. The User Info 1 field 2520 comprises an AID12 subfield 2522, an RU Allocation subfield, an Allocation Duration subfield, and a PS160 subfield. The Common Info field 2510 comprises a Triggered TXOP Sharing Mode subfield 2512.

[0121] Similar to the MU-RTS TXS frame 1300 in Figure 13, the value of the Triggered TXOP Sharing Mode subfield 2512 may be set to: 'O' to indicate a MU-RTS that does not initiate TXS procedure; 'T to indicate a MU-RTS that initiates TXS procedure wherein a scheduled STA can only transmit MPDU(s) addressed to its associated AP; '2' to indicate a MU-RTS that initiates TXS procedure wherein a scheduled STA can transmit MPDU(s) addressed to its associated AP or addressed to another STA; or '3', which was Reserved, to indicate a MU- RTS (e.g., MU-RTS TXS 2022) that initiates TXS procedure wherein a scheduled STA (e.g., shared APs 2004, 2006) can transmit data in its BSS (e.g., transmit MPDU(s) addressed to its associated STAs or addressed to other APs). The AID12 subfield 2522 may indicate an APID, which is an identifier to uniquely identify an AP among multiple APs.

[0122] Alternatively, the reserved value '3' may not be used, and instead the description for Triggered TXOP Sharing Mode subfield 2512 value '2' may be changed to: a MU-RTS (e.g., MU-RTS TXS 2022) that initiates TXS procedure wherein a scheduled STA (e.g., shared AP 2004) can transmit MPDU(s) addressed to its associated AP or addressed to another STA, or a scheduled AP can transmit data in its BSS (e.g., transmit MPDU(s) addressed to its associated STAs or other APs).

[0123] Each User Info field (e.g., User Info 1 field 2520 and User Info 1 field 2530) may include an allocated TXOP duration and the order of allocation for each shared AP. For example, User Info field 1 2520 may be allocated to shared AP 2004 and User Info field 2 2530 may be allocated to shared AP 2006.

[0124] The order of allocation may be based on LL requirements information included in RTR (e.g., RTR frames 2014, 2015).

[0125] Figures 26A and 26B show flow charts illustrating two phases of a process implemented by a sharing AP according to the third embodiment of the present disclosure. In pre-TXS phase 2610 shown in Figure 26A, in response to obtaining a TXOP in step 2612, a sharing AP (e g., sharing AP 2002) may carry out step 2614, sending a RTRP (e g., RTRP frame 2012) to shared APs (e.g., shared APs 2004, 2006) to solicit RTR (e.g., RTR frames 2014, 2015). In TXS phase 2620 shown in Figure 26B, after receiving a RTR from the shared APs in step 2622, the sharing AP may then carry out step 2624, sending a MU-RTS TXS (e.g., MU-RTS TXS frame 2022) to the shared AP to share the TXOP (e.g., TXOP 2030) based on information in the received RTR. The two phases 2610, 2620 may be executed as two separate methods or the phase 2620 may be carried out as a continuation of the phase 2610, forming a single method.

[0126] Figures 27A and Figure 27B show flow charts illustrating two phases of a process implemented by a shared AP according to the third embodiment of the present disclosure. In pre-TXS phase 2710 shown in Figure 27A, in response to receiving a RTRP (e.g., RTRP frame 2012) from a sharing AP (e.g., sharing AP 2002) in step 2712, each shared AP (e.g., shared APs 2004, 2006) may carry out step 2714, sending a RTR (e.g., RTR frames 2014, 2015) to the sharing AP, the RTR comprising required TXOP duration (e.g., Required TXOP Duration subfield 1120, 1222) and LL information (e.g., LL Requirements Info subfield 1130, 1224). In TXS phase 2720 shown in Figure 27B, after receiving a MU-RTS TXS (e.g., MU-RTS TXS frame 2022) from the sharing AP in step 2722, the shared AP may carry out step 2724, responding with a CTS (e.g., transmitting CTS frames 2024, 2025 to the sharing AP 2002) and then in step 2726, starts data transmission during its allocated time in its own BSS (e.g., transmitting data 2026, 2027 in a BSS of the respective shared AP 2004, 2006 during its allocated TXOP 2032, 2033). The two phases 2710, 2720 may be executed as two separate methods or the phase 2720 may be carried out as a continuation of the phase 2710, forming a single method.Fourth Embodiment

[0127] Figure 28 shows a schematic diagram illustrating a TXOP sharing procedure 2800 involving a sharing AP 2802 and multiple shared APs 2804, 2806, according to a fourth embodiment of the present disclosure. In the procedure 2800, each of the shared APs 2804, 2806 may respectively broadcast unsolicited RTR 2814, 2815 to the sharing AP 2802.

[0128] For example, in TXS phase 2820, the sharing AP 2802 may generate a frame (e.g., MU-RTS TXS frame 2822) for allocating a TXOP (e.g., TXOP 2830) obtained by the sharing AP 2802, the frame allocating (i) a portion (e.g., TXOP 2832) of the TXOP for the shared AP 2804 to transmit data 2826 in a BSS of the shared AP 2804 (e.g., the data 2826 may be transmitted to one or more communication apparatuses in the BSS of the shared AP 2804, such as a STA, another AP, the sharing AP 2802, or other similar communication apparatus) and (ii) another portion (e.g., TXOP 2833) of the TXOP for the shared AP 2806 to transmit data 2827 in a BSS of the shared AP 2806 (e.g., the data 2827 may be transmitted to one or more communication apparatuses in the BSS of the shared AP 2806, such as a STA, another AP, the sharing AP 2802, or other similar communication apparatus). The sharing AP 2802 may then transmit the frame to the shared AP 2804. The frame may allocate the TXOP based on information (e.g., required TXOP duration and LL requirements information) received from the shared APs 2804, 2806 in a previous TXOP or TXS (e.g., TXOP or TXS 2810). The shared AP 2804 may transmit another frame (e.g., RTR 2814, 2815) comprising the information (e.g., broadcast unsolicited RTR 2814, 2815) within its allocated TXOP (e.g., in the previous TXS or TXOP 2810) to help the next round of TXOP sharing (e.g., to allocate the TXOP 2830 in TXS phase 2820).

[0129] After receiving the frame, the shared APs 2804, 2806 may process the frame to perform a CTS procedure (e.g., transmitting GTS frames 2824, 2825 to the sharing AP 2802) and then transmits the data 2826, 2827 in their respective BSS during their allocated TXOP (e.g., TXOP 2832, 2833). Additionally, each AP 28022804, 2806 may broadcast another RTR 2828, 2829, 2835 during its allocated TXOP 2830, 2832, 2833, to help in the next TXOP sharing (e.g., in future TXS 2840).

[0130] In a next TXOP (e.g., future TXS 2840), the sharing AP 2802 may share TXOP according to RTR (e.g., RTR 2828, 2829, 2835) broadcasted by the APs (e.g., sharing AP 2802 and shared APs 2804, 2806).

[0131] Similar to the second embodiment, the RTR in the fourth embodiment may also be a frame having the same format as described in the first embodiment (Figures 10, 11 , and 12B), with the Address 1 field 1020 being set to broadcast address. As an example, each of the RTR 2814, 2815 may have the same format as the RTR frame 1000 in Figure 10 (including the exemplary Control Information subfield 1100 in Figure 11).

[0132] Alternatively, the RTR in the fourth embodiment may also be an element included in a beacon frame and broadcasted, similar to the RTR described in the second embodiment(Figure 17). For example, each of the RTR 2814, 2815 may be an element having the same format as the RTR element 1700 in Figure 17.

[0133] Similar to the third embodiment, in the fourth embodiment, the order of allocation of the TXOP may also be based on the information (e.g., LL requirements information) received from the shared APs 2804, 2806. For example, if only information from shared AP 2806 indicates arrival of data 2827 of a certain traffic type (e.g., LL data) in the previous TXS or TXOP 2810, the sharing AP 2802 may share the TXOP 2830 with the shared AP 2806 first (e.g., by allocating the TXOP 2830 such that TXOP 2833 allocated to shared AP 2806 is before TXOP 2832 allocated to shared AP 2804). The order of allocation of TXOP may also be indicated in the frame (e.g., MU-RTS TXS frame 2822).

[0134] Alternatively or additionally, if any of the shared APs 2804, 2806 does not require TXOP, it may not send RTR 2814, 2815, or indicate 'O' in the Required TXOP Duration subfield 1120, 1734.

[0135] Advantageously, this approach enhances the efficiency of the sharing AP in gathering information of resource request from shared AP, thereby improving the efficiency of TXOP allocation.

[0136] Figure 29 shows a flow chart illustrating a process implemented by a sharing AP according to the fourth embodiment of the present disclosure. In step 2902, a sharing AP (e.g., sharing AP 2802) receives broadcast / unsolicited RTR (e.g., RTR 2814, 2815) from other AP (e.g., shared AP 2804, 2806). Subsequently, the sharing AP may carry out step 2904 during TXOP (e.g., during TXS phase 2820), sending MU-RTS TXS (e.g., MU-RTS TXS frame 2822) to share TXOP (e.g., TXOP 2830) based on information in the received RTR.

[0137] Figure 30 shows a flow chart illustrating a process implemented by a shared AP according to the fourth embodiment of the present disclosure. In step 3002, each shared AP (e.g., shared AP 2804, 2805) may broadcast unsolicited RTR (e.g., RTR 2814, 2815) to other AP (e.g., sharing AP 2802) in a first TXOP (e.g., TXS or TXOP 2810). Then, in response to receiving MU-RTS TXS (e.g., MU-RTS TXS frame 2822) from a sharing AP (e.g., sharing AP 2802) in step 3004, each shared AP may carry out step 3006, responding with CTS (e.g., transmitting a CTS frame 2824, 2825 to the sharing AP 2802) and then in step 3008, starts data transmission during its allocated time in its own BSS (e.g., transmitting data 2826, 2827 in a BSS of the respective shared AP 2804, 2806 during its allocated TXOP 2832, 2833).Fifth Embodiment

[0138] Figures 31A to 32B show schematic diagrams illustrating TXOP sharing procedures according to a fifth embodiment of the present disclosure. In particular, Figure 31A illustrates an exemplary TXOP sharing procedure involving a sharing AP and a single shared AP with a pre-TXS phase before each TXS phase. Figure 31 B illustrates a TXOP sharing procedure similar to that of Figure 31A but without a pre-TXS phase between TXS phases. Figure 32A shows an exemplary TXOP sharing procedure involving a sharing AP and multiple shared APs, with a pre-TXS phase before each TXS phase. Figure 32B illustrates a TXOP sharing procedure similar to that of Figure 32A but without a pre-TXS phase between TXS phases (Figure 32B).

[0139] In the fifth embodiment, after the current TXOP (e.g., TXOP 3110) finishes, the AP (e.g., AP 3104, 3204) that obtains the next TXOP (e.g., 3120, 3220) may become the next sharing AP. The sharing AP 3104, 3204 may then determine whether to include a pre-TXS phase (e.g., pre-TXS phase 3122, 3222) and share the next TXOP with shared AP(s) (e.g., AP 3102 in Figures 31 A and 31 B; APs 3202, 3206 in Figures 32A and 32B). For example, the sharing AP may include a pre-TXS phase in order to collect new information from shared AP(s). Alternatively, the sharing AP may not include a pre-TXS phase in order to initiate next round of TXS immediately. The allocation of the next TXOP may be based on information from unsolicited RTR and implemented according to the TXOP sharing procedures 1600, 2800 described in the second and fourth embodiments.

[0140] For example, in implementations with a single shared AP as shown in Figures 31 A and 31 B, after TXOP 3100, AP 3104 may obtain a next TXOP 3120 and becomes the next sharing AP, sharing the TXOP 3120 with a single shared AP (e.g., AP 3102). In these scenarios, prior to transmission of data from the AP 3102 in its BSS during the next TXOP 3120, the AP 3104 may receive information from the AP 3102 indicating an amount of time required for the AP 3102 to transmit the data in its BSS. During the TXOP 3120, the AP 3104 may then generate a frame (e.g., MU-RTS TXS) for allocating the next TXOP 3120 and transmit the frame to the AP 3102, the frame allocating a portion of the next TXOP 3120 for the AP 3102 to transmit the data in its BSS, with the portion of the next TXOP 3120 being based on the information from the AP 3102.

[0141] The AP 3104 may receive the information during the next TXOP 3120 (e.g., in a pre- TXS phase 3122) or prior to the next TXOP 3120 (e.g., without a pre-TXS phase).

[0142] In implementations with multiple shared APs, for example as shown in Figures 32A and 32B, after TXOP 3200, AP 3204 may obtain a next TXOP 3220 and becomes the next sharing AP, sharing the TXOP 3220 with multiple shared APs (e.g., AP 3202, AP 3206). In these scenarios, prior to transmission of data from the APs 3202, 3206 in their respective BSS during the next TXOP 3220, the AP 3204 may receive information from the APs 3202, 3206 indicating an amount of time required for the APs 3202, 3206 to transmit the data in their respective BSS. During the TXOP 3220, the AP 3204 may then generate a frame (e.g., MU- RTS TXS) for allocating the next TXOP 3220 and transmit the frame to the APs 3202, 3206, the frame allocating portions of the next TXOP 3220 for the APs 3202, 3206 to transmit the data in their respective BSS, with the portions of the next TXOP 3220 being based on the information from the APs 3202, 3206.

[0143] Similarly, the AP 3204 may receive the information during the next TXOP 3220 (e.g., in a pre-TXS phase 3222) or prior to the next TXOP 3220 (e.g., without a pre-TXS phase).

[0144] The benefits of including a pre-TXS phase between TXS phases (as shown in Figures 31A and 32A) may be that new information (e.g., up-to-date resource requirements) can be collected from each shared AP(s) through the pre-TXS phase, ensuring efficient TXOP allocation by minimising unused TXOP and prioritising LL data.

[0145] On the other hand, the benefits of not including a pre-TXS phase between TXS phases (as shown in Figures 31 B and 32B) may be that it allows for more efficient TXOP sharing by initiating the next round of TXS immediately without a pre-TXS phase.Sixth Embodiment

[0146] Figures 33 to 34B show schematic diagrams illustrating a TXOP sharing procedure involving capability exchange between APs, according to a sixth embodiment of the present disclosure.

[0147] As shown in Figure 33, prior to the transmission of a RTR or RTRP frame in a TXOP sharing procedure, a capability exchange 3300 may take place between APs (e.g., sharing AP 3302 and shared AP 3304) in the sixth embodiment. Each AP may transmit a frame (e.g., beacon frame 3312, 3314) indicating its UHR capability (e.g., information about which UHR features are supported) to another AP. Any TXOP sharing procedure according to the first to the fifth embodiments may follow after the capability exchange 3300.

[0148] Referring to Figure 34A, in implementations with solicited RTR (e.g., in the first and third embodiments), capability exchange 3410 may occur prior to the transmission of a frame (e.g., RTR 3424) from the shared AP (e.g., AP 3404) and also prior to the transmission of a trigger frame (RTRP 3422) that solicits the frame. During the capability exchange, the sharing AP (e.g., AP 3402) may transmit a first management frame (e.g., beacon frame 3412) indicating a UHR capability of the sharing AP to the shared AP, and receive a second management frame (e.g., beacon frame 3414) indicating a UHR capability of the shared AP from the shared AP.

[0149] Similarly, referring to Figure 34B, in implementations with unsolicited RTR (e.g., in the second and fourth embodiments), the capability exchange 3410 may occur prior to the transmission of a frame (e.g., RTR 3432) from the shared AP (e.g., AP 3404). During the capability exchange, the sharing AP (e.g., AP 3402) may transmit a first management frame (e.g., beacon frame 3412) indicating a UHR capability of the sharing AP to the shared AP, and receive a second management frame (e.g., beacon frame 3414) indicating a UHR capability of the shared AP from the shared AP.

[0150] The UHR capability of an AP may be indicated by a UHR capabilities element which contains information about which UHR features are supported. The UHR capabilities element may be included in a management frame such as Beacon frame, Probe Request / Response frame, Multi-AP Coordination Setup Request / Response frames transmitted by the AP and broadcasted.

[0151] Advantageously, this approach allows a sharing AP to get new resource requirements from a shared AP through RTRP / RTR, helping to allocate TXOP more efficiently.

[0152] Figures 35 to 38 respectively show an exemplary format of a UHR Capabilities element 3500, 3600, 3700, 3800 according to the sixth embodiment of the present disclosure. The UHR Capabilities element 3500, 3600, 3700, 3800 in Figures 35 to 38 may be examples of a UHR Capabilities element included in a management frame (e.g., beacon frames 3312, 3314, 3412, 3414 in Figures 33 to 34B) and broadcasted by APs during capability exchange.

[0153] The UHR Capabilities element 3500, 3600, 3700, 3800 comprises an Element ID field, a Length field, an Element ID Extension field, and a UHR Capabilities Information field 3510, 3610, 3710, 3810. The Element ID field may be set to '255', and the Element ID Extension field may be set to '118', which were previously Reserved, to indicate the UHR Capabilities element in the present disclosure. The presence of the UHR Capabilities Information field3510, 3610, 3710, 3810 indicates that the AP / STA transmitting the management frame is capable of UHR features. For example, the AP / STA may be a UHR AP / STA, and the management frame may contain information of C-TDMA and RTR. The UHR Capabilities Information field 3510, 3610, 3710, 3810 may comprise a C-TDMA Support subfield 3512, 3612 and a RTR Support subfield 3514, 3714.

[0154] The C-TDMA Support subfield 3512, 3612 indicates whether an AP supports TXOP Sharing between APs (e.g., C-TDMA feature, capable of transmission / reception of MU-RTS TXS to / from peer AP). For example, the C-TDMA Support subfield 3512, 3612 may be set to T to indicate that C-TDMA is supported by the AP, and set to 'O' otherwise.

[0155] The RTR Support subfield 3514, 3714 indicates whether RTR is supported in the AP / STA. For example, the RTR Support subfield 3514, 3714 may be set to T to indicate that RTR is supported by the AP, and set to 'O' otherwise.

[0156] Additionally, there may also be Reserved bits 3516, 3616, 3716, 3816 in the UHR Capabilities Information field 3510, 3610, 3710, 3810 for indicating other UHR capabilities support.

[0157] In a first example shown in Figure 35, the UHR Capabilities Information field 3510 may comprise both the C-TDMA Support subfield 3512 and the RTR Support subfield 3514, which may be set to 'O' or 'T (both C-TDMA and RTR Support are optional features for UHR). For example, if the sharing AP 3402 receives a frame (e.g., beacon frame 3414) with RTR Support subfield 3514 set to T from the shared AP 3404, the sharing AP 3402 may transmit RTRP 3422 to the shared AP 3404 during the TXOP of sharing AP 3402 (e.g., during pre-TXS phase 3420) as shown in Figure 34A. Alternatively, if the shared AP 3404 receives a frame (e.g., beacon frame 3412) with RTR Support subfield 3514 set to T from the sharing AP 3402, the shared AP 3404 may transmit unsolicited RTR (e.g., RTR 3432) to the sharing AP 3402 as shown in Figure 34B.

[0158] Table 4 summarises the relationship between UHR Capabilities element and RTR transmission.Table 4

[0159] In a second example shown in Figure 36, the UHR Capabilities Information field 3610 may comprise the C-TDMA Support subfield 3612, which may be set to 'O' or 'T, without RTR Support subfield (C-TDMA support is an optional feature for UHR APs while RTR support is mandatory for UHR APs).

[0160] For example, if the sharing AP 3402 receives a frame (e g., beacon frame 3414) including UHR Capabilities element 3600 (with RTR being mandatory), from the shared AP 3404 , the sharing AP 3402 may transmit RTRP 3422 to the shared AP during the TXOP of the sharing AP 3402 (e.g., during pre-TXS phase 3420) as shown in Figure 34A. Alternatively, if the shared AP 3404 receives this frame (with RTR being mandatory) from the sharing AP 3402, the shared AP 3404 may transmit unsolicited RTR (e.g., RTR 3432) to the sharing AP 3402 as shown in Figure 34B.

[0161] In a third example shown In Figure 37, the UHR Capabilities Information field 3710 may comprise RTR Support subfield 3714, which may be set to 'O' or 'T, without C-TDMA Support subfield (RTR support is an optional feature for UHR APs while C-TDMA is mandatory for UHR APs).

[0162] For example, if the sharing AP 3402 receives a frame (e.g., beacon frame 3414) including UHR Capabilities element 3700 (with RTR Support subfield set to '1') from the shared AP 3404, the sharing AP 3402 may transmit RTRP 3422 to the shared AP 3404 during the TXOP of the sharing AP 3402 (e.g., during pre-TXS phase 3420) as shown in Figure 34A. Alternatively, if the shared AP 3404 receives this frame (with RTR Support subfield set to '1') from the sharing AP 3402, the shared AP 3404 may transmit unsolicited RTR (e.g., RTR 3432) to the sharing AP 3402 as shown in Figure 34B.

[0163] In a fourth example shown in Figure 38, the UHR Capabilities Information field 3810 may not comprise a C-TDMA Support subfield and a RTR Support subfield (both C-TDMA and RTR are mandatory for UHR APs).

[0164] For example, if the sharing AP 3402 receives a frame (e.g., beacon frame 3414) including UHR Capabilities element 3800 (with RTR being mandatory) from the shared AP 3404, the sharing AP 3402 may transmit RTRP 3422 to the shared AP 3404 during the TXOP of the sharing AP 3402 (e g., during pre-TXS phase 3420) as shown in Figure 34A). If the shared AP 3404 receives this frame (with RTR being mandatory) from the sharing AP 3402, the shared AP 3404 may transmit unsolicited RTR (e g., 3432) to the sharing AP 3402 as shown in Figure 34B.

[0165] Figure 39 shows a flow chart illustrating a communication method according to various embodiments of the present disclosure. At step 3902, a frame for allocating a transmission opportunity (TXOP) obtained by the first AP is generated, the frame allocating a portion of the TXOP for a second AP to transmit data in a basic service set (BSS) of the second AP. At step 3904, the frame is transmitted to the second AP.

[0166] Figure 40 shows a flow chart illustrating another communication method according to various embodiments of the present disclosure. At step 4002, a frame is received from a first AP for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for the second AP to transmit data in a basic service set (BSS) of the second AP. At step 4004, the frame is processed to perform a clear-to-send (CTS) procedure.

[0167] Figure 41 shows a schematic view of a communication apparatus 4100 according to various embodiments of the present disclosure. The communication apparatus 4100 may be implemented as an AP, and more particularly as a sharing AP or a shared AP.

[0168] Various functions and operations of the communication apparatus 4100 are arranged into layers in accordance with a hierarchical model. In the model, lower layers report to higher layers and receive instructions therefrom in accordance with IEEE specifications. For the sake of simplicity, details of the hierarchical model are not discussed in the present disclosure.

[0169] As shown in Figure 41 , the communication apparatus 4100 may include circuitry 4114, at least one radio transmitter 4102, at least one radio receiver 4104, and at least one antenna 4112 (for the sake of simplicity, only one antenna is depicted in Figure 41 for illustration purposes). The circuitry 4114 may include at least one controller 4106 for use in software and / or hardware aided execution of tasks that the at least one controller 4106 is designed to perform, including control of communications with one or more other devices in a wireless network. The circuitry 4114 may further include at least one transmission signal generator4108 and at least one receive signal processor 4110. The at least one controller 4106 may control the at least one transmission signal generator 4108 for generating frames (e g., MU- RTS TXS frames, RTR frames, RTRP frames, trigger frames, CTS frames, management frames, beacon frames, Probe Request / Response frame, Multi-AP Coordination Setup Request / Response frames) to be sent through the at least one radio transmitter 4102 to one or more other communication apparatuses (e g., STAs or APs). The at least one controller 606 may control the at least one receive signal processor 4110 for processing frames received through the at least one radio receiver 4104 from the one or more other communication apparatuses. The at least one transmission signal generator 4108 and the at least one receive signal processor 4110 may be stand-alone modules of the communication apparatus 4100 that communicate with the at least one controller 4106 for the above-mentioned functions. Alternatively, the at least one transmission signal generator 4108 and the at least one receive signal processor 4110 may be included in the at least one controller 4106. It is appreciable to those skilled in the art that the arrangement of these functional modules is flexible and may vary depending on the practical needs and / or requirements. The data processing, storage and other relevant control apparatus can be provided on an appropriate circuit board and / or in chipsets.

[0170] In various embodiments, when in operation, the at least one radio transmitter 4102, at least one radio receiver 4104, and at least one antenna 4112 may be controlled by the at least one controller 4106. Furthermore, while only one radio transmitter 4102 is shown, it will be appreciated that there can be more than one of such transmitters.

[0171] In various embodiments, when in operation, the at least one radio receiver 4104, together with the at least one receive signal processor 4110, forms a receiver of the communication apparatus 4100. The receiver of the communication apparatus 4100, when in operation, provides functions required for processing an information container. While only one radio receiver 4104 is shown, it will be appreciated that there can be more than one of such receivers.

[0172] The communication apparatus 4100, when in operation, provides functions required for transmission opportunity allocation. For example, the communication apparatus 4100 may be a first AP, and the circuitry 4114 may, in operation, generate a frame for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for a second AP to transmit data in a basic service set (BSS) of the second AP. The transmitter 4102 may, in operation, transmit the frame to the second AP.

[0173] The frame may be a multi-user request-to-send (MU-RTS) triggered TXOP sharing (TXS) frame. The frame may allocate the portion of the TXOP based on information received from the second AP. The information may indicate an amount of time required for the second AP to transmit the data in the BSS of the second AP. The information may further indicate at least one of: a traffic type of the data and a traffic priority level of the data. The information may further indicate a bandwidth for transmitting the data by the second AP.

[0174] The receiver 4104 may, in operation, receive from the second AP another frame comprising the information prior to the generation of the frame. The transmitter 4102 may transmit to the second AP a trigger frame to solicit the another frame from the second AP prior to the generation of the frame. The trigger frame may indicate a bandwidth for transmitting the data by the second AP. The frame may further allocate another portion of the TXOP for a third AP to transmit data in a BSS of the third AP, the another portion being based on information received from the third AP. The information from the third AP may indicate an amount of time required for the third AP to transmit the data in the BSS of the third AP. The transmitter 4102 may transmit the frame to the third AP. The frame may indicate an order of allocation of the TXOP for the second AP and the third AP based on the information from the second AP and the information from the third AP.

[0175] The transmitter 4102 may transmit information from the first AP to the second AP, prior to transmission of data in a BSS of the first AP during a next TXOP obtained by the second AP after the TXOP. The information from the first AP may indicate an amount of time required for the first AP to transmit the data in the BSS of the first AP. The receiver 4104 may receive a next frame from the second AP for allocating the next TXOP, the next frame allocating a portion of the next TXOP for the first AP to transmit the data in the BSS of the first AP, the portion of the next TXOP being based on the information from the first AP. The circuitry 4114 may process the next frame to perform a clear-to-send (GTS) procedure. The transmitter 4102 may transmit the information from the first AP to the second AP prior to the next TXOP.

[0176] Prior to the receipt of the another frame from the second AP, the transmitter 4102 may transmit a first management frame indicating an ultra high reliability (UHR) capability of the first AP to the second AP, and the receiver 4104 may receive a second management frame indicating a UHR capability of the second AP from the second AP.

[0177] The communication apparatus 4100 may be a second AP. The receiver 4104 may, in operation, receive a frame from a first AP for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for the second AP totransmit data in a basic service set (BSS) of the second AP. The circuitry 4114 may, in operation, process the frame to perform a clear-to-send (CTS) procedure.

[0178] The frame may be a multi-user request-to-send (MU-RTS) triggered TXOP sharing (TXS) frame. The frame may allocate the portion of the TXOP based on information transmitted by the second AP. The information may indicate an amount of time required for the second AP to transmit the data in the BSS of the second AP. The information may further indicate at least one of: a traffic type of the data and a traffic priority level of the data. The information may further indicate a bandwidth for transmitting the data by the second AP. The transmitter 4102 may, in operation, transmit the data within the indicated bandwidth.

[0179] The transmitter 4102 may transmit to the first AP another frame comprising the information prior to the receipt of the frame. The receiver 4104 may receive from the first AP a trigger frame to solicit the another frame from the second AP prior to the receipt of the frame. The trigger frame may indicate a bandwidth for transmitting the data by the second AP, and the transmitter 4102 may transmit the data within the indicated bandwidth. The frame may further allocate another portion of the TXOP for a third AP to transmit data in a BSS of the third AP, the another portion being based on information received from the third AP. The information from the third AP may indicate an amount of time required for the third AP to transmit the data in the BSS of the third AP. The frame may indicate an order of allocation of the TXOP for the second AP and the third AP based on the information from the second AP and the information from the third AP.

[0180] The receiver 4104 may receive information from the first AP prior to transmission of data in a BSS of the first AP during a next TXOP obtained by the second AP after the TXOP, the information from the first AP indicating an amount of time required for the first AP to transmit the data in the BSS of the first AP. The circuitry 4114 may generate a next frame for allocating the next TXOP, the next frame allocating a portion of the next TXOP for the first AP to transmit the data in the BSS of the first AP, the portion of the next TXOP being based on the information from the first AP. The transmitter 4102 may transmit the next frame to the first AP. The receiver 4104 may receive the information from the first AP prior to the next TXOP.

[0181] The receiver 4104 may receive information from the first AP and the information from the third AP prior to transmission of data in a BSS of the first AP and the data in the BSS of the third AP during a next TXOP obtained by the second AP after the TXOP. The information from the first AP may indicate an amount of time required for the first AP to transmit the data in the BSS of the first AP. The circuitry 4114 may generate a next frame for allocating the nextTXOP, the next frame allocating (i) a portion of the next TXOP for the first AP to transmit the data in the BSS of the first AP, the portion of the next TXOP being based on the information from the first AP and (ii) another portion of the next TXOP for the third AP to transmit the data in the BSS of the third AP, the another portion of the next TXOP being based on the information from the third AP. The transmitter 4102 may transmit the next frame to the first AP and the third AP.

[0182] Prior to the transmission of the another frame to the first AP, the receiver 4104 may receive a first management frame indicating an ultra high reliability (UHR) capability of the first AP from the first AP, and the transmitter 4102 may transmit a second management frame indicating a UHR capability of the second AP to the first AP.

[0183] The present disclosure can be realised by software, hardware, or software in cooperation with hardware. Each functional block used in the description of each embodiment described above can be partly or entirely realised by an LSI such as an integrated circuit, and each process described in each embodiment may be controlled partly or entirely by the same LSI or a combination of LSIs. The LSI may be individually formed as chips, or one chip may be formed so as to include a part or all of the functional blocks. The LSI may include a data input and output coupled thereto. The LSI here may be referred to as an IC, a system on a chip (SoC), a system LSI, a super LSI, or an ultra LSI depending on a difference in the degree of integration. However, the technique of implementing an integrated circuit is not limited to the LSI and may be realised by using a dedicated circuit, a general-purpose processor, or a special-purpose processor. In addition, an FPGA (Field Programmable Gate Array) that can be programmed after the manufacture of the LSI or a reconfigurable processor in which the connections and the settings of circuit cells disposed inside the LSI can be reconfigured may be used. The present disclosure can be realised as digital processing or analogue processing. If future integrated circuit technology replaces LSIs as a result of the advancement of semiconductor technology or other derivative technology, the functional blocks could be integrated using the future integrated circuit technology. Biotechnology can also be applied.

[0184] The present disclosure can be realised by any kind of apparatus, device or system having a function of communication, which is referred to as a communication apparatus.

[0185] Some non-limiting examples of such a communication apparatus include a phone (e.g., cellular (cell) phone, smart phone), a tablet, a personal computer (PC) (e.g., laptop, desktop, netbook), a camera (e.g., digital still / video camera), a digital player (digital audio / video player), a wearable device (e.g., wearable camera, smart watch, tracking device),a game console, a digital book reader, a telehealth / telemedicine (remote health and medicine) device, and a vehicle providing communication functionality (e g., automotive, airplane, ship), and various combinations thereof.

[0186] The communication apparatus is not limited to be portable or movable, and may also include any kind of apparatus, device or system being non-portable or stationary, such as a smart home device (e g., an appliance, lighting, smart meter, control panel), a vending machine, and any other "things" in a network of an "Internet of Things (loT)".

[0187] The communication may include exchanging data through, for example, a cellular system, a wireless LAN system, which is not limited to systems compliant with UHR but may also include systems compliant with any other standards applicable to wireless LAN systems (e.g., Wi-Fi, IEEE 802.15, etc.) and future amendments or enhancements of IEEE 802.11 standards, a satellite system, etc., and various combinations thereof.

[0188] The communication apparatus may comprise a device such as a controller or a sensor which is coupled to a communication device performing a function of communication described in the present disclosure. For example, the communication apparatus may comprise a controller or a sensor that generates control signals or data signals which are used by a communication device performing a communication function of the communication apparatus.

[0189] The communication apparatus also may include an infrastructure facility, such as a base station, an access point, and any other apparatus, device or system that communicates with or controls apparatuses such as those in the above non-limiting examples.

[0190] It will be understood that while some properties of the various embodiments have been described with reference to a device, corresponding properties also apply to the methods of various embodiments, and vice versa.

[0191] In the following paragraphs, certain exemplifying embodiments are explained with reference to terms related to wireless communication and the present disclosure regarding access points and communication methods for transmission opportunity allocation, namely:Example 1 . A first access point (AP) comprising: circuitry, which in operation, generates a frame for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for a second AP to transmit data in a basic service set (BSS) of the second AP; anda transmitter, which in operation, transmits the frame to the second AP.Example 2. The first AP of example 1 , wherein the frame is a multi-user request-to-send (MU-RTS) triggered TXOP sharing (TXS) frame.Example 3. The first AP of example 1 or 2, wherein the frame allocates the portion of the TXOP based on information received from the second AP.Example 4. The first AP of example 3, wherein the information indicates an amount of time required for the second AP to transmit the data in the BSS of the second AP.Example 5. The first AP of example 4, wherein the information further indicates at least one of: a traffic type of the data and a traffic priority level of the data.Example 6. The first AP of example 4 or 5, wherein the information further indicates a bandwidth for transmitting the data by the second AP.Example 7. The first AP of any one of examples 3 to 6, further comprising: a receiver, which, in operation, receives from the second AP another frame comprising the information prior to the generation of the frame.Example 8. The first AP of example 7, wherein the transmitter transmits to the second AP a trigger frame to solicit the another frame from the second AP prior to the generation of the frame.Example 9. The first AP of example 8, wherein the trigger frame indicates a bandwidth for transmitting the data by the second AP.Example 10. The first AP of any one of examples 7 to 9, wherein: the frame further allocates another portion of the TXOP for a third AP to transmit data in a BSS of the third AP, the another portion being based on information received from the third AP, the information from the third AP indicating an amount of time required for the third AP to transmit the data in the BSS of the third AP; and the transmitter transmits the frame to the third AP.Example 11. The first AP of example 10, wherein the frame indicates an order of allocation of the TXOP for the second AP and the third AP based on the information from the second AP and the information from the third AP.Example 12. The first AP of any one of examples 7 to 11 , wherein: the transmitter transmits information from the first AP to the second AP, prior to transmission of data in a BSS of the first AP during a next TXOP obtained by the second AP after the TXOP, the information from the first AP indicating an amount of time required for the first AP to transmit the data in the BSS of the first AP; the receiver receives a next frame from the second AP for allocating the next TXOP, the next frame allocating a portion of the next TXOP for the first AP to transmit the data in the BSS of the first AP, the portion of the next TXOP being based on the information from the first AP; and the circuitry processes the next frame to perform a clear-to-send (CTS) procedure.Example 13. The first AP of example 12, wherein the transmitter transmits the information from the first AP to the second AP prior to the next TXOP.Example 14. The first AP of any one of examples 7 to 13, wherein prior to the receipt of the another frame from the second AP, the transmitter transmits a first management frame indicating an ultra high reliability (UHR) capability of the first AP to the second AP, and the receiver receives a second management frame indicating a UHR capability of the second AP from the second AP.Example 15. A second access point (AP) comprising: a receiver, which in operation, receives a frame from a first AP for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for the second AP to transmit data in a basic service set (BSS) of the second AP; and circuitry, which in operation, processes the frame to perform a clear-to-send (CTS) procedure.Example 16. The second AP of example 15, wherein the frame is a multi-user request-to- send (MU-RTS) triggered TXOP sharing (TXS) frame.Example 17. The second AP of example 15 or 16, wherein the frame allocates the portion of the TXOP based on information transmitted by the second AP.Example 18. The second AP of example 17, wherein the information indicates an amount of time required for the second AP to transmit the data in the BSS of the second AP.Example 19. The second AP of example 18, wherein the information further indicates at least one of: a traffic type of the data and a traffic priority level of the data.Example 20. The second AP of example 18 or 19, wherein the information further indicates a bandwidth for transmitting the data by the second AP, and the second AP further comprises a transmitter, which in operation, transmits the data within the indicated bandwidth.Example 21. The second AP of any one of examples 17 to 20, further comprising: a transmitter, which in operation, transmits to the first AP another frame comprising the information prior to the receipt of the frame.Example 22. The second AP of example 21 , wherein the receiver receives from the first AP a trigger frame to solicit the another frame from the second AP prior to the receipt of the frame.Example 23. The second AP of example 22, wherein the trigger frame indicates a bandwidth for transmitting the data by the second AP, and the transmitter transmits the data within the indicated bandwidth.Example 24. The second AP of any one of examples 21 to 23, wherein the frame further allocates another portion of the TXOP for a third AP to transmit data in a BSS of the third AP, the another portion being based on information received from the third AP, the information from the third AP indicating an amount of time required for the third AP to transmit the data in the BSS of the third AP.Example 25. The second AP of example 24, wherein the frame indicates an order of allocation of the TXOP for the second AP and the third AP based on the information from the second AP and the information from the third AP.Example 26. The second AP of any one of examples 21 to 25, wherein: the receiver receives information from the first AP prior to transmission of data in a BSS of the first AP during a next TXOP obtained by the second AP after the TXOP, the information from the first AP indicating an amount of time required for the first AP to transmit the data in the BSS of the first AP;the circuitry generates a next frame for allocating the next TXOP, the next frame allocating a portion of the next TXOP for the first AP to transmit the data in the BSS of the first AP, the portion of the next TXOP being based on the information from the first AP; and the transmitter transmits the next frame to the first AP.Example 27. The second AP of example 26, wherein the receiver receives the information from the first AP prior to the next TXOP.Example 28. The second AP of example 24 or 25, wherein: the receiver receives information from the first AP and the information from the third AP prior to transmission of data in a BSS of the first AP and the data in the BSS of the third AP during a next TXOP obtained by the second AP after the TXOP, the information from the first AP indicating an amount of time required for the first AP to transmit the data in the BSS of the first AP; the circuitry generates a next frame for allocating the next TXOP, the next frame allocating (i) a portion of the next TXOP for the first AP to transmit the data in the BSS of the first AP, the portion of the next TXOP being based on the information from the first AP and (ii) another portion of the next TXOP for the third AP to transmit the data in the BSS of the third AP, the another portion of the next TXOP being based on the information from the third AP; and the transmitter transmits the next frame to the first AP and the third AP.Example 29. The second AP of any one of examples 21 to 28, wherein prior to the transmission of the another frame to the first AP, the receiver receives a first management frame indicating an ultra high reliability (UHR) capability of the first AP from the first AP, and the transmitter transmits a second management frame indicating a UHR capability of the second AP to the first AP.Example 30. A communication method implemented by a first access point (AP) comprising: generating a frame for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for a second AP to transmit data in a basic service set (BSS) of the second AP; and transmitting the frame to the second AP.Example 31. A communication method implemented by a second access point (AP) comprising:receiving a frame from a first AP for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for the second AP to transmit data in a basic service set (BSS) of the second AP; and processing the frame to perform a clear-to-send (CTS) procedure.

[0192] While exemplary embodiments have been presented in the foregoing detailed description of the present embodiments, it should be appreciated that a vast number of variations exist. It should further be appreciated that the exemplary embodiments are examples, and are not intended to limit the scope, applicability, operation, or configuration of this disclosure in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing exemplary embodiments, it being understood that various changes may be made in the function and arrangement of steps and method of operation described in the exemplary embodiments and modules and structures of devices described in the exemplary embodiments without departing from the scope of the subject matter as set forth in the appended claims.

Claims

CLAIMS1. A first access point (AP) comprising: circuitry, which in operation, generates a frame for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for a second AP to transmit data in a basic service set (BSS) of the second AP; and a transmitter, which in operation, transmits the frame to the second AP.

2. The first AP of claim 1, wherein the frame is a multi-user request-to-send (MU-RTS) triggered TXOP sharing (TXS) frame.

3. The first AP of claim 1 , wherein the frame allocates the portion of the TXOP based on information received from the second AP.

4. The first AP of claim 3, wherein the information indicates an amount of time required for the second AP to transmit the data in the BSS of the second AP.

5. The first AP of claim 4, wherein the information further indicates at least one of: a traffic type of the data and a traffic priority level of the data.

6. The first AP of claim 4, wherein the information further indicates a bandwidth for transmitting the data by the second AP.

7. The first AP of claim 3, further comprising: a receiver, which, in operation, receives from the second AP another frame comprising the information prior to the generation of the frame.

8. The first AP of claim 7, wherein the transmitter transmits to the second AP a trigger frame to solicit the another frame from the second AP prior to the generation of the frame.

9. The first AP of claim 8, wherein the trigger frame indicates a bandwidth for transmitting the data by the second AP.

10. The first AP of claim 7, wherein: the frame further allocates another portion of the TXOP for a third AP to transmit data in a BSS of the third AP, the another portion being based on information received from thethird AP, the information from the third AP indicating an amount of time required for the third AP to transmit the data in the BSS of the third AP; and the transmitter transmits the frame to the third AP.11 . The first AP of claim 10, wherein the frame indicates an order of allocation of the TXOP for the second AP and the third AP based on the information from the second AP and the information from the third AP.

12. The first AP of claim 7, wherein: the transmitter transmits information from the first AP to the second AP, prior to transmission of data in a BSS of the first AP during a next TXOP obtained by the second AP after the TXOP, the information from the first AP indicating an amount of time required for the first AP to transmit the data in the BSS of the first AP; the receiver receives a next frame from the second AP for allocating the next TXOP, the next frame allocating a portion of the next TXOP for the first AP to transmit the data in the BSS of the first AP, the portion of the next TXOP being based on the information from the first AP; and the circuitry processes the next frame to perform a clear-to-send (CTS) procedure.

13. The first AP of claim 12, wherein the transmitter transmits the information from the first AP to the second AP prior to the next TXOP.

14. The first AP of claim 7, wherein prior to the receipt of the another frame from the second AP, the transmitter transmits a first management frame indicating an ultra high reliability (UHR) capability of the first AP to the second AP, and the receiver receives a second management frame indicating a UHR capability of the second AP from the second AP.

15. A second access point (AP) comprising: a receiver, which in operation, receives a frame from a first AP for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for the second AP to transmit data in a basic service set (BSS) of the second AP; and circuitry, which in operation, processes the frame to perform a clear-to-send (CTS) procedure.

16. The second AP of claim 15, wherein the frame is a multi-user request-to-send (MU- RTS) triggered TXOP sharing (TXS) frame.

17. The second AP of claim 15, wherein the frame allocates the portion of the TXOP based on information transmitted by the second AP.

18. The second AP of claim 17, wherein the information indicates an amount of time required for the second AP to transmit the data in the BSS of the second AP.

19. A communication method implemented by a first access point (AP) comprising: generating a frame for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for a second AP to transmit data in a basic service set (BSS) of the second AP; and transmitting the frame to the second AP.

20. A communication method implemented by a second access point (AP) comprising: receiving a frame from a first AP for allocating a transmission opportunity (TXOP) obtained by the first AP, the frame allocating a portion of the TXOP for the second AP to transmit data in a basic service set (BSS) of the second AP; and processing the frame to perform a clear-to-send (CTS) procedure.

Images