Method, architecture, apparatus and system for multi-modal communication including multiple user equipments

Abstract

Processes, methods, architectures, apparatuses, systems, devices, and computer program products are described for multi-modal communication including a plurality of user devices. The network node receives a first request for a first set of network slices requested by a first wireless transmit / receive unit, WTRU, the first request being associated with a service identifier, receives a second request for a second set of network slices requested by a second WTRU, the second request being associated with a service identifier, and transmits the second request to the second WTRU. Wherein the first and second sets of network slices collectively comprise at least two different types of network slices, determining a set of instances corresponding to the requested network slice, and transmitting information indicating instances of network slices corresponding to the first and second sets of network slices, respectively, to at least one further network node.

Description

Background Art

[0001] The present disclosure generally relates to the fields of communications, software, and coding, including, for example, methods, architectures, apparatuses, and systems related to multimodal communications involving multiple user devices. Summary of the invention

[0002] In a first aspect, the present principles are directed to a method performed by a network node, which receives a first request for a first set of network slices requested by a first wireless transmit / receive unit WTRU, the first request being associated with a service identifier, receives a second request for a second set of network slices requested by a second WTRU, the second request being associated with a service identifier, wherein the first and second sets of network slices together include at least two different types of network slices, determines a set of instances corresponding to the requested network slices, and transmits information indicating instances of network slices corresponding to the first and second sets of network slices, respectively, to at least one further network node.

[0003] In a second aspect, the present principles are directed to a network node comprising a memory storing processor-executable program instructions and at least one hardware processor configured to execute the program instructions to receive a first request for a first set of network slices requested by a first wireless transmit / receive unit WTRU, the first request being associated with a service identifier, receive a second request for a second set of network slices requested by a second WTRU, the second request being associated with a service identifier, wherein the first and second sets of network slices together include at least two different types of network slices, determine a set of instances corresponding to the requested network slices, and transmit information indicating instances of network slices corresponding to the first and second sets of network slices, respectively, to at least one further network node.

[0004] In a third aspect, the present principles are directed to a wireless transmit / receive unit WTRU comprising a memory storing processor-executable program instructions and at least one hardware processor, wherein the at least one hardware processor is configured to execute the program instructions to transmit a first request for a first set of network slices to a network node, the first request being associated with a service identifier further known to a second WTRU, wherein the first set of network slices comprises at least two different types of network slices, and to receive information indicating an instance of a slice corresponding to the first set of network slices. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be obtained through the following detailed description given by way of example in conjunction with the accompanying drawings. Like the detailed description, the figures in these drawings are examples. Likewise, the accompanying drawings (figures) and detailed description should not be considered limiting, and other equally effective examples are possible and may occur. In addition, the same reference numerals ("reference numerals") in the figures represent the same elements, wherein:

[0006] Figure 1A is a system diagram illustrating an example communication system;

[0007] Figure 1B It shows that it can be Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the communication system is shown;

[0008] Figure 1C It shows that it can be Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the illustrated communication system;

[0009] Figure 1D It shows that it can be Figure 1A A system diagram of another example RAN and another example CN used within the illustrated communication system;

[0010] Figure 2 An example use case for augmented robotic telepresence is shown;

[0011] Figure 3A and 3B Two embodiments for signaling a multimodal service ID according to the present principles are shown;

[0012] Figure 4 is a message flow diagram illustrating signaling of a multimodal service ID according to one embodiment;

[0013] Figure 5 Figures 5A-5D , is an example sequential flow chart illustrating a method for coordinating network slices for composite E2E multimodal services according to an embodiment;

[0014] Figure 6 Shown for Figure 2 An example of UE slice multimodal coordination for an example use case of enhanced robotic telepresence as shown; and

[0015] Figure 7 is a sequence diagram showing the message flow in a network involved in a composite E2E multimodal service according to an embodiment. DETAILED DESCRIPTION

[0016] In the following detailed description, many specific details are set forth to provide a comprehensive understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be implemented without some or all of the specific details set forth herein. In other cases, well-known methods, processes, components and circuits have not yet been described in detail to avoid blurring the following description. In addition, the embodiments and examples not specifically described herein may be implemented in place of or in conjunction with the embodiments and other examples explicitly, implicitly and / or inherently described, disclosed or otherwise provided (collectively referred to as "providing") herein. Although various embodiments are described and / or claimed herein, wherein devices, systems, equipment, etc. and / or any of their elements perform operations, processes, algorithms, functions, etc. and / or any part thereof, it should be understood that any embodiments described and / or claimed herein assume that any device, system, equipment, etc. and / or any of its elements are configured to perform any operations, processes, algorithms, functions, etc. and / or any part thereof.

[0017] Example Communication System

[0018] The methods, devices, and systems provided herein are well suited for communications involving both wired and wireless networks. Figures 1A-1D An overview of various types of wireless devices and infrastructure is provided in which various elements of the network can utilize, perform, be arranged according to and / or adapted for the methods, apparatuses, and systems provided herein and / or be configured for the methods, apparatuses, and systems provided herein.

[0019] Figure 1A 1 is a system diagram illustrating an example 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 such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such 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 (ZT) unique word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-sOFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0020] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, 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 of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include (or be) a 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), a consumer electronic device, a device 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.

[0021] 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 interface with at least one of the WTRUs 102a, 102b, 102c, 102d, for example, to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be any one of a base transceiver station (BTS), a Node B (NB), an eNode-B (eNB), a Home Node B (HNB), a Home eNode-B (HeNB), a gNode-B (gNB), a NR Node B (NR NB), a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0022] 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 transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may also be divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology, and may utilize multiple transceivers for each or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0023] 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).

[0024] 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).

[0025] In one 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-APro).

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

[0027] 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 together implement LTE radio access and NR radio access, for example using dual connectivity (DC) principles. Thus, the air interface utilized 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).

[0028] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), 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.

[0029] For example, 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, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. 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 one 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-APro, NR, etc.) to establish any one of a small cell, a pico cell, or a femto cell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not be required to access Internet 110 via CN 106 / 115.

[0030] 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, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calls, Internet connectivity, video distribution, etc. and / or perform high-level security functions, such as user authentication. Although in Figure 1A Although not shown, it will be appreciated that the RAN 104 / 113 and / or the 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 utilize an NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs any of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

[0031] 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 / 114 or a different RAT.

[0032] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-modal 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.

[0033] Figure 1B is a system diagram illustrating an example 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 keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other elements / 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.

[0034] 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 is understood that the processor 118 and the transceiver 120 may be integrated together, such as in an electronic package or chip.

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

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

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

[0038] 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 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 from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0040] 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.

[0041] The processor 118 may also be coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, the components / peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (e.g., for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, frequency modulation (FM) radio unit, digital music player, media player, electronic game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Component / peripheral 138 may include one or more sensors, which may be gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographic location sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0042] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes 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 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 one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0043] 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, and 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0044] 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 receive wireless signals from, the WTRU 102a.

[0045] Each of the eNode-Bs 160a, 160b, and 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, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0046] 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 (PGW) 166. Although each of the foregoing elements is described as being 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.

[0047] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c 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 during an initial attach of the WTRUs 102a, 102b, 102c, etc. 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.

[0048] 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 / 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 DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0049] 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.

[0050] 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 communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 owned and / or operated by other service providers.

[0051] Although the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use (eg, temporarily or permanently) a wired communications interface with a communications network.

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

[0053] 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 distributed system (DS) or another type of wired / wireless network that transmits traffic to and / or out of the BSS. Traffic originating from outside the BSS to a STA may be reached by the AP and may be delivered to the STA. Traffic from a STA to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. For example, traffic between STAs within a BSS may be sent by the AP, where the source STA may send traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between source and destination STAs (e.g., directly between them) using direct link establishment (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.

[0054] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP can transmit a beacon on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a wide bandwidth of 20 MHz) or a width dynamically set by 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 sense the primary channel. If a particular STA senses / 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.

[0055] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, formed via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0056] 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 by combining two discontinuous 80MHz channels, which can be called an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser, 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 transmitted 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 a media access control (MAC) layer, an entity, etc.

[0057] 802.11af and 802.11ah support sub-1GHz operating modes. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah 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, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support metering type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, for example, limited capabilities, 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., in order to maintain very long battery life).

[0058] WLAN systems (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) that can support multiple channels and channel bandwidths include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating 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 primary channel may be 1MHz wide, 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 transmitting to the AP, for example, due to a STA (supporting only the 1MHz operating mode), the entire available band may be considered busy, even if most of the band remains idle and may be available.

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

[0060] 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.

[0061] The RAN 113 may include gNBs 180a, 180b, 180c, but it should be understood that the RAN 113 may include any number of gNBs while remaining consistent with the embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via 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 WTRUs 102a, 102b, 102c. 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 one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

[0062] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different 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., including a variable number of OFDM symbols and / or lasting a variable length of absolute time).

[0063] 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., such as the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize 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 such as an 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 act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for the serving WTRU 102a, 102b, 102c.

[0064] 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 UL and / or 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, gNB180a, 180b, and 180c can communicate with each other through the Xn interface.

[0065] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and at least one data network (DN) 185a, 185b. Although each of the foregoing elements is described as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0066] 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 protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing, for example, 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 that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-APro, and / or non-3GPP access technologies such as Wi-Fi.

[0067] 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 services 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.

[0068] 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, such as the Internet 110, for example, 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.

[0069] 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 acts 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 one 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.

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

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

[0072] One or more simulation devices can perform one or more functions, 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 in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas).

[0073] introduce

[0074] Tactile and Multimodal Communication (TACMM)

[0075] Haptic and multimodal communication services enable multimodal interactions, typically combining ultra-low latency with extremely high throughput, availability, and reliability. It can be applied in multiple areas such as remote human interaction, remote surgery, robot-to-robot interaction, industrial and commercial IoT services, extended reality (XR), and media services or applications. For haptic and multimodal communication services, which can be provided on a single network slice or multiple slices with different QoS requirements, the modality can be video / audio data, sensor data, and / or tactile data. Multimodal data includes input data from different kinds of devices or sensors, or output data to different kinds of destinations required for the same task, service, or application. Therefore, multimodal output is generated based on input from multiple sources that may be located within a single device or multiple devices.

[0076] Network Slicing

[0077] Network slicing implements multiple logical networks on top of a shared physical network infrastructure (including radio, core, and transport infrastructure). Network slicing enables the physical network infrastructure to be divided into separate end-to-end (E2E) instances / slices, each of which is independent and has its own service requirements and characteristics [see, for example, 3GPP TR23.640 "Network Slicing Enhancement Study (Release 16)"]. A UE can use different network slices (up to 8) with different QoS requirements simultaneously. These independent E2E slices can provide, for example, (i) high-throughput services via eMBB slices; (ii) delay and reliability-related services via URLLC slices. Therefore, network slicing enables flexible utilization of network infrastructure and resources according to network slicing requirements / characteristics.

[0078] Quality of Service (QoS)

[0079] The 5G QoS model is based on QoS flows. QoS flows are the finest granularity for QoS differentiation in a PDU session. A QoS flow may or may not require a guaranteed bit rate, which is defined in the corresponding QoS flow profile, which can be GBR or non-GBR, respectively. Within a PDU session, a QoS flow is identified by a QoS flow ID (QFI). In addition, the 5G QoS model supports reflective QoS, which enables the UE to derive UL QoS rules from downlink packets instead of having explicit signaling for UL QoS rules. Within the 5GS, QoS flows are controlled by the SMF and can be pre-configured or established via the PDU session establishment or session modification process.

[0080] The QoS flow is characterized by: a QoS flow profile (provided by the SMF to the AN via the AMF); one or more QoS rules and optional QoS flow-level QoS parameters, such as 5G QoS identifier (5QI), allocation and retention priority (ARP), guaranteed flow bit rate / maximum flow bit rate / maximum packet loss rate for UL and DL (which can be provided by the SMF to the UE via the AMF, or derived by the UE applying reflective QoS); and one or more UL and DL packet detection rules (PDR) (provided by the SMF to the UPF).

[0081] Quality of Experience (QoE)

[0082] QoE is a measure of both the subjective and objective user experience of a service or application. It covers both network-related / QoS measurements (such as throughput, latency) and application / service-related measurements (such as responsiveness, end-user device capabilities, application / service content, user actions / interactions). For example, for VR services, in addition to traditional QoS measurements, video resolution / codec, camera motion, user perspective, etc. are also considered for some QoE measurements.

[0083] 5G QoE measurement is an application layer measurement that is configured by operations, administration and maintenance (OAM) for different service types, such as streaming, VR, XR, multimedia broadcast and multicast services (MBMS). It includes (i) radio-related measurements (e.g., MDT procedures) to help the network evaluate and improve QoE; (ii) radio-related information, such as mobility history or dual-connectivity status; and (iii) per-slice measurements. As mentioned above, QoE measurements are configured by OAM, but can be triggered by the CN (called a signaling-based procedure) or by OAM (called a management-based procedure). The RAN may not understand or utilize all QoE metrics. However, there may be a subset of QoE measurements that the RAN can utilize, such as, for example, buffer levels. This subset of metrics is called RAN-visible QoE metrics and has been discussed in 3GPP Rel-17. In addition, the maximum number of simultaneous QoE measurement configurations for a UE is still under discussion in 3GPP. Currently, the configuration of QoE measurements between the UE and the RAN (in RRC_CONNECTED) is agreed to be identified by an RRC identifier, called MeasConfigAppLayerId [see 3GPP TS 38.890 "Study on NR QoE (Quality of Experience) Management and Optimization for Diverse Services (Release 17)" and RP-2116761 "Status reporting of WI on NRQoE Management and Optimization for Diverse Services"].

[0084] Network Data Analysis Function (NWDAF)

[0085] NWDAF is used for data collection and data analysis in the network. Certain analyses can be performed independently by 5GS network functions (NFs), and NWDAF instances specific to that analysis can be collocated with 5GS NFs. The data used by 5GS NFs as input to the analysis can also be used to allow for centralized NWDAF deployment options. 5GS network functions and OAM decide how to use the data analysis provided by NWDAF to improve network performance.

[0086] NWDAF uses the existing service-based interfaces to communicate with other 5GC network functions and OAM. 5GC NF can use the service-based interfaces to expose the results of data analysis to any consumer NF [see 3GPP TR 23.700-91 "Study on enablers for network automation for 5G System (5GS); Stage 2 (Release 17)"].

[0087] AI / ML Model Transfer (AMMT)

[0088] The use cases and potential performance requirements supported by 5G systems for artificial intelligence (AI) / machine learning (ML) model distribution and transfer (download, upload, update, etc.) are studied in 3GPP as the AI / ML Model Transfer (AMMT) study item [see 3GPP TR22.864 “Study on service characteristics and performance requirements for AI / ML model transfer in 5GS (Release 18)]. This study item also identifies the service characteristics of AI / ML model distribution, transfer and training for various applications, such as video / speech recognition, robotic control, automotive and other verticals. Aspects related to the partitioning of AI / ML operations between AI / ML endpoints, AI / ML model / data distribution and sharing on 5G systems, and distributed / federated learning on 5G systems are addressed.

[0089] AI / ML operations / models are divided into multiple parts according to the current task and environment. The purpose is to offload the computation-intensive and energy-intensive parts to the network endpoints, while leaving the privacy-sensitive and latency-sensitive parts on the end devices.

[0090] Multifunctional mobile terminals may need to switch AI / ML models in response to task and environment changes. The condition for adaptive model selection is that the model to be selected is available for the mobile device and the model is selected based on device constraints / capabilities.

[0091] In distributed / federated learning, the cloud server trains a global model by aggregating local models partially trained by each terminal device. In each training iteration, the UE performs training based on the model downloaded from the AI ​​server using local training data. The UE then reports the interim training results to the cloud server via the 5G UL channel. The server aggregates the interim training results from the UE and updates the global model. The updated global model is then distributed to the UE, and the UE can perform training for the next iteration.

[0092] Multimodal input can be provided by a single device (UE with different sensors) or multiple devices (such as a first device for integrated and external cameras and microphones for video and audio data, a second device for environmental sensing, and a third device for tactile information). Multimodal service input is actually transmitted from one or more application servers to one or more UEs and vice versa at the same time to achieve integrated processing. Even relatively small time differences may degrade the performance and experience of tactile and multimodal communication services.

[0093] Since multimodal inputs can be provided by different devices in a multimodal service, the input data from these multiple sources may have different characteristics or QoS / QoE requirements, such as sampling rate / transmission frequency, latency, image / video resolution, throughput, and reliability. Figure 2 In the illustrated augmented robotic telepresence use case, a human operator may control a robot 220 or other machine to perform a remote operation. In such a use case, (i) the robot 220 may provide video, audio, tactile data, and LIDAR data, (ii) another device 230 such as a camera or any sensor may provide additional information about the environment to enhance the remote operator's perception of the real environment, and (iii) the operator interacts with a control device 210 that sends control signals to the robot and camera to perform the operation. These signals may be sent via a network 240 (e.g., a 5G network). Depending on the scenario considered, these devices may exist behind a gateway and / or have on-device AI capabilities, which may require another set of control signals from the remote operator to / from the robot and surrounding sensing devices to the remote operator.

[0094] In this enhanced robotic telepresence, the transmission of typically bandwidth-hungry sensing data from the robot and ambient sensing devices to the teleoperator station and typically low-latency data in the opposite direction represents multimodal communication. Such transmission should take into account the different QoS / QoE requirements of each traffic flow / application between the robot and the teleoperator and between the ambient sensing devices and the teleoperator. Figure 2As shown, for the robot 220, two eMBB slices (a first 222A for video streaming and a second 222B for LIDAR sensor) and four URLLC slices (a first 224A for tactile streaming, a second 224B for audio streaming, a third 224C for AI-related control signals, and a fourth 224D for robot control) are considered simultaneously. For another device 230, which is a camera in this example, one eMBB slice 232 (for video streaming) and two URLLC slices (one 234A for controlling camera zoom and tilt, and another 234B for AI-related control signals) are considered.

[0095] As mentioned in the given augmented robotic telepresence use case, multimodal input can be provided by a single device or multiple devices. Meeting the QoS / QoE requirements of one device and one slice does not necessarily mean meeting the QoE requirements of the composite E2E multimodal service. Therefore, to support composite E2E tactile and multimodal communication services, multimodal service flows from different UEs should be identified and parallel transmission of different multimodal service flows should be coordinated.

[0096] In order to use Figure 2 To clarify this using the use cases shown in , (i) eMBB slices and URLLC slices from the same UE (robot or external camera) will need to be identified and coordinated (eMBB <-> URLLC), and (ii) eMBB and URLLC slices from different UEs (robot and external camera) will need to be identified and coordinated (eMBB <-> eMBB; eMBB <-> URLLC; URLLC <-> URLLC).

[0097] Currently, 3GPP systems guarantee dedicated performance, such as E2E latency or throughput, for only a single UE. Network slice selection is static, where the same network slice is always selected for a given application or service assuming that one UE completes the task. Although a UE can use different network slices (up to 8) with different QoS requirements simultaneously, the assumption that one UE completes the task still exists. Therefore, supporting the simultaneous use of multiple network slices and QoE measurements for each slice for a single UE is not sufficient to establish a coordination / collaboration mechanism between multiple UE devices for multimodal services and their QoE requirements. Therefore, it should be understood that for current 3GPP systems, it is difficult to support the collaboration of multiple UE devices that utilize various network slices to perform tasks. In addition, having on-device AI capabilities also requires coordination between multiple UE devices to determine whether to consider the output / model parameter update of this specific AI model for composite multimodal services.

[0098] Overview

[0099] This principle considers a scenario in which multiple UEs (such as reference Figure 2 As described, each UE may include multiple parts (e.g., camera, microphone, etc.) that may collaborate to perform multimodal services, where the UE may use multiple network slices simultaneously (e.g., in parallel), and where a network slice may be used by a single UE, or across more than one UE that communicate directly or indirectly (e.g., via a gateway). Therefore, the slices may require different QoS / QoE requirements. Therefore, the network slices involved are grouped to form a collection, with the goal of being able to guarantee the QoE requirements of a composite E2E multimodal service. Here, the grouping is considered to be an identification of a multimodal service and related service flows and / or PDU sessions.

[0100] Since the performance of multimodal services depends on the performance of multiple UE devices and associated network slices, there are dependencies between different network slices and within a single network slice (such as URLLC or eMBB slice) used by different UE devices. Although the current 3GPP system can map multiple sessions to one slice / service type (SST) and use a slice distinguisher (SD) to customize the QoS of each session, there may be interdependencies. For example, different sessions of the same UE can be interdependent, for example, an action on one session can depend on another session. As another example, different sessions involving different UE devices directly or via a gateway can be interdependent, for example, an action on one UE can depend on an action from (multiple) another UE device located behind the gateway. These dependencies are not addressed in the current 3GPP specifications. In addition, in the case where the device has AI capabilities, there is currently no mechanism to coordinate the input / output of the AI ​​model adopted on different UE devices contributing to the same E2E multimodal service. The present principle provides network slice selection function (NSSF)-based and application function (AF)-based coordination between multiple UE devices. NSSF-based and AF-based solutions use multimodal service identification information to coordinate multiple UE devices and associated slices to jointly meet the QoE requirements of composite E2E multimodal services.

[0101] Multimodal service identification

[0102] As described in 3GPP TS23.501 "System Architecture Phase 2 (Release 17) of the 5G System (5GS)", 5GS supports network slicing. A network slice is identified by an S-NSSAI, which includes an SST and a SD, where the SD in the S-NSSAI is optional. A set of one or more S-NSSAIs is called an NSSAI. During the UE registration process, the UE notifies the AMF about its requested NSSAI, which is defined by a list of requested NSSAIs with associated SSTs and SDs. The requested S-NSSAI can be used by different applications that require different QoS profiles. As described in 3GPP TS23.501, applications and corresponding application-specific services can be identified by a combination of a DNN and an optional S-NSSAI or AF service identifier. In addition, a subscription permanent identifier (SUPI) / globally unique temporary identifier (GUTI) / general public subscription identifier (GPSI) can be applied to identify a single UE, or an external group identifier can be applied to identify a group of UEs. Since more than one application can be used by a single UE or multiple UEs for the same multimodal service, the currently available identifiers for applications, application-specific services, network slices and / or UE / UE groups are insufficient to identify the multimodal service and the corresponding network slice / PDU session and UE.

[0103] Therefore, in one embodiment, a new identifier named "Multimodal Service ID" (MMID) is used to identify the network slices and UEs involved in a composite E2E multimodal service. Because (i) not all applications available / running in a UE are necessarily part of the same multimodal service; (ii) applications available / running in a UE can be part of different multimodal services; and (iii) different network slice instances can have slice-specific PDU sessions using the same DNN, during the UE registration process, the UE can (preferably should) include the "Multimodal Service ID" for each S-NSSAI in the requested NSSAI.

[0104] In another embodiment, "composite slices", "super slices" or "hyper slices" (to be used hereinafter) are proposed to stitch, connect or group already defined slice types (e.g., eMBB, URLLC and V2X) according to multimodal service requirements. This "hyper slice" can be defined as a fixed slice, but it can also be dynamically constructed based on multimodal service QoE monitoring. In cases where slice isolation is not a requirement or the slices to be stitched are not mutually exclusive, the newly generated network slice can be used. As an example, the operator can use the same slice distinguisher (SD) or any other indicator (e.g., NSSF) that the system can use to configure the network slices that are allowed to be stitched to determine whether the network slice can be part of a super / super slice.

[0105] A "super slice" may be explicitly requested by the UE, for example using a combined identifier which may be generated, for example, by ORing the SSTs of the defined slices and using the result as a mask to obtain the relevant slices at the AMF or NSSF.

[0106] For example, the UE may generate a slice mask representing the SST under consideration, and the network may utilize the generated slice mask to understand whether the slice type is part of a super slice.

[0107] Alternatively, the network may derive a "super-slice" by combining multiple network slices based on network analysis, as will be described with reference to embodiments with AI on the network / remote operator side.

[0108] like Figure 3A and 3B As shown, the multimodal service ID MMID of each S-NSSAI may be included in a variety of ways.

[0109] Figure 3A A first way of including an additional identifier of a (SST, SD) tuple is shown, such as (SST, SD, MMID), where MMID stands for "Multimodal Service ID". In one example, SST is 8 bits, SD is 24 bits, and MMID is n bits. Different multimodal services may have a predefined field for MMID, as it is already used for SST and SD.

[0110] Figure 3B A second approach is shown, where a portion of the SD field is reserved to indicate the MMID, which is similar to the recommendation given in 3GPP TR23.640 for the slice group ID. This can be interpreted as (SST, [SD, MMID]). As can be seen, SST is 8 bits, MMID is n bits, and SD is 24-n bits.

[0111] A "super slice" can be identified by a reserved SD field, where each multimodal service has a single SD identifier. Based on a specific SD identifier, different SSTs are stitched to a multimodal service. For example, the requested eMBB and URLLC slices will have the same SD identifier, such as for eMBB (SST=eMBB, SD=X) and for URLLC (SST=URLLC, SD=X), where X is a designated SD field used to stitch different slices to a multimodal service.

[0112] In case the application available / running in the UE is part of multiple multimodal services, e.g., where the camera streaming from the UE is used for object detection in one multimodal service and for positioning in another multimodal service, the "Multimodal Service IDs" may include a list of multimodal services.

[0113] Figure 4 The message flow for signaling the proposed "Multimodal Service ID" information in the network is shown.

[0114] In step S402, UE 42 sends a registration request message to access management node 44 (e.g., AMF) via access network 43 to indicate that the S-NSSAI in the requested NSSAI is part of a specific multimode service / specific multimode service set or part of a "super slice". For illustration purposes, step S402 is shown as three different steps, steps S402a-S402c, one step for each of the following embodiments.

[0115] In the first embodiment, in step S402a, the MMID is included as an additional identifier.

[0116] In the second embodiment, in step S402b, the MMID is included in the SD field.

[0117] In a third embodiment, in step S402c, a designated SD field (indicated by an X) is used to stitch an SST or a group of SSTs into a "superslice".

[0118] The AMF verifies whether the requested NSSAI is included in the list of allowed NSSAI parts subscribed by the UE, and in step S404, responds to the UE via the access network with a message indicating registration acceptance or registration rejection, which includes relevant NSSAI information, such as allowed NSSAI, rejected NSSAI, and configured NSSAI.

[0119] Coordination of multiple UE devices

[0120] The coordination of multiple UE devices will be described in two embodiments, one with AI capabilities only on the network and / or remote operator side, and one with AI capabilities also on the UE.

[0121] Embodiments with AI capabilities only on the network / remote operator side

[0122] As described in 3GPP TS23.501, the Network Slice Selection Function (NSSF) supports (i) selecting a set of network slice instances serving a UE, (ii) determining and mapping allowed NSSAI / subscribed S-NSSAI, (iii) determining the configured NSSAI, (iv) determining the set of AMFs serving the UE (if necessary, by querying the Network Repository Function (NRF), and (v) limiting the network slice instances based on NWDAF analysis. From the functions of the NSSF that have been described, it can be seen that the NSSF can utilize the NWDAF, can query the NRF, and can determine the set of AMFs serving the UE. In the case of multimodal services, the NSSF can not only for a single UE, and similar functionality may be utilized jointly for all UEs involved in a composite multimodal service. In one embodiment, the NSSF uses the “Multimodal Service ID” or “Super / Hyper Slice” proposed in the “Multimodal Service Identification” section to identify (i) the requested multimodal service and its QoE requirements, (ii) the UEs involved in the same multimodal service, and (iii) the required network slice and its specific QoS requirements. Therefore, in this embodiment, the NSSF creates a group for the UEs that are part of the multimodal service, referred to herein as a “Multimodal UE Group”, and associates the requested S-NSSAI of the UEs part from the “Multimodal UE Group” with the same service.

[0123] In another embodiment, the NWDAF collects analytics / statistics of multimodal services and provides interdependencies between members of a “multimodal UE group” based on the QoS / QoE (herein referred to as “multimodal QoE”) of the network slices / services / applications contributing to the multimodal services.

[0124] In another embodiment, NSSF utilizes NWDAF analysis regarding multimodal services, multimodal QoE, and interdependencies between members of a multimodal UE group to determine slice / service / application specific QoS / QoE levels and QoE measurement configurations.

[0125] In addition to the proposed NSSF-based solution, another embodiment uses the same functionality for AMF / SMF. When the AMF first receives the Registration Request / Update message, the AMF may use the “Multimodal Service ID” or “Super Slice” to identify (i) the requested multimodal service and its QoE requirements, (ii) the UEs involved in the same multimodal service, and (iii) the required network slice and its specific QoS requirements. The SMF may then utilize the NWDAF analysis of the interdependencies between the multimodal service, multimodal QoE, and members of the multimodal UE group to determine the slice / service / application specific QoS / QoE levels as well as the QoE measurement configuration. This will also enable dynamic updates to UEs establishing new PDU sessions as well as new PDU sessions triggered by a single UE, which may change the nature of the multimodal services provided to the end-user.

[0126] According to the present principles, the identification of specific QoS / QoE requirements may be handled as follows. A network may support a set of specific multimodal services, which may be identified by a given "multimodal service ID" or "hyper-slice". Each multimodal service may have predefined QoE requirements, referred to as "multimodal QoE". "Multimodal QoE" consists of different QoS / QoE requirements of the network slices / services / applications contributing to the multimodal service. "Multimodal QoE" represents the interdependencies between network slices / services / applications used not only by the same UE but also by all other UEs that are part of a "multimodal UE group". For example, a delay in acquiring data from one of the UEs / applications or acquiring low quality data due to low data rate performance may affect the performance / experience of another service / application. As a result, the overall performance of the multimodal service will fall short of the required QoE. Therefore, this interdependency is determined by the NWDAF based on the considered "multimodal QoE". This information is then used by (i) the NSSF to jointly configure the network slice or (ii) the AMF / SMF to jointly configure the QoS / PDU session to provide the multimodal service. This configuration includes determining the set of AMFs to serve all UEs involved in the multimodal service, updating the "multimodal UE group" in case some UEs (or sensors / devices) involved in the multimodal service may not be part of the group due to mobility and mapping of allowed / configured NSSAI to subscribed NSSAI.

[0127] Note that this embodiment with AI capability only on the network side may correspond to, for example, a network without AI 224C and 234B. Figure 2 .

[0128] Figure 5 Figures 5A-5D, is an example sequential flow chart showing a method for coordinating network slicing of composite E2E multimodal services according to an embodiment. The figure shows a network 50, which includes N UEs 51 (WTRU 1-WTRUN), an access network, (R)AN 52, AMF / SMF 53, UDM 54, NSSF 55, NWDAF 56, Policy Control Function (PCF) 57 and NRF 58. As an example, the MMID may be included in the example Figure 3A In the NSSAI shown, however, it will be appreciated that the MMID may alternatively be included in the Figure 3B and in the NSSAI shown in step S402c.

[0129] The network 50 has a specific set of multimodal services, and each multimodal service has a predefined multimodal QoE.

[0130] In step S502, WTRU1, WTRU2, ..., WTRUN 51 (where N represents the number of users considered in the figure) sends a registration request message with a multimodal service ID MMID for each S-NSSAI to the AMF 53, as already described in step S402.

[0131] In the case that the AMF 53 does not have the slice subscription information of the UE, in step S504, it queries the UDM 54 for the information by sending a message, as known in the art. When there is a multimodal service request, having the slice subscription information of the UE is not sufficient for the AMF 53 to determine whether to serve the UE 51, because the multimodal service may involve multiple UEs and the performance of each UE has interdependencies.

[0132] In the case where the AMF 53 queries the UDM 54 in step S504, the UDM 54 sends a response including the requested information in step S506.

[0133] In step S508, the AMF 53 sends a message including the multimodal service ID to the NSSF 55 to verify the allowed NSSAI(s) to serve the UE.

[0134] In step S510, based on the received identity information of each S-NSSAI with a multimodal service ID, the NSSF 55 generates a multimodal UE group. If the group already exists, the NSSF may alternatively update the existing multimodal UE group.

[0135] In step S512, the NSSF 55 sends a subscription message to the NWDAF 56 to receive multimodal QoE and interdependency analysis. The NSSF can use the SD to determine whether a network slice can be part of a super / ultra slice, for example, an S-NSSSI with a specific SD can signal a network slice that is neither mutually exclusive nor requires isolation.

[0136] In step S514, the PCF 57 sends a similar subscription message to the NWDAF 56. Note that the subscription may be part of the AM / SM policy association establishment or modification process initiated by the AMF / SMF 53. The NWDAF 56 has the analysis ID exposed to other NFs via Nnf_eventExposure, so that other NFs including the PCF can subscribe to the analysis.

[0137] In step S516, in the case where the requested multimodal service has been used by (multiple) UEs 51 or is currently being used by (multiple) UEs 51, the NWDAF 56 collects input data from relevant other 5GC NFs, AMF 53 and (R)AN 52. More specifically, the data collected from the RAN 52 is about UE QoE measurements.

[0138] In step S518, the NWDAF 56 determines the multimodal QoE prediction and interdependency analysis, and in steps S520a and S520b, sends messages including these analyses to the NSSF 55 and PCF 57, respectively. Note that the QoE measurements are application layer measurements configured by the OAM, and the NWDAF 56 can communicate with the OAM using existing service-based interfaces. It is assumed that the NWDAF 56 has preliminary information of the multimodal QoE configuration provided by the OAM, and in step S518, the NWDAF 56 uses this information to determine the multimodal QoE prediction and interdependency analysis.

[0139] In step S522, the NSSF 55 selects a network slice instance serving the multimodal UE group and determines / configures the allowed NSSAI and its 5QI.

[0140] In step S524, the NSSF 55 sends an NF Discovery Request message to the NRF 58 in order to determine a list of candidate AMFs that can serve the requested S-NSSAI for the multimodal service.

[0141] In step S526, the NRF 58 responds by sending a message to the NSSF 55 with a list of candidate AMF(s).

[0142] In step S528 , the PCF 57 determines a policy for QoS configuration for each member of the multimodal UE group, and sends the policy to the NSSF 55 in step S530 .

[0143] In step S532, NSSF 55 determines the AMF set to be used to serve the multimodal UE group, and the applicable access type information of each allowed NSSAI of each member of the multimodal UE group. NSSF 55 also determines the QoE measurement configuration of each member of the multimodal UE group based on the QoS configuration provided by PCF 57.

[0144] In step S534, the NSSF 55 sends a message, such as an Nnssf_NSselection_GetResponse message, to the AMF / SMF 53, which has the allowed NSSAI and the target AMF set.

[0145] In step S536, the NSSF 55 sends a message including information about the QoE measurement configuration to the AMF / SMF 53.

[0146] In step S538, the PCF 57 sends a message including information about the QoS configuration to the AMF / SMF 53.

[0147] In step S540, the AMF 53 responds to the UE's registration request by sending a message (registration acceptance or registration rejection) via the access network 52, as shown in FIG. Figure 4 In case the registration is accepted, in step S542, AMF 53 also sends a message including information about QoE measurement / QoS configuration.

[0148] In the case where the described AMF / SMF based embodiment is used instead of the NSSF based embodiment, the functions defined for the NSSF regarding (i) building a multimodal UE group, (ii) subscribing to multimodal QoE and interdependency analysis in the NWDAF, and (iii) QoE measurement configuration for each member of the multimodal UE group are handled by the AMF / SMF.

[0149] Note that the NSSF or AMF / SMF may determine the QoE measurement configuration for each member of the multimodal UE group. In order for the NSSF or AMF / SMF to do this, they use QoE measurement reports. The UE application layer generates the QoE report and sends it to the UEAS layer, which sends the QoE report to the NG-RAN node. The NG-RAN node then sends the QoE report to the configured final destination, such as the Measurement Collection Entity (MCE). According to the present principles, the MCE may be (i) NWDAF, (ii) OAM, or (iii) any other AF / NF that provides measurements / statistics to the NWDAF. Then, in step S518, the NWDAF determines the multimodal QoE prediction and interdependency analysis.

[0150] The NWDAF may perform these predictions / analyses as follows, for example, to provide analysis to other NFs that have subscribed to them. The NWDAF may leverage existing solutions described in 3GPP TR 23.700-91 "Study of enablers for network automation for the 5G System (5GS); Phase 2 (Release 17)", such as redundant transport experience statistics, session inactivity timer prediction, observed service experience analysis, etc., and multimodal UE group IDs. The NWDAF may then predict the multimodal QoE (based on the prediction for each service / application contributing to the multimodal service) and determine the interdependencies between the UEs / applications / services contributing to the multimodal service.

[0151] Based on the NWDAF statistics and predictions, (i) the NSSF (re)configures the QoE measurements based on the QoS configuration provided by the PCF and provides them to the AMF / SMF, or (ii) the AMF / SMF (re)configures the QoE measurements based on the QoS configuration provided by the PCF. The (re)configured QoE measurements / QoS are then signaled to the UE using existing mechanisms, such as explicit NAS signaling or explicit RRC signaling.

[0152] Figure 6 An example of UE slice multimodal coordination for an example use case of enhanced robotic telepresence is shown. SST / SD pairs are used to represent different network slices / services / applications that are part of a composite multimodal service. When the network wants to control / modify the UE usage of allowed S-NSSAI for a multimodal service, or when there is an update in the multimodal UE group due to mobility, the network updates the UE with the Network Slice Selection Policy (NSSP) as part of the UE Routing Selection Policy (URSP) rules as described in 3GPP TS23.501.

[0153] The figure shows in more detail Figure 2The figure also shows the network functions involved in the method shown in FIG5 .

[0154] Embodiments with on-device AI capabilities

[0155] In this embodiment, it is considered that not only the network but also the UE devices have AI capabilities. Therefore, once a multimodal UE group is created and the QoS / QoE of the network slices / services / applications contributing to the multimodal service are identified for the devices belonging to the multimodal UE group, each device autonomously or collaboratively optimizes (predicts) the QoE of the services / applications running in the devices affecting the composite E2E multimodal service. In order to achieve coordination / collaboration between devices that have AI capabilities and belong to the multimodal UE group, this embodiment uses an SST / SD pair named "Collaborative AI", which may require high throughput (for AI / ML model transmission / update) and / or low latency (providing device / application-specific changes that may affect the QoE of multimodal services or providing AI / ML model parameters). The new collaborative AI SST / SD pair is configured to include network slices that need not be isolated from each other nor mutually exclusive.

[0156] A "collaborative AI" SST / SD pair may be used to provide AI / ML model updates from the network to the UE device, or vice versa, from the UE device to the network, in the case of a federated learning-based AI / ML approach. Therefore, a "collaborative AI" SST / SD pair may require high throughput (for AI / ML model transmission / updates) and / or low latency (for the case of federated learning).

[0157] The “Collaborative AI” SST / SD pair can also be used to inform the network (SMF / NSSF as it provides coordination between the multimodal UE group as described in the embodiments with AI capabilities on the network / remote operator side) about any changes on the UE side, such as changes in video codec, video resolution, data granularity / frame rate, QoS requirements for specific service types, zoom level, tilt level, etc., which are applied based on the UE's own AI / ML-based assessment. Such information can enable the network (coordinator of multiple UE devices for the same multimodal service) to react accordingly. Therefore, the “Collaborative AI” SST / SD pair should preferably provide low latency in order to provide predictions for the UE, such as trajectory / mobility predictions, QoE predictions for applications running in the UE, or device / application specific changes that may affect the QoE of multimodal services.

[0158] The “Collaborative AI” SST / SD pair can be used to indicate that the video resolution of the application running on the surrounding sensing device is increased to a level where the robot does not need to stream video services at high quality or at all without degrading the E2E composite multimodal service QoE. In another instance, the “Collaborative AI” SST / SD pair can be used to indicate the UE’s own trajectory prediction, such as the UE may soon move in / out of different geographic areas. Therefore, the network can reconfigure the network slice / QoS / PDU session / DRB allocation accordingly. By doing so, the network can efficiently use its resources (enhanced energy / resource efficiency) as well as prepare for upcoming events that may affect QoS / QoE (mobility optimization / robustness).

[0159] Figure 7 is a sequence diagram illustrating message flows in a network involved in a composite E2E multimodal service according to an embodiment. The network 700 includes a core network 706, for example including NSSF (NSSF / UDM / NWDAF / PCF) and AMF / SMF, and multiple UEs with on-device AI capabilities, illustrated by WTRU1 702 and WTRU2 704. Typically, the network 700 includes an access network, but for purposes of illustration, this is not shown. Communications between the UE and the NSSF may be delivered via the access network and the AMF that forwards registration request / update messages in both directions or the SMF that forwards PDU session establishment / modification messages. It will be understood that where the description refers to messages to or from the core network, this may mean to or from a node in the core network. Multimodal QoE and interdependencies between members of a multimodal UE group may be determined as described previously in the description of an embodiment with AI capabilities on the network / remote operator side.

[0160] In step S702a, the UE capable of supporting the execution of AI / ML operations sends a request message to the core network 706. The UE may indicate the capability as "supporting AI / ML operations" in a 5GMM capability IE of a registration request / update message, etc. The message may have the AI / ML bit of "supporting AI / ML operations" set in the 5GMM capability IE.

[0161] Alternatively, in step S702b, the UE may send a PDU Session Establishment / Modification Request message or similar message including an indication of its 5GSM Capability IE. The message may have the AI / ML bit set to "Supports AI / ML Operations" in the 5GSM Capability IE.

[0162] The UE may request a network slice that is part of a collaborative AI group by providing a collaborative AI SST / SD pair.

[0163] Based on the AI / ML capability information of the UE, in step S704, the network 706 configures a "cooperative AI" slice (SST / SD pair), which includes establishing a PDU session for the cooperative AI slice. In step S706, the network 706 provides (sends) corresponding configuration information to the UE to perform AI / ML operations.

[0164] In one embodiment, these operations are to train the AI / ML model locally and provide model / parameter updates to the network.

[0165] In another embodiment, these operations are to predict UE behavior such as trajectory, load, CPU usage, etc. or modify device / application specific parameters / specifications that may affect the QoE of multimodal services.

[0166] In step S708 , one or more UEs perform AI / ML operations.

[0167] In step S710, one or more UEs send a message with results from the AI / ML operation to the network. The UE sends the message using collaborative AI slicing.

[0168] If the UE performs local AI / ML model training, the message may include AI / ML model / parameter updates. If the UE performs device / application specific AI / ML operations, the message may include predictions or device / application specific parameter / specification changes.

[0169] In step S712a, in response to one or more messages sent in step S710, the network may aggregate the AI / ML models / parameters provided by the UE to update the global AI / ML model. Based on the AI / ML operation on the network side, in step S714a, the network may send a message with the model / parameters of the retrained global model to the UE.

[0170] In step S712b, the network may determine the need for reconfiguration of slices / QoS / PDU sessions / DRB allocation based on UE prediction and / or device / application specific changes that may affect the QoE of the multimodal service. Figure 5C Determine the requirements as described in steps S528-S530 in FIG.

[0171] The network can also configure / modify slices / QoS / PDU sessions / DRB allocations to provide multimodal service QoE requirements.

[0172] in conclusion

[0173] Although features and elements are provided above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in 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 various aspects. Without departing from the spirit and scope of the present invention, many modifications and changes can be made, as will be apparent to those skilled in the art. Any element, action or instruction used in the description of this application should not be interpreted as being critical or necessary to the present invention unless explicitly provided as such. According to the foregoing description, in addition to the methods and devices listed here, functionally equivalent methods and devices within the scope of the present disclosure are apparent to those skilled in the art. Such modifications and changes 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 scope of equivalents to which these claims are assigned. It should be understood that the present disclosure is not limited to a specific method or system.

[0174] For simplicity, the foregoing embodiments are discussed with respect to terminology and structure of devices having infrared capabilities (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 (such as sound waves).

[0175] It should also be understood that the terminology used herein is for the purpose of describing specific embodiments only 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 on a time basis. 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" and its abbreviation "HMD" may represent or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any one of a plurality of embodiments of a WTRU; (iii) a device having wireless capabilities and / or wired capabilities (e.g., tetherable), which is particularly configured with some or all of the structure and functionality of a WTRU; (iii) a device having wireless capabilities and / or wired capabilities configured with less than all of the structure and functionality of a WTRU; or (iv) the like. References herein Figures 1A-1D Details of an example WTRU are provided that may represent any WTRU described herein. As another example, various embodiments disclosed above and below are described as utilizing a head mounted display. Those skilled in the art will recognize that devices other than head mounted displays may be utilized 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.

[0176] In addition, the methods provided herein can 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, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0177] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the various embodiments that may be applied, it should be understood that the illustrated embodiments are merely examples and should not be considered to limit the scope of the appended claims. For example, the embodiments provided herein include handheld devices that may include or be used with any suitable voltage source that provides any suitable voltage, such as a battery, etc.

[0178] In addition, in the embodiments provided above, processing platforms, computing systems, controllers and other devices including processors are mentioned. 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 symbolic representations of actions and operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as being "executed", "computer executed" or "CPU executed".

[0179] 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 that may result in the ultimate conversion or reduction of electrical signals and maintain the data bits in memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU and other processing of signals. The memory locations where the data bits are maintained are physical locations with specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. 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.

[0180] 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)) mass storage systems readable by the CPU. The computer-readable media may include cooperating or interconnected computer-readable media that reside exclusively on a processing system or distributed across multiple interconnected processing systems, which 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.

[0181] 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.

[0182] There is little distinction between hardware and software implementations of various aspects of the system. The use of hardware or software is typically (but not always, as in some cases the choice between hardware and software may become important) a design choice that represents a cost-efficiency tradeoff. There may be various means to implement the processes and / or systems and / or other technologies described herein (e.g., hardware, software, and / or firmware), and the preferred means may vary with the environment in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a tool that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0183] The foregoing detailed description has described various embodiments of the device and / or process by using block diagrams, flow charts and / or examples. To the extent that such block diagrams, flow charts and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation in such block diagrams, flow charts or examples can be implemented individually and / or together by various hardware, software, firmware or any combination thereof in fact. In one 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 some aspects of the embodiments disclosed herein can be implemented in whole or in part equivalently 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 a combination thereof in fact, and according to the present disclosure, designing circuits and / or writing codes for software and / or firmware will be completely within the skill of those skilled in the art. Furthermore, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the particular type of signal bearing medium used to actually perform the distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media, such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc., and transmission type media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0184] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein and then to integrate such described devices and / or processes into data processing systems using engineering practices. That is, at least a portion of the devices and / or processes described herein can be integrated into data processing systems through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system can typically include one or more of the following: a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, a driver, a graphical user interface, and an application, one or more interactive devices such as a touch pad or screen, and / or a control system including a feedback loop and a control motor (e.g., feedback for sensing position and / or velocity, a control motor 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 those commonly found in data computing / communication and / or network computing / communication systems.

[0185] The subject matter described here sometimes shows different components included in or connected to different other components.It should be understood that the architecture described in this way is only an example, and in fact many other architectures that realize the same function can 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 that are combined to realize a specific function here can be regarded as "associated" with each other so that the desired function is realized, without considering 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 compatible and / or physically interactive components and / or wirelessly interactive and / or wirelessly interactive components and / or logically interactive and / or logically interactive components.

[0186] With respect to the use of substantially any plural and / or singular terms herein, those skilled in the art may translate from the plural to the singular and / or from the singular to the plural as appropriate, depending on the context and / or application. For clarity, various singular / plural arrangements may be expressly set forth herein.

[0187] Those skilled in the art will understand 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 "comprising" should be interpreted as "including but not limited to", etc.). Those skilled in the art will further understand that if a specific number of a claim recitation is intended to be introduced, such intent will be expressly recited in the claim, and if no such recitation is present, such intent does not exist. For example, where only one item is intended, the term "single" or similar language may be used. To aid understanding, the claims appended below 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 including such introduced claim recitation to including only one embodiment of such recitation, even when 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 applies to the use of definite articles used to introduce claim recitations. Furthermore, even if a specific number of an introduced claim recitation is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted as meaning at least the recited number (e.g., the simple recitation of "two recitations" without other modifiers means at least two recitations, or two or more recitations). In addition, in those cases where there is a convention similar to "at least one of A, B, and C, etc.", in general, such construction is intended to allow those skilled in the art to understand the convention (e.g., "a system having at least one of A, B, and C" would include but is not limited to systems 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.). In those cases where there is a convention similar to "at least one of A, B, or C, etc.", in general, such construction is intended to allow those skilled in the art to understand the convention (e.g., "a system having at least one of A, B, or C" would include but is not limited to systems 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 further understand that any disjunctive words and / or phrases that actually represent two or more optional terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either term, or both terms. For example, the phrase "A or B" would 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 one," "any combination," "any plurality," and / or "any combination of a plurality" of the items and / or categories of items, either 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 the term "plurality" as used herein is intended to be synonymous with "multiple."

[0188] 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.

[0189] As will be understood by those skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also include any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be easily considered to fully describe and be able to divide the same range into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed here can be easily decomposed into a lower third, a middle third, and an upper third, etc. It will also be understood by those skilled in the art that all languages, such as "up to", "at least", "greater than", "less than", etc., include the recorded numbers and refer to the ranges that can be subsequently decomposed into sub-ranges as described above. Finally, as will be understood by those skilled in the art, 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, etc.

[0190] Furthermore, the claims should not be read as limited to the order or elements provided unless so stated. Furthermore, the use of the term "means for..." in any claim is intended to refer to 35 USC §112, 6 or means-plus-function claim format, and any claim without the term “means for…” is not so.

Claims

1. A method performed by a network node, the method comprising: Receiving a first request for a first set of network slices requested by a first wireless transmit / receive unit WTRU, the first request being associated with a service identifier; receiving a second request for a second set of network slices requested by a second WTRU, the second request being associated with a service identifier; wherein the first and second groups of network slices together include at least two different types of network slices; determining a set of instances corresponding to the requested network slice; as well as Information indicating instances of network slices corresponding to the first and second groups of network slices, respectively, is transmitted to at least one further network node.

2. The method of claim 1 , further comprising creating a multi-modal WTRU group comprising the first and second WTRUs.

3. The method of claim 1 , further comprising updating the multi-modal WTRU group to include a second WTRU.

4. The method according to claim 2 or 3, further comprising: transmitting a message to a data analysis node indicating a request for quality of experience (QoE) and interdependency analysis for a set of network slices including the first and second sets of network slices; as well as Receive QoE predictions and interdependency analysis from data analytics nodes.

5. The method according to any preceding claim, further comprising: Information indicative of a configuration for measuring QoE is transmitted to at least one further network node.

6. A method according to any preceding claim, wherein the request for a network slice includes information indicating the type of network slice and a slice distinguisher.

7. A method according to claim 6, wherein determining a set of instances corresponding to the requested network slice is based on a slice distinguisher.

8. A method according to any preceding claim, wherein the instance also corresponds to an allowed network slice for the corresponding WTRU.

9. A method according to any preceding claim, wherein: Information indicating instances of slices corresponding to the first and second groups of network slices, respectively, is transmitted to at least one additional network node for further transmission to the first and second WTRUs.

10. A network node, comprising: a memory storing processor executable program instructions; as well as At least one hardware processor configured to execute program instructions to: Receiving a first request for a first set of network slices requested by a first wireless transmit / receive unit WTRU, the first request being associated with a service identifier; receiving a second request for a second set of network slices requested by a second WTRU, the second request being associated with a service identifier; wherein the first and second groups of network slices together include at least two different types of network slices; determining a set of instances corresponding to the requested network slice; as well as Information indicating instances of network slices corresponding to the first and second groups of network slices, respectively, is transmitted to at least one further network node.

11. The network node of claim 10, wherein the at least one hardware processor is configured to execute program instructions to: A multi-modal WTRU group is created including the first and second WTRUs.

12. The network node of claim 10, wherein the at least one hardware processor is configured to execute program instructions to: The multi-modal WTRU group is updated to include the second WTRU.

13. The network node according to claim 11 or 12, wherein the at least one hardware processor is configured to execute program instructions to: transmitting a message to a data analysis node indicating a request for quality of experience (QoE) and interdependency analysis for a set of network slices including the first and second sets of network slices; and Receive QoE predictions and interdependency analysis from data analytics nodes.

14. The network node according to any one of claims 10-13, wherein the at least one hardware processor is configured to execute program instructions to: Information indicative of a configuration for measuring QoE is transmitted to at least one further network node.

15. A network node according to any one of claims 10-14, wherein the request for a network slice includes information indicating the type of network slice and a slice distinguisher.

16. A network node according to claim 15, wherein determining a set of instances corresponding to the requested network slice is based on a slice distinguisher.

17. A network node according to any one of claims 10-16, wherein the instance also corresponds to an allowed network slice of the corresponding WTRU.

18. The network node according to any one of claims 10 to 17, wherein: The at least one hardware processor is configured to execute program instructions to transmit information indicating instances of slices corresponding to the first and second groups of network slices, respectively, to at least one additional network node for further transmission to the first and second WTRUs.

19. A wireless transmit / receive unit WTRU, comprising: a memory storing processor executable program instructions; as well as At least one hardware processor configured to execute program instructions to: transmitting a first request for a first set of network slices to a network node, the first request being associated with a service identifier further known to the second WTRU; The first group of network slices includes at least two different types of network slices; as well as Information is received indicating an instance of a slice corresponding to a first set of network slices.

Images