Method and apparatus for integrating 3GPP multicast / broadcast service for 5G and IEEE 802.11 bc

Abstract

Described is a method and apparatus for transmitting a 5G multicast / broadcast service to a WTRU in a 3GPP network over a non-3GPP access (e.g., an 802.11 bc enhanced broadcast service network). A method may include receiving first information from a 3GPP network indicating a service announcement or a protocol data unit (PDU) session request associated with a 3GPP multicast / broadcast service (MBS). The first information may include MBS session information. The method may also include determining an MBS session context in the wireless LAN based on the MBS session information. The MBS session context may include second information for transmitting the MBS over the wireless LAN. The method may then include transmitting third information indicating the MBS session context to the wireless LAN for distribution to a wireless transmit unit (WTRU) in the wireless LAN.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 392,809, filed on July 27, 2022, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure may, for example, relate to methods and apparatus for delivering 5G multicast / broadcast services to WTRUs in a 3GPP network via a non-3GPP access (e.g., an 802.11bc enhanced broadcast service network). Summary of the invention

[0004] Embodiments may include a method for interfacing between a 3GPP network and a wireless local area network (LAN). The method may include receiving first information from the 3GPP network, the first information indicating a service announcement or a protocol data unit (PDU) session request associated with a 3GPP multicast / broadcast service (MBS). The first information may include or may indicate MBS session information. The method may include determining an MBS session context in a wireless LAN based on the MBS session information, wherein the MBS session context may include second information for transmitting the MBS via the wireless LAN. The method may also include sending third information indicating the MBS session context to the wireless LAN for distribution to wireless transmission units (WTRUs) in the wireless LAN.

[0005] An embodiment may include an apparatus configured to interface between a 3GPP network and a wireless local area network (LAN). The apparatus may include a circuit including any one or more of a processor, a memory, a transmitter, and / or a receiver. The circuit may be configured to receive first information from the 3GPP network, the first information indicating a service announcement or a protocol data unit (PDU) session request associated with a 3GPP multicast / broadcast service (MBS). The first information may include or may indicate MBS session information. The circuit may also be configured to determine an MBS session context in a wireless LAN based on the MBS session information. The MBS session context may include second information for transmitting the MBS via the wireless LAN. The circuit may be configured to send third information indicating the MBS session context to the wireless LAN for distribution to a wireless transmission unit (WTRU) in the wireless LAN. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed understanding can be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. The figures in these drawings are exemplary as are the detailed description. Therefore, these figures and detailed description should not be considered limiting, and there can and are likely to be other equally effective examples. In addition, like reference numerals ("ref") in the figures represent similar elements, among which:

[0007] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0008] Figure 1B is a diagram showing a method for use according to an embodiment of the present invention. Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) within a communication system shown in;

[0009] Figure 1C is a diagram showing a method for use according to an embodiment of the present invention. Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) within a communication system shown in FIG.

[0010] Figure 1D is a diagram showing a method for use according to an embodiment of the present invention. Figure 1A A system diagram of another exemplary RAN and another exemplary CN within the communication system shown in ;

[0011] Figure 2 is a block diagram illustrating a system architecture for multicast and broadcast services;

[0012] Figure 3 is a block diagram of the interconnection architecture for untrusted non-3GPP networks in 3GPP;

[0013] Figure 4 is a block diagram of the interconnection architecture for trusted non-3GPP networks in 3GPP;

[0014] Figure 5 is a block diagram of an integrated MBS / EBCS architecture according to an embodiment;

[0015] Figure 6 is a signal flow diagram illustrating establishment of a session on the 3GPP side according to an embodiment;

[0016] Figure 7 is a signal flow diagram illustrating an ATSSS process according to an embodiment;

[0017] Figure 8 is a signal flow diagram illustrating a process for announcing an MBS service for non-3GPP access according to an embodiment;

[0018] Fig. 9 is a signal flow diagram illustrating multicast service initiation requiring a request from the IEEE 802.11bc side according to an embodiment; and

[0019] Fig.10 is a flow chart illustrating a method according to an embodiment. DETAILED DESCRIPTION

[0020] introduce

[0021] In the following detailed description, many specific details are set forth in order to fully understand the embodiments and / or examples disclosed herein. However, it should be understood that these embodiments and examples can be implemented without some or all of the specific details described herein. In other cases, well-known methods, procedures, components, and circuits are not described in detail to avoid confusing the following description. In addition, the embodiments and examples not specifically described herein may be implemented to replace or combine the embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively referred to as "provided") herein.

[0022] Exemplary Communication System

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

[0024] like Figure 1AAs shown, the communication system 100 may include: wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d; RAN 104 / 113; CN 106 / 115, public switched telephone network (PSTN) 108; Internet 110; and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), consumer electronic devices, devices operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0025] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly connect to at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NRNodeB, a site controller, an access point (AP), a wireless router, and the like. Although each of the base stations 114a, 114b is depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0026] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed spectrum and unlicensed spectrum. A cell may provide coverage for a wireless service, and the coverage may be relatively fixed or may be a specific geographic area that changes over time. A cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in an embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology, and may employ multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

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

[0028] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

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

[0030] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as NR wireless access, which may establish the air interface 116 using New Radio (NR).

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

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

[0033] Figure 1AThe base station 114b in the example may be a wireless router, a home Node B, a home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area (e.g., a business location, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc.). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown, base station 114b may be directly connected to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0034] The RAN 104 / 113 may be in communication with the CN 106 / 115, 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 the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although Figure 1A Although not shown, it will be appreciated that the RAN 104 / 113 and / or CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may employ NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0035] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0036] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The WTRU 102c shown in FIG. 1 may be configured to communicate with the base station 114a (which may employ a cellular-based radio technology) and with the base station 114b (which may employ an IEEE 802 radio technology).

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

[0038] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated into an electronic package or chip.

[0039] 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 an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0041] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

[0042] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 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 therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128. In addition, the processor 118 may access information in and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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 in and store data in a memory that is not physically on the WTRU 102, such as on a server or a home computer (not shown).

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

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

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

[0046] The WTRU 102 may include a full-duplex radio in which transmission and reception of some or all signals (e.g., associated with particular subframes used for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference through hardware (e.g., chokes) or through signal processing by a processor (e.g., a separate processor (not shown) or through the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio in which transmission and reception of some or all signals (e.g., associated with particular subframes used for both uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0047] Figure 1C 1 is a system diagram showing the RAN 104 and the CN 106 in accordance with an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

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

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

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

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

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

[0054] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway, such as an IP Multimedia Subsystem (IMS) server, which serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0055] although Figures 1A to 1D WTRUs are described in the EMBODIMENTS as wireless terminals, but it is contemplated in certain representative embodiments that such terminals may communicate with a communication network using (eg, temporarily or permanently) a wired communication interface.

[0056] In a representative embodiment, the other network 112 may be a WLAN.

[0057] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another wired / wireless network that transfers a communication stream into and / or out of the BSS. A communication stream originating from outside the BSS and directed to a STA may be reached by the AP and may be transmitted to the STA. A communication stream originating from a STA and directed to a destination outside the BSS may be sent to the AP for transmission to the corresponding destination. Communication streams between STAs within a BSS may be sent by the AP, for example, where a source STA may send a communication stream to the AP, and the AP may transmit the communication stream to a target STA. Communication streams between STAs within a BSS may be considered and / or referred to as point-to-point communication streams. Point-to-point communication streams may be transmitted between a source STA and a target STA (e.g., directly between them) via a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad-hoc" communication mode.

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

[0059] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

[0060] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels or combining two discontinuous 80MHz channels, which can be called an 80+80 configuration. For the 80+80 configuration, the data can be passed through a segment parser after channel coding, which can divide the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing respectively. The stream can be mapped onto two 80MHz channels, and the data can be sent by the transmitting STA. At the receiver of the receiving STA, the operation of the above 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0061] 802.11af and 802.11ah support sub-1 GHz operating modes. The channel operating bandwidths and carriers in 802.11af and 802.11ah are reduced relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah uses non-TVWS spectrum to support 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths. According to a representative embodiment, 802.11ah may support meter type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain functionality, such as limited functionality, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0062] The WLAN system may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, including channels that may be designated as primary channels. The bandwidth of the primary channel may be 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 the STA that supports the minimum bandwidth operating mode among all STAs in the BSS. In the example of 802.11ah, for STAs (e.g., MTC type devices) that support (e.g., only support) 1MHz mode, the width of the primary channel may be 1MHz, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, 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. If the primary channel is busy (e.g., because the STA (supporting only the 1MHz operating mode) is transmitting to the AP), the entire available band may be considered busy, even if most of the band remains idle and may be available.

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

[0064] Figure 1D 1 is a system diagram showing the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

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

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

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

[0068] Each of the gNBs 180a, 180b, 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 uplink (UL) and / or downlink (DL), network slicing support, dual connectivity, interworking between NR and E-UTRA, routing user plane data to a user plane function (UPF) 184a, 184b, routing control plane information to an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0069] Figure 1DThe CN 115 shown in FIG. 1 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the above elements is depicted as part of the CN 115, it is understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0070] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of service used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. AMF a82a, 182b may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies (e.g., LTE, LTE-A, LTE-A Pro) and / or non-3GPP access technologies (e.g., WiFi).

[0071] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of the communication flow through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

[0073] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to a local data network (DN) 185a, 185b through the UPF 184a, 184b via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0074] Given that Figures 1A to 1D as well as Figures 1A to 1D In accordance with the corresponding description of the present invention, one or more or all of the functions described herein with respect to one or more of the WTRU 102a to WTRU 102d, the base station 114a to base station 114b, the eNode-B 160a to eNode-B 160c, the MME 162, the SGW 164, the PGW 166, the gNB 180a to gNB 180c, the AMF 182a to AMF 182b, the UPF 184a to UPF 184b, the SMF 183a to SMF 183b, the DN 185a to DN 185b and / or any other devices described herein may be performed by one or more simulation devices (not shown). The simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0075] The simulation device may be designed to perform one or more tests on other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more or all functions when fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices may perform one or more or all functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing and / or may use over-the-air wireless communication to perform testing.

[0076] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used for testing scenarios in a test lab and / or a wired and / or wireless communication network that is not deployed (e.g., tested) to implement testing of one or more components. One or more simulation devices can be test devices. The simulation device can use direct RF coupling and / or wireless communication through RF circuits (e.g., which can include one or more antennas) to send and / or receive data.

[0077] Multicast / Broadcast Environment

[0078] IEEE 802.11bc

[0079] IEEE 802.11bc specifies modifications to the IEEE 802.11 Medium Access Control (MAC) specification that enable enhanced transmission and reception of broadcast data both in situations where an association between transmitters and receivers exists and in situations where no association between transmitters and receivers exists in an infrastructure Basic Service Set (BSS).

[0080] [1] describes a variety of use cases for IEEE 802.11bc, including: stadium video distribution, low-power sensor UL broadcast, smart traffic broadcast, event production broadcast services, multi-language and emergency broadcast, VR e-sports video distribution, multi-channel data distribution, lecture room slide distribution, area-based broadcast television services, and AP tag uplink (UL) forwarding.

[0081] Stadium video distribution may include providing enhanced broadcast services (EBCS) for video to a large number of densely distributed stations (STAs). These STAs may or may not be associated with an access point (AP) or may be non-transmitting STAs.

[0082] Low power sensor UL broadcasts may include pre-configured Internet of Things (IoT) devices automatically connecting to the end server through the EBCS access point (AP) without any setup operations. This feature includes low power IoT devices reporting movement to their server through the EBCS AP without scanning and association.

[0083] Intelligent traffic broadcasting may include connected vehicle roadside equipment (RSE), connected vehicle onboard equipment (OBE) and personal information devices (PID) providing EBCS services for traffic-related information for railway crossings, or RSE providing EBCS services for local traveler information.

[0084] The event production broadcast service may include providing EBCS for multiple data streams suitable for different client STAs. The number of STAs may be large and these STAs may be fixed or mobile.

[0085] Multi-language emergency broadcasting may include providing EBCS for emergency and / or multi-language services to a large number of densely distributed STAs. These STAs may or may not be associated with an AP, or may be non-transmitting STAs. These STAs may be fixed or mobile.

[0086] VR esports video distribution may include distributing a video of a player's view to an audience via an EBCS at a location (e.g., an arena) of a virtual reality (VR) esports game.

[0087] Multi-channel data distribution may include the AP broadcasting the same information in different languages, each language in a dedicated channel. The user can select one of the channels.

[0088] Lecture room slide distribution may include simultaneous distribution of slides on screen to audience PCs, tablets, etc. There is no need for audience to download visual aids and change pages. Distribution of slides to all students is synchronized.

[0089] Regional broadcast TV services may include TV content (e.g., local news) that can be distributed by small local TV companies to consumer BYOD devices (rather than TV receivers). In the event of a disaster, evacuation information can be distributed without any complex customer operations.

[0090] AP tag uplink (UL) forwarding may include pre-configured low-cost, low-power tracker devices automatically connecting to end servers through nearby EBCS APs without any setup operations. Tracker devices periodically report to their servers through EBCS APs without the need for scanning and association. Trackers broadcast UL frames periodically, which are randomly received at EBCS APs. EBCS APs append metadata (such as IP, date / time, location, RSSI, etc.) to the data packets before forwarding to the target server. Metadata from EBCS APs will be protected.

[0091] 5G Multicast / Broadcast Service (MBS)

[0092] Multicast and Broadcast Service (MBS) is a point-to-multipoint service where data is sent from a single source entity to multiple receivers, either to all users within a broadcast service area or to users in a multicast group. MBS services include broadcast services (where content is broadcast without a request from the WTRU) and multicast (where a request from the WTRU is required).

[0093] MBS specifies RAN enhancements for efficient use of the radio interface and CN enhancements for efficient content distribution to the RAN through multicast and broadcast services. Between 5GC and NG-RAN, there are two possible delivery methods for transmitting MBS data: 5GC single MBS communication flow delivery method and 5GC shared MBS communication flow delivery method.

[0094] The 5GC individual MBS traffic flow delivery method may only be applicable to multicast MBS sessions. For example, the 5GC receives a single copy of the MBS packets and delivers a separate copy of these MBS packets to each WTRU via each WTRU PDU session. Therefore, for each such WTRU, a PDU session is required to be associated with the multicast session.

[0095] The 5GC shared MBS communication flow delivery method can be applied to both broadcast MBS sessions and multicast MBS sessions. For example, the 5GC receives a single copy of the MBS data packets and transmits a single copy of these MBS data packets to the 5G RAN node, which then transmits the data packets to one or more WTRUs.

[0096] 5G MBS also provides functions such as local MBS services, multicast MBS authorization and QoS differentiation.

[0097] The MBS architecture is defined in TS23.247 (v17.0.0). Figure 2 shown.

[0098] The MBS architecture enhances the 5GS architecture by introducing several new functions or entities (as well as other functions or entities not included in the present disclosure), such as: multicast / broadcast session management function (MB-SMF), multicast / broadcast user plane function (MB-UPF), network exposure function (NEF), multicast / broadcast service function (MBSF), and multicast / broadcast service transmission function (MBSTF).

[0099] MB-SMF supports MBS session management, configures MB-UPF (Multicast / Broadcast User Plane Function) for multicast and broadcast transport streams, allocates and de-allocates TGMI (Temporary Mobile Group Identity) used to identify MBS streams, and interacts with RAN through AMF to control data transmission.

[0100] The MB-UPF performs packet filtering, QoS enforcement on multicast and broadcast downlink packets, transmits multicast and broadcast data to the RAN based on the selected transmission method, and interacts with the MB-SMF to receive multicast and broadcast communication flows.

[0101] NEF provides an application function (Afs) interface for MBS procedures including service configuration, MBS session and QoS management.

[0102] MBSF provides service-level functions to support MBS and interworks with LTE MBMS (Multimedia Broadcast / Multicast Service), interacts with the Access Function (AF) and MB-SMF for MBS session operation, determining transmission parameters and session transmission. It also performs MB-SMF selection to serve MBS sessions and controls the Multicast / Broadcast Service Transport Function (MBSTF) (if MBSTF is used).

[0103] If desired, the MBSTF can be the media anchor for the MBS data stream, including the source of IP multicast (if required), common packet transport functions available to any application supporting IP multicast (such as framing, multi-streaming, packet FEC (coding)), and multicast / broadcast delivery of input files as objects or object streams.

[0104] Interconnection between 5GS and non-3GPP RAN technologies

[0105] 3GPP has defined different architectures to enable interconnection between non-3GPP networks (such as IEEE 802.11) and 5GS. These architectures are defined in 3GPP TS 23.502 and 3GPP TS 24.502. 3GPP has defined two different connection scenarios, considering whether the non-3GPP network is trusted (e.g., managed and controlled by the 3GPP network) or untrusted. For an untrusted non-3GPP access network, it will be connected to the 5G core network through the Non-3GPP Interworking Function (N3IWF), while a trusted non-3GPP access network will be connected to the 5G core network through the Trusted Non-3GPP Gateway Function (TNGF). N3IWF and TNGF interface with the 5G core network control plane (CP) and user plane (UP) functions through the N2 and N3 interfaces, respectively, as Figure 3 and Figure 4 shown, taken from [3].

[0106] Both trusted and untrusted connection scenarios protect the data of the terminal (TE) via an IPsec tunnel between the TE and the N3IWF / TNGF, although the IPsec tunnel is set up using different mechanisms in each case. Consistent with [3], TE refers to a terminal connected to 3GPP via WiFi access. However, WTRU and TE are both WTRU devices and can be used interchangeably.

[0107] A key challenge in integrating IEEE 802.11bc (EBCS) and MBS architecture is that these two broadcast mechanisms are designed from different perspectives.

[0108] The 3GPP MBS system is designed so that authorized application servers / application functions (AS / AF) can directly broadcast / multicast content in the 3GPP network. For example, the AS can directly announce broadcast / multicast services through direct WTRU signaling via standard Internet Engineering Task Force (IETF) protocols such as Session Description Protocol (SDP). Therefore, there is no service announcement mechanism framework for announcing all available MBS services in a specific area. Each service is independently announced and distributed.

[0109] On the other hand, EBCS is based on the pre-authorization of services to be transmitted through the ESS (Extended Service Set). Services are registered in the EBCSESS and jointly announced in the IEEE generic 802.11bc service announcement frame. Therefore, the transmission server is not allowed to directly and independently transmit the signal of available services. In fact, in 3GPP, the service sender must obtain authorization to use MBS, while in EBCS, the service transmission must be authorized through pre-registration.

[0110] This poses complex challenges for delivering MBS services provided in 3GPP systems through EBCS domains connected to 3GPP systems in trusted and untrusted non-3GPP interconnect architectures.

[0111] Architecture, methods and devices for integrated 5G and non-3GPP multicast / broadcast service delivery

[0112] According to some exemplary embodiments, the present invention introduces a 3GPP MSB-IEEE 802.11bc architecture, a modified context structure, and a message sequence chart for integrating WLAN (e.g., IEEE 802.11bc) into a 3GPP 5G MBS network to provide multicast / broadcast services.

[0113] In various embodiments, a new MBS / EBCS controller entity is provided that: 1) groups / announces 3GPP MBS service announcements to terminals connected via WiFi (trusted or untrusted) via 802.11bc; and / or 2) triggers multicast streaming from the MBS AF / AS based on EBSC ​​requests from terminals connected via WiFi (trusted or untrusted).

[0114] According to certain exemplary embodiments, a new module is provided in the trusted and untrusted WLAN to 3GPP interconnect architecture. The new element (herein referred to as MBS_EBCS_Controller) may reside in the N3IWF or TNGF and may set the EBCS filter in the IEEE 802.11 network and act as a WTRU to request MBS services.

[0115] In various embodiments, extensions are provided to the ATSSS bootstrap mode and 5GS Session Management (5GSM) information elements to indicate a new ASSSS bootstrap mode.

[0116] In various embodiments, extensions are provided to the MBS session context to include information required to deliver MBS services over IEEE 802.11bc.

[0117] In various embodiments, extensions to the message sequence charts are provided to show how broadcast and multicast MBS sessions use IEEE 802.11bc as the RAN with ASSS support (for multicast streaming) and without ASSSS support (broadcast and multicast).

[0118] Integrated Architecture MBS-IEEE 802.11bc

[0119] Figure 5 is a block diagram of an integrated MBS / EBCS architecture according to an embodiment, wherein dashed lines correspond to control interfaces and solid lines correspond to data plane interfaces.

[0120] The key element introduced in this architecture is the MBS / EBCS controller entity (from now on MBS_EBCS_Controller 501). This entity can be collocated in the TNGF, in the N3IWF, or separately. Figure 5 In the exemplary embodiment shown, there is an MBS_EBCS_controller 501a associated with the trusted non-3GPP access network 503, and an MBS_EBCS_controller 501b associated with the untrusted non-3GPP access network 505. Its main functions may be dual. The MBS_EBCS_controller 501 can monitor the service announcement from the AF / AS 509, and configure the EBCS content flow mapper 511 of the IEEE 802.11bc domain (or any other IEEE802.11bc element responsible for EBCS service announcement and filtering of the ingress EBCS communication flow), register the 5G MBS service in the network, so that it can be announced to the terminal accessed by WiFi via 802.11bc. In the case of multicast transmission, the MBS_EBCS_Controller 501 may receive a trigger from the EBCS domain when the TE 513 issues an EBCS message (e.g., an enhanced broadcast service request access network query protocol (ANQP) element according to IEEE802.11bc / D2.0) requesting the start of a multicast flow. The MBS_EBCS_Controller 501 performs the N1 / higher layer signaling required to request a multicast flow on the 3GPP side on behalf of the WTRU operating as a TE in the IEEE 802.11bc domain. If N1 signaling is required, this part of the MBS_EBCS_Controller functionality resides in the N1 stack of the TE.

[0121] MBS sessions are defined by an MBS session context, which is stored in each node that handles an MBS communication flow. This MBS session context is defined in 3GPP TS 23.247 and can be modified as shown in Table 1 below to consider the MBS_EBCS_Controller 501 for the broadcast MBS case. In the following table, new parameters are indicated by underscores. In addition, an X in a table column indicates that the MBS session context stored in each entity according to the column header includes the elements in the corresponding row.

[0122] Table 1: Modification to Table 6.9.1-2: Broadcast MBS session context (3GPP TS 23.247 V17.0.02021-09)

[0123]

[0124]

[0125] Note that an MBS communication flow may consist of multiple data streams, such as audio and video in separate data frames. IEEE 802.11bc treats these data streams (video and audio of the same content) as different EBCS services. The MBS_EBCS_Controller 501 can create multiple EBCS communication flows from a single MBS service.

[0126] It is also noted that the MBS context created at the MBS_EBCS_Controller 501 is in the "Configured" state when the MBS_EBCS_Controller has received a service announcement from the AF generating the flow but the communication flow has not yet started to arrive at the MBS_EBCS_Controller. The Configured state means that the configuration has been completed at the MBS_EBCS_Controller. However, this configuration may not have been pushed into the IEEE802.11bc domain. The "Transmitted" state means that a request from at least one STA has been received and the MBS content is being sent to one or more STAs over the air as an EBCS service in the 802.11bc network (or broadcast without request).

[0127] For the case of multicast MBS, the MBS session context may be modified as shown in Table 3 below.

[0128] Table 2: Modification to Table 6.9.1-1: Multicast MBS session context (3GPP TS 23.247 V17.0.02021-09)

[0129]

[0130]

[0131]

[0132] Note that an MBS communication flow may consist of multiple data streams, such as audio and video in separate data frames. IEEE 802.11bc treats these data streams (video and audio of the same content) as different EBCS services. The MBS_EBCS_Controller 501 can create multiple EBCS communication flows from a single MBS service. If TMGI is used as the MBS session identifier, the EBCS service can be mapped to a specific TMGI and QoS profile.

[0133] It should also be noted that the MBS context created at the MBS_EBCS_Controller 501 is in the "Configured" state when the MBS_EBCS_Controller has received the service announcement but the communication flow has not yet started to arrive at the MBS_EBCS_Controller. The configured state means that the service configuration has been applied to the MBS_EBCS_Controller. However, this configuration may not have been pushed into the IEEE 802.11bc domain yet. The "Waiting for Request" state means that the MBS session context is available and the EBCS configuration for this service has been installed in the IEEE 802.11bc network (i.e., it has been announced and available for use by the TE). An EBCS service in this state means that the content requires a request message from the STA to be transmitted. The "Transmitted" state means that a request for an MBS context has been received from at least one STA, and the MSB content is being sent wirelessly to one or more STAs as an EBSC ​​service in the 802.11bc network (or, in the case of a broadcast without a request).

[0134] As a possible implementation, the EBCS related parameters are already included in the MBS session context, but they may be part of this context or created separately in a different structure that is later associated to the received MBS communication flow.

[0135] Multicast and Broadcast Services (MBS) are announced by the AF 509 and provide them to the 3GPP network. The AF (depending on its authorization level) can use different protocols and mechanisms. Examples of these mechanisms include SIP / SDP-based methods or 3GPP group mechanism-based methods. See

[11] . The information required for the MBS_EBCS_Controller 501 to create an EBCS context and start announcing services within the EBCS network can be obtained by inspecting the announcements sent by the AF. In addition, once the TGMI is allocated and the context is created on the AMF, some other information can be obtained from the AMF 507. This information is passed from the AMF 507 to the MBS_EBCS_Controller 501 via an N2 message request (for example, as discussed in more detail below). Figure 7 22 in step 2).

[0136] Use ATSS functionality to redirect MBS traffic to non-3GPP networks supporting IEEE 802.11bc

[0137] This embodiment focuses on the use of Access Traffic Steering, Switching and Splitting (ATSSS) and Multi-Access (MA) PDU sessions to locally split the MBS session to a non-3GPP access supporting IEEE 802.11bc. Figure 6 start, Figure 6 shows the session setup on the 3GPP side and the definition of the new ATSSS control mode, while Figure 7Completed the sequence diagram for the ATSSS process.

[0138] Figure 6 The signal flow diagram assumes that the WTRU and the network can support ATSSS and that the WTRU can associate with the same public land mobile network (PLMN) using 3GPP and non-3GPP accesses, although the idea can be applied to accesses connected to different PLMNs with minor modifications.

[0139] Figure 6 Actually Figure 7 .1.1.2-1 Initial configuration of MBS session without PCC and Figure 7 .3.1-1 Merger of Broadcast MBS Session Establishment (from 3GPP TS 23.247 (V17.0.0, 2021-09)) It should be noted that according to the exemplary embodiments described below, the conventional steps from the 3GPP specification are modified. Figure 6 Some steps in the TS23.247 specification may not change ( Figure 6 One modification that occurs in 3GPP TS 23.247 is located in the arrow box between steps 18 and 19, because the figure is only a high-level representation of the signal flow, and does not explicitly represent all the details. However, the following describes modifications to the conventional process, including particularly significant modifications to the actions, which are implemented to locally split the MBS session to a non-3GPP access supporting IEEE802.11bc. Therefore, the following description includes a summary of the standard steps defined in 3GPP TS 23.247, as well as the extensions included according to this embodiment.

[0140] Figure 6 Steps 1 to 6 are optional and apply if TMGI is used as MBS session ID and needs to be pre-allocated. This procedure can be used to allocate a TMGI to an MBS session.

[0141] In step 7, the AF may perform a service announcement to the WTRU. The AF notifies the WTRU of the MBS session information, which includes the MBS session ID, such as the TMGI, the source-specific multicast address, and possibly other information (such as the MBS service area, session description information, etc.). Step 7 considers a generic MBS service being set up on a 3GPP network. This MBS service may require the participation of multiple UPFs. Therefore, at the moment of step 7, part of the RAN may receive the announcement, while other parts may not. In addition, in step 18 (which will be discussed in detail below), it is assumed that the transmission of the MBS has been established, and then the NG-RAN may receive the announcement and relay it to the WTRU. It is important to note that the WTRU shown in the figure has not yet established a PDU session, so it cannot receive the MBS yet. The MBS service area information may include a cell ID list, a TAI list, geographic area information, or city address information. The cell ID list and the TAI list can only be used by the AF that is located in a trusted domain and knows such information. The MBS service area may also include IEEE 802.11bc accesses, which are identified, for example, by TWIDs (Trusted Wireless IDs) or Registration Areas (RAs) assigned to non-3GPP accesses.

[0142] This new content in the MBS Service Area can be used as a way to indicate that an EBCS AP is available to transmit the service. This MBS Service Information element in context is used to actually store the current area where the content is being transmitted. With the current definition of the element, non-3GPP networks cannot be used. This information may come from multiple sources, such as the AF, which indicates the area where the broadcast service is needed, or it may come from the SMF (the SMF can get it from the UDR / UDM or PCF), and this can be configured in the network. Finally, it is important to note that this element may also appear in the AMF, so it can be used as a variable to indicate where the service is transmitted.

[0143] In 3GPP 23.247, it is assumed that the MBS service area is sent by the AF in step 7.

[0144] The WTRU should know whether the service is a broadcast service or a multicast service in order to decide whether to perform a JOIN operation. This information is obtained by listening to the announcement message from the AF (step 18).

[0145] Steps 8 to 17 correspond to creating an MBS session context on the MB-SMF, selecting an MB-UPF, and creating an MBS session context on the MB-UPF.

[0146] Step 18 shows the periodic announcements performed by the AF. As the path to the WTRU is established, announcements may arrive at the WTRU indicating different relevant information, such as the nature of the service (ie, multicast or broadcast).

[0147] At this point, the WTRU requests to establish a PDU session (arrow box between steps 18 and 19). This procedure contains information about the ASSSS capabilities and indicates that the PDU session to be created may be upgraded later to use multiple access. To cover aspects of bootstrapping to a broadcast network, the exemplary embodiments extend the bootstrapping modes defined in 3GPP TS 23.501 (v17.2.0) (indicated in bold in the arrow box between steps 18 and 19). Currently ATSSS supports four bootstrapping modes, namely: Active-Standby, Minimum Delay, Load Balancing, and Priority-Based.

[0148] A fifth steering mode can be added, namely multicast, where multicast mode is used to steer service data flows to accesses that support specialized broadcast / multicast transmission enhancements, such as IEEE 802.11bc or DVB networks. Broadcast offloading is only applicable to UDP traffic flows and ATSSS-LL (lower layer).

[0149] The definition of this new bootstrap mode may have an impact on other structures defined in 3GPP. Specifically, the 5GSM Capabilities IE (as defined in 3GPP TS 24.501 (v17.5.0) Table 9.11.4.1.1) may be modified to include "ATSSS low layer functions supporting only broadcast failure mode", as shown in Table 3 below:

[0150] Table 3: Modifications to Table 9.11.4.1.1 (3GPP TS 24.501 V17.5.0)

[0151]

[0152]

[0153] The PDU session establishment request in the arrow box between steps 18 and 19 may include an ATSS low layer function bit that supports only multicast failure mode set in the 5GSM function IE.

[0154] Step 19 associates the PDU connection established in the process represented by the arrow box between steps 18 and 19 with the MBS communication flow. Steps 20 to 24 correspond to the completion of the session setup and the preparation of the radio bearer.

[0155] Once the network configuration is complete, the WTRU may join the broadcast stream by issuing an Internet Group Management Protocol / Multicast Listener Discovery (IGMP / MLD) join (step 25) and complete the session join (steps 26 to 30).

[0156] Once a WTRU joins an MBS service (e.g., Figure 6 shown), Figure 7The process of splitting the MBS stream to the IEEE 802.11bc network can be shown as follows Figure 7 Implementation shown. Note that at this point, the MBS is being transmitted on the 3GPP side. Some of the more important new or modified steps are highlighted below with underscores.

[0157] refer to Figure 7 , First, in step 1, the known procedures for the WTRU to connect to the non-3GPP domain and establish a secure N1 transport are performed. Figure 7 The procedures shown in do not presuppose a trusted or untrusted non-3GPP domain, but are applicable to both cases.

[0158] In step 2, the WTRU requests to establish a new PDU session over non-3GPP access. In order to use the ATSSS functionality, the PDU session establishment request introduces information about the ATSSS functionality into the 5GSM Capabilities IE modified as above. This message may also include information to associate the PDU connection related to the MBS communication flow with this new PDU session establishment. The information required to associate the PDU session with the MBS communication flow may be the MBS session ID, such as the TMGI.

[0159] Alternatively, the first PDU Session may have been established over the 3GPP access before step 2. Since the MBS Session ID is included in the PDU Session Establishment Request, this first PDU Session may have been associated with the MBS Session. In step 2, the new PDU Session over the non-3GPP access may be associated with the MBS Session by including the PDU Session ID of the first PDU Session in the PDU Session Establishment Request of step 2.

[0160] In step 3, after receiving the PDU session establishment request, the AMF will select the SMF according to the identifier carried in step 2 (i.e., MBS session ID or PDU session ID), indicating the PDU connection that carries the MBS communication flow in the 3GPP access. On this basis, the SMF responsible for transmitting the MBS communication flow and the MB-SMF will be contacted (steps 4-6).

[0161] Steps 4 to 9 correspond to the standard mechanism by which the SMF collects the information required to handle sessions, authorization, and PCF selection.

[0162] In steps 10 and 11, the SMF will select the UPF based on the non-3GPP location and MBS communication flow (step 10) and configure the transport mechanism required to deliver the traffic to the non-3GPP domain (step 11).

[0163] Through the messages in steps 12 and 13, the SMF can push the available information about the MBS service (according to the MBS context in Tables 1 and 2) to the AMF (step 12), and the AMF can forward this information to the non-3GPP domain (MBS_EBCS_Controller) (step 13). This message carries information used to create the IEEE 802.11bc configuration for the EBCS. This information can be supplemented once the MBS_EBCS_Controller receives the service announcement from the AF. The SMF uses the PDU Session ID or MBS Session ID (e.g., TMGI) in step 2 to determine which information to forward to the AMF in step 12.

[0164] With this information, the MBS_EBCS_Controller configures the EBCS domain (step 14), and in step 15, EBCS service information begins to be transmitted in the EBCS network via IEEE 802.11bc mechanisms (e.g., available EBCS information frames and EBCS ANQP elements), including EBCS configuration (e.g., configuring the services to be announced in the EBCS information frames and their security parameters) and EBCS service announcements (step 16).

[0165] Once the EBCS domain is configured, the WTRU is informed by replying to the PDU Session Establishment (step 17).

[0166] In step 18, the MBS_EBCS_Controller may join the MBS on behalf of the WTRU connected to the EBCS domain. Figure 7 The MBS_EBCS_Controller is shown sending the multicast join primitive, but this can also be done by the WTRU through a newly established PDU Session.

[0167] In step 19, the MBS_EBCS_Controller forwards the PDU Session Establishment Accept message to the AMF.

[0168] In the case of using ATSSS (such as in the present embodiment), the data plane communication flow of the MBS can be transmitted using IEEE802.11bc by applying flow control rules on the IEEE 802.11 network. These rules can be installed by the MBS_EBCS_Controller.

[0169] Step 20 comprises known procedures to update the N4 session that sends traffic to the non-3GPP network. The exact message depends on the choice of transport mechanism decided for the MBS session and is beyond the scope of this disclosure.

[0170] Service announcement integration between 3GPP MBS domain and IEEE 802.11bc for broadcast traffic (ATSSS not supported)

[0171] MBS and IEEE 802.11bc use completely different mechanisms to announce services to users. MBS allows the source of an MBS service to send an announcement message (e.g., using SDP) to inform users of an upcoming MBS session. IEEE 802.11bc requires pre-registration of multicast / broadcast services before allowing them to be transmitted over the air interface. Figure 8 is a signal flow diagram showing different steps extended from 3GPP TS 23.247 (V17.0.0, 2021-09) according to an embodiment for the initial configuration and setup process of a broadcast MBS stream transmitted over an IEEE802.11bc network. The figure shows the MBS_EBCS_Controller as a function of the TNGF / N2IWF. In alternative embodiments, a similar process may be used if the MBS_EBCS_Controller forms part of the N3IWF or any other function as a gateway to a non-3GPP network connected to a 3GPP infrastructure.

[0172] Figure 8 It is 3GPP TS 23.247 (V17.0.0, 2021-09) Figure 7 .1.1.2-1 Initial configuration of MBS session without PCC and 7.3.1-1 MBS session establishment for broadcast The following includes a summary of the steps defined in 3GPP TS 23.247, as well as extensions, behavior changes and / or new procedures included according to this embodiment.

[0173] Figure 8 Steps 1 to 6 are optional and are applicable only when TMGI is used as MBS session ID and needs to be pre-allocated. This procedure is used to allocate TMGI to MBS session.

[0174] In step 7, the AF may perform a service announcement to the WTRU. The AF informs the WTRU of the MBS session information, including the MBS session ID, such as TMGI, source-specific multicast address, and possibly other information (such as MBS service area, session description information, etc.).

[0175] MBS service area information can be a cell ID list, a tracking area identifier (TAI list), geographic area information or city address information. The cell ID list and TAI list should only be used by AFs that are in a trusted domain and the AF is aware of such information. The MBS service area may include IEEE 802.11bc access, which can be identified by TWID, for example. Information provided by the AF is required to understand whether the service is broadcast.

[0176] Step 8 corresponds to the case where the MBS service area includes an IEEE 802.11bc network. In this case, the MBS_EBCS_Controller receives the service announcement (which may be via the Session Initiation Protocol (SIP) or other mechanisms (such as those specified in 3GPP TS 26.346) and uses the information in the service description to construct an MBS Session Context Draft (or a separate structure containing the required EBCS parameters), which includes the relevant information provided by the service announcement. This information is not yet forwarded to the IEEE 802.11bc domain because traffic cannot be initiated at this time and therefore announcements within the IEEE 802.11bc domain cannot be initiated.

[0177] Steps 9 to 16 correspond to creating an MBS session context on the MB-SMF, selecting an MB-UPF, and creating an MBS session context on the MB-UPF.

[0178] After MB-UPF creates the MBS session context, MB-SMF selects AMF to interact with the network supporting IEEE 802.11bc. AMF installs the MBS session context after being triggered by SMF (step 17, in this case, the broadcast context defined in Table 1), and sends the information required to complete the MBS session context to the MBS_EBCS_Controller using the N3 interface (step 18).

[0179] At this point, the MBS_EBCS_Controller is able to complete the MBS session context and push the MBS flow configuration in the IEEE 802.11bc network, pre-configuring announcements and filtering so that the communication flow is broadcast in the network (steps 19 to 20). The messages identified in steps 19 to 21 will use the newly defined interface that can configure the IEEE 802.11bc announcement and filtering mechanism.

[0180] Once the IEEE 802.11bc network is complete, the MBS_EBCS_Controller can join the broadcast stream by issuing an IGMP / MLD join (step 21) and completing a session join (steps 22 to 25).

[0181] Please note that Figure 8 In the embodiment of the present invention, Join / MLD is sent by MBS_EBCS_Controller. However, since this is a functional element, Join / MLD may be sent by any other function belonging to TNGF, N3IWF or similar functions for connecting IEEE 802.11 to 3GPP network.

[0182] In this case, since it is an MBS broadcast transmission, the IEEE 802.11bc network advertises the configuration service and transmits the communication flow over the air even if there is no STA associated with the IEEE 802.11bc AP or no request to start the communication flow is received.

[0183] Steps 26 and 27 are used to indicate to the AF through the NEF / MBSF that the MBS session setup is completed.

[0184] Service announcement integration between 3GPP MBS domain and IEEE 802.11bc for multicast traffic (ATSSS not supported)

[0185] Fig. 9 The message sequence for initiating a multicast service that requires a request from the IEEE 802.11bc side is shown. In this case, the WTRU portion of the MBS_EBCS_Controller plays a central role as it performs the MBS request for the service on behalf of the STAs on the IEEE 802.11bc side.

[0186] Fig. 9 It includes different steps, which are taken from 3GPP TS 23.247 V17.0.0 (2021-09) Figure 7 .1.1.2-1- Initial configuration of MBS session without PCC and Figure 7 .2.1.3-1: PDU session modification for WTRU joining a multicast session.

[0187] Until step 16, Fig. 9 The multicast message sequence shown in the figure is different from the broadcast message sequence ( Figure 8 ) are basically the same. The differences start to appear after the session is set up in the MB-UPF. First, in this case, steps 17 and 18 indicate to the AF that the MBS session setup to the MB-UPF has been completed. This step is necessary because no MBS transmission will be performed unless some WTRU requests a multicast stream. For a WTRU to join a multicast session, it needs to know at least the MBS session ID or the multicast group. This information is partially available from the service announcement in step 19.

[0188] In step 20, the MBS_EBCS_Controller intercepts and analyzes the service announcement message describing the MBS service to be provided. The service announcement may include information such as the IP multicast address, protocol, port or service description used. This information is used to complete the MBS context of this service stored in the MBS_EBCS_Controller.

[0189] In step 21, the information collected from the service announcement (step 20) is configured in the IEEE 802.11bc domain. In step 22, the service begins to be announced in the 802.11bc network by introducing the service in the Enhanced Broadcast Service ANQP element and the EBCS information frame (according to IEEE 802.11bc / D2.0, step 22).

[0190] In step 23, the STA requests to start the MBS service (according to IEEE 802.11bc / D2.0) by issuing an EBCS request frame or an enhanced broadcast service request ANQP element.

[0191] After receiving the service request frame, the IEEE 802.11bc network will notify the MBS_EBCS_Controller that it needs to request service from the 5G network. At this point, the MBS_EBCS_Controller will issue the signaling required to request service and join the multicast stream (steps 24 to 30).

[0192] A key feature of steps 24 and 27 is that the MBS_EBCS_Controller may act as a WTRU on behalf of a node in the non-3GPP domain, requesting a PDU session establishment.

[0193] After this process, the network will establish transmission between the gateway and the IEEE 802.11bc network (step 31), and the multicast stream will begin (step 32).

[0194] MBS Session Activation

[0195] In some exemplary embodiments, the WTRU may receive a request via a first access to receive MBS data via a second access. The first access may be to a 3GPP or non-3GPP access network and the second access may be to another of the 3GPP or non-3GPP access networks. The request may include information required to receive the service (i.e., an MBS session ID or a PDU session ID associated with the MBS session ID).

[0196] As described in clause 7.2.5.2 of 3GPP TS 23.247, the AF may trigger the MBS session activation procedure when receiving multicast data, or the MB-UPF may trigger the MBS session activation procedure when receiving multicast data.

[0197] When MBS session activation is triggered, MB-SMF will send Nmbsmf_MBSSession_ContextStatusNotify(MBS session ID, multicast session activated) to SMF. SMF will then invoke Namf_MT_EnableGroupReachabilityRequest(WTRU list, [PDU session ID of the relevant PDU session], TMGI, [WTRU reachability notification address]) for the AMF serving the WTRUs that are part of the service.

[0198] For each WTRU that is part of the service, the AMF shall determine the CM status of the WTRU's 3GPP and non-3GPP accesses. The AMF may then take the following actions.

[0199] If the WTRU is in CM-CONNECTED state in 3GPP access, the AMF may send a NAS notification to the WTRU, which includes the MBS session ID and the non-3GPP access type that the WTRU should use to receive the MBS session. The NAS notification may be sent over 3GPP access and trigger the WTRU to move from CM-IDLE state to CM-CONNECTED state in non-3GPP access. Moving to CM-CONNECTED state in non-3GPP means triggering the WTRU to send a service request over the non-3GPP access, and the service request may include the MBS session ID or the PDU session ID associated with the MBS session ID.

[0200] If the WTRU is in CM-IDLE state in 3GPP access, the AMF may send a NAS notification containing the MBS session ID and 3GPP access type that the WTRU should use to receive the MBS session. The NAS notification may be sent over non-3GPP access and triggers the WTRU to move from CM-IDLE state to CM-CONNECTED state in 3GPP access. Moving to CM-CONNECTED state in 3GPP means triggering the WTRU to send a service request over 3GPP access, and the service request may include the MBS session ID or the PDU session ID associated with the MBS session ID.

[0201] Exemplary Methods

[0202] Fig.10 is an exemplary flow chart illustrating an exemplary method 1000 for interfacing between a 3GPP network and a wireless local area network (LAN) according to some exemplary embodiments. Fig.10 The exemplary methods and the disclosures attached herein can be regarded as a summary or synthesis of the above-mentioned various disclosures. For convenience and simplicity of description, reference can be made to Figure 5 The architecture described in Fig.10However, Fig.10 The exemplary method shown in can also be performed using different architectures. According to some embodiments, Fig.10 The method may be implemented by a network entity (eg, the MBS / EBCS controller 501 described above). It is worth noting that Fig.10 The methods and / or blocks of can be modified to include or be replaced with any one or more of the procedures or blocks discussed elsewhere herein, such as Figures 6 to 9 Therefore, it will be understood by those skilled in the art that Fig.10 It is provided as an example and modifications thereof are possible still within the scope of certain exemplary embodiments.

[0203] like Fig.10 As shown in the example of , method 1000 may include receiving first information from a 3GPP network at 1005, the first information may indicate or include a service announcement or a protocol data unit (PDU) session request associated with a 3GPP multicast / broadcast service (MBS). The first information may include or indicate MBS session information.

[0204] In some embodiments, the PDU session request may indicate or may include access traffic steering, switching and splitting (ATSSS) functionality, as described elsewhere herein. According to an embodiment, the first information may be received in a non-access stratum (NAS) notification, which may indicate an MBS session identifier and / or a non-3GPP access type that the WTRU may (e.g., should) use to receive the MBS session.

[0205] In an embodiment, method 1000 may include determining an MBS session context in a wireless LAN based on the MBS session information at 1010. The MBS session context may include second information used for (e.g., to be used for) transmitting the MBS via the wireless LAN. According to an embodiment, the wireless LAN may be an 802.11bc network. However, in further exemplary embodiments, the wireless LAN may be another type of LAN.

[0206] According to an embodiment, the method 1000 may include, at 1015 , sending third information (eg, including the second information) indicating the MBS session context to the wireless LAN for distribution to wireless transmission units (WTRUs) in the wireless LAN.

[0207] In some exemplary embodiments, as described above (for example, as shown in Table 1 and / or Table 2), the second information (and / or MBS session context) may include or indicate at least one or more of the following: (1) a list of wireless LAN networks in the MBS service area, (2) an indication of an enhanced broadcast service (EBCS) status, (3) a content identifier, (4) a related content identifier, (5) an access point identifier, (6) an indication of a content authentication algorithm, (7) an indication of a next transmission time, (8) an indication of a protocol and port for transmitting the MBS, (9) an indication of whether the broadcast EBCS needs to be associated with an access point of the wireless LAN, and / or (10) quality of service (QoS) information.

[0208] According to an exemplary embodiment, as discussed in more detail above, the MBS session information may include or may indicate one or more of the following: (1) an MBS session identifier, (2) a temporary mobile group identity (TMGI), (3) an MBS service area, and / or (4) session description information.

[0209] In some embodiments, the method 1000 may include joining the MBS on behalf of the WTRU in the wireless LAN. For example, the joining may include transmitting an Internet Group Management Protocol / Multicast Listener Discovery (IGMP / MLD) join message corresponding to the MBS to the 3GPP network.

[0210] According to some exemplary embodiments, in case of multicast transmission, method 1000 may include receiving a trigger signal from the EBCS domain to start a multicast flow associated with the MBS.

[0211] in conclusion

[0212] Although features and elements are provided above in specific combinations, it will be appreciated by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this application, which are intended to illustrate multiple aspects. It will be appreciated by those of ordinary skill in the art that many modifications and variations may be made without departing from its spirit and scope. Unless expressly provided, any element, action or instruction used in the description of this application should not be interpreted as being essential or indispensable to the present invention. In addition to those listed herein, it will be apparent to those of ordinary skill in the art from the foregoing description that functionally equivalent methods and devices within the scope of the present disclosure. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full range of equivalents enjoyed by such claims. It should be understood that the present disclosure is not limited to a particular method or system.

[0213] For simplicity, the foregoing embodiments are discussed with respect to the terminology and structure of infrared devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (e.g., sound waves).

[0214] It should also be understood that the terminology used herein is used only to describe specific embodiments and is not intended to be limiting. As used herein, the term "video" or the term "image" may refer to any of a snapshot, a single image, and / or a plurality of images displayed over a period of time. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" or its abbreviation "HMD" may refer to or include: (i) a wireless transmit and / or receive unit (WTRU); (ii) any one of a plurality of embodiments of a WTRU; (iii) a wireless and / or wired (e.g., bindable) device configured with some or all of the structure and functionality of a WTRU; (iii) a device having wireless functionality and / or wired functionality that is configured with less than all of the structure and functionality of a WTRU; or (iv) the like. This document combines Figures 1A to 1D Details of an example WTRU are provided, which may represent any WTRU described herein. As another example, various embodiments disclosed herein above and below are described as using a head mounted display. Those skilled in the art will recognize that devices other than head mounted displays may be used, and that some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0215] In addition, the methods provided herein may be implemented in a computer program, software, or firmware, which is contained in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) 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, caches, 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 the software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.

[0216] The above methods, devices and systems may be modified without departing from the scope of the present invention. In view of the wide variety of embodiments that may be applied, it should be understood that the embodiments shown are only examples and should not be considered to limit the scope of the following claims. For example, the embodiments provided herein include handheld devices that may include or be used with any suitable voltage source, such as a battery, to provide any suitable voltage.

[0217] In addition, in the above-described embodiments, it is noted that processing platforms, computing systems, controllers, and other devices including processors are described. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as "execution," "computer execution," or "CPU execution."

[0218] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits, which may result in the ultimate transformation or reduction of the electrical signal, and the maintenance of the data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU, and other processing of the signal. The memory location where the data bit is maintained is a physical location with specific electrical, magnetic, optical or organic properties corresponding to or representing the data bit. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may support the provided methods.

[0219] The data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) CPU-readable mass storage system. The computer-readable media may include cooperating or interconnected computer-readable media that reside exclusively on a processing system or distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may support the provided methods.

[0220] In an illustrative embodiment, any operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0221] There is little distinction between hardware and software implementations of aspects of the system. The use of hardware or software is often (but not always, as the choice between hardware and software may become important in certain circumstances) a design choice that represents a trade-off between cost and efficiency. There may be a variety of carriers (e.g., hardware, software, and / or firmware) that can implement the processes and / or systems and / or other techniques described herein, and the preferred carrier may vary depending on the environment in which the processes and / or systems and / or other techniques are deployed. For example, if the implementer determines that speed and accuracy are critical, the implementer may choose a carrier that uses primarily hardware and / or firmware. If flexibility is critical, the implementer may choose a software-based implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0222] The foregoing detailed description has described various embodiments of the device and / or process by using block diagrams, flow charts and / or examples. As long as these block diagrams, flow charts and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation in these block diagrams, flow charts or examples can be implemented individually and / or collectively by various hardware, software, firmware or almost any combination. In an embodiment, several parts of the subject matter described herein can be implemented by application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) and / or other integrated formats. However, those skilled in the art will recognize that certain aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as almost any combination thereof, and according to the present disclosure, designing circuits and / or writing software and / or firmware codes are completely within the skill of those skilled in the art. Furthermore, those skilled in the art will recognize that the mechanisms of the subject matter described herein may be distributed as a program product in various forms, and that the illustrative embodiments of the subject matter described herein are applicable to the particular type of signal-bearing media used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following media: recordable media, such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memories, etc., and transmission media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0223] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner described herein and then use engineering practices to integrate the devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may typically include one or more system unit housings, a video display device, memory (e.g., volatile and non-volatile memory), a processor (e.g., a microprocessor and a digital signal processor), a computing entity (e.g., an operating system, a driver, a graphical user interface, and an application), one or more interactive devices (e.g., a touch pad or screen), and / or a control system (including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as components typically found in data computing / communication and / or network computing / communication systems.

[0224] The subject matter described herein sometimes shows different components contained in or connected to different other components. It should be understood that the architecture depicted in this way is only an example, and many other architectures that realize the same function can actually be implemented. In a conceptual sense, any arrangement of components that realize the same function is effectively "associated", so that the desired function can be realized. Therefore, any two components combined to realize a specific function herein can be regarded as "associated" with each other, so as to realize the desired function, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be regarded as "operably connected" or "operably coupled" to each other to realize the desired function, and any two components that can be so associated can also be regarded as "operably coupled" to each other to realize the desired function. Specific examples of operable coupling include, but are not limited to, physically matchable and / or physically interactive components and / or wirelessly interactive and / or wirelessly interactive components and / or logically interactive and / or logically interactive components.

[0225] For the use of almost any plural and / or singular terms in this document, those skilled in the art can convert the plural to the singular and / or the singular to the plural, depending on the context and / or application. For clarity, various singular / plural arrangements may be explicitly set forth herein.

[0226] Those skilled in the art will appreciate that, in general, the terms used herein, especially in the appended claims (e.g., the bodies of the appended claims), are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "including" should be interpreted as "including but not limited to", etc.). Those skilled in the art will also understand that if a specific number of claim recitations are intended to be introduced, such intent will be explicitly stated in the claim, and if such statement is absent, such intent is not present. For example, if only one item is intended to be introduced, the term "single" or similar language may be used. To aid understanding, the following appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be interpreted as implying that the introduction of a claim recitation by the indefinite article "a" or "an" will limit any particular claim that includes such introduced claim recitation to embodiments that contain only one such recitation, even if the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same is true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of claim recitations is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted as meaning at least the number of recitations (e.g., a simple recitation of "two recitations" without other modifiers means at least two recitations, or two or more recitations). In addition, where a convention similar to "at least one of A, B, and C, etc." is used, generally the intention of such construction is the convention understood by those skilled in the art (e.g., "a system having at least one of A, B, and C" would include, but is not limited to, a system having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Where a convention similar to "at least one of A, B, or C, etc." is used, generally the intention of such construction is the convention understood by those skilled in the art (e.g., "a system having at least one of A, B, or C" would include, but is not limited to, a system having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will also appreciate that almost any disjunctive word and / or phrase that indicates two or more alternative terms, whether in the specification, claims, or drawings, should be understood to include the possibility of one, either, or both terms. For example, the phrase "A or B" should be understood to include the possibility of "A" or "B" or "A and B".Furthermore, as used herein, the term "any" followed by a listing of multiple items and / or multiple categories of items is intended to include "any," "any combination," "any multiple," and / or "any combination of multiples" of the items and / or categories of items, alone or in combination with other items and / or other categories of items. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero. And as used herein, the term "plurality" is intended to be synonymous with "plurality."

[0227] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0228] It will be understood by those skilled in the art that all ranges disclosed herein also encompass any possible sub-ranges and combinations of sub-ranges thereof for any purpose, such as in providing a written description. Any listed range can be easily understood to fully describe and be able to decompose the same range into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be easily decomposed into the lower third, the middle third, and the upper third, etc. It will also be understood by those skilled in the art that all languages, such as "at most", "at least", "greater than", "less than", etc., include the listed numbers and refer to the ranges that can be subsequently decomposed into sub-ranges as described above. Finally, it will be understood by those skilled in the art that the range includes each individual member. Therefore, for example, a group with 1-3 cells refers to a group with 1, 2, or 3 cells. Similarly, a group with 1-5 cells refers to a group with 1, 2, 3, 4, or 5 cells, and so on.

[0229] Furthermore, the claims should not be read as limited to the order or elements provided unless otherwise stated. Furthermore, use of the term "for" in any claim is intended to invoke 35 U.S.C. § 112, 6 or the “for” plus “function” claim format, any claim without the term “for” is not intended to be cited.

[0230] Suitable processors include, for example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), an application specific standard product (ASSP); a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine.

[0231] The WTRU may be coupled to hardware and / or software-implemented modules, including software-defined radio (SDR), and other components, such as cameras, video camera modules, video phones, speaker phones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module).

[0232] Although various embodiments have been described in the form of communication systems, it is contemplated that these systems can be implemented in software on a microprocessor / general purpose computer (not shown). In some embodiments, one or more functions of various components can be implemented in software controlling a general purpose computer.

[0233] Furthermore, although the invention has been illustrated and described herein with reference to specific embodiments, the invention is not limited to the details shown. Rather, various modifications may be made to the details within the scope and range of equivalents of the claims without departing from the invention.

[0234] References

[0235] [1]https: / / mentor.ieee.org / 802.11 / dcn / 19 / 11-19-0151-05-00bc-802-11bc-functional-requirements-document.doc

[0236] [2]https: / / mentor.ieee.org / 802.11 / dcn / 19 / 11-19-0268-05-00bc-tgbc-use-case-document.pptx

[0237] [3] 3GPP 5G Network and WLAN Interworking Technical Report: https: / / mentor.ieee.org / 802.11 / dcn / 20 / 11-20-0013-17-AANI-technical-report-on-interworking-between-3gpp-5g-network-wlan.docx

[0238] [4] TS 23.247 (v17.0.0, 2021-09): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture Enhancements for 5G Multicast Broadcast Services; Stage 2 (Release 17)

[0239] [5] TS 23.502 (v17.2.0, 2021-09): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for 5G System (5GS); Stage 2 (Release 17)

[0240] [6] TS 24.502 (v17.4.0, 2021-09): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Access to the 3GPP 5G Core Network (5GCN) via non-3GPP access networks

[0241] [7] TS 23.501 (v17.2.0, 2021-09): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture of 5G System (5GS); Stage 2 (Release 17)

[0242] [8] TS 24.501 (v17.5.0, 2021-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access Stratum (NAS) Protocols for 5G System (5GS); Stage 3 (Release 17)

[0243] [9] TS 26.346 (v16.9.1, 2021-05): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast / Multicast Service (MBMS); Protocols and Codecs (Release 16)

[0244]

[10] IEEE 802.11bc / D2.0: Draft standard for information technology—Telecommunications and information exchange between systems in local and metropolitan area networks—Specific requirements: Part 11: Wireless LAN medium access control (MAC) and physical layer (PHY) specifications. Amendment 5: Enhanced broadcast service

[0245]

[11] TS 23.468 (v16.0.0, 2020-07): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; LTE Group Communication System Enabler (GCSE_LTE) Stage 2 (Release 16)

Claims

1. An apparatus configured to interface between a 3GPP network and a wireless local area network (LAN), the apparatus comprising: A circuit comprising any one of a processor, a memory, a transmitter, and a receiver, the circuit being configured to: receiving first information indicating a service announcement or a protocol data unit (PDU) session request associated with a 3GPP multicast / broadcast service (MBS) from the 3GPP network, the first information including MBS session information; determining an MBS session context in the wireless LAN based on the MBS session information, the MBS session context comprising second information for transmitting an MBS through the wireless LAN; as well as Third information indicating the MBS session context is sent to the wireless LAN for distribution to wireless transmission units (WTRUs) in the wireless LAN.

2. The apparatus of claim 1, wherein the wireless LAN comprises an 802.11bc network.

3. The apparatus according to any one of claims 1 and 2, wherein the PDU session request indicates access traffic steering, switching and splitting (ATSSS) capability.

4. The apparatus according to any one of claims 1 to 3, wherein the second information comprises any one of the following: (1) a list of wireless LAN networks in an MBS service area, (2) an indication of an enhanced broadcast service (EBCS) status, (3) a content identifier, (4) a related content identifier, (5) an access point identifier, (6) an indication of a content authentication algorithm, (7) an indication of a next transmission time, (8) an indication of a protocol and a port used to transmit the MBS, (9) an indication of whether the broadcasted EBCS needs to be associated with an access point of the wireless LAN, and / or (10) quality of service (QoS) information.

5. The apparatus according to any one of claims 1 to 4, wherein the MBS session information comprises any one of the following: (1) an MBS session identifier, (2) a temporary mobile group identity (TMGI), (3) an MBS service area and / or (4) session description information.

6. The apparatus of any one of claims 1 to 5, wherein the first information is received in a non-access stratum (NAS) notification indicating an MBS session identifier and a non-3GPP access type that the WTRU should use to receive an MBS session.

7. The apparatus according to any one of claims 1 to 6, wherein the circuit is configured to: Joining the MBS on behalf of the WTRU in the wireless LAN.

8. The apparatus of claim 7, wherein the circuit is configured to: An Internet Group Management Protocol / Multicast Listener Discovery (IGMP / MLD) join message corresponding to the MBS is sent to the 3GPP network.

9. The apparatus according to any one of claims 1 to 8, wherein in case of multicast transmission, the circuit is configured to receive a trigger signal from an EBCS domain to start a multicast flow associated with the MBS.

10. A method for interfacing between a 3GPP network and a wireless local area network (LAN), the method comprising: receiving first information indicating a service announcement or a protocol data unit (PDU) session request associated with a 3GPP multicast / broadcast service (MBS) from the 3GPP network, the first information including MBS session information; determining an MBS session context in the wireless LAN based on the MBS session information, the MBS session context comprising second information for transmitting an MBS through the wireless LAN; as well as Third information indicating the MBS session context is sent to the wireless LAN for distribution to wireless transmission units (WTRUs) in the wireless LAN.

11. The method of claim 1, wherein the wireless LAN comprises an 802.11bc network.

12. The method according to any one of claims 10 and 11, wherein the PDU session request indicates Access Traffic Steering, Switching and Splitting (ATSSS) capability.

13. The method according to any one of claims 10 to 12, wherein the second information comprises any one of the following: (1) a list of wireless LAN networks in an MBS service area, (2) an indication of an enhanced broadcast service (EBCS) status, (3) a content identifier, (4) a related content identifier, (5) an access point identifier, (6) an indication of a content authentication algorithm, (7) an indication of a next transmission time, (8) an indication of a protocol and port used to transmit the MBS, (9) an indication of whether the broadcasted EBCS needs to be associated with an access point of the wireless LAN, and / or (10) quality of service (QoS) information.

14. The method according to any one of claims 10 to 13, wherein the MBS session information comprises any one of the following: (1) an MBS session identifier, (2) a temporary mobile group identity (TMGI), (3) an MBS service area and / or (4) session description information.

15. The method of any one of claims 10 to 14, wherein the first information is received in a non-access stratum (NAS) notification indicating an MBS session identifier and a non-3GPP access type that the WTRU should use to receive an MBS session.

16. The method according to any one of claims 10 to 15, comprising: Joining the MBS on behalf of the WTRU in the wireless LAN.

17. The method of claim 16, wherein the joining comprises sending an Internet Group Management Protocol / Multicast Listener Discovery (IGMP / MLD) join message corresponding to the MBS to the 3GPP network.

18. The method according to any one of claims 10 to 17, wherein in case of multicast transmission, the method comprises receiving a trigger signal from an EBCS domain to start a multicast flow associated with the MBS.

Images