Multidimensional Beam Refinement Procedures and Signaling for Millimeter-Wave WLANs

Abstract

A system and method for multidimensional beam refinement procedures and signaling for millimeter-wave WLANs is provided. In one embodiment, there is a multi-dimensional extended beam refinement protocol (eBRP) MAC and PHY frame design that extends MAC packet and PPDU formats with or without backward compatibility. Multiple dimensions may be supported jointly or separately. In other embodiments, increased data signaled in the eBRP frame design may be more efficiently signaled with a reduced BRP frame size, such as through a training type-dependent BRP minimum duration selection procedure or the use of null data packet BRP frames. In a further embodiment, the maximum duration of inter-frame spacing between BRP packets may be changed to improve the efficiency of BRP operation.

Description

[Technical Field]

[0001] The present invention relates to multidimensional beam refinement procedures and signaling for mmWave WLANs. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 417,145, filed November 3, 2016, U.S. Provisional Patent Application No. 62 / 445,642, filed January 12, 2017, and U.S. Provisional Patent Application No. 62 / 500,421, filed May 2, 2017, all three of which are incorporated herein by reference in their entirety.

[0003] Overview of WLAN systems A WLAN in infrastructure basic service set (BSS) mode has an access point (AP / PCP) for the BSS and one or more stations (STAs) associated with the AP / PCP. The AP / PCP typically has access to or an interface with a distribution system (DS) or another type of wired or wireless network that carries traffic to and from the BSS. Traffic to a STA originating from outside the BSS arrives through the AP / PCP and is delivered to the STA. Traffic originating from a STA to a destination outside the BSS is sent to the AP / PCP for delivery to the respective destination. Traffic between STAs within a BSS can also be sent through the AP / PCP if the source STA sends traffic to the AP / PCP, which then delivers the traffic to the destination STA. Such traffic between STAs within a BSS is actually peer-to-peer traffic. Such peer-to-peer traffic can also be sent directly between the source and destination STAs using 802.11e Direct Link Setup (DLS) or 802.11z Tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode does not have an AP / PCP and / or STAs communicate directly with each other. This mode of communication is called an "ad hoc" mode of communication.

[0004] Using the 802.11ac infrastructure mode of operation, an AP / PCP can transmit beacons on a fixed channel, usually the primary channel. This channel can be 20 MHz wide and is the operating channel of the BSS. This channel is also used by STAs to establish a connection with the AP / PCP. The basic channel access mechanism in 802.11 systems is carrier sense multiple access with collision avoidance (CSMA / CA). In this mode of operation, every STA (including the AP / PCP) senses the primary channel. If the channel is detected as busy, the STA backs out. Therefore, only one STA can transmit in a given BSS at any given time.

[0005] In 802.11n (see Non-Patent Document 1), high-throughput (HT) STAs can also use 40 MHz wide channels for communication, which is achieved by combining a primary 20 MHz channel with an adjacent 20 MHz channel to form a 40 MHz wide contiguous channel.

[0006] In 802.11ac (see Non-Patent Document 2), a very high throughput (VHT) STA can support channels of 20 MHz, 40 MHz, 80 MHz, and 160 MHz width. 40 MHz and 80 MHz channels are formed by combining contiguous 20 MHz channels, similar to 802.11n described above. 160 MHz channels can be formed by combining eight contiguous 20 MHz channels or two non-contiguous 80 MHz channels, sometimes referred to as an 80+80 configuration. For the 80+80 configuration, the channel-encoded data is passed through a segment parser, which splits it into two streams. IFFT and time-domain processing are performed separately on each stream. The streams are then mapped onto two channels, and the data is transmitted. At the receiver, this mechanism is reversed, and the combined data is sent to the MAC.

[0007] Sub-1 GHz modes of operation are supported by 802.11af (see Non-Patent Document 3) and 802.11ah (see Non-Patent Document 4). For these specifications, the channel operating bandwidths and carriers are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. A possible use case for 802.11ah is support for meter-type control (MTC) devices in macro coverage areas. MTC devices may have limited capabilities, including support for only limited bandwidths, but may also include the need for very long battery life.

[0008] WLAN systems that support multiple channels and channel widths, e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel designated as the primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS, but not necessarily so. The bandwidth of the primary channel is therefore limited by the STA supporting the smallest bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, the primary channel may be 1 MHz wide if there is an STA (e.g., an MTC-type device) that only supports 1 MHz mode, even if the AP / PCP and other STAs in the BSS may support 2 MHz, 4 MHz, 8 MHz, 16 MHz, or other channel bandwidth operating modes. All carrier sensing and NAV configuration depends on the status of the primary channel. That is, if the primary channel is busy, e.g., due to STAs that only support a 1 MHz mode of operation transmitting to the AP / PCP, the entire available frequency band is considered busy, even if most of it remains idle and available.

[0009] In the United States, the available frequency band that can be used by 802.11ah is from 902 MHz to 928 MHz. In South Korea, it is from 917.5 MHz to 923.5 MHz, and in Japan, it is from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is from 6 MHz to 26 MHz depending on the country code.

[0010] To improve spectral efficiency, 802.11ac introduces the concept of downlink multi-user MIMO (MU-MIMO) transmission to multiple STAs in the same symbol time frame, for example, during a downlink OFDM symbol. The potential for the use of downlink MU-MIMO is also currently being considered for 802.11ah. It is important to note that downlink MU-MIMO, when used in 802.11ac, uses the same symbol timing for multiple STAs, so waveform transmission interference for multiple STAs is not an issue. However, all STAs participating in MU-MIMO transmission with an AP / PCP must use the same channel or band, which limits the operating bandwidth to the minimum channel bandwidth supported by the STAs included in the MU-MIMO transmission with the AP / PCP.

[0011] 802.11ad. 802.11ad is an amendment to the WLAN standard that specifies the MAC and PHY layers for very high throughput (VHT) in the 60 GHz band.

[0012] 802.11ad has the following important features: - Supports data rates up to 7Gbit / s. - Supports three different modulation modes Control PHY with single carrier and spread spectrum Single Carrier PHY OFDM PHY - Use the 60 GHz unlicensed band, which is available globally. At 60 GHz, the wavelength is 5 mm, which allows for compact antennas or antenna arrays. Such antennas can create narrow RF beams at both the transmitter and receiver, which effectively increases coverage range and reduces interference. - The 802.11ad frame structure facilitates mechanisms for beamforming training (discovery and tracking). The beamforming training protocol includes two components: the Sector Level Sweep (SLS) procedure and the Beam Refinement Protocol (BRP) procedure. The SLS procedure is used for transmit beamforming training, while the BRP procedure enables receive beamforming training and iterative refinement of both transmit and receive beams.

[0013] MIMO transmission, including both SU-MIMO and MU-MIMO, is not supported by 802.11ad.

[0014] 802.11ad PPDU Formats. 802.11ad supports three PPDU formats: Control PHY, Single Carrier (SC) PHY, and OFDM PHY PPDU. The PPDU formats defined in Non-Patent Document 2 are shown in Figure 1. Figure 1 shows the Control Format 12, the Single Carrier Format 14, and the OFDM Format 16.

[0015] 802.11ad Control PHY. The Control PHY is defined in 802.11ad as the lowest data rate transmission. Frames transmitted before beamforming training can use the Control PHY PPDU. For 802.11ad, the transmit block diagram of the Control PHY is shown in Figure 2.

[0016] Sector-Level Sweep. An exemplary SLS training procedure is shown in FIG. 3. SLS training can be performed using a beacon frame or an SSW frame. When a beacon frame is used, the AP repeats the beacon frame with multiple beams / sectors within each beacon interval (BI), allowing multiple STAs to simultaneously perform BF training. However, due to the size of the beacon frame, there is no guarantee that the AP can sweep all sectors / beams within one BI. Therefore, a STA may need to wait for multiple BIs to complete ISS training, and latency may be an issue. An SSW frame can be used for point-to-point BF training. The SSW frame can be transmitted using a control PHY, and the frame format is shown in FIG. 4. The SSW field is defined in FIG. 4, and the field format is defined in FIG. 5. The SSW feedback field is given in FIGS. 6A and 6B.

[0017] Beam Refinement Protocol (BRP). Beam refinement is a process by which a STA can improve its antenna configuration (or antenna weight vector) for both transmit and receive. In the beam refinement procedure, BRP packets are used to train the receiver and transmitter antennas. There are two types of BRP packets: BRP-RX packet and BRP-TX packet. BRP packets can be carried by a Directional Multi-Gigabit (DMG) Physical Layer (PHY) Protocol Data Unit (PPDU) followed by a training field that includes an AGC field and a transmitter or receiver training field, as shown in Figure 7.

[0018] The value N in Figure 7 is the training length given in the header field, which indicates that the AGC has 4N subfields and that the TRN-R / T field has 5N subfields. The CE subfield is the same as the CE subfield in the preamble described in the previous section. All subfields in the beam training field are transmitted using rotated π / 2-BPSK modulation.

[0019] The BRP MAC frame is an Action No ACK frame, which has the following fields: - Category - Unprotected DMG actions - Dialogue Token - BRP Request Field - DMG beam refinement elements - Channel Measurement Feedback Element 1 - ... - channel measurement feedback element k

[0020] 802.11ay (TGay). 802.11ay Requirements. Task Group ay (TGay), approved by the IEEE in March 2015, is expected to develop an amendment that defines standardized modifications to both the IEEE 802.11 physical layer (PHY) and the IEEE 802.11 medium access control layer (MAC) that enable at least one mode of operation capable of supporting a maximum throughput of at least 20 Gbit / s (measured at the MAC data service access point) while preserving or improving power efficiency per station. This amendment also defines operation over license-exempt bands above 45 GHz while ensuring backward compatibility and coexistence with legacy directional multi-gigabit stations (defined by the IEEE 802.11ad-2012 amendment) operating in the same bands.

[0021] Although a maximum throughput much higher than that of 802.11ad is a primary goal of TGay, several members of the group also proposed including mobility and outdoor support. More than 10 different use cases have been proposed and analyzed in terms of throughput, latency, operating environment, and application (see Non-Patent Document 5).

[0022] Since 802.11ay will operate in the same bands as legacy standards, it is necessary to ensure that this new technology is backward compatible and coexists with legacy standards in the same bands.

[0023] 802.11ay PPDU Format. It is agreed that the 802.11ay PPDU contains a legacy part and an EDMG part. The detailed PPDU format is shown in Figure 8.

[0024] The Legacy Short Training Field (L-STF), Legacy Channel Estimation Field (L-CEF), L-Header, and EDMG-Header-A fields are transmitted using SC mode for backward compatibility. The following was agreed upon at the IEEE January 2016 meeting: - For control mode PPDUs, reserved bits 22 and 23 shall both be set to 1 to indicate the presence of the EDMG-Header-A field. - For an SC mode PPDU or an OFDM mode PPDU, the reserved bit 46 shall be set to 1 to indicate the presence of the EDMG-Header-A field.

[0025] Millimeter-Wave Precoding: Precoding at millimeter-wave frequencies can be digital, analog, or a hybrid of digital and analog (see Non-Patent Document 6).

[0026] Digital Precoding: Digital precoding is accurate and can be combined with equalization. It enables single-user (SU), multi-user (MU), and multi-cell precoding and is typically used in sub-6 GHz, for example, in IEEE 802.11n and above, and in 3GPP LTE and above. However, at millimeter-wave frequencies, the presence of a limited number of RF chains compared to antenna elements and the sparse nature of the channel complicate the use of digital beamforming.

[0027] Analog Beamforming: Analog beamforming overcomes the problem of a limited number of RF chains by using analog phase shifters on each antenna element. It is used in IEEE 802.11ad during sector-level sweep (which identifies the best sector), beam refinement (which refines the sector into an antenna beam), and beam tracking (which adjusts the sub-beams over time to account for any changes in the channel) procedures. Analog beamforming is also used in IEEE 802.15.3. In this case, a binary search beam training algorithm using a layered multi-resolution beamforming codebook is used. Analog beamforming is typically limited to single-stream transmission.

[0028] Hybrid Beamforming: In hybrid beamforming, the precoder is split between the analog and digital domains. Each domain has separate structural constraints, e.g., a precoding matrix and a combining matrix with a constant modulus constraint on the combining matrix in the analog domain. This design offers a compromise between hardware complexity and system performance. Hybrid beamforming can achieve digital precoding performance due to the sparse nature of the channel and can support multi-user / multi-stream multiplexing. However, it is limited by the number of RF chains. This may not be an issue because mmWave channels are sparse in the angular domain, so this limitation may not be significant.

[0029] Multi-antenna analog beamforming method for 802.11ad+. Based on the problems that analog beamforming has found in IEEE 802.11ad, an analog beamforming method for 802.11ad+ / 802.11ay is proposed in Patent Document 1, entitled "Beamforming Methods and Procedures in mmW WLAN Systems," filed on May 7, 2015. The disclosed embodiment included the following: - Spatial diversity with beam switching. - Spatial diversity with a single beam. - Weighted multipath beamforming training. - Beam Division Multiple Access. - Single-user spatial multiplexing. - Reduced beamforming training overhead.

[0030] In the above disclosure, two architectures have been proposed: the first architecture has all physical antennas (PAs) excited by all weights (shown in FIG. 9), while the second architecture has separate PAs excited by separate weights (shown in FIG. 10).

[0031] In various embodiments, the present disclosure relates to a combination of analog and digital precoding (hybrid mmWave precoding) to enable multi-stream / multi-user transmission. [Prior art documents] [Patent documents]

[0032] [Patent Document 1] U.S. Utility Patent Application No. 14 / 441,237 [Patent Document 2] U.S. Provisional Patent Application No. 61 / 365,014 [Non-patent literature]

[0033] [Non-Patent Document 1] IEEE Standard 802.11TM-2012: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications [Non-patent document 2] IEEE Std 802.11adTM-2012: Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 3: Enhancements for Very High Throughput in the 60 GHz Band [Non-patent document 3] IEEE 802.11-10 / 0258r0, MAC and PHY Proposal for 802.11af, March 2010 [Non-patent document 4] IEEE 802.11-10 / 0001r13, Sub 1 GHz license-exempt PAR and 5C, July 2010 [Non-Patent Document 5] IEEE 802.11-2015 / 0625r2, “IEEE 802.11 TGay Use Cases”, Huawei, et. al [Non-patent document 6] MIMO Precoding and Combining Solutions for mmWave Systems: Alkahteeb, Mo, Gonzalez-Prelcic, Heath, 2014 Summary of the Invention

[0034] The systems and methods described herein are provided for multidimensional beam refinement procedures and signaling for millimeter-wave WLANs.

[0035] BRP MAC Packet for M-Dimensional Transmission. The current BRP MAC in 802.11ad is designed to set up beam refinement and feedback for the single-beam transmission that exists in 802.11ad. In FIG. 11, a MAC packet 1102 includes a BRP request field 1104 and a DMG beam refinement element 1106. The supporting PHY layer PPDU used to estimate the best beam in the BRP procedure is designed for single-beam transmission (as shown in FIG. 12). Elements of this PPDU include an AGC field, a channel estimation field, and a TRN field for a single Tx-Rx antenna pair and signal channel. For multi-dimensional BRP (the dimensions can be multiple transmit-receive beam pairs, multiple polarizations, or multiple channels), methods for extending the MAC packet and PPDU formats with or without backward compatibility are disclosed herein. Multiple dimensions can be supported jointly or separately.

[0036] BRP MAC Packet Overhead: With the increase in the amount of data that needs to be signaled in the BRP MAC packet due to the increase in the number of antennas and beams for M-dimensional transmission described above, a more efficient BRP packet is presented herein to reduce overhead.

[0037] BRP IFS. In 802.11ad, the interframe spacing between a BRP frame and its response is set to a value greater than or equal to the short interframe space (SIFS) and less than or equal to the beam refinement protocol interframe space (BRPIFS) (with the value of BRPIFS held fixed). Due to the improved feedback considering the multidimensionality discussed above, there can be multiple exchanges of BRP frames for optimized operation. Methods for improving the efficiency of BRP operation and for enabling signaling of and / or reduction in BRPIFS duration are disclosed herein.

[0038] BRP IFS and Channel Access. With the possibility of Interframe Spacing being set to BRPIFS=44 usec, STAs in sleep mode or missing a TxOP reservation frame can assume the channel is unoccupied and abort the TxOP. Embodiments are disclosed herein to allow the IFS to be set to a particular value while still tolerating delays in processing. [Brief explanation of the drawings]

[0039] A more detailed understanding may be had from the following description, presented by way of example in conjunction with the accompanying drawings, in which:

[0040] [Figure 1] FIG. 1 illustrates an exemplary PPDU format in 802.11ad. [Figure 2] FIG. 1 is an exemplary control PHY transmission diagram in 802.11ad. [Figure 3] FIG. 1 illustrates an exemplary sector-level sweep training procedure. [Figure 4] FIG. 1 illustrates an exemplary SSW frame format. [Figure 5] FIG. 1 illustrates an exemplary SSW field format. [Figure 6A] FIG. 10 illustrates an exemplary SSW feedback field format when transmitted as part of an ISS. [Figure 6B] FIG. 10 illustrates an exemplary SSW feedback field format when not transmitted as part of an ISS. [Figure 7] FIG. 1 illustrates an exemplary BRP TRN-RX packet. [Figure 8] FIG. 1 illustrates an exemplary PPDU format in 802.11ay. [Figure 9] FIG. 1 illustrates an example architecture for beamforming in which all physical antennas are excited by all weights. [Figure 10] FIG. 1 illustrates an example architecture for beamforming in which different physical antennas are excited by different weights. [Figure 11] FIG. 1 illustrates an exemplary 802.11ad BRP MAC packet for single-stream transmission. [Figure 12] FIG. 1 illustrates an exemplary 802.11ad BRP PPDU for single-stream transmission. [Figure 13] FIG. 1 illustrates an exemplary multiple antenna BRP with two beam pairs for an exemplary initiator and responder. [Figure 14] A diagram showing an example independent BRP request and DMG beam refinement frame for each dimension using independent eBRP signaling. [Figure 15] 15 illustrates an exemplary separate BRP request field that can be incorporated into the frame of FIG. 14. [Figure 16] FIG. 10 illustrates an embodiment of CSD during simultaneous BRP, where the AGC and TRN fields are cyclically shifted as a block. [Figure 17] FIG. 10 illustrates an embodiment of CSD during simultaneous BRP where individual AGC and TRN fields are cyclically shifted. [Figure 18] FIG. 1 illustrates one embodiment of a simultaneous BRP procedure. [Figure 19] FIG. 10 illustrates one embodiment of a joint BRP request field with a fixed number of BRP requests. [Figure 20] FIG. 10 illustrates one embodiment of a joint BRP request field with a dynamic number of BRP requests. [Figure 21] FIG. 1 illustrates one embodiment of an independent eDMG beam refinement element. [Figure 22] FIG. 1 illustrates one embodiment of a joint eDMG beam refinement element. [Figure 23] FIG. 1 illustrates an exemplary multidimensional eBRP procedure with an eMIDC subphase for multiple beam transmission. [Figure 23A] FIG. 1 illustrates an exemplary multidimensional eBRP procedure with an eMIDC subphase for multiple beam transmission. [Figure 24] FIG. 1 illustrates an exemplary multidimensional eBRP procedure with an eBRP eMID sub-phase dedicated to multiple beam transmission. [Figure 25] FIG. 1 illustrates an exemplary R-eMID subphase of multi-beam eBRP. [Figure 26] FIG. 1 illustrates an exemplary R-eBC subphase of multi-beam eBRP. [Figure 27] FIG. 10 illustrates an exemplary minimum duration determination procedure at the receiver side. [Figure 28] FIG. 1 illustrates a first embodiment of an exemplary NDP BRP frame format. [Figure 29] FIG. 10 illustrates a second embodiment of an exemplary NDP BRP frame format. [Figure 30A] FIG. 1 illustrates a baseline case in which inter-frame spacing can vary between short inter-frame spacing (SIFS) and beam refinement protocol inter-frame spacing (BRPIFS). [Figure 30B]FIG. 10 illustrates an embodiment in which a response is available and is sent with an IFS equal to SIFS. [Figure 30C] FIG. 10 illustrates an embodiment in which a response is available and is sent with an IFS equal to SIFS. [Figure 31A] FIG. 10 illustrates an embodiment in which the response is not ready to be sent in SIFS and the responders contend for the channel. [Figure 31B] FIG. 10 illustrates an embodiment in which the response is not ready to be sent in SIFS and the responders contend for the channel. [Figure 31C] FIG. 10 illustrates an embodiment in which the response is not ready to be sent in a SIFS and the initiator polls for a response. [Figure 31D] FIG. 10 illustrates an embodiment in which the response is not ready to be sent in a SIFS and the initiator polls for a response. [Figure 31E] FIG. 10 illustrates an embodiment in which the response is not ready for transmission in a SIFS and the responder occupies the channel until the response is sent. [Figure 32A] FIG. 1 illustrates an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 32B] 32B illustrates an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system of FIG. 32A. [Figure 32C] 32B illustrates an example radio access network (RAN) and an example core network that can be used within the communication system of FIG. 32A. [Figure 32D] FIG. 32B illustrates a second exemplary RAN and a second exemplary core network that can be used within the communications system of FIG. 32A. [Figure 32E] FIG. 32B illustrates a third exemplary RAN and a third exemplary core network that can be used within the communications system of FIG. 32A. [Figure 32F]32B illustrates exemplary network entities that may be used within the communication system of FIG. 32A. [Figure 33] 10 is a graph showing the effect of SC block and IFS on TxOP duration of the BRP procedure. [Figure 34] 1 illustrates an example procedure and signaling for BRP feedback without polling. DETAILED DESCRIPTION OF THE INVENTION

[0041] A detailed description of exemplary embodiments will now be provided with reference to various figures. While this description provides detailed examples of possible implementations, it should be noted that the details provided are intended as examples and in no way to limit the scope of the present application.

[0042] It should be noted that one or more of the various hardware elements of the described embodiments are referred to as “modules,” and that the modules perform (i.e., perform, execute, etc.) various functions described herein with respect to the respective modules. As used herein, a module includes hardware deemed appropriate by one of ordinary skill in the art for a given implementation (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field-programmable gate arrays (FPGAs), one or more memory devices). It should be noted that each described module may also include executable instructions to perform one or more functions described as being performed by the respective module, which may take the form of or include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, etc., and may be stored on any suitable non-transitory computer-readable medium or media, such as commonly referred to as RAM, ROM, etc.

[0043] Network architecture. The systems and methods disclosed herein can be used in conjunction with the wireless communication systems described with respect to Figures 32A-32F. As a first consideration, these wireless systems are described. Figure 32A is a diagram of an example communication system 100 in which one or more disclosed embodiments can be implemented. The communication system 100 can be a multiple-access system that provides content, e.g., voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 can employ one or more channel access methods, e.g., code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), etc.

[0044] 32A, the communications system 100 may include WTRUs 102a, 102b, 102c, and / or 102d (which may be collectively or collectively referred to as WTRUs 102), RANs 103 / 104 / 105, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, consumer electronics devices, etc.

[0045] The communications system 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the core networks 106 / 107 / 109, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a home Node B, a home eNode B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0046] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), e.g., a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). A cell may be further divided into sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and thus utilize multiple transceivers for each sector of the cell.

[0047] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115 / 116 / 117, which may be any suitable wireless communications link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0048] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RANs 103 / 104 / 105 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0049] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 using Long Term Evolution (LTE) and / or LTE Advanced (LTE-A).

[0050] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0051] The base station 114b in FIG. 32A may be, by way of example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as an office, home, vehicle, campus, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. 32A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0052] The RANs 103 / 104 / 105 may be in communication with the core networks 106 / 107 / 109, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. By way of example, the core networks 106 / 107 / 109 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 32A , it will be understood that the RANs 103 / 104 / 105 and / or the core networks 106 / 107 / 109 may be in direct or indirect communication with other RANs employing the same RAT as the RANs 103 / 104 / 105 or a different RAT. For example, the core networks 106 / 107 / 109, in addition to being connected to the RANs 103 / 104 / 105 which may utilize E-UTRA radio technology, may also be in communication with another RAN (not shown) which employs GSM radio technology.

[0053] The core networks 106 / 107 / 109 may also serve as gateways for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and IP in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RANs 103 / 104 / 105 or a different RAT.

[0054] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with separate wireless networks over separate wireless links. For example, the WTRU 102c shown in FIG. 32A may be configured to communicate with a base station 114a that may employ cellular-based wireless technology and with a base station 114b that may employ IEEE 802.11 wireless technology.

[0055] 32B is a system diagram of an example WTRU 102. As shown in FIG. 32B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. The transceiver 120 may be implemented as a component of decoder logic 119. For example, the transceiver 120 and the decoder logic 119 may be implemented on a single LTE or LTE-A chip. The decoder logic may include a processor that operates to execute instructions stored on a non-transitory computer-readable medium. Alternatively, or additionally, the decoder logic may be implemented using custom and / or programmable digital logic circuitry.

[0056] It will be understood that the WTRU 102 may include any sub-combination of the above-described elements while remaining consistent with an embodiment. Embodiments also contemplate that the base stations 114a and 114b and / or the nodes to which the base stations 114a and 114b may correspond (e.g., but not limited to, a transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and a proxy node, among others) may include some or all of the elements shown in FIG. 32B and described herein.

[0057] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 32B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0058] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 115 / 116 / 117. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive IR signals, UV signals, or visible light signals, by way of example. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and receive both RF signals and light signals. It will be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0059] Additionally, although the transmit / receive element 122 is shown as a single element in Figure 32B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0060] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as, for example, UTRA and IEEE 802.11.

[0061] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may access information from and store data in any type of suitable memory, e.g., non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, for example, on a server or home computer (not shown).

[0062] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. By way of example, the power source 134 may include one or more dry batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0063] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. The WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 in addition to or in lieu of information from the GPS chipset 136 and / or determine its location based on the timing of signals received from two or more neighboring base stations. It will be appreciated that the WTRU 102 may obtain location information through any suitable location-determination method while remaining consistent with an embodiment.

[0064] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photos or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, etc.

[0065] Figure 32C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in Figure 32C, the RAN 103 may include Node-Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0066] As shown in Figure 32C, Node-Bs 140a and 140b can be in communication with RNC 142a. Additionally, Node-B 140c can be in communication with RNC 142b. Node-Bs 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b can be in communication with each other via an Iur interface. Each of RNCs 142a and 142b can be configured to control its respective Node-B 140a, 140b, and 140c. Additionally, each of RNCs 142a and 142b can be configured to perform or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0067] The core network 106 shown in Figure 32C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the above elements is shown as part of the core network 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0068] The RNC 142a in the RAN 103 may be connected to an MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to an MGW 144. The MSC 146 and MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communication devices.

[0069] The RNC 142a in the RAN 103 may also be connected to an SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to a GGSN 150. The SGSN 148 and GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0070] As mentioned above, the core network 106 may also be connected to the networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0071] 32D is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0072] The RAN 104 may include eNode Bs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNode Bs while remaining consistent with an embodiment. The eNode Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the eNode Bs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNode B 160a may use multiple antennas, for example, to transmit wireless signals to and receive wireless signals from the WTRU 102a.

[0073] Each of the eNode Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users on the uplink and / or downlink, etc. As shown in FIG. 32D, the eNode Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0074] The core network 107 shown in Figure 32D may include a mobility management entity (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the above elements is shown as part of the core network 107, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0075] The MME 162 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during initial connection of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) employing other radio technologies, such as GSM or WCDMA.

[0076] The serving gateway 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as fixing the user plane during handover between eNode Bs, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0077] The serving gateway 164 may also be connected to a PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0078] The core network 107 may facilitate communication with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the core network 107 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. Additionally, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0079] 32E is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) employing IEEE 802.16 wireless technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117. As discussed further below, the communication links between the separate functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0080] As shown in FIG. 32E, the RAN 105 may include base stations 180a, 180b, and 180c and an ASN gateway 182, although it will be understood that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, and 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, and 180c may implement MIMO technology. Thus, the base station 180a may use multiple antennas, for example, to transmit wireless signals to and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, etc. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, etc.

[0081] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. Additionally, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point (not shown), which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0082] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between the base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point that includes protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0083] As shown in Figure 32E, the RAN 105 can be connected to a core network 109. The communication link between the RAN 105 and the core network 109 can be defined as an R3 reference point, which includes protocols for facilitating data transfer and mobility management functions, by way of example. The core network 109 can include a Mobile IP Home Agent (MIP-HA) 184, an Authentication / Authorization / Accounting (AAA) server 186, and a gateway 188. Although each of the above elements is shown as part of the core network 109, it will be understood that any of these elements can be owned and / or operated by an entity other than the core network operator.

[0084] The MIP-HA 184 may be responsible for IP address management and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. In addition, the gateway 188 may provide access to the network 112 for the WTRUs 102a, 102b, 102c, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0085] 32E, it will be understood that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point (not shown), which may include protocols for coordinating mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point (not shown), which may include protocols for facilitating interworking between a home core network and a visited core network.

[0086] Figure 32F illustrates an exemplary network entity 190 that may be used within the communication system 100 of Figure 32A. As shown in Figure 32F, the network entity 190 includes a communication interface 192, a processor 194, and non-transitory data storage 196, all of which are communicatively linked by a bus, network, or other communication path 198.

[0087] The communication interface 192 may include one or more wired communication interfaces and / or one or more wireless communication interfaces. For wired communication, the communication interface 192 may include one or more interfaces, such as, for example, an Ethernet interface. For wireless communication, the communication interface 192 may include components, such as one or more antennas, one or more transceivers / chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and / or any other components deemed appropriate by those skilled in the art. And further, for wireless communication, the communication interface 192 may be deployed in a scale and configuration suitable to function on the network side rather than the client side of wireless communication (e.g., LTE communication, Wi-Fi communication, etc.). Thus, the communication interface 192 may include appropriate equipment and circuitry (possibly including multiple transceivers) to provide for multiple mobile stations, UEs, or other access terminals in a coverage area.

[0088] Processor 194 may include one or more processors of any type deemed appropriate by one skilled in the art, some examples of which include general purpose microprocessors and special purpose DSPs.

[0089] Data storage 196 can take the form of any non-transitory computer-readable medium or combination of such media (some examples include flash memory, read-only memory (ROM), and random access memory (RAM), to name just a few), as any type or types of non-transitory data storage deemed appropriate by one of ordinary skill in the art can be used. As shown in FIG. 32F, data storage 196 includes program instructions 197 executable by processor 194 to perform various combinations of the various network entity functions described herein.

[0090] In some embodiments, the network entity functions described herein are performed by a network entity having a structure similar to that of network entity 190 of Figure 32F. In some embodiments, one or more of such functions are performed by a set of multiple network entities combined, where each network entity has a structure similar to that of network entity 190 of Figure 32F. In various different embodiments, network entity 190 may be RAN 103 (one or more entities thereof), RAN 104 (one or more entities thereof), RAN 105 (one or more entities thereof), core network 106 (one or more entities thereof), core network 107 (one or more entities thereof), core network 109 (one or more entities thereof), base station 114a, base station 114b, Node-B 140a, Node-B 140b, Node-B 140c, RNC 142a, RNC 142b, MGW 144, MSC 146, SGSN 148, GGSN 150, eNode B 160a, eNode B 160b, eNode B 16 ...b, eNode B 160c, RNC 142a, RNC 142b, MGW 144, MSC 146, SGSN 148, GGSN 150, eNode B 160c, RNC 142b, RNC 142a, RNC 142b, RNC 142b, RNC 142b, RNC 142b, RNC 142b, RNC 142b, RNC 142b, RNC 142b, RNC 142b, RNC 142b, RNC 142b, R The network entities may be, or at least include, one or more of: B 160c, MME 162, serving gateway 164, PDN gateway 166, base station 180a, base station 180b, base station 180c, ASN gateway 182, MIP-HA 184, AAA 186, and gateway 188. And of course, other network entities and / or combinations of network entities may be used in various embodiments to perform the network entity functions described herein, as the foregoing list is provided by way of example and not limitation.

[0091] BRP MAC packets for M-dimensional transmission. The current BRP MAC in 802.11ad is designed to provide setup, beam refinement, and feedback for the single-beam transmission present in 802.11ad. The MAC packet includes a BRP request field and a DMG beam refinement element (see Figure 11). The supporting PHY layer PPDU used to estimate the best beam in the BRP procedure is designed for single-beam transmission (as shown in Figure 12). The elements of this PPDU include an AGC field, a channel estimation field, and a TRN field for a single Tx-Rx antenna pair and signal channel. For multi-dimensional BRP (the dimensions can be multiple transmit-receive beam pairs, multiple polarizations, or multiple channels, etc.), methods for extending the MAC packet and PPDU formats with or without backward compatibility are presented below. Multiple dimensions can be supported jointly or separately.

[0092] Methods and procedures for addressing these and other issues are presented in this section.

[0093] Multidimensional extended beam refinement protocol MAC and PHY frame design. In some embodiments, an enhanced Beam Refinement Protocol (eBRP) MAC frame (and associated PHY PPDU) design is disclosed to support multi-dimensional BRP procedures, which can be specified in terms of space, frequency, and / or polarization. Capability representation for multidimensional eBRP procedures. To enable negotiation of eDMG STA capabilities during the eBRP setup phase, an eDMG Capability field is defined that provides an indication of the following transmission dimensions: 1) the allowed number of transmit-receive beam pairs, 2) the number of channels that can be aggregated or combined, and / or 3) Maximum number of spatial streams.

[0094] This allows an eDMG STA to negotiate these parameters or dimensions to be used with another STA during the eBRP setup procedure. The number of transmit / receive beam pairs can be greater than the number of allowed streams, e.g., N_beams=4 and Nss=2. The final negotiated parameters used in the sector-level sweep procedure include the number of beam pairs and the number of streams.

[0095] BRP procedures and signaling for multidimensional transmission. 13 shows an example initiator 1302 and responder 1304 with two beam pairs. Beam pair 1 is found based on a sweep in the upper sector, while beam pair 2 is found based on a sweep in the lower sector. As such, information on the particular beam pair being refined can be signaled in the updated eBRP packet.

[0096] The eBRP refinement procedure can be signaled and / or performed independently or jointly for each dimension. In various embodiments, the eBRP refinement signaling can be coded or transmitted independently for each dimension. This signaling can occur in the setup phase or during the refinement procedure. In various embodiments, the eBRP refinement procedure can be performed independently for each dimension. In various embodiments, the eBRP refinement signaling can be coded or transmitted jointly for each dimension. In various embodiments, the eBRP refinement procedure can be performed jointly for each dimension.

[0097] A procedure for identifying the quality of each dimension (e.g., transmit / receive beam pair or channel) can be used as input to determine (a) which dimensions will be updated and (b) whether those dimensions will be signaled and / or performed independently or jointly.

[0098] In mmWave beamforming for a single-stream WLAN as implemented in 802.11ad, a transmit-receive pair may undergo the following procedure. - Sector Level Sweep (SLS): Identifies large sectors and allows communication between Tx and Rx at or above the DMG control mode rate. - Beam Refinement Protocol (BRP): enables receiver training and enables iterative refinement of both transmitter and receiver AWVs in both participating STAs.

[0099] The BRP consists of one or more of the following: BRP setup, multiple sector identification and detection (MID), beam combining (BC), multiple sector identification and acquisition (MIDC), beam refinement transaction, etc.

[0100] BRP Setup is responsible for exchanging BRP parameters between the initiator and responder. This step is used only if the BRP does not immediately follow an SLS.

[0101] In the MID, a quasi-omni transmit pattern is tested against a multiple antenna waveform vector (AWV) to identify the best set of receive antennas for the initiator (I-MID) or responder (R-MID). The quasi-omni pattern is the closest to omnidirectional available in eDMG antennas. It can consist of multiple beams and is omnidirectional.

[0102] BC involves testing on an exhaustive pair of sets of transmit and receive AWVs.

[0103] The MIDC combines the MID and BC procedures.

[0104] A beam refinement transaction is a set of BRP frames constructed in response to a request for and response to an AWV test by an initiator or responder.

[0105] For multidimensional transmission, one or more of the following modifications disclosed hereafter can be used:

[0106] An extended sector level sweep (eSLS) can be used to identify large sectors for each dimension, enabling communication between Tx and Rx at or above the eDMG control mode rate. For multiple beam transmissions, SLS can be used to create multiple Tx / Rx beams. The dimensions can be divided by any of the following: time, eDMG antenna, polarization, frequency, etc. To improve the reliability of eDMG control mode transmissions, the following can be used: - A beam selection algorithm that selects the beam with the best quality (e.g., maximum SNR) for transmitting control information and improving the reliability of the control mode. - Beam diversity codes (Alamouti-like codes, e.g., STBC or SFBC) to transmit control information and improve the reliability of eDMG control modes. Regarding the eDMG beam refinement element, note that if the element is sent during request or negotiation (capabilityrequest=1), the transmission can be in diversity mode. In other modes, the transmission can be in diversity, quasi-omni, or beam-based mode.

[0107] An enhanced beam refinement protocol (eBRP) can be utilized to enable receiver training for each beam in each dimension, while also enabling iterative refinement of the antenna weight vectors (AWVs) of all beams at both the transmitter and receiver in both participating STAs.

[0108] In a single-beam MID, the requester feeds back the SNR and sector ID of the last SLS phase to allow the initiator to identify the selected AWV. For multi-dimensional transmissions (e.g., multiple transmit-receive beams or multiple channel transmissions), this information can be signaled in a dimension-specific manner.

[0109] In various embodiments, the eBRP procedure may be performed independently for each beam pair, or may be performed jointly between all (or a subset) of the beam pairs.

[0110] In embodiments with independent eBRP procedure execution, each dimension (e.g., transmit-receive beam pair) performs the eBRP procedure as a separate procedure. This is a simple, backward-compatible extension of the current 802.11ad procedure with additional signaling to indicate the desired beam pair or dimension.

[0111] In independent eBRP signaling, each dimension (e.g., transmit-receive beam pair) has its own independent signaling as shown in Figure 14. Each dimension (e.g., transmit-receive pair) can have its own independent BRP request field 1402 and DMG beam refinement element 1404 to enable feedback of the BS-FBCK field (index of the TRN-T field received with the best quality in the last received BRP-TX). This is a backward-compatible extension of the current 802.11ad procedure.

[0112] In one example, signaling of an additional dimension (which can be labeled as Tx-Rx beam ID, without loss of generality) can be placed in the BRP request field. In this case, the reserved bits (B27 to B31) in the existing BRP request field format can be used (see 1502 in FIG. 15). Frames can be transmitted sequentially. In scenarios where there may be multiple existing dimensions already available for transmitting information, they can be transmitted independently per dimension (e.g., in the case of multiple transmit-receive beam pairs), in which case each dimension can transmit its information on its own beam.

[0113] In embodiments with joint / simultaneous eBRP procedure execution, multiple dimensions (e.g., multiple transmit-receive beam pairs) can perform the eBRP procedure simultaneously. The eBRP procedure can be implemented in multiple ways. For example, in one embodiment, it can be based on an exhaustive search of all possible beam pairs. In another embodiment, it can be based on a search for the next best beam pair conditioned on the selection of the previously selected best beam pair.

[0114] In another embodiment, the eBRP procedure can be based on a simultaneous search of all possible beam pairs. In this case, the 802.11ad BRP PPDU can be modified to support simultaneous transmission of CE, AGC1802, and TRN-T / R1804 signals as shown in FIG. 18 and as discussed in U.S. Patent Application Publication No. 2016 / 0129994, filed July 21, 2016, the entire contents of which are incorporated herein by reference.

[0115] The CEFs can be orthogonalized by sending orthogonal sequences (e.g., using conjugation) or by masking sequences from each spatial stream with an orthogonal matrix. AGC can be sent on multiple streams using techniques, e.g., cyclic shift diversity (CSD), to reduce correlation between streams and allow the receiver to properly configure the AGC settings during simultaneous BRPs. In various embodiments, CSD during simultaneous BRPs can follow two approaches: 1) the AGC field 1602 and the TRN field 1604 are cyclically shifted as a block as shown in FIG. 16, or 2) the individual AGC field 1702 and the TRN field 1704 are cyclically shifted as shown in FIG. 17. In 2), the sequences in the AGC field and the TRN field may be different on each time slot. CSD can also be applied to the EDMG CEF field. In this case, the block cyclic shift for the TRN field in 1) and 2) can also include the EDMG CEF. The TRN-T / R sequences can be orthogonalized by sending orthogonal (e.g., using conjugation) or by masking the sequences from each spatial stream with an orthogonal matrix. Signaling is required to indicate the number of simultaneous streams. This can be signaled in the BRP frame (in MAC) or implicitly by the AGC.

[0116] In embodiments with joint / simultaneous BRP signaling, each dimension (e.g., each transmit-receive pair) is allocated a BRP request field, where the fields can be concatenated in a fixed or dynamic manner.

[0117] In embodiments with fixed concatenation, the number of BRP request fields is fixed based on the maximum number of transmit / receive beams or dimensions required. In cases where the transmit / receive beams do not require refinement, the MID-REQ, BC-REQ, MID-Grant, and BC-Grant fields can be set to zero (see FIG. 19). The number of dimensions to be simultaneously refined (and possible grouping) can also be signaled. In one method, the number of dimensions to be simultaneously processed can be agreed upon during the BRP setup phase. In one method, the number of dimensions to be simultaneously processed can be explicitly signaled in the PHY header or MAC frame, e.g., in the BRP request field. In one method, the grouping of dimensions can be implicitly determined by the arrangement of the BRP request field. In one method, the grouping can be determined by explicit signaling in the PHY header or MAC frame, e.g., in the BRP request field.

[0118] In an embodiment with dynamic concatenation, the number of eBRP request fields is changed based on the number of transmit / receive beams that may require refinement. A parameter indicating the number of eBRP requests can be placed in the BRP frame (e.g., in the PHY or MAC header) or elsewhere in the MAC frame. The number of BRP requests can also be implicitly derived from the length of the BRP frame. This is shown in BRP frame 2000 in FIG. 20.

[0119] For performing a joint eBRP procedure, the eDMG beam refinement element can be modified to allow feedback of a desired number of BS-FBCK and BS-FBCK antenna ID fields. An additional field indicating the corresponding dimension (e.g., transmit-receive beam pair) may be required for some embodiments. In one method, each transmit-receive beam pair can feedback an independent element (see 2100 in FIG. 21).

[0120] This may result in unnecessary overhead due to the commonality of some of the parameters. In another method, a single eDMG beam refinement element can be sent with multiple BS-FBCK, BS-FBCK antenna ID, and dimension (e.g., transmit-receive beam) fields (see 2200 in FIG. 22). In a BRP procedure, the transmitter / receiver may, in some embodiments, need to obtain the Tx sector ID and SNR received during the SLS phase for use in the L-RX field in the BRP sub-phase. In an eBRP procedure, feedback can be identified based on the transmitter-receiver beam pair.

[0121] If detailed channel measurement feedback is desired, the detailed measurements can be per dimension, or the detailed channel measurement feedback can be a composite of all the different dimensions, for example the effective MIMO channel.

[0122] In this case, a simple extension of the 802.11ad BRP feedback can be used, where each channel tap is reported as Nr x Nt x x bits, with the in-phase and quadrature component pairs of the response estimated relative to the amplitude of the strongest I / Q component measured, with each component value expressed as two's complement. An exemplary multi-dimensional eBRP procedure 2300 illustrating the eMIDC subphase for multiple beam transmission is shown in Figure 23, and Figures 25 and 26 show the R-eMID and R-eBC subphases 2500 and 2600 of multi-beam eBRP, respectively. In this example, the dimensions are transmit-receive beam pairs.

[0123] An exemplary multi-dimensional eBRP procedure 2400 illustrating the eBRP eMID sub-phase dedicated to multiple beam transmission is shown in Figure 24. In that example, the dimension is a transmit-receive beam pair.

[0124] As a further example, the method may include performing an extended beam refinement protocol (eBRP) between an initiator device and at least one responder device with respect to at least one transmit-receive beam pair, the at least one transmit-receive beam pair having multiple dimensions.

[0125] The eBRP may include receiver training for each of at least one beam pair, enabling iterative refinement of antenna weight vectors (AWVs) for all beams at both the transmitter and receiver at the initiator device and at least one responder device.

[0126] AWVs can be identified in a dimension-specific manner.

[0127] The eBRP procedure can be performed independently for each of the at least one beam pair.

[0128] Each of at least one beam pair can perform the eBRP procedure as an individual procedure.

[0129] Each dimension of at least one transmit-receive beam pair may include its own independent BRP request field and DMG beam refinement element to enable feedback of the BS-FBCK field.

[0130] The eBRP may be backward compatible with 802.11ad and may signal dimension identification information in the BRP request field.

[0131] Each of at least one beam pair can transmit its own information on its own beam.

[0132] The eBRP procedure can be performed jointly between all of at least one beam pair.

[0133] The eBRP procedure can be based on an exhaustive search of all possible beam pairs.

[0134] The eBRP procedure can be based on a search for the next best beam pair that is conditioned on the selection of the previously selected best beam pair.

[0135] The eBRP procedure can be based on a simultaneous search of all possible beam pairs.

[0136] The BRP PPDU can be modified to support simultaneous transmission of CE, AGC, and TRN-T / R signals.

[0137] The CEFs can be orthogonalized by sending orthogonal or masking sequences from each spatial stream with an orthogonal matrix.

[0138] The AGC can be sent using cyclic shift diversity.

[0139] The AGC and TRN fields can be cyclically shifted as a block.

[0140] The individual AGC and TRN fields can be circularly shifted.

[0141] Cyclic shift diversity can be applied to the EDMG CEF field.

[0142] The TRN-T / R sequences can be orthogonalized by sending orthogonal or masking the sequences from each spatial stream with an orthogonal matrix.

[0143] The number of simultaneous streams can be signaled in the BRP frame.

[0144] The number of simultaneous streams can be implicitly signaled by the AGC.

[0145] Each dimension can be assigned a BRP request field, and the fields are linked together with a fixed linkage.

[0146] The number of BRP request fields can be fixed based on the maximum number of dimensions required.

[0147] Each dimension can be assigned a BRP request field, and the fields are linked together with dynamic linkages.

[0148] The number of eBRP request fields can vary based on the number of transmit and receive beams requesting refinement.

[0149] A parameter indicating the number of eBRP requests can be placed in the BRP frame.

[0150] A parameter indicating the number of eBRP requests can be placed in the MAC frame.

[0151] The number of BRP requests can be implicitly derived from the length of the BRP frame.

[0152] The eDMG beam refinement element can be modified to allow feedback of a desired number of BS-FBCK and BS-FBCk antenna ID fields.

[0153] An additional field may be provided to indicate the corresponding dimension.

[0154] Each of at least one beam pair can feedback an independent element.

[0155] A single eDMG beam refinement element can be sent with multiple BS-FBCK, BS-FBCK antenna ID, and dimension fields.

[0156] The eBRP procedure may be performed jointly for at least a subset of at least one beam pair.

[0157] In another example, a method includes performing an enhanced beam refinement protocol (eBRP) between an initiator device and at least one responder device for at least two transmit-receive beam pairs, each of the at least two transmit-receive beam pairs having at least one dimension. The eBRP can include receiver training for each of the at least two beam pairs and enables iterative refinement of antenna weight vectors (AWVs) for all beams at both the transmitter and receiver at the initiator device and the at least one responder device.

[0158] Another example is a system including a processor and a non-transitory storage medium having instructions stored thereon that, when executed on the processor, operate to perform functions including performing an enhanced beam refinement protocol (eBRP) between an initiator device and at least one responder device for at least one transmit-receive beam pair, the at least one transmit-receive beam pair having multiple dimensions.

[0159] Another example is a system including a processor and a non-transitory storage medium having instructions stored thereon that, when executed on the processor, operate to perform functions including performing an enhanced beam refinement protocol (eBRP) between an initiator device and at least one responder device for at least two transmit-receive beam pairs, each of the at least two transmit-receive beam pairs having at least one dimension.

[0160] Short BRP frame

[0161] BRP MAC packet overhead With the increase in the amount of data to be signaled in the BRP MAC packet due to the increase in the number of antennas and beams for the M-dimensional transmission described above, more efficient BRP packets are presented herein to reduce overhead. The embodiments presented below relate to reducing the size of the BRP frame to increase the efficiency of the BRP procedure, taking into account the multidimensionality described above.

[0162] Training type dependent BRP minimum duration selection procedure In some embodiments, the minimum duration of the data field of a BRP packet can be varied depending on the purpose of BRP training. For example, multiple BRP minimum durations can be defined. A particular BRP minimum duration can be chosen from among the available ones if certain conditions are met.

[0163] In one example, two BRP minimum durations can be defined for various BRP frames: BRP minimum duration 1 (short duration) can be used for BRP-TX packets, BRP-RX packets in which a receiver training request can be sent in the previous frame exchange, and / or BRP packets that can carry a BRP MAC frame but do not have a TRN field attached; BRP minimum duration 2 (long duration) can be used for BRP-RX packets in which a receiver training request can be sent in the MAC body of the current frame.

[0164] Here, a BRP-RX packet can refer to a packet with an attached TRN-R training field that enables receiver antenna weight vector training, and a BRP-TX packet can refer to a packet with an attached TRN-T training field that enables transmitter antenna weight vector training.

[0165] In another example, two BRP minimum durations can be defined for the BRP-RX and BRP-TX packets, respectively.

[0166] The BRP minimum duration can be a set of values ​​greater than or equal to 0. The shortest BRP minimum duration can be set to 0.

[0167] An exemplary transmitter procedure may be as given below. 1) The sender can acquire the medium through contention or scheduling. It can prepare a BRP packet transmission. 2) Depending on the type of BRP training packet, or the use of a BRP frame, or other criteria, the sender may choose a specific BRP minimum duration. 3) The transmitter can signal the selection of the BRP minimum duration implicitly or explicitly in the PLCP header and / or MAC header and / or MAC frame body. In the case of implicit signaling, the signal can be the type of BRP training packet, or the use of a BRP frame, or any other type of criteria that allows the transmitter and receiver to determine a particular BRP minimum duration. 4) The transmitter may prepare a PPDU for a BRP packet. If needed, the data field of the packet may be extended with additional zero padding to meet the BRP minimum duration requirement.

[0168] An example receiver procedure can be as given below (and shown as method 2700 in FIG. 27). 1) At 2702, the receiver can detect a packet. 2) At 2704, by reading the PLCP header and / or MAC header and / or MAC frame body, the receiver can realize that this is a BRP packet. 3) At 2706, according to explicit or implicit signaling, the receiver can determine the specific BRP minimum duration to be used for this packet. 4) At 2712, the receiver may perform data detection using the BRP minimum duration determined at 2706 (eg, BRPmin1 at 2708 or BRPmin2 at 2710).

[0169] A generalized training type dependent BRP minimum duration selection procedure The methods and procedures described above can be extended to the general case. In such an embodiment, a set of BRP minimum durations can be predefined or predetermined. In one example, the set of BRP minimum durations can be discrete integers between 0 and aBRPminLimit. For example, aBRPminLimit can be set to the value 18 in units of SC blocks or OFDM symbols. The set of BRP minimum durations can be defined as {6, 12, 18} in units of SC blocks or OFDM symbols. Alternatively, the set of BRP minimum durations can have finer granularity, such as {0, 1, 2, ..., 18}. STAs, including PCP / AP STAs and non-PCP / AP STAs, can negotiate the use of BRP minimum durations. STA capability to support a predefined or predetermined set or subset of BRP minimum durations can be communicated through an association request / response, a reassociation request / response, a probe request / response, a beacon frame, or other type of management frame. The negotiation can be done explicitly through packet exchanges between the STAs.

[0170] FIG. 33 is a graph 3300 illustrating the impact of SC blocks and IFS on the TxOP duration of a BRP procedure.

[0171] In one example, duration negotiation can be initiated by the PCP / AP as follows: The PCP / AP can send a BRP minimum duration request frame, which can request the STA to report a preferred BRP minimum duration. The STA addressed by the BRP minimum duration request frame can then send a BRP minimum duration response / report frame, which can indicate the preferred BRP minimum duration used by the STA. Optionally, the PCP / AP can confirm the BRP minimum duration for the STA. After negotiation, the BRP minimum duration can be used by the PCP / AP and the STA until it is updated through the exchange of another BRP minimum duration request / response frame.

[0172] In a second example, duration negotiation can be initiated by a non-PCP / AP STA using the following method: The non-PCP / AP STA can send a BRP minimum duration request frame, which can ask the PCP / AP STA to select or adjust a BRP minimum duration for the STA. In this frame, one or more BRP minimum durations supported by the STA can be included. Alternatively, a minimum number of supported BRP minimum durations can be included. The PCP / AP STA addressed by the BRP minimum duration request frame can then send a BRP minimum duration response / report frame, which can indicate the BRP minimum duration for the STA. After negotiation, the BRP minimum duration can be used by the PCP / AP and the STA until it is updated through the exchange of another BRP minimum duration request / response frame.

[0173] In a third example, the PCP / AP can obtain the BRP minimum duration for each associated STA through STA capability exchange, and then the PCP / AP can determine the BRP minimum duration for each STA.

[0174] In an exemplary procedure for selecting the BRP minimum duration in DL MU-MIMO BRP training, the PCP / AP can use a DL MU-MIMO-like scheme to simultaneously train two or more STAs using the full bandwidth. In such an embodiment, the PCP / AP can check the BRP minimum durations for all potential receiving STAs and set the maximum among them as the BRP minimum duration for DL ​​MU-MIMO transmission.

[0175] In some embodiments, a procedure is provided for selecting an MCS due to a BRP minimum duration. Due to the BRP minimum duration requirement, a guaranteed number of resources may be required for the transmission of the MAC body. Therefore, an MCS can be selected to fully utilize those resources.

[0176] Null Data Packet BRP frame. In 802.11, a Null Data Packet (NDP) can refer to a PPDU that includes a PLCP header but no MAC packet. A signaling field in the PLCP header can be overwritten to carry BRP information. Generally, one reserved bit in a PLCP header, including legacy and / or extension header fields, can indicate that this is an NDP MAC frame, and the rest of the bits in that field can be overwritten. A field in the overwritten NDP MAC frame can be used to indicate the MAC frame type. For example, it can indicate that this may be an NDP BRP frame.

[0177] In one approach, a unified NDP BRP frame can be defined to carry information regarding the exchange of simplified BRP frames.

[0178] Alternatively, a set of NDP BRP frames can be defined for different purposes. In this manner, each NDP BRP frame can be required to carry limited information. For example, an NDP BRP frame can include, but is not limited to, the following: - NDP BRP receiver training request frame - NDP BRP receiver training response frame - NDP BRP MIMO training request frame - NDP BRP MIMO training response frame - NDP BRP setup frame - NDP BRP MID frame - NDP BRP BC Frame

[0179] An NDP BRP frame 2800 may be defined as shown in FIG. 28. In this exemplary design, the legacy fields, including the L-STF, L-CEF, and L-header fields, may be the same as those defined in 802.11ad. A field in the L-header may indicate the presence and length of the TRN field. The extended header A field may be overwritten to carry BRP information. The extended STF and CEF fields may be optional. The TRN field may be used for BRP training, which may support MIMO and multi-channel transmission.

[0180] Another NDP BRP frame 2900 may be defined as shown in FIG. 29. In this exemplary design, multi-user BRP training can be performed. The legacy fields, including the L-STF, L-CEF, and L-header, may be the same as those defined in 802.11ad. A field in the L-header may indicate the presence and length of the TRN field. The extended header A field may be overwritten to carry general BRP information. The extended STF and CEF fields may be used for MU AGC and channel estimation. The extended header B field may be overwritten to carry user-specific BRP information. The TRN field may be used for BRP training, which may support MIMO and multi-channel transmission.

[0181] As a further example, a method may include obtaining media at a transmitter; preparing a BRP packet transmission from the transmitter; selecting, at the transmitter, a particular BRP minimum duration from a set of at least two BRP minimum durations; signaling the selection of the BRP minimum duration; preparing a PPDU for the BRP packet; and transmitting the prepared BRP packet transmission from the transmitter to at least one receiver.

[0182] A particular BRP minimum duration may be selected based at least in part on the type of BRP training packet.

[0183] A particular BRP minimum duration may be selected based at least in part on the use of the BRP frame.

[0184] The selection of the BRP minimum duration can be explicitly signaled in one of the PLCP header, the MAC header, or the MAC frame body.

[0185] The selection of the BRP minimum duration may be implicitly signaled based at least in part on one of the type of BRP training packet or the use of the BRP frame.

[0186] detecting a packet transmission at a receiver; determining that the detected packet is a BRP packet; determining a specific BRP minimum duration to be used for the detected BRP packet from a set of at least two BRP minimum durations; and performing data detection at the receiver using the determined BRP minimum duration.

[0187] Determining that the detected packet is a BRP packet may include reading at least one of a PLCP header, a MAC header, or a MAC frame body.

[0188] The step of determining the particular BRP minimum duration may be based at least in part on implicit signaling.

[0189] The step of determining a particular BRP minimum duration may be based at least in part on explicit signaling.

[0190] As another example, a method can consist in utilizing null data packets to overwrite PLCP header information to carry BRP information.

[0191] A unified NDP BRP frame can be defined to carry information about the exchange of simplified BRP frames.

[0192] A set of NDP BRP frames can be defined for various purposes.

[0193] The set of NDP BRP frames may include an NDP BRP receiver training request frame, an NDP BRP receiver training response frame, an NDP BRP MIMO training request frame, an NDP BRP MIMO training response frame, an NDP BRP setup frame, an NDP BRP MID frame, and an NDP BRP BC frame.

[0194] The extension header A field can be overwritten to carry general BRP information, and the extension header B field can be overwritten to carry user-specific BRP information.

[0195] Another example is a system that includes a processor and a non-transitory storage medium storing instructions that, when executed on the processor, operate to perform functions including acquiring media at a transmitter, preparing a BRP packet transmission from the transmitter, selecting a particular BRP minimum duration from a set of at least two BRP minimum durations at the transmitter, signaling the selection of the BRP minimum duration, preparing a PPDU for the BRP packet, and transmitting the prepared BRP packet transmission from the transmitter to at least one receiver.

[0196] Another example is a system that includes a processor and a non-transitory storage medium storing instructions that, when executed on the processor, operate to perform functions including detecting a packet transmission at a receiver, determining that the detected packet is a BRP packet, determining a particular BRP minimum duration to use for the detected BRP packet from a set of at least two BRP minimum durations, and performing data detection at the receiver using the determined BRP minimum duration.

[0197] Another example is a method including, at a STA, receiving a BRP minimum duration request from an AP, responding to the request by identifying a preferred BRP minimum duration, and performing beam refinement with the AP using the identified BRP minimum duration.

[0198] Another example is a method including, at an AP, sending a BRP minimum duration request to a STA, receiving a response to the request identifying a preferred BRP minimum duration, and performing beam refinement with the STA using the identified BRP minimum duration.

[0199] Another example is a method performed by a non-PCP / AP requesting STA, the method including the steps of sending a BRP minimum duration request to a responding STA identifying at least one BRP minimum duration supported by the requesting STA, receiving a response from the responding STA indicating the BRP minimum duration, and performing beam refinement using the identified BRP minimum duration.

[0200] Another example is a method performed by an AP, the method including the steps of communicating with a plurality of STAs to obtain a respective BRP minimum duration for each of the STAs, selecting a maximum value among the obtained BRP minimum durations, and using the selected maximum value among them as the BRP minimum duration for DL ​​MU-MIMO transmission to the STA.

[0201] BRP Interframe Spacing Negotiation BRP IFS. Because of the improved feedback given the multidimensionality described above, some embodiments utilize the exchange of multiple BRP frames for optimized operation. Methods for improving the efficiency of BRP operation and for enabling signaling of and / or reduction in BRPIFS duration are presented below.

[0202] In some embodiments, the maximum duration of inter-frame spacing between BPR packets can be varied depending on the efficiency of the implementation. In some embodiments, the IFS spacing can be quantized to one of a set of possible IFS spacing lengths.

[0203] Signaling can be added to allow the transmitter and receiver to negotiate the values ​​used for beam-based inter-frame spacing parameters, such as one or more of the following: - SBIFS: Short Beamforming Interframe Spacing - BRPIFS: Beam refinement protocol interframe spacing - MBIFS: Medium Beamforming Interframe Spacing - LBIFS: Long Beamforming Interframe Spacing

[0204] A particular IFS spacing can be chosen if certain conditions are met.

[0205] In one embodiment, the IFS is dynamically selected from arbitrary values ​​(i.e., not quantized). In this case, the AP and STAs can signal the actual IFS value to be used to the network, allowing the STAs to identify the actual IFS value to use.

[0206] In an exemplary embodiment, the AP and STAs can allocate a particular IFS to a particular BRP scenario, which can be a function of one of the following: The type of feedback used, e.g., SNR-only feedback vs. SNR+relative channel estimate feedback. The antenna architecture, e.g., the IFS used, may differ in cases where beam switching requires switching between beams of the same DMG antenna versus switching between separate DMG antennas. Note that the actual values ​​can be negotiated and signaled during the DMG setup procedure (e.g., L_rx=10, L_rx_dmg=1,2, etc.).

[0207] If the STA is unable to feedback information within the required timing, the AP can override the requested IFS time by raising the STA IFS to the next IFS duration in the case of a quantized IFS space, or by adding a predetermined value to the IFS value for the system.

[0208] In this case, the AP may need to signal a change in the IFS value.

[0209] In one embodiment, the IFS used can be set based on a reference scenario (or set of reference scenarios), in which case the Tx / Rx pair switches to the reference scenario, measures the IFS, and uses that IFS in the BRP transmission procedure.

[0210] An example scenario can be based on the following: A particular initiator / responder reference configuration, e.g., receive beam, is set within a particular DMG antenna only. Specific types of feedback, e.g., SNR-only feedback. The time intervals, for example, the time interval between receiving a BRP measurement frame and transmitting a response or receive beam, can be switched between each other within a specified number of microseconds.

[0211] It should be noted that the AP and the STAs can negotiate the parameters for their respective reference scenarios.

[0212] In an exemplary embodiment, the IFS negotiation procedure operates as follows: The AP sends an IFS Measurement Setup frame to one or more STAs. The AP can specify a particular configuration or scenario for the measurement. The AP can indicate that the measurement is for one or more specific STAs. Alternatively, the AP can assume that all STAs in the PBSS will be measured. The AP sends out a Channel Measurement frame to the STAs.

[0213] The STA receives the measurement frame and estimates the duration of the IFS needed for transmission. The STA feeds back the IFS measurements to the AP. In one embodiment, the AP solicits the information. For example, the STA can be polled by the AP for the information. In another embodiment, the STA can proactively send the information to the AP, for example, by contending for the channel.

[0214] The AP initiates the BRP procedure. The AP sends a BRP frame with the IFS value that will be used in the BRP setup frame. This allows all other STAs in the network to know the IFS value that will be used. The STA processes the information and feeds it back with the desired IFS between frames. In one embodiment, the STA can start sending information at any time between the set of SIFS and IFS values.

[0215] If the STA is unable to reply with an IFS set, the AP can increase the IFS estimate for the desired scenario.

[0216] 802.11ay BRP with SIFS only. The IFS can vary between SIFS and BRPIFS, as shown at 3002 in Figure 30A. With the possibility that the interframe spacing is set to BRPIFS = 44 usec, STAs in sleep mode or missing a TxOP reservation frame can assume the channel is not occupied and abort the TxOP. To address this issue, the interframe spacing for the BRP can be set to SIFS. However, feedback that requires additional processing time greater than SIFS can benefit from an efficient method for accessing the network. To enable this, one of the following methods can be used.

[0217] If a response is available within the SIFS of the received BRP measurement frame, the response can be sent. Such an embodiment is shown in Figure 30B (IFS 3004) and Figure 30C (IFS 3006).

[0218] If a response is not available within SIFS of receipt of the BRP measurement frame, one or more of the following methods may be employed.

[0219] In one method, an ACK can be sent by the responder, and it is the responder's responsibility to access the channel to feedback the needed information. This can be done by (a) contending for the channel, (b) sending a traffic available frame to the initiator to request channel access, or (c) waiting for the initiator to poll it for feedback. This method is shown in Figures 31A and 31B, which show IFSs 3102 and 3104, respectively.

[0220] In another method, an ACK can be sent by the responder with the minimum time required for access. The initiator can request information (e.g., by polling) at a time interval greater than the time indicated in the ACK. Note that this can be an absolute time interval or a value indicating a quantized time interval. This method is shown in Figures 31C and 31D, which show IFSs 3106 and 3108, respectively.

[0221] In a further method, the responder can transmit dummy information in the interval before the information is ready to be transmitted. In one example, the responder can transmit repeated STF and / or LTF sequences for the duration of the wait interval. This method is shown in Figure 31E, which shows IFS 3110.

[0222] Negotiation of minimum duration and IFS. Negotiation of minimum duration (aBRPminSCblocks) In an exemplary embodiment, the 11ay BRP protocol allows negotiation of a value of aBRPminSCblocks<=18. Negotiation of the minimum duration requires selection and signaling of a value for aBRPminSCblocks. In an embodiment, the PCP / AP and STA may select a minimum duration value from a set of duration values, for example, as follows: aBRPminSCblocks={6 12 18}, {1,2,...,18}

[0223] The signaling used for negotiation can be based on the capabilities of the AP / PCP and the STA. In some embodiments, this can be communicated in a capability exchange procedure, for example, in transmissions using association request / response, reassociation request / response, probe request / response, beacon frames, or other types of management frames. In some embodiments, this can be communicated as capabilities during the BRP setup procedure.

[0224] IFS optimization. The IFS has a significant impact on the efficiency of the BRP feedback. As such, it is beneficial to optimize the IFS to improve the efficiency of the BRP. Various embodiments may use various techniques to optimize the IFS for the BRP. In some embodiments, the value of the IFS is negotiated. In other embodiments, the IFS is limited to only SIFS.

[0225] IFS negotiation. In embodiments that use IFS negotiation, IFS can be selected as one of a discrete set of values. In such embodiments, IFS can be selected from a pre-determined set of values. In some embodiments, the PCP / AP and STA can negotiate a discrete set of resolutions such that SIFS<=IFS<=BRPIFS.

[0226] In an exemplary embodiment, the negotiation procedure may proceed as follows: BRPIFS may be communicated in a capability exchange, e.g., in a transmission using an association request / response, reassociation request / response, probe request / response, beacon frame, or other type of management frame. BRPIFS may be negotiated as part of the BRP setup negotiation, at which point the antenna configuration is expected to have been communicated. If the negotiated value fails, the responder may respond by transmitting one or more PPDUs, e.g., an ACK, to the requesting STA. The initiator may increment the IFS value for subsequent refinements. The initiator may advertise the IFS value to allow other STAs to know the IFS value for channel access.

[0227] Limit IFS to SIFS only. In an exemplary embodiment, the responder transmits a response to the initiator after a SIFS duration upon receiving the BRP measurement frame. If a response is available, the STA sends the response a SIFS duration after the frame is received. If a response is not available, various options are available. In a first option, the responder can respond by transmitting one or more PPDUs (e.g., an ACK) to the requesting STA a SIFS duration after the frame is received. The STA can contend for the channel at a later time and / or the AP can poll the STA at a later time. In a second option, the STA can transmit dummy information until the information is ready, e.g., L-STF.

[0228] As a further example, the method may include varying the maximum duration of inter-frame spacing between BPR packets.

[0229] The method may further include signaling from the transmitter to the receiver to enable negotiation of values ​​to be used for the beam-based inter-frame spacing parameters.

[0230] These parameters may include short beamforming interframe spacing, beam refinement protocol interframe spacing, medium beamforming interframe spacing, and long beamforming interframe spacing.

[0231] A particular inter-frame spacing can be chosen based on particular conditions.

[0232] In an embodiment, a method performed by an AP may include communicating with a plurality of STAs to obtain a respective BRP minimum duration for each of the STAs, selecting a maximum value among the obtained BRP minimum durations, and using the selected maximum value as the BRP minimum duration for DL ​​MU-MIMO transmission to the STA.

[0233] In an embodiment, a method for negotiating an IFS may include, at an AP, sending an IFS measurement frame to at least one STA, sending a channel measurement frame to at least one STA, receiving respective estimated IFS durations from the at least one STA, and performing a BRP procedure using the received estimated IFS durations.

[0234] The AP may poll at least one STA during each estimated IFS duration.

[0235] The BRP procedure may include sending a BRP setup frame that identifies the IFS value to be used.

[0236] In an embodiment, a method includes negotiating an inter-frame spacing (IFS) between a PCP / AP and a STA, where the IFS can be selected from a predetermined set of values.

[0237] Another example is a method of IFS negotiation, including, at an AP, sending an IFS measurement frame to at least one STA, sending a channel measurement frame to at least one STA, receiving respective estimated IFS durations from the at least one STA, and performing a BRP procedure using the received estimated IFS durations. The AP can poll the at least one STA during each estimated IFS duration. Performing the BRP procedure can include sending a BRP setup frame identifying the IFS value to be used.

[0238] Detailed procedure with fixed IFS. To limit IFS to SIFS only, in the 11ay BRP protocol, in some embodiments there will be an option for the BRP frame to act as an Action ACK frame.

[0239] Exchange of abilities In some embodiments, the capabilities of the STA may be signaled by a beamforming capability field format as shown below: The beamforming capability field may be implemented as shown below.

[0240] [Table 1]

[0241] The "BRP Action ACK Supported" field is set to 1 to indicate that the BRP request frame will be acknowledged within the SIFS duration of receipt. If the information is available, the STA will respond with the required information. If the information is not available, the STA will respond with an ACK.

[0242] The "ACK with Contention Supported" field is set to 1 if the STA can contend for the channel when information is ready to be fed back to the requester, and 0 otherwise.

[0243] The "ACK with polling supported" field is set to 1 if the STA can be polled before feeding information back to the requestor, and 0 otherwise.

[0244] Note that the initiator can set the parameters to contention only, polling only, or both.

[0245] These fields can be placed in separate capability fields or added to different frames such as the EDMG BRP request field.

[0246] In another embodiment, the beamforming capability field may be defined according to the following beamforming capability field format:

[0247] [Table 2]

[0248] The BRP Action ACK response subfield indicates whether the responding STA should contend to feed back information or whether the requesting STA should poll the responding STA for BRP information.

[0249] [Table 3]

[0250] Signaling an Immediate Response Request: Method 1 In one method, the existing DMG No Action ACK BRP frame can be modified to signal the need for an immediate acknowledgment in the BRP Setup frame, indicating that an ACK response is required SIFS duration after the packet is received. The current 802.11 standard has a category for unprotected DMG frames with a type value of 00 (management frame) and a subtype value of 1110 (No Action ACK). The existing BRP frame is defined as a No Action Ack frame under the unprotected DMG frame. The detailed frame format of the BRP frame is given below.

[0251] [Table 4]

[0252] In an exemplary embodiment, a variety of different schemes for signaling an immediate acknowledgment required in the current BRP frame can be used, including the following techniques. 1. Modifying the BRP request fields (described below in the section "Modified DMG BRP Request Fields") 2. Modifying the EDMG BRP requirement elements (described below in the section titled "Modified EDMG BRP requirement elements") 3. Add the EDMG BRP required fields (described below in the section "EDMG BRP Required Fields").

[0253] Signaling an Immediate Response Request: Method 2 In one method, an EDMG BRP frame is introduced and can be defined as a DMG action frame, which can be used to indicate that an acknowledgment is required.

[0254] A new EDMG BRP frame can be introduced under the category DMG frame with a type value of 00 (management frame) and a subtype value of 1101 (action frame). To do so, an entry can be inserted into the DMG action field. For example, a DMG action field value = 23 can be used to indicate that the frame is an EDMG BRP frame.

[0255] [Table 5]

[0256] The detailed EDMG BRP frame format can be as disclosed below.

[0257] [Table 6]

[0258] In an exemplary embodiment, the Category field is defined as DMG. The DMG Action field is defined as EDMG BRP Frame. The Dialogue Token field is set to a value chosen by the STA transmitting the frame to uniquely identify the transaction. The BRP Request field can be defined as present in the standard. Alternatively, this field can be updated as described in the section titled "Modified DMG BRP Request Field." The DMG Beam Refinement element is defined in 9.4.2.130 of 802.11-2016. The Channel Measurement Feedback element is defined in 9.4.2.136.

[0259] A BRP frame contains multiple channel measurement feedback elements if the measurement information exceeds 255 octets. The content of each channel measurement feedback element following the first element in a single BRP frame is a continuation of the content of the previous element. The channel measurement, tap delay, and sector ID order subfields may be split among several elements. Each channel measurement feedback element that is not the last channel measurement feedback element in a frame is 257 octets long. The channel measurement information for a single channel measurement is always contained within a single BRP frame.

[0260] It can be noted that the length of the BRP frame can limit the selection of channel measurement parameters such as the number of measurements and the number of taps.

[0261] The EDMG BRP Request element can be defined as is, or this field can be modified as described in the section titled "Modified EDMG BRP Request Element." In some embodiments, the EDMG BRP Request field can be a newly inserted field as described in the section titled "EDMG BRP Request Field."

[0262] Signaling an Immediate Response Request: Method 3 In one exemplary method, an existing DMG No Action ACK BRP frame can be modified to signal the need for an immediate acknowledgment in the BRP Setup frame, indicating that an ACK response is required SIFS duration after the packet is received. The current 802.11 standard has a category for unprotected DMG frames with a type value of 00 (management frame) and a subtype value of 1110 (No Action ACK). The existing BRP frame is defined as a No Action ACK frame under the Unprotected DMG category. The BRP frame in this case is an Action or No Action ACK frame in the Unprotected DMG category. In some embodiments, the existing BRP frame settings are modified from a subtype value of 1110 (No Action ACK) to a subtype value of 1101 (Action), and the rest of the parameter settings are retained to create a new EDMG Action ACK frame.

[0263] When performing a BRP, if the BRP frame is a management frame of subtype Action, and if the responding STA requires more than a SIFS to send the BRP frame in response to a beam refinement training request from the requesting STA, the STA sends an ACK frame or an EDMG BRP ACK frame in response to the beam refinement training request.

[0264] To send a BRP response to the requesting STA,

[0265] The requesting STA may send a feedback poll to request a response.

[0266] The responding STA can contend for the media and send a response back.

[0267] If the reverse direction protocol is supported by both the requesting and responding STAs, the requesting STA can allocate time for feedback through a reverse direction grant.

[0268] The BRP response method can be selected during the BRP setup phase. The STA can indicate the additional time required in the EDMG BRP ACK.

[0269] The BRP Setup subphase may begin with the initiator sending a BRP packet with the Capabilities Request subfield in the DMG Refinement field set to 1 and with the remaining subfields in the BRP Request / EDMG Request fields set according to the initiator's desired method of response. Upon receiving a BRP packet with the Capabilities Request subfield set to 1, the responder will respond with a BRP packet with the subfields in the BRP Request field set to indicate the desired BRP response method. This process is repeated until the responder sends a BRP packet to the initiator with the Capabilities Request subfield set to 0, and the initiator sends a BRP packet in response, also with the Capabilities Request subfield set to 0.

[0270] The detailed frame format of an exemplary BRP frame is given below.

[0271] [Table 7]

[0272] In an exemplary method, various techniques can be used to signal an immediate acknowledgment that is required in the current BRP frame, including the following: 1. Modifying the BRP request field (as described in the section "Modified DMG BRP Request Field") 2. Modifying the EDMG BRP requirement elements (as described in the section entitled "Modified EDMG BRP requirement elements") 3. Adding EDMG BRP Request Fields (as described in the section "EDMG BRP Request Fields")

[0273] Modified EDMG BRP requirement elements In some embodiments, in both action and no-action BRP frames, the EDMG BRP Request element can be updated as follows:

[0274] [Table 8]

[0275] The Action ACK subfield indicates whether an acknowledgment is required SIFS duration after the transmission of the request. If this field is set to 0, then no response is required SIFS duration after the receipt of the request. Instead, a response is required within BRPIFS duration after the receipt of the request. If the field is set to 1, then a response is required SIFS duration after the receipt of the request.

[0276] In the case where a response is ready, the response serves as an acknowledgement. In the case where a response is not ready, an ACK can be sent as a response. Alternatively, this field can be absent. Note that this field is most suitable for Method 1, which uses a single DMG No Action ACK frame to signal the need for an ACK. For Methods 2 and 3, which define specific Action ACK frames, this field can be optional.

[0277] The Action ACK response subfield can be used to indicate whether the responder should contend to feedback information or whether the responder should be polled.

[0278] [Table 9]

[0279] The BF Poll field indicates that there is no further TRN field being sent, but that this is a request for feedback regarding a previously transmitted BRP request with the exact same parameters. In another embodiment, the TX Sector ID can be used as an identifier in the feedback to indicate the specific BRP transmission (e.g., in a contention-based transmission) that the feedback is for.

[0280] Given that a reasonable estimate of the duration needed before feedback is ready depends on the information requested and the EDMG antenna configuration, a timing estimate can be sent back along with the acknowledgement frame. In one method, the ACK can include a control trailer to indicate the amount of time needed before the information is ready. In this case, for the ACK frame sent, the TXVECTOR parameter CONTROL_TRAILER will be set to Present and the parameter CT_TYPE will be set to ACK. The control trailer in this case can be a single data octet. Alternatively, an EDMG BRP ACK can be sent that includes the required time.

[0281] EDMG BRP Request Fields Alternatively, in some embodiments, the EDMG BRP Request field can be defined to carry acknowledgment-related information. In both action and no-action BRP frames, the EDMG BRP Request field can be updated as follows:

[0282] [Table 10]

[0283] The Action ACK subfield indicates whether an acknowledgment is required after a SIFS duration of receipt of the request. If this field is set to 0, no response is required after a SIFS duration of receipt of the request. Instead, a response is required within a BRPIFS duration of receipt of the request. If the field is set to 1, a response is required after a SIFS duration of receipt of the request. In the case where a response is ready, the response acts as an acknowledgment. In the case where a response is not ready, an ACK can be sent as a response. Alternatively, this field can be absent.

[0284] The Action ACK response subfield indicates whether the responder should contend to feedback information or whether the responder should be polled.

[0285] [Table 11]

[0286] The BF Poll field indicates that there is no further TRN field being sent, but that this is a request for feedback regarding a previously transmitted BRP request with the exact same parameters. In another embodiment, the TX Sector ID can be used as an identifier in the feedback to indicate the specific BRP transmission (e.g., in a contention-based transmission) that the feedback is for.

[0287] Modified DMG BRP request fields Alternatively, the existing DMG BRP request fields can be modified to carry acknowledgment related information.

[0288] [Table 12]

[0289] The Action ACK subfield indicates whether an acknowledgment is required after a SIFS duration of receipt of the request. If this field is set to 0, no response is required after a SIFS duration of receipt of the request. Instead, a response is required within a BRPIFS duration of receipt of the request. If the field is set to 1, a response is required after a SIFS duration of receipt of the request. In the case where a response is ready, the response acts as an acknowledgment. In the case where a response is not ready, an ACK can be sent as a response. Alternatively, this field can be absent.

[0290] The Action ACK response subfield indicates whether the responder should contend to feedback information or whether the responder should be polled.

[0291] [Table 13]

[0292] The BF Poll field indicates that there is no further TRN field being sent, but that this is a request for feedback regarding a previously transmitted BRP request with the exact same parameters. In another embodiment, the TX Sector ID can be used as an identifier in the feedback to indicate the specific BRP transmission (e.g., in a contention-based transmission) that the feedback is for.

[0293] In one embodiment, the requesting and responding STAs can decide on a default method of feedback, e.g., contention or polling. The Action ACK response can then be a single bit indicating whether a non-default method is supported. This can be signaled in a modified EDMG BRP Request element, an EDMG BRP Request field, or a Beamforming Capability field.

[0294] [Table 14]

[0295] EDMG BRP ACK frame format If a BRP response may not be ready within a SIFS duration after receiving a BRP frame, a regular ACK frame may be used.

[0296] Alternatively, a newly defined EDMG BRP ACK frame can be used to carry further information such as an estimated time to prepare the required BRP feedback. The EDMG BRP ACK frame can be defined below.

[0297] [Table 15]

[0298] In a third method, a normal ACK frame can be carried in a control mode PPDU, where a control trailer can be appended as shown below.

[0299] [Table 16]

[0300] The Duration field is set as defined in 9.2.5 of 802.11-2016.

[0301] RA is set to the receiving STA that requested the BRP transmission. The time estimate is the minimum duration that the receiving STA will delay before:

[0302] The requesting STA can poll for a BRP response.

[0303] The requesting STA may set up the reverse protocol link.

[0304] A requesting STA can configure the CBAP to allow transmitters to contend for the channel.

[0305] The time estimate can indicate the number of SIFS that the receiving STA should wait. Note that the upper limit can be set as the legacy BRPIFS value (44 usec) or approximately 15 SIFS durations (of 3 usec each), or can be set to any value. In one solution, the duration is 2 sig- naled with 4 bits as shown in the diagram below. * SIFS(6usec)<Interval<15 * SIFS (45usec) and can be set to a specific value. * Note that SIFS entries default to BRPIFS wait times, similar to DMG behavior.

[0306] [Table 17]

[0307] In an exemplary embodiment, all 8 bits can be used to quantize the 44 usec interval, or the duration can be expressed in usec as in the duration field (e.g., 256 usec).

[0308] To define an EDMG BRP ACK frame, a control frame extension value can be set to indicate the newly defined frame. For example, in the proposed EDMG BRP ACK frame, the type value in the frame control field can be set to 01 to indicate a control frame. The subtype value in the frame control field can be set to 0110 to indicate a control frame extension. Along with the control frame extension subtype, bits 8 through 11 can be set to specific values ​​to indicate an EDMG BRP ACK frame. For example, the following settings can be used:

[0309] [Table 18]

[0310] Procedures and Signaling for Polling-Based BRP Feedback In the case where an ACK frame can be transmitted SIFS duration after receipt of a BRP request frame, a BRP feedback frame, which can carry information requested by the previous BRP request frame, can be transmitted via a polling-based procedure, in which a frame can be used to poll for the BRP feedback frame.

[0311] For polling-based feedback, the following techniques can be used.

[0312] In some embodiments for polling-based feedback, a BF Poll is used. To enable this, a unique BF identifier can be generated from fields in the BF Request. The BF Poll and BF Feedback Response can use this unique identifier to identify the specific feedback. This identifier can be placed in the BRP Feedback Poll Request / Response fields below.

[0313] [Table 19]

[0314] [Table 20]

[0315] In other embodiments, for polling-based feedback, an updated BR request frame can be used with an added parameter to indicate that the request is for a previously sent BRP request as discussed above. The BF Poll response can use a unique identifier. Alternatively, an EDMG BRP request can be sent along with the response. In this case, all or some of the fields of the BRP frame are sent. A scenario in which a subset of the frame is sent is shown below.

[0316] [Table 21]

[0317] For contention-based feedback, the PCP / AP can set up a general CBAP in the DTI for feedback. Alternatively, the PCP / AP can set up a dedicated CBAP for feedback in the DTI that is limited to the STAs that sent the ACK. The PCP / AP can send the addresses of the STAs that can be allowed to contend during this period.

[0318] Procedures and signaling for BRP feedback without polling In cases where an ACK frame can be transmitted SIFS duration after receipt of a BRP request frame, a BRP feedback frame that can carry information requested by the previous BRP request frame can be transmitted through a BRP feedback procedure without polling.

[0319] A BRP initiator can send a BRP frame requesting BRP training. In the BRP frame, the initiator can indicate that a response can be required SIFS duration after receipt of the BRP frame.

[0320] Upon receiving a BRP frame, the responder may not have enough time to prepare the required BRP response frame. The responder may send an ACK frame SIFS duration after receiving a BRP frame sent by the initiator. The responder may transmit a response frame carrying the requested information BRFIFS duration after receiving the BRP frame transmitted by the initiator. Before transmitting the BRP response frame, the responder may operate to sense the channel. If the channel is free for a predefined / predetermined period, the BRP response frame may be transmitted. In one method, the STA may not need to extend the backoff period set by the EDMA backoff timer further. In cases where a STA may not be able to successfully transmit a BRP response frame within the BRPIFS duration from the end of the BRP request frame sent by the initiator, the STA may (i) wait for the SP assigned to the STA to transmit, (ii) wait for the next CBAP to contend to transmit, or (iii) aggregate the BRP response frame with other data, control, or management frames and send them to the initiator. Alternatively, the responder can send a response frame carrying the requested information a duration T after receiving the BRP frame sent by the initiator, where SIFS<=T<+BRPIFS. Before transmitting the BRP response frame, the responder may need to sense the channel. If the channel is free for a predefined / predetermined period, the BRP response frame can be transmitted. In one method, the STA may not need to extend the backoff period set by the EDMA backoff timer further. In cases where a STA may not be able to successfully transmit a BRP response frame within the BRPIFS duration from the end of the BRP request frame sent by the initiator, the STA may (i) wait for the SP assigned to the STA to transmit, (ii) wait for the next CBAP to contend to transmit, or (iii) aggregate the BRP response frame with other data, control, or management frames and send them to the initiator.

[0321] An exemplary embodiment of the procedure and signaling for BRP feedback without polling is shown in FIG. 34, which shows an IFS 3402.

[0322] Procedures and signaling involved in the exchange of BRP response time capabilities Alternatively, or in addition, the beamforming field may include an indication of the STA's capability in providing feedback after receiving a BRP frame. For example, a STA may indicate its capability regarding the expected time for transmitting a response frame after receiving a BRP frame. One or more bits in the EDMG capabilities field, e.g., in the beamforming field, may be used to indicate the expected BRP response time. In one embodiment, a bit may be used to indicate the presence of an expected BRP response time. The expected BRP response time may be indicated by one or more bits and may be indicated in terms of us, SIFS, or any other time unit. In one embodiment, a STA may indicate multiple expected BRP response times, e.g., in the EDMG capabilities field, e.g., in the beamforming field. For example, a STA may indicate an expected BRP response time for SU and / or MU MIMO training, and a STA may indicate an expected BRP response time for one or more spatial streams.

[0323] A STA may communicate its capabilities for, or one or more of its expected BRP response times, during the association process with an AP, for example, in a probe request or (re)association frame. An AP / PCP may publish its capabilities for, or one or more of its expected BRP response times, in its beacon and / or in a probe response or (re)association response frame. In addition, an AP / PCP may publish one or more maximum expected BRP response times for all STAs associated with it. For example, an AP / PCP may publish the maximum expected BRP response time for all STAs associated with it; in another example, an AP / PCP may publish the maximum expected BRP response time for SU and / or MU MIMO for all STAs associated with it; in another example, an AP / PCP may publish the maximum expected BRP response time for one or more spatial streams for all STAs associated with it. A STA may adapt one or more maximum BRP response times in its BRP protocol after receiving from its AP / PCP, for example, in a beacon, probe response, or (re)association response frame.

[0324] Additionally and / or alternatively, a STA can indicate in a frame setting up a BRP exchange sequence that an appropriate BRP response time should be applied. For example, the AP / PCP can indicate the appropriate BRP response time to be used for the BRP exchange sequence, e.g., in an extended schedule element or grant frame. The AP / PCP can obtain the maximum BRP response time required by all STAs that will provide feedback. The AP / PCP can obtain the maximum BRP response time required by all STAs that will provide SU, feedback regarding MU training, one or more SS feedbacks, etc., based on information obtained by the AP / PCP earlier, e.g., during the association process or during the BRP request or service period request time. For example, if four STAs are providing feedback in MU MIMO training, the maximum expected BRP response time is the maximum expected BRP response time among all four STAs. If both the initiator and responder can provide feedback, the maximum expected BRP response time can be the maximum expected BRP response time among the initiator and responder STAs.

[0325] If a responder STA indicates a need for training in response to SSW feedback, it may indicate its expected BRP response time or times in a BRP request field, e.g., in an SSW-ACK frame. The initiator may use the most appropriate indicated BRP response time in its subsequent BRP execution.

[0326] The AP / PCP and / or initiator can publish an applicable BRP response time to be used in upcoming BRP sequence exchanges. If the responder is unable to provide feedback, it can respond with an ACK frame. It can also include the expected BRP response time in the ACK. If the expected BRP response time in the ACK sent by the responder is longer than the published BRP response time by the AP / PCP or initiator, the initiator can adjust the BRP response time in subsequent BRP frames.

[0327] In one embodiment, if the responding STA is not ready to send a BRP response when the SIFS duration has elapsed, the STA sends an ACK to the requesting STA. The requesting STA can request the information BRPIFS duration after receipt of the ACK or later. Alternatively, the requesting STA can request the information BRPIFS duration after receipt of the ACK or later when it estimates that the transmitted packet has arrived at the responding STA. This eliminates the need for any further timing information.

[0328] Define the BRP Action ACK frame In an exemplary embodiment, if the BRP frame is a management frame of subtype Action, the beam refinement response will be separated from the preceding beam refinement request by a SIFS interval, provided that sufficient time is available for the complete transmission of the frame within the SP assignment or TXOP. The response serves as an implicit ACK.

[0329] When performing a BRP, if the BRP frame is a management frame of subtype Action, and if the responding STA requires more than SIFS to send the BRP frame in response to a beam refinement training request from the requesting STA, the STA shall send an ACK frame (9.3.1.4) or an EDMG BRP ACK frame (9.3.1.22) in response to the beam refinement training request.

[0330] To send a BRP response to the requesting STA, - The requesting STA can send a feedback poll to request a response. - The responding STA can contend for media and send a response back. If the reverse protocol is supported by both the requesting and responding STAs, the requesting STA may allocate time for feedback through a reverse grant.

[0331] The BRP response method can be selected during the BRP setup phase.

[0332] The STA can indicate how much more time is needed in the EDMG BRP ACK.

[0333] As a further example, a method performed by a BRP responder may include receiving a BRP measurement frame from an initiator, determining whether a response to the BRP measurement frame is available within a single frame time slot of receipt of the BRP measurement frame, and, in response to determining that a response is not available within a single frame time slot of receipt of the BRP measurement frame, transmitting an ACK at the end of the single frame time slot, followed by transmitting the response to the BRP measurement frame. The subsequent transmitting may be performed using channel contention. The subsequent transmitting may be performed by using a traffic available frame to request channel access. The subsequent transmitting may be performed in response to being polled by the initiator.

[0334] As another example, a method performed by a BRP responder may include receiving a BRP measurement frame from an initiator; determining whether a response to the BRP measurement frame is available within a single interval of time (SIFS) of receipt of the BRP measurement frame; in response to determining that the response is not available within a single interval of time (SIFS) of receipt of the BRP measurement frame, transmitting an ACK at the end of the single interval of time (SIFS), the ACK identifying a time interval; receiving a poll frame from the initiator after the identified time interval has elapsed; and transmitting the response to the BRP measurement frame in response to the poll.

[0335] As another example, a method performed by a BRP responder may include receiving a BRP measurement frame from an initiator; determining whether a response to the BRP measurement frame is available within a single frame of receipt of the BRP measurement frame; and, in response to determining that a response is not available within a single frame of receipt of the BRP measurement frame, initiating transmission to the initiator using dummy data, and thereafter continuing transmission to the initiator including the response to the BRP measurement frame.

[0336] As another example, the method may include negotiating a minimum duration (aBRPminSCblocks) between the PCP / AP and the STA, which may be selected from a predetermined set of values.

[0337] Notes on embodiments. Although the features and elements of the present disclosure are described in particular combinations in preferred embodiments, each feature or element can be used alone without other features and elements of the preferred embodiments, or in various combinations with or without other features and elements of the present disclosure.

[0338] Although the solutions described herein take into account protocols specific to 802.11, it is understood that the solutions described herein are not limited to this scenario and are applicable to other wireless systems as well.

[0339] Throughout the solutions and examples provided, any blank area in the diagram, e.g., white space, means that there is no limitation on this area and any solution can be adopted.

[0340] Although features and elements are described above in particular combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method performed by a first wireless transmit / receive unit (WTRU), comprising: receiving a signal from a second WTRU including an indication of a minimum data duration of a packet, the minimum data duration indicating a minimum amount of data that can be supported by the second WTRU; generating feedback associated with the packet; transmitting the feedback of the packet to the second WTRU using at least the minimum data duration; A method for providing the above.

2. The method of claim 1 , wherein the packet is a BRP packet, the method further comprising extending the BRP packet with additional zero padding to produce at least the minimum data duration.

3. the indication of the minimum data duration is included in a beamforming capability field; the minimum data duration is expressed as a number of single carrier (SC) blocks; The minimum data duration is indicated as a value of a BRP minimum single carrier (SC) blocks (BRPminSCblocks) parameter; the minimum data duration indicates a maximum value of minimum data amounts of a plurality of minimum data durations associated with the second WTRU and a third WTRU; or The feedback includes an explicit acknowledgement (ACK). The method of claim 1.

4. 4. The method of claim 3, wherein the beamforming capability field includes a 5-bit requested BRP single carrier (SC) block field.

5. transmitting a response to the signal indicating when feedback will be available; the time at which the feedback is available comprises a given number of bits indicating the time; or the feedback is transmitted to the second WTRU at the indicated time. The method of claim 1.

6. 6. The method of claim 5, further comprising receiving a polling frame from the second WTRU after the indicated time has elapsed during which the feedback will be available, the feedback being transmitted in response to the polling frame.

7. the signal is a BRP measurement frame including a plurality of BRP measurement frames from the second WTRU; transmitting the feedback includes transmitting a response to each of the plurality of BRP measurement frames. The method of claim 1.

8. a first wireless transmit / receive unit (WTRU) comprising a processor and a memory, The processor: receiving, via the processor, a signal from a second WTRU including an indication of a minimum data duration of a packet, the minimum data duration indicating a minimum amount of data that can be supported by the second WTRU; generating feedback associated with the packet; transmitting, via the processor, to the second WTRU, the feedback of the packet using at least the minimum data duration; a first WTRU configured to perform the following:

9. The first WTRU of claim 8 , wherein the packet is a BRP packet, and the processor is further configured to extend the BRP packet with additional zero padding to generate at least the minimum data duration.

10. the indication of the minimum data duration is included in a beamforming capability field; the minimum data duration is expressed as a number of single carrier (SC) blocks; the minimum data duration is indicated as the value of a BRPminSCblocks parameter; or The feedback includes an explicit acknowledgement (ACK). The first WTRU of claim 8 .

11. The first WTRU of claim 10 , wherein the beamforming capability field includes a 5-bit requested BRP SC block field.

12. the processor is further configured to transmit a response to the signal indicating a time when feedback will be available; the time at which the feedback is available comprises a given number of bits indicating the time; the minimum data duration indicates a maximum value of minimum data amounts of a plurality of minimum data durations associated with the second WTRU and a third WTRU; or the feedback is transmitted to the second STA at the indicated time. The first WTRU of claim 8 .

13. The processor: receiving, via the processor, a polling frame from the second STA after the time period during which the feedback is available has elapsed; and transmitting, via the processor, the feedback in response to the polling frame; The first WTRU of claim 12 , further configured to perform:

14. the signal is a BRP measurement frame including a plurality of BRP measurement frames from the second WTRU; and configuring the processor to transmit the feedback includes configuring the processor to transmit a response to each of the plurality of BRP measurement frames. The first WTRU of claim 8 .

15. 1. A method performed by a first wireless transmit / receive unit (WTRU), comprising: transmitting a signal to a second WTRU including an indication of a minimum data duration of a packet, the minimum data duration indicating a minimum amount of data that can be supported by the second WTRU; receiving feedback of the packet from the second WTRU using at least the minimum data duration; A method for providing the above.

16. 16. The method of claim 15, wherein the packet is a BRP packet, the method further comprising extending the BRP packet with additional zero padding to produce at least the minimum data duration.

17. the indication of the minimum data duration is included in a beamforming capability field; the minimum data duration is expressed as a number of single carrier (SC) blocks; The minimum data duration is indicated as a value of a BRP minimum single carrier (SC) blocks (BRPminSCblocks) parameter; the minimum data duration indicates a maximum value of minimum data amounts of a plurality of minimum data durations associated with the second WTRU and a third WTRU; or The feedback includes an explicit acknowledgement (ACK).

16. The method of claim 15.

18. 18. The method of claim 17, wherein the beamforming capability field includes a 5-bit requested BRP single carrier (SC) block field.

19. transmitting a response to the signal indicating when feedback will be available; the time at which the feedback is available comprises a given number of bits indicating the time; or the feedback is transmitted to the second WTRU at the indicated time.

16. The method of claim 15.

20. 20. The method of claim 19, further comprising transmitting a polling frame to the second WTRU after the indicated time period during which the feedback will be available, the feedback being received in response to the polling frame.

21. the signal is a BRP measurement frame including a plurality of BRP measurement frames from the second WTRU; receiving the feedback includes receiving a response from each of the plurality of BRP measurement frames; 16. The method of claim 15.

22. a first wireless transmit / receive unit (WTRU) comprising a processor and a memory, The processor: transmitting, via the processor, a signal to a second WTRU including an indication of a minimum data duration of a packet, the minimum data duration indicating a minimum amount of data that can be supported by the second WTRU; receiving, via the processor, feedback of the packet from the second WTRU using at least the minimum data duration; a first WTRU configured to perform the following:

23. 23. The first WTRU of claim 22, wherein the packet is a BRP packet, and the processor is further configured to extend the BRP packet with additional zero padding to generate at least the minimum data duration.

24. the indication of the minimum data duration is included in a beamforming capability field; the minimum data duration is expressed as a number of single carrier (SC) blocks; The minimum data duration is indicated as a value of a BRP minimum single carrier (SC) blocks (BRPminSCblocks) parameter; the minimum data duration indicates a maximum value of minimum data amounts of a plurality of minimum data durations associated with the second WTRU and a third WTRU; or The feedback includes an explicit acknowledgement (ACK). The first WTRU of claim 22.

25. The first WTRU of claim 24 , wherein the beamforming capability field includes a 5-bit requested BRP single carrier (SC) block field.

26. the processor is further configured to transmit a response to the signal indicating a time when feedback will be available; the time at which the feedback is available comprises a given number of bits indicating the time; or the feedback is transmitted to the second WTRU at the indicated time. The first WTRU of claim 22.

27. The processor:

27. The first WTRU of claim 26, further configured to transmit a polling frame to the second WTRU after the indicated time has elapsed during which the feedback will be available, the feedback being received in response to the polling frame.

28. the signal is a BRP measurement frame including a plurality of BRP measurement frames from the second WTRU; receiving the feedback includes receiving a response from each of the plurality of BRP measurement frames; The first WTRU of claim 22.

Images