Method and apparatus for enabling reliable and available wireless communication for multimodal applications

Abstract

A multimodal application is an application that can include several modalities of communication, such as audio, video, and haptics. Therefore, a multimodal application can be decomposed into multiple smaller components. The components can be distributed throughout the network and run separately on collaborating devices. Cooperative devices can use multiple flows to forward multimodal traffic. Deterministic Networking (DetNet) defines capabilities that enable collaborating devices to support multimodal traffic by allowing each device to consider all available paths when selecting a path for forwarding data. The network can instantiate different application components in different devices and configure each device with traffic policies aligned with DetNet policies. This process is enabled by extensions to ProSe capabilities and traffic policies based on DetNet capabilities and policies, with the aim of guaranteeing a given QoS in terms of latency, reliability, and availability.

Description

[Technical Field]

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

[0002] Deterministic Networking (DetNet) is an effort led by the Internet Engineering Task Force (IETF) DetNet Working Group (WG) to study the implementation of deterministic data paths for real-time applications. Real-time applications require bounded latency, extremely low data loss rates, and low jitter. Examples of such applications include audio and video streaming, engine control systems, and industrial and vehicular automation. DetNet operates at the IP layer and delivers services on top of lower-layer technologies such as Multiprotocol Label Switching (MPLS) and IEEE 802.1 Time-Sensitive Networking (TSN). DetNet provides reliable and available services by dedicating network resources, such as link bandwidth and buffer space, to DetNet flows and / or classes of flows, and by redistributing and / or duplicating data packets along multiple paths. Multimodal applications can involve multiple modalities of communication, such as audio, video, and haptics. A multimodal application may be decomposed into multiple smaller functions, which may be distributed throughout the network to run on cooperating devices (e.g., WTRUs, UEs) and / or infrastructure nodes. Because applications often require rigorous and reliable behavior, it is important to provide procedures that enable the cooperating devices and infrastructure nodes to achieve the required performance. [Brief explanation of the drawings]

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

[0004] [Figure 1A]FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) used within the communication system of FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an exemplary radio access network (RAN) and core network (CN) used within the communication system of FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1B is a system diagram illustrating a further example RAN and CN that may be used within the communication system of FIG. 1A, according to one embodiment. [Figure 2] FIG. 1 illustrates the DetNet data plane protocol stack. [Figure 3] FIG. 1 illustrates an example of communication involving multiple cooperating devices and different locations in an infrastructure. [Figure 4] FIG. 1 illustrates an exemplary authorization procedure for 5G ProSe and DetNet communications. [Figure 5] FIG. 1 is a schematic diagram of an example of multimodal side link operation. [Figure 6] FIG. 1 illustrates an example procedure for multimodal side link operation. DETAILED DESCRIPTION OF THE INVENTION

[0005] 1A 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 the multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail (ZT) unique-word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0006] 1A, communications 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, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of 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 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, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), a consumer electronics device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0007] The communications 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 communications networks, such as, for example, the CN 106, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be any of a base transceiver station (BTS), a Node B (NB), an eNodeB (eNB), a Home Node B (HNB), a Home eNodeB (HeNB), a gNode B (gNB), a NR Node B (NR NB), a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0010] More particularly, as mentioned above, the communications 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 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using Wideband CDMA (WCDMA). 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).

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

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

[0013] 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 from / to multiple types of base stations (e.g., eNBs and gNBs).

[0014] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless 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), or the like.

[0015] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT for facilitating wireless connectivity in a localized 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, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In 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-A Pro, NR, etc.) to establish either a small cell, a picocell, or a femtocell. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 through the CN 106.

[0016] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error resilience, reliability, data throughput, mobility, 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 not shown in FIG. 1A , it will be understood that the RAN 104 and / or CN 106 may be in direct or indirect communication with other RANs employing 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 NR radio technology, the CN 106 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.

[0017] 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 providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as TCP, User Datagram Protocol (UDP), and / or IP in the Transmission Control Protocol / Internet Protocol (TCP / IP) Internet protocol suite. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 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.

[0018] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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 over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may employ cellular-based wireless technology and may be configured to communicate with a base station 114b that may employ IEEE 802.11 wireless technology.

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

[0020] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) 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. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be incorporated together, for example, in an electronic package or chip.

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

[0022] 1B 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.

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

[0024] 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, etc. 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 home computer (not shown).

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

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

[0027] The processor 118 may further be coupled to other 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 peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripherals 138 may include one or more sensors, which 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 gesture sensor, a biometric sensor, and / or a humidity sensor.

[0028] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the uplink (e.g., for transmission) and the downlink (e.g., for reception) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and or substantially eliminating self-interference via either 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 that is for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the uplink (e.g., for transmission) or the downlink (e.g., for reception)).

[0029] 1C is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As mentioned above, the RAN 104 may employ 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.

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

[0031] Each of the eNodeBs 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, scheduling of users in the uplink (UL) and / or downlink (DL), etc. As shown in FIG. 1C, the eNodeBs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0032] 1C 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 above elements is shown as part of the CN 106, it will be understood that any one of these elements may be owned and / or operated by an entity other than the CN operator.

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

[0034] The SGW 164 may be connected to each of the eNodeBs 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-eNodeB handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

[0036] The CN 106 may facilitate communication 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 communication between the WTRUs 102a, 102b, 102c and legacy landline communication devices. For example, the CN 106 may include or 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. Additionally, 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.

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

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

[0039] 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 to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic during and / or from the BSS. Traffic to the STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within the BSS may be sent through the AP, e.g., where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA via a direct link setup (DLS). In some 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 the STAs within or using the IBSS (e.g., all of the STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

[0040] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an 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 width dynamically set via signaling. 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 some representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. In CSMA / CA, STAs (e.g., every STA), including the AP, can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0041] High-throughput (HT) STAs may use, for example, a 40 MHz wide channel for communication via a combination of a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0042] A very high throughput (VHT) STA can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz channel and / or an 80 MHz channel can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, sometimes referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be passed through a segment parser that can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to a medium access control (MAC) layer, entity, etc.

[0043] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. 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 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 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 can support meter-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices can have limited capabilities, including, for example, support for some and / or limited bandwidths (e.g., only support for that). MTC devices can include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0044] 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 primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a STA, from among all STAs operating in the BSS, that supports the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for a STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1 MHz mode, 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. For example, if a STA (that only supports 1 MHz operating mode) transmits to an AP such that the primary channel is busy, the entire available frequency band may be considered busy, even though most of the frequency band may remain idle and available for use.

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

[0046] 1D is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As mentioned 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.

[0047] The RAN 104 may include gNBs 180a, 180b, and 180c, although it will be understood 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 an 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 WTRUs 102a, 102b, and 102c. Thus, the gNB 180a may, for example, 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 to the WTRU 102a (not shown). 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 gNBs 180a and 180b (and / or 180c).

[0048] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerologies. 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 varying numbers of OFDM symbols and / or varying lengths of absolute time duration).

[0049] 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 can communicate with the gNBs 180a, 180b, 180c without accessing any other RAN (e.g., eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c can communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0050] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another via an Xn interface.

[0051] 1D 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. While each of the above elements is shown as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0052] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 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 WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c, for example, based on the type of service being utilized by the WTRUs 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, etc. 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 Wi-Fi.

[0053] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 106 via an N11 interface. The SMFs 183a and 183b may also be connected to the UPFs 184a and 184b in the CN 106 via an N4 interface. The SMFs 183a and 183b may 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 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.

[0054] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 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 UPFs 184a, 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.

[0055] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or 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. Additionally, 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 be connected to local data networks (DNs) 185a, 185b through UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0056] 1A-1D and the corresponding description thereof, one or more, or all, of the functions described herein with respect to any of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other element / device(s) described herein may be performed by one or more emulation elements / devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functionality.

[0057] The emulation device may 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 emulation devices may perform one or more, or all, functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more, or all, functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may perform testing using over-the-air wireless communication.

[0058] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test labs and / or test scenarios in non-deployed (e.g., test) wired and / or wireless communication networks to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may, for example, include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0059] 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, Replication, Elimination and Ordering PCE Path Computation Element PDU Packet Data Unit PEF packet removal function POF packet ordering function PREOF Packet Replication, Elimination, and Ordering Functions PRF packet duplication function ProSe Proximity Services PSE Route 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 communication V2X Vehicle to Everything WTRU Radio Transmit Receive Unit XR Extended Reality WG Working Group

[0060] Definition: - Deterministic Networking (DetNet): The IETF WG is responsible for defining data and control plane procedures to support deterministic networking in wired and wireless multi-hop networks. - Reliable and Available Radio (RAW): An extension of IETF DetNet that aims to ensure high reliability and availability for IP networks that utilize scheduled radio segments. - DetNet service sublayer: A sublayer that provides DetNet services to upper layers in the protocol stack and to applications. - DetNet Forwarding Sublayer: A sublayer that supports DetNet services to the underlying network. Packet Replication, Removal, and Ordering Function (PREOF): A function of the DetNet service sublayer. It includes: 1. Packet Replication Function (PRF): replicates packets 2. Packet Elimination Function (PEF): Eliminates duplicate packets 3. Packet Ordering Function (POF): Reordering packets in a DetNet flow - Route Computation Element (PCE): Generates alternative solutions for packet forwarding. - Path Selection Engine (PSE): Selects one of the solutions defined by the PCE to be used for each packet. - OODA (Observe, Orient, Decide, Act) Loop: A phase that is implemented during DetNet operation. 1. Observation phase: monitoring some or all hops along the track 2. Orientation Phase: Reporting Link Statistics to PCE 3. Decision Phase: The PSE decides which sub-track to use for the next packet(s) to be routed along the track. 4. Action Phase: PAREO data plane actions operate at the DetNet service layer to increase end-to-end transmission reliability. - DetNet Route: A route through the network that is designed to meet several performance guarantees, such as low latency, bounded jitter, and high reliability. The routes are established to ensure predictable and consistent network behavior. - DetNet Track: A network resource reserved for a specific DetNet path. The track is established to separate traffic in the DetNet path from other network traffic.

[0061] Figure 2 shows the DetNet data plane protocol stack. DetNet functionality is implemented in two adjacent sublayers in the protocol stack: DetNet service sublayer 201 and DetNet forwarding sublayer 202. DetNet service sublayer 201 provides DetNet services, e.g., service protection, to higher layers in the protocol stack and applications. DetNet forwarding sublayer 202 supports DetNet services in the underlying network, e.g., by providing explicit routes and resource allocation for DetNet flows.

[0062] The DetNet service sublayer includes a packet duplication function (PRF), a packet elimination function (PEF), and a packet ordering function (POF) for use in DetNet edge, relay node, and end system packet processing. These functions may be enabled at DetNet edge nodes, relay nodes, or end systems. The collective name for all three functions is the packet duplication, elimination, and ordering function (PREOF). The packet duplication and elimination service protection method involves a total of four capabilities. Sequencing information is provided to packets of DetNet composite flows. This can be done by adding a sequence number or timestamp as part of DetNet, or it can be inherent to the packet or associated with other physical characteristics, such as the exact time of receipt of the packet (and radio channel), for example, in a higher-layer protocol. This is typically done once at or near the source. The PRF replicates these packets to multiple DetNet member flows and typically sends them along multiple different paths to their destination(s). The PEF removes duplicate packets of a DetNet flow based on sequencing information and the history of received packets. The output of the PEF is a single packet. This can be done at any DetNet node along the path to conserve network resources further downstream, especially if multiple duplication points exist. The most common case is to perform this operation at the very edge of the DetNet network, preferably at or near the receiver. The POF uses sequencing information to reorder packets of a DetNet flow that are received out of order.

[0063] To implement PREOF, the DetNet service layer requires that the user data plane between DetNet nodes contain sequencing information and a service label, called an S-label. Based on time, resource reservation, and policy enforcement by a distributed shaper, DetNet aims to provide the capability to carry designated unicast or multicast data streams for real-time applications with extremely low data loss rates and bounded latency to support time-sensitive and mission-critical applications over converged enterprise infrastructures. Wireless systems operating over shared media can experience unpredictable behavior due to the inherent volatile nature of wireless communications. Therefore, the wireless medium can present significant challenges to achieving deterministic characteristics such as very low packet error rates, bounded consecutive loss, and bounded latency.

[0064] Reliable and Available Radio (RAW) refers to an extension of the IETF DetNet concept with the purpose of ensuring high reliability and availability for IP networks that utilize frequency / time shared physical medium resources with probabilistic traffic, such as scheduled radio segments and other functionalities, e.g., IEEE Standard 802.15.4 Time Slotted Channel Hopping (TSCH), 3GPP features targeting 5G Ultra Reliable Low Latency Communications (URLLC), IEEE 802.11ax / be, and L-Band Digital Aviation Communications Systems (LDACS). Like DetNet, RAW technology aims to remain abstract to the lower radio layer and addresses Layer 3 aspects that support applications requiring high reliability and availability. The term DetNet is used herein to refer to IETF DetNet technology, including its extension to RAW.

[0065] The DetNet architectural framework summarizes key DetNet operations as follows: DetNet distinguishes between long and short forwarding timescales, where the long timescale is used for route computation and the short timescale is used for per-packet forwarding decisions. DetNet operates in the network plane at the forwarding (short) timescale on one DetNet flow over a complex path called a "track." A track represents network resources reserved along the path that are dedicated to DetNet traffic. Tracks are established to isolate traffic in the DetNet path from other network traffic with the objective of guaranteeing several QoS requirements, such as low latency, bounded jitter, and high reliability. Tracks are established and installed in advance by means outside of DetNet, and can be strict or loose, depending on whether each hop or only a subset of hops is observed and controlled by DetNet. Subtracks are "tracks within tracks."

[0066] The DetNet architecture is built as an OODA (Observe, Orient, Decide, Act) 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 in the recovery graph by instantiating the OODA phases: Observe, Orient, Decide, and Act.

[0067] The DetNet network has two timescales: the route computation timescale, which is the timescale over which complex routes are (re)computed, and the route selection timescale, which is the timescale over which forwarding decisions are made for one or a few packets. DetNet functions to perform route selection on a packet-by-packet basis, with the goal of providing reliable and available service while minimizing the waste of constrained resources. For example, a PCE can generate alternative solutions during routing, and one solution is selected through the DetNet loop. To that effect, DetNet defines a PSE, equivalent to a PCE, to perform rapid local adjustments of the forwarding table within the diversity selected by the PCE for the track. The PSE enables the use of PAREO to exploit more abundant forwarding capacity and schedule transmissions on a faster timescale.

[0068] In the observation phase, network plane measurement protocols for operations, administration, and maintenance (OAM) monitor some or all hops along the track and end-to-end packet delivery. In the direction phase, controller plane elements report link statistics to a path computation element (PCE) in a centralized controller, which computes and establishes the track and provides metadata for directing routing decisions. In the decision phase, a runtime distributed path selection engine (PSE) determines which sub-track to use for the next packet(s) to be routed along the track. In the action phase, packet (hybrid) ARQ, duplication, elimination, and ordering (PAREO) data plane actions operate at the DetNet service layer to increase the reliability of end-to-end transmission. The DetNet architecture also accommodates piggybacking signaling (i.e., signaling sent in data packets) when decisions are made by nodes on the path down the track from the PSE. The overall OODA loop optimizes the use of redundancy to achieve the necessary reliability and availability to maintain service level agreements (SLAs) while minimizing the use of constrained resources such as spectrum and batteries.

[0069] A path computation element (PCE) generates alternative solutions, and one solution is chosen to be used for each packet to provide reliable and available service while minimizing waste of constrained resources. DetNet defines a path selection function (PSE), equivalent to a PCE, to perform rapid local adjustments of forwarding tables within the diversity the PCE selects for tracks. The PSE utilizes packet (hybrid) ARQ, duplication, elimination, and ordering (PAREO) to exploit richer forwarding capacity and enable scheduled transmissions on faster time scales.

[0070] In contrast to the above definition of a path, a "track" is not necessarily linear. It can include multiple paths that can branch and recombine, for example, to enable DetNet PAREO operation. In DetNet terminology, a track has the following properties: it has one ingress node and one egress node that operate as DetNet edge nodes; it is reversible, meaning that packets can be routed against the flow of data packets (e.g., to carry OAM measurements or control messages 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 topology edges of the graph are serial sequences of DetNet transit nodes that operate at the DetNet forwarding sublayer. A DetNet PSE selects a subtrack for each packet or group of packets to provide the desired reliability for the transported flow.

[0071] 3GPP introduced the 5G NR sidelink (SL) in Release 16 to enable nearby devices to communicate directly with each other without packets passing through the 3GPP network. The device-to-device (D2D) direct communication protocol allows two devices to communicate directly between themselves, with or without network assistance. Different scenarios exist for D2D communication depending on whether the UEs involved are within the coverage of a cellular network. Targeted applications include mission-critical services, vehicle-to-everything (V2X) services, and the Industrial Internet of Things (IIoT). D2D communication promises ultra-low latency links and is therefore an attractive solution for various emerging applications such as AR, VR, and XR.

[0072] Within the scope of D2D, two technologies are generally supported in 3GPP standards: 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 made possible by the D2D Discovery and D2D Direct Communication procedures. The discovery procedure allows a UE to discover other UEs in its proximity, which can be performed by the UE directly or through the network. The group communication procedure enables one-to-many communication between UEs in a very resource-efficient manner, allowing messages to be easily spread to large groups of people on a common stream.

[0073] The concept of packet data unit (PDU) sets was first introduced to 3GPP in research on XR (Extended Reality) and media services. A PDU set contains a set of interrelated PDUs grouped together, allowing them to be treated similarly (e.g., PDUs containing data belonging to the same video frame). The definition of a PDU set, as defined in 3GPP TR23.700-60 V1.2.0, is as follows: A PDU set consists of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g., a frame or video slice for XRM services, as used in TR26.926). In some implementations, all PDUs in a PDU set are required by the application layer to use the corresponding unit of information. In other implementations, the application layer can still recover some or all of the information unit even when some PDUs are missing.

[0074] There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks. Relevant examples are, for example, extended reality (XR) and multimodal applications, such as immersive gaming and digital twins. In these environments, UEs require strict and predictable behavior in terms of latency and / or resilience and / or availability and / or throughput while they move and may change their attachment points. As described in the previous paragraph, a multimodal application is an application that can include several modalities of communication, such as audio, video, and haptics. Thus, a multimodal application can be decomposed into multiple smaller functions, which can be distributed in the network to run on cooperating devices (e.g., WTRUs, UEs) and / or infrastructure nodes (e.g., nodes at the edge or cloud). Communication between the devices and the infrastructure nodes is via a multimodal communication link, which can be a communication link that can be used by a DetNet-enabled flow, i.e., a link over which DetNet mechanisms can be enabled.

[0075] Figure 3 shows an example of communications involving multiple cooperating devices and different locations in an infrastructure. The devices are called "cooperative" because they cooperate to forward the same or different packets of a multimodal flow to their destination. A given application can have multiple functions (or components) 301, each of which runs at different locations, both on the terminal 302 and on the infrastructure side 303, 304. UEs utilize device-to-device / sidelink communications 305 to communicate between them. New solutions are needed to enable UEs to decompose applications into different functions that can run on these distributed nodes (including other UEs 302 and infrastructure nodes 303, 304, such as edge / cloud 304) in a manner that guarantees the reliability and availability requirements of each of the involved nodes across multiple network segments and transports.

[0076] Typically, traffic and QoS requirements are addressed at a session / flow granularity. This limits the system's ability to meet QoS requirements, especially in scenarios where applications require strict latency requirements and the inherent volatile nature of device-to-device communications involves 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 multihop networks. DetNet capabilities enable the network to consider all available paths when determining the most preferred path for forwarding data, taking into account runtime conditions. It also allows traffic forwarding decisions to be made at the packet level, allowing for more dynamic changes at a finer granularity.

[0077] UEs can cooperate to support distributed multimodal / XR traffic by providing reliability and availability to multiple flows. Procedures may be defined for cooperative UEs to support multimodal traffic. Extensions to ProSe signaling and to UE and ProSe policies can enable the simultaneous use of multiple sidelink channels to support such applications. Messages may be exchanged between UEs to enable multiple cooperative UEs to use multiple sidelink channels in a manner that guarantees a given QoS in terms of reliability and availability. Various exemplary functional blocks and method phases are described in terms of their functionality or logical blocks. Whether such functionality is implemented as hardware, software, or a combination of both depends on the particular application and design constraints imposed on the overall system. The exemplary procedures described for various embodiments may be described as functions with phases that follow a particular order, although the particular order is for clarity only. Thus, in different implementations, some phases may be performed in a different order, some phases may be skipped or may not be present in all embodiments, and some phases may be added (and may not be shown herein). Similarly, parameter, message, and procedure names used herein are for purposes of clarity only and may differ in different implementations.

[0078] FIG. 4 shows an example of an authorization procedure that may be used by a UE for combined ProSe and DetNet authorization. At 401, UE(s) participating in multimodal / XR applications may register with a 5G system. The UE may indicate multimodal / XR application functionality 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 (see Section 4.2.2.2.2 of 3GPP TS23.502 V17.3.0 for general registration messages). Optionally, a new registration message may be defined that includes one or more IEs with multimodal / XR application functionality support. In another example, a new procedure may be defined for a UE to communicate its multimodal / XR application functionality support and DetNet capabilities to the network. Information sent by the UE to the network related to multimodal / XR application functionality support may include one or more multimodal / XR applications supported by the UE(s). For example, DetNet capabilities may be included in the "5GMM Capabilities" IE in the Registration Request message (see Release 18 of 24.501 as an example). Multimodal / XR application functionality support may also indicate the UE's intent to join an existing group that already supports one of such applications, for example, via an application identity (App ID).

[0079] To request a ProSe policy, the UE uses the 5G ProSe Policy Provisioning Request IE in a Registration Request message or during a UE-triggered 5G ProSe Policy Provisioning procedure (as defined in clause 4.3.1 in 3GPP TW23.304 V17.0.0). 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) along with existing parameters for 5G ProSe Direct Discovery and other ProSe features. The 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); (c) packet and PDU set level switching / forwarding / routing capabilities (e.g., packet level switching enabled by the PSE, allowing for much faster switching of paths / tracks / subtracks); (d) information related to multimodal flows (e.g., QoS requirements of each flow, application modality type [audio, video, haptic]) or application ID may be used by the network to determine the QoS requirements of application layer traffic and make resource reservation decisions; (e) duration, or when DetNet and ProSe / sidelink communication links may be required, this may be specified as a duration, or along with start / end times, or along with the geographical location where DetNet and ProSe / sidelink services are required.

[0080] New procedures may be defined to exchange DetNet capabilities and policies between a UE and a network, or between different UEs. The network can send its DetNet capabilities and traffic policies, referred to herein as DetNet configuration, to the UE. The DetNet configuration may be sent autonomously, i.e., the UE does not request it; it may be sent, for example, during UE authorization registration. Optionally, the configuration may be sent to the UE in response to an explicit request from the UE.

[0081] At 402 in FIG. 4, the UE may perform an authorization procedure with the network, more specifically with the PCF (e.g., PCF via AMF over the N1 interface). Optionally, the UE may perform an authorization procedure with the ProSe application server over the PC1 interface. The UE may send or receive an authorization message to / from the 5GC (i.e., PCF via AMF over the N1 interface) or through the ProSe application server over the PC1 interface. The UE may be pre-configured with a ProSe+DetNet configuration, and the 5GC (e.g., PCF) may send an authorization message with a list of PLMNs / networks / geolocations / cells where the UE can use ProSe discovery and direct communication and the DetNet configuration. If there is no associated UE context, subscription information may be captured (e.g., through UDM). The UE may send an authorization request to the network to obtain permission to use the ProSe+DetNet capability within the specified PLMNs / networks / geolocations / cells. For example, ProSe+DetNet capabilities may be specified as packet-level path / track / subtrack switching and availability of a locally hosted PSE.

[0082] The authorization message may include information related to the time for which ProSe communication is valid, such as duration or start and / or end time. The authorization message may include information related to authorization of ProSe discovery and direct communication (e.g., including parameters such as the authorization policy described in Section 5.1.3 of 3GPP TS23.304 V17.0.0) and information related to authorization of DetNet services (e.g., geographic areas requiring privacy support, list of ProSe identifiers with authorized PLMNs). The authorization message may include new IEs to enable authorization of new DetNet capabilities based on existing service authorization for ProSe, and optionally, existing procedures may be extended to enable authorization of new DetNet capabilities. Such new capabilities may include: (i) an indication of whether DetNet features are enabled, or the UE / 5GC may not include this explicit indication, but may be able to achieve authorization for DetNet functionality based on the following parameters: (ii) Hosted DetNet functionality, which may indicate DetNet functionality (e.g., PSE) that may be hosted by the UE to provide services to other network entities; (iii) Path Switching Capability, which may indicate whether the UE supports dynamic path / track switching, and if so, at what level the switching may be performed (e.g., packet, PDU, PDU set); and (iv) DetNet domains of interest to the application and domain IDs of interest, which may allow the domain to be restricted to only some UEs.

[0083] The grant message may include information related to the multimodal flow (e.g., QoS requirements for each flow, application modality type [audio, video, haptic]), or the UE may provide an application ID that is used by the network to determine QoS requirements and make resource reservation decisions for application layer traffic.

[0084] The authorization message may contain authorization information required for DetNet network operation. This may use either subscription data, existing authorization mechanisms of 5GS, or an external authorization system (if some services of DetNet are provided externally). Such information may include, but is not limited to, authorization to host DetNet functions (e.g., PSE), authorization to perform switching at either packet and PDU level, and authorization to provide DetNet services to other UEs (e.g., acting as ProSe+DetNet relay UEs).

[0085] In some scenarios, 402 in Figure 4 may be triggered by 401. In 403, the UE may receive a configuration message including any combination of the information specified in 402. In scenarios where only partial information is sent to the UE in 402, the remaining information, along with authorization for ProSe discovery, may be sent through an Authorization and Policy Provisioning message 403, which 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 establishment of flows using DetNet capabilities, applying DetNet services on flows forwarded through the UE, forwarding / routing / switching flows between UEs or between the UE and the network, or authorization to use other DetNet features for portions / segments of the DetNet network as described herein (e.g., only some DetNet domains may be authorized to be used, while other domains enabling lower latency and higher bandwidth may be accessible only to higher tier subscribers).

[0086] In Figure 4, the procedures related to the DetNet PCE may be implemented as an extension to the PCF and / or deployed alongside the PCF. The DetNet PSE functionality may be hosted in whole or in part by the UE used by multimodal applications.

[0087] Figure 5 shows a summarized example of a multimodal link establishment procedure. After the registration, authorization, and policy negotiation 500 described above, the UE can initiate the establishment procedure. The UE indicates QoS application requirements to the AF / AS 501. The QoS requirements may include DetNet extension parameters, including at least one of bounded latency, reliability, and availability requirements associated with the multimodal application. Latency refers to the one-way end-to-end latency. Availability refers to the total percentage of time that the service is available for "intended" use, i.e., can meet the required QoS. Reliability is the percentage of operating time that the service is operating "as intended," i.e., meeting the required QoS.

[0088] The AF / AS can forward the information to the PCF / PCE 502. The PCF / PCE can implement UE QoS policy updates, including DetNet extension policies 503. The UE can establish both ProSe and DetNet communication links as needed to satisfy the QoS requirements of the multimodal application 504. The UE can use the QoS policies to implement per-packet forwarding decisions, ensuring that QoS application requirements are met 505.

[0089] Figure 6 shows another example procedure for multimodal sidelink operation. A UE (UE1) may be aware of other UEs in its vicinity with which sidelink communication may be established and which are capable of instantiating multiple functions that may be part of a multimodal / XR application 600. 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 procedure.

[0090] If the ProSe open discovery procedure is used (Model A), all UEs capable of instantiating the capabilities of a specific multimodal / XR application send a ProSe discovery announcement message over the PC5 reference point announcing their capabilities. A ProSe application code / ID can be defined to identify the specific multimodal / XR application, which can then be used by UE1 to identify suitable UEs in the vicinity when monitoring. This message can include an indication of the specific DetNet services supported by each individual UE. If the ProSe restricted discovery procedure is used (Model B), UE (UE2) (and all other UEs) can obtain authorization for restricted discovery. UE1 sends an announcement message over the PC5 interface targeting UEs capable of instantiating the capabilities of the multimodal / XR application. The application can be identified by the ProSe application code, obtained during authorization or during a separate procedure with the network. This message can include an indication of the DetNet services supported by each individual UE. The UE can identify which detected UEs support DetNet extensions. A UE that does not support DetNet may be used to transmit only non-DetNet traffic.

[0091] The UE can take into account other UEs and the infrastructure to determine how to separate the application into different components / flows and where they should be instantiated 601. The UE can take into account different computing and connectivity requirements.

[0092] The UE or application function (AF) requests instantiation of multiple functions, including a service, 602. This message may be an application layer message sent by a service enabler client in the UE to the AF. Alternatively, it may be part of a PDU session establishment or PDU session modification procedure and may include additional DetNet parameters related to the link to be established with another UE, namely: (a) packet and PDU set-level switching / forwarding / routing capabilities, including packet-level switching enabled by the PSE, which allows for much faster switching of paths / tracks / subtracks; (b) information related to multimodal flows, including QoS requirements for each flow, application modality type [audio, video, haptic]; and (c) duration of communication, or when DetNet and ProSe / sidelink communication links may be needed. The communication link duration may be given as a start time and end time, or a start time and length of time. The start time may be relative to another time known to all UEs, such as a frame number, slot number, or symbol number. The start time may be relative to the end time of another procedure, such as a discovery procedure. Additional parameters may include the geographical location where DetNet and ProSe / sidelink services are required.

[0093] The orchestrator / controller entity can instantiate different functions 603. The orchestrator / controller can send messages to other UEs and / or service enabler clients hosted in the network infrastructure, including, for example, the identities of these UEs / infrastructure nodes, which may be known either by the requesting UE or the AF. An example of an orchestration framework is that defined by ETSI NFV. The orchestrator can handle application components. In some implementations, 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)).

[0094] The UE may indicate application requirements for QoS to the AF / AS 604. The QoS policy request may include DetNet extension parameters, including at least one of bounded latency, reliability, and availability requirements, associated with a set of network flows associated with the multimodal application. The UE may also indicate QoS requirements for each individual single-modal flow. The UE may provide an application ID that the AF / AS can map to a set of QoS requirements.

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

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

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

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

[0099] The PCF may be aware of different network nodes, their capabilities, and UE sidelinks. The PCF can store information received from the PCE and generate routing path computation rules, which are rules that enable the UE to derive a preferred path (including tracks and subtracks) for each flow for all or a subset of links (including sidelinks and Uu). The PCF can generate rules for deriving QoS rules and profiles for flows sent over the sidelink. The PCF can generate PCC rules for PDU sessions associated with the same application. The PCF / PCE can perform UE policy updates 609. The updates can be performed by sending a Manage UE Policy Command message to the UE, which is returned in a Manage UE Policy Complete message from the UE. These messages include URSP rules or ProSe Policy (ProSeP) rules for the UE(s), which are extended to include DetNet extended policies. The DetNet extended policies can include support for message or packet duplication, message or packet merging, and network coding for additional reliability. The extension may include, for example, a track ID, PREOF / PAREO rules to apply to the traffic, and network coding policies to apply to the traffic. The NEF / PCF may reply 610 to the AF / AS with a Nnef_AFsessionWithQoS notification message.

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

[0101] The UE(s) can make per-packet forwarding decisions to ensure the QoS desired by the service based on the policy and associated rules 612. These decisions can include complex forwarding schemes, such as overlap and merge, employing DetNet mechanisms, as well as network coding. This can require the use of DetNet data plane mechanisms (e.g., RFC 8939) or extensions of the 3GPP data plane to include information that allows DetNet flows to be identified. The UE(s) are acting as PSE entities as defined by the DetNet architecture.

[0102] When multimodal communications involve infrastructure-hosted functions (either at the mobile network edge / core or in external data networks), DetNet data plane mechanisms can be used to provide end-to-end reliable communications. This can include, by way of non-limiting example, the use of IP data plane mechanisms (as specified in RFC 8939), extensions to other encapsulation mechanisms to include service labels (S-labels).

[0103] Traffic is now exchanged between different nodes as determined by the PSE functionality running on the UE. Non-limiting examples of packet forwarding decisions made by the UE include dynamic selection of a path (track) to use based on local context information, duplication of packets and transmissions over multiple paths (tracks) (by source and / or intermediate UEs), merging of traffic received over multiple paths (tracks) (by intermediate and / or destination UEs), and application of network coding policies. Sufficient monitoring tools should be deployed to detect / predict potential disruptions in the agreed-upon QoS and react as quickly as possible.

[0104] While Figure 6 illustrates a UE-triggered or UE-controlled approach, this is provided by way of example and not limitation. For example, an AF in the network infrastructure may also trigger / control the procedure. Examples of messages that may originate from the AF are shown at 602 and 604 in Figure 6 and in the associated description above. [Industrial Applicability]

[0105] Enables reliable and available wireless communication.

Claims

1. 1. A method implemented by a wireless transmit / receive unit (WTRU), comprising: sending WTRU capabilities, including WTRU multimodal communication capabilities, to a network; sending multimodal application Quality of Service (QoS) requirements to an Application Function (AF) associated with said network; receiving, from the network, multimodal policies and configuration parameters associated with multimodal operation; establishing a direct link with one or more WTRUs based on the received multimodal policy; determining, for each packet, which multimodal policy to apply to each packet and which communication link to use to send each packet; A method for providing the above.

2. The WTRU multimodal communication capability comprises: DetNet related functions (e.g., PSE functions) hosted by the UE; and Packet and PDU set level routing capabilities; information related to supported multimodal applications, including QoS requirements, supported application modality types, and / or supported application identities; the time or duration for which a multimodal communication link may be required; Geographic locations where multimodal communication links may be required; 10. The method of claim 1, comprising one or more of:

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

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

5. 10. The method of claim 1, wherein the WTRU multimodal communication capability includes a request for network permission for the WTRU to exercise the multimodal communication capability.

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

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

8. The method of claim 1 , wherein the multimodal QoS requirements include geographic locations in which the multimodal links are required to operate.

9. 2. The method of claim 1, wherein the multimodal policy and configuration parameters include DetNet policies and configurations including at least one of track identification information, packet duplication, elimination, and ordering function (PREOF) information, packet (hybrid) ARQ, duplication, elimination, and ordering (PAREO) information, and / or network coding policy information.

10. 10. The method of claim 1, wherein the communication link to use to send each packet includes at least one of a Proximity Services (ProSe) communication link, a DetNet communication link, and / or a direct communication link to the network.

11. 1. A wireless transmit / receive unit (WTRU), comprising: a processor; Communication interface and Equipped with 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 multimodal application quality of service (QoS) requirements to an application function (AF) associated with the network; the processor and the communication interface are configured to receive, from the network, multimodal policies and configuration parameters associated with multimodal operation; the communication interface is configured to establish a direct link with one or more WTRUs based on the received multimodal policy; The processor is configured to determine, for each packet, which multimodal policy to apply to each packet and which communication link to use to send each packet. WTRU.

12. The WTRU multimodal communication capability comprises: DetNet related functions (e.g., PSE functions) hosted by the UE; and Packet and PDU set level routing capabilities; Information relating to supported multimodal applications, including QoS requirements; and information related to the supported multimodal applications, including QoS requirements, supported application modality types, and / or supported application identities; and the time or duration for which a multimodal communication link may be required; Geographic locations where multimodal communication links may be required; 12. The WTRU of claim 11, comprising one or more of:

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 capabilities information element (IE).

15. The WTRU of claim 11 , wherein the WTRU multimodal communication capability includes a request for network permission for the WTRU to exercise the multimodal communication capability.

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 requirements include a time window during which a multimodal link is required to operate.

18. The WTRU of claim 11 , wherein the multimodal QoS requirements include a geographic location in which a multimodal link is required to operate.

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

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

Images