Power-efficient broadcasting in WLAN

Abstract

To provide a method for a station (STA) to negotiate continuity upon termination of an enhanced broadcast service (eBCS).SOLUTION: In a communication system, a STA receives an eBCS notification frame indicating that an eBCS service is to be terminated, and negotiates with an access point (AP) for continuation of the eBCS service when the termination of the eBCS service consumed by the STA is not acceptable, and continues to receive the eBCS service consumed by the STA.SELECTED DRAWING: Figure 17

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 on February 7, 2020, and U.S. Provisional Patent Application No. 63 / 042,059, filed on June 22, 2020, the contents of which are incorporated herein by reference.

Background Art

[0002] An infrastructure Basic Service Set (BSS) mode WLAN 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 sensor non - AP STAs. The enhanced broadcast service may be provided to both STAs associated with a particular AP and those not associated with it. Some exemplary 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.

Summary of the Invention

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

Brief Description of the Drawings

[0004] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals in the figures indicate like elements.

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

DETAILED DESCRIPTION OF THE INVENTION

[0005] FIG. 1A is a diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a plurality of access systems that provide content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication 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 filter type OFDM, filter bank multicarrier (FBMC).

[0006] As shown in Figure 1A, the communication system 100 can 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 is understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can 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, which may all be referred to as stations (STAs), can be configured to transmit and / or receive wireless signals and can include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscriber-based units, pocket bells, cellular telephones, 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 an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d can also be referred to interchangeably as a UE.

[0007] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as CN 106, the Internet 110, and / or other network 112. By way of example, base stations 114a, 114b may be next generation NodeBs such as a base transceiver station (BTS), NodeB, eNode B (eNode B, eNB), home Node B, home eNode B, gNode B (gNode B, gNB), new radio (NR) NodeB, site controller, access point (AP), wireless router, etc. Although base stations 114a, 114b are each shown as a single element, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0008] Base station 114a may be part of RAN104, which may also include other base stations such as a base station controller (BSC), a radio network controller (RNC), a relay node, and / or network elements (not shown). Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals at one or more carrier frequencies that 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 to a specific geographic area that may be relatively fixed or may change over time. A cell may further be divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, base station 114a may utilize multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0009] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via 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.). Air interface 116 may be established using any suitable radio access technology (RAT).

[0010] More specifically, as described above, the communication system 100 can be a multiple access system and can adopt one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a of RAN104 and WTRU102a, 102b, 102c can establish the air interface 116 using wideband CDMA (WCDMA), and can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can 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 WTRU102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can 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 WTRU102a, 102b, 102c can implement radio technologies such as NR radio access, which can 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, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technology transmitted to / from multiple types of base stations (e.g., eNBs and gNBs) and / or transmissions.

[0014] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE802.11 (i.e., Wireless Fidelity (WiFi)), IEEE802.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), etc.

[0015] The base station 114b in 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 connection in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (e.g., for use by a drone), a road, or other locations. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a wireless 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 wireless 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 pico cell or a femto cell. As shown in Fig. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 in some cases.

[0016] RAN 104 can communicate with CN 106, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of 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. CN 106 can provide call control, billing services, mobile location-based services, prepaid calls, 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 RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs using the same RAT or a different RAT as RAN 104. For example, in addition to being connected to RAN 104, which may utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0017] CN106 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 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 network 112 may include wired and / or wireless communication networks that are owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs that may use the same or a different RAT as the RAN 104.

[0018] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include multimode capabilities (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A may be configured to communicate with a base station 114a that may use a cellular-based wireless technology and a base station 114b that may use IEEE802 wireless technology.

[0019] Figure 1B is a system diagram illustrating an exemplary WTRU102. As shown in Figure 1B, the WTRU102 can 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, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU102 can include any partial combination of the foregoing elements while remaining consistent with one embodiment.

[0020] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), a plurality of 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 can perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can 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) via 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 signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0022] Although the transmit / receive element 122 is shown in FIG. 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 via 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 noted 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 can be coupled to the speaker / microphone 124, keypad 126, and / or display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit), and can receive user input data therefrom. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Further, the processor 118 can access information from and store data in any suitable type of memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 can access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0025] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 can include one or more dry cells (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, a fuel cell, and the like.

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

[0027] The processor 118 may further be coupled to other peripheral devices 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), 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 / Augmented Reality (VR / AR) device, an activity tracker, etc. The peripheral devices 138 may include one or more sensors. The sensors 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 geographical location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0028] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (associated with certain subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) can 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., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of the signals (associated with a certain subframe for either UL (e.g., for transmission) or DL (e.g., for reception)).

[0029] FIG. 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 may communicate with WTRU102a, 102b, 102c via air interface 116 using E-UTRA radio technology. RAN104 may also communicate with CN106.

[0030] RAN104 may include eNode-Bs 160a, 160b, 160c, although it will be understood that RAN104 may include any number of eNode-Bs while remaining consistent with one embodiment. Each of eNode-Bs 160a, 160b, 160c may include one or more transceivers for communicating with WTRU102a, 102b, 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, eNode-B 160a may transmit a wireless signal to and / or receive a wireless signal from WTRU102a, for example, using multiple antennas.

[0031] Each of eNode-Bs 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. in the UL and / or DL. As shown in FIG. 1C, eNode-Bs 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0032] CN 106 shown in FIG. 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 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] MME 162 can be connected to each of eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can function as a control node. For example, MME 162 can authenticate WTRUs 102a, 102b, 102c, bearer active / inactive users, and can play a role in selecting a specific serving gateway during the initial attach of WTRUs 102a, 102b, 102c. MME 162 can provide control plane functions for switching between RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0034] SGW164 can be connected to each of eNode Bs 160a, 160b, and 160c in RAN104 via the S1 interface. SGW164 can generally route and transfer user data packets to / from WTRUs 102a, 102b, and 102c. SGW164 can perform other functions such as the function of anchoring the user plane during handover between eNode Bs, the function of triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and the function of managing and storing the contexts of WTRUs 102a, 102b, and 102c.

[0035] SGW164 can be connected to PGW166, and PGW166 can provide WTRUs 102a, 102b, and 102c with access to a packet switched network such as the Internet 110 in order to facilitate communication between WTRUs 102a, 102b, and 102c and IP - compliant devices.

[0036] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRUs 102a, 102b, and 102c with access to a circuit - switched network such as PSTN108 in order to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, CN106 can include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. Further, CN106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112 that can include other wired and / or wireless networks owned and / or operated by other service providers.

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

[0038] In a representative embodiment, the other network 112 can be a WLAN.

[0039] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP can have an 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 an STA originating from outside the BSS can reach and be delivered to the STA through the AP. Traffic from an STA to a destination outside the BSS can be sent to the AP and then sent to each destination. Traffic between STAs within the BSS can be transmitted, for example, via the AP. The source STA can send the traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be regarded as and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted in a direct link setup (DLS) between the source STA and the destination STA (e.g., directly between them). In certain representative embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) can communicate directly with each other. The IBSS mode of communication can be referred to herein as the "ad hoc" communication mode.

[0040] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel such as the primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STA 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. In the case of CSMA / CA, STAs including the AP (e.g., all STAs) may sense the primary channel. If the primary channel is sensed / detected as busy and / or determined to be busy by a particular STA, the particular STA may back off. Only one STA (e.g., only one station) may transmit at any given time in a given BSS.

[0041] A High Throughput (HT) STA may form a 40 MHz wide channel for communication, for example, through a combination of an adjacent or non - adjacent 20 MHz channel with the primary 20 MHz channel.

[0042] A Very High Throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 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. In the case of the 80 + 80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. The Inverse Fast Fourier Transform (IFFT) process 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] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine-type communications (MTC) such as MTC devices in a macro coverage area. The MTC device may have limited capabilities including, for example, support for a specific and / or limited bandwidth (e.g., support only therefor). The MTC device may include a battery having a battery life exceeding a threshold (e.g., to maintain a very long battery life).

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

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

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

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

[0048] WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using transmissions associated with an expandable numerology. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using sub-frames or transmission time intervals (TTIs) of various or expandable lengths (e.g., including various numbers of OFDM symbols and / or varying lengths of absolute time durations).

[0049] gNBs 180a, 180b, and 180c may be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c, etc.). In a stand-alone configuration, WTRUs 102a, 102b, and 102c may utilize one or more of gNBs 180a, 180b, and 180c as a mobility anchor point. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c may implement a DC principle for communicating with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNode-Bs 160a, 160b, and 160c may function as a mobility anchor for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c may provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0050] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, DC, interaction 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, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0051] CN 106 shown in FIG. 1D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although the foregoing elements are shown as part of CN 106, it will be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

[0052] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can perform functions such as user authentication of WTRUs 102a, 102b, and 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selection of the SMFs 183a and 183b for registration, management of the registration area, termination of non-access stratum (NAS) signaling, and mobility management. Network slicing can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of service being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for switching between RAN 104 and other RANs (not shown) that use other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

[0053] SMF183a and 183b can be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN106 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic passing through UPF184a and 184b. SMF183a and 183b can perform other functions such as the function of managing and allocating UE IP addresses, the function of managing PDU sessions, the function of implementing policies and controlling QoS, and the function of providing DL data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0054] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c in RAN104 via the N3 interface, which can provide access to a packet-switched network such as the Internet 110 to WTRU102a, 102b, and 102c to facilitate communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 and 184b can perform other functions such as packet routing and forwarding, implementation of user plane policies, support for multi-home PDU sessions, processing of user plane QoS, buffering of DL packets, and mobility anchoring.

[0055] CN106 may facilitate communication with other networks. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and the PSTN108. Further, CN106 may provide access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers, to the WTRU102a, 102b, 102c. In one embodiment, the WTRU102a, 102b, 102c may be connected to the local DN185a, 185b through the UPF184a, 184b via an N3 interface to the UPF184a, 184b and an N6 interface between the UPF184a, 184b and the DN185a, 185b.

[0056] In view of FIGS. 1A - 1D and the corresponding descriptions of FIGS. 1A - 1D, one or more or all of the functions described herein with respect to one or more of the WTRU102a - d, base stations 114a - b, eNode - B160a - c, MME162, SGW164, PGW166, gNB180a - c, AMF182a - b, UPF184a - b, SMF183a - b, DN185a - b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0057] An emulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more emulation devices can be fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network and / or execute one or more or all functions while being deployed. One or more emulation devices can execute one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. An emulation device can be directly coupled to another device for the purpose of testing and / or executing tests using over-the-air wireless communication.

[0058] One or more emulation devices can execute one or more functions including all while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or a non-deployed (e.g., for testing) wired and / or wireless communication network to implement tests of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which can include one or more antennas) can be used by an emulation device 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 an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic to an STA originating from outside the BSS can reach the STA through the AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS is sent to the AP and can be sent to each destination. Traffic between STAs within the BSS can be sent via the AP, where the source STA sends the traffic to the AP and the AP delivers the traffic to the destination STA. Such traffic between STAs within the BSS can be regarded as peer-to-peer traffic. Such peer-to-peer traffic can also be sent directly between the source STA and the destination STA in a direct link setup (DLS) using, for example, 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using 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 the "ad hoc" communication mode.

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

[0061] In 802.11n, a high throughput (HT) STA may also use a 40 MHz wide channel for communication. This can be achieved by combining a primary 20 MHz channel with an adjacent 20 MHz channel to form a continuous 40 MHz wide channel.

[0062] In 802.11ac, a very high throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and 160 MHz wide channels. The 40 MHz and 80 MHz channels can be formed by combining consecutive 20 MHz channels similar to the above 802.11n. The 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non - consecutive 80 MHz channels, also 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 can be performed separately for each stream, and then the streams can be mapped to two channels and the data can be transmitted. At the receiver, this mechanism is reversed and the combined data is transmitted to the MAC.

[0063] The sub - 1 GHz operating mode 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 the TV white space (TVWS) spectrum, and 802.11ah may support 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the 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] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah may include a channel designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS, but not necessarily. The bandwidth of the primary channel can thus be limited by an STA among all STAs operating in a BSS that supports the minimum bandwidth operation mode. In the example of 802.11ah, the primary channel can be 1 MHz wide if there is an STA (e.g., an MTC type device) that supports only the 1 MHz mode even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, or other channel bandwidth operation modes. All carrier sensing and NAV setting can depend on the status of the primary channel. That is, for example, if the primary channel is busy due to an STA that supports only the 1 MHz operation mode transmitting to the AP, the entire available frequency band can be considered busy even though most of it remains idle and may be available.

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

[0066] IEEE802.11 (trademark) High Efficiency WLAN (HEW) may include corrections to enhance the quality of service experienced by all wireless users in a wide range of usage scenarios, including high-density scenarios in the 2.4 GHz, 5 GHz, and 6 GHz bands. New use cases that support high-density deployments of APs and STAs, as well as related Radio Resource Management (RRM) techniques, may be considered.

[0067] Potential uses of HEW may include new usage scenarios such as data distribution for stadium events, railway stations, or enterprise / retail environments, as well as high-user-density scenarios such as evidence of increasing dependence on video distribution, and wireless services for medical applications.

[0068] Measured traffic for various applications is likely to consist of short packets, and network applications may also generate short packets. Such applications may include virtual offices, transmit power control (TPC) acknowledgements (ACKs), video streaming ACKs, device / controllers (such as mice, keyboards, game controls), access-probe requests / responses, network selection-probe requests, Access Network Query Protocol (ANQP), and / or network management-control frame applications.

[0069] 802.11ax may include MU features, including UL OFDMA and DL OFDMA, as well as 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 can address media access issues in the 6 GHz band by, for example, using media access that is triggered or scheduled only in the 6 GHz band and / or by actively scanning for and using Enhanced Distributed Channel Access (EDCA) media access scheduled in the 6 GHz band without limitation.

[0071] IEEE 802.11bc may include MAC revisions for the enhanced broadcast service (eBCS) for 802.11 devices. The IEEE 802.11bc revision may not affect the current IEEE 802.11 PHY specifications.

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

[0073] Some exemplary 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, the eBCS AP may provide a broadcast service to STAs that are or are not associated with the AP. Since broadcast frames may not be acknowledged, it is not always clear whether there are STAs that utilize the broadcast service and receive broadcast data. If broadcast data is not received, the AP consumes both power and wireless medium resources. Some implementations provide a broadcast service mechanism that facilitates a power-efficient broadcast service and may only provide the broadcast service when the service is actively consumed and / or when.

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

[0076] Some implementations provide an end to the broadcast service announcement information element. In some implementations, the AP may transmit a frame that includes the end of the broadcast service announcement frame or the end of the broadcast service announcement information element to indicate that one or more eBCS services have ended.

[0077] The exemplary values for the various fields and sub - fields considered in this specification are provided for illustration purposes only, and it should be noted that in other implementations, any other suitable values may be used to indicate the same information or different information. For example, in some implementations, a bit value of 1 within a field may indicate certain information, while a bit value of 0 within the field may indicate the same information.

[0078] Figure 2 is a bitmap diagram illustrating an exemplary format for the end of a broadcast service announcement information element. The end of a broadcast service announcement information element may include one or more of the fields of element identifier (ID) 202, length 204, and element ID extension 206, broadcast service field count 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 a broadcast service announcement information element and may indicate the length of the current element. The broadcast service field count 208 may indicate the number of broadcast service fields included in the element. 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] One or more broadcast service fields 210 may have a format as shown in FIG. 2 and may include one or more of the following fields: a broadcast service information control field 212, a broadcast service ID field 214, an upper layer destination address field 216, a title length field 218, a title field 220, an end time field 222, and / or a negotiation method field 224. The broadcast service information control field 212, the broadcast service ID field 214, the title length field 218, the end time field 222, and the negotiation method field 224 may be 1 byte in length, and the upper layer destination address field 216 and the title field may be of variable byte length.

[0080] FIG. 3 is a bitmap diagram illustrating an exemplary format of the broadcast service information control field 212. The broadcast service information control field 212 may be 1 byte in length and may include an indication as to whether specific 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 presence subfield 302, an upper layer protocol subfield 304, a title presence subfield 306, a negotiation method presence subfield 308, an association request subfield 310, and a reservation subfield 312.

[0081] The Broadcast Service ID Presence Subfield 302 can be 1 bit long and can indicate whether a Broadcast Service ID is included in the Broadcast Service Field. The Upper Layer Protocol Subfield 304 can be 3 bits long and can contain a value indicating whether an upper layer destination address does not exist or whether the upper layer destination address exists within the Broadcast Service Field 210, and can contain a value indicating that the upper layer destination address present in the Broadcast Service Field 2010 can be an address associated with one of the upper layer protocols UDP / IPv4, UDP / IPv6, UDP / Host Name; MPEG Transport Stream Identifier, MAC address, or Reserved.

[0082] The Title Presence Subfield 306 can be 1 bit long and can indicate whether a user-readable title exists in the Broadcast Service Field 210. When the Title Presence Subfield 306 bit is set to 1, the Title Length Subfield 218 and the Title Subfield 220 can be included in the Broadcast Service Field 210. The Negotiation Method Presence Subfield 308 can be 1 bit long and can indicate whether the Negotiation Method Subfield 224 is included in the Broadcast Service Field 210. The Association Request Subfield 310 can be 1 bit long and can indicate whether the broadcast service described by the current Broadcast Service Field 210 requires an association before it can be utilized by other STAs.

[0083] Referring back to FIG. 2, the broadcast service ID subfield 214 can be 1 byte in length and can indicate an identifier of the broadcast service. The upper layer destination address subfield 216 can take different lengths, for example, according to the value indicated in the upper layer protocol field of the broadcast service information control subfield. When IPv4 / UDP or IPv6 / UDP is indicated in the upper layer protocol subfield 304, the upper layer destination address subfield 216 can include an IP address and a UDP port.

[0084] The upper layer destination address subfield 216 can include a 6-byte MAC address when the MAC address is indicated in the upper layer protocol subfield 304. When the upper layer protocol subfield 304 indicates that there is no upper layer destination address field, the upper layer destination address may not be included in the broadcast service field 210.

[0085] When the title presence subfield 306 in the broadcast service information control subfield 212 is set to 1, the title length subfield 218 can be included in the broadcast service field 210, otherwise it may not exist. The title length subfield 218 can be 1 byte in length and can indicate the length of the title subfield 220.

[0086] When the title presence subfield 306 in the broadcast service information control subfield 212 is set to 1, the title subfield 220 can be included in the broadcast service field 210, otherwise it may not exist. The title length subfield 218 can be 1 byte in length and can indicate the length of the title subfield 220.

[0087] The time-to-end subfield 222 can be used to indicate the remaining time until the end of the broadcast service described in this broadcast service field 210, unless additional negotiation is performed by one or more STAs that can consume the broadcast service. In another example, the time-to-end subfield 222 can include a time, such as a timing synchronization function (TSF) time value, or another type of time, at which the broadcast service ends unless additional negotiation is performed by an initiator of the broadcast service or by another user of the broadcast service. Additionally or alternatively, a timestamp of the current time, such as the current value of the TSF timer, can be included.

[0088] The negotiation method subfield 224 can be included in the broadcast service field 210 if the negotiation method presence subfield 308 is set to 1 (or another suitable indicator). The negotiation method subfield can be used to indicate the negotiation method to be used to negotiate for the continuation of the broadcast service beyond the end time. The negotiation method subfield can 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 address required for the negotiation can be included).

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

[0090] Some implementation modes provide an eBCS service termination notification format. In some implementation modes, the eBCS service termination notification frame is transmitted by the STA that is the transmitter of the eBCS service, and announces the termination of one or more of the eBCS services transmitted by the STA, such as an AP or another STA.

[0091] FIG. 4 is a diagram illustrating an exemplary format of the 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 1 octet in length, and the eBCS service termination information set field 406 may be of variable length. In some implementation modes, the eBCS service termination information set field 406 includes one or more of the eBCS service termination information sub-fields 500.

[0092] FIG. 5 is a diagram illustrating an exemplary format of the eBCS service termination information sub-field 500. As shown in FIG. 5, the eBCS service termination information set field 406 may include one or more of an eBCS service termination information control sub-field 502, an eBCS service ID sub-field 504, a title length sub-field 506, a title sub-field 508, a time to end sub-field 510, a negotiation method sub-field 512, a negotiation address type sub-field 514, and / or a negotiation address sub-field 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 1 octet, while the title length subfield 506 and the negotiation method subfield 514 may have a length of 0 or 1 octet. The time until termination subfield 510 may have a length of 2 octets. The title subfield 508 and the negotiation address subfield 516 may have a variable octet length.

[0094] Figure 6 is a diagram illustrating an exemplary 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 an 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 an association is not 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 1 octet in length. In some implementations, the eBCS service ID subfield 504 indicates the ID of the eBCS service that is ending. In some implementations, the title length subfield 506 is 1 octet in length. In some implementations, the title length subfield 506 indicates the length of the title subfield 508 in octets. 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 to end subfield 510 is 2 octets in length. In some implementations, the time to end 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 ends. 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, the value 0 indicates that the eBCS service identified by the eBCS service ID within the same eBCS service ID subfield 504 does not have a specific end time. In some implementations, some other values, for example, the maximum value of the time to end subfield, indicate that the eBCS service identified by the eBCS service ID within the same eBCS service ID subfield 504 does not have a specific end time, or that the eBCS service identified by the eBCS service ID within the same eBCS service ID subfield 504 has an end time greater than the maximum value that can be included in the time to end subfield 510.

[0097] In some implementations, the negotiation method subfield 512 is 1 octet in length. 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 in Table 1 below. Other values may be used to indicate the same negotiation method as detailed in Table 1.

[0098] [Table 1]

[0099] In some implementations, the negotiation address type subfield 514 is 1 octet in length. In some implementations, the negotiation address type subfield 514 indicates the type of address included 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 the address used to negotiate an extension of 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 depend on the value included in the negotiation address type subfield 514. In some implementations, the negotiation address subfield 516 includes, for example, a MAC address when the negotiation address type is equal to 0.

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

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

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

[0105] FIG. 10 illustrates an exemplary format of the negotiation address subfield 516 when, for example, 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 in, for example, a UTF-8 format.

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

[0107] The AP can advertise the broadcast service using broadcast service elements, such as beacons, probe responses, eBCS service advertisement frames, and / or eBCS information frames. Some broadcast services can be specific allocated time and / or frequency resources. These time and frequency resources can be broadcast at specific intervals.

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

[0109] The AP may indicate the remaining time of the broadcast service it provides by including, for example, periodically, the end of the broadcast service announcement element in one or more of the frames it transmits (such as in beacon frames, probe response frames, eBCS data frames, broadcast service request frames, eBCS service advertisement frames, and / or eBCS information frames).

[0110] The AP may, for example, include the end of one or more broadcast service announcement elements in one or more of the frames it transmits (such as in beacon frames, probe response frames, eBCS data frames, broadcast service request frames, eBCS service advertisement frames, or eBCS information frames), indicating that one or more of the broadcast services it provides have ended at a given time. The AP may include the negotiation method required for any STA interested in continuing the broadcast beyond the indicated end time to negotiate the continuation of the broadcast service beyond the end time in order to execute the negotiation for the broadcast service. The AP may indicate that one or more of the broadcast services it provides are broadcast at a specific period before ending.

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

[0112] If a broadcast service requires an association (as indicated, for example, in an association request subfield) and the negotiation is via a broadcast service request frame, the STA may execute an association procedure with the AP. If the STA is already associated with the AP, the STA may send 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 over a particular period or at a particular period. The AP may respond with a broadcast service response frame indicating that the broadcast service will continue for a longer period and / or period. If a second STA desires the same broadcast service and the second STA receives a frame containing a broadcast service announcement element or the 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 an association (as indicated, for example, in the association request subfield), and the negotiation is via an ANQP / GAS broadcast service request frame, the STA may send an ANQP / generic advertisement service (GAS) broadcast service request frame indicating that it desires one or more broadcast services or registers for one or more broadcast services. The STA may indicate that it desires or registers for one or more broadcast services over a specific period. The AP may respond with an ANQP / GAS broadcast service response frame indicating that the broadcast service is to be continued for a longer period. If a second STA desires the same broadcast service and the second STA receives a frame including a broadcast service announcement element or the end of information indicating that the broadcast service has been extended, the second STA may cancel any pending ANQP / GAS broadcast service request frames that it planned to send to the AP.

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

[0115] Some implementations provide an eBCS service termination notification procedure. In some implementations, the eBCS service termination notification procedure enables the STA that is the broadcaster of the eBCS service to indicate that one or more eBCS services being broadcast are ending. In some implementations, the eBCS service termination notification procedure enables the STA that is the broadcaster of the eBCS service to indicate that one or more eBCS services being broadcast are ending. In some implementations, the eBCS service termination notification procedure enables the STA to indicate that one or more eBCS services being broadcast by one or more other STAs are ending.

[0116] In some implementation manners, when one or more eBCS services are terminated within an interval less than a time such as dot11eBCSTerminationNoticeTime, and the STA does not periodically transmit the schedule of the eBCS service(s) to be terminated, the eBCS STA, which is a broadcaster of one or more eBCS services, shall start to transmit an eBCS service termination notification frame. In some implementation manners, when one or more eBCS services are terminated within an interval less than a time such as dot11eBCSTerminationNoticeTime, and the STA does not periodically transmit the schedule of the eBCS service(s) to be terminated, the eBCS STA shall start to transmit an eBCS service termination notification frame. In some implementation manners, when one or more eBCS services are terminated within an interval less than a time such as dot11eBCSTerminationNoticeTime, the eBCS STA shall start to transmit an eBCS service termination notification frame. In some implementation manners, when the eBCS STA starts to transmit 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 implementation manners, the eBCS STA that transmits an eBCS service termination notification frame indicates the number of TBTTs in the time-to-end subfield within the eBCS service termination information subfield before the eBCS service identified by the eBCS service ID included in the eBCS service ID subfield within the same eBCS service termination information subfield is terminated. In some implementation manners, the time-to-end subfield may be indicated in another time format such as ms, us, time unit (TU), or any other type of time unit.

[0118] In some implementations, the eBCS STA that transmits the eBCS service termination notification frame shall indicate, in the negotiation method subfield within the negotiation information subfield of the eBCS service termination information subfield, the negotiation method that the STA shall use to negotiate about the 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. In some implementations, the eBCS STA may indicate that negotiation is not available.

[0119] In some implementations, the eBCS STA that transmits the eBCS service termination notification frame may indicate, in the negotiation address subfield within the 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 shall use to negotiate about the 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 implementation manners, after sending an eBCS service termination notification frame, if the eBCS service identified by the eBCS service ID in the eBCS service ID subfield within the same eBCS service termination information subfield is negotiated with a different duration or a new time-to-end value, the eBCS STA shall send an eBCS service termination notification frame with the value of the time-to-end subfield in the eBCS service termination information subfield updated. In some implementation manners, if the negotiated duration for the eBCS service is longer than the maximum value of the time-to-end subfield, the transmitting STA shall set the time-to-end subfield to 0. In some implementation manners, if the negotiated duration for the eBCS service is longer than the maximum value of the time-to-end subfield, the transmitting STA shall set the time-to-end to the maximum value of the time-to-end subfield. In some implementation manners, if the negotiated duration for the eBCS service is longer than the maximum value of the time-to-end subfield, the transmitting STA shall set the time-to-end subfield to some specific value N.

[0121] In some implementation manners, after sending an eBCS service termination notification frame, if the eBCS is negotiated with a different duration or a new time-to-end value, the eBCS STA shall send an eBCS service information frame or another type of frame with the value of the time-to-end subfield or the eBCS service duration subfield updated.

[0122] In some implementation manners, an eBCS STA that receives an eBCS service termination notification frame may negotiate for an extension of the eBCS service if, for example, the eBCS service indicated in one of the eBCS service termination information sub-fields ends earlier than desired. In some implementation manners, the eBCS STA may negotiate for an extension of the eBCS service by using a negotiation method as indicated in the negotiation method within the eBCS service termination information sub-field. In some implementation manners, for example, it may follow the procedures defined in the 802.11 specifications, such as 11.22.6.x (eBCS service negotiation procedures for associated STAs) and 11.23.3.3 (ANQP procedures).

[0123] In some implementation manners, an eBCS STA that receives an eBCS service information frame or any other frame time may negotiate for an extension of the eBCS service if, for example, the eBCS service ends earlier than desired. In some implementation manners, the eBCS STA may negotiate for an extension of the eBCS service by using a negotiation method as indicated in the negotiation method within the eBCS service termination information sub-field. In some implementation manners, for example, it may follow the procedures defined in the 802.11 specifications, such as 11.22.6.x (eBCS service negotiation procedures for associated STAs) and 11.23.3.3 (ANQP procedures).

[0124] In some implementation manners, if the eBCS STA receives an eBCS service termination notification frame that includes a time-to-end value or a duration value that is acceptable, and the eBCS service ID of the eBCS service of the STA is included in the eBCS service termination information sub-field, or is included in the eBCS service information frame or another type of frame for the same eBCS service, the transmission of any eBCS service request frame, or a frame including an enhanced broadcast request ANQP element, or any frame including an IP frame requesting an eBCS service shall be skipped.

[0125] Some implementation manners include the end of a broadcast service announcement indication procedure having a trigger mechanism. In some implementation manners, after the end of a broadcast service announcement indication (EBSAI) is sent by an AP via a management or control frame, or after being aggregated with any type of frame, STAs that may intend to hold the current service or negotiate a new broadcast service may respond. Two or more STAs may need to send responses to the EBSAI.

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

[0127] The AP may expect one or more STAs to send response frames. The AP may send a trigger frame to trigger the transmission of a multiple access response. In some implementation manners, the trigger frame may be sent after a frame having an EBSAI with an inter-frame space (xIFS) time. Here, xIFS may refer to any existing inter-frame space or a newly defined inter-frame space. In some implementation manners, the trigger frame may be aggregated with a frame having 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 EBSAI, NDP, or a probe request management frame trigger, etc. Alternatively, the trigger type field may indicate an existing trigger type, such as a basic trigger, etc.

[0128] One or more STAs may send a response to the EBSAI, so that the STA may maintain the initially negotiated broadcast service, modify the initially negotiated broadcast service, for example, continue the service beyond the end time, and / or request to start a new broadcast negotiation at specific periods and intervals.

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

[0130] In an exemplary same response method, the common end of the broadcast response frame / field / element / PPDU may be defined so that STAs that may intend to respond may simultaneously send the same physical layer packet. The AP may be able to detect the simultaneous transmissions from the STAs, for example, because they are the same.

[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 may prefer to hold the initially 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 hold the first negotiation. Alternatively, the SIG field may be omitted, and the current NDP transmission may indicate that the STA may prefer to hold the first setting. The PPDU may be transmitted at an xIFS after a trigger frame by one or more STAs. In this way, a STA that may prefer to terminate the broadcast service may not need to respond, and a STA 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 first negotiation, modifying the first negotiation, starting a new negotiation, etc. In one design, the NDP EBSAI response PPDU may be used for this type of EBSAI response. The NDP EBSAI response PPDU may carry the STF and LTF and SIG fields (the legacy preamble field may be prepended for backward compatibility). Some of the above fields may be transmitted with a partial bandwidth. The transmission position may indicate the message that can be carried. For example, the full bandwidth may be divided into M chunks. If the STF and / or LTF and / or SIG field can be transmitted on the first frequency chunk, it may indicate the first message. If the STF and / or LTF and / or SIG field can be transmitted on the second frequency chunk, it may indicate the second message, and so on. The PPDU may be the transmitted xSIF immediately following the trigger frame. In one method, the mapping of the frequency resources and the message may be predefined and no signaling is required. In one method, the mapping of the frequency resources and the message may 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 the trigger frame. The STA may start an OFDMA random access procedure, select one or more resource units, and transmit its own response frame. The response frame may be a normal MAC frame, and the normal MAC frame may be the transmission (Tx) and / or reception (Rx) address and other fields normally defined within the MAC header. Further, it may carry EBSAI response-related information.

[0134] In an exemplary trigger-based probe request method, one or more of the resource units can be allocated for this response transmission. The resource allocation can be included in the trigger frame. Unassociated STAs can use the probe request management frame to select one or more resource units for frame transmission. This response frame can negotiate / renegotiate the broadcast service by including additional information beyond what is currently available within these management frames.

[0135] Some implementations provide eBCS service capability indicators. In some implementations, the AP can include eBCS service capability elements such as probe responses, beacon frames, eBCS service advertisement frames, eBCS information frames, FILS discovery frames, etc. in any frame to be transmitted.

[0136] FIG. 12 is a bitmap diagram illustrating an exemplary format of an eBCS service capability element. The eBCS service capability element may include one or more of the following subfields, such as those 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 subframe 1214, number of broadcast services subframe 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 parameter subfield 1230, broadcast security subfield 1232, upper layer destination address subfield 1234, title existence subfield 1236, title length subfield 1228, title subfield 1240, time to end subfield 1242, broadcast control subfield 1244, and / or other subfields. Descriptions of examples of such subfields are as follows.

[0137] For the element ID subfield 1202, length subfield 1204, and element ID extension subfield 1206, the combination of the element ID and the 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 the 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 capability element included in the current eBCS capability element.

[0141] The eBCS1-N subfield 1218 may include N subfields that may be included in the broadcast element, and 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 parameter subfield 1230, and / or a broadcast security subfield 1232.

[0142] The broadcast information control subfield 1220 may be 1 byte in length and may include an indicator as to whether specific broadcast information is included in the eBCS N field. The broadcast ID subfield 1222 may be 1 bit in length and may indicate whether a broadcast ID is included in the eBCS N field.

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

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

[0145] The association request subfield 1226 may indicate whether an association is required to consume one or more broadcast services, e.g., a broadcast service identified by a broadcast ID. The UL transmission request subfield 1228 may indicate whether a 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, if a STA desires a particular broadcast service, it may indicate that the STA needs to directly negotiate with the transmitting STA, e.g., the transmitting AP, by using, e.g., 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 the 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. The method for control may be via WLAN, TCP / IP, broadcast request negotiation, ANQP, or GAS frame exchange, etc. The broadcast parameter subfield may include one or more broadcast parameters, e.g., an offset and / or a 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 on which the broadcast service packet may be available, or an OFDMA subchannel or a resource unit (RU).

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

[0148] For example, when the title presence subfield 1236 in the broadcast service information control subfield is set to 1, the title length subfield 1238 can be included in the broadcast service field; otherwise, it does not exist. The title length field can be 1 byte long and can indicate the length of the title subfield 1240.

[0149] For example, when the title presence subfield 1236 in the broadcast service information control subfield is set to 1, the title subfield 1240 can be included in the broadcast service field; otherwise, it may not exist. The title length field can be 1 byte long and can indicate the length of the title subfield 1240.

[0150] The time-to-end subfield 1242 can be used to indicate the remaining time until the end of the broadcast service described in this broadcast service field, unless additional negotiation is performed by the initiator of the broadcast service or by other users of the broadcast service. In some implementations, the subfield can include a time (e.g., a TSF time value, or other type of time) at which the broadcast service ends unless additional negotiation is performed by the initiator of the broadcast service or by other users of the broadcast service. Additionally or alternatively, it can include a timestamp of the current time, such as the current value of the TSF timer.

[0151] The broadcast control subfield 1244 can be included in the eBCS N field, for example, if the broadcast control presence subfield is set to 1 within the broadcast information control subfield 1220. The broadcast control subfield 1244 can be used to indicate the negotiation method to be used to negotiate the initialization, control, or stop of the broadcast service. The broadcast control subfield 1244 can 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 address required for the negotiation can be included).

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

[0153] Some implementations include an eBCS service request format. In some implementations, the eBCS service request format may be defined as follows. The eBCS service request frame may include eBCS service request elements. Such eBCS service request elements 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] FIG. 13 is a bitmap diagram illustrating an exemplary 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 field Element ID 1302, Length 1304, Element ID Extension 1306, Number of Broadcast Service Fields 1308, and / or one or more of Broadcast Service Fields 1310.

[0155] The Element ID field 1302, the Length field 1304, and the 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 included in the element.

[0157] In one or more of the Broadcast Service Fields 1310, each of the Broadcast Service Fields 1310 may include information about a particular broadcast service being requested, and may include a Broadcast Service Information Control Field Subfield 1312, a Broadcast Service ID Subfield 1314, a Upper Layer Destination Address Subfield 1316, a Title Length Subfield 1318, a Title Subfield 1320, a Requested Duration Period Subfield 1322, and / or a Requested Parameter Subfield 1324.

[0158] The broadcast service information control field 1312 can be 1 byte in length and can include an indicator as to whether specific broadcast information is included in the broadcast service field 1310. The broadcast service ID subfield 1314 can be 1 byte in length and can be used to indicate an identifier of the broadcast service. The upper layer destination address subfield 1316 can be of 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 can include an IP address and a UDP port. If a MAC address is indicated in the upper layer protocol subfield, it can include a 6-byte MAC address. If the upper layer protocol subfield 1316 indicates that there is no upper layer destination address field, the upper layer destination address is not included in the broadcast service field.

[0159]

[0160] The required duration subfield 1322 can be 1 byte long and can be used to indicate the required duration of the required broadcast service. The required parameter subfield 1324 can be 1 byte long and can indicate the required parameters of the required 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] FIG. 14 is a diagram illustrating an exemplary format of the broadcast service information control field subfield 1312. The broadcast service information control field subfield 1312 can include a broadcast service ID presence subfield 1402, an upper layer protocol 1404 subfield, a title presence subfield 1406, a required duration presence subfield 1408, and a required parameter presence subfield 1410. The broadcast service information control field subfield 1312 can also have a reservation subfield 1412.

[0162] The Broadcast Service ID Presence Subfield 1402 can be 1 bit long and can indicate whether the Broadcast Service ID is included in the Broadcast Service Field 1310. The Upper Layer Protocol Subfield 1404 can be 3 bits long and can indicate one of the following values: the upper layer destination address does not exist, the upper layer destination address does not exist, and / or the upper layer destination address exists within the Broadcast Service Field 1310. The Upper Layer Protocol Subfield 1404 can include UDP / IPv4, UDP / IPv6, UDP / hostname, MPEG transport stream identifier, and / or MAC address. The Title Presence Subfield 1406 can be 1 bit long and is used to indicate whether a user-readable title exists in the Broadcast Service Field 1310. If the Title Presence bit is set to 1, the Title Length Subfield and the Title Subfield can be included in the Broadcast Service Field 1310. Negotiation Method Presence Subfield: This subfield can be 1 bit long and can be used to indicate whether the Negotiation Method Subfield is included in the Broadcast Service Field.

[0163] The Requested Duration Presence Subfield 1408 can be 1 bit long and can indicate whether the requested duration of the requested broadcast service exists in the Broadcast Service Field 1310. The Requested Parameter Presence Subfield 1410 can be 1 bit long and can indicate whether the requested parameters of the requested broadcast service exist in the Broadcast Service Field 1310.

[0164] In some implementation manners, any subset of the fields or sub - fields of the eBCS service request element can be implemented in any field or sub - field or set or subset of fields of an existing or newly designed element or frame, or any management, control, and data frame's PHY and / or MAC header, or other header, or other frame such as an EBCS request frame.

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

[0166] FIG. 15 is a bitmap diagram illustrating an exemplary format of an eBCS service response element. In some implementation manners, the eBCS service response element can include one or more of the following fields: element ID field 1502, length field 1504, element ID extension field 1506, number of broadcast service fields field 1508, and / or one or more broadcast service fields fields 1510.

[0167] The element ID field 1502, length field 1504, and element ID extension field 1506 can 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 can indicate the number of broadcast service fields included in the element.

[0168] Each of one or more of the broadcast service fields 1510 may contain response information for a particular requested broadcast service, 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 parameter field 1526.

[0169] The broadcast service information control field 1512 may be 1 byte in length and may include an indicator as to whether specific broadcast information is included in the broadcast service field 1510.

[0170] FIG. 16 illustrates an exemplary format of the broadcast service information control subfield 1512. As shown in FIG. 16, the broadcast service information control field 1512 may include a broadcast service ID presence subfield 1602, an upper layer protocol subfield 1604, a title presence subfield 1606, a broadcast service duration presence subfield 1608, a broadcast service parameter presence subfield 1610, and / or a reservation subfield 1612.

[0171] The broadcast service ID presence subfield 1602 may be 1 bit in length and may indicate whether the broadcast service ID is included in the broadcast service field. The upper layer protocol subfield 1604 may be 3 bits in length and may indicate, for example, one of the following values: the absence of an upper layer destination address, the presence of an upper layer destination address in the broadcast service field (the upper layer protocol may be UDP / IPv4, UDP / IPv6, UDP / hostname, MPEG transport stream identifier, MAC address, and / or reserved and / or may be indicated as such).

[0172] The Title Present subfield 1606 can be 1 bit in length and can indicate whether a user-readable title exists in the Broadcast Service field 1510. If the Title Present bit is set to 1, the Title Length subfield 1518 and the Title field 1520 can be included in the Broadcast Service field 1510.

[0173] The Broadcast Service Duration Present subfield 1608 can be 1 bit in length and can indicate whether a Broadcast Service Duration for the provided Broadcast Service exists in the Broadcast Service field 1510. The Broadcast Service Parameter Present subfield 1610 can be 1 bit in length and can indicate whether Broadcast Service Parameters for the requested Broadcast Service exist in the Broadcast Service field 1510.

[0174] Referring back to FIG. 15, the broadcast service ID field 1514 may indicate an identifier of the broadcast service and may be 1 byte in length. The upper layer destination address sub-field 1516 may have different lengths, for example, depending on the value indicated in the upper layer protocol field of the broadcast service information control sub-field. When IPv4 / UDP or IPv6 / UDP is indicated in the upper layer protocol sub-field 1604, the upper layer destination address sub-field 1516 may include an IP address and a UDP port. The upper layer destination address sub-field 1516 may include, for example, a 6-byte MAC address when the MAC address is indicated in the upper layer protocol sub-field 1604. For example, when the upper layer protocol sub-field indicates that there is no upper layer destination address field, the upper layer destination address may not be included in the broadcast service field 1510. When the title presence sub-field 1606 in the broadcast service information control sub-field 1512 is set to 1, the title length sub-field 1518 may be included in the broadcast service field 1510, otherwise it may not exist. The title length field 1518 may be 1 byte in length and may indicate the length of the title sub-field 1520. For example, when the title presence sub-field in the broadcast service information control sub-field 1512 is set to 1, the title sub-field 1520 may be included in the broadcast service field 1510, otherwise it may not exist.

[0175] Status subfield 1522 may indicate whether a broadcast service request was successful. The status subfield may also include a reason for rejection if the request was rejected. The broadcast service duration subfield may indicate the duration of the provided broadcast service. The broadcast service parameter subfield may indicate parameters of the provided broadcast service, such as a time offset compared to a fixed time reference point (e.g., TBTT), channel, RU resource, 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 any management, control, and data frame's PHY and / or MAC header, or other header, or other frame such as an EBCS request frame.

[0177] Some implementations include eBCS service request / response procedures. Some implementations include eBCS service request / response procedures for an unassociated STA. In some implementations, the eBCS service negotiation procedures for an unassociated STA may be as follows.

[0178] In some implementations, the AP may advertise one or more broadcast services using broadcast service elements, e.g., in beacons, probe responses, eBCS service advertisement frames, eBCS information frames, etc., and / or using only probe responses, eBCS service advertisement frames, eBCS information frames, or EBCS end notification frames, etc. The AP may indicate a negotiation method for one or more eBCS services via ANQP / GAS frame exchanges, via probe request frame exchanges, via eBCS service request / response frames, or via IP packets, etc.

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

[0180] The AP may respond to an eBCS service request by transmitting an eBCS response frame, or an ANQP / GAS eBCS service response frame, or a frame containing eBCS service response frames or information. The AP may indicate the status of one or more eBCS service requests, such as success or rejection, and may include the reason for rejection if the request is rejected. The AP may indicate the remaining time of the broadcast service being provided. For example, the AP may include the broadcast service duration in the eBCS service response element, or may include, for example, the end of the broadcast service announcement element periodically in one or more of the frames being transmitted, such as 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 on a specific channel or RU, such as the broadcast frequency, the data rate used, etc., if the eBCS service request is successful. Thereafter, the AP may then start to provide the requested eBCS service accordingly.

[0181] Some implementation modes include eBCS service request / response procedures for associated STAs. In some implementation modes, the eBCS service negotiation procedures for associated STAs can be as follows. The AP can advertise one or more broadcast services using broadcast service elements, for example, in beacons, probe responses, eBCS service advertisement frames, eBCS information frames, etc., and / or simply using probe responses, eBCS service advertisement frames, eBCS information frames, EBCS end notification frames, etc. The AP can indicate negotiation methods for one or more eBCS services, for example, via ANQP / GAS frame exchanges, via probe request frame exchanges, via eBCS service request / response frames, and / or via IP packets. The AP can indicate that association is required to utilize those eBCS services for one or more eBCS services.

[0182] After receiving frames such as EBCS information frames, EBCS end notification frames, or EBCS ANQP service frames from an AP, or from pre-acquired knowledge, and / or via ANQP / GAS frame exchanges from one or more APs, a STA may discover a desired broadcast service. One or more broadcast services that an AP can provide but is not currently providing and that require association may be requested by the STA. If the STA is not currently associated with an AP, the STA may perform authentication and association with the AP. The STA may follow the negotiation method indicated by the AP for its eBCS service and may send frames such as an eBCS service request frame, or a frame containing an eBCS service request element or information to the AP, and those frames 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, upper layer destination address, MAC address, title, etc. If a broadcast service is requested, the STA may request the broadcast service for a specific period. 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, data rate used, etc.

[0183] The AP may respond to an eBCS service request by transmitting an eBCS response frame, or a frame containing an eBCS response frame or information including a probe response and an association response frame. If the eBCS service requires association, the AP may not start the eBCS (Enhanced Broadcast Service) service until the STA is fully associated with the AP. The AP may indicate the status of one or more eBCS service requests, such as successful, rejected, etc., and may include the reason for rejection. The AP may indicate the remaining time of the broadcast service it is providing. For example, the AP may include the broadcast service duration in the eBCS service response element, or may include, for example, the end of the broadcast service announcement element periodically in one or more of the frames it is transmitting, such as 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 on a specific channel or RU, such as the broadcast frequency, the broadcast period duration, the data rate used, etc., when the request for the eBCS service is successful. Thereafter, the AP may then start to provide the requested eBCS service accordingly.

[0184] Some implementation modes include eBCS service request / response procedures for receive-only STAs. In some implementation modes, the eBCS service negotiation procedure for a receive-only STA is as follows. In some implementation modes, an AP may advertise one or more broadcast services using broadcast service elements in beacons, probe responses, eBCS service advertisement frames, eBCS information frames, etc., and / or simply using probe responses, eBCS service advertisement frames, eBCS information frames, etc. The AP may indicate negotiation methods for one or more eBCS services via ANQP / GAS frame exchanges, via probe request frame exchanges, via eBCS service request / response frames, and / or via IP packets, etc. The AP may indicate that association is required to utilize those eBCS services for one or more eBCS services.

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

[0186] If the request is successful, the AP may accordingly start providing the requested eBCS service. The AP may indicate the remaining time of the broadcast service being provided. For example, the AP may include, for example, periodically, at the end of the broadcast service announcement element in one or more of the frames being transmitted (such as, for example, beacon frames, probe response frames, eBCS data frames, broadcast service request frames, eBCS service advertisement frames, EBCS end notification frames, and / or eBCS information frames, etc.).

[0187] Although the features and elements of the various embodiments described above are described in specific combinations, each feature or element can be used alone without being accompanied by other features and elements of the preferred embodiment, or can be used in various combinations with or without other features and elements of the present invention. The solutions described herein take into account the protocol of the 802.11 specification, but it is understood that the solutions described herein are not limited to this scenario and are further applicable to other wireless systems.

[0188] xIFS and / or SIFS are used to indicate various inter-frame spacings in the design and procedure embodiments, but all other inter-frame spacings such as RIFS, AIFS, DIFS, or other agreed-upon time intervals can be applied to the same solution. Four RBs per triggered TXOP are shown as an example in some figures, but the actual number of RBs / channels / bandwidths utilized can vary.

[0189] Figure 17 illustrates an exemplary method 1700 for a STA to request continuation of an eNCS service. At step 1702, the STA may first receive from an access point (AP) an eBCS termination notification frame indicating that the eBCS service being consumed by the STA is ending. At step 1704, the STA may negotiate for continuation of the eBCS service on the condition that termination is not allowed. Next, at step 1706, if the negotiation for continuation of the eBCS service is successful, the STA may continue to receive 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 execute these steps in a different order.

[0190] Features and elements are described above in particular combinations, but those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Further, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer may be implemented using a processor associated with software.

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 eBCS service consumed by the STA, provided that the termination of the eBCS service consumed by the STA is not acceptable; and upon successfully negotiating continuation of the eBCS service being consumed by the STA, continuing to receive the eBCS service being consumed by the STA.

2. 2. The method of claim 1, wherein the enhanced broadcast service (eBCS) termination frame further includes an indication of a time when the eBCS service that the STA is consuming will terminate.

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

4. The method of claim 1 , further comprising receiving, from the AP, an indication of a negotiation method for negotiating an extension of the eBCS service that the STA is consuming.

5. 5. The method of claim 4, wherein the indication of the negotiation method is contained in a negotiation method subfield value that is one octet in length.

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

7. The method of claim 5 , wherein the negotiation method subfield value 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 value 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 value indicates that the STA negotiates via an IP request.

10. A station (STA), a receiver configured to receive an enhanced broadcast service (eBCS) termination frame from an access point (AP), the eBCS termination frame indicating that an eBCS service being consumed by the STA is to be terminated; a processor and a transmitter configured to negotiate with the AP for continuation of the eBCS service consumed by the STA, provided that the termination of the eBCS service consumed by the STA is not acceptable; A station (STA), wherein the receiver is further configured to continue receiving the eBCS service being consumed by the STA when the processor and transmitter successfully negotiate the continuation of the eBCS service being consumed by the STA.

11. The STA of claim 10 , wherein the enhanced broadcast service (eBCS) termination frame further includes an indication of a time when the eBCS service that the STA is consuming will terminate.

12. The STA of claim 10 , wherein the first enhanced broadcast service (eBCS) termination 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 an indication of a negotiation method for negotiating an extension of the eBCS service that the STA is consuming.

14. The STA of claim 13, wherein the indication of the negotiation method is contained in a negotiation method subfield value that is one octet long.

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

16. The STA of claim 14 , wherein the negotiation method subfield value 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 value 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 value indicates that the STA negotiates via an IP request.

Images