Power-efficient broadcasting over WLAN

Abstract

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

Description

Technical Field

[0001] (Cross - reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 971,621, filed on February 7, 2020, and U.S. Provisional Patent Application No. 63 / 042,059, filed on June 22, 2020, the contents of which are incorporated herein by reference.

Background Art

[0002] A WLAN in Infrastructure Basic Service Set (BSS) mode may include an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. Enhanced Broadcast Service (eBCS) may include a downlink from the AP to non - AP STAs or an uplink from sensor non - AP STAs. The enhanced broadcast service may be provided to both STAs associated with a particular AP and those not associated. Some exemplary use cases for eBCS may include stadium video broadcasting, automotive broadcasting, uplink sensor data broadcasting, museum information and multilingual broadcasting, and / or event producer information and content broadcasting.

Summary of the Invention

[0003] A device, method, and / or system for broadcasting in a wireless local area network (WLAN). The STA receives a frame from a wireless access point (AP) that indicates the termination of an Enhanced Broadcast Service (eBCS) service. The frame may include the end of a broadcast service announcement information element and / or an indicator of the time when the eBCS service will terminate. If the STA wishes to continue receiving the eBCS service beyond the time when the eBCS service will terminate, the STA may negotiate with the AP for the continuation of the broadcast service. The STA may receive a trigger frame from the AP that triggers a response from the STA indicating that the STA wishes to continue receiving the eBCS service beyond the time when the eBCS service will terminate. [Brief explanation of the drawing]

[0004] A more detailed understanding can be obtained from the following explanation, which is given as an example in conjunction with the attached drawings, where similar reference numbers in the drawings indicate similar elements. [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2]This diagram illustrates an exemplary format for the end of a Broadcast Service Announcement information element. [Figure 3] This diagram illustrates an exemplary format for a broadcast service information control field. [Figure 4] This diagram illustrates an example format of the eBCS termination notification frame action field. [Figure 5] This diagram illustrates an example format for the eBCS service termination information subfield. [Figure 6] This diagram illustrates an example format of the eBCS service termination information control subfield. [Figure 7] This diagram illustrates an exemplary format for the negotiation address subfield. [Figure 8] This diagram illustrates an exemplary format for the negotiation address subfield. [Figure 9] This diagram illustrates an exemplary format for the negotiation address subfield. [Figure 10] This diagram illustrates an exemplary format for the negotiation address subfield. [Figure 11] This is a signal diagram illustrating an exemplary multiple access procedure. [Figure 12] This diagram illustrates an example format for eBCS service capability elements. [Figure 13] This diagram illustrates an example format of an eBCS service request element. [Figure 14] This diagram illustrates an exemplary format for a broadcast service information control field. [Figure 15] This diagram illustrates an example format of an eBCS service response element. [Figure 16] This diagram illustrates an exemplary format for the broadcast service information control field in the eBCS service response element. [Figure 17] This section illustrates an exemplary method by which an STA requests the continuation of eNCS services. [Modes for carrying out the invention]

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

[0006] As shown in Figure 1A, the communication system 100 may include radio 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, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, all of which may be referred to as stations (STAs), may be configured to transmit and / or receive radio signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronic devices, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UEs.

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

[0008] Base station 114a may be part of RAN 104, which may also include other base stations such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and / or network elements (not shown). Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a particular geographic area which may be relatively fixed or change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, the base station 114a may use multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0010] More specifically, as described above, the communication 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, etc. For example, the base station 114a of RAN104 and WTRU102a, 102b, 102c can establish an air interface 116 using wideband CDMA (WCDMA), and can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).

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

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

[0013] In one embodiment, base station 114a and WTRU 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRU 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRU 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to and from multiple types of base stations (e.g., eNB and gNB).

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

[0015] The base station 114b in FIG. 1A may be, for example, a wireless router, a home node B, a home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connections in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by drones, for example), a road, or other locations. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (such as WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 in some cases.

[0016] RAN104 may communicate with CN106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 and / or CN106 may communicate directly or indirectly with other RANs using the same RAT or a different RAT as RAN104. For example, in addition to being connected to RAN104 which may utilize NR radio technology, CN106 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0017] CN106 may also function as a gateway to WTRU102a, 102b, 102c, and 102d for access to PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a public switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the transmission control protocol (TCP), the datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs that may use the same RAT as RAN104 or a different RAT.

[0018] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may use cellular-based radio technology, and base station 114b, which may use IEEE 802 radio technology.

[0019] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0020] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to a transmit / receive element 122. Figure 1B shows the processor 118 and transceiver 120 as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

[0022] Although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 116.

[0023] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

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

[0026] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may determine its location by receiving location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method, while maintaining consistency with one embodiment.

[0027] The processor 118 may be further coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. Peripherals 138 may include one or more sensors. The sensor may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0028] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of a signal (for example, associated with specific subframes of both UL (for example, for transmission) and DL (for example, for reception) may occur simultaneously and / or together. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of a signal (for example, associated with specific subframes of either UL (for example, for transmission) or DL ​​(for example, for reception)).

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

[0030] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with one embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

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

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

[0033] The MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may be responsible for authenticating users of WTRU102a, 102b, and 102c, as well as for bearer activation / deactivation, and for selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may also provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0034] The SGW164 can be connected to each of the eNode B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions such as anchoring the user plane during eNode B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0035] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

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

[0037] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface (e.g., temporary or permanent) with a communication network.

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

[0039] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with a Distribution System (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating outside the BSS to an STA may reach and be delivered to the STA via an AP. Traffic originating from an STA to an outside BSS destination may be sent to an AP and then delivered to its respective destination. Traffic between STAs within the BSS may be transmitted, for example, via an AP; a source STA may send traffic to an AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (for example, directly between them) in a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

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

[0041] A high-throughput (HT) STA can, for example, form a 40MHz wide channel for communication using a 40MHz wide channel via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels.

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

[0043] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including support for specific and / or limited bandwidths (e.g., support only for those bandwidths). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0044] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, 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 may depend on the state of the primary channel. For example, if the primary channel is busy, an STA (which only supports 1MHz operating mode) sending to the AP may consider the entire available frequency band to be busy, even if most of the available frequency band is idle.

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

[0046] Figure 1D is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using NR radio technology. RAN104 can also communicate with CN106.

[0047] RAN104 may include gNB180a, 180b, and 180c, but it will be understood that RAN104 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, and the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0048] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with an expandable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or expandable lengths (e.g., varying numbers of OFDM symbols and / or varying durations of absolute time).

[0049] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. Non-standalone configurations of WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0050] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slice support, interaction between DC, NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0051] The CN106 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although the aforementioned elements are shown as part of CN106, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0052] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c in RAN104 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may play roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of SMF183a and 183b for registration, management of registration areas, termination of non-access stratum (NAS) signals, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for MTC access. AMF182a, 182b may provide control plane functionality for switching between RAN104 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

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

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

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

[0057] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for the purpose of testing and / or performing testing using over-the-air radio communications.

[0058] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to implement testing of one or more components. One or more emulation 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 emulation device to transmit and / or receive data.

[0059] A WLAN in Infrastructure Basic Service Set (BSS) mode may include an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP typically has access to or an interface with a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating outside the BSS to an STA may reach the STA through the AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to the AP and then delivered to its respective destination. Traffic between STAs within the BSS may be transmitted through the AP, with the source STA sending traffic to the AP, and the AP delivering the traffic to the destination STA. Such traffic between STAs within the BSS may be considered peer-to-peer traffic. Such peer-to-peer traffic may also be transmitted directly between the source STA and the destination STA in a Direct Link Setup (DLS), for example, using an 802.11e DLS or 802.11z Tunnel DLS (TDLS). WLANs using Independent BSS (IBSS) mode may not have access points (APs) and / or may include STAs that communicate directly with each other. This communication mode is referred to as "ad-hoc" communication mode.

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

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

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

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

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

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

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

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

[0068] Measured traffic for various applications is likely to consist of short packets, and network applications can also generate short packets. Such applications may include virtual offices, transmit power control (TPC) acknowledgment (ACK), video streaming ACK, device / 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.

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

[0070] 802.11ax can address media access issues in the 6GHz band by, for example, using media access triggered or scheduled only in the 6GHz band, and / or restricting the active scanning and use of Enhanced Distributed Channel Access (EDCA) media access scheduled in the 6GHz band.

[0071] IEEE 802.11bc may include MAC revisions for Enhanced Broadcast Services (eBCS) for 802.11 devices. IEEE 802.11bc revisions may not affect the current IEEE 802.11 PHY specification.

[0072] The eBCS service may include downlinks from APs to non-AP STAs, or uplinks from sensor non-AP STAs. The enhanced broadcast service may be provided to STAs that are either associated with a particular AP or not. An AP may support up to 3000 non-AP STAs using the eBCS service. Furthermore, there may be a class of low-cost non-AP STAs that consume eBCS services that may not be able to transmit directly to the AP.

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

[0074] In downlink broadcast use cases, an eBCS AP may provide broadcast services to STAs that are associated with or unassociated with the AP. Because broadcast frames may not be acknowledging, it is not always clear whether there are STAs utilizing the broadcast service and receiving broadcast data. If no broadcast data is received, the AP consumes both power and radio medium resources. Some implementations provide a broadcast service mechanism that facilitates power-efficient broadcast services and may only provide broadcast services when and / or when the service is actively consumed.

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

[0076] Some implementations provide the end of a broadcast service announcement information element. In some implementations, an AP may send a frame containing the end of a broadcast service announcement frame, or the end of a broadcast service announcement information element, to announce that one or more eBCS services have terminated.

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

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

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

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

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

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

[0083] Referring back to Figure 2, the broadcast service ID subfield 214 can be 1 byte long and may indicate an identifier for the broadcast service. The upper layer destination address subfield 216 may have a different length, for example, depending on the value shown in the upper layer protocol field of the broadcast service information control subfield. If IPv4 / UDP or IPv6 / UDP is shown in the upper layer protocol subfield 304, the upper layer destination address subfield 216 may include the IP address and UDP port.

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

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

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

[0087] The Time to Terminate subfield 222 may be used to indicate the remaining time until the broadcast service described in this broadcast service field 210 terminates, unless additional negotiation is performed by one or more STAs that may consume the broadcast service. In another example, the Time to Terminate subfield 222 may include time, for example, a timing synchronization function (TSF) time value, or other type of time, at which time the broadcast service terminates unless additional negotiation is performed by the broadcast service initiator or other users of the broadcast service. Additionally or alternatively, it may include a timestamp of the current time, such as the current value of the TSF timer.

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

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

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

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

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

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

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

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

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

[0097] In some implementations, the negotiation method subfield 512 is one octet long. In some implementations, the negotiation method subfield 512 indicates a negotiation method for negotiating an extension of 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 ​​may be used to indicate the same negotiation method as detailed in Table 1.

[0098] [Table 1]

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

[0100] [Table 2]

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

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

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

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

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

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

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

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

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

[0110] An AP may indicate that one or more broadcast services it provides have ended at a given time by including the end of one or more broadcast service announcement elements in one or more of the frames it transmits (e.g., a beacon frame, probe response frame, eBCS data frame, broadcast service request frame, eBCS service advertisement frame, or eBCS information frame). An AP may include any negotiation methods necessary for any STA interested in the continuation of broadcasting beyond the indicated end time in order to perform negotiation for broadcast services beyond the indicated end time. An AP may indicate that one or more broadcast services it provides will be broadcast at a specific interval before they end.

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

[0112] If a broadcast service requires association (for example, as indicated in the association request subfield) and negotiation is via a broadcast service request frame, the STA may perform the association procedure with the AP. If the STA is already associated with the AP, the STA may send a broadcast service request frame indicating that it desires one or more broadcast services. The STA may indicate that it desires one or more broadcast services over a specific period or at a specific interval. The AP may respond with a broadcast service response frame indicating that the broadcast service will continue for a longer period and / or interval. If a second STA desires the same broadcast service and the second STA receives a frame containing a broadcast service announcement element or end of information indicating that the broadcast service has been extended, the second STA may cancel any pending broadcast service request frames that it had planned to send to the AP.

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

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

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

[0116] In some implementations, an eBCS STA, which is a broadcaster of one or more eBCS services, will initiate sending an eBCS service termination notification frame if one or more of the eBCS services it transmits are to terminate within an interval of time less than or equal to, for example, dot11eBCSTerminationNoticeTime, and the STA has not been periodically sending schedules for the eBCS services to terminate. In some implementations, when an eBCS STA initiates sending eBCS Termination Notice frames, the STA sends the eBCS Termination Notice frames within a period that is greater than a minimum interval, such as dot11eBCSTerminationNoticeMinimumInterval, and less than a maximum interval, such as dot11eBCSTerminationNoticeMaximumInterval.

[0117] In some implementations, the eBCS STA sending the eBCS Termination Notification Frame indicates the TBTT (Time to Terminate Time) in the Time to Terminate subfield within the same eBCS Termination Information subfield before the eBCS service identified by the eBCS Service ID contained in the eBCS Service ID subfield within the same eBCS Termination Information subfield is terminated. In some implementations, the Time to Terminate subfield may be expressed in other time formats such as ms, us, time units (TU), or any other type of time unit.

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

[0119] In some implementations, an eBCS STA sending an eBCS Termination of Service notification frame may indicate in the Negotiation Address subfield within the eBCS Termination of Service Information subfield an address associated with a negotiation method indicated in the Negotiation Method subfield within the same eBCS Termination of Service Information subfield, which the STA should use to negotiate an extension of the eBCS service identified by the eBCS Service ID contained in the eBCS Service ID subfield within the same eBCS Termination of Service Information subfield.

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

[0121] In some implementations, if the eBCS negotiates a different duration or a new time-to-termination value after sending an eBCS service termination notification frame, the eBCS STA shall send an eBCS service information frame or other type of frame with updated values ​​in the time-to-termination subfield or the eBCS service duration subfield.

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

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

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

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

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

[0127] An AP may anticipate that one or more STAs will send response frames. The AP may send a trigger frame to trigger multiple access response transmissions. In some implementations, the trigger frame may send inter-frame space (xIFS) time after a frame with EBSAI, where xIFS can refer to any existing or newly defined inter-frame space. In some implementations, the trigger frame may be aggregated with a frame with EBSAI. The trigger frame may indicate a trigger type in the trigger type field. The trigger type field may indicate a newly defined type, such as EBSAI, NDP, or probe request management frame trigger. Alternatively, the trigger type field may indicate an existing trigger type, such as a basic trigger.

[0128] One or more STAs may send a response to EBSAI, so that an STA may hold the initially negotiated broadcast service, modify the initially negotiated broadcast service to, for example, continue the service beyond its termination time, and / or request to initiate a new broadcast negotiation at a specific time and period.

[0129] STA may send an EBSAI response using one or more of the following methods: the same response method, a trigger-based random access method, and / or a trigger-based probe request method.

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

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

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

[0133] In an exemplary trigger-based random access method, one or more resource units may be allocated for sending a response. Resource allocation may be included in the trigger frame. The STA may initiate an OFDMA random access procedure, select one or more resource units, and send its own response frame. The response frame may be a regular MAC frame, which may contain the transmit (Tx) and / or receive (Rx) addresses, as well as other fields typically defined in the MAC header. Furthermore, it may carry EBSAI response-related information.

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

[0135] Some implementations provide eBCS service capability metrics. In some implementations, an AP may include eBCS service capability elements such as probe responses, beacon frames, eBCS service advertisement frames, eBCS information frames, and FILS discovery and frames in any frame it transmits.

[0136] Figure 12 is a bitmap diagram illustrating an exemplary format of eBCS service capability elements. The eBCS service capability element may include one or more of the following subfields, as shown in Figure 12, for example: Element ID subfield 1202, Length subfield 1204, Element ID extension subfield 1206, Sequence number subfield 1208, Fragment count subfield 1210, Fragment index subfield 1212, DL broadcast capability subframe 1214, Broadcast service count subframe 1216, eBCS1-N subfield 1218, Broadcast information control subfield 1220, Broadcast ID subfield 1222, eBCS subfield 1224, Association request subfield 1226, UL transmission request subfield 1228, Broadcast parameter subfield 1230, Broadcast security subfield 1232, Upper layer destination address subfield 1234, Title presence subfield 1236, Title length subfield 1228, Title subfield 1240, Time to end subfield 1242, Broadcast control subfield 1244, and / or other subfields. Examples of such subfields are as follows:

[0137] For the element ID subfield 1202, the length subfield 1204, and the 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.

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

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

[0140] The fragment index subfield 1212 may indicate the index of the fragment of the eBCS capability element currently contained within the eBCS capability element.

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

[0142] The broadcast information control subfield 1220 may be 1 byte long and may contain an indicator of whether specific broadcast information is included in the eBCS N field. The broadcast ID subfield 1222 may be 1 bit long and may indicate whether the broadcast ID is included in the eBCS N field.

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

[0144] The broadcast ID subfield 1222 may indicate the ID of the broadcast service. The eBCS type subfield 1224 may include the type of broadcast service, for example, whether the eBCS is UL or DL, or whether the broadcast service belongs to the categories of Automotive, Directions, Emergency, Support, Information, or Event Support. In some implementations, a bitmap may be included in the DL broadcast element to indicate what type of broadcast service is provided by the transmitting STA. The type may also be a multi-AP broadcast. In some implementations, the broadcast type may be identified by an organizationally unique identifier (OUI).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0159] If the Title Existence subfield in the Broadcast Service Information Control subfield is set to 1, the Title Length subfield 1318 may be included in the Broadcast Service field 1310; otherwise, it does not exist. The Title Length subfield 1318 can be 1 byte long and indicates the length of the Title field. If the Title Existence subfield 1406 in the Broadcast Service Information Control subfield 1312 is set to 1, the Title subfield 1320 may be included in the Broadcast Service field; otherwise, it does not exist. The Title Length subfield 1318 can be 1 byte long and indicates the length of the Title subfield 1320. The Title subfield can be of variable byte length.

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

[0161] Figure 14 illustrates an exemplary format of the broadcast service information control field subfield 1312. The broadcast service information control field subfield 1312 may include a broadcast service ID presence subfield 1402, a higher-layer protocol 1404 subfield, a title presence subfield 1406, a requested duration presence subfield 1408, and a requested parameter presence subfield 1410. The broadcast service information control field subfield 1312 may also have a reserved subfield 1412.

[0162] The Broadcast Service ID Presence subfield 1402 may be 1 bit long and may indicate whether the Broadcast Service ID is included in the Broadcast Service field 1310. The Upper Layer Protocol subfield 1404 may be 3 bits long and may indicate one of the following values: no upper layer destination address exists, no upper layer destination address exists, and / or the upper layer destination address is present in the Broadcast Service field 1310. The Upper Layer Protocol subfield 1404 may contain UDP / IPv4, UDP / IPv6, UDP / Hostname, MPEG Transport Stream Identifier, and / or MAC address. The Title Presence subfield 1406 may be 1 bit long and is used to indicate whether a user-readable title exists in the Broadcast Service field 1310. If the Title Presence bit is set to 1, the Title Length subfield and Title subfield may be included in the Broadcast Service field 1310. Negotiation Method Presence subfield: This subfield may be 1 bit long and may be used to indicate whether the Negotiation Method subfield is included in the Broadcast Service field.

[0163] The requested duration existence subfield 1408 may be 1 bit long and may indicate whether the requested duration of the requested broadcast service exists in the broadcast service field 1310. The requested parameter existence subfield 1410 may be 1 bit long and may indicate whether the requested parameter of the requested broadcast service exists in the broadcast service field 1310.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0178] In some implementations, an AP may advertise one or more broadcast services using broadcast service elements such as beacons, probe responses, eBCS service advertisement frames, and eBCS information frames, and / or simply using probe responses, eBCS service advertisement frames, eBCS information frames, or EBCS termination notification frames. An AP may indicate a negotiation method for one or more eBCS services via ANQP / GAS frame exchange, probe request frame exchange, eBCS service request / response frames, or IP packets.

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

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

[0181] Some implementations include eBCS service request / response procedures for associated STAs. In some implementations, the eBCS service negotiation procedure for associated STAs may be as follows: The AP may advertise one or more broadcast services using broadcast service elements, for example, beacons, probe responses, eBCS service advertisement frames, eBCS information frames, and / or simply probe responses, eBCS service advertisement frames, eBCS information frames, EBCS termination notification frames, and / or simply. The AP may indicate how to negotiate for one or more eBCS services, for example, via ANQP / GAS frame exchange, via probe request frame exchange, via eBCS service request / response frames, and / or via IP packets. The AP may indicate for one or more eBCS services that association is required to use those eBCS services.

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

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

[0184] Some implementations include eBCS service request / response procedures for receive-only STAs. In some implementations, the eBCS service negotiation procedure for a receive-only STA is as follows: In some implementations, an AP may advertise one or more broadcast services using broadcast service elements such as beacons, probe responses, eBCS service advertisement frames, and / or simply using probe responses, eBCS service advertisement frames, and / or eBCS information frames. An AP may indicate how to negotiate for one or more eBCS services via ANQP / GAS frame exchange, probe request frame exchange, eBCS service request / response frames, and / or via IP packets. An AP may indicate that association is required to use those eBCS services for one or more eBCS services.

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

[0186] If the request is successful, the AP may, accordingly, begin providing the requested eBCS service. The AP may indicate the remaining time for the broadcast service it is providing. For example, the AP may periodically include the end of a broadcast service announcement element in one or more of the frames it is transmitting (e.g., 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).

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

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

[0189] Figure 17 illustrates an exemplary method 1700 of an STA requesting the continuation of eBCS services. In step 1702, the STA may first receive an eBCS termination notification frame from the access point (AP) indicating that the eBCS service being consumed by the STA is terminating. In step 1704, the STA may negotiate for the continuation of the eBCS service on the condition that termination is not permitted. Then, in step 1706, if the STA has successfully negotiated for the continuation of the eBCS service, it may continue to receive the eBCS service. Note that the various steps described with respect to method 1700 are merely examples, and other implementations may omit some of these steps, include additional steps, or perform these steps in a different order.

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

Claims

1. A method implemented in an access point (AP), Send an Enhanced Broadcast Service (eBCS) termination notification frame to the station (STA) indicating that the Enhanced Broadcast Service (eBCS) being consumed by the station (STA) is ending. Based on the transmitted Enhanced Broadcast Service (eBCS) termination notification frame indicating that the Enhanced Broadcast Service (eBCS) being consumed by the station (STA) is ending, negotiate with the station (STA) regarding the continuation of the Enhanced Broadcast Service (eBCS) being consumed by the station (STA), Based on the negotiation, the station (STA) continues to transmit the enhanced broadcast service (eBCS) it is consuming, Methods that include...

2. The method according to claim 1, wherein the enhanced broadcast service (eBCS) termination notification frame includes a time to termination subfield indicating the number of target beacon transmission times (TBTT) remaining until the enhanced broadcast service (eBCS) being consumed by the station (STA) terminates.

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

4. The method according to claim 1, wherein negotiating with the station (STA) for the continuation of the enhanced broadcast service (eBCS) includes transmitting a negotiation method subfield to the station (STA) for negotiating an extension of the enhanced broadcast service (eBCS) that the station (STA) is consuming.

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

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

7. The method according to claim 5, wherein the negotiation method subfield indicates that the station (STA) negotiates via one or more eBCS service request frames.

8. The method according to claim 5, wherein the negotiation method subfield indicates that the station (STA) negotiates via one or more Access Network Query Protocol (ANQP) eBCS service request frames.

9. The method according to claim 5, wherein the negotiation method subfield indicates that the station (STA) negotiates via an IP request.

10. An access point (AP), A transmitter configured to send an Enhanced Broadcast Service (eBCS) Termination Notice frame to a Station (STA) indicating that the Enhanced Broadcast Service (eBCS) being consumed by the Station (STA) is ending, A processor and receiver configured to negotiate with the station (STA) regarding the continuation of the Enhanced Broadcast Service (eBCS) being consumed by the station (STA), based on a transmitted Enhanced Broadcast Service (eBCS) termination notification frame indicating that the Enhanced Broadcast Service (eBCS) being consumed by the station (STA) is ending. Equipped with, The transmitter is configured to continue transmitting the Enhanced Broadcast Service (eBCS) consumed by the Station (STA) based on the negotiation, as an access point (AP).

11. The access point (AP) according to claim 10, wherein the enhanced broadcast service (eBCS) termination notification frame includes a time to termination subfield indicating the number of target beacon transmission times (TBTT) remaining until the enhanced broadcast service (eBCS) consumed by the station (STA) terminates.

12. The access point (AP) according to 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 access point (AP) according to claim 10, wherein the transmitter is configured to transmit to the station (STA) a negotiation method subfield for negotiating an extension of the enhanced broadcast service (eBCS) that the station (STA) is consuming.

14. The access point (AP) according to claim 13, wherein the negotiation method subfield is included in the enhanced broadcast service (eBCS) termination notification frame.

15. The negotiation method subfield indicates that negotiation is not available, according to claim 14, for the access point (AP).

16. The access point (AP) according to claim 14, wherein the negotiation method subfield indicates that the station (STA) negotiates via one or more eBCS service request frames.

17. The access point (AP) according to claim 14, wherein the negotiation method subfield indicates that the station (STA) negotiates via one or more Access Network Query Protocol (ANQP) eBCS service request frames.

18. The access point (AP) according to claim 14, wherein the negotiation method subfield indicates that the station (STA) negotiates via an IP request.

Images