High-efficiency broadcast in wireless local area networks

Abstract

Apparatuses, methods, and / or systems are provided for broadcasting in a wireless local area network (WLAN). A STA receives a frame from a wireless access point (AP), the frame including an indication of an end of an enhanced broadcast service (eBCS) service. The frame can include an end broadcast service announcement information element and / or an indication of an eBCS service end time. If the STA desires to continue to receive the eBCS service beyond the eBCS service end, the STA can negotiate with the AP to continue the broadcast service. The STA can receive a trigger frame from the AP, the trigger frame triggering a response from the STA indicating that the STA desires to continue to receive the eBCS service beyond the eBCS service end.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 971,621, filed February 7, 2020, and U.S. Provisional Application No. 63 / 042,059, filed June 22, 2020, the contents of which are incorporated by reference herein. BACKGROUND

[0003] A wireless local area network (WLAN) in infrastructure basic service set (BSS) mode can include an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. An enhanced broadcast service (eBCS) can include a downlink from an AP STA to non-AP STAs or can include an uplink from a sensor non-AP STA. The enhanced broadcast service can be provided to STAs associated or unassociated with a particular AP. Some example use cases for eBCS can include a sports stadium video broadcast; a car broadcast; an uplink sensor data broadcast; a museum information and multi-language broadcast; and / or an event producer information and content broadcast. SUMMARY

[0004] The present disclosure provides devices, methods, and / or systems for broadcasting in a wireless local area network (WLAN). A STA receives a frame from a wireless access point (AP), the frame including an indication of an end of an enhanced broadcast service (eBCS) service. The frame can include an end broadcast service announcement information element and / or an indication of an eBCS service end time. If the STA desires to continue to receive the eBCS service beyond the eBCS service end, the STA can negotiate with the AP to continue the broadcast service. The STA can receive a trigger frame from the AP, the trigger frame triggering a response from the STA, the response indicating that the STA desires to continue to receive the eBCS service beyond the eBCS service end. BRIEF DESCRIPTION OF DRAWINGS

[0005] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings wherein like reference numerals indicate like parts and wherein:

[0006] Figure 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented;

[0007] Figure 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications system Figure 1A illustrated in FIG. 1 can be used;

[0008] Figure 1C is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications systemFigure 1A System diagram of an exemplary radio access network (RAN) and exemplary core network (CN) used within the illustrated communication system;

[0009] Figure 1D is a signaling diagram illustrating an exemplary multiple access procedure according to one embodiment; Figure 1A System diagram of another exemplary RAN and another exemplary CN used within the illustrated communication system;

[0010] Figure 2 is a diagram illustrating an exemplary format of an end-broadcast-service announcement information element;

[0011] Figure 3 is a diagram illustrating an exemplary format of a broadcast service information control field

[0012] Figure 4 is a diagram illustrating an exemplary format of an eBCS termination notification frame action field;

[0013] Figure 5 is a diagram illustrating an exemplary format of an eBCS service termination information subfield;

[0014] Figure 6 is a diagram illustrating an exemplary format of an eBCS service termination information control subfield;

[0015] Figure 7 is a diagram illustrating an exemplary format of a negotiation address subfield;

[0016] Figure 8 is a diagram illustrating an exemplary format of a negotiation address subfield;

[0017] Figure 9 is a diagram illustrating an exemplary format of a negotiation address subfield;

[0018] Figure 10 is a diagram illustrating an exemplary format of a negotiation address subfield;

[0019] Figure 11 is a signaling diagram illustrating an exemplary multiple access procedure;

[0020] Figure 12 is a diagram illustrating an exemplary format of an eBCS service capability element;

[0021] Figure 13 is a diagram illustrating an exemplary format of an eBCS service request element;

[0022] Figure 14 is a diagram illustrating an exemplary format of a broadcast service information control field;

[0023] Figure 15FIG. 1 is an illustration showing an exemplary format of an eBCS service response element;

[0024] Figure 16 FIG. 1 is an illustration showing an exemplary format of an eBCS service response element;

[0025] Figure 17 An exemplary method of a STA requesting continuation of an eNCS service is shown. DETAILED DESCRIPTION

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

[0027] As Figure 1AAs shown, 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, though it will be appreciated 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 (any of which can be referred to as a station (STA)), can be configured to transmit and / or receive wireless signals, and can include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot or other wireless devices operating in an industrial and / or an automated processing chain environment), a consumer electronics, a device operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

[0029] The base stations 114a can be part of a RAN 104 that also can include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base stations 114a and / or the base stations 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies. The base stations 114a and / or 114b can be referred to as cells supporting a particular carrier frequency. The base stations 114a and / or 114b can utilize multiple carriers (e.g., in a Carrier Aggregation (CA) scheme). The base stations 114a and / or 114b can also support additional carriers (e.g., in a licensed-assisted access (LAA) scheme). The base stations 114a and / or 114b can be configured to transmit and receive wireless signals on the above-mentioned frequency bands, or other frequency bands. The base stations 114a and / or 114b can be configured to transmit and receive wireless signals on the above-mentioned frequency bands, or other frequency bands. The base stations 114a and / or 114b can be configured to communicate with the WTRUs 102a, 102b, 102c, 102d on a

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

[0031] More specifically, as noted above, the communications system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 116 using wideband CDMA (WCDMA). 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).

[0032] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology 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-A Pro.

[0033] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using NR.

[0034] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access and NR wireless access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

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

[0036] Figure 1AThe base station 114b in the embodiment can be, for example, a wireless router, Home Node B, Home eNode B, or access point, and can utilize any suitable RAT for facilitating wireless connectivity access by the WTRUs 102c, 102d within a local area. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in FIG. 1, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106. Figure 1A

[0037] The RAN 104 can be in communication with the CN 106, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in Figure 1A Although not shown in FIG. 1, it will be appreciated that the RAN 104 and / or the CN 106 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which can employ NR radio technology, the CN 106 can also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0038] ​The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice telephony. The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP Internet Protocol suite. The networks 112 can include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 or a different RAT.

[0039] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 can include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links. For example, Figure 1A The WTRU 102c shown in Figure 1A can be configured to communicate with the base station 114a using a cellular-based radio technology and can be configured to communicate with the base station 114b using an IEEE 802 radio technology.

[0040] Figure 1B Figure 1B is a system diagram illustrating an example WTRU 102. As shown in Figure 1B The WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0041] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs), any other type of integrated circuit (IC), a state machine, and / or the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. WhileFigure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is to be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

[0043] Although the transmit / receive element 122 is depicted in the WTRU 102 Figure 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to enable MIMO technology. Thus, the WTRU 102 can

[0044] The transceiver 120 can be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

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

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

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

[0048] The processor 118 can further be coupled to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands- free headset, a Bluetooth® The peripheral device 138 can include one or more sensors. The sensors can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, a compass sensor, a proximity sensor, a temperature sensor, a time sensor; a geo-location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0049] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and DL (e.g., for reception) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and and / or substantially eliminate self-interference and / or cross- interference due to concurrent transmission and reception. In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) or DL (e.g., for reception)) are time-divided.

[0050] Figure 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can be in communication with the WTRUs 102a, 102b, 102c over the air interface 116 and can include eNode-Bs 160a, 160b, 160c, although

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

[0052] Each of the eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown, the eNode-Bs 160a, 160b, 160c can communicate with one another over an X2 interface. Figure 1C

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

[0054] The MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an SI interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activations / deactivations, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 can provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

[0057] ​CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Further, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a local DN 110 through the UPF 106a. In another embodiment, the WTRUs 102a, 102b, 102c can be connected to the DN 110 through the UPF 106a and the UPF 106b.

[0058] Although WTRUs are often described in this disclosure as if there can be temporary or permanent wired / wireless communication interfaces to the communication network, it is contemplated that, in certain representative embodiments, such a terminal can use only a wired communication interface to the communication network. Figures 1A-1D

[0059] In representative embodiments, the other network 112 can be a WLAN.

[0060] A WLAN in Infrastructure Basic Service Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that is carried by the WLAN can be transmitted from the AP to the STAs via downlink (DL) transmissions. DL traffic can be transmitted by the AP to STAs using, for example, orthogonal frequency division multiplexing (OFDM) techniques. OFDM techniques can include frequency division multiple access (FDMA), time division multiple access (TDMA), code division multiple access (CDMA), and / or the like. DL traffic can be transmitted by the AP using, for example, downlink subframes, downlink subframes, and / or the like. Traffic from STAs to the AP, or uplink (UL) traffic, can be transmitted from the STAs to the AP via UL transmissions. UL traffic can be transmitted by STAs using, for example, OFDM techniques. UL traffic can be transmitted by STAs using, for example, UL subframes, UL subframes, and / or the like.

[0061] ​When using an 802.11 ac infrastructure mode of operation or similar mode of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems. For CSMA / CA, a STA (e.g., each STA), including the AP, can listen to the primary channel. If the primary channel is sensed / detected as busy by a particular STA, the particular STA can back off. Only one STA can transmit in a given BSS at any given time.

[0062] High Throughput (HT) STAs can use 40 MHz wide channels to communicate, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0063] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be parsed by a segment parser that can divide the data into two streams. Each stream can be independently subjected to inverse fast Fourier transform (IFFT) processing and time domain processing. The streams can be mapped to the two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0064] 802.11af and 802.11ah support sub-1 GHz modes of operation. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11η and 802.1 lac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC) such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidth. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0065] WLAN systems that can support multiple channels and channel bandwidths such as 802.11η, 802.1 lac, 802.11af, and 802.11ah include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in a BSS. The bandwidth of the primary channel can be set and / or limited by a STA from all STAs operating in the BSS that supports the smallest bandwidth operating mode. In the example of 802.11ah, for a STA (e.g., MTC type device) that supports (e.g., only supports) a 1 MHz mode, the primary channel can be 1 MHz wide even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, e.g., due to a STA (only supporting a 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy even if most of the available frequency band remains idle.

[0066] In the United States, the available frequency bands for 802.11ah to use are 902 MHz to 928 MHz. In Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 916.5 MHz to 927.5 MHz. The total bandwidth available to 802.11ah is 6 MHz to 26 MHz depending on the country code.

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

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

[0069] The WTRUs 102a, 102b, 102c can use transmission associated with scalable numerology to communicate with gNBs 180a, 180b, 180c. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary from different transmissions, from different cells, and / or from different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can use subframe or transmission time interval (TTI) of various or scalable lengths (e.g., containing different quantities of OFDM symbols and / or lasting varying lengths of absolute time) to communicate with gNBs 180a, 180b, 180c.

[0070] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with one or more of gNBs 180a, 180b, 180c without also accessing other RANs, such as eNode-Bs 160a, 160b, 160c. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can use signals

[0071] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As Figure 1D As shown, the gNBs 180a, 180b, 180c can be in communication with one another over an Xn interface.

[0072] Figure 1DThe illustrated CN 106 can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0073] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating the WTRUs 102a, 102b, 102c, supporting for different

[0074] The SMF 183a, 183b can be connected to the AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b can also be connected to the UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type can be IP-based, non-IP based, Ethernet-based, and the like.

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

[0076] The CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Further, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a DN 185a, 185b through the UPF 184a, 184b via the N3 interface between the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0077] In view of Figures 1A-1D And Figures 1A-1D In view of the corresponding description of the above, one or more or all of the functions described herein with reference to one or more of the WTRUs 102a-102d, the base stations 114a-114b, the eNode-Bs 160a-160c, the MME 162, the SGW 164, the PGW 166, the gNBs 180a-180c, the AMFs 182a-182b, the UPFs 184a-184b, the SMFs 183a-183b, the DNs 185a-185b, and / or any other device described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device can be used to test other devices and / or to simulate network and / or WTRU functionality.

[0078] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform one or more or all functions while being 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. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or use over-the-air wireless communication to perform tests.

[0079] The one or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0080] A wireless local area network (WLAN) in Infrastructure Basic Services Set (BSS) mode may include an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP typically has an access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic originating outside the BSS and destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA and destined for an external BSS destination can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can also be sent via the AP, where the source STA sends traffic to the AP, and the AP delivers the traffic to the destination STA. Such traffic between STAs within the BSS can be considered point-to-point traffic. Direct link setups (DLS) can also be used to send such point-to-point traffic directly between the source and destination STAs, such as using 802.11e DLS or 802.11z Channel DLS (TDLS). A WLAN using Standalone BSS (IBSS) mode may not have an AP and / or may include STAs communicating directly with each other. This communication mode is called the "ad-hoc" communication mode.

[0081] When using the 802.11 ac infrastructure mode of operation, the AP can transmit beacons on a fixed channel (e.g., 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 STAs to establish a connection with the AP. Channel access in 802.11 systems can include carrier sense multiple access with collision avoidance (CSMA / CA). In this mode of operation, each STA, including the AP, can sense the primary channel. If the channel is detected to be busy, the STA can "back off." Thus, only one STA can transmit in a given BSS at any given time.

[0082] In 802.11η, high throughput (HT) STAs can also communicate using 40 MHz wide channels. This can be accomplished by combining the primary 20 MHz channel with an adjacent 20 MHz channel to form a 40 MHz wide contiguous channel.

[0083] In 802.11 ac, very high throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and 160 MHz wide channels. The 40 MHz and 80 MHz channels can be formed by combining contiguous 20 MHz channels similar to 802.11η described above. The 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which can also be referred to as 80+80 configuration. For the 80+80 configuration, after channel coding, the data can be passed through a segment parser that divides the data into two streams. Each stream can be IFFT'ed and time domain processed separately, after which the streams can be mapped on to the two channels and the data can be transmitted. At the receiver, the mechanism is reversed and the combined data is sent to the MAC.

[0084] Sub-1 GHz modes of operation can be supported by 802.11 af and 802.11 ah. For these specifications, the channel operating bandwidth and carriers can be reduced relative to those used in 802.11η and 802.11 ac. 802.11 af can support 5 MHz, 10 MHz, and 20 MHz bandwidths in the television white space (TVWS) spectrum, and 802.11 ah can support 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. A possible use case for 802.11 ah is support for meter type control (MTC) devices in a macro coverage area. MTC devices can not only have limited capabilities including support for limited bandwidth, but can also include requirements for very long battery life.

[0085] WLAN systems support multiple channels and channel widths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, which can include a channel designated as the primary channel. The bandwidth of the primary channel can (but does not have to) be equal to the largest common operating bandwidth supported by all STAs in the BSS. Thus, the bandwidth of the primary channel can be limited by a STA (which supports the smallest bandwidth operating mode) of all STAs operating in the BSS. In the example of 802.11ah, if there is a STA (e.g., MTC-type device) that only supports the 1 MHz mode, the primary channel can be 1 MHz wide even if other STAs in the AP and BSS can support 2 MHz, 4 MHz, 8 MHz, 16 MHz, or other channel bandwidth operating modes. All carrier sensing and NAV settings can depend on the status of the primary channel; that is, if the primary channel is busy, for example, due to a STA that only supports the 1 MHz operating mode transmitting to the AP, then the entire available frequency band can be considered busy even if most of the frequency band remains idle and available.

[0086] Today, the available frequency band that 802.11ah can use in the United States can be from 902 MHz to 928 MHz. Today, in Korea, the available frequency band that 802.11ah can use can be from 917.5 MHz to 923.5 MHz; and in Japan, the available frequency band that 802.11ah can use can be from 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.

[0087] IEEE 802.11 TM High-efficiency WLAN (HEW) can include amendments to improve the quality of service for a broad spectrum of wireless users to improve all user experiences in many usage scenarios, including high-density scenarios in the 2.4 GHz, 5 GHz, and 6 GHz bands. New use cases can be considered that support dense deployment of APs, STAs, and associated wireless resource management (RRM) techniques.

[0088] Potential applications for HEW can include emerging usage scenarios such as data delivery for sporting events, high user density scenarios such as train stations or enterprise / retail environments, and there is also evidence of growing dependence on video delivery and wireless services for medical applications.

[0089] Measured traffic for multiple applications can have a high likelihood of being short packets, and network applications can also generate short packets. Such applications can include virtual offices; transmit power control (TPC) acknowledgements (ACKs); video stream ACKs; devices / controllers (mouse, keyboard, game control, etc.); access-probe request / response; network selection-probe request, access network query protocol (ANQP); and / or network management-control frame applications.

[0090] 802.11ax can include MU features including UL and DL OFDMA and UL and DL multi-user MIMO (MU-MIMO). Mechanisms for multiplexing UL random access can be designed and defined for different purposes in the specification.

[0091] 802.11ax can address media access issues in the 6 GHz band, such as by using only triggered or scheduled media access in the 6 GHz band, and / or limiting active scanning and having enhanced distributed channel access (EDCA) media access scheduled in the 6 GHz band.

[0092] IEEE 802.11bc can include MAC amendments for enhanced broadcast services (eBCS) for 802.11 devices. The IEEE 802.11bc amendment can not impact the current IEEE 802.11 PHY specification.

[0093] The eBCS service can include downlink from an AP STA to non-AP STAs, or can include uplink from sensor non-AP STAs. The enhanced broadcast service can be provided to STAs associated with a particular AP or not. An AP can support up to 3000 non-AP STAs with eBCS service. In addition, there can be a class of low-cost non-AP STAs that use eBCS service that can not be able to transmit directly to the AP.

[0094] Some example use cases for eBCS can include sports stadium video broadcast; car broadcast; uplink sensor data broadcast; museum information and multi-language broadcast; and / or event producer information and content broadcast.

[0095] Under the downlink broadcast use case, an eBCS AP can provide broadcast service to STAs associated with it or not associated with the AP. Since broadcast frames can not be acknowledged, it can not always be clear whether there are any STAs that are utilizing the broadcast service and receiving the broadcast data. If the broadcast data is not received, the AP will waste both power and wireless medium resources. Some implementations provide broadcast service mechanisms to facilitate broadcast service that is power efficient and can provide broadcast service only when and / or as the service is actively used.

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

[0097] Some implementations provide an end-broadcast-service announcement information element. In some implementations, an AP can transmit an end-broadcast-service announcement frame, or a frame containing an end-broadcast-service announcement information element, to announce that one or more eBCS services will end.

[0098] The example values for the various fields and subfields discussed herein are for illustration only and it is noted that any other suitable values can be used to indicate the same information or different information in other implementations. For example, in some implementations, a bit value of 1 in a field can indicate certain information, while a bit value of 0 in the field can indicate the same information.

[0099] Figure 2 is a bit map diagram illustrating an example format of an end-broadcast-service announcement information element. The end-broadcast-service announcement information element can include one or more of the following fields: an element identifier (ID) 202, a length 204 and element ID extension 206, a number of broadcast services field 208, and one or more broadcast service fields 210. The element identifier (ID) field 202, the length field 204, and the element ID extension field 206 can indicate that the current element is an end-broadcast-service announcement information element, and can indicate the length of the current element. The number of broadcast services field 208 can indicate the number of broadcast service fields that the element includes. Each of the one or more broadcast service fields 210 can include information for a particular broadcast service, including some or all of the fields described below for each broadcast service.

[0100] The one or more broadcast service fields 210 can have a format as shown in Figure 2 and can include one or more of the following fields: a broadcast service information control field 212; a broadcast service ID field 214; a higher 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 can be 1 byte in length, while the higher layer destination address field 216 and the title field can be variable byte length.

[0101] Figure 3 is a bit map diagram illustrating an example format of a broadcast service information control field 212. The broadcast service information control field 212 can be 1 byte in length, and can include an indication of whether certain broadcast information is contained in the broadcast service field 210. The broadcast service information control field 212 can include one of the following subfields: a broadcast service ID present subfield 302, a higher layer protocol subfield 304, a title present subfield 306, a negotiation method present subfield 308, an association required subfield 310, and a reserved subfield 312.

[0102] The length of the Broadcast Service ID present subfield 302 can be one bit and indicates whether a Broadcast Service ID is included in the Broadcast Service field. The length of the Higher Layer Protocol subfield 304 can be three bits and can contain a value indicating that no Higher Layer Destination Address is present in the Broadcast Service field 210 or that a Higher Layer Destination Address is present, and can contain a value indicating that the Higher Layer Destination Address present in the Broadcast Service field 210 can be an address associated with one of the Higher Layer Protocols UDP / IPv4; UDP / IPv6; UDP / Host Name; MPEG Transport Stream Identifier; MAC Address; or Reserved.

[0103] The length of the Title Present subfield 306 can be one bit and can indicate whether a user-readable title is present in the Broadcast Service field 210. If the Title Present subfield 306 bit is set to one, a Title Length subfield 218 and a Title subfield 220 can be included in the Broadcast Service field 210. The length of the Negotiation Method Present subfield 308 can be one bit and can indicate whether a Negotiation Method subfield 224 is included in the Broadcast Service field 210. The length of the Association Required subfield 310 can be one bit and can indicate whether the broadcast service described by the current Broadcast Service field 210 requires association before another STA utilizes it.

[0104] Referring back to Figure 2 , the length of the Broadcast Service ID subfield 214 can be one byte and can indicate an identifier of the broadcast service. The Higher Layer Destination Address subfield 216 can take different lengths, for example, depending on the value indicated in the Higher Layer Protocol field of the Broadcast Service Information Control subfield. If IPv4 / UDP or IPv6 / UDP is indicated in the Higher Layer Protocol subfield 304, the Higher Layer Destination Address subfield 216 can contain an IP address and a UDP port.

[0105] If a MAC address is indicated in the Higher Layer Protocol subfield 304, the Higher Layer Destination Address subfield 216 can include a 6-byte MAC address. If the Higher Layer Protocol subfield 304 indicates that no Higher Layer Destination Address field is present, no Higher Layer Destination Address can be included in the Broadcast Service field 210.

[0106] If the Title Present subfield 306 in the Broadcast Service Information Control subfield 212 is set to one, a Title Length subfield 218 can be included in the Broadcast Service field 210; otherwise it can not be present. The length of the Title Length subfield 218 can be one byte and can indicate the length of the Title subfield 220.

[0107] If the title present subfield 306 in the broadcast service information control subfield 212 is set to 1, a title subfield 220 can be included in the broadcast service field 210; otherwise it can not be present. The title length subfield 218 can be 1 byte in length and can indicate the length of the title subfield 220.

[0108] The termination time subfield 222 can be used to indicate the remaining time until the broadcast service described in this broadcast service field 210 will terminate, unless additional negotiation by one or more STAs that can use the broadcast service. In another example, the termination time subfield 222 can include a time, e.g., a timing synchronization function (TSF) time value or other type of time at which the broadcast service will terminate, unless additional negotiation by the initiator of the broadcast service or other users of the broadcast service. Additionally or alternatively, a timestamp of the current time can be included, such as the current value of the TSF timer.

[0109] If the negotiation method present subfield 308 is set to 1 (or another suitable indication), a negotiation method subfield 224 can be included in the broadcast service field 210. The negotiation method subfield can be used to indicate the negotiation method that should be used to continue negotiating the broadcast service beyond the termination time. The negotiation method subfield can contain one or more of the following values: through a broadcast service request frame, through an ANQP / GAS broadcast service request frame, and / or through IP request (in which case the IP version and IP address needed for negotiation can be included).

[0110] In some implementations, any subset of the fields or subfields of the end broadcast service announcement element 200 can be implemented in any existing or newly designed elements or frames or any fields or subfields or sets or subsets of the PHY and / or MAC header of any management, control, data frames or other headers or other frames.

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

[0112] Figure 4 is an illustration showing an exemplary format of the eBCS termination notification frame action field 400. As Figure 4As shown, the eBCS termination notification frame action field 400 can 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 can be one octet in length, while the eBCS service termination information set field 406 can have a variable length. In some implementations, the eBCS service termination information set field 406 includes one or more of the eBCS service termination information subfields 500.

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

[0114] The eBCS service termination information control subfield 502, the eBCS service ID subfield 504, and the negotiation method subfield 512 can be one octet in length, while the title length subfield 506 and the negotiation method subfield 514 can be zero or one octet in length. The termination time subfield 510 can be two octets in length. The title subfield 508 and the negotiation address subfield 516 can be variable octets in length.

[0115] Figure 6 FIG. 6 is a diagram illustrating an exemplary format of the eBCS service termination information control subfield 502. As shown, the eBCS service termination information control subfield 502 can include a title present indicator subfield 602, a negotiation address present indicator subfield 604, an association required subfield 606, and / or a reserved subfield 608. Figure 6

[0116] ​​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 required subfield 606 indicates that an association is required to use 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 use the eBCS service identified by the eBCS service ID included in the eBCS service ID subfield 504.

[0117] Referring back to Figure 5In some implementations, the eBCS Service ID subfield 504 is 1 octet in length. In some implementations, the eBCS Service ID subfield 504 indicates an ID of an eBCS service to be terminated. In some implementations, the header length subfield 506 is 1 octet in length. In some implementations, the header length subfield 506 indicates a length of the header subfield 508 in octets. In some implementations, the header subfield 508 indicates a header of an eBCS service identified by the eBCS service ID contained in the eBCS Service ID subfield 504. In some implementations, the header subfield 508 indicates the header in 8-bit Unicode Transformation Format (UTF-8) format. In some implementations, the termination time subfield 510 is 2 octets in length. In some implementations, the termination time subfield 510 indicates a number of beacon scheduled transmission times (TBTTs) before an eBCS service identified by the eBCS service ID contained in the eBCS Service ID subfield 504 is terminated. In some implementations, the termination time subfield 510 can indicate in other time formats, such as milliseconds (ms), microseconds (us), time units (TUs), or any other type of time unit. In some implementations, a value of 0 indicates that the eBCS service identified by the eBCS service ID in the same eBCS Service ID subfield 504 does not have a specific termination time. In some implementations, some other value, e.g., a maximum value of the termination time subfield, indicates that the eBCS service identified by the eBCS service ID in the same eBCS Service ID subfield 504 does not have a specific termination time, or that the eBCS service identified by the eBCS service ID in the same eBCS Service ID subfield 504 has a termination time that is greater than the maximum value that can be contained by the termination time subfield 510.

[0118] 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 used to negotiate an extension of an eBCS service identified by the eBCS service ID contained in the eBCS Service ID subfield 504. Exemplary encodings of the negotiation method subfield 512 are defined in Table 1 below. Other values can be used to indicate the same negotiation methods detailed in Table 1.

[0119] Table 1

[0120] Negotiation Method Subfield Encoding

[0121] Negotiation Method Subfield Values Meaning 0 No negotiation 1 Negotiation via eBCS Service Request frame 2 Negotiation via ANQP / GAS eBCS Service Request frame 3 Negotiation via IP request 4-7 Reserved

[0122] In some implementations, the negotiation address type subfield 514 is 1 octet in length. In some implementations, the negotiation address type subfield 514 indicates a type of address included in the negotiation address subfield 516. Exemplary encodings for the negotiation address type subfield 514 are defined in Table 2.

[0123] Table 2

[0124] Negotiation Address Type Subfield Encoding

[0125] Negotiation Address Type Values Meaning 0 MAC address 1 UDP / IPv4 address 2 UDP / IPv6 address 3 UDP / host name 4 MPEG Transport Stream Identifier 5-7 Reserved

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

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

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

[0129] Figure 9is an illustration showing an exemplary format of the negotiated address subfield 516, for example, when the negotiated address type is equal to 3 (or another suitable value indicating this). In some implementations, the host name length subfield 902 indicates the length of the host name subfield, for example, in octets. In some implementations, the host name subfield 904 indicates a host name for negotiating extensions of eBCS services, for example, in UTF-8 format. In some implementations, the destination UDP port subfield 906 indicates a UDP port, for example, in little-endian format, that is associated with the host name indicated in the host name subfield.

[0130] Figure 10 is an illustration showing an exemplary format of the negotiated address subfield 516, for example, when the negotiated 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 an MPEG transport stream ID, for example, in UTF-8 format.

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

[0132] An AP can advertise a broadcast service using a broadcast service element in its beacons, probe responses, eBCS service advertisement frames, and / or eBCS information frames, among others. Some broadcast services can be allocated specific time and / or frequency resources. These time and frequency resources can utilize certain periodic broadcasts.

[0133] Broadcast services can be requested by STAs that can be associated or unassociated with the AP, or that can request broadcast services through other means, such as through IP protocols. When requesting a broadcast service, a STA can request the broadcast service for a certain period of time. For example, a STA can request a video playback for 10 minutes. STAs requesting the same or similar services can be grouped by the AP. Broadcast service periodicity can be modified by the AP based on explicit or implicit STA or group of STAs demand.

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

[0135] An AP can indicate one or more broadcast services that the AP is providing, e.g., by including one or more end-broadcast-service-announcement elements in one or more frames that it is transmitting (e.g., in a beacon frame, a probe response frame, an eBCS data frame, a broadcast service request frame, an eBCS service advertisement frame, and / or an eBCS information frame, etc.). The AP can include a negotiation method required for any STA, the focus of which is to continue a broadcast service beyond a termination time to negotiate for the broadcast service beyond the indicated termination time. The AP can indicate that one or more broadcast services that it is providing will be broadcast with a particular periodicity until its end.

[0136] A STA that is utilizing or plans to utilize a broadcast service can receive one or more frames that can contain end-broadcast-service-announcement information or elements for the broadcast service. If the STA desires to utilize the broadcast service beyond the indicated termination time, it can follow the negotiation method indicated by the AP to negotiate with the AP in order to continue the broadcast service.

[0137] If the broadcast service requires association (e.g., as indicated in the association required subfield) and is negotiated through a broadcast service request frame, the STA can go through an association procedure with the AP. If the STA is already associated with the AP, the STA can send a broadcast service request frame indicating that it desires one or more broadcast services. The STA can indicate that it desires the one or more broadcast services for a certain period of time or with a certain periodicity. The AP can respond with a broadcast service response frame indicating that the broadcast service will continue for a longer period of time and / or periodicity. If a second STA desires the same broadcast service and it receives a frame containing an end-broadcast-service-announcement element or information indicating that the broadcast service has been extended, it can cancel any pending broadcast service request frame that it plans to send to the AP.

[0138] If the broadcast service does not require association (e.g., as indicated in the association required subfield) and is negotiated through an ANQP / GAS broadcast service request frame, the STA can send an ANQP / General Advertisement Service (GAS) broadcast service request frame indicating that it desires or registers for one or more broadcast services. The STA can indicate that it desires or can register for the one or more broadcast services for a certain period of time. The AP can respond with an ANQP / GAS broadcast service response frame indicating that the broadcast service will continue for a longer period of time. If a second STA desires the same broadcast service and it receives a frame containing an end-broadcast-service-announcement element or information indicating that the broadcast service has been extended, it can cancel any pending ANQP / GAS broadcast service request frame that it plans to send to the AP.

[0139] If the broadcast service does not require association (e.g., as indicated in the association required subfield) and is negotiated over an IP protocol (e.g., IPv4 and IPv6 with appropriate IP addresses), the STA can send an IP packet over another interface indicating that it desires one or more broadcast services or registers for one or more broadcast services. The STA can indicate that it desires or registers for one or more broadcast services for a certain period of time. The AP can 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 an end broadcast service announcement frame indicating that the broadcast service will continue for a longer period of time. If a second STA desires the same broadcast service and it receives a frame containing an end broadcast service announcement element or information indicating that the broadcast service has been extended, it can cancel any pending IP packets requesting continuation of the broadcast service.

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

[0141] In some implementations, if one or more eBCS services being transmitted are to be terminated within a time interval (e.g., equal to or shorter than a certain time, such as dotll eBCS T- termination notification time), the eBCS STA broadcasting the one or more eBCS services shall start transmitting eBCS service termination notification frames if the STA is not periodically transmitting a schedule for the eBCS services to be terminated. In some implementations, if one or more eBCS services are to be terminated within a time interval (e.g., equal to or shorter than a certain time, such as dotll eBCS T- termination notification time), the eBCS STA shall start transmitting eBCS service termination notification frames if the STA is not periodically transmitting a schedule for the eBCS services to be terminated. In some implementations, if one or more eBCS services are to be terminated within a time interval (e.g., equal to or shorter than a certain time, such as dotll eBCS T- termination notification time), the eBCS STA shall start transmitting eBCS service termination notification frames. In some implementations, if an eBCS STA starts transmitting eBCS service termination notification frames, the STA shall transmit eBCS service termination notification frames with a periodicity that is, for example, greater than a minimum interval, such as dotll eBCS T- termination notification minimum time interval, and less than a maximum interval, such as dotll eBCS T- termination notification maximum time interval.

[0142] In some implementations, an eBCS STA transmitting eBCS service termination notification frames indicates in a termination time subfield in an eBCS service termination information subfield the number of TBTTs before termination of an eBCS service identified by an eBCS service ID contained in an eBCS service ID subfield in the same eBCS service termination information subfield. In some implementations, the termination time subfield can be indicated in other time formats, such as milliseconds, microseconds, time units (TUs), or any other type of time unit.

[0143] In some implementations, an eBCS STA transmitting eBCS service termination notification frames shall indicate in a negotiation method subfield in an eBCS service termination information subfield a negotiation method that the STA shall use for negotiation of extension for an eBCS service identified by an eBCS service ID contained in an eBCS service ID subfield in the same eBCS service termination information subfield. In some implementations, the eBCS STA can indicate that no negotiation is available.

[0144] In some implementations, an eBCS STA that transmits an eBCS service termination notification frame can indicate in the negotiation address subfield in an eBCS service termination information subfield an address associated with the negotiation method indicated in the negotiation method subfield in the same eBCS service termination information subfield that the STAs should use to negotiate for the extension of the eBCS service identified by the eBCS service ID contained in the eBCS service ID subfield in the same eBCS service termination information subfield.

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

[0146] In some implementations, after transmitting an eBCS service termination notification frame, if the eBCS has negotiated to another duration or has a new termination time value, the eBCS STA should transmit an eBCS service information frame or other type of frame with an updated value in the termination time subfield or eBCS service duration subfield.

[0147] In some implementations, an eBCS STA that receives an eBCS service termination notification frame can negotiate for the extension of the eBCS service, for example, if the eBCS service indicated in one of the eBCS service termination information subfields terminates earlier than expected. In some implementations, the eBCS STA can negotiate for the extension of the eBCS service, for example, using the negotiation method indicated in the negotiation method in the eBCS service termination information subfield, and in some implementations, can follow the procedures defined in the 802.11 specification, for example, 11.22.6.x (eBCS service negotiation procedures for associated STAs) and 11.23.3.3 (ANQP procedures).

[0148] In some implementations, eBCS STAs receiving the eBCS service information frame or any other timeframe can negotiate for the extension of the eBCS service, e.g., if the eBCS service terminates earlier than expected. In some implementations, eBCS STAs can negotiate for the extension of the eBCS service, e.g., using the negotiation method indicated in the negotiation method in the eBCS service termination information subfield, and in some implementations, can follow procedures defined in the 802.11 specification, e.g., 11.22.6.x (eBCS service negotiation procedure for associated STAs) and 11.23.3.3 (ANQP procedure).

[0149] In some implementations, if a STA receives an eBCS service termination announcement frame with an acceptable termination time value or duration value contained in the eBCS service termination information subfield containing the eBCS service ID of the eBCS service or contained in the eBCS service information frame or other type of frame for the same eBCS service, the eBCS STA shall skip transmitting any eBCS service request frame or frame containing an enhanced broadcast request ANQP-element or any frame containing IP frames requesting the eBCS service.

[0150] Some implementations include an end broadcast service announcement indication procedure with a trigger mechanism. In some implementations, after an AP transmits an end broadcast service announcement indication (EBSAI) through a management or control frame or with any type of frame, STAs that can intend to remain with the current service or negotiate a new broadcast service can respond. More than one STA can need to transmit in response to the EBSAI.

[0151] Figure 11 is a signal diagram illustrating an example multiple access procedure. As shown in Figure 11 The AP can transmit a frame with the EBSAI. The detailed frame format can be as described herein, e.g., with respect to the end broadcast service announcement information element and / or the end broadcast service announcement indication procedure.

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

[0153] One or more STAs can transmit a response to the EBSAI such that the STAs can keep the originally negotiated broadcast service, can modify the originally negotiated broadcast service, e.g., to continue the service beyond the termination time, and / or can request to start a new broadcast negotiation for a certain time period and periodicity.

[0154] The STAs can use one or more of the same response method, a trigger-based random access method, and / or a trigger-based probe request method to transmit the EBSAI response.

[0155] In an example same response method, a common end-broadcast response frame / field / element / physical layer protocol data unit (PPDU) can be defined such that STAs that can intend to respond can transmit the same physical layer packet at the same time. The AP can be able to detect the simultaneous transmissions from the STAs, e.g., because the transmissions are identical.

[0156] In some implementations, e.g., the same response method, the STAs can be able to indicate a single message, e.g., that the STAs prefer to keep the originally negotiated broadcast service. In some implementations, a null data packet (NDP) EBSAI response PPDU can be used for such an EBSAI response. The NDP EBSAI response PPDU can carry a short training field (STF) and a long training field (LTF) and a signal training field (SIG) field (in addition, a legacy preamble field can be reserved for backwards compatibility). The SIG field can be modified to indicate that the STAs can prefer to keep the original negotiation. Alternatively, the SIG field can be omitted and the current NDP transmission can indicate that the STAs prefer to keep the original settings. The PPDU can be transmitted by one or more STAs within xIFS after the trigger frame. With this method, STAs that can want to terminate the broadcast service can not need to respond and STAs that can want to continue the broadcast service can respond.

[0157] In some implementations, such as the same response method, a STA can be able to carry several messages (e.g., M messages). Examples of such messages can include keep original negotiation, modify original negotiation, start new negotiation, etc. In one design, a NDP EBSAI response PPDU can be used for such EBSAI responses. The NDP EBSAI response PPDU can carry STF and LTF and SIG fields (which can be reserved legacy preamble fields). Some of the above-mentioned fields can be transmitted in partial bandwidth. The transmission location can indicate the message it can carry. For example, the entire bandwidth can be allocated as M blocks. If the STF and / or LTF and / or SIG fields can be transmitted through the first frequency block, it can indicate the first message. If the STF and / or LTF and / or SIG fields can be transmitted through the second frequency block, it can indicate the second message, etc. The PPDU can be transmitted immediately within xSIF after the trigger frame. In one method, the mapping of frequency resources and messages can be predefined and no signaling is needed. In one method, the mapping of frequency resources and messages can be carried in the trigger frame.

[0158] In an example trigger-based random access method, one or more resource units in a resource unit can be allocated for response transmission. The resource allocation can be included in a trigger frame. A STA can start an OFDMA random access procedure to select one or more resource units to transmit its own response frame. The response frame can be a standard MAC frame, which can carry transmit (Tx) and / or receive (Rx) addresses and other fields normally defined in a MAC header. In addition, it can carry EBSAI response related information.

[0159] In an example trigger-based probe request method, one or more resource units in a resource unit can be allocated for such response transmission. The resource allocation can be included in a trigger frame. An irrelevant STA can use a probe request management frame to select one or more resource units to transmit a frame. Such response frame can contain additional information beyond what is currently available in these management frames to negotiate / re-negotiate a broadcast service.

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

[0161] Figure 12is a bitmap illustration showing an exemplary format of an eBCS service capability element. The eBCS service capability element can contain one or more of the following subfields: element ID subfield 1202, length subfield 1204, element ID extension subfield 1206, sequence number subfield 1208, number of fragments subfield 1210, fragment index subfield 1212, DL broadcast capability subfield 1214, number of broadcast services subfield 1216, eBCS 1 through eBCS N subfields 1218, broadcast information control subfield 1220, broadcast ID subfield 1222, eBCS type subfield 1224, association requirement subfield 1226, UL transmission requirement subfield 1228, broadcast parameters subfield 1230, broadcast security subfield 1232, higher layer destination address subfield 1234, title present subfield 1236, title length subfield 1228, title subfield 1240, termination time subfield 1242, broadcast control subfield 1244, and / or the like as Figure 12 or otherwise arranged or other subfields. Examples of such subfields are described below.

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

[0163] The sequence number subfield 1208 can indicate the sequence number of the eBCS service capability element

[0164] Number of fragments: The number of fragments subfield 1210 can indicate the number of fragments that the eBCS capability element identified by the sequence number can be divided into.

[0165] The fragment index subfield 1212 can indicate the index of the fragment of the eBCS capability element contained in the current eBCS capability element.

[0166] The eBCS 1 through eBCS N subfields 1218 can include N subfields that can be contained in the broadcast element, where each field can be used to specify a particular broadcast service that is provided by the transmitting STA (e.g., the transmitting AP). Each eBCS field can include one or more of the following subfields: broadcast information control subfield 1220; broadcast ID subfield 1222; eBCS type subfield 1224; association requirement subfield 1226; UL transmission requirement subfield 1228; broadcast parameters subfield 1230; and / or broadcast security subfield 1232.

[0167] The length of the broadcast information control field 1220 can be 1 byte and can include certain indications of whether certain broadcast information is included in the eBCS N field. The length of the broadcast ID subfield 1222 can be 1 bit and indicates whether a broadcast ID is included in the eBCS N field.

[0168] The length of the higher layer destination address subfield 1234 can be three bits and can indicate one of the following values: no higher layer destination address is present in the eBCS N field, a higher layer destination address is present and the higher layer protocol can include: UDP / IPv4; UDP / IPv6; UDP / Host Name; MPEG Transport Stream Identifier; MAC Address; and / or reserved. The length of the title present subfield 1236 can be 1 bit and can indicate whether a user-readable title is present in the eBCS N field. If the title present bit is set to 1, a title length subfield 1238 and a title subfield 1240 can be included in the eBCS N field. The length of the broadcast control present subfield can be 1 bit and can indicate whether a negotiation method subfield is included in the eBCS N field.

[0169] The broadcast ID subfield 1222 can indicate the ID of a 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 belongs to the categories of vehicular, directional, 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).

[0170] The association required subfield 1226 can indicate whether association is required to use one or more broadcast services, for example, identified by the broadcast ID. The UL transmission required subfield 1228 can indicate whether UL transmission is required to use one or more broadcast services, for example, identified by the broadcast ID.

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

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

[0173] For example, if the title present subfield 1236 in the broadcast service information control subfield is set to 1, a title length subfield 1238 can be included in the broadcast service field; otherwise it can not be present. The title length field can be 1 byte in length and can indicate the length of the title subfield 1240.

[0174] For example, if the title present subfield 1236 in the broadcast service information control subfield is set to 1, a title subfield 1240 can be included in the broadcast service field; otherwise it can not be present. The title length field can be 1 byte in length and can indicate the length of the title subfield 1240.

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

[0176] For example, if the broadcast control present subfield is set to 1 in the broadcast information control subfield 1220, the broadcast control subfield 1244 can be included in the eBCS N field. The broadcast control subfield 1244 can be used to indicate the negotiation method that should be used for negotiation for initialization, control, or stop of the broadcast service. The broadcast control subfield 1244 can include one or more of the following values: through a broadcast service request frame; through an ANQP / GAS broadcast service request frame; and / or through an IP request (in which case, the IP version and IP address needed for the negotiation can be included.)

[0177] In some implementations, any subset of the fields or subfields of the eBCS service capabilities element or eBCS service advertisement frame can be implemented in any existing or newly designed elements or frames of any management, control, and data frames or other headers or other frames or any fields or subfields or sets or subsets of the PHY and / or MAC headers.

[0178] Some implementations include an eBCS service request frame format. In some implementations, the eBCS service request frame format can be defined as follows. The eBCS service request frame can include an eBCS service request element. Such an eBCS service request element can also be included in other frames, such as a probe request frame, an association request frame, an ANQP / GAS eBCS service request frame, or any other type of frame, e.g., for requesting one or more eBCS services.

[0179] Figure 13 is a bitmap illustration showing an example format of an eBCS service request element. As Figure 13 shown, in some implementations, the eBCS service request element can contain one or more of the following fields: element ID 1302, length 1304, element ID extension 1306, number of broadcast service fields 1308, and / or one or more broadcast service fields 1310.

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

[0181] The number of broadcast service fields field 1308 can be used to indicate the number of broadcast service fields included by the element.

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

[0183] The broadcast service information control field subfield 1312 can be 1 byte in length and can include an indication of whether certain 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 higher layer destination address subfield 1316 can be variable bits depending on the value indicated in the higher layer protocol field of the broadcast service information control subfield 1312. If IPv4 / UDP or IPv6 / UDP is indicated in the higher layer protocol field, the higher layer destination address subfield 1316 can contain an IP address and UDP port. If a MAC address is indicated in the higher layer protocol subfield, it can contain a 6 byte MAC address. If the higher layer protocol subfield 1316 indicates that there is no higher layer destination address field, the higher layer destination address is not included in the broadcast service field.

[0184] The title length subfield 1318 can be included in the broadcast service field 1310 if the title present subfield in the broadcast service information control subfield is set to 1; otherwise it is not present. The title length field 1318 can be 1 byte in length and indicates the length of the title field. The title subfield 1320 can be included in the broadcast service field if the title present subfield 1406 in the broadcast service information control subfield 1312 is set to 1; otherwise it is not present. The title length subfield 1318 can be 1 byte in length and indicates the length of the title subfield 1320. The title subfield can be a variable byte length.

[0185] The request duration subfield 1322 can be 1 byte in length and can be used to indicate the request duration of the requested broadcast service. The request parameters subfield 1324 can be 1 byte in length and can indicate the request parameters for the requested broadcast service, such as a time offset from a fixed time reference point (e.g., TBTT), channel, RU resources, frequency band, broadcast rate, etc.

[0186] Figure 14is an illustration showing 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 present subfield 1402, a higher layer protocol 1404 subfield, a title present subfield 1406, a request duration present subfield 1408, and a request parameters present subfield 1410. The broadcast service information control field subfield 1312 can also have a reserved subfield 1412.

[0187] The broadcast service ID present subfield 1402 can be one bit in length and can indicate whether a broadcast service ID is included in the broadcast service field 1310. The higher layer protocol subfield 1404 can be three bits in length and can indicate one of the following values: no higher layer destination address present in the broadcast service field 1310, no higher layer destination address and / or a higher layer destination address present. The higher layer protocol subfield 1404 can include: UDP / IPv4, UDP / IPv6, UDP / host name, MPEG transport stream identifier, and / or MAC address. The title present subfield 1406 can be one bit in length and used to indicate whether a user-readable title is present in the broadcast service field 1310. If the title present bit is set to one, a title length subfield and a title subfield can be included in the broadcast service field 1310. The negotiation method present subfield: this subfield can be one bit in length and can be used to indicate whether a negotiation method subfield is included in the broadcast service field.

[0188] The request duration present subfield 1408 can be one bit in length and can indicate whether a request duration for a requested broadcast service is present in the broadcast service field 1310. The request parameters present subfield 1410 can be one bit in length and can indicate whether request parameters for a requested broadcast service are present in the broadcast service field 1310.

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

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

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

[0192] The element ID field 1502, the length field 1504, and the 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 field 1510 can indicate the number of broadcast service fields that the element includes.

[0193] Each of the one or more broadcast service fields in the broadcast service fields 1510 can include response information for a particular broadcast service being requested, and can include one or more of the following: a broadcast service information control field 1512, a broadcast service ID field 1514, a higher layer destination address subfield 1516, a title length field 1518, a title field 1520, a status field 1522, a broadcast service duration field 1524, and / or a broadcast service parameters field 1526.

[0194] The broadcast service information control field 1512 can be 1 byte in length, and can include an indication of whether certain broadcast information is contained in the broadcast service field 1510.

[0195] Figure 16 An exemplary format of the broadcast service information control subfield 1512 is shown. As shown, the broadcast service information control field 1512 can include a broadcast service ID present subfield 1602, a higher layer protocol subfield 1604, a title present subfield 1606, a broadcast service duration present subfield 1608, a broadcast service parameters present subfield 1610, and / or a reserved subfield 1612. Figure 16 The broadcast service ID present subfield 1602 can be 1 bit in length, and indicates whether a broadcast service ID is included in the broadcast service field. The higher layer protocol subfield 1604 can be three bits in length, and can indicate one or more of the following values: no higher layer destination address present in the broadcast service field, a higher layer destination address present (the higher layer protocol can be and / or indicated as: UDP / IPv4, UDP / IPv6, UDP / host name, MPEG transport stream identifier, MAC address, and / or reserved).

[0196]

[0197] ​The length of the title present subfield 1606 can be 1 bit and can indicate whether a user-readable title is present in the broadcast service field 1510. If the title present bit is set to 1, a title length subfield 1518 and a title field 1520 can be included in the broadcast service field 1510.

[0198] The length of the broadcast service duration present subfield 1608 can be 1 bit and can indicate whether a broadcast service duration for the offered broadcast service is present in the broadcast service field 1510. The length of the broadcast service parameters present subfield 1610 can be 1 bit and can indicate whether broadcast service parameters for the requested broadcast service are present in the broadcast service field 1510.

[0199] Referring back to Figure 15 , the broadcast service ID field 1514 can indicate an identifier of the broadcast service and can be 1 byte in length. The higher layer destination address subfield 1516 can have different lengths, for example, depending on the value indicated in the higher layer protocol field of the broadcast service information control subfield. If IPv4 / UDP or IPv6 / UDP is indicated in the higher layer protocol subfield 1604, the higher layer destination address subfield 1516 can include an IP address and a UDP port. For example, if a MAC address is indicated in the higher layer protocol subfield 1604, the higher layer destination address subfield 1516 can include a MAC address, for example, 6 bytes. For example, if the higher layer protocol subfield indicates that no higher layer destination address field is present, no higher layer destination address can be included in the broadcast service field 1510. For example, if the title present subfield 1606 in the broadcast service information control subfield 1512 is set to 1, a title length subfield 1518 can be included in the broadcast service field 1510; otherwise it can not be present. The length of the title length field 1518 can be 1 byte and can indicate the length of the title subfield 1520. For example, if the title present subfield in the broadcast service information control subfield 1512 is set to 1, a title length subfield 1520 can be included in the broadcast service field 1510; otherwise it can not be present.

[0200] The status subfield 1522 can indicate whether the request for the broadcast service was successful. The status subfield can also contain a rejection reason if the request was rejected. The broadcast service duration subfield can indicate the duration of the offered broadcast service. The broadcast service parameters subfield can indicate parameters for the offered broadcast service, such as a time offset compared to a fixed time reference point (e.g., TBTT), a channel, RU resources, a frequency band, a broadcast rate, etc.

[0201] In some implementations, any subset of fields or subfields of eBCS service response elements can be implemented in any existing or newly designed elements or frames or any fields or subfields or sets or subsets of PHY and / or MAC headers of any management, control, data frames or other headers or other frames, such as EBCS request frames

[0202] Some implementations include eBCS service request / response procedures. Some implementations include eBCS service request / response procedures for unassociated STAs. In some implementations, eBCS service negotiation procedures for unassociated STAs can be as follows.

[0203] In some implementations, an AP can advertise one or more broadcast services, e.g., using broadcast service elements in its beacons, probe responses, eBCS service advertisement frame sequences, eBCS information frames, etc., and / or simply using probe responses, eBCS service advertisement frames, eBCS information frames, or eBCS termination notification frames, etc. The AP can indicate the negotiation method for one or more eBCS services, such as through ANQP / GAS frame exchanges, through probe request frames, through eBCS service request / response frames, or through IP packets.

[0204] After receiving a frame from an AP or from pre-acquired information, such as an EBCS information frame, an EBCS termination notification frame, or an EBCS ANQP service frame, or through ANQP / GAS frame exchanges from one or more APs, an unassociated STA can discover a desired broadcast service. The STA can request one or more broadcast services that the AP is capable of providing but is not currently providing, which do not require association. The STA can follow the negotiation method (e.g., as indicated by the AP of the eBCS service) and can send a frame to the AP, such as an ANQP / GAS broadcast service request frame or a public action frame containing an eBCS service request element or information. The requested broadcast service can be indicated by certain IDs, such as a broadcast service ID, a higher layer destination address, a MAC address, a title, etc. When a broadcast service is being requested, the STA can request the broadcast service for a certain time period, e.g., the STA can request a video playback for 10 minutes. The STA can also request certain parameters for the broadcast service, such as a broadcast frequency, a data rate to use, for a particular channel or RU.

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

[0206] Some implementations include an eBCS service request / response procedure for an associated STA. In some implementations, an eBCS service negotiation procedure for an associated STA can be as follows. The AP can advertise one or more broadcast services, e.g., using a broadcast service element in its beacon, a probe response, an eBCS service advertisement frame, an eBCS information frame, etc., or simply using a probe response, an eBCS service advertisement frame, an eBCS information frame, an eBCS termination notification frame, etc. The AP can indicate a negotiation method for one or more eBCS services, e.g., through ANQP / GAS frame exchange, through a probe request frame, through an eBCS service request / response frame, and / or through IP packets. The AP can indicate that association to one or more eBCS services is required to utilize those eBCS services.

[0207] After receiving frames (such as EBCS information frames, EBCS termination notification frames, or EBCS ANQP service frames) from an AP or from pre-acquired information, and / or through ANQP / GAS frame exchanges from one or more APs, a STA can discover a desired broadcast service. One or more broadcast services that the AP is capable of providing but is not currently providing can be requested by the STA, which requires association. If the STA is not currently associated with the AP, the STA can authenticate and associate with the AP. The STA can follow the negotiation method indicated by the AP for the eBCS service and can send a frame (such as an eBCS service request frame, or a frame containing an eBCS service request element or information) to the AP, which can also be included in a probe request frame and / or an association request frame. The requested broadcast service can be indicated by certain IDs (such as a broadcast service ID, a higher layer destination address, a MAC address, a title, etc.). The STA can request a broadcast service for a certain time period when the broadcast service is being requested. For example, the STA can request a video playback for 10 minutes. The STA can also request certain parameters for the broadcast service, such as a broadcast frequency, a data rate used, for a certain channel or RU.

[0208] The AP can respond to the eBCS service request by sending an eBCS response frame or a frame containing an eBCS service response frame or information, including probe response and association response frames. If the eBCS service requires association, the AP can not start the eBCS (enhanced broadcast service) service until the STA is fully associated with the AP. The AP can indicate the status of the request for one or more eBCS services, such as success, rejection, and it can include a rejection reason. The AP can indicate the remaining time of the broadcast service it is providing. For example, the AP can include a broadcast service duration in an eBCS service response element, or include an end broadcast service announcement element, for example periodically, in one or more frames it is transmitting (e.g., in a beacon frame, a probe response frame, an eBCS data frame, a broadcast service request frame, an eBCS service advertisement frame or an eBCS information frame, an eBCS termination notification frame, etc.). If the request for the eBCS service is successful, the AP can also include broadcast service parameters, such as a broadcast frequency, a broadcast service periodic duration, a data rate used, for a certain channel or RU. The AP can start providing the requested eBCS service accordingly thereafter.

[0209] Some implementations include an eBCS service request / response procedure for receive-only STAs. In some implementations, the eBCS service negotiation procedure for receive-only STAs is as follows. An AP can advertise one or more broadcast services using broadcast service elements in its 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 can indicate the negotiation method for one or more eBCS services, such as through ANQP / GAS frame exchanges, through probe request frames, through eBCS service request / response frames, and / or through IP packets. The AP can indicate that association is required for one or more eBCS services to utilize those eBCS services.

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

[0211] If the request is successful, the AP can start providing the requested eBCS service accordingly. The AP can indicate the remaining time for the broadcast service it is providing. For example, the AP can include (e.g., periodically) an end broadcast service announcement element in one or more frames it is transmitting, such as in beacon frames, probe response frames, eBCS data frames, broadcast service request frames, eBCS service advertisement frames, EBCS termination notification frames, and / or eBCS information frames, etc.

[0212] While the features and elements of the various examples described above are presented with specific combinations, each feature or element can be used alone or in various combinations with or without other features and elements of the preferred embodiments. Although the solutions described herein consider 802.11 specific protocols, it should be understood that the solutions described herein are not limited to such scenarios and are applicable to other wireless systems as well.

[0213] Although xIFS and / or SIFS are used in the design and program examples to indicate various interframe spacings, all other interframe spacings such as RIFS, AIFS, DIFS, or other agreed time intervals can be applied to the same solution. Although four RBs per triggered TXOP are shown as an example in some figures, the actual RBs / channels / bandwidth used can vary.

[0214] Figure 17 An example method 1700 of a STA requesting continuation of eNCS service is shown. At step 1702, first, the STA can receive an eBCS termination notification frame from an access point (AP) indicating that an eBCS service being used by the STA is to be terminated. At step 1704, the STA, under conditions where termination is not acceptable, can negotiate to continue the eBCS service. Then, at step 1706, the STA can continue to receive the eBCS service upon successful negotiation to continue the eBCS service. The various steps described in relation to method 1700 are merely examples, and it is noted that other implementations omit some of these steps, include additional steps, or perform steps in different orders.

[0215] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals (optical, electrical or electromagnetic) that are transmittable through a wired or wireless communication means. Examples of computer-readable media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, for example, a hard disk, a floppy disk, or a magnetic strip, magneto-optical media such as, for example, a floptical disk, and optical media such as, for example, a compact disc (CD) and a digital versatile disc (DVD). A processor in association with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented in a station (STA), the method 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 used by the STA is to be terminated; based on the received indication that the eBCS service being used by the STA is to be terminated, negotiating with the AP to continue the eBCS service being used by the STA; and continuing to receive the eBCS service being used by the STA based on the negotiation.

2. The method of claim 1, wherein the enhanced broadcast service (eBCS) termination notification frame further comprises a termination time subfield indicating a number of beacon scheduled transmission times (TBTTs) until the eBCS service being used by the STA is to be terminated.

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

4. The method of claim 1, wherein negotiating with the AP to continue the eBCS service comprises: receiving an indication of a negotiation method from the AP for negotiating an extension to the eBCS service being used by the STA.

5. The method of claim 4, wherein the indication of the negotiation method is included in a negotiation method subfield.

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

7. The method of claim 5, wherein the negotiation method subfield indicates that the STA is to negotiate through one or more eBCS service request frames.

8. The method of claim 5, wherein the negotiation method subfield indicates that the STA is to negotiate through one or more access network query protocol (ANQP) eBCS service request frames.

9. The method of claim 5, wherein the negotiation method subfield indicates that the STA is to negotiate through IP request.

10. A station (STA), the STA comprising: a receiver configured to receive an enhanced broadcast service (eBCS) termination notification frame from an access point (AP), the eBCS termination frame indicating that an eBCS service being used by the STA is to be terminated; a processor and transmitter configured to negotiate with the AP to continue the eBCS service being used by the STA based on the received indication that the eBCS service being used by the STA is to be terminated; and the receiver is further configured to continue to receive the eBCS service being used by the STA based on the negotiation.

11. The STA of claim 10, wherein the enhanced broadcast service (eBCS) termination notification frame further comprises a termination time subfield indicating a number of beacon scheduled transmission times (TBTTs) until the eBCS service being used by the STA is to be terminated. ​ ​ 12. The STA of claim 10, wherein the enhanced broadcast service (eBCS) termination notification frame includes a category field, a public action field, and an eBCS termination information set field.

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

14. The STA of claim 13, wherein the indication of the negotiation method is included in a negotiation method subfield.

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

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

17. The STA of claim 14, wherein the negotiation method subfield indicates that the STA will negotiate through one of a plurality of Access Network Query Protocol (ANQP) eBCS service request frames.

18. The STA of claim 14, wherein the negotiation method subfield indicates that the STA will negotiate through an IP request.

Images