Power-Efficient Broadcasting in WLAN

Abstract

A device, method, and / or system for broadcasting in a wireless local area network (WLAN). A STA receives a frame from a wireless access point (AP) that includes an indication that an enhanced broadcast service (eBCS) service is ending. The frame may include an end of broadcast service announcement information element and / or an indication of the time the eBCS service will end. If the STA wishes to continue receiving the eBCS service beyond the time the eBCS service will end, the STA may negotiate with the AP for continuation of the broadcast service. The STA may receive a trigger frame from the AP that triggers a response from the STA indicating that the STA wishes to continue receiving the eBCS service beyond the time the eBCS service will end.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 971,621, filed February 7, 2020, and U.S. Provisional Patent Application No. 63 / 042,059, filed June 22, 2020, the contents of which are incorporated herein by reference. [Background technology]

[0002] A WLAN in infrastructure Basic Service Set (BSS) mode may include an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. An enhanced broadcast service (eBCS) may include a downlink from the AP to non-AP STAs or an uplink from a sensor non-AP STA. Enhanced broadcast services may be provided to STAs both associated and not associated with a particular AP. Some example use cases for eBCS may include stadium video broadcasting, automotive broadcasting, uplink sensor data broadcasting, museum information and multi-language broadcasting, and / or event producer information and content broadcasting. Summary of the Invention

[0003] A device, method, and / or system for broadcasting in a wireless local area network (WLAN). A STA receives a frame from a wireless access point (AP) including an indication that an enhanced broadcast service (eBCS) service is ending. The frame may include an end of broadcast service announcement information element and / or an indication of the time the eBCS service is ending. If the STA wishes to continue receiving the eBCS service beyond the time the eBCS service is ending, the STA may negotiate with the AP for continuation of the broadcast service. The STA may receive a trigger frame from the AP that triggers a response from the STA indicating that the STA wishes to continue receiving the eBCS service beyond the time the eBCS service is ending. [Brief description of the drawings]

[0004] 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 numbers indicate similar elements and in which: [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1 is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 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 one embodiment. [Diagram 2]1 illustrates an exemplary format of an End of Broadcast Service Announcement information element. [Diagram 3] A diagram illustrating an example format of a broadcast service information control field. [Figure 4] FIG. 13 illustrates an example format of an eBCS termination notification frame action field. [Diagram 5] FIG. 13 illustrates an example format of the eBCS Service Termination Information subfield. [Figure 6] A diagram illustrating an example format of the eBCS service termination information control subfield. [Figure 7] 1 illustrates an example format of a negotiation address subfield. [Figure 8] 1 illustrates an example format of a negotiation address subfield. [Figure 9] 1 illustrates an example format of a negotiation address subfield. [Figure 10] 1 illustrates an example format of a negotiation address subfield. [Figure 11] 4 is a signal diagram illustrating an exemplary multiple access procedure. [Figure 12] FIG. 1 illustrates an example format of an eBCS service capability element. [Figure 13] FIG. 1 illustrates an example format of an eBCS service request element. [Figure 14] A diagram illustrating an example format of a broadcast service information control field. [Figure 15] FIG. 1 illustrates an example format of an eBCS service response element. [Figure 16] A diagram illustrating an example format of a Broadcast Service Information control field in an eBCS service response element. [Figure 17] 1 illustrates an example method for a STA to request continuity of eNCS service. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] 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 multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communications system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (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), and the like.

[0006] 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, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), consumer electronic devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0007] The communications system 100 may also 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 eNode B (eNode B, eNB), a Home NodeB, a home eNodeB, a gNode B (gNode B, gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, or the like. 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.

[0008] The base station 114a may be part of the RAN 104, which may also include other base stations, such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and / or network elements (not shown). The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further 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 one 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, using beamforming to transmit and / or receive signals in a desired spatial direction.

[0009] 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., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0010] More specifically, as noted above, the communications 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 stations 114a of 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 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).

[0011] In one 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 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-APro).

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

[0013] In one 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 LTE radio access and NR radio access together, e.g., using a dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0014] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), GSM Evolution (Enhanced Data rates for GSM Evolution, EDGE), GSM EDGE (GERAN), or the like.

[0015] The base station 114b of FIG. 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 a location of a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by a drone), a road, 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 one 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, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106.

[0016] The RAN 104 may communicate with the CN 106, 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. The data may have various quality of service (QoS) requirements, such as 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 user authentication. Although not shown in FIG. 1A, it will be understood that the RAN 104 and / or the CN 106 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA or WiFi radio technologies.

[0017] The CN 106 may also 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 public switched telephone network that provides 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 the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of 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 CN connected to one or more RANs that may use the same RAT as the RAN 104 or a different RAT.

[0018] 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 different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may use a cellular-based wireless technology, and a base station 114b, which may use an IEEE 802 wireless technology.

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

[0020] 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), 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. Although 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.

[0021] The transmit / receive element 122 may be configured to transmit signals to or receive signals from 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 one 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 appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0022] 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 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 116.

[0023] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and 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, NR and IEEE 802.11.

[0024] 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, 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 from and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

[0025] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For 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.

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

[0027] 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 electronic 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, and the like. 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, an orientation 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.

[0028] 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 of both the UL (e.g., for transmission) and DL (e.g., for reception)) may be simultaneous and / or together. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one 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 of either the UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be simultaneous and / or together.

[0029] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

[0030] The RAN 104 may include eNode-Bs 160a, 160b, 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, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0031] 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.

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

[0033] 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 function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c. 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.

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

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

[0036] The CN 106 may facilitate communications 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 communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Additionally, 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.

[0037] Although the WTRU is illustrated in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

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

[0039] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic to a STA originating from outside the BSS may arrive through the AP and be distributed to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs in a BSS may be transmitted, for example, through the AP, where a source STA may transmit traffic to the AP, which may distribute the traffic to the destination STA. Traffic between STAs in a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted in a direct link setup (DLS) between (e.g., directly between) a source STA and a destination STA. In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have APs, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

[0040] When using an 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit a beacon 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 set width. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., all STAs), 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 at any given time in a given BSS.

[0041] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0042] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz may be formed by combining consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be transmitted to the Medium Access Control (MAC).

[0043] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths 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 TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter-type control / machine-type communications (MTC), such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including, for example, support for (e.g., support only for) specific and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0044] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) 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 Network Allocation Vector (NAV) settings may depend on the condition of the primary channel. For example, if the primary channel is busy, a STA (that only supports a 1 MHz mode of operation) transmitting to the AP may cause all of the available frequency bands to be considered busy, even if most of the available frequency bands are idle.

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

[0046] 1D is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.

[0047] The RAN 104 may include gNBs 180a, 180b, 180c, although it will be understood that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit and / or receive signals to the gNBs 180a, 180b, 180c. Thus, the gNB 180a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using, for example, multiple antennas. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, and the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or gNB 180c).

[0048] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different 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 different or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying lengths of absolute time duration and varying times).

[0049] 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. A non-standalone configuration WTRU 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNode-B 160a, 160b, 160c. For example, the WTRU 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 for serving the WTRUs 102a, 102b, 102c.

[0050] 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 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.

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

[0052] 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 function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of the SMFs 183a, 183b for registration, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0053] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also 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, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0054] 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, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as 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 packet routing and forwarding, enforcing user plane policy, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, mobility anchoring, etc.

[0055] 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 IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Additionally, 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 an 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.

[0056] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to 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 devices 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 functions.

[0057] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or an operator 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 communication network to test other devices in the communication 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 communication network. The emulation devices may be directly coupled to another device for the purpose of testing and / or performing tests using over-the-air wireless communication.

[0058] The one or more emulation devices may perform one or more functions, including but not limited to, while not implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication 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, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0059] A WLAN in infrastructure basic service set (BSS) mode may include an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP typically has access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic to the STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs in the BSS may be transmitted through the AP, where the source STA transmits traffic to the AP, and the AP delivers the traffic to the destination STA. Such traffic between STAs in the BSS may be considered as peer-to-peer traffic. Such peer-to-peer traffic may also be transmitted directly between the source and destination STAs in a direct link setup (DLS), for example, using 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP and / or may include STAs that communicate directly with each other. This communication mode is referred to as an "ad-hoc" communication mode.

[0060] Using 802.11ac infrastructure mode of operation, an AP may transmit a beacon on a fixed channel, such as the primary channel. This channel may be 20 MHz wide and may be the operating channel of the BSS. This channel may also be used by STAs to establish a connection with the AP. Channel access in 802.11 systems may include carrier sense multiple access with collision avoidance (CSMA / CA). In this mode of operation, all STAs, including the AP, may sense the primary channel. If the channel is detected as busy, the STAs may "back off." Thus, only one STA may transmit at any given time in a given BSS.

[0061] In 802.11n, high-throughput (HT) STAs may also use 40 MHz wide channels for communication, which may be accomplished by combining a primary 20 MHz channel with an adjacent 20 MHz channel to form a 40 MHz wide contiguous channel.

[0062] In 802.11ac, very high throughput (VHT) STAs may support 20 MHz, 40 MHz, 80 MHz, and 160 MHz wide channels. 40 MHz and 80 MHz channels may be formed by combining contiguous 20 MHz channels similar to 802.11n above. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which may also be referred to as an 80+80 configuration. In the case of the 80+80 configuration, after channel encoding, the data may pass through a segment parser that splits the data into two streams. IFFT and time domain processing may be performed separately on each stream, after which the streams may be mapped to two channels and the data may be transmitted. At the receiver, this mechanism is reversed and the combined data is transmitted to the MAC.

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

[0064] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, may include a channel designated as a primary channel. The primary channel may, but does not necessarily, have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may therefore be limited by the STA among all STAs operating in the BSS that supports the smallest bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide if there are STAs (e.g., MTC type devices) that only support the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, or other channel bandwidth operating modes. All carrier sensing and NAV settings may depend on the status of the primary channel. That is, if the primary channel is busy, for example due to STAs that only support the 1 MHz operating mode transmitting to the AP, the entire available frequency band may be considered busy, even though most of it may remain idle and available.

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

[0066] IEEE 802.11™ High Efficiency WLAN (HEW) may include enhancements to improve the quality of service experienced by all users for wide spectrum wireless users in many usage scenarios, including high density scenarios in the 2.4 GHz, 5 GHz, and 6 GHz bands. New use cases supporting high density deployment of APs and STAs, as well as related Radio Resource Management (RRM) techniques, may be considered.

[0067] Potential applications for HEW could include new usage scenarios such as data distribution of stadium events, train stations, or corporate / retail environments, as well as high user density scenarios such as evidence with increasing reliance on video distribution, and wireless services for medical applications.

[0068] The measured traffic for various applications is likely to be short packets, and network applications may also generate short packets, such as virtual office, transmit power control (TPC) acknowledgement (ACK), video streaming ACK, device / controller (mouse, keyboard, game control, etc.), access-probe request / response, network selection-probe request, Access Network Query Protocol (ANQP), and / or network management-control frame applications.

[0069] 802.11ax may include UL OFDMA and DL OFDMA, as well as MU features including UL multi-user MIMO (MU-MIMO) and DL multi-user MIMO. Designing and defining mechanisms for multiplexing UL random access for different purposes may be considered in the specification.

[0070] 802.11ax may address medium access issues in the 6 GHz band, such as by using triggered or scheduled medium access only in the 6 GHz band and / or by limiting active scanning and use of Enhanced Distributed Channel Access (EDCA) medium access scheduled in the 6 GHz band.

[0071] IEEE 802.11bc may include MAC amendments for enhanced broadcast services (eBCS) for 802.11 devices. The IEEE 802.11bc amendments may not affect the current IEEE 802.11 PHY specification.

[0072] The eBCS service may include a downlink from the AP to non-AP STAs or an uplink from a sensor non-AP STA. Enhanced broadcast services may be provided to STAs both associated or not associated with a particular AP. An AP may support up to 3000 non-AP STAs with eBCS services. Additionally, there may be a class of low-cost non-AP STAs consuming eBCS services that may not be able to transmit directly to an AP.

[0073] Some example use cases for eBCS may include stadium video broadcasting, automotive broadcasting, uplink sensor data broadcasting, museum information and multilingual broadcasting, and / or event producer information and content broadcasting.

[0074] In a downlink broadcast use case, an eBCS AP may provide broadcast services to STAs associated or not associated with the AP. Because broadcast frames may not be acknowledged, it is not always clear whether there are STAs that utilize the broadcast service and receive the broadcast data. If the broadcast data is not received, the AP consumes both power and wireless medium resources. Some implementations provide a broadcast service mechanism that facilitates a broadcast service that is power efficient, and may only provide the broadcast service when and / or if the service is actively consumed.

[0075] For a STA that desires to utilize a downlink broadcast service provided by one or more APs, the STA may or may not be associated with the AP that provides the broadcast service. Such a STA and the AP may need to request the broadcast service and negotiate parameters of the requested broadcast service. Some implementations include indications and negotiation procedures to support broadcast service discovery and parameter negotiation.

[0076] Some implementations provide an end of broadcast service announcement information element. In some implementations, an AP may transmit an end of broadcast service announcement frame or a frame including an end of broadcast service announcement information element to announce that one or more eBCS services are ending.

[0077] It should be noted that the example values ​​of the various fields and subfields discussed herein are provided for illustration only, and that in other implementations, any other suitable values ​​may be used to indicate the same or different information. For example, in some implementations, a bit value of 1 in a field may indicate a particular information, while a bit value of 0 in the field may indicate this same information.

[0078] 2 is a bitmap diagram illustrating an example format of an end of broadcast service announcement information element. The end of broadcast service announcement information element may include one or more of the fields element identifier (ID) 202, length 204, and element ID extension 206, number of broadcast service fields 208, and one or more broadcast service fields 210. The element identifier (ID) field 202, length field 204, and element ID extension field 206 may indicate that the current element is the end of the broadcast service announcement information element and may indicate the length of the current element. The number of broadcast service fields 208 may indicate the number of broadcast service fields the element contains. Each of the one or more broadcast service fields 210 may include information for a particular broadcast service, including some or all of the fields described below for each broadcast service.

[0079] 2 and may include one or more of the following fields: broadcast service information control field 212, broadcast service ID field 214, upper layer destination address field 216, title length field 218, title field 220, time to termination field 222, and / or negotiation method field 224. The broadcast service information control field 212, broadcast service ID field 214, title length field 218, time to termination field 222, and negotiation method field 224 may be one byte long, while the upper layer destination address field 216 and the title field may be variable byte long.

[0080] 3 is a bitmap diagram illustrating an example format of the broadcast service information control field 212. The broadcast service information control field 212 may be one byte long and may include an indication of whether particular broadcast information is included in the broadcast service field 210. The broadcast service information control field 212 may include one of the following subfields: a broadcast service ID present subfield 302, a higher layer protocol subfield 304, a title present subfield 306, a negotiation method present subfield 308, an association request subfield 310, and a reservation subfield 312.

[0081] The Broadcast Service ID Present subfield 302 may be 1 bit long and may indicate whether a Broadcast Service ID is included in the Broadcast Service field. The Upper Layer Protocol subfield 304 may be 3 bits long and may contain a value indicating whether there is no upper layer destination address or whether an upper layer destination address is present in the Broadcast Service field 210, and may contain a value indicating that the upper layer destination address present in the Broadcast Service field 2010 may be an address associated with one of the following upper layer protocols: UDP / IPv4, UDP / IPv6, UDP / hostname; MPEG transport stream identifier, MAC address, or reservation.

[0082] The Title Present subfield 306 may be one bit long and may indicate whether a user-readable title is present in the Broadcast Services field 210. If the Title Present subfield 306 bit is set to one, then the Title Length subfield 218 and the Title subfield 220 may be included in the Broadcast Services field 210. The Negotiation Method Present subfield 308 may be one bit long and may indicate whether the Negotiation Method subfield 224 is included in the Broadcast Services field 210. The Association Request subfield 310 may be one bit long and may indicate whether the broadcast service described by the current Broadcast Services field 210 requires association before it can be utilized by other STAs.

[0083] 2, the Broadcast Service ID subfield 214 may be one byte long and may indicate an identifier for the broadcast service. The Upper Layer Destination Address subfield 216 may be of different lengths depending on, for example, the value indicated in the Upper Layer Protocol field of the Broadcast Service Information Control subfield. If IPv4 / UDP or IPv6 / UDP is indicated in the Upper Layer Protocol subfield 304, the Upper Layer Destination Address subfield 216 may include an IP address and a UDP port.

[0084] The upper layer destination address subfield 216 may contain a 6-byte MAC address if a MAC address is indicated in the upper layer protocol subfield 304. If the upper layer protocol subfield 304 indicates that an upper layer destination address field is not present, then an upper layer destination address may not be included in the broadcast service field 210.

[0085] The title length subfield 218 may be included in the broadcast services field 210 if the title present subfield 306 in the broadcast services information control subfield 212 is set to 1, otherwise it may not be present. The title length subfield 218 may be 1 byte long and may indicate the length of the title subfield 220.

[0086] The title subfield 220 may be included in the broadcast services field 210 if the title present subfield 306 in the broadcast services information control subfield 212 is set to 1, otherwise it may not be present. The title length subfield 218 may be 1 byte long and may indicate the length of the title subfield 220.

[0087] The time until termination subfield 222 may be used to indicate the time remaining until the broadcast service described in this broadcast service field 210 is terminated unless further negotiations are made by one or more STAs that may consume the broadcast service. In another example, the time until termination subfield 222 may include a time, such as a timing synchronization function (TSF) time value, or other type of time, at which the broadcast service will be terminated unless further negotiations are made by the initiator of the broadcast service or by other users of the broadcast service. Additionally or alternatively, a timestamp of the current time, such as the current value of a TSF timer, may be included.

[0088] The negotiation method subfield 224 may be included in the broadcast service field 210 if the negotiation method present subfield 308 is set to 1 (or another suitable indication). The negotiation method subfield may be used to indicate the negotiation method to be used to negotiate the continuation of the broadcast service beyond the end time. The negotiation method subfield may include one or more of the following values ​​via a broadcast service request frame, via an ANQP / GAS broadcast service request frame, and / or via an IP request (in which case the IP version and IP addresses required for negotiation may be included):

[0089] In some implementations, any subset of the fields or subfields of the end of broadcast service announcement element 200 may be implemented in any field or subfield or set or subset of fields of an existing or newly designed element or frame, or the PHY and / or MAC header of any management, control, data frame, or other header, or other frame.

[0090] Some implementations provide an eBCS service termination notification frame format. In some implementations, the eBCS service termination notification frame is transmitted by a STA that is a transmitter of an eBCS service to announce the termination of one or more of the eBCS services transmitted by that STA, e.g., an AP or another STA.

[0091] 4 is a diagram illustrating an example format of an eBCS termination notification frame action field 400. As illustrated in FIG. 4, the eBCS termination notification frame action field 400 may include a category field 402, a public action field 404, and / or an eBCS service termination information set field 406. The category field 402 and the public action field 404 may be one octet long, and the eBCS service termination information set field 406 may be variable length. In some implementations, the eBCS service termination information set field 406 includes one or more of the eBCS service termination information subfields 500.

[0092] Figure 5 is a diagram illustrating an example format of an eBCS service termination information subfield 500. As shown in Figure 5, the eBCS service termination information set field 406 may include one or more of an eBCS service termination information control subfield 502, an eBCS service ID subfield 504, a title length subfield 506, a title subfield 508, a time to termination subfield 510, a negotiation method subfield 512, a negotiation address type subfield 514, and / or a negotiation address subfield 516.

[0093] The eBCS service termination information control subfield 502, the eBCS service ID subfield 504, and the negotiation method subfield 512 may have a length of one octet, while the title length subfield 506 and the negotiation method subfield 514 may have a length of 0 or 1 octet. The time to termination subfield 510 may have a length of two octets. The title subfield 508 and the negotiation address subfield 516 may be of variable octet length.

[0094] Figure 6 is a diagram illustrating an example format of the eBCS service termination information control subfield 502. As shown in Figure 6, the eBCS service termination information control subfield 502 may include a title presence indicator subfield 602, a negotiation address presence indicator subfield 604, an association request subfield 606, and / or a reservation subfield 608.

[0095] In one example, a value of 1 in the title presence indicator subfield 602 indicates that the title length subfield 506 and the title subfield 508 are present in the same eBCS service termination information subfield. In one example, a value of 0 in the title presence indicator subfield 602 indicates that the title length subfield 506 and the title subfield 508 are not present in the same eBCS service termination information subfield. In one example, a value of 1 in the negotiation address presence indicator subfield 604 indicates that the negotiation address type subfield 514 and the negotiation address subfield 516 are present in the same eBCS service termination information subfield. In one example, a value of 0 indicates that the negotiation address type subfield 514 and the negotiation address subfield 516 are not present in the same eBCS service termination information subfield. In one example, a value of 1 in the association request subfield 606 indicates that association is required to consume the eBCS service identified by the eBCS service ID included in the eBCS service ID subfield 504. In one example, a value of 0 indicates that no association is required to consume the eBCS service identified by the eBCS service ID included in the eBCS service ID subfield 504.

[0096] Referring back to FIG. 5 , in some implementations, the eBCS service ID subfield 504 is one octet long. In some implementations, the eBCS service ID subfield 504 indicates the ID of the eBCS service to be terminated. In some implementations, the title length subfield 506 is one octet long. In some implementations, the title length subfield 506 indicates the length in octets of the title subfield 508. In some implementations, the title subfield 508 indicates the title of the eBCS service identified by the eBCS service ID included in the eBCS service ID subfield 504. In some implementations, the title subfield 508 indicates the title in 8-bit Unicode Transformation Format (UTF-8) format. In some implementations, the time until termination subfield 510 is two octets long. In some implementations, the time until termination subfield 510 indicates the number of TBTTs until the eBCS service identified by the eBCS service ID included in the eBCS service ID subfield 504 is terminated. In some implementations, the Time to End subfield 510 may be indicated in other time formats, such as milliseconds (ms), microseconds (us), Time Units (TU), or any other type of time unit. In some implementations, a value of 0 indicates that the eBCS service identified by the eBCS service ID in the same eBCS service ID subfield 504 does not have a specific end time. In some implementations, some other value, such as the maximum value of the Time to End subfield, indicates that the eBCS service identified by the eBCS service ID in the same eBCS service ID subfield 504 does not have a specific end time or indicates that the eBCS service identified by the eBCS service ID in the same eBCS service ID subfield 504 has an end time that is greater than the maximum value that may be included in the Time to End subfield 510.

[0097] In some implementations, the negotiation method subfield 512 is one octet long. In some implementations, the negotiation method subfield 512 indicates a negotiation method for negotiating an extension of the eBCS service identified by the eBCS service ID included in the eBCS service ID subfield 504. An exemplary encoding of the negotiation method subfield 512 is defined below in Table 1. Other values ​​may be used to indicate the same negotiation methods as detailed in Table 1.

[0098] [Table 1]

[0099] In some implementations, the negotiation address type subfield 514 is one octet long. In some implementations, the negotiation address type subfield 514 indicates the type of address contained in the negotiation address subfield 516. An exemplary encoding of the negotiation address type subfield 514 is defined in Table 2.

[0100] [Table 2]

[0101] In some implementations, the negotiation address subfield 516 indicates an address used to negotiate extensions to the eBCS service identified by the eBCS service ID included in the eBCS service ID subfield 504. In some implementations, the format and length of the negotiation address subfield 516 depends on the value included in the negotiation address type subfield 514. In some implementations, the negotiation address subfield 516 includes a MAC address, for example, if the negotiation address type is equal to 0.

[0102] 7 is a diagram illustrating an example format of the negotiation address subfield 516, for example, when the negotiation address type is equal to 1 (or another suitable value indicating this). In some implementations, the IPv4 address subfield 702 indicates an IPv4 address used to negotiate an extension of the eBCS service. In some implementations, the destination UDP port subfield 704 indicates a UDP port associated with the IPv4 address indicated in the IPv4 address subfield 702 in little endian format.

[0103] 8 is a diagram illustrating an example format of the negotiation address subfield 516, for example, when the negotiation address type is equal to 2 (or another suitable value indicating this). In some implementations, the IPv6 address subfield 802 indicates an IPv6 address used to negotiate an extension of the eBCS service. In some implementations, the destination UDP port subfield 804 indicates a UDP port associated with the IPv6 address indicated in the IPv6 address subfield 802 in little endian format.

[0104] 9 is a diagram illustrating an example format of the negotiation address subfield 516, for example, when the negotiation address type is equal to 3 (or another suitable value indicating this). In some implementations, the hostname length subfield 902 indicates the length of the hostname subfield, for example, in octets. In some implementations, the hostname subfield 904 indicates a hostname for negotiating an extension of the eBCS service, for example, in UTF-8 format. In some implementations, the destination UDP port subfield 906 indicates a UDP port associated with the hostname indicated in the hostname subfield, for example, in little endian format.

[0105] 10 is a diagram illustrating an example format of the negotiation address subfield 516, for example, when the negotiation address type is equal to 4 (or another suitable value indicating this). In some implementations, the MPEG transport stream length subfield 1002 indicates the length of the MPEG transport stream ID subfield 1004, for example, in octets. In some implementations, the MPEG transport stream ID subfield 1004 indicates the MPEG transport stream ID, for example, in UTF-8 format.

[0106] Some implementations include an end of broadcast service announcement indication procedure. In some implementations, the end of broadcast service announcement indication procedure for a DL broadcast service may be as follows:

[0107] An AP may advertise a broadcast service using a broadcast service element, such as in a beacon, a probe response, an eBCS service advertisement frame, and / or an eBCS information frame. Some broadcast services may be assigned specific time and / or frequency resources. These time and frequency resources may be broadcast at a specific periodicity.

[0108] Broadcast services may be requested by STAs that may or may not be associated with an AP, or that may request broadcast services through other means, such as through an IP protocol. When broadcast services are requested, the STA may request broadcast services for a particular period of time. For example, a STA may request video playback for 10 minutes. STAs requesting the same or similar services may be grouped by an AP. The period of the broadcast service may be modified by the AP based on the explicit or implicit desires of the STA or group of STAs.

[0109] The AP may indicate the remaining time of the broadcast service it is providing by including (e.g., periodically) an end of broadcast service announcement element in one or more of the frames it is transmitting (e.g., in a beacon frame, a probe response frame, an eBCS data frame, a broadcast service request frame, an eBCS service advertisement frame, and / or an eBCS information frame).

[0110] An AP may indicate that one or more broadcast services it is providing are ending at a given time, for example, by including an end of one or more broadcast service announcement elements in one or more of the frames it is transmitting (e.g., in a beacon frame, a probe response frame, an eBCS data frame, a broadcast service request frame, an eBCS service advertisement frame, or an eBCS information frame). The AP may include negotiation methods necessary for any STAs interested in continuing the broadcast beyond the end time to perform negotiation of the broadcast service beyond the indicated end time. The AP may indicate that one or more broadcast services it is providing will be broadcast at a particular periodicity before ending.

[0111] A STA using or planning to use the broadcast service may receive one or more frames that may include broadcast service announcement information or end of element for the broadcast service. If the STA wishes to use the broadcast service beyond the indicated end time, the STA may negotiate with the AP for the continuation of the broadcast service according to the negotiation method indicated by the AP.

[0112] If the broadcast service requires association (e.g., as indicated in the Association Request subfield) and the negotiation is via a Broadcast Service Request frame, the STA may perform an association procedure with the AP. If the STA is already associated with the AP, the STA may transmit a Broadcast Service Request frame indicating that it desires one or more broadcast services. The STA may indicate that it desires one or more broadcast services for a particular duration or with a particular periodicity. The AP may respond with a Broadcast Service Response frame indicating that the broadcast service will continue for a longer duration and / or periodicity. If a second STA desires the same broadcast service and the second STA receives a frame including a broadcast service announcement element or end of information indicating that the broadcast service has been extended, the second STA may cancel any pending Broadcast Service Request frames that it plans to send to the AP.

[0113] If the broadcast service does not require association (e.g., as indicated in the association request subfield) and negotiation is via an ANQP / GAS broadcast service request frame, the STA may transmit an ANQP / generic advertisement service (GAS) broadcast service request frame indicating that it desires one or more broadcast services or to register for one or more broadcast services. The STA may indicate that it desires or registers for one or more broadcast services for a particular period of time. The AP may respond with an ANQP / GAS broadcast service response frame indicating that the broadcast service will continue for a longer period of time. If a second STA desires the same broadcast service and the second STA receives a frame including a broadcast service announcement element or end of information indicating that the broadcast service has been extended, the second STA may cancel any pending ANQP / GAS broadcast service request frame that it plans to send to the AP.

[0114] If the broadcast service does not require association (e.g., as indicated in the association request subfield) and negotiation is via IP protocols (e.g., using IPv4 and IPv6 and appropriate IP addresses), the STA may send an IP packet over another interface indicating that it desires one or more broadcast services, if possible, or registers for one or more broadcast services. The STA may indicate that it desires or registers for one or more broadcast services for a particular period of time. The AP may send an ANQP / GAS broadcast service response frame, or an eBCS information frame, or any other frame with a beacon frame, eBCS service advertisement frame, or end of broadcast service announcement frame, indicating that the broadcast service will continue for a longer period of time. If a second STA desires the same broadcast service and the second STA receives a frame including a broadcast service announcement element or end of information indicating that the broadcast service has been extended, the second STA may cancel any pending IP packets requesting that the broadcast service continue.

[0115] Some implementations provide an eBCS service termination notification procedure. In some implementations, the eBCS service termination notification procedure allows a STA that is a broadcaster of an eBCS service to indicate that one or more eBCS services that it is broadcasting will be terminated. In some implementations, the eBCS service termination notification procedure allows a STA that is a broadcaster of an eBCS service to indicate that one or more eBCS services that it is broadcasting will be terminated. In some implementations, the eBCS service termination notification procedure allows a STA to indicate that one or more eBCS services that one or more other STAs are broadcasting will be terminated.

[0116] In some implementations, an eBCS STA that is a broadcaster of one or more eBCS services shall start transmitting eBCS service termination notification frames if one or more of the eBCS services it is transmitting are terminated within an interval less than or equal to a time, e.g., dot11eBCSTerminationNoticeTime, if the STA is not periodically transmitting a schedule for the eBCS services that are terminating. In some implementations, an eBCS STA shall start transmitting eBCS service termination notification frames if one or more of the eBCS services are terminated within an interval less than or equal to a time, e.g., dot11eBCSTerminationNoticeTime, if the STA is not periodically transmitting a schedule for the eBCS services that are terminating. In some implementations, an eBCS STA shall start transmitting eBCS service termination notification frames if one or more of the eBCS services are terminated within an interval less than or equal to a time, e.g., dot11eBCSTerminationNoticeTime, if the STA is not periodically transmitting a schedule for the eBCS services that are terminating. In some implementation aspects, when an eBCS STA starts transmitting an eBCS service termination notification frame, the STA shall transmit the eBCS service termination notification frame within a period greater than a minimum interval, such as dot11eBCSTerminationNoticeMinimumInterval, and less than a maximum interval, such as dot11eBCSTerminationNoticeMaximumInterval.

[0117] In some implementations, an eBCS STA transmitting an eBCS service termination notification frame indicates the number of TBTTs in a Time to Termination subfield in the eBCS Service Termination Information subfield before the eBCS service identified by the eBCS service ID included in the eBCS Service ID subfield in the same eBCS Service Termination Information subfield is terminated. In some implementations, the Time to Termination subfield may be indicated in other time formats, such as ms, us, time units (TUs), or any other type of time unit.

[0118] In some implementations, an eBCS STA sending an eBCS service termination notification frame shall indicate in a negotiation method subfield within the eBCS service termination information subfield the negotiation method that the STA should use to negotiate an extension of the eBCS service identified by the eBCS service ID contained in the eBCS service ID subfield within the same eBCS service termination information subfield. In some implementations, the eBCS STA may indicate that negotiation is not available.

[0119] In some implementations, an eBCS STA sending an eBCS service termination notification frame may indicate in a negotiation address subfield within an eBCS service termination information subfield an address associated with the negotiation method indicated in the negotiation method subfield within the same eBCS service termination information subfield that the STA should use to negotiate an extension of the eBCS service identified by the eBCS service ID included in the eBCS service ID subfield within the same eBCS service termination information subfield.

[0120] In some implementations, after transmitting an eBCS service termination notification frame, if the eBCS service identified by the eBCS service ID in the eBCS service ID subfield in the same eBCS service termination information subfield is negotiated with a different duration or a new time to termination value, the eBCS STA shall transmit an eBCS service termination notification frame with an updated value of the Time to Termination subfield in the eBCS service termination information subfield. In some implementations, if the duration negotiated for the eBCS service is longer than the Time to Termination subfield maximum, the transmitting STA shall set the Time to Termination subfield to 0. In some implementations, if the duration negotiated for the eBCS service is longer than the Time to Termination subfield maximum, the transmitting STA shall set the Time to Termination to the maximum value of the Time to Termination subfield. In some implementations, if the duration negotiated for the eBCS service is longer than the Time to Termination subfield maximum, the transmitting STA shall set the Time to Termination subfield to some specific value N.

[0121] In some implementations, after transmitting an eBCS Service Termination Notification frame, if the eBCS has been negotiated with a different duration or a new Time to Termination value, the eBCS STA shall transmit an eBCS Service Information frame or other type of frame with an updated value for the Time to Termination subfield or the eBCS Service Duration subfield.

[0122] In some implementations, an eBCS STA receiving an eBCS service termination notification frame may negotiate an extension of the eBCS service if, for example, the eBCS service indicated in one of the eBCS service termination information subfields is terminated earlier than desired. In some implementations, the eBCS STA may negotiate the extension of the eBCS service using, for example, a negotiation method as indicated in the negotiation method in the eBCS service termination information subfield, and in some implementations may follow, for example, procedures defined in the 802.11 specifications, for example, 11.22.6.x (eBCS service negotiation procedures for associated STAs) and 11.23.3.3 (ANQP procedures).

[0123] In some implementations, an eBCS STA receiving an eBCS service information frame or any other frame time may negotiate an extension of the eBCS service, e.g., if the eBCS service terminates earlier than desired. In some implementations, the eBCS STA may negotiate an extension of the eBCS service using, e.g., a negotiation method as indicated in the negotiation method in the eBCS service termination information subfield, and in some implementations may follow, e.g., procedures defined in the 802.11 specifications, e.g., 11.22.6.x (eBCS service negotiation procedures for associated STAs) and 11.23.3.3 (ANQP procedures).

[0124] In some implementations, an eBCS STA shall skip transmitting any eBCS service request frames, or frames containing an enhanced broadcast request ANQP element, or any IP frames requesting an eBCS service, if the STA receives an eBCS service termination notification frame in which the eBCS service termination information subfield contains the eBCS service ID of the eBCS service, or in an eBCS service information frame or other type of frame for the same eBCS service, has an acceptable time to termination or duration value.

[0125] Some implementations include an end of broadcast service announcement indication procedure with a trigger mechanism. In some implementations, after an end of broadcast service announcement indication (EBSAI) is sent by an AP via a management or control frame or aggregated with any type of frame, STAs that may intend to retain a current service or negotiate a new broadcast service may respond. More than one STA may need to send a response to the EBSAI.

[0126] 11 is a signal diagram illustrating an example multiple access procedure. As shown in FIG. 11, an AP may transmit a frame with an EBSAI. The detailed frame format may be as described herein, for example, with respect to an end of broadcast service announcement information element and / or an end of broadcast service announcement indicator procedure.

[0127] The AP may expect one or more STAs to transmit a response frame. The AP may transmit a trigger frame to trigger a multiple access response transmission. In some implementations, the trigger frame may be transmitted an interframe space (xIFS) time after a frame with an EBSAI, where xIFS may refer to any existing interframe space or a newly defined interframe space. In some implementations, the trigger frame may be aggregated with a frame with an EBSAI. The trigger frame may indicate a trigger type in a trigger type field. The trigger type field may indicate a newly defined type, such as an EBSAI, an NDP, or a probe request management frame trigger. Alternatively, the trigger type field may indicate an existing trigger type, such as a basic trigger.

[0128] One or more STAs may send a response to the EBSAI so that the STAs may retain the originally negotiated broadcast service, modify the originally negotiated broadcast service, for example, to continue the service beyond an end time, and / or request to initiate a new broadcast negotiation at a specified duration and periodicity.

[0129] The STA may send an EBSAI response using one or more of the same response method, the triggered-based random access method, and / or the triggered-based probe request method.

[0130] In an exemplary identical response method, a common end of the broadcast response frame / field / element / PPDU may be defined such that STAs that may intend to respond may transmit identical physical layer packets at the same time. The AP may be able to detect simultaneous transmissions from the STAs, e.g., because they are identical.

[0131] For example, in some implementations of the same response method, the STA may be able to indicate a single message (e.g., the STA prefers to keep the originally negotiated broadcast service). In some implementations, a null data packet (NDP) EBSAI response PPDU may be used for this type of EBSAI response. The NDP EBSAI response PPDU may carry a short training field (STF), a long training field (LTF), and a signal training field (SIG) field (in addition, a legacy preamble field may be prepended for backward compatibility). The SIG field may be modified to indicate that the STA may prefer to keep the original negotiation. Alternatively, the SIG field may be omitted and the current NDP transmission may indicate that the STA prefers to keep the original configuration. The PPDU may be an xIFS transmitted after a trigger frame by one or more STAs. In this manner, STAs that may prefer to end the broadcast service may not need to respond, and STAs that may prefer to continue the broadcast service may respond.

[0132] For example, in some implementations of the same response method, the STA may be able to carry several messages (e.g., M messages). Examples of such messages may include holding the initial negotiation, modifying the initial negotiation, starting a new negotiation, etc. In one design, an NDP EBSAI response PPDU may be used for this type of EBSAI response. The NDP EBSAI response PPDU may carry STF and LTF and SIG fields (the legacy preamble field may be prepended for backward compatibility). Some of the above-mentioned fields may be transmitted in partial bandwidths. The location of the transmission may indicate the message that may be carried. For example, the entire bandwidth may be divided into M chunks. If the STF and / or LTF and / or SIG fields may be transmitted on a first frequency chunk, it may indicate a first message. If the STF and / or LTF and / or SIG fields may be transmitted on a second frequency chunk, it may indicate a second message, etc. The PPDU can be the transmitted xSIF immediately following the trigger frame. In one method, the mapping of frequency resources and messages can be predefined and no signaling is required. In one method, the mapping of frequency resources and messages can be carried in the trigger frame.

[0133] In an exemplary trigger-based random access method, one or more of the resource units may be allocated for response transmission. The resource allocation may be included in a trigger frame. A STA may initiate an OFDMA random access procedure and select one or more resource units to transmit its response frame. The response frame may be a regular MAC frame, which may include transmit (Tx) and / or receive (Rx) addresses and other fields normally defined in a MAC header. It may further carry EBSAI response related information.

[0134] In an exemplary trigger-based probe request method, one or more of the resource units may be allocated for this response transmission. The resource allocation may be included in the trigger frame. An unassociated STA may use a probe request management frame to select one or more resource units for transmitting a frame. This response frame may contain additional information beyond what is currently available in these management frames to negotiate / renegotiate broadcast services.

[0135] Some implementations provide an eBCS service capability indication. In some implementations, an AP may include an eBCS service capability element in any frame it transmits, such as a probe response, a beacon frame, an eBCS service advertisement frame, an eBCS information frame, an FILS discovery frame, etc.

[0136] FIG. 12 is a bitmap diagram illustrating an example format of an eBCS service capabilities element. The eBCS service capability element may include one or more of the following subfields, for example, as arranged in FIG. 12 : element ID subfield 1202, length subfield 1204, element ID extension subfield 1206, sequence number subfield 1208, number of fragments subfield 1210, fragment index subfield 1212, DL broadcast capability subfield 1214, number of broadcast services subfield 1216, eBCS1-N subfield 1218, broadcast information control subfield 1220, broadcast ID subfield 1222, eBCS subfield 1224, association request subfield 1226, UL transmission request subfield 1228, broadcast parameters subfield 1230, broadcast security subfield 1232, higher layer destination address subfield 1234, title present subfield 1236, title length subfield 1228, title subfield 1240, time to end subfield 1242, broadcast control subfield 1244, and / or other subfields. A description of an example of such a subfield follows:

[0137] For the element ID subfield 1202, length subfield 1204, and element ID extension subfield 1206, the combination of the element ID and element ID extension may identify the current element as a DL broadcast capability element or as a DL eBCS element. The length subfield 1204 may indicate the length of the element.

[0138] The sequence number subfield 1208 may indicate a sequence number of the eBCS service capability element.

[0139] The number of fragments subfield 1210 may indicate the number of fragments into which the eBCS capability element identified by the sequence number may be divided.

[0140] The fragment index subfield 1212 may indicate the index of the fragment of the eBCS capabilities element included in the current eBCS capabilities element.

[0141] The eBCS1-N subfields 1218 may include N subfields that may be included in a broadcast element, where each field may be used to specify a particular broadcast service provided by a transmitting STA, e.g., a transmitting AP. Each eBCS field may include one or more of the following subfields: a broadcast information control subfield 1220, a broadcast ID subfield 1222, an eBCS type subfield 1224, an association request subfield 1226, a UL transmission request subfield 1228, a broadcast parameters subfield 1230, and / or a broadcast security subfield 1232.

[0142] The Broadcast Information Control subfield 1220 may be 1 byte long and may include an indication of whether particular broadcast information is included in the eBCS N field. The Broadcast ID subfield 1222 may be 1 bit long and may indicate whether a Broadcast ID is included in the eBCS N field.

[0143] The upper layer destination address subfield 1234 may be 3 bits long and may indicate one of the following values: no upper layer destination address is present, an upper layer destination address is present in the eBCS N field, and the upper layer protocol may include UDP / IPv4, UDP / IPv6, UDP / hostname, MPEG transport stream identifier, MAC address, and / or reserved. The title present subfield 1236 may be 1 bit long and may indicate whether a user-readable title is present in the eBCS N field. If the title present bit is set to 1, then the title length subfield 1238 and the title subfield 1240 may be included in the eBCS N field. The broadcast control present subfield may be 1 bit long and may indicate whether a negotiation method subfield is included in the eBCS N field.

[0144] The broadcast ID subfield 1222 may indicate the ID of the broadcast service. The eBCS type subfield 1224 may include the type of broadcast service, for example, whether the eBCS is UL or DL, or whether the broadcast service is of the following categories: auto, direction, emergency, support, information, event_support. In some implementations, a bitmap may be included in the DL broadcast element to indicate what type of broadcast service is provided by the transmitting STA. The type may also be multi-AP broadcast. In some implementations, the broadcast type may be identified by an organizationally unique identifier (OUI).

[0145] The association required subfield 1226 may indicate whether association is required to consume one or more broadcast services, e.g., a broadcast service identified by a broadcast ID. The UL transmission required subfield 1228 may indicate whether UL transmission is required to consume one or more broadcast services, e.g., a broadcast service identified by a broadcast ID.

[0146] The Broadcast Control subfield 1244 may indicate how to control the broadcast service. For example, it may indicate that if the STA desires a particular broadcast service, the STA must negotiate directly with the transmitting STA, e.g., the transmitting AP, e.g., by using a broadcast request frame. In another example, the subfield may indicate a server address, e.g., the IP address of the server, or a controller address, e.g., the MAC address or BSSID of another AP. Such a controller AP may be a master AP of a multi-AP set. The STA may also communicate with the controller or server to provide feedback or negotiation rate or encoding of the broadcast service. Methods for control may be via WLAN, TCP / IP, broadcast request negotiation, ANQP or GAS frame exchange, etc. The Broadcast Parameters subfield may include one or more broadcast parameters, including, for example, an offset and / or channel. For example, the offset of the start of the next broadcast packet or broadcast burst may be from the end of the current transmission, or from the target beacon transmission time (TBTT) or other reference point. The channel may include a channel or an OFDMA subchannel or a resource unit (RU) on which broadcast service packets may be available.

[0147] The upper layer destination address subfield 1234 may be of different lengths depending on the value indicated in the upper layer protocol field of the broadcast service information control subfield 1220. If IPv4 / UDP or IPv6 / UDP is indicated in the upper layer protocol subfield, the upper layer destination address subfield 1234 may include an IP address and a UDP port. The upper layer destination address subfield 1234 may include, for example, a 6-byte MAC address if a MAC address is indicated in the upper layer protocol subfield. If the upper layer protocol subfield indicates that the upper layer destination address field is not present, then an upper layer destination address may not be included in the broadcast service field.

[0148] For example, the Title Length subfield 1238 may be included in the Broadcast Services field if the Title Present subfield 1236 in the Broadcast Services Information Control subfield is set to 1, otherwise it is not present. The Title Length field may be 1 byte long and may indicate the length of the Title subfield 1240.

[0149] For example, the Title subfield 1240 may be included in the Broadcast Services field if the Title Present subfield 1236 in the Broadcast Services Information Control subfield is set to 1, otherwise it may not be present. The Title Length field may be 1 byte long and may indicate the length of the Title subfield 1240.

[0150] The Time to Termination subfield 1242 may be used to indicate the remaining time until the broadcast service described in this Broadcast Service field is terminated unless further negotiations are made by the initiator of the broadcast service or by other users of the broadcast service. In some implementations, the subfield may include a time (e.g., a TSF time value, or other type of time) at which the broadcast service will terminate unless further negotiations are made by the initiator of the broadcast service or by other users of the broadcast service. Additionally or alternatively, a timestamp of the current time, such as the current value of a TSF timer, may be included.

[0151] The broadcast control subfield 1244 may be included in the eBCS N field, for example, if the broadcast control present subfield is set to 1 in the broadcast information control subfield 1220. The broadcast control subfield 1244 may be used to indicate the negotiation method to be used to negotiate the initialization, control, or termination of a broadcast service. The broadcast control subfield 1244 may include one or more of the following values: a value via a broadcast service request frame, a value via an ANQP / GAS broadcast service request frame, and / or a value via an IP request (in which case the IP version and IP addresses required for negotiation may be included).

[0152] In some implementations, any subset of the fields or subfields of an eBCS service capability element or an eBCS service advertisement frame may be implemented in any field or subfield or set or subset of fields of an existing or newly designed element or frame, or the PHY and / or MAC header of any management, control, and data frame, or other header, or other frame.

[0153] Some implementations include an eBCS service request frame format. In some implementations, the eBCS service request frame format may be defined as follows: An eBCS service request frame may include an eBCS service request element. Such an eBCS service request element may also be included in other frames, such as, for example, a probe request frame, an association request frame, an ANQP / GAS eBCS service request frame, or any other type of frame, to request one or more eBCS services.

[0154] 13 is a bitmap diagram illustrating an example format of an eBCS service request element. As shown in FIG. 13, in some implementations, the eBCS service request element may include one or more of an element ID 1302, a length 1304, an element ID extension 1306, a number of broadcast services fields 1308, and / or one or more of a broadcast services field 1310.

[0155] The element ID field 1302, length field 1304, and element ID extension field 1306 may be used to indicate that the current element is an eBCS service request element and the length of the current element.

[0156] The number of broadcast service fields field 1308 may indicate the number of broadcast service fields the element contains.

[0157] In one or more of the broadcast service fields 1310, each of the broadcast service fields 1310 contains information of the particular broadcast service being requested and may include a broadcast service information control field subfield 1312, a broadcast service ID subfield 1314, a higher layer destination address subfield 1316, a title length subfield 1318, a title subfield 1320, a requested duration subfield 1322, and / or a requested parameters subfield 1324.

[0158] The broadcast service information control field 1312 may be one byte long and may include an indication of whether specific broadcast information is included in the broadcast service field 1310. The broadcast service ID subfield 1314 may be one byte long and may be used to indicate an identifier for the broadcast service. The upper layer destination address subfield 1316 may be variable bit length depending on the value indicated in the upper layer protocol field of the broadcast service information control subfield 1312. If IPv4 / UDP or IPv6 / UDP is indicated in the upper layer protocol subfield, the upper layer destination address subfield 1316 may include an IP address and a UDP port. If a MAC address is indicated in the upper layer protocol subfield, it may include a 6-byte MAC address. If the upper layer protocol subfield 1316 indicates that the upper layer destination address field is not present, then no upper layer destination address is included in the broadcast service field.

[0159] The Title Length subfield 1318 may be included in the Broadcast Service field 1310 if the Title Present subfield in the Broadcast Service Information Control subfield is set to 1, otherwise it is not present. The Title Length field 1318 may be 1 byte long and indicates the length of the Title field. The Title Subfield 1320 may be included in the Broadcast Service field if the Title Present subfield 1406 in the Broadcast Service Information Control subfield 1312 is set to 1, otherwise it is not present. The Title Length subfield 1318 may be 1 byte long and indicates the length of the Title subfield 1320. The Title subfield may be variable byte long.

[0160] The requested duration subfield 1322 may be 1 byte long and may be used to indicate the requested duration of the requested broadcast service. The requested parameters subfield 1324 may be 1 byte long and may indicate requested parameters of the requested broadcast service, such as a time offset compared to a fixed time reference point (e.g., TBTT), channel, RU resource, band, broadcast rate, etc.

[0161] 14 is a diagram illustrating an example format of the broadcast service information control field subfield 1312. The broadcast service information control field subfield 1312 may include a broadcast service ID present subfield 1402, a higher layer protocol 1404 subfield, a title present subfield 1406, a requested duration present subfield 1408, and a requested parameters present subfield 1410. The broadcast service information control field subfield 1312 may also have a reservation subfield 1412.

[0162] The Broadcast Service ID Present subfield 1402 may be one bit long and may indicate whether a Broadcast Service ID is included in the Broadcast Service field 1310. The Upper Layer Protocol subfield 1404 may be three bits long and may indicate one of the following values: no upper layer destination address is present, no upper layer destination address is present, and / or an upper layer destination address is present in the Broadcast Service field 1310. The Upper Layer Protocol subfield 1404 may include UDP / IPv4, UDP / IPv6, UDP / hostname, MPEG transport stream identifier, and / or MAC address. The Title Present subfield 1406 may be one bit long and may be used to indicate whether a user-readable title is present in the Broadcast Service field 1310. If the Title Present bit is set to 1, then the Title Length subfield and the Title subfield may be included in the Broadcast Service field 1310. Negotiation Method Present subfield: This subfield may be one bit long and may be used to indicate whether a Negotiation Method subfield is included in the Broadcast Service field.

[0163] The requested duration present subfield 1408 may be one bit long and may indicate whether a requested duration of the requested broadcast service is present in the broadcast services field 1310. The requested parameters present subfield 1410 may be one bit long and may indicate whether a requested parameter of the requested broadcast service is present in the broadcast services field 1310.

[0164] In some implementations, any subset of the fields or subfields of the eBCS service request element may be implemented in any field or subfield or set or subset of fields of an existing or newly designed element or frame, or the PHY and / or MAC header of any management, control, and data frame, or other header, or other frame, such as an EBCS request frame.

[0165] Some implementations include an eBCS service response frame format. In some implementations, the eBCS service response frame format may be as follows: The eBCS service response frame may include an eBCS service response element. Such an eBCS service response element may also be included in other frames, such as a probe response frame, an association response frame, an ANQP / GAS eBCS service response frame, or any other type of frame that responds to one or more eBCS service requests.

[0166] 15 is a bitmap diagram illustrating an example format of an eBCS service response element. In some implementations, the eBCS service response element may include an element ID field 1502, a length field 1504, an element ID extension field 1506, one or more of a number of broadcast service fields field 1508, and / or one or more broadcast service fields fields 1510.

[0167] The element ID field 1502, the length field 1504, and the element ID extension field 1506 may indicate that the current element is an eBCS service response element and the length of the current element. The number of broadcast service fields 1510 may indicate the number of broadcast service fields the element contains.

[0168] One or more of the broadcast service fields 1510 may each contain response information for the particular broadcast service being requested and may include one or more of a broadcast service information control field 1512, a broadcast service ID field 1514, an upper layer destination address subfield 1516, a title length field 1518, a title field 1520, a status field 1522, a broadcast service duration field 1524, and / or a broadcast service parameters field 1526.

[0169] The broadcast service information control field 1512 may be one byte long and may contain an indication of whether particular broadcast information is included in the broadcast service field 1510.

[0170] Figure 16 illustrates an example format of the broadcast service information control subfield 1512. As shown in Figure 16, the broadcast service information control field 1512 may include a broadcast service ID present subfield 1602, a higher layer protocol subfield 1604, a title present subfield 1606, a broadcast service duration present subfield 1608, a broadcast service parameters present subfield 1610, and / or a reservation subfield 1612.

[0171] The Broadcast Service ID Present subfield 1602 may be 1 bit long and may indicate whether a Broadcast Service ID is included in the Broadcast Service field. The Upper Layer Protocol subfield 1604 may be 3 bits long and may indicate, for example, one of the following values: no upper layer destination address is present, an upper layer destination address is present in the Broadcast Service field (the upper layer protocol may be and / or may be indicated as UDP / IPv4, UDP / IPv6, UDP / hostname, MPEG Transport Stream Identifier, MAC address, and / or reserved).

[0172] The title present subfield 1606 may be one bit long and may indicate whether a user-readable title is present in the broadcast services field 1510. If the title present bit is set to 1, then the title length subfield 1518 and the title field 1520 may be included in the broadcast services field 1510.

[0173] The broadcast service duration present subfield 1608 may be one bit long and may indicate whether a broadcast service duration for the provided broadcast service is present in the broadcast service field 1510. The broadcast service parameters present subfield 1610 may be one bit long and may indicate whether broadcast service parameters for the requested broadcast service are present in the broadcast service field 1510.

[0174] 15, the Broadcast Service ID field 1514 may indicate an identifier of a broadcast service and may be one byte long. The Upper Layer Destination Address subfield 1516 may have a different length depending on, for example, the value indicated in the Upper Layer Protocol field of the Broadcast Service Information Control subfield. If IPv4 / UDP or IPv6 / UDP is indicated in the Upper Layer Protocol subfield 1604, the Upper Layer Destination Address subfield 1516 may include an IP address and a UDP port. The Upper Layer Destination Address subfield 1516 may include, for example, a 6-byte MAC address if, for example, a MAC address is indicated in the Upper Layer Protocol subfield 1604. For example, if the Upper Layer Protocol subfield indicates that the Upper Layer Destination Address field is not present, then the upper layer destination address may not be included in the Broadcast Service field 1510. If the Title Present subfield 1606 in the Broadcast Service Information Control subfield 1512 is set to 1, then the Title Length subfield 1518 may be included in the Broadcast Service field 1510 and may not be present otherwise. The Title Length field 1518 may be one byte long and may indicate the length of the Title subfield 1520. For example, if the Title Present subfield in the Broadcast Services Information Control subfield 1512 is set to 1, the Title subfield 1520 may be included in the Broadcast Services field 1510, and may not be present otherwise.

[0175] The Status subfield 1522 may indicate whether the request for the broadcast service was successful. The Status subfield may also include a reason for the rejection if the request was rejected. The Broadcast Service Duration subfield may indicate the duration of the provided broadcast service. The Broadcast Service Parameters subfield may indicate parameters of the provided broadcast service, such as time offset compared to a fixed time reference point (e.g., TBTT), channel, RU resources, band, broadcast rate, etc.

[0176] In some implementations, any subset of the fields or subfields of the eBCS Service Response element may be implemented in any field or subfield or set or subset of fields of an existing or newly designed element or frame, or in the PHY and / or MAC headers of any management, control, and data frame, or other header, or other frame, such as an EBCS request frame.

[0177] Some implementations include an eBCS service request / response procedure. Some implementations include an eBCS service request / response procedure for unassociated STAs. In some implementations, an eBCS service negotiation procedure for unassociated STAs may be as follows:

[0178] In some implementations, an AP may advertise one or more broadcast services using a broadcast service element, for example, in a beacon, a probe response, an eBCS service advertisement frame, an eBCS information frame, etc., and / or simply using a probe response, an eBCS service advertisement frame, an eBCS information frame, or an EBCS termination notification frame, etc. The AP may indicate how to negotiate one or more eBCS services, such as via an ANQP / GAS frame exchange, via a probe request frame exchange, via an eBCS service request / response frame, or via an IP packet.

[0179] An unassociated STA may discover a desired broadcast service after receiving a frame such as an EBCS information frame, an EBCS termination notification frame, or an EBCS ANQP service frame from an AP, or from pre-acquired knowledge, or through an ANQP / GAS frame exchange from one or more APs. One or more broadcast services that an AP can provide but does not currently provide, and that do not require association, may be requested by the STA. The STA may follow a negotiation method, for example, as indicated by the AP for its eBCS service, and may send a frame, for example, an ANQP / GAS broadcast service request frame, or a public action frame containing an eBCS service request element or information, to the AP. The requested broadcast service may be indicated by a specific ID, such as a broadcast service ID, a higher layer destination address, a MAC address, a title, etc. If a broadcast service is requested, the STA may request the broadcast service for a specific period of time, for example, the STA may request video playback for 10 minutes. The STA may also request specific parameters of the broadcast service on a specific channel or RU, such as the broadcast frequency, the data rate to be used, etc.

[0180] The AP may respond to the eBCS service request by sending an eBCS response frame, or an ANQP / GAS eBCS service response frame, or a frame containing an eBCS service response frame or information. The AP may indicate the status of the request for one or more eBCS services, such as success or rejection, and may include a reason for the rejection if the request is rejected. The AP may indicate the remaining time of the broadcast service it is providing. For example, the AP may include a broadcast service duration in the eBCS service response element, or may include, for example, an end of broadcast service announcement element periodically in one or more of the frames it is transmitting, such as, for example, a beacon frame, a probe response frame, an eBCS data frame, a broadcast service request frame, an eBCS service advertisement frame, or an eBCS information frame. The AP may also include broadcast service parameters, such as broadcast frequency, data rate to be used, on a particular channel or RU, if the request for the eBCS service is successful. The AP may then start providing the requested eBCS service accordingly.

[0181] Some implementations include an eBCS service request / response procedure for associated STAs. In some implementations, an eBCS service negotiation procedure for associated STAs may be as follows: An AP may advertise one or more broadcast services using a broadcast service element, e.g., in a beacon, a probe response, an eBCS service advertisement frame, an eBCS information frame, etc., and / or simply using a probe response, an eBCS service advertisement frame, an eBCS information frame, an EBCS termination notification frame, etc. An AP may indicate a negotiation method for one or more eBCS services, e.g., via an ANQP / GAS frame exchange, via a probe request frame exchange, via an eBCS service request / response frame, and / or via an IP packet. An AP may indicate for one or more eBCS services that association is required to utilize those eBCS services.

[0182] A STA may discover a desired broadcast service after receiving a frame, such as an EBCS information frame, an EBCS termination notification frame, or an EBCS ANQP service frame, from an AP, or from pre-acquired knowledge and / or through an ANQP / GAS frame exchange from one or more APs. One or more broadcast services that require association that the AP can provide but does not currently provide may be requested by the STA. If the STA is not currently associated with the AP, the STA may perform authentication and association with the AP. The STA may follow a negotiation method indicated by the AP for its eBCS service and may send a frame, such as an eBCS service request frame, or a frame containing an eBCS service request element or information, to the AP, which may also be included in a probe request frame and / or an association request frame. The requested broadcast service may be indicated by a specific ID, such as a broadcast service ID, a higher layer destination address, a MAC address, a title, etc. If a broadcast service is requested, the STA may request the broadcast service for a specific period of time. For example, the STA may request video playback for 10 minutes. The STA may also request specific parameters of the broadcast service on a particular channel or RU, such as the broadcast frequency, the data rate to be used, etc.

[0183] The AP may respond to the eBCS service request by transmitting an eBCS response frame, or an eBCS response frame including a probe response and association response frame, or a frame including information. If the eBCS service requires association, the AP may not start the eBCS (Enhanced Broadcast Service) service before the STA is fully associated with the AP. The AP may indicate the status of one or more eBCS service requests, e.g., successful, rejected, etc., and may include a reason for the rejection. The AP may indicate the remaining time of the broadcast service it is providing. For example, the AP may include a broadcast service duration in the eBCS service response element, or may include an end of broadcast service announcement element, e.g., periodically, in one or more of the frames it is transmitting, e.g., in a beacon frame, a probe response frame, an eBCS data frame, a broadcast service request frame, an eBCS service advertisement frame, or an eBCS information frame, an EBCS end notification frame, etc. The AP may also include broadcast service parameters, such as broadcast frequency, broadcast period duration, data rate to be used, etc., on a particular channel or RU if the eBCS service request is successful. The AP may then start providing the requested eBCS service accordingly.

[0184] Some implementations include an eBCS service request / response procedure for receive-only STAs. In some implementations, the eBCS service negotiation procedure for receive-only STAs is as follows: In some implementations, the AP may advertise one or more broadcast services using a broadcast service element in a beacon, probe response, eBCS service advertisement frame, eBCS information frame, etc., and / or simply using a probe response, eBCS service advertisement frame, eBCS information frame, etc. The AP may indicate a negotiation method for one or more eBCS services, such as via an ANQP / GAS frame exchange, via a probe request frame exchange, via an eBCS service request / response frame, and / or via an IP packet. The AP may indicate for one or more eBCS services that association is required to utilize those eBCS services.

[0185] A STA may discover a desired broadcast service after receiving a frame, such as an EBCS information frame, an EBCS termination notification frame, or an EBCS ANQP service frame, from an AP, or from pre-acquired knowledge and / or by overhearing an ANQP / GAS frame exchange from one or more APs. One or more broadcast services that require uplink transmission or association may not be requested by a receive-only STA. A receive-only STA may follow a negotiation method as indicated by the AP for that eBCS service, e.g., send an IP packet to an advertised IP address containing an eBCS service request element or information over a different network interface.

[0186] If the request is successful, the AP may begin providing the requested eBCS service accordingly. The AP may indicate the remaining time of the broadcast service it is providing. For example, the AP may include an end of broadcast service announcement element in one or more of the frames it is transmitting (e.g., in a beacon frame, a probe response frame, an eBCS data frame, a broadcast service request frame, an eBCS service advertisement frame, an EBCS end notification frame, and / or an eBCS information frame, etc.), e.g., periodically.

[0187] Although the features and elements of the various embodiments above have been described in particular combinations, each feature or element may be used alone without other features and elements of the preferred embodiments, or may be used in various combinations with or without other features and elements of the present invention. It is understood that although the solutions described herein take into account the 802.11 specification protocols, the solutions described herein are not limited to this scenario and may also be applicable to other wireless systems.

[0188] Although xIFS and / or SIFS are used to illustrate various interframe spacings in the design and procedural examples, any other interframe spacing such as RIFS, AIFS, DIFS, or other agreed upon time intervals may be applied to the same solution. Four RBs per triggered TXOP is shown as an example in some figures, but the actual number of RBs / channels / bandwidth utilized may vary.

[0189] FIG. 17 illustrates an example method 1700 of a STA requesting continuation of an eNCS service. In step 1702, the STA may first receive an eBCS termination notification frame from an access point (AP) indicating that the eBCS service that the STA is consuming will be terminated. In step 1704, the STA may negotiate for continuation of the eBCS service, provided that the termination is not permitted. Then, in step 1706, upon successfully negotiating continuation of the eBCS service, the STA may continue receiving the eBCS service. It should be noted that the various steps described with respect to method 1700 are merely examples, and other implementations may omit some of these steps, include additional steps, or perform these steps in a different order.

[0190] Although the features and elements are described above in certain combinations, one skilled in the art will understand that each feature or element may 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 electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. 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 in association with software may 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 implemented in a station (STA), comprising: receiving an enhanced broadcast service (eBCS) termination notification frame from an access point (AP), the eBCS termination notification frame indicating that an eBCS service being consumed by the STA is to be terminated; negotiating with the AP for continuation of the enhanced broadcast service (eBCS) service consumed by the STA based on the received eBCS termination notification frame indicating that the eBCS service consumed by the STA is to be terminated; continuing to receive the eBCS service that the STA is consuming based on the negotiating; and A method comprising:

2. 2. The method of claim 1, wherein the enhanced broadcast service (eBCS) termination notification frame further includes a time to end subfield indicating a number of target beacon transmission times (TBTTs) until the eBCS service that the STA is consuming is terminated.

3. The method of claim 1 , wherein the enhanced broadcast service (eBCS) termination notification frame includes a category field, a public action field, and an eBCS termination information set field.

4. negotiating with the AP for the continuation of the eBCS service; receiving from the AP a negotiation method subfield for negotiating an extension of the eBCS service being consumed by the STA; The method of claim 1 further comprising:

5. The method of claim 4 , wherein the negotiation method subfield is included in the enhanced broadcast service (eBCS) termination notification frame.

6. The method of claim 5 , wherein the negotiation method subfield indicates that negotiation is not available.

7. The method of claim 5 , wherein the negotiation method subfield indicates that the STA negotiates via one or more eBCS service request frames.

8. 6. The method of claim 5, wherein the negotiation method subfield indicates that the STA negotiates via one or more Access Network Query Protocol (ANQP) eBCS Service Request frames.

9. The method of claim 5 , wherein the negotiation method subfield indicates that the STA negotiates via an IP request.

10. A station (STA), a receiver configured to receive an enhanced broadcast service (eBCS) termination notification frame from an access point (AP), the eBCS termination notification frame indicating that an eBCS service consumed by the STA is to be terminated; and a processor and a transmitter configured to negotiate with the AP for continuation of the eBCS service consumed by the STA based on the received enhanced broadcast service (eBCS) termination notification frame indicating that the eBCS service consumed by the STA will be terminated. The station (STA), wherein the receiver is further configured to continue receiving the eBCS service that the STA is consuming based on the negotiating.

11. 11. The STA of claim 10, wherein the enhanced broadcast service (eBCS) termination notification frame further includes a time to end subfield indicating a number of target beacon transmission times (TBTTs) until the eBCS service that the STA is consuming is terminated.

12. The STA of claim 10 , wherein the enhanced broadcast service (eBCS) termination notification frame includes a category field, a public action field, and an eBCS termination information set field.

13. The STA of claim 10 , wherein the receiver is further configured to receive from the AP a negotiation method subfield for negotiating an extension of the eBCS service that the STA is consuming.

14. The STA of claim 13 , wherein the negotiation method subfield is included in the enhanced broadcast service (eBCS) termination notification frame.

15. The STA of claim 14 , wherein the negotiation method subfield indicates that negotiation is not available.

16. The STA of claim 14 , wherein the negotiation method subfield indicates that the STA negotiates via one or more eBCS service request frames.

17. 15. The STA of claim 14, wherein the negotiation method subfield indicates that the STA negotiates via one of more Access Network Query Protocol (ANQP) eBCS Service Request frames.

18. The STA of claim 14 , wherein the negotiation method subfield indicates that the STA negotiates via an IP request.

Images