Broadcasting and AIML Discovery Methods in WLANs

Abstract

Methods and apparatus are described for broadcasting and artificial intelligence and machine learning (AIML) discovery in wireless local area networks (WLANs). The method for use in a station (STA) is described and may include receiving an EBCS termination notification from an EBCS AP for one or more Enhanced Broadcast Service (ECBS) traffic streams transmitted by an access point (AP), determining that the termination notification indicates an EBCS traffic stream of a shorter duration than desired by the STA, and, when the STA associates with the AP and the termination notification indicates that negotiation method Type 1 or Type 2 is allowed, transmitting an EBCS content request frame by the STA to the EBCS AP requesting an extension of the EBCS traffic stream. In a further embodiment, the EBCS content request frame includes a desired value in a requested time to termination subfield of the EBCS content request.

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to the following U.S. provisional applications, serial number 63 / 424,578, filed November 11, 2022, entitled "Methods for Broadcasting and AIML Discovery in WLAN," and serial number 63 / 431,540, filed December 9, 2022, entitled "Methods for Broadcasting and AIML Discovery in WLAN," which are incorporated by reference in their entireties.

[0002] Enhanced broadcast service (EBCS) may refer to a medium access control (MAC) amendment for IEEE 802.11 devices. EBCS service may be a downlink from an access point (AP) to non-AP stations (STAs) or an uplink from non-AP STAs. An AP may be expected to support up to 3,000 non-AP STAs with EBCS service. In downlink broadcasting, an EBCS AP provides broadcasting services to STAs that are either associated or not associated with the AP. EBCS STAs need to discover which EBCS APs provide EBCS services. Furthermore, the EBCS AP and STAs need to negotiate regarding providing and receiving EBCS traffic streams. Therefore, a method and apparatus for efficiently discovering and negotiating the above services is needed. Summary of the Invention

[0003] A method is described for use in a station (STA), the method including receiving an EBCS termination notification from an EBCS AP for one or more Enhanced Broadcast Service (ECBS) traffic streams transmitted by the access point (AP), determining that the termination notification indicates an EBCS traffic stream of a shorter duration than desired by the STA, and, when the STA associates with the AP and the termination notification indicates that negotiation method Type 1 or Type 2 is allowed, transmitting an EBCS content request frame by the STA to the EBCS AP requesting an extension of the EBCS traffic stream. In a further embodiment, the EBCS content request frame includes a desired value in a requested time to termination subfield of the EBCS content request. In a further embodiment, the EBCS content request frame includes a content ID subfield corresponding to the EBCS traffic stream. In a further embodiment, a Type 1 negotiation method includes a request via an EBCS content request frame. In further embodiments, the Type 2 negotiation method includes requesting through an EBCS content request frame or through an EBCS content request ANQP element.

[0004] A further method is described for use in a STA, the method including receiving an EBCS termination notification from an EBCS AP for one or more ECBS traffic streams transmitted by the AP, determining that the termination notification indicates an EBCS traffic stream of a shorter duration than desired by the STA, and, if the STA is not associated with the AP and the termination notification indicates that negotiation method Type 2 is allowed, transmitting an EBCS content request frame including an access network query protocol (ANQP) element by the STA to the EBCS AP requesting an extension of the EBCS traffic stream. In a further embodiment, the ANQP element includes a desired value in a termination request time subfield of the EBCS content request. In a further embodiment, the EBCS content request frame includes a content ID subfield corresponding to the EBCS traffic stream. In a further embodiment, the type 2 negotiation method includes a request through the EBCS content request ANQP element.

[0005] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which: [Brief explanation of the drawings]

[0006] [Figure 1A] 1 is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an example WTRU (Wireless Transmit / Receive Unit) that may be used within the communication system illustrated in FIG. 1A according to an embodiment. [Figure 1C] 1B is a system diagram illustrating an example RAN (Radio Access Network) and an example CN (Core Network) that may be used within the communication system illustrated in FIG. 1A according to an embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A according to an embodiment. [Figure 2] FIG. 1 illustrates an example Enhanced Broadcast Service (EBCS) discovery procedure. [Figure 3] FIG. 1 illustrates an example EBCS negotiation procedure. [Figure 4] FIG. 10 illustrates a further exemplary EBCS negotiation procedure. DETAILED DESCRIPTION OF THE INVENTION

[0007] 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), etc.

[0008] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, 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 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, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals, and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated processing chain), a consumer electronics device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0009] Further, the communications system 100 may include a base station 114a and / or 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 CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNodeB (eNB), a Home NodeB, a Home eNodeB, a next generation NodeB, e.g., a gNodeB (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted 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.

[0010] The base station 114a may be part of the RAN 104, which may further include other base stations and / or network elements (not shown), such as, for example, a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies and may be referred to as a cell (not shown). The frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services over a particular geographic area, which may be relatively fixed or may change over time. Furthermore, a cell may be divided into cell 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 for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0012] More specifically, as mentioned above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as, for example, CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using, for example, 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 (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

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

[0014] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may establish the air interface 116 using NR and may implement a radio technology such as NR radio access.

[0015] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement both LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0016] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as, for example, IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), 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), GERAN (GSM EDGE), etc.

[0017] 1A may be, for 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 localized area, such as, for example, a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as, for example, IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as, for example, 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, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As shown in FIG. 1A, 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 through the CN 106.

[0018] The RAN 104 may be in communication with the CN 106 and 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. The data may have various quality of service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 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, for example, user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 and / or CN 106 may be in direct or indirect communication with other RANs employing the same RAT as the RAN 104 or a different RAT. For example, the CN 106, in addition to being connected to the RAN 104, which may utilize NR radio technology, may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0019] Additionally, the CN 106 may serve as a gateway 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 / or 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 network 112 may include another CN connected to one or more RANs that may employ the same RAT as the RAN 104 or a different RAT.

[0020] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., 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. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114b, which may employ an IEEE 802.11 radio technology.

[0021] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, 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 GPS (Global Positioning System) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the above elements while remaining consistent with an embodiment.

[0022] 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 in conjunction with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), 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 function that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit / receive element 122. While FIG. 1B 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.

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

[0024] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO techniques. 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 116.

[0025] 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, for example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate according to multiple RATs, such as NR and IEEE 802.11.

[0026] The processor 118 of the WTRU 102 may be coupled to and may receive user input data through a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit). Additionally, the processor 118 may output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information and store data in any suitable type of memory, such as 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 and store data in memory that is not physically located in the WTRU 102, such as in a server or host computer (not shown).

[0027] 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 device suitable for providing power to the WTRU 102. For example, the power source 134 may include one or more dry batteries (e.g., NiCd (nickel cadmium), NiZn (nickel zinc), NiMH (nickel metal hydride), Li-ion (lithium ion), etc.), solar cells, fuel cells, etc.

[0028] Additionally, the processor 118 may 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. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals being received from two or more neighboring base stations. It will be understood that the WTRU 102 may obtain location information through any suitable location-determination method while remaining consistent with an embodiment.

[0029] Additionally, the processor 118 may 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 and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripherals 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.

[0030] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the UL (e.g., for transmission) and DL (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference, either by hardware (e.g., a choke) or signal processing by a processor (e.g., by a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be half-duplex.

[0031] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As mentioned above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. Additionally, the RAN 104 may be in communication with the CN 106.

[0032] 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, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0033] 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 in the UL and / or DL, etc. As shown in FIG. 1C , the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0034] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the above-mentioned elements are depicted as part of the CN 106, it will be understood that any of the just-mentioned elements may be owned and / or operated by an entity other than the CN operator.

[0035] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c 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, activating / deactivating bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0036] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. In general, the SGW 164 may route and forward user data packets to the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as, for example, anchoring the user plane during inter-eNode B handovers, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0037] The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0038] The CN 106 may facilitate communication with other networks. For example, the CN 106 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 CN 106 may include or communicate with an IP gateway (e.g., an IMS (IP Multimedia Subsystem) server) that serves as an interface between the CN 106 and the PSTN 108. Furthermore, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0039] Although the WTRU is described in Figures 1A-1D as a wireless terminal, it is expected that in certain exemplary embodiments, such a terminal may use a wired communication interface (e.g., temporarily or permanently) with the communication network.

[0040] In an exemplary embodiment, the other network 112 may be a WLAN.

[0041] A WLAN in infrastructure Basic Service Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and out of the BSS. Traffic to a STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within a BSS may be routed through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be routed between (e.g., directly between) a source and destination STA via a direct link setup (DLS). In one exemplary embodiment, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication is sometimes referred to herein as an "ad-hoc" mode of communication.

[0042] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically configured width. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In a typical embodiment, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented in an 802.11 system, for example. With CSMA / CA, STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit in a given BSS at any given time.

[0043] For example, a HT (high throughput) STA may use a 40 MHz wide channel for communication by combining a 20 MHz primary channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0044] A Very High Throughput (VHT) STA may support channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz width. A 40 MHz and / or 80 MHz channel may be constructed by combining contiguous 20 MHz channels. A 160 MHz channel may be constructed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, sometimes referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may proceed to a segment parser, which may split the data into two streams. IFFT (inverse fast Fourier transform) processing and time-domain processing may be performed on each stream separately. The streams may be mapped onto two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations for the 80+80 configuration described above may be reversed and the combined data may be sent to the MAC (Media Access Control).

[0045] Sub-1 GHz modes of operation are supported by 802.11af and 802.11ah. The operating bandwidths of the channels and carriers are reduced in 802.11af and 802.11ah 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. According to an exemplary embodiment, 802.11ah may support Meter Type Control / Machine-Type Communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including support (e.g., only support) for limited and / or limited bandwidths. An MTC device may include a battery with a battery life above a threshold (eg, to maintain a very long battery life).

[0046] A WLAN system that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In an 802.11ah example, the primary channel may be 1 MHz wide for a STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or NAV (Network Allocation Vector) setting may depend on the state of the primary channel. If the primary channel is busy, for example, due to a STA (that only supports a 1 MHz mode of operation) transmitting to the AP, then all available frequency bands may be considered busy even if most of the available frequency bands remain idle.

[0047] In the United States, the available frequency bands that may be used by 802.11ah are 902 MHz to 928 MHz. In South Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0048] 1D is a system diagram illustrating the RAN 104 and the CN 106, according to an embodiment. As mentioned above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. Additionally, the RAN 104 may be in communication with the CN 106.

[0049] The RAN 104 may include gNBs 180a, 180b, and 180c, although it will be understood that the RAN 104 may include any number of gNBs without departing from the spirit or scope of the present invention. The gNBs 180a, 180b, and 180c 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 gNBs 180a, 180b, and 180c may implement MIMO techniques. For example, the gNBs 180a, 180b may utilize beamforming to transmit and / or receive signals to the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit and / or receive wireless signals to the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of the just-mentioned component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0050] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for separate transmissions, separate cells, and / or separate portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or various absolute time lengths).

[0051] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as, for example, an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput in serving the WTRUs 102a, 102b, 102c.

[0052] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0053] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one SMF (Session Management Function) 183a, 183b, and possibly a DN (Data Network) 185a, 185b. While the above-mentioned elements are depicted as part of the CN 106, it will be understood that any of the just-mentioned elements may be owned and / or operated by an entity other than the CN operator.

[0054] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling sessions of separate protocol data units (PDUs) with separate requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support for the WTRUs 102a, 102b, 102c based on the type of service being used for the WTRUs 102a, 102b, 102c. For example, separate network slices may be established for separate use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services related to MTC access, and the like. The AMFs 182a, 182b may provide control plane functionality for switching between the RAN 104 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0055] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. Furthermore, the SMFs 183a, 183b may be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, and the like. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0056] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface and may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network such as, for example, the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as, for example, routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, etc.

[0057] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IMS (IP Multimedia Subsystem) server) that acts as an interface between the CN 106 and the PSTN 108. Furthermore, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local DNs 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0058] 1A-1D and the corresponding descriptions thereof, one or more or all of the functions described herein in connection with one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functionality.

[0059] The emulation device may be designed to implement one or more tests of other devices in a lab environment and / or in an operator's network environment. For example, one or more emulation devices may perform one or more, or all, functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communications network to test other devices in the communications network. One or more emulation devices may perform one or more, or all, functions while temporarily implemented / deployed as part of a wired and / or wireless communications network. The emulation device may be directly coupled to another device for testing purposes and / or may perform testing using over-the-air (OTA) wireless communications.

[0060] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communications network. For example, the emulation devices may be utilized in testing scenarios in a testing laboratory and / or in an undeployed (e.g., testing) wired and / or wireless communications network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0061] A WLAN in infrastructure Basic Service Set (BSS) mode has an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. Typically, the AP has access or an interface to a distribution system (DS) or another type of wired or wireless network that carries traffic into and out of the BSS. Traffic originating from outside the BSS to a STA arrives through the AP and is delivered to the STA. Traffic originating from a STA to a destination outside the BSS is sent to the AP for delivery to the respective destination. Furthermore, traffic between STAs within a BSS may be routed through the AP, where a source STA may send traffic to the AP, which then delivers the traffic to the destination STA. Such traffic between STAs within a BSS is peer-to-peer in nature. Furthermore, such peer-to-peer traffic may be routed directly between the source and destination STAs via a direct link setup (DLS), using 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode does not have an AP and / or STAs communicate directly with each other. This mode of communication is referred to as an "ad-hoc" mode of communication.

[0062] Using the 802.11ac infrastructure mode of operation, an AP may transmit beacons on a fixed channel, typically using a primary channel. This channel is 20 MHz wide and is the operating channel of the BSS. Furthermore, this channel is used by STAs that establish a connection with the AP. The basic channel access mechanism in 802.11 systems is CSMA / CA (Carrier Sense Multiple Access with Collision Avoidance). In this mode of operation, all STAs, including the AP, will sense the primary channel. If the channel is detected to be busy, the STA backs off. Therefore, only one STA may transmit in a given BSS at any given time.

[0063] In 802.11n, High Throughput (HT) STAs may also use 40 MHz wide channels for communication. This is accomplished by combining a primary 20 MHz channel with adjacent 20 MHz channels to form a 40 MHz wide contiguous channel.

[0064] In 802.11ac, a Very High Throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and 160 MHz. 40 MHz and 80 MHz channels may be formed by combining contiguous 20 MHz channels, similar to the 802.11n described above. A 160 MHz channel may 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, after channel encoding, the data passes through a segment parser that splits the data into two streams. IFFT and time-domain processing are performed separately on each stream. The streams are then mapped to two channels, and the data is transmitted. At the receiver, the mechanism described above is reversed, and the combined data is sent to the MAC.

[0065] Sub-1 GHz modes of operation are supported by 802.11af and 802.11ah. With these specifications, the operating bandwidths of the channels 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 TVWS (TV White Space) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. A potential 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 also have very long battery life requirements.

[0066] WLAN systems that support multiple channels and channel widths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel designated as the primary channel. The primary channel may, but need not, have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. Therefore, the bandwidth of the primary channel is limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, the primary channel may be 1 MHz wide if there are STAs (e.g., MTC-type devices) that support only the 1 MHz mode, even if the AP and other STAs in the BSS may support operating modes of 2 MHz, 4 MHz, 8 MHz, 16 MHz, or other channel bandwidths. All carrier sensing and NAV setting depends on the state of the primary channel; for example, if the primary channel is busy because a STA that only supports 1 MHz mode of operation is transmitting to the AP, the entire available frequency band is considered busy, even though most of the available frequency band remains idle and available.

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

[0068] IEEE 802.11bc may include a MAC amendment for Enhanced Broadcast Service (EBCS) for 802.11 devices. The IEEE 802.11bc amendment will not affect the current IEEE 802.11 PHY specification.

[0069] The EBCS service can be a downlink from the AP to non-AP STAs, or an uplink from non-AP STAs, such as sensors or IoT devices. The intention is that enhanced broadcast services be provided to both STAs associated with a particular AP and STAs that are not associated. An AP may support up to 3000 non-AP STAs with EBCS services. Furthermore, there may be a class of low-cost non-AP STAs that consume the EBCS service that may not be able to transmit directly to the AP.

[0070] Some use cases for EBCS may include, but are not limited to, stadium video broadcasting, automotive broadcasting, uplink sensor data broadcasting, museum information and multilingual broadcasting, event producer information and content broadcasting, machine learning and federated learning deployments, and machine learning.

[0071] Machine learning may be defined as a computer program that, given a class of tasks T and a performance measure P, is said to learn from experience E if experience E improves its performance at the tasks in T, as measured by P. There are many different types of machine learning that depend on the nature of the tasks T that the system learns, the nature of the performance measure P used to evaluate the system, and the nature of the training signals or experience E that are given to the system.

[0072] Machine learning implementations can be classified into three main categories depending on the nature of the learning "signals" or "responses" available to the learning system:

[0073] Supervised Learning: When an algorithm learns from example data and associated target responses, which can consist of numeric or string labels such as classes or tags, to later predict the correct response when posed by a new example, it falls into the category of supervised learning. The approach just described is quite similar to human learning under the supervision of a teacher: the teacher provides good examples for the student to memorize, and the student then derives general rules from the concrete examples.

[0074] Unsupervised learning: This leaves the algorithm to determine data patterns on its own, as opposed to learning from plain examples with no associated responses. These types of algorithms tend to restructure data into something else, such as new features that may represent classes, or new series of uncorrelated values. This can be very useful in giving people insight into the meaning of the data and providing new useful inputs to supervised machine learning algorithms.

[0075] In reinforcement learning, a system or agent must learn how to interact with its environment. This can be encoded by a policy a = π(x), which specifies which action to take in response to each possible input x (derived from the environmental state). The difference with supervised learning is that the system is not told which action is the best one to take (i.e., which output to produce for a given input). Instead, the system only receives occasional reward (or punishment) signals depending on the action it takes. This is like learning with a critic who occasionally gives you a thumbs up or a thumbs down, as opposed to learning with a teacher who tells you what to do at each step.

[0076] Federated learning is a machine learning approach where the goal is to train a high-quality centralized model while training data remains distributed across many clients, each with unreliable and relatively slow network connections. A learning algorithm considered for this setting is that, in each round, each client independently computes updates to the current model based on its location data, communicates the updates to a central server, and the client-side updates are aggregated to compute a new global update. The typical client in this setting is a mobile phone, and communication efficiency is paramount. Federated learning allows mobile phones to collaboratively train a shared predictive model while keeping all training data on-device, decoupling the ability to perform machine learning from the need to store data in the cloud. Training data may be stored locally on a user's mobile device, and the device acts as a node performing local data computations to update the global model.

[0077] A naive implementation of federated learning may require each client to send a full model (or full model update) back to the server in each round. For large models, this step is likely to become a bottleneck in federated learning due to several factors. One factor is the asymmetric nature of Internet connection speeds, with the uplink typically being much slower than the downlink. Therefore, there are many ways to reduce the uplink communication (client-to-server) cost in federated learning. For example, structured updates can be parameterized with fewer variables if updates from a limited pace can be learned. Another example is sketch updates, where the full model is updated. This can then be compressed before sending to the server.

[0078] In a downlink broadcasting use case, an EBCS AP may provide broadcasting services to STAs that are either associated with the AP or not associated with the AP. The EBCS STAs may need to discover which EBCS APs provide the EBCS services. Furthermore, the EBCS AP and the STAs may need to negotiate regarding providing and receiving EBCS traffic streams. Therefore, a method and apparatus are needed to efficiently discover and negotiate for the above services.

[0079] Due to the popularity of Artificial Intelligence and Machine Learning (AIML) in many technical fields, it is expected that AIML technology will be applied and handled in WLAN networks. Therefore, a method and apparatus are needed for how to enable STAs to efficiently support and use AIML services after association or AIML service configuration and information exchange.

[0080] Embodiments for efficient EBCS discovery and negotiation are described herein. In an embodiment for EBCS discovery, an AP not included in a multiple BSSID set and having EBCSSupportActivated equal to true and a non-zero EBCSTrafficStreamTable length may include an EBCS parameter element in a fast initial link setup (FILS) discovery frame that it transmits. In a multiple BSSID set, an AP corresponding to a transmitted BSSID that also has EBCSSupportActivated equal to true and a non-zero EBCSTrafficStreamTable length may include an EBCS parameter element in a FILS discovery frame that it transmits.

[0081] An EBCS STA or receiver discovers an EBCS capable AP by receiving, but not limited to, any of the following frames: a beacon frame, an S1G beacon frame, a probe response frame, or a PV1 probe response frame with the EBCS supported field in the extended capabilities element equal to 1, an EBCS information frame, an ANQP response frame containing an EBCS ANQP element, and a FILS discovery frame containing an EBCS parameters element.

[0082] An EBCS STA or receiver can know when the next EBCS information frame will be transmitted by inspecting the EBCS information frame TX countdown field in a received beacon frame, S1G beacon frame, Protocol Version 1 (PV1) probe response frame, and the EBCS parameters element in a probe response frame, a FILS discovery frame, an Enhanced Broadcast Service ANQP element in an ANQP response frame, or the like. An EBCS receiver may select which EBCS traffic streams to receive and consume.

[0083] The EBCS STA or receiver may then receive an EBCS information frame using the information discovered in the EBCS information frame TX countdown field received in a beacon frame, an S1G beacon frame, a probe response frame, or a FILS discovery frame. After receiving one or more EBCS information frames, the EBCS STA or receiver may decide to request one or more EBCS traffic streams. The EBCS STA may then send an EBCS content request to the EBCS AP to request one or more EBCS traffic streams. Alternatively or additionally, the EBCS STA may send an EBCS content request ANQP element to request one or more EBCS traffic streams, depending on whether the EBCS traffic streams require association.

[0084] 2 is a diagram illustrating an example Enhanced Broadcast Service (EBCS) discovery procedure. At 210, an EBCS-capable AP transmits a FILS discovery frame including an EBCS parameter element. At 212, an EBCS-capable STA receives the FILS discovery frame including the EBCS parameter element and discovers the EBCS-capable AP. At 214, the EBCS-capable STA receives an EBCS information frame using information included in the EBCS parameter element in the FILS discovery frame.

[0085] An embodiment of an efficient EBCS negotiation procedure is described herein. An unassociated EBCS STA may send an EBCS ANQP element to an EBCS AP to register for one or more EBCS traffic streams if the EBCS AP indicates that association is not required. When registering an EBCS traffic stream using the EBCS Request ANQP element, the EBCS STA may request a specific time until termination using the Requested Time to Termination subfield and may indicate the MAC address of the AP currently receiving service using the Broadcaster MAC Address subfield. The Broadcaster MAC Address subfield may allow a non-AP STA to provide the MAC address of the AP currently serving the EBCS traffic stream, which may not be the same as the one receiving the request. This information may be used to distribute the EBCS load transmitted by different EBCS APs in an area.

[0086] After receiving an EBCS Request ANQP element from an unassociated EBCS STA, the EBCS AP may respond with an EBCS Response ANQP element and an EBCS ANQP element indicating acceptance or rejection of the request to initiate transmission of each EBCS traffic stream indicated in the EBCS Content Request ANQP element.

[0087] In one example, an EBCS AP may indicate that an EBCS STA or receiver may need to establish security with the EBCS AP before the EBCS STA or receiver may send a frame containing an EBCS Request ANQP element. Security between the EBCS AP and the EBCS STA or receiver may be established by using a pre-association security negotiation (PASN) or other type of security protocol. In one example, the EBCS AP may send a frame containing an EBCS Response ANQP element to the EBCS STA or receiver in response to a received EBCS Request ANQP element, indicating that the EBCS STA or receiver may first establish a PASN or other type of security with the EBCS AP before sending another EBCS Request ANQP element. In another example, the EBCS AP may indicate in every beacon, S1G beacon, probe response frame, or FILS discovery frame that a PASN or other type of security is required before any negotiation or request for an EBCS traffic stream. An EBCS STA or receiver receiving the indication may first establish security with the EBCS AP using the PASN or other type of security that may be indicated in the received frame before sending any frames containing an EBCS content request ANQP element to the EBCS AP to request one or more EBCS traffic streams.

[0088] If the EBCS AP accepts the request for an EBCS traffic stream, it may include a Termination Time subfield in the EBCS ANQP element that indicates the time until termination for the EBCS traffic stream.

[0089] The EBCS AP may have the authority to determine the time until termination of an EBCS traffic stream. ANQP elements received from unassociated STAs are not protected, and therefore, the EBCS AP may be cautious when accepting a requested duration. The EBCS AP may evaluate certain criteria before responding to an EBCS service request from an unassociated STA that received an EBCS Request ANQP element. Such criteria may include, but are not limited to, the time duration and / or frequency of EBCS traffic stream requests. Evaluation of the criteria could be based on local policies installed in the EBCS AP, which are outside the scope of this disclosure.

[0090] In another example, an EBCS STA or receiver that registered with an EBCS traffic stream using an EBCS Content Request ANQP element may unregister from the traffic stream when it no longer consumes the EBCS traffic stream. To accomplish this, the EBCS STA or receiver may send a frame containing an EBCS Content Request ANQP element to the EBCS AP transmitting the EBCS traffic stream. The Broadcast Action bit of the EBCS Content Request Information Control subfield in the EBCS Content Request Information subfield containing the Content ID of the EBCS traffic stream from which the EBCS STA or receiver is attempting to unregister may be set to 0.

[0091] In another example, an EBCS STA or receiver consuming an EBCS traffic stream may unregister from the traffic stream when it no longer consumes the EBCS traffic stream. To accomplish this, the EBCS STA or receiver may send a frame containing an EBCS Content Request ANQP element to the EBCS AP transmitting the EBCS traffic stream. The Broadcast Action bit of the EBCS Content Request Information Control subfield in the EBCS Content Request Information subfield containing the Content ID of the EBCS traffic stream from which the EBCS STA or receiver attempts to unregister may be set to 0.

[0092] An EBCS STA or receiver may combine registering for one or more EBCS traffic streams and deregistering for one or more EBCS traffic streams by sending a frame containing one EBCS Content Request ANQP element, with one or more EBCS Content Request Information subfields containing a Broadcast Action set to 1 and one or more EBCS Content Request Information subfields containing a Broadcast Action set to 0.

[0093] After receiving an EBCS Request ANQP element from an unassociated EBCS STA or receiver, for example, an EBCS STA or receiver registered for one or more EBCS traffic streams with a Broadcast Action set to 0 in the EBCS Content Request Information subfield for that traffic stream or streams, the EBCS AP may respond with an EBCS Response ANQP element with an EBCS Content Request Status set to 1 in the EBCS Content Response Information subfield containing the Content ID for the traffic stream for which the EBCS STA is requesting deregistration. The EBCS AP may continue to broadcast the EBCS traffic stream after the unassociated EBCS STA or receiver has deregistered for the EBCS traffic stream.

[0094] In another example, an EBCS AP may transmit an ACK frame after receiving an EBCS Request ANQP element from an unrelated EBCS STA or receiver, for example, an EBCS STA or receiver registered for one or more EBCS traffic streams that has the Broadcast Action set to 0 in the EBCS Content Request Information subfield for the one or more EBCS traffic streams. The EBCS AP may continue to broadcast the EBCS traffic streams after transmitting the ACK frame.

[0095] In another example, after receiving an EBCS Request ANQP element from an unassociated EBCS STA or receiver, e.g., an EBCS STA or receiver registered for one or more EBCS traffic streams with the broadcast action set to 0 in the EBCS Content Request Information subfield for one or more EBCS traffic streams, the EBCS AP may not respond with respect to the EBCS traffic stream for which the EBCS STA or receiver requests deregistration. The EBCS AP may continue to broadcast the EBCS traffic stream even after the unassociated EBCS STA or receiver deregisters with respect to the EBCS traffic stream.

[0096] An EBCS AP may terminate transmission of an EBCS traffic stream after receiving an EBCS Request ANQP element from an unassociated EBCS STA or receiver, e.g., an EBCS STA or receiver registered for one or more EBCS traffic streams that has the Broadcast Action set to 0 in the EBCS Content Request Information subfield for one or more EBCS traffic streams.

[0097] An efficient time-to-termination negotiation procedure is described herein.

[0098] An EBCS STA receiving an EBCS Termination Notice frame may negotiate the extension of an EBCS traffic stream indicated in one of the EBCS Termination Information subfields if the EBCS traffic stream terminates earlier than desired. If an EBCS STA negotiates the extension of an EBCS traffic stream, it may use the negotiation method indicated in the Negotiation Method subfield in the EBCS Termination Information subfield.

[0099] A negotiation method 1 subfield value means that STAs associated with the broadcaster AP can make EBCS traffic stream requests through EBCS content request frames. A negotiation method 2 subfield value means that EBCS traffic stream requests made by STAs not associated with the broadcaster AP can be made using an EBCS content request ANQP element. Furthermore, negotiation method 2 means that STAs associated with the broadcaster AP can make EBCS traffic stream requests either by using an EBCS content request ANQP element or an EBCS content request frame.

[0100] In an embodiment, an EBCS non-AP STA may transmit an EBCS content request frame to an EBCS AP to request one or more EBCS traffic streams provided by the EBCS AP with which it is associated. An unassociated EBCS non-AP STA may associate with an EBCS AP and subsequently transmit an EBCS content request frame to request one or more EBCS traffic streams for which the EBCS AP has indicated that association is required. Furthermore, requests for one or more EBCS traffic streams that do not require association may be included in the same EBCS content request frame. When requesting an EBCS traffic stream using an EBCS content request frame, the EBCS non-AP STA may request the EBCS traffic stream with a specific time until termination, as indicated in a requested time-to-termination field included in the EBCS content request frame. Furthermore, the STA may indicate the MAC address of the AP currently receiving service using the broadcaster MAC address subfield. The non-AP STA may include the MAC address of the AP currently serving the EBCS traffic stream, which may be different from the AP receiving the request, in the broadcaster MAC address subfield in the EBCS content request frame. The information just described may be used to distribute the EBCS load transmitted by different EBCS APs in an area.

[0101] After receiving an EBCS Content Request frame from an associated EBCS non-AP STA, the EBCS AP may respond with an EBCS Content Response frame. The status of the request for the EBCS traffic stream identified by the Content ID is indicated by an EBCS Content Request Status subfield in the EBCS Content Response Information subfield containing the same Content ID. If the EBCS AP indicates in the EBCS Content Response frame that the request for the EBCS traffic stream was successful, it may include a Time to Termination field indicating the time until termination for the EBCS traffic stream. Additionally, the EBCS Content Response frame may include the EBCS SP Duration and EBCS SP Interval for the EBCS traffic stream.

[0102] An EBCS non-AP STA receiving an EBCS Content Response frame may negotiate an extension of the EBCS traffic stream if the EBCS traffic stream indicated in one of the EBCS Response Information subfields terminates earlier than desired. The EBCS STA may negotiate an extension of the EBCS traffic stream by sending another EBCS Content Request frame to the associated AP by including the desired value in the Requested Time to Termination subfield in the EBCS Request Information subfield whose Content ID subfield corresponds to the EBCS traffic stream.

[0103] An EBCS non-AP STA receiving an EBCS Termination Notification frame may negotiate an extension of the EBCS traffic stream using an EBCS Content Request frame if the EBCS traffic stream indicated in one of the EBCS Termination Information subfields terminates earlier than desired and the negotiation method indicated in the same EBCS Termination Information subfield is set to 1 or 2. The EBCS STA may negotiate an extension of the EBCS traffic stream by sending an EBCS Content Request frame to the associated AP by including the desired value in the Requested Time to Termination subfield in the EBCS Request Information subfield whose Content ID subfield corresponds to the EBCS traffic stream.

[0104] In an embodiment, an unassociated EBCS STA may send an EBCS ANQP element to an EBCS AP to register for one or more EBCS traffic streams when the EBCS AP indicates that association is not required. When registering an EBCS traffic stream using the EBCS Request ANQP element, the EBCS STA may request a specific time until termination using the Requested Time to Termination subfield and may indicate the MAC address of the AP currently receiving service using the Broadcaster MAC Address subfield. The Broadcaster MAC Address subfield allows a non-AP STA to provide the MAC address of the AP currently serving the EBCS traffic stream, which may not be the same as the one receiving the request. This information may be used to distribute the EBCS load transmitted by different EBCS APs in an area.

[0105] After receiving an EBCS Request ANQP element from an unassociated EBCS STA, the EBCS AP may respond with an EBCS Response ANQP element and an EBCS ANQP element indicating acceptance or rejection of the request to begin transmitting each EBCS traffic stream indicated in the EBCS Request ANQP element. If the EBCS AP accepts the request for an EBCS traffic stream, it may include a Termination Time subfield in the EBCS ANQP element indicating the time until termination for the EBCS traffic stream.

[0106] An unaffiliated EBCS STA receiving an EBCS Termination Notification frame may negotiate an extension of the EBCS traffic stream using an EBCS Content Request ANQP element if the EBCS traffic stream indicated in one of the EBCS Termination Information subfields terminates earlier than desired and the negotiation method indicated in the same EBCS Termination Information subfield is set to 2. The EBCS STA may negotiate an extension of the EBCS traffic stream by sending an EBCS Content Request ANQP element to the EBCS AP from which the EBCS Termination Notification frame was received, by including the desired value in the Requested Time to Termination subfield of the EBCS Request Information subfield whose Content ID subfield corresponds to the EBCS traffic stream.

[0107] 3, at 310, an EBCS-enabled AP may send a termination notification for one or more traffic streams that the AP is broadcasting, where the termination notification indicates negotiation method 2. At 312, an EBCS-STA not associated with the AP may send a frame including an EBCS content request ANQP element to negotiate extension of the EBCS traffic stream. At 314, the EBCS-AP may respond by sending a frame including an EBCS content response ANQP element that allows extension of the EBCS traffic stream.

[0108] 4, at 410, an EBCS-enabled AP may send a termination notification for one or more traffic streams that the AP is broadcasting, the termination notification indicating negotiation method 1 or 2. At 412, an EBCS-STA associated with the AP may send a frame including an EBCS content request frame requesting extension of the EBCS traffic stream. At 414, the EBCS-AP may respond by sending a frame including an EBCS content response that grants extension of the EBCS traffic stream.

[0109] The EBCS AP may follow an EBCS termination notification procedure (eg, an EBCS termination notification procedure) before terminating transmission of an EBCS traffic stream.

[0110] For example, embodiments for efficient AIML capability discovery through ANQP are described herein. STAs may use ANQP to retrieve information about aspects of the network and available services. However, currently, there are no ANQP elements designated to support AIML capability discovery. Hence, a set of ANQP elements is needed that supports STAs' ability to discover AIML capabilities available from an AP or from networks reachable through an AP. ANQP elements may include query, response, and information elements. The just-mentioned elements may be pre-association elements sent via the Generic Advertisement Service (GAS) protocol, may be included in an AP beacon, or may be post-association elements sent to enable discovery of AIML capabilities or availability.

[0111] An embodiment is described herein for an AIML query / response via GAS. A requesting STA may send an AIML ANQP query to another STA (e.g., a queried STA, typically an AP connected to the network) via a GAS query request. The AIML query may be defined in an AIML element or a set of AIML elements. The AIML element may be sent alone in the GAS query request or may be one of several ANQP elements sent in the GAS query. The AIML element may include fields that describe aspects of the AIML service desired by the requesting STA that may be provided by or through the queried STA. The AIML element may include, but is not limited to, an info ID field indicating that it is an AIML query, a length field, an AIML service type field, an AIML learning type field, an AIML data field, an AIML coefficient field, and additional AIML description and service description fields. The info ID field may include a value (e.g., 287) that identifies the ANQP element as an AIML element. The length field may include a value providing the field length. The AIML Service Type field may contain a value that may indicate the type of AIML / MIML service (e.g., AIML-based Location Service (001), AIML Wireless Media (WM) Management (002), AIML Beamforming (003), etc.). The AIML Learning Type field may contain a value that may indicate the type of learning used by the AIML (e.g., Supervised (001), Unsupervised (002), Enhanced (003), Collaborative (004), etc.). The AIML Data field may indicate an indication that the STA has data to provide, the type of data it has, or the type of data it is requesting to support the AIML service. The AIML Coefficients field may contain a request for AIML coefficients from the AIML service or may provide the coefficients the STA is currently using.Additional fields may be defined as needed to request / provide AIML information. Furthermore, AIML queries may use vendor-specific ANQP elements or may be made by other ANQP elements with AIML fields.

[0112] An AIML ANQP GAS query to an ANQP server via the queried STA may generate an AIML ANQP GAS response. The AIML ANQP GAS response may contain the requested information in an AIML element or a set of AIML elements. The AIML elements may contain the same fields as the AIML elements used in the AIML ANQP GAS request, a subset of the fields, or additional fields.

[0113] Embodiments of AIML information via ANQP advertisement are described herein. An AP may provide AIML information via the ANQP advertisement protocol. To do so, the AP may provide an AIML element or multiple AIML elements in an ANQP advertisement protocol element in a beacon or probe response frame transmitted by the AP. A STA seeking AIML service may receive the transmitted beacon or probe response frame and obtain information advertised about AIML services provided by or available through the AP. Furthermore, a STA seeking AIML service may send a probe transmission to the AP requesting the AIML service, and the probe request may include an AIML element (as described above) or other content describing the requested AIML information.

[0114] Embodiments of AIML information via ANQP queries are described herein. A STA associated with an AP may request AIML information from a service information registry (SIR) via an ANQP request. To do so, the STA may send an ANQP request containing an AIML element or multiple AIML elements to the SIR. The SIR may respond with an ANQP response containing the requested information or an ANQP response indicating that the information is not available.

[0115] Embodiments of AIML information via PAD (pre-association discovery) are described herein. A STA may use PAD to discover APs that provide AIML services. A STA may use unsolicited or requested PAD to obtain information that an AP provides an AIML service. Once a STA discovers that an AP provides an AIML service via PAD, it obtains additional AIML information via ANQP, by communicating directly with the AIML service, or by using other network services.

[0116] Although the features and elements of the present invention are described in preferred embodiments in specific combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without other features and elements of the present invention.

[0117] Although the solutions described herein may refer to IEEE 802.11 specific protocols, it will be understood that the solutions described herein are not limited to the scenario just mentioned and are applicable to other wireless systems as well.

[0118] SIFS is used in the example designs and procedures to indicate various interframe spacings, but any other interframe spacing, such as RIFS, AIFS, DIFS or other agreed-upon time intervals, could be applied to the same solution.

[0119] Although features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. Furthermore, the methods described herein may 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 media include electrical signals (transmitted over wired or wireless connections) and computer-readable recording media. Examples of computer-readable recording media include, but are not limited to, ROM (described), RAM (random access memory), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, and optical media such as magneto-optical media, e.g., CD-ROM disks and digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for use in a UE, WTRU, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method for use in a station (STA), comprising: receiving an Enhanced Broadcast Service (EBCS) termination notification from an EBCS Access Point (EBCS) AP for one or more ECBS traffic streams transmitted by the ECBS AP; determining that the termination notification indicates an EBCS traffic stream of shorter duration than desired by the STA; sending, by the STA to the EBCS AP, an EBCS content request frame requesting an extension of the EBCS traffic stream when the STA associates with the AP and the termination notification indicates that negotiation method type 1 or type 2 is allowed; A method comprising:

2. 2. The method of claim 1, wherein the EBCS content request frame includes a desired value in a termination request time subfield of the EBCS content request.

3. 3. The method of claim 1, wherein the EBCS content request frame includes a content ID subfield corresponding to the EBCS traffic stream.

4. 4. The method of claim 1, wherein the type 1 negotiation method comprises a request through an EBCS content request frame.

5. 5. The method of any one of claims 1 to 4, wherein the type 2 negotiation method comprises a request through an EBCS content request frame or a request through an EBCS content request ANQP element.

6. 1. A method for use in a station (STA), comprising: receiving an Enhanced Broadcast Service (EBCS) termination notification from an EBCS Access Point (EBCS) AP for one or more ECBS traffic streams transmitted by the ECBS AP; determining that the termination notification indicates an EBCS traffic stream of shorter duration than desired by the STA; sending, by the STA to the EBCS AP if the STA is not associated with an AP and the termination notification indicates that negotiation method type 2 is allowed, an EBCS content request frame including an Access Network Query Protocol (ANQP) element requesting an extension of the EBCS traffic stream; A method comprising:

7. The method of claim 6 , wherein the ANQP element includes a desired value for a termination request time subfield of the EBCS content request.

8. 8. The method of claim 6, wherein the EBCS content request frame includes a content ID subfield corresponding to the EBCS traffic stream.

9. 9. The method of any one of claims 6 to 8, wherein the Type 2 negotiation method comprises a request through an EBCS Content Request ANQP element.

Images