Main wireless transmitting and receiving unit and method implemented by main wireless transmitting and receiving unit

Abstract

The method implemented by a primary wireless transmit receive unit (WTRU) comprises: sending a PDU session establishment request to establish a single shared PDU session for the primary WTRU and one or more other WTRUs, where the PDU establishment request comprises at least one indication of a multicast stream and at least one indication of a unicast stream, wherein the indicated multicast stream and the indicated unicast stream are associated with the single shared PDU session; and receiving a PDU session establishment response, wherein the PDU session establishment response establishes the single shared PDU session with the one or more other WTRUs.

Description

[0001] This application is a divisional application of the patent application with the application date of October 7, 2022, application number 202280074963.9, and invention title "Multicast-Broadcast Traffic Delivery for Distributed Terminals".

[0002] Cross-reference to Related Applications

[0003] This application claims the benefit of U.S. Provisional Application No. 63 / 253,873, filed on October 8, 2021, the content of which is incorporated herein by reference. Summary of the Invention

[0004] In some cases, various advanced end-user devices, such as wireless transmit / receive units (WTRUs), can be used to consume content (e.g., watch / listen to pre-recorded content, interact with content or others, watch / listen to live content, data, traffic, etc.). Thus, to meet these new usage scenarios, there can be a single PDU session management process that distributes a single PDU session among multiple devices on the network. In some cases, there can be a distribution of functions belonging to a single terminal across multiple terminals, thereby improving execution efficiency and enhancing the user experience.

[0005] A method implemented by a primary wireless transmit / receive unit (WTRU) includes: sending a PDU session establishment request to establish a single shared PDU session for the primary WTRU and one or more other WTRUs, wherein the PDU establishment request includes at least one indication of a multicast flow and at least one indication of a unicast flow, and wherein the indicated multicast flow and the indicated unicast flow are associated with the single shared PDU session; and receiving a PDU session establishment response that establishes the single shared PDU session with the one or more other WTRUs.

[0006] A primary wireless transmit / receive unit (WTRU) includes: a processor operatively coupled to a transceiver, the processor and the transceiver being configured to send a PDU session establishment request to establish a single shared PDU session for the primary WTRU and one or more other WTRUs, wherein the PDU establishment request includes at least one indication of a multicast flow and at least one indication of a unicast flow, and wherein the indicated multicast flow and the indicated unicast flow are associated with the single shared PDU session; and the processor and the transceiver, the processor and the transceiver being configured to receive a PDU session establishment response that establishes the single shared PDU session with the one or more other WTRUs. Brief Description of the Drawings

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

[0008] Figure 1A is a system diagram showing an exemplary communication system in which one or more of the disclosed embodiments can be implemented;

[0009] Figure 1B is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that can be used within the communication system shown in Figure 1A in accordance with one embodiment;

[0010] Figure 1C is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used within the communication system shown in Figure 1A in accordance with one embodiment;

[0011] Figure 1D is a system diagram showing another exemplary RAN and another exemplary CN that can be used within the communication system shown in Figure 1A in accordance with one embodiment;

[0012] Figure 2 shows an example of a separate and shared delivery method in accordance with the embodiments disclosed herein;

[0013] Figure 3 shows an example of an architecture for implementing the scenarios and embodiments disclosed herein;

[0014] Figure 4 shows an example of a scenario in which a single PDU session carries MBS and non-MBS flows for a distributed terminal;

[0015] Figure 5 shows an example of actions for MBS and non-MBS traffic transmission on a single PDU session for a distributed terminal in accordance with the embodiments disclosed herein; and

[0016] Figure 6 shows an example of establishing a transmission on a single PDU session in accordance with the embodiments disclosed herein. DETAILED DESCRIPTION

[0017] In some cases, various advanced end-user devices such as wireless transmit / receive units (WTRUs) can be used to consume content (e.g., watch / listen to pre-recorded content, interact with content or others, watch / listen to live content, data, traffic, etc.). Due to recent advancements in various device form factors, the prevalence of these devices with various capabilities (e.g., video presentation devices such as televisions, projectors, haptic suites, immersive audio systems, etc.) has increased significantly. As a result, data in multiple modalities (e.g., audio, video, haptic, etc.) must be efficiently transmitted over the network to those end devices while meeting quality of experience (QoE) requirements.

[0018] However, in traditional scenarios when consuming a single experience, the user may be limited to the initial device being used for that content / experience, even though other better devices may become available / are available around the user during the interaction with that content / experience (e.g., when the user moves around the house, more devices may enter his / her vicinity). Such traditional scenarios may limit the experience / content to one device (e.g., to the user's mobile phone - unless the user manually configures the experience / content and / or transfers the experience / content to another device).

[0019] Accordingly, there is a need for systems, devices, and / or methods for delivering content / experiences to more than one WTRU. For example, there is a need to deliver multicast-broadcast traffic to distributed WTRUs. Also, there is a need to distribute a single PDU session among multiple WTRUs on the network. There is also a need to distribute functions belonging to a single WTRU (e.g., when distributing a single PDU session) across multiple WTRUs. The partitioning of WTRU functions allows specific functions at the end device to be offloaded to other devices for execution to improve the overall experience (e.g., video for a gaming experience can be transferred to a larger display, but functions related to haptic feedback for the game can remain at the initiating device, thus providing a better gaming experience). As a result of such functional modularization / separation, a multimodal stream (e.g., audio, video, input, haptic, etc.) initially sent to only one WTRU can also be separated and distributed to the corresponding WTRU functions distributed among multiple WTRUs. Additionally, when using WTRUs distributed over the network (e.g., in a 5G system), separate PDU sessions can be used, and thus, each individual WTRU can be identified not only as a separate stand-alone device but also as potentially belonging to a separate authorized user. When distributing functions belonging to a single WTRU (e.g., and a single authorized user) across multiple WTRUs, a single PDU session management process can allow the utilization of a single PDU session among multiple devices on the network. This can improve the efficiency of content distribution and / or enhance the user experience. Accordingly, functions belonging to a single WTRU can be distributed / offloaded to other WTRUs along with the corresponding PDU session.

[0020] Figure 1A FIG. 1 is a schematic diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 may enable the plurality of wireless users to access such content through the sharing of 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 discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0021] As Figure 1A shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, 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 one of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a terminal, 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 computer, 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, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any one of the WTRUs 102a, 102b, 102c, and 102d (or any WTRU described herein) may be interchangeably referred to as one or more of the foregoing devices.

[0022] The communication system 100 may further include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as CN 106, Internet 110, and / or other networks 112. By way of example, base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, evolved Node Bs (eNBs), home Node Bs, home evolved Node Bs, next generation Node Bs such as gNode Bs (gNBs), New Radio (NR) Node Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a, 114b are each depicted as a single element, it should be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0024] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) may be used to establish air interface 116.

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

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

[0027] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish the air interface 116.

[0028] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base stations 114a and the WTRUs 102a, 102b, 102c can implement LTE radio access and NR radio access together using, for example, the Dual Connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

[0029] 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), GSM Enhanced Data Rate for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0030] Figure 1A The base station 114b in may be, for example, a wireless router, a home Node B, a home evolved Node B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business premises, a home, 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 one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As Figure 1A shown, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106.

[0031] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Internet Protocol Voice (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, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, location-based services for mobile devices, prepaid calls, Internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not shown in Figure 1Ais shown, but it should be understood that RAN 104 and / or CN 106 may communicate directly or indirectly with other RANs that employ the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104 that may utilize NR radio technology, CN 106 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0032] CN 106 may also act as a gateway for 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 network 112 may include wired communication networks and / or wireless communication networks that are owned and / or operated by other service providers. For example, the network 112 may include another CN that is connected to one or more RANs, and the other CN may employ the same RAT as RAN 104 or a different RAT.

[0033] Some or all of the WTRUs in the communication system 100, such as WTRUs 102a, 102b, 102c, 102d, may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, Figure 1A the illustrated WTRU 102c may be configured to communicate with a base station 114a that may employ a cellular-based radio technology and with a base station 114b that may employ IEEE 802 radio technology.

[0034] Figure 1B is a system diagram showing an exemplary WTRU 102. As Figure 1B shown, the WTRU 102 may include a processor 118, a transceiver 120, transmit / receive elements 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0035] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 can execute signal encoding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120, which can be coupled to a transmit / receive element 122. Although Figure 1B the processor 118 and the transceiver 120 are depicted as separate components, it should be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

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

[0038] The transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive element 122 and demodulate the signals received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. For example, thus, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

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

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

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

[0042] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and / or hardware modules that provide additional features, functions, and / or wired or wireless connections. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. The peripheral device 138 may include one or more sensors. The sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographical location sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0043] The WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all of the signals in a signal (e.g., associated with a particular subframe for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., chokes) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio, for which some or all of the transmit and receive signals (e.g., associated with a particular subframe for UL (e.g., for transmission) or DL (e.g., for reception)).

[0044] Figure 1C FIG. is a system diagram of the RAN 104 and the CN 106 according to one embodiment. As noted above, the RAN 104 may communicate with the WTRU 102a, 102b, 102c via the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

[0045] The RAN 104 may include evolved Node Bs 160a, 160b, 160c, but it should be understood that the RAN 104 may include any number of evolved Node Bs while remaining consistent with the embodiment. Each of the evolved Node Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, the evolved Node Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0046] Each of evolved Node Bs 160a, 160b, 160c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, etc. As Figure 1C shown, the evolved Node Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

[0047] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0048] The MME 162 may be connected to each of the evolved Node Bs 162a, 162b, 162c in the RAN 104 via the S1 interface and may act 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 specific serving gateway during the initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide control plane functions for handover between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

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

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

[0051] CN 106 can facilitate communication with other networks. For example, CN 106 can provide access to a circuit-switched network (such as, the PSTN 108) for the WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, CN 106 can include an IP gateway (such as, an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and the PSTN 108 or can communicate with the IP gateway. In addition, CN 106 can provide access to other networks 112 for the WTRUs 102a, 102b, 102c, and the other networks can include other wired and / or wireless networks owned and / or operated by other service providers.

[0052] Although the WTRU is described in Figures 1A to 1D as a wireless terminal, it is contemplated that in some representative embodiments, such a terminal can (e.g., temporarily or permanently) use a wired communication interface with a communication network.

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

[0054] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic originating from outside the BSS and destined for an STA can reach the STA through the AP and can be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS can be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS can be sent through the AP. For example, the source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In some representative embodiments, DLS can use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and the STAs within the IBSS or using the IBSS (e.g., all STAs in the IBSS) can communicate directly with each other. The IBSS communication mode can sometimes be referred to as an "ad-hoc" communication mode in this document.

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

[0056] High Throughput (HT) STAs may communicate using a 40 MHz wide channel, e.g., by combining the primary 20 MHz channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0058] 802.11af and 802.11ah support operation modes below 1 GHz. Relative to those used in 802.11n and 802.11ac, the channel operation bandwidth and carriers are reduced in 802.11af and 802.11ah. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication (MTC), such as MTC devices in a macro coverage area. The MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. The MTC devices may include a battery with a battery life higher than a threshold (e.g., to maintain a very long battery life).

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

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

[0061] Figure 1DFIG. 0 is a system diagram showing RAN 104 and CN 106 according to one embodiment. As noted above, RAN 104 may employ NR radio technology to communicate with WTRU 102a, 102b, 102c via air interface 116. RAN 104 may also communicate with CN 106.

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

[0063] WTRU 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU 102a, 102b, 102c may use subframes or transmission time intervals (TTIs) of various lengths or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths) to communicate with gNBs 180a, 180b, 180c.

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

[0065] Each of gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As Figure 1D shown, gNBs 180a, 180b, 180c can communicate with each other via the Xn interface.

[0066] Figure 1DThe illustrated CN 106 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possibly data networks (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0067] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services that rely on ultra-reliable low-latency (URLLC) access, services that rely on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 182a, 182b may provide control plane functions for handover between the RAN 104 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0068] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b may select and control the UPFs 184a, 184b and configure the traffic routing through the UPFs 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 DL data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

[0070] CN 106 can facilitate communication with other networks. For example, CN 106 can include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and the PSTN 108 or can communicate with this IP gateway. Additionally, CN 106 can provide access to other networks 112 to WTRUs 102a, 102b, and 102c. These other networks can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to DNs 185a and 185b via UPF 184a and 184b through the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and local DNs 185a and 185b.

[0071] In addition, one or more of the following may be present in an exemplary communication system: a Multicast Broadcast User Plane Function (MB-UPF); an Application Function (AF); a 5G Core (5GC); an Access and Mobility Management Function (AMF); a Session Management Function (SMF); and / or a Multicast Broadcast Session Management Function (MB-SMF). One or more of these components may be de facto embodied (e.g., two entities operating from one device) or physically embodied in a WTRU or a hardware device similar to a WTRU. In some aspects, these are nodes on the network.

[0072] Generally, in Figures 1A to 1DThe neutralization and / or any network - side device / node / function / base station described anywhere herein may be interchangeable, and the reference to the network may refer to a specific entity on the network side (e.g., in the communication between a WTRU and a network entity such as a base station), such as a device, node, function, base station, cloud, etc., as disclosed herein. Further, a transmission - reception point (TRP) may be used interchangeably with one or more of a TP (transmission point), RP (reception point), RRH (radio remote head), DA (distributed antenna), BS (base station), a sector and a cell (e.g., a geographical cell area served by a BS) of the (BS), but still in accordance with the present invention. Hereinafter, multiple TRPs may be used interchangeably with one or more of MTRP, M - TRP, and multiple TRPs, but still in accordance with the present disclosure.

[0073] In view of Figures 1A to 1D and Figures 1A to 1D In view of the corresponding description, one or more functions or all functions of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a - d, base stations 114a - b, evolved Node Bs 160a - c, MME 162, SGW 164, PGW 166, gNBs 180a - c, AMFs 182a - b, UPFs 184a - b, SMFs 183a - b, DNs 185a - b, and / or any other device described herein. A simulation device may be one or more devices configured to mimic one or more functions or all functions described herein. For example, a simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

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

[0076] Figure 2 An exemplary communication system utilizing multicast broadcast services is shown. Multicast broadcast service (MBS) traffic may be used to distribute traffic to multiple WTRUs. In some scenarios, MBS traffic may be used to efficiently deliver content from a single data source to multiple WTRUs. For example, MBS traffic 201 may originate from a single source, pass through a core network 211 (e.g., 5G CN), where the MBS traffic is replicated into multiple PDU sessions (e.g., 203B and 203C), each of which may be destined for a different WTRU (e.g., 102C and 102D respectively). This scenario provides separate MBS traffic delivery 204B, where separate copies of the received data packets are delivered to separate WTRUs via the PDU sessions.

[0077] Multicast may be used to serve several types of data streams (e.g., data patterns) to a single user via distributed WTRUs, as well as to serve multi-mode traffic to multiple users. Depending on various conditions, multiple delivery methods may be used in a communication system. As shown, there may be separate MBS traffic delivery 204B and shared MBS traffic delivery 204A. In the latter, a single copy of the MBS packets may be received at a RAN node, which in turn uses a point-to-point (PTP) or point-to-multipoint (PTM) protocol (e.g., 213) to deliver them to the corresponding WTRUs. For example, MBS traffic 201 may originate from a single source, pass through a core network 211 (e.g., 5G CN), where the MBS traffic is sent in a shared transmission 203A to a radio access network 212 and subsequently distributed to multiple WTRUs 102a and 102b.

[0078] In some cases, MBS traffic may be distributed among functions that are distributed over multiple WTRUs. WTRU function distribution involves the partitioning of functions that run on a WTRU and the collaborative distributed execution of those functions among other participating WTRUs. The partitioned functions may include different execution requirements and / or different communication requirements / mode, and / or varying communication modalities. During this distribution process, the WTRU functions and a single PDU session established for the original WTRU may be distributed among the participating WTRUs. Additionally, multi-mode communication may benefit from using multicast / broadcast delivery methods to implement distributed WTRU functions, depending on the requirements of those functions (e.g., two of five distributed WTRU functions may receive data via multicast, where both functions require the same data). Or these functions may be added to an existing multicast group so that the network does not have to process the same data separately and deliver that same data to the distributed functions, thereby improving communication efficiency. In some traditional cases, separate PDU sessions are created for individual deliveries and separate shared delivery sessions are created for shared delivery methods, creating additional signaling and resource utilization.

[0079] Figure 3 Examples of different architectures for WTRU function distribution are shown. For illustrative purposes, there may be three different scenarios for WTRU function distribution: device-to-device (Scenario A), device-to-edge (Scenario B), and / or device-to-cloud (Scenario C). While the examples disclosed herein may discuss the processes with respect to Scenario B and Scenario C, it should be understood that the techniques and methods may equally apply to all scenarios. In any scenario, there may be a process for distributing WTRU functions and a single PDU session that includes MBS flows across multiple WTRUs.

[0080] The components used are first described herein. Then, the process for distributing WTRU functions across multiple WTRUs on a single session is described.

[0081] In Figure 3 WTRU 320, at least two layers are shown: a partitioning layer 321 and a function distribution layer 322A. The function distribution layer 322A may be decomposed into components shown at 322B, such as a terminal analyzer 322B1, a user context engine 322B2, a discovery engine 322B4, and / or a function manager 322B5. Each component / layer / device shown may be optional depending on a given scenario, and this illustration is not intended as an exhaustive list of components / layers / devices for a given scenario.

[0082] The functional distribution layer (e.g., 322A) includes virtualization of WTRU functions, management of resources (e.g., device local resources and network resources), and / or functional life cycle. Functions at various layers of the WTRU stack can be partitioned to ultimately execute these functions over the network, thus optimizing resources and user experience.

[0083] The analyzer (e.g., 322B1) provides functional information (e.g., type of hardware functions, system calls, etc.) and run-time information (e.g., run-time CPU, energy utilization, etc.) about existing individual device (e.g., WTRU) functions. Such information can be used for both functional life cycle management and resource management decisions by both the functional manager component (e.g., 322B5) and the communication manager component (e.g., 322B3). This component (e.g., the analyzer entity) can be implemented as an operating system or application layer service with security privileges to collect the said information.

[0084] The user context engine (e.g., 322B2) can collect context information of the user (e.g., of the WTRU) by sensors in the WTRU (e.g., user location received by a GPS receiver) and / or other services / applications that provide information indicative of user behavior (e.g., user calendar). This component can be implemented as an operating system or application layer service with API calls (e.g., REST API calls) to the corresponding sensor software drivers and / or network services. In some instances, continuously collecting and storing such information may lead to over-utilization of permanent and / or non-permanent storage. Thus, the user context engine (e.g., 322B2) can collect and store information only when requested by the functional and communication manager components.

[0085] For offloading WTRU functions, the distribution layer must discover previously unknown available WTRUs. In particular, in the case where the WTRU (e.g., the user) is mobile, a suitable WTRU for offloading must be discovered. The discovery engine (e.g., 322B4) provides an API for actively registering / querying available WTRUs (e.g., for the functional / communication manager components). Otherwise, it can also actively search for WTRUs around the WTRU by periodically scanning the network and then provide the newly discovered WTRUs to the communication manager component. Such information can in turn be used for making functional offloading / distribution decisions. Optionally, the discovery engine can use discovery services provided by network operators, discovery services provided by non-3GPP access networks, and / or peer-to-peer WTRU / network (e.g., Bluetooth) discovery methods to discover new WTRUs.

[0086] The function manager (e.g., 322B5) makes lifecycle management decisions regarding the local operation of WTRU functions (e.g., turning off WTRU functions to save energy) and decisions regarding offloading / distributing functions to be executed to more suitable discovered WTRUs. Additionally, considering the type of content used by each individual participating WTRU, the function manager may also decide whether each individual function must receive data using unicast or multicast (MBS). Ultimately, the decisions made can optimize the energy efficiency of the local WTRU, the resource utilization of the WTRU and the network, and / or the overall user experience. Such decisions can be made using information collected based on user behavior (e.g., via a context engine), resource consumption (e.g., via an analyzer), and user mobility / WTRU availability (e.g., via a discovery engine).

[0087] The communication manager (e.g., 322B3) manages the interconnection between WTRUs that provide the ability for the distributed execution of WTRU functions and the interconnection between the functions themselves. Such processes may include the selection (e.g., network selection) and / or management of communication medium functions. The communication manager may also initiate connectivity with the 5GC and manage the corresponding QoS and MBS flows (e.g., the establishment of MBS flows as described herein).

[0088] Regarding the local hub (e.g., 330), an end-user device such as a WTRU can provide resources (e.g., computing resources, display screens, etc.) to be used by other WTRUs / users in its vicinity via the local hub. The local hub provides APIs (e.g., functions of the discovery engine) for such resource provider WTRUs to register their capabilities for discovery by other WTRUs in the vicinity of the user (e.g., at home, on campus, in a shopping mall). Access to the local hub and its APIs (e.g., registration and discovery) can be provided over a wireless network (e.g., Wi-Fi, etc.). The capabilities and available information of each registered WTRU can be provided to the local hub during registration and stored in the hub until they are deregistered or a specific registration expiration time has passed. The local hub can operate as an independent entity without any direct connection to the operator's core network, or it can be connected to the operator's network as a non-3GPP (e.g., Wi-Fi) network to extend various operator network services to the connected WTRUs.

[0089] Figure 4An exemplary scenario is shown for delivering traffic (e.g., packets) to a single user's distributed WTRU. In particular, there may be a delivery of MBS and non-MBS flows (e.g., data, packets, content, etc.) from one or more sources (e.g., 430) on a single PDU session (e.g., shared PDU session 420) for a distributed WTRU (e.g., a single user 410, including WTRU1, WTRU2, WTRU3, and / or WTRU4). The WTRU may be connected to various sources 430, such as a dedicated Application Function (AF). The AF may reside in one or more Delivery Networks (DNs), such as a local access DN, an edge DN, and / or a cloud DN. In one instance, the WTRU 410 may be connected via the network to other (not shown) WTRUs (e.g., specifically or in addition to the delivery network) for performing distributed functions. WTRUs that perform functions that require the same MBS traffic (e.g., two displays showing the same video - WTRU 3 and WTRU 4 as shown) may receive the same MBS flow, while other data (e.g., haptic data specific to a particular user and only required to be received by one WTRU - WTRU 1 and / or WTRU 2) may be delivered via unicast.

[0090] Figure 5 An exemplary method is shown for transferring MBS traffic and non-MBS traffic on the same PDU session for a distributed WTRU. For context, e.g., WTRU 2, WTRU 3, and WTRU 4 (as Figure 4 shown) may be sub-WTRUs that receive the same modality flow, WTRU 1 may receive a unicast flow, and these WTRUs may experience Figure 5 one or more aspects of the process. As described herein, a reference to receiving or sending a unicast or multicast flow may be implemented when sending its indication, or may be implemented in some other device for exchanging this information (e.g., within another message or as part of another message).

[0091] As Figure 5 shown, in this exemplary scenario, there may be a primary WTRU 521 that may initiate a process for distributing functions to other selected WTRUs (e.g., discovered WTRU 522) on a single PDU session. For illustration, it may be assumed that an MBS session has been configured in the 5GC, but alternative scenarios may exist and still be consistent with the techniques described herein. In this scenario, there may also be a discovery engine 523 (e.g., located on a single WTRU, multiple WTRUs, away from one of the WTRUs or as part of one of the WTRUs, etc.), the 5GC, and an AF / multicast source 525 for content / traffic / etc.

[0092] All WTRUs belonging to a user can receive at least MBS session ID information of the multicast groups of interest to which they can join, such as via a service announcement (e.g., MBS announcement 501). A WTRU that can be used to load the functions being distributed can register (e.g., 502) using a discovery engine 523 (e.g., in a local hub). The registration process can collect / gather and store the WTRU ID for each WTRU, which uniquely identifies the WTRU within a 5G Core (5GC) network 524. Along with the WTRU ID, each registered WTRU can provide device information to the discovery engine 523, such as its computing capabilities (e.g., CPU size, RAM size), networking (e.g., cellular status) capabilities, and / or location information (i.e., GPS coordinates).

[0093] A WTRU can register through an API provided by the discovery engine 523. The registration can be automatically performed by discovering nearby WTRUs. The ID of a WTRU can also be a service ID, or any other shareable ID that can be used to uniquely identify the WTRU or a service / function within it.

[0094] The master / originating WTRU 521 can send a request to query (e.g., 503) newly discovered / updated WTRUs 522 from the discovery engine 523. In the case where the discovery engine 523 resides within the same device, a callback or IPC (inter-processor communication) process can be used to obtain the information. The master WTRU 521 can have any required access permission in the discovery engine 523 (e.g., in a local hub) to obtain the information. Alternatively, the master WTRU 521 can automatically receive updates on newly discovered WTRUs.

[0095] The discovery engine 523 can respond (e.g., 504) to the master WTRU 521 using all the information collected, such as information on each registered WTRU. The master WTRU 521 can decide on the most suitable distribution of WTRU functions among the WTRUs (e.g., 505) (e.g., performing the role of a function manager). When making a function distribution decision (e.g., 505), it uses information collected from an analyzer, a user context engine, the discovery engine, and / or any other function to decide on one or more factors, such as what (e.g., which functions), when (e.g., the appropriate time), and / or where (e.g., the best WTRU) to offload functions. Alternatively, the selection of the most suitable distribution of WTRU functions can be performed by an entity within the network (e.g., an application function at the edge, a dedicated node within the network, etc.).

[0096] Once a distribution selection has been made and one or more WTRUs have been selected for distribution / offloading (e.g., based on one or more factors), the master WTRU 521 (e.g., the communication manager) may trigger the function distribution process by establishing a connection for the selected WTRUs. This may include initiating the creation and modification of a PDU session to be shared among all participating WTRUs by communicating with the 5G core network (e.g., 506).

[0097] As part of the session initiation, the master WTRU 521 may generate a session ID. The ID of the WTRUs being selected, along with the session ID, may be provided to the 5GC for creating a single session to be distributed among the selected WTRUs. The message may also contain information about the multicast session, where each individual may be a WTRU that needs to join (e.g., added as a vector / list / key-value pair). This may include one or more MBS session IDs or any other identifier for identifying MBS traffic, which indicates the multicast group that the WTRU wants to join, including the join request.

[0098] The process may deviate / modify the traditional MBS session establishment process. For example, the process may incorporate additional WTRU and flow information (e.g., such as the information described herein). In the case where the decision regarding the distribution of WTRU functions is performed by an entity in the network, the request may be executed by the corresponding entity (e.g., after a network-triggered PDU session initiation). A vector indicating whether each individual WTRU supports a single PDU session may be added to the message. In the case where a WTRU does not support single PDU session creation, a regular PDU session may be used for those subsets of the WTRU. In such a case, the 5GC 524 (e.g., the SMF) may maintain a list of all PDU IDs used and associated with the WTRU / user such that the decision-making entity has access to or has been given the information at some point in the process.

[0099] The 5GC 524 may authorize the establishment of a connection for the selected WTRUs (e.g., for the same user). The session management function (SMF) or the AMF in the initial phase of selecting the SMF may identify, discover, and / or select the MB-SMF for the corresponding MBS session for each individual WTRU in the provided list. If one or more WTRUs need to receive MBS traffic, the SMF may authorize an MBS session for the WTRUs belonging to the same user. If no suitable MB-SMF is configured, the SMF may perform the configuration or reject the request. The MB-SMF may accordingly select and / or configure the MB-UPF corresponding to each individual WTRU.

[0100] The 5GC 524 (e.g., AMF / SMF) can perform the selection of the corresponding SMF for the unicast flow (e.g., 507) and the selection of the MB-SMF for the multicast flow for each individual WTRU according to the provided MBS session information (e.g., as previously described in this exemplary process). To track the mapping between PDU sessions, unicast and / or multicast flows (e.g., MBS sessions and contexts) belonging to the same user, the 5GC 524 can store (e.g., 508) the mapping information (e.g., in the SMF, AMF, and / or RAN).

[0101] If it has been decided to use the shared delivery method for one or more WTRUs and if the resources for shared MBS traffic delivery have not been established, the 5GC can establish the required resources (e.g., shared tunnel) (e.g., 509). This can be performed separately for each MBS session. If it has been decided to use the unicast / individual delivery method for one or more WTRUs and if the resources for unicast / individual MBS traffic delivery have not been established, the 5GC can establish the resources required for unicast / individual delivery (e.g., 510). This can be performed separately for each MBS session.

[0102] For a WTRU using the unicast flow, the 5GC 524 can send (e.g., 511) a PDU session trigger message to all WTRUs (e.g., WTRU IDs). The 5GC 524 can use a triggering process (e.g., such as SMS) to perform this step. Alternatively, the SMF can send this trigger message to all corresponding WTRUs.

[0103] All WTRUs (e.g., 522) that receive the PDU session trigger request send (e.g., 512) a PDU session establishment request to the 5GC 524. The 5GC 524 can establish a PDU session (e.g., 513) with the provided WTRU (e.g., WTRU ID) using the same session ID. Thus, the corresponding WTRU can be added to the same PDU session. All selected / discovered WTRUs can be added to the same PDU session. The 5GC 524 can accept and establish (e.g., 514) a PDU session with the primary / originating WTRU 521.

[0104] The execution of distributed functions can be initiated / resumed (e.g., 515) by establishing communication between the corresponding functions. (e.g., between the primary WTRU 521 and one or more discovered WTRUs 522). This can include the transfer of function codes and other data used by the function (e.g., synchronization of data / status).

[0105] Transfer MBS traffic from a source (AF) to a corresponding WTRU (e.g., 516) via a 5G network. The 5GC can process the traffic according to the configurations described herein and can use the selected delivery method for each individual WTRU accordingly. For a WTRU that has selected conventional unicast delivery, the corresponding PDU / unicast stream can be used to deliver the content.

[0106] In some cases, for unicast, there can be a 1-1 mapping between an MBS session and a GTP-U tunnel towards a RAN node, and for multicast transmission, there can be a 1-1 mapping between the MBS session and the GTP-U tunnel. As described herein, in the case of a single PDU session combining both unicast and multicast flows, the flows within the PDU session can be delivered via both unicast and multicast GTP-U tunnels.

[0107] Figure 6 An exemplary method of transferring MBS traffic and non-MBS traffic on the same PDU session for a distributed WTRU is shown. For context, e.g., WTRU 2, WTRU 3, and WTRU 4 (as Figure 4 shown) can be sub-WTRUs that receive the same modality of flow, WTRU 1 can receive a unicast flow, and these WTRUs can go through Figure 5 one or more aspects of the process.

[0108] In this example scenario, there can be a master WTRU 621 that can initiate a process for distributing functionality to other selected WTRUs (e.g., discovered WTRU 622) on a single PDU session. For illustration, it can be assumed that an MBS session has been configured in the 5GC, but alternative scenarios can exist and still be consistent with the techniques described herein. In this scenario, there can also be a discovery engine 623 (e.g., located on a single WTRU, multiple WTRUs, away from one of the WTRUs, or as part of one of the WTRUs, etc.), the 5GC, and an AF / multicast source 625 of content / traffic / etc.

[0109] All WTRUs belonging to a user can receive at least MBS session ID information of the multicast groups of interest to which they can join, such as via a service announcement (e.g., MBS announcement 601). WTRUs that can be used as part of the same PDU session can be registered / discovered (e.g., 602) using a discovery engine 623 (e.g., in a local hub, in a primary WTRU, etc.). The registration process can collect / gather and store the WTRU ID for each WTRU, which uniquely identifies the WTRU within the 5G Core (5GC) network 624. Along with the WTRU ID, each registered WTRU can provide device information to the discovery engine 623, such as its computing capabilities (e.g., CPU size, RAM size), networking (e.g., cellular status) capabilities, and / or location information (i.e., GPS coordinates).

[0110] The WTRU can register through an API provided by the discovery engine 623. The registration can be automatically performed by discovering nearby WTRUs. The ID of the WTRU can also be a service ID, or any other shareable ID that can be used to uniquely identify the WTRU or a service / function within it.

[0111] The primary / originating WTRU 621 can send a request to query (e.g., 603) newly discovered / updated WTRUs 622 from the discovery engine 623. In the case where the discovery engine 623 resides within the same device, a callback or IPC (inter-processor communication) process can be used to obtain this information. The primary WTRU 621 can have any required access permission in the discovery engine 623 (e.g., in a local hub) to obtain this information. Alternatively, the primary WTRU 621 can automatically receive updates on newly discovered WTRUs.

[0112] The discovery engine 623 can respond (e.g., 604) to the primary WTRU 621 using all the information collected, such as information on each registered WTRU. The primary WTRU 621 can decide on the configuration of a single PDU session (e.g., 605) for all involved WTRUs. This decision can use information collected from an analyzer, a user context engine, the discovery engine, and / or any other function to determine one or more factors, such as what (e.g., which functions), when (e.g., the appropriate time), and / or where (e.g., the best WTRU), for the purpose of a single PDU session with multiple WTRUs. Alternatively, this decision can be performed by an entity within the network (e.g., an application function at the edge, a dedicated node within the network, etc.).

[0113] Once a decision has been made and one or more WTRUs have been selected (e.g., based on one or more factors), the master WTRU 621 (e.g., the communication manager) may trigger a process by establishing a connection for the selected WTRUs. This may include initiating the creation and modification of a PDU session to be shared among all participating WTRUs by communicating with the 5G core network (e.g., 606).

[0114] As part of the session initiation, the master WTRU 621 may generate a session ID or receive a session ID from an application / service provider. The ID of the WTRU being selected, along with the session ID, may be provided to the 5GC for creating a single session to be distributed among the selected WTRUs. The message may also contain information about the multicast session, with each individual being a WTRU that needs to join (e.g., added as a vector / list / key-value pair). This may include one or more MBS session IDs or any other identifier for identifying MBS traffic, which indicates the multicast group that the WTRU wants to join, including the join request.

[0115] The process may deviate / modify the traditional MBS session establishment process. For example, the process may incorporate additional WTRU and flow information (e.g., such as the information described herein). In cases where the decision regarding the distribution of WTRU functions is performed by an entity in the network, the request may be executed by the corresponding entity (e.g., after a network-triggered PDU session initiation). A vector indicating whether each individual WTRU supports a single PDU session may be added to the message. In cases where a WTRU does not support single PDU session creation, a regular PDU session may be used for those subsets of the WTRU. In such cases, the 5GC 624 (e.g., the SMF) may maintain a list of all PDU IDs used and associated with the WTRU / user such that the decision-making entity has access rights or has been given the information at some point in the process.

[0116] The 5GC 624 may authorize the establishment of a connection for the selected WTRUs (e.g., for the same user). The session management function (SMF) or the AMF in the initial stage of selecting the SMF may identify, discover, and / or select the MB-SMF for the corresponding MBS session for each individual WTRU in the provided list. If one or more WTRUs need to receive MBS traffic, the SMF may authorize an MBS session for the WTRUs belonging to the same user. If no suitable MB-SMF is configured, the SMF may perform the configuration or reject the request. The MB-SMF may accordingly select and / or configure the MB-UPF corresponding to each individual WTRU.

[0117] The 5GC 624 (e.g., AMF / SMF) may perform the selection of the corresponding SMF for the unicast flow (e.g., 607) and the selection of the MB-SMF for the multicast flow for each individual WTRU based on the provided MBS session information (e.g., as previously described in this exemplary process). To track the mapping between PDU sessions, unicast and / or multicast flows (e.g., MBS sessions and contexts) belonging to the same user, the 5GC 624 may store (e.g., 608) the mapping information (e.g., in the SMF, AMF, and / or RAN).

[0118] If it has been decided to use the shared delivery method for one or more WTRUs and if the resources for shared MBS traffic delivery have not been established, the 5GC may establish the required resources (e.g., shared tunnel) (e.g., 609). This may be performed separately for each MBS session. If it has been decided to use the unicast / individual delivery method for one or more WTRUs and if the resources for unicast / individual MBS traffic delivery have not been established, the 5GC may establish the resources required for unicast / individual delivery (e.g., 610). This may be performed separately for each MBS session.

[0119] For a WTRU using a unicast flow, the 5GC 624 may send (e.g., 611) a PDU session trigger message to all WTRUs (e.g., WTRU IDs). The 5GC 624 may use a triggering procedure (e.g., such as SMS) to perform this step. Alternatively, the SMF may send the trigger message to all corresponding WTRUs.

[0120] All WTRUs (e.g., 622) that receive the PDU session trigger request send (e.g., 612) a PDU session establishment request to the 5GC 624. The 5GC 624 may establish a PDU session (e.g., 613) with the provided WTRU (e.g., WTRU ID) using the same session ID. Thus, the corresponding WTRU may be added to the same PDU session. All selected / discovered WTRUs may be added to the same PDU session. The 5GC 624 may accept and establish (e.g., 614) a PDU session with the primary / originating WTRU 621.

[0121] The execution of the selection of the discovered WTRUs may be initiated / continued by establishing communication between the other WTRUs and the discovery entity (e.g., 615). (e.g., between the primary WTRU 621 and one or more discovered WTRUs 622). This may include the transfer of information, establishment of connections (e.g., directly or indirectly), tunneling, synchronization of data / status, etc.

[0122] Transfer MBS traffic from a source (AF) to a corresponding WTRU (e.g., 616) via a 5G network. The 5GC may process the traffic according to the configurations described herein and may use the selected delivery method for each individual WTRU accordingly. For a WTRU that has selected conventional unicast delivery, the corresponding PDU / unicast flow may be used to deliver the content.

[0123] In some cases, for unicast, there may be a 1-1 mapping between the MBS session and the GTP-U tunnel towards the RAN node, and for multicast transmission, there may be a 1-1 mapping between the MBS session and the GTP-U tunnel. As described herein, in the case of a single PDU session combining both unicast and multicast flows, the flows within the PDU session may be delivered via both unicast and multicast GTP-U tunnels.

[0124] In another example, there may be a method implemented by a primary wireless transmit / receive unit (WTRU) for using one PDU session with multiple WTRUs. The primary WTRU may send a PDU session establishment request to establish a single shared PDU session for the primary WTRU and one or more other WTRUs. The PDU establishment request may include at least one multicast flow and at least one unicast flow for the single shared PDU session. The primary WTRU may receive a PDU session establishment response that establishes a single shared PDU session with one or more other WTRUs. The primary WTRU may receive information about one or more other WTRUs from a discovery function. The discovery function may be part of the network or part of the primary WTRU. The primary WTRU may receive information for multiple WTRUs and may select one or more other WTRUs from the multiple WTRUs based on the information. The primary WTRU may receive data from one or more delivery networks, where the delivery network is an edge, cloud, or local access source of the data. One or more other WTRUs and the primary WTRU may have a common PDU session ID. In some instances, the multi-broadcast announcement is before the PDU session establishment request. All WTRUs may share common elements such as an ID, user, session ID, or some other identifier. As described herein, the components of the network may receive the request, process / implement the request, and respond in relation to one or more of the WTRUs involved and the communication with the delivery network.

[0125] As described herein, a higher layer can refer to one or more layers in a protocol stack, or a specific sub - layer within a protocol stack. The protocol stack can include one or more layers in a WTRU or a network node (e.g., eNB, gNB, other functional entities, etc.), where each layer can have one or more sub - layers. Each layer / sublayer can be responsible for one or more functions. Each layer / sublayer can communicate directly or indirectly with one or more of the other layers / sublayers. In some cases, the layers can be numbered, such as layer 1, layer 2, and layer 3. For example, layer 3 can include one or more of the following: non - access stratum (NAS), Internet Protocol (IP), and / or radio resource control (RRC). For example, layer 2 includes one or more of the following: packet data convergence protocol (PDCP), radio link control (RLC), and / or media access control (MAC). For example, layer 3 can include physical (PHY) layer - type operations. The higher the layer number, the higher the layer is relative to other layers (e.g., layer 3 is higher than layer 1). In some cases, the foregoing examples can be referred to as the layer / sublayer itself, regardless of the layer number, and can be referred to as the higher layer as described herein. For example, from highest to lowest, the higher layer can refer to one or more of the following layer / sublayers: NAS layer, RRC layer, PDCP layer, RLC layer, MAC layer, and / or PHY layer. Any reference herein to a higher layer in connection with a process, device, or system will refer to the layer above the layer of that process, device, or system. In some cases, a reference herein to a higher layer can refer to a function or operation performed by one or more of the layers described herein. In some cases, a reference herein to a higher layer can refer to information sent or received by one or more of the layers described herein. In some cases, a reference herein to a higher layer can refer to a configuration sent and / or received by one or more of the layers described herein.

[0126] Although the features and elements are described above in specific combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein can be implemented in a computer program, software, or firmware combined with a computer - readable medium for execution by a computer or a 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, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto - optical media, and optical media (such as CD - ROM disks and digital versatile disks (DVD)). A processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented by a master wireless transmit / receive unit (WTRU), the method comprising: Sending a PDU session establishment request to establish a single shared PDU session for the master WTRU and one or more other WTRUs, wherein the PDU establishment request includes at least one indication of a multicast flow and at least one indication of a unicast flow, wherein the indicated multicast flow and the indicated unicast flow are associated with the single shared PDU session; And Receiving a PDU session establishment response that establishes the single shared PDU session with the one or more other WTRUs.

2. The method according to claim 1, the method further comprising receiving an indication of the one or more other WTRUs from a discovery function.

3. The method according to claim 1, the method further comprising receiving information for a plurality of WTRUs and selecting the one or more other WTRUs from the plurality of WTRUs based on the information.

4. The method according to claim 1, the method further comprising receiving data from one or more delivery networks, wherein the delivery network is an edge system, a cloud system, or a local access system source of the data.

5. The method according to claim 1, wherein the one or more other WTRUs and the master WTRU have a common PDU session ID.

6. The method according to claim 1, wherein the multi-broadcast announcement is before the PDU session establishment request.

7. A master wireless transmit / receive unit (WTRU), the master WTRU comprising: A processor operatively coupled to a transceiver, the processor and the transceiver being configured to send a PDU session establishment request to establish a single shared PDU session for the master WTRU and one or more other WTRUs, wherein the PDU establishment request includes at least one indication of a multicast flow and at least one indication of a unicast flow, wherein the indicated multicast flow and the indicated unicast flow are associated with the single shared PDU session; And The processor and the transceiver, the processor and the transceiver being configured to receive a PDU session establishment response that establishes the single shared PDU session with the one or more other WTRUs.

8. The master WTRU according to claim 7, wherein the processor and the transceiver are further configured to receive an indication of the one or more other WTRUs from a discovery function.

9. The master WTRU according to claim 7, wherein the processor and the transceiver are further configured to receive information for a plurality of WTRUs and select the one or more other WTRUs from the plurality of WTRUs based on the information.

10. The master WTRU according to claim 7, wherein the processor and the transceiver are further configured to receive data from one or more delivery networks, wherein the delivery network is an edge system, a cloud system, or a local access system source of the data.

11. The master WTRU according to claim 7, wherein the one or more other WTRUs and the master WTRU have a common PDU session ID.

12. The primary WTRU according to claim 7, wherein the multi-broadcast announcement is before the PDU session establishment request.

Images