Method and network node for delay-aware scheduling of protocol data unit (PDU) flow collection

Abstract

Methods and apparatus for delay aware scheduling of protocol data unit (PDU) flow collection are described herein. A method implemented in a network node includes receiving a message including first information indicating at least one quality of service (QoS) flow of a wireless transmit / receive unit (WTRU), the at least one QoS flow associated with an amount of traffic transmitted to or received from a device of a tether; receiving one or more protocol data units (PDUs) associated with the at least one QoS flow; and prioritizing transmission of the one or more PDUs over PDUs associated with other QoS flows based on the received one or more PDUs being associated with the device of the tether. The method includes calculating a delay value for the one or more PDUs or one or more sets of PDUs as a function of at least one of: RAT, data delay value, jitter value, packet loss rate, or bit rate.

Description

Cross-references to related applications

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 529,082, filed July 26, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] Consumer devices that can be hooked to a Wireless Transmit / Receive Unit (WTRU) for wireless access via a cellular network, such as a 3GPP network, e.g., 3G, LTE, or 5G, are typically used. In such devices, applications can run on the hooked device, which can use the WTRU to exchange data with an Application Server (AS). Multiple devices can be hooked to the same WTRU. For example, a person might be using headphones and a smartwatch; the headphones and smartwatch can be hooked to their smartphone simultaneously, and each application running on one of the hooked devices can send and / or receive data in the form of Protocol Data Units (PDUs), PDC sets, or similar protocols.

[0003] Extended reality (XR) applications (such as augmented reality (AR), virtual reality (VR), or mixed reality (MR) applications, to name a few) typically run on devices tethered to a WTRU. In an XR context, users running VR applications can use a Universal Serial Bus (USB) connection to tether a VR headset to their smartphone or other WTRU, and can use a Bluetooth connection to tether a haptic kit to the same smartphone or other WTRU. A WTRU can provide connectivity for multiple XR applications, and each XR application can receive a data stream as part of a PDU set.

[0004] When a WTRU is hosted on an application running on a connected device, there can be a non-negligible delay between the time the WTRU receives data and the time the application receives the data. For example, when the WTRU (e.g., a smartphone) receives downlink data, there can be a non-negligible delay between the data between the WTRU and the application, for example, via Bluetooth. Radio access between the WTRU and the application server can be via a radio access network (RAN), such as a 5G RAN. 5G systems support application programming interfaces (APIs) that allow application servers to configure QoS requirements for data flows. However, the application server may not be aware that the WTRU application is hosted on a connected device, and the associated traffic may therefore cause latency on the connected connection. Therefore, signaling enhancements are needed to assist the RAN in making scheduling decisions. Summary of the Invention

[0005] This document describes a method and apparatus for delay-aware scheduling of Protocol Data Unit (PDU) set streams. In one aspect, a method implemented in a network node may include receiving a message including first information indicating at least one Quality of Service (QoS) stream from a Radio Transmit / Receive Unit (WTRU), wherein the at least one QoS stream is associated with traffic transmitted to or received from a tethered device. The method may include: receiving one or more Protocol Data Units (PDUs) associated with the at least one QoS stream; and prioritizing the transmission of the one or more PDUs over PDUs associated with other QoS streams based on the association of the received one or more PDUs with the tethered device. The message may be a QoS profile configuration message and may include information indicating at least one of a Radio Access Technology (RAT), a data delay value, a jitter value, a packet loss rate, and a bit rate associated with the WTRU and the tethered device. In another aspect, the method may include calculating a delay value for the one or more PDUs or a set of one or more PDUs based on at least one of the following: the RAT, the data delay value, the jitter value, the packet loss rate, or the bit rate. In one or more aspects, the QoS profile configuration message includes multiple QoS profiles, each of which has a different data delay value. In yet another aspect, the method may include: receiving an index from the WTRU corresponding to a new data delay value based on a change in delay between the WTRU and the linked device; and selecting one of the multiple QoS profiles that includes the new data delay value corresponding to the index received from the WTRU. The method may include: determining at least one Connection Mode Discontinuous Receive (CDRX) timer value for the WTRU based at least on second information in the QoS profile configuration message; and sending the determined at least one CDRX timer value to the WTRU. In one aspect, the linked device is at least one of a Terminal Equipment (TE) portion of the WTRU or a remote device configured to communicate with the WTRU via a communication link different from the radio access network interface between the network node and the WTRU. The method may further include preferentially transmitting the one or more PDUs by mapping the one or more PDUs associated with the linked device to a DRB with a higher priority than the DRB used for PDUs not associated with the linked device.

[0006] Aspects and characteristics may be applied to a network node including a transceiver and a processor, wherein the transceiver and the processor are configured to: receive a message including first information indicating at least one Quality of Service (QoS) stream of a Radio Transmit / Receive Unit (WTRU), the at least one QoS stream being associated with traffic transmitted to or received from a tethered device; receive one or more Protocol Data Units (PDUs) associated with the at least one QoS stream; and, based on the association of the received one or more PDUs with the tethered device, prioritize the transmission of the one or more PDUs over PDUs associated with other QoS streams. In some aspects, the message may be a QoS profile configuration message and may include information indicating at least one of a Radio Access Technology (RAT), data latency value, jitter value, packet loss rate, and bit rate associated with the WTRU and the tethered device. Attached Figure Description

[0007] A more detailed understanding can be obtained from the following description given with reference to the accompanying drawings, in which the same reference numerals in the figures denote the same elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system that can implement one or more of the disclosed embodiments; Figure 1B This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shown is of an example wireless transmit / receive unit (WTRU) used in the communication system. Figure 1C This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system shown. Figure 1D This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shown illustrates another example RAN and another example CN used within the communication system. Figure 2 An example signaling path between the WTRU and the data network is shown; Figure 3 This is a system diagram illustrating an example of multiplexing a set of PDUs from multiple applications within a single QoS stream; Figure 4 This is a signal diagram illustrating an example of the delay offset calculation process for a tethering device; and Figure 5 This is a flowchart of an example method for delay-aware scheduling of PDU aggregation streams implemented in a network node. Detailed Implementation

[0008] The following abbreviations may be used in this article.

[0009] 5G 5th generation ACK confirmation AF application functions AS Application Server DL downlink DRB Data Radio Bearer NACK negates ACK MCS modulation and coding scheme MT mobile terminal NR New Radio OFDM (Orthogonal Frequency Division Multiplexing) PCC Strategy and Charging Control PDR Grouping Detection Rules PDU Packet Data Unit RAN Radio Access Network RNTI Radio Network Identifier RRC Radio Resource Control RRM Radio Resource Management RSSI Received Signal Strength Indicator RTP Real-Time Transport Protocol SDF service data flow SDP Session Description Protocol SDU Service Data Unit TE terminal equipment TRP Transmit / Receive Point TSC Time-Sensitive Communication TSN Time-Sensitive Networking UL uplink UPF User Plane Functions URLLC Ultra-Reliable Low-Latency Communication WLAN (Wireless Local Area Network) and related technologies (IEEE 802.xx domain) WTRU Wireless Transmit / Receive Unit Figure 1AThis diagram illustrates an example communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through shared system resources including wireless broadband. For example, the communication system 100 can employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0010] like Figure 1A As 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 understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 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), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0011] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), node Bs, eNodeBs (eNBs), master node Bs, master eNodeBs, next-generation node Bs such as gNode Bs (gNBs), new radio (NR) node Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0012] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio 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 coverage for a specific geographic area that may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In embodiments, 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.

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

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

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

[0016] In this embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies, such as using NR to establish NR radio access for air interface 116. NR is a radio access that can be used with 5G.

[0017] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use the dual connectivity (DC) principle to jointly implement LTE radio access and NR radio access. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0018] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global System for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0019] Figure 1A Base station 114b can be, for example, a wireless router, master node B, master eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-a, LTE-a Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106.

[0020] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can 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. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although... Figure 1AAs not shown, but will be understood, RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104. For example, in addition to connecting to RAN 104, which may be utilizing NR radio technology, CN 106 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0021] CN 106 can also serve as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

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

[0023] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving 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 peripheral devices 138, etc. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing elements.

[0024] Processor 118 can 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. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

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

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

[0027] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via various RATs (e.g., such as NR and IEEE 802.11).

[0028] The processor 118 of WTRU 102 can be coupled to and 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) unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 can access information and store data from any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. 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. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access information and store data from memory not actually located on WTRU 102, such as on a server or home computer (not shown).

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

[0030] 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) about 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) via 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 understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0031] The processor 118 can also be connected to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth® module, FM radio unit, digital music player, media player, video 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. Sensors may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0032] WTRU 102 may include a full-duplex radio, wherein some or all of the transmission and reception of signals (e.g., associated with a specific subframe of 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 via hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio, wherein some or all of the transmission and reception of signals (e.g., associated with a specific subframe of both UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0033] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0034] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

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

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

[0037] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0038] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to or from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during eNode-B handover, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0039] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0040] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or be able to communicate with it, serving as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0041] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that, in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

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

[0043] A WLAN in Infrastructure Basic Services 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 access a distribution system (DS) or another type of wired / wireless network that loads traffic into and / or loads traffic out of the BSS, or have an interface to it. Traffic originating outside the BSS destined for a STA can be delivered to the AP via it. Traffic from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between a source STA and a destination STA using a direct link setup (DLS) (e.g., directly between them). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

[0044] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access - Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (e.g., every STA), including the AP, can sense the primary channel. If a particular STA senses / detects that the primary signal is busy and / or determines that the primary signal is busy, that particular STA can back off. In a given BSS, at any given time, only one STA (e.g., only one station) can transmit.

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

[0046] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. In the 80+80 configuration, data, after channel coding, can be passed through a fragment parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0047] 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 compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (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 instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0048] 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 the primary channel. The primary channel can have a bandwidth 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 STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), 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 Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to STAs (which only support the 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even if most available frequency bands remain idle.

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

[0050] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0051] RAN 104 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be located on unlicensed spectrum, while the remaining component carriers may be located on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0052] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can be varied for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various or scalable lengths or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or absolute times of varying durations).

[0053] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobile anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c while also communicating / connecting with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

[0054] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0055] Figure 1DThe CN 106 shown 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. Although the foregoing elements are described as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0056] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types being used by WTRU 102a, 102b, and 102c. For example, different network slices can be created for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between 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).

[0057] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. 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. PDU session types can be IP-based, non-IP-based, or Ethernet-based.

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

[0059] CN 106 can facilitate communication with other networks. For example, CN 106 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 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, WTRUs 102a, 102b, and 102c can be connected to DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and local DNs 185a and 185b.

[0060] Given Figures 1A to 1D and Figures 1A to 1D The corresponding descriptions can be performed by one or more emulation devices (not shown) that perform one or more of the functions described herein with respect to: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other devices described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

[0062] One or more simulation devices may perform one or more functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, a simulation device may be used to test scenarios in a laboratory and / or undeployed (e.g., under test) wired and / or wireless communication networks to enable testing of one or more components. One or more simulation devices may be test equipment. The simulation device may transmit and / or receive data using direct RF connection and / or wireless communication via an RF circuit system (e.g., which may include one or more antennas).

[0063] Generally, a device linked to the WTRU is one that communicates with the WTRU via a connection different from the RAN. For example, the RAN may be part of a 5G network, and the device linked to the WTRU may communicate with the WTRU using, for example, a Bluetooth or Wi-Fi connection. Therefore, applications running on the linked device can use the linked connection to send and / or receive data via the RAN. However, as used herein, "linked" can be used more broadly to also include scenarios where applications run on the WTRU itself. For example, the WTRU may include a Mobile Terminal (MT) portion and a Terminal Equipment (TE) portion. The MT portion may include logic or processing capabilities that may include radio transmission / signaling and reception. The TE portion may provide services to users of the WTRU and may include logic or processing capabilities for running applications and interfacing with applications running on the linked-to-WTRU device. The TE and MT portions of the WTRU can communicate via an API using Attention (AT) commands. If an application runs on a device or the WTRU, it can be said that the device or the WTRU hosts the application.

[0064] Examples of tethered links may include, for example: a communication link between an application hosted on the WTRU and the WTRU; a communication link between an application hosted on the WTRU and the WTRU, wherein the application hosted on the WTRU runs in the TE section of the WTRU; and / or a communication link between an application hosted on the WTRU and the WTRU, wherein the application hosted on the WTRU runs on a device separate from the WTRU. For example, the WTRU may be a smartphone, and the application hosted on the WTRU may run on a device communicating with the WTRU via a Bluetooth or Wi-Fi link.

[0065] A WTRU can provide connectivity for multiple applications, such as XR applications. Each application can receive a data stream as part of a PDU set. Applications using the WTRU for connectivity can be hosted in the TE section of the WTRU or can be hosted devices tethered to the WTRU. For example, when using a VR application, a user can tether a VR headset (USB) and a haptic kit (Bluetooth) to the WTRU. Therefore, the tethering scenario can be generalized to the WTRU running multiple applications that support traffic sent in the form of PDU sets.

[0066] When the WTRU receives data flows associated with different applications, each data flow may contain a set of PDUs, and each data flow may have the same QoS requirements. In this scenario, the network can multiplex each data flow onto the same QoS flow. This is likely desirable because the QoS framework of 5G systems is designed so that QoS flows are intended to carry traffic from Service Data Flows (SDFs) with similar QoS characteristics. However, there are overheads associated with using a larger number of QoS flows. For example, at User Plane Function (UPF) or Next Generation Radio Access Network (NG RAN) nodes, there is overhead associated with QoS monitoring for each QoS flow. Furthermore, if the network has multiple QoS flows with identical QoS characteristics, this can lead to unpredictable behavior during handover when the NG RAN needs to determine which QoS flows to accept or reject, and can also lead to unpredictable behavior when resources are limited and the NG RAN must determine which QoS flows to reject or preempt.

[0067] Figure 2An example signal path between the WTRU, the hosting device, and the external data network is shown. The signal path between WTRU 102 and the linked device 210 can be a Bluetooth connection, a Wi-Fi connection (212a), a USB interface (212b), or another interface that is not a Uu interface. That is, the signal path between the linked device and the WTRU is a signal path that is not part of the RAN. The interface between WTRU 102 and RAN 104 can be via a Uu interface. The Uu interface facilitates the transmission of user data, control signaling, and various other types of information between WTRU 102 and RAN 104. For simplicity, RAN 104 is shown, and those skilled in the art will understand that the Uu interface can be an interface with a gNB, microcell, femtocell, picocell, etc. The signal path between RAN 104 and UPF 184 is via an N3 interface, and the interface between UPF 184 and data network 204 is via an N6 interface. Data network 204 can be a service provider data network, a private data network, the Internet, or any other data network. The hosted application 202 can run on WTRU 102 or on the tethered device 210. The hosted application 202 communicates with the application server 208 residing in the data network 204. The application server 208 may not be aware that the WTRU-hosted application 202 is hosted on the tethered device 210, and the associated traffic may cause delays on the tethered connection.

[0068] Application server 208 and hosted application 202 can use Session Description Protocol (SDP) signaling to negotiate the use of PDU set tags. Negotiating the use of PDU set tags may mean that the sending application (i.e., the AS or WTRU hosted application) can indicate to the receiving application (i.e., another AS or WTRU hosted application) whether the sender supports adding PDU set header extensions. This indication can be included in an SDP message.

[0069] The header field can be associated with a PDU set. In some embodiments, the PDU set sequence number (PSSN) can be a header field that encodes the sequence number of the PDU set to which the current PDU belongs, thereby serving as a 10-bit numeric identifier for the PDU set.

[0070] An N6 interface can refer to a UPF interface used for sending and receiving PDUs. For example, PDUs can be sent to and received from application server 208. PDUs can be in IP or Ethernet format. An N6 traffic flow can be a series of PDUs that match the same Packet Detection Rule (PDR) or SDF.

[0071] The Packet Flow Description (PFD) can contain information needed to classify uplink or downlink packets arriving at the UPF. Information used for packet detection may include the source interface, WTRU IP address, network instance, core network tunnel information, packet filter set, application identifier, QoS flow identifier, Ethernet PDU session information, frame routing information, fully qualified domain name (FQDN) filters from Domain Name System (DNS) queries, or protocol descriptions. The application identifier in the PDR can identify the Packet Flow Description (PFD). The PDR may also include what QoS enforcement rules to apply to detected traffic. QoS enforcement rules (QERs) can include QoS flow IDs that can be applied to the associated traffic and can instruct the UPF whether it should insert PDU set information associated with downlink packets into the General Packet Radio Service (GPRS) Tunneling Protocol User Plane (GTP-U) header.

[0072] SDP is an information encoding format describing a multimedia session. The technical solution described in this paper includes enhancements to SDP. These enhancements describe information that can be conveyed from a first multimedia session participant to a second multimedia session participant. This information can then be used by the multimedia session participants to configure the communication network for carrying data from the multimedia session, and to configure the format of the data sent in the multimedia session. Examples of multimedia session participants could be WTRU-hosted applications and application servers.

[0073] It should be noted that protocols other than SDP can be similarly enhanced to convey information from a first multimedia session participant to a second multimedia session participant, such that the information can then be used by the multimedia session participant to configure the communication network for carrying data to and from the multimedia session, and to configure the format of the data sent in the multimedia session. For example, RTCP (Real-time Transmission Control Protocol) can be similarly enhanced.

[0074] The WTRU-hosted application can perform a process for determining quality information about the link between the WTRU-hosted application and the WTRU (when the WTRU-hosted application resides on a linking device) or between the WTRU-hosted application and the TE portion of the WTRU. The quality information can be related to the quality of the link. For example, the determined quality information could be data latency values, jitter values, packet loss rate, and / or bit rate associated with traffic volume sent to or from the WTRU-hosted application.

[0075] Figure 3 This is a diagram illustrating an example of multiplexing a set of PDUs from multiple applications within a single QoS stream. Figure 3In the example shown, WTRU 102 hosts more than one application and receives downlink data from the hosted applications. Data associated with each application is sent to WTRU 102 in the form of PDU sets 302a and 302b. Figure 3 As shown, application data can be multiplexed from UPF 184 onto a single QoS stream 304 and sent from UPF 184 to RAN 104 (RAN node). As described herein, data from applications can be multiplexed onto the same QoS stream because the traffic from the applications has the same or similar QoS requirements. As an example, applications using WTRU for connectivity can be hosted in the TE section of the WTRU or can be hosted devices tethered to the WTRU. For example, when using a VR application, a user can tether a VR headset (USB) and a haptic kit (Bluetooth) to the WTRU. Therefore, the tethering scenario can be generalized to the WTRU running multiple applications 306a and 306b that support traffic sent in the form of PDU sets.

[0076] When WTRU 102 hosts an application running on a connected device, there may be a non-negligible delay between the time WTRU 104 receives data and the time the application receives the data. For example, if one of the applications (e.g., 306a) is hosted on a device connected to a smartphone via Bluetooth, the smartphone may provide the device's connection to the communication network (RAN 104) via Bluetooth. The communication network could be, for example, a 5G network. When the smartphone receives downlink data, there may be a non-negligible delay between WTRU 102 and application 306a, for example, via Bluetooth. The 5G system supports an application programming interface (API) that allows AS (208) to configure QoS requirements for data flows. However, AS 208 may not be aware that the WTRU application is hosted on a connected device and the associated traffic may therefore cause delays on the connected connection.

[0077] Signaling enhancements are described that enable AS 208 to be aware of the linking delay, and AS 208 and the communication network can take this delay into account, for example, the communication network could be a 5G communication system. The embodiments described herein enable the calculation of the delay offset between WTRU 102 and the linked device by considering the delay difference between the WTRU and the linked device, and the use of this delay offset to achieve timely data delivery.

[0078] In the embodiments described herein, the RAN node can be configured with information about additional latency that may be caused by the traffic flow after the RAN node transmits traffic. For example, if an application that needs to receive traffic is hosted on a device linked to a WTRU, the traffic flow may cause significant latency after being transmitted by the RAN node. As an example, the application may run on a device connected to the WTRU via Bluetooth or Wi-Fi, and the application may run on a remote WTRU communicating with a 5G system via the WTRU (e.g., if the WTRU is a relay WTRU). By informing the RAN node about the additional latency that may be caused by the traffic flow after the RAN node transmits traffic, the RAN node may be able to make better decisions about how to prioritize the transmission of its received traffic flows for that WTRU and other WTRUs. The RAN node can calculate a latency value for one or more PDUs or a set of one or more PDUs based on at least one of the following: RAT, data latency value, jitter value, packet loss rate, or bit rate. Additionally, the RAN node can receive at least one PDU associated with at least one other QoS flow that is associated with traffic of an application running on a device other than the chained device, and the transceiver and processor are also configured to map at least one other QoS flow to a lower priority DRB.

[0079] As used herein, for example, the term RAN node can be applied to a base station or a network node that controls multiple base stations. The terms RAN node, NG-RAN, and NG-RAN node are used interchangeably herein. Those skilled in the art will understand that the concepts described herein as being performed by RAN nodes can be equally applied to other nodes interfacing with access networks such as N3IWF or TNGF.

[0080] Figure 4 This is a signal diagram illustrating an example delay offset calculation process for a tethering device. Figure 4 In the example shown, at 422, the WTRU-hosted application 404 can receive a Session Description Protocol (SDP) message from AS 420. The SDP message can instruct AS 420 to support sending data using PDU set header extensions. The SDP message can also instruct AS 420 to support receiving the external identifier of WTRU 402, and that AS 420 supports receiving information about the data quality associated with traffic sent to or from the WTRU-hosted application 404. Figure 4 This illustrates that application 404, managed by the WTRU, runs in the Terminal Equipment (TE) section 406 of the WTRU 402. Alternatively or additionally, such as... Figure 4As shown by the dashed line, the application 404 hosted by the WTRU can run on an external device 450 connected to the WTRU 402. For example, a Bluetooth device can be connected to the WTRU 402.

[0081] At 424, the WTRU-hosted application 404 can perform a process for determining quality information regarding the link between the WTRU-hosted application 404 and the WTRU 402 (when the WTRU-hosted application 404 resides on the linking device 450) or between the WTRU-hosted application 404 and the MT portion 408 of the WTRU 402. The quality information relates to the quality of the link. For example, the determined quality information may be data latency values, jitter values, packet loss rate, and bit rate associated with traffic sent to or from the WTRU-hosted application 404.

[0082] Quality information can be determined based on the tether configuration configured in the application 404 hosted by the WTRU or received from AS 420. For example, it can be expected that an application hosted on a Bluetooth device is associated with specific data latency values, jitter values, packet loss, and bit rate. Alternatively or additionally, quality information can be determined based on traffic characteristics associated with the application 404 hosted by the WTRU; for example, it can be expected that an application transmitting or receiving certain types of video traffic is associated with specific data latency values, jitter values, packet loss, and bit rate.

[0083] Quality information may be received by the WTRU-hosted application 404 from the MT portion 408 of the WTRU 402. For example, the MT portion 408 of the WTRU 402 may indicate the expected latency value on the link, or the MT portion 408 of the WTRU 402 may indicate the expected quality information on the link. The quality information may be based on a calculation performed between the WTRU-hosted application 404 in, for example, a Bluetooth device and / or a client in the TE portion 406 of the WTRU 402. Alternatively or additionally, the quality information may be based on a calculation performed between the WTRU-hosted application 404 and the MT portion 408 of the WTRU 402. The quality information may also be based on multiple calculations previously performed by the WTRU-hosted application 404. For example, the quality information may be the average of calculations performed or received by the WTRU-hosted application 404.

[0084] At 426, the WTRU-hosted application 404 can send the determined quality information to the MT section 408 of the WTRU 402. The MT section 408 of the WTRU 402 can then use this information when considering how to schedule uplink traffic initiated at the WTRU-hosted application 404 and destined for a communication network (such as a 5G network). For example, since traffic from the WTRU-hosted application 404 may cause delays on the tethered link, the MT section 408 of the WTRU 402 can prioritize the transmission of traffic associated with the WTRU-hosted application 404. Prioritizing traffic associated with the WTRU-hosted application 404 might mean sending that traffic before other traffic received by the MT section 408 at an earlier time.

[0085] At 428, the WTRU-hosted application 404 can send an SDP message to AS 420. If AS 420 indicates that it supports receiving the external identifier of WTRU 402, and that it supports receiving quality information associated with traffic sent to or from the WTRU-hosted application 404, the SDP message may include the external ID of WTRU 402 and quality information.

[0086] Quality information can indicate an estimate of the delay expected to occur between the time when the WTRU-hosted application 404 receives a packet at WTRU 402 and the time when the WTRU-hosted application 404 receives the packet. Alternatively, the delay value can indicate an estimate of the delay expected to occur between the time when the WTRU-hosted application 404 sends a packet and the time when WTRU 402 sends the packet. This delay may be non-negligible, especially if the WTRU-hosted application 452 is running on a device 450 linked to WTRU 402. For example, the WTRU-hosted application 404 may run on a device 450 connected to WTRU 402 via Bluetooth. Alternatively, the message can simply indicate that the WTRU-hosted application 452 is running on the linked device 450. Additional delay values ​​can be pre-configured in the WTRU-hosted application 404 or calculated by the WTRU-hosted application 402 based on its interactions with WTRU 402 (e.g., based on speed test message exchanges with WTRU 404).

[0087] The SDP message may include additional auxiliary information. For example, the auxiliary information may indicate whether the WTRU-hosted application 452 is hosted on a linked device 450 or not hosted on a linked device 450. For example, the auxiliary information may indicate the type of radio access technology used by the device running on the WTRU-hosted application 452 to communicate with the WTRU 402. For example, this could be Bluetooth or Wi-Fi radio access. The additional latency value may also indicate jitter introduced by the application and / or network, such as due to network congestion, improper implementation of packet prioritization, interference from other components, poor hardware performance, etc.

[0088] The application 404 hosted by the WTRU can additionally include a set of values ​​for the additional latency that can be taken in the SDP message. For example, if the tethered device 450 moves relative to the WTRU 402, the additional latency can take different values. As an example, the tethered device 450 could be VR glasses, and the user wearing the tethered device could move around in a room while the WTRU 402 is in a fixed position on a table.

[0089] At 430, AS 420 uses quality information and additional auxiliary information to determine and make necessary adjustments at the application layer, such as codec settings changes. AS 420 can determine QoS references or individual QoS parameters based on the quality information and additional auxiliary information. QoS parameters or QoS references can be based on codec settings, which in turn are based on quality information.

[0090] At 432, AS 420 can invoke the API of the Nnef_AFsessionWithQoS service. AS 420 can indicate the flow associated with the WTRU-hosted application 452 residing on device 450 in the tethered chain and associated with an additional latency value. Each device in the tethered chain can be associated with a certain additional latency value. AS 420 can then indicate the device ID of device 450 in the tethered chain where the flow resides, from which the latency value can be derived. Alternatively, AS 420 can provide a set of values ​​for the additional latency, which are the values ​​that the additional latency can take. These values ​​can be represented by indices (e.g., integer values), and the mapping between latency values ​​and indices can be provided by AS 420 to NEF 418, which can be, for example, a 5G core network (5GC).

[0091] At 434, NEF 418 can call the API of the Npcf_PolicyAuthorization service to provide the information received from AS 420 at 428 to PCF 416. At 436, PCF 416 can construct Policy and Charging (PCC) rules. PCC rules can instruct certain SDFs to be associated with additional delay values ​​and / or with applications hosted on the tethered device 450. Alternatively, if multiple additional delay values ​​are provided to the PCF, for example, delay values ​​for tethered device 450 to WTRU 402, the PCC can construct a set of PCC rules, and each rule can include different values ​​for the additional delays and can include corresponding index values.

[0092] At 438, SMF 414 can receive PCC rules, and at 440, it can use the PCC rules to construct QoS profiles. QoS profiles can be indications of certain SDFs associated with additional delay values ​​and / or with applications hosted on the tethered device 450. Alternatively or additionally, SMF 414 can construct multiple QoS profiles for a specific SDF, where each QoS profile has a different value of additional delay corresponding to the PCC rules provided to SMF 414. QoS profiles can include index values ​​corresponding to the PCC rules associated with those index values. Alternatively or additionally, SMF 414 can construct QoS rules for the SDF, including information about the additional delay values. When multiple additional delay values ​​are provided, SMF 414 can generate a set of QoS rules for the SDF of WTRU 402, including the different values ​​of additional delay and their corresponding indices.

[0093] At 442, SMF 414 can send a QoS profile to RAN node 410. When making a scheduling decision at 444, RAN node 410 can use indications associated with certain SMFs and additional quality information and with hosted applications 452 on linked device 450. For example, RAN node 410 can choose to prioritize the transmission of traffic associated with an additional delay value over traffic not associated with an additional delay value. RAN node 410 (e.g., at the Service Data Adaptation Protocol (SDAP) layer) can map QoS flows associated with the additional delay value and / or with hosted applications 452 on linked device 450 to higher-priority data radio bearers (DRBs) to ensure PDU set delay budget (PSDB) is met. As an example, the additional delay value can also be used by RAN node 410 when calculating the delay value of a PDU set. For example, the access network (AN) PSDB can be determined by subtracting both the additional delay value and the core network (CN) PSDB from the PSDB. The additional delay value can be used by RAN node 410 when calculating the delay value of a PDU.

[0094] In some embodiments, RAN node 410 may use quality information to determine the Connectivity Mode Discontinuous Receive (CDRX) setting of WTRU 402. The CDRX setting may include timer values. For example, a relatively small jitter value in the quality information may cause RAN node 410 to configure WTRU 402 to sleep for a longer period than a relatively large jitter value. Alternatively, when WTRU 402 is exchanging traffic with AS 420, if WTRU 402 is configured to calculate the delay between tethered device 450 and WTRU 402, and if WTRU 402 detects a change in the value of the additional delay, WTRU 402 can notify RAN 410 that the new additional delay value should be considered by providing an index corresponding to the delay value. In this case, RAN 410 can utilize the newly received index value from WTRU 402 to select a QoS profile. In this way, if AS 420 provides or provides multiple values ​​for the additional delay, RAN 410 can quickly adapt to changes in tethered link delay.

[0095] Based on the PCC rule received at 438, at 446, SMF 414 can be triggered to send a configuration message to WTRU 402. This message can instruct WTRU 402 to use quality information received from the TE part 406 of the application or from the WTRU-hosted application 404 on the tethered device 450 for scheduling traffic between the tethered device 450 / WRUL-hosted application 404 and the MT part 408 of WTRU 402 when prioritizing transmissions. In other words, this message can instruct WTRU 402 that it can use the information received at 426 to consider how to prioritize uplink traffic.

[0096] Upon receiving data from WTRU-hosted application 404 or chained device 450, WTRU 402 or MT section 408 can perform scheduling at 448 based on the quality information received at 426. For example, WTRU 402 or MT section 408 can ensure that all WTRU-hosted applications running on chained devices receive their associated data at similar times. For example, MT section 408 can prioritize traffic from applications running on chained devices. WTRU 402 can use the quality information to schedule or prioritize traffic for both uplink and downlink.

[0097] Figure 5 This is a flowchart of an example process 500 for latency-aware scheduling of PDU aggregation streams implemented in a network node. Figure 5 In the example shown, at point 502, the network node can receive a message indicating at least one of the QoS flows of the WTRU, the at least one of which is associated with traffic sent to or received from a device in the tethered network. As an example, this message could be a QoS profile configuration message, and the QoS profile configuration message could include information indicating at least one of the Radio Access Technology (RAT), data delay value, jitter value, packet loss rate, and bit rate associated with the WTRU and the device in the tethered network.

[0098] At 504, the network node may receive one or more PDUs associated with at least one QoS flow, and at 506, the network node may associate the received one or more PDUs with linked devices, prioritizing the transmission of those PDUs over PDUs associated with other QoS flows. This process may include calculating a delay value for one or more PDUs or a set of one or more PDUs based on at least one of the following: RAT, data delay value, jitter value, packet loss rate, or bit rate. In an example embodiment, the QoS profile configuration message includes multiple QoS profiles, each with a different data delay value. Alternatively or additionally, the process may include receiving an index from the WTRU corresponding to a new data delay value based on a change in delay between the WTRU and the linked devices; and selecting one of the multiple QoS profiles that includes the new data delay value corresponding to the index received from the WTRU.

[0099] In an exemplary embodiment, the linking device may be at least one of the terminal equipment (TE) portion of the WTRU or a remote device configured to communicate with the WTRU via a communication link different from the radio access network interface between the network node and the WTRU. The network node may be a RAN node. The process may further include prioritizing the transmission of one or more PDUs associated with the linking device by mapping them to a DRB with a higher priority than the DRB used for PDUs not associated with the linking device.

[0100] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of non-transitory 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 discs and digital multifunction disks (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A network node, comprising: transceiver; as well as processor, The transceiver and the processor are configured as follows: Receive a message including first information, the first information indicating at least one Quality of Service (QoS) stream of a Wireless Transmit / Receive Unit (WTRU), the at least one QoS stream being associated with traffic volume sent to or received from a device in the tethering chain; Receive one or more Protocol Data Units (PDUs) associated with the at least one QoS flow; and Based on the association of one or more received PDUs with the device in the chain, the transmission of the one or more PDUs is prioritized over PDUs associated with other QoS flows.

2. The network node according to claim 1, wherein, The message is a QoS configuration file message.

3. The network node according to claim 2, wherein, The QoS profile configuration message also includes second information indicating at least one of the following associated with the WTRU and the linked device: radio access technology (RAT), data latency value, jitter value, packet loss rate, and bit rate.

4. The network node according to claim 3, wherein, The transceiver and the processor are further configured to calculate the latency value of the one or more PDUs or one or more PDU sets based on at least one of the following: the RAT, the data latency value, the jitter value, the packet loss rate, or the bit rate.

5. The network node according to claim 4, wherein: The QoS configuration message includes multiple QoS configuration files, each with a different data latency value. The transceiver and the processor are also configured to receive an index from the WTRU corresponding to a new data latency value based on a change in latency between the WTRU and the linked device, and The transceiver and the processor are also configured to select one of the plurality of QoS profiles that includes the new data latency value corresponding to the index received from the WTRU.

6. The network node according to claim 1, wherein, The linking device is at least one of the terminal equipment (TE) portion of the WTRU or a remote device, the remote device being configured to communicate with the WTRU via a communication link different from the radio access network interface between the network node and the WTRU.

7. The network node according to claim 6, wherein, The transceiver and the processor are configured to preferentially transmit the one or more PDUs by mapping the one or more PDUs associated with the linked device to a DRB with a higher priority than the DRB for PDUs not associated with the linked device.

8. The network node according to claim 7, wherein: The transceiver and the processor are also configured to receive at least one PDU associated with at least one other QoS flow related to traffic of an application running on a device other than the tethered device, and The transceiver and the processor are also configured to map the at least one other QoS stream to a lower priority DRB.

9. The network node according to claim 4, wherein, The transceiver and the processor are further configured to: At least one connection mode discontinuous reception (CDRX) timer value for the WTRU is determined based on the second information in the QoS profile configuration message, and Send at least one determined CDRX timer value to the WTRU.

10. The network node according to claim 1, wherein, The network node is a Radio Access Network (RAN) node.

11. A method implemented in a network node, the method comprising: Receive a message including first information, the first information indicating at least one Quality of Service (QoS) stream of a Wireless Transmit / Receive Unit (WTRU), the at least one QoS stream being associated with traffic volume sent to or received from a device in the tethering chain; Receive one or more Protocol Data Units (PDUs) associated with the at least one QoS flow; as well as Based on the association of one or more received PDUs with the device in the chain, the transmission of the one or more PDUs is prioritized over PDUs associated with other QoS flows.

12. The method according to claim 11, wherein, The message is a QoS configuration file message.

13. The method according to claim 12, wherein, The QoS profile configuration message also includes second information indicating at least one of the following associated with the WTRU and the linked device: radio access technology (RAT), data latency value, jitter value, packet loss rate, and bit rate.

14. The method of claim 13, further comprising calculating a delay value for the one or more PDUs or one or more PDU sets based on at least one of the following: the RAT, the data delay value, the jitter value, the packet loss rate, or the bit rate.

15. The method of claim 14, wherein: The QoS configuration message includes multiple QoS configuration files, each of which has a different data latency value.

16. The method of claim 15, further comprising: Based on the change in delay between the WTRU and the linked device, an index corresponding to the new data delay value is received from the WTRU, and Select one of the plurality of QoS profiles that includes the new data latency value corresponding to the index received from the WTRU.

17. The method according to claim 11, wherein, The linking device is at least one of the terminal equipment (TE) portion of the WTRU or a remote device, the remote device being configured to communicate with the WTRU via a communication link different from the radio access network interface between the network node and the WTRU.

18. The method of claim 17, further comprising preferentially transmitting the one or more PDUs by mapping the one or more PDUs associated with the chained device to a DRB with a higher priority than a data radio bearer (DRB) for PDUs not associated with the chained device.

19. The method of claim 14, further comprising: At least one connection mode discontinuous reception (CDRX) timer value for the WTRU is determined based on the second information in the QoS profile configuration message, and Send at least one determined CDRX timer value to the WTRU.

20. The method according to claim 11, wherein, The network node is a Radio Access Network (RAN) node.

Images