Methods and apparatus to enable reliable and available wireless communications for multi-modal applications

Abstract

Multi-modal applications are applications that may include several communication modes such as audio, video, and haptic. Accordingly, a multi-modal application may be decomposed into a plurality of smaller components, and the plurality of components may be distributed in the network and run individually on a collaboration device, which may transmit multi-modal traffic using a plurality of streams. A deterministic network (DetNet) defines the ability to enable cooperative devices to support multi-modal traffic by having each device account for all available paths when selecting a path for transmitting data. The network may instantiate different application components in different devices and configure each device with a traffic policy consistent with the DetNet policy. This process can be implemented by extension of ProSe capability and traffic policies based on DetNet capability and policies, with the aim of ensuring a given QoS in terms of latency, reliability and availability.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 63 / 433,153, filed December 16, 2022, the contents of which are incorporated herein by reference. Background Art

[0002] Deterministic Networking (DetNet) is an effort led by the Internet Engineering Task Force (IETF) DetNet Working Group (WG) that studies the implementation of deterministic data paths for real-time applications. Real-time applications require bounded latency, very low data loss, and low jitter. Examples of such applications include audio and video streaming, engine control systems, and industrial and vehicle automation. DetNet operates at the IP layer and delivers services through lower layer technologies such as Multiprotocol Label Switching (MPLS) and IEEE 802.1 Time-Sensitive Networking (TSN). By dedicating network resources such as link bandwidth and buffer space to DetNet flows and / or flow classes, and by redistributing and / or replicating data packets along multiple paths, DetNet provides reliable and available services. Multimodal applications can include multiple communication modalities, such as audio, video, and haptics. Multimodal applications can be decomposed into multiple smaller functions, and the multiple smaller functions can be distributed in the network to run on collaborating devices (e.g., WTRUs, UEs) and / or infrastructure nodes. Since applications often require rigorous and reliable behavior, providing procedures that enable cooperating devices and infrastructure nodes to achieve the required performance is key. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] A more detailed understanding may be obtained from the following description given by way of example with reference to the accompanying drawings, in which like reference numerals represent like elements and in which:

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

[0005] Figure 1B is a diagram showing that according to one embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0006] Figure 1C is a diagram showing that according to one embodiment, Figure 1A a system diagram of an example radio access network (RAN) and an example core network (CN) used within the illustrated communication system;

[0007] Figure 1D is a diagram showing that according to one embodiment, Figure 1AA system diagram of an additional example RAN and an additional example CN used within the illustrated communication system;

[0008] Figure 2 shows the DetNet data plane protocol stack;

[0009] Figure 3 An example of communications involving multiple cooperating devices and different locations at an infrastructure is shown;

[0010] Figure 4 An example authorization process for 5G ProSe and DetNet communications is shown;

[0011] Figure 5 A high-level view illustrating an example of multimodal sidelink operation; and

[0012] Figure 6 An example process for multimodal sidelink operation is shown. DETAILED DESCRIPTION

[0013] Figure 1A is a 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-tailing unique word discrete Fourier transform spread OFDM (ZT-UW-DTS-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0014] 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, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d 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 (STA), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, 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 equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), 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.

[0015] 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 to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation Node B such as a gNode B (gNB), a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0016] Base station 114a may be part of the RAN 104, 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), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage 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, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In one embodiment, base station 114a may employ multiple-input, multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0018] 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, and the like. For example, the base station 114a in the RAN 104 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 (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

[0019] 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-A Pro).

[0020] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access and may establish the air interface 116 using NR.

[0021] In one 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 jointly implement LTE radio access and NR radio access, e.g., 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).

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

[0023] 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, 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 another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-APro, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown, base station 114b may have a direct connection to the Internet 110. Thus, base station 114b may not be required to access the Internet 110 via CN 106.

[0024] The RAN 104 may be in communication with the CN 106, 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. Data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, 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 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize an NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0025] The CN 106 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), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from 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 or a different RAT.

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

[0027] 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0028] 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), 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 in an electronic package or chip.

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

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

[0031] 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-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0032] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from 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). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0033] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to the 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.

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

[0035] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, (Bluetooth) 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. Peripheral device 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a posture sensor, a biometric sensor, a humidity sensor, etc.

[0036] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., signals associated with particular subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference through hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via 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., signals associated with particular subframes for both UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

[0040] Figure 1C The CN 106 shown in FIG may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing elements are 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.

[0041] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also 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.

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

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

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

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

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

[0047] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the 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 and destined for a STA may reach through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. For example, traffic between STAs within a BSS may be sent through the AP, where the source STA may send traffic to the AP, and the AP may deliver the 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 (e.g., directly between) the source and destination STAs using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled 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.

[0048] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel (such as a primary channel). The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, such as in an 802.11 system. For CSMA / CA, STAs (e.g., each STA) including the AP can sense the primary channel. If a particular STA senses / detects the primary channel 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.

[0049] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, formed by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0050] Very High Throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels, or by combining two discontinuous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can separate the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing separately. The streams 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 operations of the above-mentioned 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0051] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support metered 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).

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

[0053] In the United States, 802.11ah can be used in the available frequency band 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 available bandwidth for 802.11ah ranges from 6MHz to 26MHz, depending on the country code.

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

[0055] The RAN 104 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, and 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 unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, the gNBs 180a, 180b, and 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).

[0056] 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., containing a varying number of OFDM symbols and / or varying durations of absolute time).

[0057] 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 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 WTRUs 102a, 102b, 102c may communicate / connect with the gNBs 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles 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-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for the serving WTRUs 102a, 102b, 102c.

[0058] 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, interworking between DC, NR, and E-UTRA, routing user plane data to a user plane function (UPF) 184a, 184b, routing control plane information to an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0059] Figure 1DThe illustrated CN 106 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the aforementioned elements are depicted 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.

[0060] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 104 via the 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 non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMFs 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies, such as WiFi.

[0061] The SMFs 183a and 183b can connect to the AMFs 182a and 182b in the CN 106 via the N11 interface. The SMFs 183a and 183b can also connect to the UPFs 184a and 184b in the CN 106 via the N4 interface. The SMFs 183a and 183b can select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, and so on.

[0062] The UPF 184a, 184b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 104 via the N3 interface, 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. 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 DL packets, providing mobility anchoring, etc.

[0063] The CN 106 may facilitate communications with other networks. 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. Furthermore, 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. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0064] Given that Figures 1A-1D as well as Figures 1A-1D

[0045] As described above, one or more or all of the functionality described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functionality described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0065] Emulated devices can be designed to implement one or more tests of other devices in a laboratory environment and / or in a carrier network environment. For example, one or more emulated 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 emulated 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 emulated device can be directly coupled to another device and / or can use over-the-air wireless communication to perform the test.

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

[0067] Abbreviations and Acronyms: 5GC 5G Core BSS Business Support System D2D device to device DetNet Deterministic Networking IETF Internet Engineering Task Force IIoT Industrial Internet of Things LDACS L-band digital aviation communication system (LDACS) OAM operations, administration, and maintenance OODA Observe, Orient, Decide, Act OSS operation support system PAREO Packet (Hybrid) ARQ, duplication, elimination, and sequencing PCE Path Computation Element PDU Packet Data Unit PEF packet elimination function POF group sorting function PREOF packet duplication, elimination and sorting function PRF packet duplication function ProSe Proximity Services PSE path selection engine QoS Quality of Service RAW reliable and available wireless SL side link SLA Service Level Agreement TSCH Time Slotted Channel Hopping URLLC Ultra-Reliable Low-Latency Communications V2X Vehicle to Everything WTRU Wireless Receiver Transmitter Unit XR Extended Reality WG working group.

[0068] definition: - Deterministic Networking (DetNet): An IETF WG responsible for defining data and control plane procedures to support deterministic networking in wired and wireless multi-hop networks. - Reliable and Available Wireless (RAW): An extension of IETF DetNet whose goal is to ensure high reliability and availability of IP networks using scheduled wireless segments. -DetNet service sublayer: A sublayer that provides DetNet services to higher layers in the protocol stack and applications. -DetNet forwarding sublayer: The sublayer that supports DetNet services to the underlying network. Packet replication, elimination and sorting function (PREOF): The function of the DetNet service sublayer. It includes: 1. Packet Replication Function (PRF): Replicate packets 2. Packet Elimination Function (PEF): Eliminate duplicate packets 3. Packet Ordering Function (POF): Reorder packets in the DetNet stream - Path Computation Element (PCE): Generates alternative solutions for packet forwarding - Path Selection Engine (PSE): selects one of the PCE defined solutions for each packet - OODA (Observation, Orientation, Decision, Action) Loop: The phases executed during DetNet operation. 1. Observation phase: monitoring some or all jumps along the track; 2. Orientation phase: reporting link statistics to the PCE 3. Decision phase: The PSE decides which sub-track to use for the next packet(s) routed along the track. 4. Action phase: PAREO data plane actions operate at the DetNet service layer to increase the reliability of end-to-end transmission. -DetNet Path: A route through the network that is designed to meet certain performance guarantees, such as low latency, bounded jitter, and high reliability. Paths are established to ensure predictable and consistent network behavior. -DetNet Track: A network resource reserved for a specific DetNet path. Tracks are established to isolate traffic in the DetNet path from other network traffic.

[0069] Figure 2 The DetNet data plane protocol stack is shown. DetNet functionality is implemented in two adjacent sublayers in the protocol stack: the DetNet service sublayer 201 and the DetNet forwarding sublayer 202. The DetNet service sublayer 201 provides DetNet services, such as service protection, to higher layers and applications in the protocol stack. The DetNet forwarding sublayer 202 supports DetNet services in the underlying network, for example, by providing explicit routing and resource allocation for DetNet flows.

[0070] The DetNet service sublayer includes the Packet Replication Function (PRF), Packet Elimination Function (PEF), and Packet Ordering Function (POF) for packet processing at the DetNet edge, relay nodes, and end systems. These functions can be enabled at the DetNet edge node, relay node, or end system. Collectively, these three functions are referred to as the Packet Replication, Elimination, and Ordering Function (PREOF). The Packet Replication and Elimination service protection approach involves four capabilities in total. Sequencing information is provided to packets in the DetNet composite flow. This can be accomplished by adding sequence numbers or timestamps as part of the DetNet, or it can be inherent in the packet, such as in higher-layer protocols, or associated with other physical properties such as the precise time (and radio channel) the packet was received. This is typically performed once at or near the source. The PRF replicates these packets into multiple DetNet member flows and sends them to (multiple) destinations, typically along multiple different paths. The PEF eliminates duplicate packets from the DetNet flow based on the sequencing information and the history of received packets. The output of the PEF is a single packet. This can be performed at any DetNet node along the path to save network resources further downstream, especially when multiple replication points exist. The most common case is to perform this operation at the edge of the DetNet network, preferably in or near the receiver. The POF uses the sequencing information to reorder packets of the DetNet flow that were received out of order.

[0071] To perform PREOF, the DetNet service layer requires that the user data plane between DetNet nodes include ordering information and service labels, called S-labels. Based on the time, resource reservation, and policy enforcement of the distributed shaper, DetNet aims to provide real-time applications with the ability to carry designated unicast or multicast data flows with extremely low data loss rate and bounded latency to support time-sensitive and mission-critical applications on converged enterprise infrastructure. Due to the inherently volatile nature of wireless communications, wireless systems operating on shared media may experience unpredictable behavior. Therefore, wireless media may pose significant challenges to achieving deterministic properties such as very low packet error rate, bounded continuous loss, and bounded latency.

[0072] Reliable and Available Wireless (RAW) refers to an extension of the IETF DetNet concept with the goal of guaranteeing high reliability and availability of IP networks by leveraging scheduled radio segments and other features, such as frequency / time shared physical media resources with random traffic, such as IEEE Standard 802.15.4 Time Slotted Channel Hopping (TSCH); 3GPP features for 5G Ultra-Reliable Low Latency Communications (URLLC); IEEE 802.11ax / be; and L-Band Digital Aeronautical Communications System (LDACS). Similar to DetNet, RAW technology aims to maintain an abstraction from the underlying radio layer, addressing Layer 3 aspects to support applications requiring high reliability and availability. The term DetNet used here refers to the IETF DetNet technology, including its extensions to RAW.

[0073] The DetNet architectural framework summarizes the main DetNet operations as follows: DetNet distinguishes between long forwarding time scales and short forwarding time scales: the long time scale is used for routing calculations, and the short time scale is used for packet-by-packet forwarding decisions. DetNet operates on a DetNet flow through a complex path called a "track" at a forwarding (short) time scale within the network plane. A track represents network resources reserved along a path dedicated to DetNet traffic. Tracks are established to isolate traffic in a DetNet path from other network traffic, with the aim of guaranteeing certain QoS requirements such as low latency, bounded jitter, and high reliability. A track is pre-established and installed by means outside the scope of DetNet, and it can be strict or loose, depending on whether every hop or just a subset of hops is observed and controlled by DetNet. A sub-track is a "track within a track".

[0074] The DetNet architecture is structured as an OODA (Observation, Orientation, Decision, Action) loop. The OODA loop represents the operational phase in a control loop. The DetNet architecture applies this model to continuously optimize the spectrum and energy used to forward packets within the recovery graph by instantiating the OODA phases (Observation, Orientation, Decision, and Action).

[0075] Path computation timescale, which is the timescale over which complex paths are (re)computed; and path selection timescale, which is the timescale over which a forwarding decision is made for one or several packets. The DetNet function is to perform path selection on a packet-by-packet basis with the goal of providing reliable and available service while minimizing waste of limited resources. For example, the PCE may generate alternative solutions regarding routing and select one through a DetNet loop. To this end, DetNet defines a PSE, which is a peer to the PCE that is used to perform fast local adjustments of the forwarding table within the diversity that the PCE has selected for a track. The PSE enables the utilization of the richer forwarding capabilities of PAREO and the scheduling of transmissions at a faster timescale.

[0076] In the observation phase, network plane measurement protocols for operations, administration, and maintenance (OAM) monitor some or all hops along the track, as well as end-to-end packet delivery. In the orientation phase, controller plane elements report link statistics to the path computation element (PCE) in the centralized controller, which computes and installs the track and provides metadata to guide routing decisions. In the decision phase, the runtime distributed path selection engine (PSE) decides which sub-track to use for the next (multiple) packets routed along the track. In the action phase, packet (hybrid) ARQ, replication, elimination, and ordering (PAREO) data plane actions run in the DetNet service layer to increase the reliability of end-to-end transmission. The DetNet architecture also handles piggybacking signaling (i.e., signaling sent in data packets) when nodes on the path from the PSE to the track act on decisions. The overall OODA loop optimizes the use of redundancy to achieve the reliability and availability required to maintain service level agreements (SLAs) while minimizing the use of limited resources such as spectrum and battery.

[0077] The Path Computation Element (PCE) generates alternative solutions and selects one for each packet to provide reliable and available service while minimizing the waste of limited resources. DetNet defines a Path Selection Function (PSE), which is a peer of the PCE and is used to perform fast local adjustments to the forwarding table within the diversity that the PCE has selected for the track. The PSE enables the use of richer forwarding functions with packet (hybrid) ARQ, replication, elimination, and ordering (PAREO), and transmissions scheduled at faster timescales.

[0078] Contrary to the path definition above, a "track" is not necessarily linear. It may contain multiple paths, which can fork and reconnect, for example to enable DetNet PAREO operation. In DetNet terminology, a track has the following properties: a track has an ingress node and an egress node, which act as DetNet edge nodes; a track is reversible, meaning that packets can be routed against the flow of data packets (for example, to carry OAM measurements or control messages back to the ingress node); the vertices of the track are DetNet relay nodes that operate at the DetNet service sublayer and provide PAREO functionality; and the topological edges of the graph are serial sequences of DetNet forwarding nodes that operate at the DetNet forwarding sublayer. The DetNet PSE selects sub-tracks on a packet-by-packet basis or on a per-packet group basis to provide the desired reliability for the transmitted flow.

[0079] In 3GPP, 5G NR Sidelink (SL) was introduced in Release 16, enabling nearby devices to communicate directly with each other without requiring packets to pass through the 3GPP network. The device-to-device (D2D) direct communication protocol enables two devices to communicate directly with or without network assistance. D2D communication has different scenarios depending on whether the UEs involved are within the coverage area of ​​a cellular network. Target applications include mission-critical services, vehicle-to-everything (V2X) services, and the Industrial Internet of Things (IIoT). D2D communication promises ultra-low latency links, making it an attractive solution for a variety of emerging applications such as AR, VR, and XR.

[0080] Within the scope of D2D, 3GPP standards generally support two technologies: Proximity Services (ProSe) and Group Communication. ProSe allows devices in close proximity to each other to discover each other and communicate directly with each other. This is achieved by the D2D discovery and D2D direct communication procedures. The discovery procedure allows a UE to discover other UEs in its vicinity, which can be performed directly by the UE or through the network. The Group Communication procedure allows one-to-many communication between UEs in a highly resource-efficient manner, allowing messages to be easily disseminated to a large group of people via a common stream.

[0081] The concept of a packet data unit (PDU) set was first introduced in 3GPP during research on XR (Extended Reality) and media services. A PDU set consists of a group of interrelated PDUs that are grouped together, allowing them to be treated similarly (for example, a PDU includes data belonging to the same video frame). As defined in 3GPP TR 23.700-60 V1.2.0, the definition of a PDU set is: a PDU set consists of one or more PDUs that carry the payload of an information unit generated at the application level (for example, a frame or video slice for an XRM service, as used in TR 26.926). In some implementations, the application layer requires all PDUs in the PDU set to use the corresponding information unit. In other implementations, the application layer can still recover some or all of the information units even when some PDUs are lost.

[0082] There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks. Relevant examples are Extended Reality (XR) and multimodal applications, such as, for example, immersive gaming, digital twins, etc. In these environments, the UE requires strict and predictable behavior in terms of latency and / or resilience and / or availability and / or throughput as it moves and may change its attachment point. As mentioned in the previous paragraphs, a multimodal application is an application that may include several communication modalities, such as audio, video and haptics. Therefore, a multimodal application can be decomposed into multiple smaller functions, and the multiple smaller functions can be distributed in the network to run on collaborating devices (e.g., WTRU, UE) and / or infrastructure nodes (e.g., nodes at the edge or in the cloud). The communication between the devices and the infrastructure nodes is via a multimodal communication link, which may be a communication link that can be used by a flow that supports DetNet (i.e., a link on which the DetNet mechanism can be enabled).

[0083] Figure 3 An example of communications involving multiple collaborating devices and different locations at the infrastructure is shown. The devices are referred to as "collaborative" because they collaborate to forward packets of the same or different multimodal flows to a destination. A given application may have multiple functions (or components) 301, each of which runs at different locations on the terminal 302 and infrastructure side 303, 304. UEs communicate between them using device-to-device / sidelink communications 305. New solutions are needed to allow UEs to decompose different functional applications that can run on these distributed nodes (including other UEs 302 and infrastructure nodes 303, 304, such as edge / cloud 304) in a way that guarantees the reliability and availability requirements of each involved node across multiple network segments and transports.

[0084] Typically, service and QoS requirements are addressed at the session / flow granularity. This limits the system's ability to meet QoS requirements, especially when applications have strict latency requirements and the inherently volatile nature of device-to-device communications necessitates frequently fluctuating network conditions. The IETF DetNet WG is responsible for defining data and control plane procedures to support deterministic networking in wired and wireless multi-hop networks. DetNet capabilities enable the network to consider all available paths when deciding the most appropriate path to transmit data, taking into account runtime conditions. It also allows service forwarding decisions to be made at the packet level, allowing for more dynamic changes at a finer granularity.

[0085] UEs can collaborate to support distributed multimodal / XR services by providing reliability and availability to multiple streams. Procedures for collaborative UEs to support multimodal services can be defined. Extensions to ProSe signaling and UE and ProSe policies can enable the simultaneous use of multiple sidelink channels to support such applications. Messages can be exchanged between UEs to enable multiple collaborative UEs to use multiple sidelink channels in a manner that guarantees a given QoS in terms of reliability and availability. Various illustrative functional blocks and method stages are described in terms of their functions or logical blocks. Whether such functionality is implemented as hardware, software, or a combination of both depends on the specific application and the design constraints on the overall system. The illustrative processes described for various embodiments may be described as functions having stages that follow a specific order, where the specific order is for clarity purposes only. Therefore, for different implementations, some stages may be performed in a different order, some stages may be skipped or may not be present in all embodiments, and some stages may be added (and may not be shown herein). Similarly, the names of the parameters, messages, and processes used here are for clarity purposes only and may be different in different implementations.

[0086] Figure 4An example of an authorization process that can be used by a UE for combined ProSe and DetNet authorization is shown. At 401, (multiple) UEs participating in a multimodal / XR application may register with the 5G system. The UE may indicate multimodal / XR application functional support and DetNet capabilities in an existing registration request message 401. One or more DetNet-specific information elements (IEs) may be added to the registration request message sent by the UE (for typical registration messages, see clause 4.2.2.2.2 of 3GPP TS 23.502 V17.3.0). Optionally, a new registration message may be defined that includes one or more IEs with multimodal / XR application functional support. In another example, a new procedure may be defined for the UE to communicate its multimodal / XR application functional support and DetNet capabilities to the network. The information related to multimodal / XR application functional support sent by the UE to the network may include one or more multimodal / XR applications supported by the (multiple) UEs. For example, DetNet capabilities may be included in the "5GMM Capabilities" IE in the Registration Request message (see, for example, Release 18 of 24.501). Multimodal / XR application functionality support may also indicate the UE's intention to join an existing group that already supports one of such applications, for example via an application identity (App ID).

[0087] To request ProSe policy, the UE uses the 5G ProSe Policy Provisioning Request IE (as defined in clause 4.3.1 of 3GPP TW 23.304 V17.0.0) in a Registration Request message or during a UE-triggered 5G ProSe policy provisioning procedure. In one embodiment, the 5G ProSe Policy Provisioning Request IE is extended to include new capabilities / parameters for DetNet (e.g., included in the list below) as well as existing parameters for 5G ProSe direct discovery and other ProSe features. New policy parameters may include: (a) DetNet capabilities supported by the UE (e.g., an indication of whether DetNet capabilities are supported, an indication of whether DetNet enhanced ProSe / sidelink relay capabilities are supported); (b) DetNet functions hosted by the UE (e.g., PSE functions); packet and PDU set level switching / forwarding / routing capabilities (e.g., packet level switching implemented by the PSE, allowing faster switching of paths / tracks / sub-tracks); (d) information related to multimodal flows (e.g., QoS requirements for each flow, application modality type [audio, video, tactile]) or application ID that can be used by the network to determine the QoS requirements of application layer services and make resource reservation decisions; (e) the duration or time that DetNet and ProSe / sidelink communication links may be required, which can be specified as a duration, or with start / end times, or the geographical location where DetNet and ProSe / sidelink services are required.

[0088] New procedures can be defined to exchange DetNet capabilities and policies between the UE and the network, or between different UEs. The network can send its DetNet capabilities and service policies to the UE, referred to herein as the DetNet configuration. The DetNet configuration can be sent autonomously, i.e., without the UE requesting it, and can be sent, for example, during UE authorization registration. Alternatively, the configuration can be sent to the UE in response to an explicit request from the UE.

[0089] exist Figure 4 In 402, the UE may perform an authorization procedure with the network, more specifically, with the PCF (e.g., with the PCF via the AMF via the N1 interface). Optionally, the UE may perform an authorization procedure with the ProSe application server via the PC1 interface. The UE may send or receive an authorization message to / from the 5GC (i.e., the PCF via the AMF via the N1 interface) or via the ProSe application server via the PC1 interface. The UE may be pre-configured with a ProSe+DetNet configuration, and the 5GS (e.g., PCF) may send an authorization message with a list of PLMNs / networks / geographic locations / cells with which the UE may use ProSe discovery and direct communication, as well as the DetNet configuration. In the absence of an associated UE context, subscription information may be obtained (e.g., via UDM). The UE may send an authorization request to the network to obtain authorization for use of the ProSe+DetNet capability within the specified PLMN / network / geographic location / cell. For example, the ProSe+DetNet capability may be specified as packet-level path / track / sub-track switching, and the availability of a locally hosted PSE.

[0090] The authorization message may include information related to the time during which ProSe communications are valid, such as duration or start and / or end time. The authorization message may include information related to the authorization of ProSe discovery and direct communication (e.g., including other parameters such as the authorization policy and described in clause 5.1.3 of 3GPP TS 23.304 V17.0.0) and information related to the authorization of DetNet services (e.g., a list of ProSe identifiers with geographical areas requiring privacy support, authorized PLMNs). The authorization message may be based on the existing service authorization of ProSe and include a new IE for enabling authorization of new DetNet capabilities; optionally, the existing process may be extended to enable authorization of new DetNet capabilities. This new capability may include the following: (i) an indication of whether the DetNet feature is enabled, or alternatively, the UE / 5GC may not include this explicit indication but may enable authentication of the DetNet functionality based on the following parameters; (ii) hosted DetNet functionality, which may indicate the DetNet functionality that may be hosted by the UE for providing services to other network entities (e.g., PSE); (iii) path switching capability, which may indicate whether the UE supports dynamic path / track switching and, if so, at which level the switching may be performed (e.g., packet, PDU, PDU set); and (iv) DetNet domains of interest and application domain IDs of interest, which may allow limiting the domain to only some UEs.

[0091] The authorization message may include information related to the multimodal flows (e.g., QoS requirements for each flow, application modality type [audio, video, haptic]). Alternatively, the UE may provide an application ID, which is used by the network to determine the QoS requirements for the application layer service and make resource reservation decisions.

[0092] The authorization message may include authorization information required for DetNet network operation. This may use subscription data, existing authorization mechanisms of 5GS, or external authorization systems (for cases where some DetNet services are provided externally). This information may include, but is not limited to, authorization to host DetNet functions (e.g., PSE), authorization to perform handovers at any level between packet and PDU levels, and authorization to provide DetNet services to other UEs (e.g., acting as a ProSe+DetNet relay UE).

[0093] In some cases, Figure 4402 may be triggered by 401. In 403, the UE may receive a configuration message including any combination of the information specified in 402. In the scenario where only part of the information is sent to the UE in 402, the remaining information may be sent together with the authorization for ProSe discovery through the authorization and policy provisioning message 403, and it may include the following information: (a) authorization for the UE to use ProSe discovery and direct communication; (b) authorization for the UE to use DetNet features, including requesting to establish flows using DetNet capabilities; applying DetNet services to flows forwarded by the UE; forwarding / routing / switching flows between UEs or between the UE and the network; or using other DetNet features described herein, as well as for parts / segments of the DetNet network (e.g., only some DetNet domains may be authorized for use, while other domains allowing lower latency and higher bandwidth may only be accessed by higher-tier subscribers).

[0094] exist Figure 4 In

[15] , the procedures related to PCE DetNet can be implemented as an extension of PCF and / or can be deployed together with PCF. The DetNet PSE function can be hosted by all or some UEs used by multimodal applications.

[0095] Figure 5 A summary example of a multimodal link establishment process is shown. After the registration, authorization and policy negotiation 500 described above, the UE may start the establishment process. The UE may indicate the QoS application requirements to the AF / AS 501. The QoS requirements may include DetNet enhanced parameters including at least one of bounded latency, reliability and availability requirements associated with the multimodal application. Latency refers to the end-to-end latency in one direction. Availability refers to the percentage of the total time that the service is available "as expected" (i.e., able to meet the required QoS). Reliability is the percentage of the operating time that the service operates "as expected" (i.e., meets the required QoS).

[0096] The AF / AS may forward the information to the PCF / PCE 502. The PCF / PCE may perform updates to the UE QoS policy, including the DetNet enhanced policy 503. The UE may establish both ProSe and DetNet communication links required to meet the QoS requirements of the multimodal application 504. The UE may use the QoS policy to perform per-packet forwarding decisions, ensuring that QoS application requirements 505 are met.

[0097] Figure 6Another example process for multimodal sidelink operation is shown. A UE (UE 1) may be aware of other UEs in its neighborhood, may establish sidelink communications with the UEs, and may be able to instantiate multiple functions 600 that may be part of a multimodal / XR application. Each UE may indicate to the network (e.g., to the 5G DDNMF) the DetNet capabilities (e.g., PSE) supported and / or hosted by the UE. The 5G DDNMF is a Direct Discovery Name Management Function in the 5G Core Network that handles the network actions required for the Direct Discovery process.

[0098] When using the ProSe open discovery procedure (Model A), all UEs capable of instantiating the functionality of a specific multimodal / XR application send a ProSe discovery notification message over the PC5 reference point to advertise their capabilities. A ProSe application code / ID can be defined to identify a specific multimodal / XR application, which can then be used by UE1 to identify suitable UEs in the vicinity when monitoring. The message may include an indication of the specific DetNet services supported by each individual UE. When using the ProSe restricted discovery procedure (Model B), a UE (UE 2) (and all other UEs) may obtain authorization for restricted discovery. UE 1 sends a notification message over the PC5 interface, which is targeted at UEs capable of instantiating the functionality of a multimodal / XR application. The application may be identified by a ProSe application code obtained during authorization or during another procedure with the network. The message may include an indication of the DetNet services supported by each individual UE. The UE may identify which of the detected UEs support the DetNet extension. UEs that do not support DetNet may only be used to transmit non-DetNet services.

[0099] Taking into account other UEs and infrastructure, the UE may decide how to split the application into different components / flows and where to instantiate them 601. The UE may take into account different computation and connectivity requirements.

[0100] A UE or application function (AF) requests the instantiation of multiple functions, including services, 602. This message can be an application layer message sent by a service enabler client in the UE to the AF. Alternatively, this is part of the PDU Session Establishment or PDU Session Modification process and can include additional DetNet parameters related to the link to be established with other UE(s): (a) packet and PDU set-level switching / forwarding / routing capabilities, including packet-level switching implemented by the PSE, allowing faster switching of paths / tracks / sub-tracks); (b) information related to multimodal flows, including QoS requirements for each flow and application modality type (audio, video, haptic); and (c) the duration of the communication, or when the DetNet and ProSe / sidelink communication links may be required. The communication link duration can be given as a start time and end time, or a start time and time length. The start time can reference another time known to all UEs, such as a frame number, timeslot number, or symbol number. The start time can reference the end time of another process (such as a discovery process). Additional parameters can include the geographic location where DetNet and ProSe / sidelink services are required.

[0101] The orchestrator / controller entity can instantiate different functions 603. The orchestrator / controller can send messages to service enablers hosted in other UEs and / or network infrastructure, including, for example, the identities of these UE / infrastructure nodes, which can be known to the requesting UE or AF. An example of an orchestration framework is defined by ETSI NFV. The orchestrator can handle application components. In some embodiments, the orchestrator can be replaced by a control entity responsible for deploying / instantiating different components (e.g., Operations Support System (OSS), Business Support System (BSS)).

[0102] The UE may indicate its application requirements in terms of QoS to the AF / AS 604. The QoS policy request may include DetNet-enhanced parameters, including at least one of bounded latency, reliability, and availability requirements associated with a set of network flows associated with a multimodal application. The UE may also indicate the QoS requirements for each individual unimodal flow. The UE may provide an application ID, which the AF / AS may map to a set of QoS requirements.

[0103] The AF / AS may send the received QoS configuration request message to the PCE, which may include information about the multimodal flow (e.g., received QoS requirements) 605. The AF / AS may add additional parameters to the message, which are AS-specific requirements associated with the multimodal flow. The PCE may be hosted as part of the PCF or hosted on the same node.

[0104] The PCE may trigger the configuration of network paths that can be used as rails, if they are not already configured, and assign them rail IDs 606. This configuration may be done by the appropriate network entity based on a request from the PCE (e.g., PCF, SDN controller). This configuration involves the PCE configuring the network elements (including UEs) required to form the required network links (e.g., QoS profiles, forwarding profiles, etc.), including D2D links (e.g., specifying the ProSe ID of the peer UE, etc.).

[0105] The PCE can determine or calculate possible paths or tracks between different UEs, which the UEs can then use to make per-packet forwarding decisions. The PCE can use different pieces of information to calculate these tracks (e.g., monitoring information from OAM tools running in the network, information exposed by the NEF, etc.). The PCE sends a configuration message 607 to the AF / AS. The configuration may include paths calculated for each flow in a multimodal session, including their track IDs. The configuration may include a set of configurations used based on runtime conditions. Each configuration may be associated with a condition vector containing upper and lower bounds for each parameter (e.g., distance to neighboring UEs / channel quality). In cases where a subset of DetNet capabilities can be provided by an external network or component (e.g., an application layer protocol), the message may include services that the 5GS is responsible for providing and services that the DetNet network is responsible for performing. In cases where the 5GS does not provide DetNet capabilities, the DetNet capabilities may be provided by higher layers. Such information may also include associated QoS parameters for each flow, PDU set, packet set, and any one of the packet granularity.

[0106] The AF / AS may send a message 608 requesting QoS configuration to the NEF / PCF and / or the ProSe application server, for example, a Nnef_AFsessionWithQoS create request message.

[0107] The PCF may be aware of different network nodes, their capabilities, and the UE sidelinks. The PCF may store information received from the PCE and may generate routing path calculation rules for all links or a subset of links (including sidelinks and Uu), which are rules that allow the UE to derive the appropriate path (including tracks and sub-tracks) for each flow. The PCF may generate rules for deriving QoS rules and profiles for flows sent on the sidelink. The PCF may generate PCC rules for PDU sessions associated with the same application. The PCF / PCE may perform an update 609 of the UE policy. The update may be accomplished by sending a Manage UE Policy Command message to the UE, which may be replied with a Manage UE Policy Complete message from the UE. These messages include URSP rules or ProSe Policy (ProSeP) rules for (multiple) UEs, which may be extended to include DetNet enhanced policies. For additional reliability, DetNet enhanced policies may include support for message or packet duplication, message or packet merging, and support for network coding. For example, the extensions may include: track ID, PREOF / PAREO rules applied to the service, and network coding policies applied to the service. The NEF / PCF may respond with a Nnef_AFsessionWithQoS notification message 610 to the AF / AS.

[0108] Based on the rules / policies received from the PCF and local information (which may be updated through additional OAM mechanisms), the UE may configure both ProSe and DetNet communication links as needed to meet the application's requirements. This may be based on runtime conditions (e.g., direct link quality to other neighboring UEs) 611.

[0109] (Multiple) UEs can make per-packet forwarding decisions based on policies and associated rules to ensure the QoS required by service 612. These decisions may include complex forwarding modes such as duplication and merging, or even network coding, which employs DetNet mechanisms. This may require the use of DetNet data plane mechanisms (e.g., RFC 8939) or extensions to the 3GPP data plane to include information that allows identification of DetNet flows. (Multiple) UEs play the role of PSE entities defined by the DetNet architecture.

[0110] If the multimodal communication includes functions hosted in the infrastructure (at the edge / core of the mobile network or in an external data network), then DetNet data plane mechanisms can be used to provide end-to-end reliable communication. As non-limiting examples, this can include the use of IP data plane mechanisms (as specified in RFC 8939), extensions to other encapsulation mechanisms to include service tags (S tags).

[0111] At this point, traffic is exchanged between different nodes based on decisions made by the PSE function running on the UE. Non-limiting examples of packet forwarding decisions made by the UE include: dynamic selection of the path (track) to use based on local context information; replication of packets (by the source and / or intermediate UEs) and transmission over multiple paths (tracks); merging of traffic received over multiple paths (tracks) (by intermediate and / or destination UEs); and application of network coding strategies. Adequate monitoring tools should be in place to detect / predict potential disruptions to the agreed QoS and react as quickly as possible.

[0112] Although Figure 6 A UE-triggered or UE-controlled method is shown, but this is provided as an example and not limiting. For example, the AF at the network infrastructure can also trigger / control the process. Figure 6 Examples of messages that may originate from the AF are shown at 602 and 604 in FIG. 1 and the related description above.

[0113] Although the features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware contained in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over 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 may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented by a wireless transmit receive unit (WTRU), the method comprising: sending the WTRU capabilities including the WTRU's multimodal communication capabilities to the network; Sending multimodal application Quality of Service (QoS) requirements to the Application Function (AF) associated with the network; receiving, from the network, multimodal policies and configuration parameters associated with the multimodal operation; establishing a direct link with one or more WTRUs based on the received multimodal policy; as well as On a per-packet basis, a determination is made as to which multimodal policy to apply to each packet, and which communication link to use to send each packet.

2. The method of claim 1 , wherein the WTRU multimodal communication capabilities include one or more of: DetNet-related functions hosted by the UE (e.g., PSE functions); Packet and PDU level routing capabilities; Information related to supported multimodal applications, including QoS requirements, supported application modality types, and / or supported application identities; when or how long a multimodal communication link may be needed; as well as Geographical locations where multimodal communication links may be required.

3. The method according to claim 1, wherein The WTRU multimodal communication capabilities include Internet Engineering Task Force (IETF) Deterministic Networking (DetNet) capabilities.

4. The method according to claim 1, wherein The WTRU multimodal communication capabilities are sent in at least one of a registration message and / or a 5GMM capability information element (IE).

5. The method according to claim 1, wherein The WTRU multimodal communication capabilities include a request for network authorization for the WTRU to exercise multimodal communication capabilities.

6. The method of claim 1, wherein the multimodal application QoS requirement comprises at least one of latency, reliability, and / or availability.

7. The method of claim 1, wherein the multimodal QoS requirement includes a time window during which a multimodal link is required to operate.

8. The method of claim 1, wherein the multimodal QoS requirement includes a geographic location where a multimodal link is required to operate.

9. The method of claim 1 , wherein the multimodal policy and configuration parameters include DetNet policy and configuration, including at least one of: track identification information; packet replication, elimination and ordering function (PREOF) information; packet (hybrid) ARQ, replication, elimination and ordering (PAREO) information; and / or network coding strategy information. 10 . The method of claim 1 , wherein a communication link used to transmit each packet comprises at least one of a Proximity Service (ProSe) communication link, a DetNet communication link, and / or a direct communication link to a network.

11. A wireless transmit receive unit (WTRU), the WTRU comprising: processor; Communication interface; The processor and the communication interface are configured to send WTRU capabilities including WTRU multimodal communication capabilities to a network; The processor and the communication interface are configured to send a multimodal application quality of service (QoS) requirement to an application function (AF) associated with the network; The processor and the communication interface are configured to receive multimodal policies and configuration parameters associated with multimodal operations from a network; The communication interface is configured to establish a direct link with one or more WTRUs based on the received multimodal policy; as well as The processor is configured to determine on a per-packet basis which multimodal policy to apply to each packet and which communication link to use to transmit each packet.

12. The WTRU of claim 11 , wherein the WTRU multimodal communication capabilities include one or more of: DetNet associated functions hosted by the UE (e.g., PSE functions); Packet and PDU level routing capabilities; Information related to supported multimodal applications, including QoS requirements; Information related to supported multimodal applications, including QoS requirements, supported application modality types, and / or supported application identities; when or how long a multimodal communication link may be needed; as well as Geographical locations where multimodal communication links may be required.

13. The WTRU of claim 11 , wherein: The WTRU multimodal communication capabilities include Internet Engineering Task Force (IETF) Deterministic Networking (DetNet) capabilities.

14. The WTRU of claim 11 , wherein: The WTRU multimodal communication capabilities are sent in at least one of a registration message and / or a 5GMM capability information element (IE).

15. The WTRU of claim 11, wherein the WTRU multimodal communication capabilities include a request for network authorization for the WTRU to exercise multimodal communication capabilities.

16. The WTRU of claim 11, wherein the multimodal application QoS requirements include at least one of latency, reliability, and / or availability.

17. The WTRU of claim 11, wherein the multimodal QoS requirement includes a time window during which the multimodal link is required to operate.

18. The WTRU of claim 11, wherein the multimodal QoS requirement includes a geographic location where the multimodal link is required to operate.

19. The WTRU of claim 11, wherein the multimodal policy and configuration parameters comprise DetNet policy and configuration, including at least one of: track identification information; packet replication, elimination, and ordering function (PREOF) information; packet (hybrid) ARQ, replication, elimination, and ordering (PAREO) information; and / or network coding policy information.

20. The WTRU of claim 11, wherein a communication link used to send each packet comprises at least one of a Proximity Services (ProSe) communication link, a DetNet communication link, and / or a direct communication link to a network.

Images