Wtru configuration for faster rrt adjustment

Abstract

This document can describe configuring a WTRU to adjust UL QFI based on DL traffic. The WTRU can receive a DL packet and / or an associated ID. The WTRU can be triggered to check whether a QoS flow allocation (e.g., QFI) of an UL flow can be updated. The WTRU can use the associated ID to determine an UL packet filter associated with the downlink packet. The WTRU can use a QFI in a QoS rule to determine a rule and / or a QFI of the downlink packet to determine a QFI that should be allocated to uplink traffic. The WTRU can receive UL traffic from a higher layer and can determine that the uplink traffic matches an UL traffic filter associated with the associated ID and / or UL QFI. The WTRU can send the uplink traffic in the determined QoS flow.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 619,773, filed January 11, 2024, the entire contents of which are incorporated herein by reference as if set forth herein. Background Technology

[0002] 5G systems may have round-trip (RT) requirements. 5G systems can perform uplink or downlink (UL / DL) policy control based on these RT requirements. In an example, an Application Function (AF) can introduce RT requirements. The AF can request an AF session for a specific service and include a round-trip latency indication. A Policy Control Function (PCF) can receive this request from the AF (e.g., via a Network Open Function (NEF)). The PCF can use the RT latency indication to determine the RT latency requirement (e.g., having a value equal to the RT latency indication). The PCF can determine the DL PDB and / or UL PDB for the XRM service of interest (e.g., video service for the DL direction and attitude information for the UL direction). The sum of the DL PDB and / or UL PDB is set to be less than the RT latency requirement value.

[0003] If data services use different service data streams or have different QoS parameters, the PCF can generate PCC rules (e.g., two). PCC rules can be used for DL ​​services and / or UL services. The PCF can send the PCC rules to the SMF, which can then generate corresponding N4 rules for the UPF, QoS profiles for the RAN, and / or QoS rules for the WTRU. Summary of the Invention

[0004] A wireless transmit / receive unit (WTRU) may include a processor configured to receive Quality of Service (QoS) rules and / or downlink (DL) messages. The DL messages (e.g., including one or more DL packets) may include a DL QoS Flow Identifier (QFI) and an association ID. The association ID may be within the SDAP header of the DL packet message. The QoS rules may include indications of utilizing an associated QoS Flow (AQF), and the QoS rules may be constructed by a Session Management Function (SMF). The QoS rules may include one or more QFI determination rules and / or indications that an AQF should be used. The DL messages may indicate that the QFI of a UL traffic flow needs to be updated.

[0005] The processor can also be configured to determine the association between the uplink (UL) service flow and the DL message based on the association ID. The processor can also be configured to determine the QFI associated with the UL service flow based on the QoS rules and the QFI of the DL message. The processor can also be configured to use the determined QFI associated with the UL service flow to send UL data packets for the UL service flow.

[0006] The processor of the WTRU can also be configured to determine a UL packet filter associated with the association ID. The UL packet filter may be associated with the downlink message. The processor can also be configured to receive UL traffic from a higher layer and determine if the UL traffic matches the UL packet filter associated with the association ID. The UL traffic from the higher layer may be an application hosted at the WTRU. Attached Figure Description

[0007] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments can be implemented.

[0008] Figure 1B The illustration is based on an embodiment and can be used for Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) within a communication system.

[0009] Figure 1C The illustration is based on an embodiment and can be used for Figure 1A The diagram shows an example radio access network (RAN) and an example core network (CN) within the communication system.

[0010] Figure 1D The illustration is based on an embodiment and can be used for Figure 1A The system diagram shows another example RAN and another example CN within the communication system shown.

[0011] Figure 2 This is a system flowchart depicting an example of providing and implementing AQF at the WTRU.

[0012] Figure 3 This is a system flowchart depicting an example of providing AQF in a RAN.

[0013] Figure 4 This is a system flowchart depicting an example of using AQF to adjust UL QFI based on DL services. Detailed Implementation

[0014] Figure 1AThis diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasting, etc., to multiple wireless users. The communication system 100 enables multiple wireless users to access this content by sharing system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM (OFDM), Filter Bank Multicarrier (FBMC), etc.

[0015] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, and 102d may 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” and / or “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 industrial and / or automated processing chain environments), 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.

[0016] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can 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 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b can be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are depicted as single elements, it should be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network elements.

[0017] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown in the figures), 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 in the figures). These frequencies may be located in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide radio service coverage for a specific geographic area, which may be relatively fixed or may vary over time. A cell may be further 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, one for each sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0018] 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.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0019] 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 stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. 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 ​​UL Packet Access (HSUPA).

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

[0021] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use new radio (NR) to establish air interface 116.

[0022] 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 simultaneously implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions to and from multiple types of base stations (e.g., eNBs and gNBs).

[0023] 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., 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), and GSM EDGE (GERAN).

[0024] Figure 1A Base station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an 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 drone use), 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 can access Internet 110 without going through CN 106 / 115.

[0025] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to perform the following operations: provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. The data may have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 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 1A Although not shown in the diagram, it should be understood that RAN104 / 113 and / or CN106 / 115 can communicate directly or indirectly with other RANs that use the same or different RATs as RAN 104 / 113. For example, in addition to connecting to RAN 104 / 113, which may utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown in the diagram) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0026] CN 106 / 115 can also act as a gateway for WTRU 102a, 102b, 102c, 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 employ the same or different RAT as RAN 104 / 113.

[0027] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capability (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 1AThe WTRU 102c shown can be configured to communicate with a base station 114a that may employ cellular-based radio technology and a base station 114b that may employ IEEE 802 radio technology.

[0028] Figure 1B This is a system diagram illustrating the example WTRU 102. (Example:) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 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 should be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the above-described elements.

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

[0030] Transmitting / receiving element 122 may 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 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 may 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 may be configured to transmit and / or receive both radio frequency signals and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0032] Transceiver 120 can be configured to modulate the signal to be transmitted by transmitting / receiving element 122 and demodulate the signal received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as, for example, NR and IEEE 802.11).

[0033] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from these devices. The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access and store information from any type of suitable 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, a memory stick, a secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access and store information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)).

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

[0035] 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. Attached to or replacing the 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 should be understood that, while remaining consistent with the embodiments, the WTRU 102 may obtain location information using any suitable location determination method.

[0036] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biosensors, and / or humidity sensors.

[0037] WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or through signal processing by a processor (e.g., a separate processor (not shown) or through processor 118). In embodiments, WTRU 102 may include a half-duplex radio, for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

[0039] RAN 104 may include eNodeBs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. eNodeBs 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, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNodeB 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

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

[0041] 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 (or PGW) 166. While each of the above elements is depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0042] The MME 162 can connect to each eNodeB 162a, 162b, 162c in RAN104 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, 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for handover between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0043] The SGW 164 can connect to each eNode B 160a, 160b, and 160c in RAN104 via the S1 interface. The SGW 164 typically routes and forwards user packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing WTRU 102a, 102b, and 102c scenarios, etc.

[0044] The SGW 164 can connect to the PGW 166, which 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.

[0045] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional terrestrial line communication equipment. For example, CN 106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), which acts as an interface between CN 106 and PSTN 108. Furthermore, 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.

[0046] Despite Figure 1A-1D The WTRU is described as a wireless terminal, but in some representative embodiments, it is envisioned that such a terminal may communicate with a communication network using (e.g., temporarily or permanently) a wired communication interface.

[0047] In a representative embodiment, another network 112 may be a WLAN.

[0048] 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 that AP. The AP may access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating 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, for example, an AP, where the source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between the source STA and the destination STA (e.g., directly between the source STA and the destination STA) using 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 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 the "ad-hoc" communication mode in this document.

[0049] 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 can be dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections 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. With CSMA / CA, all STAs, including the AP (e.g., each STA), can listen on the primary channel. If a particular STA listens / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0050] 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 to form a 40 MHz wide channel.

[0051] Ultra-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 (this can be referred to as an 80+80 configuration). For the 80+80 configuration, data, after channel coding, can be transmitted via a segmented parser that divides the data into two streams. Each stream can be processed separately using inverse fast Fourier transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80 MHz channels and transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0052] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared 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 may support Meter Type Control / Machine-Type Communications, such as MTC devices in macro coverage areas. MTC devices may have specific capabilities, such as supporting (e.g., only supporting) specific and / or limited bandwidth functions. MTC devices may include batteries with a battery life exceeding a threshold (e.g., maintaining a very long battery life).

[0053] 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 bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. Taking 802.11ah as an example, for a STA that supports (e.g., only supports) the 1 MHz mode (e.g., MTC type device), the primary channel bandwidth can be 1 MHz, 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 Assignment Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy (e.g., due to a STA (which only supports the 1 MHz operating mode)) transmitting to the AP, the entire available band can be considered busy, even if most of the band remains idle and may be available.

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

[0055] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0056] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while maintaining consistency 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. Therefore, 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 can 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).

[0057] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with an scalable set of parameters. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary 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 or transmission time intervals (TTIs) of various or scalable lengths (e.g., including different numbers of OFDM symbols and / or absolute time lengths of varying durations).

[0058] 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 also accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more gNBs 180a, 180b, and 180c as mobility 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, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

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

[0060] Figure 1DThe CN 115 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 may include data networks (DN) 185a, 185b. While each of the above elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0061] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 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 PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating 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 used by WTRU 102a, 102b, and 102c. For example, different network slices can 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 Machine Type Communication (MTC) access, etc. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-A Pro) and / or non-3GPP access technologies (such as WiFi).

[0062] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 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 downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

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

[0064] CN 115 can facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), or may communicate with such an IP gateway, which acts as an interface between CN 115 and PSTN 108. Furthermore, CN 115 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 local data networks (DNs) 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0065] Given Figure 1A-1D and Figure 1A-1D The corresponding descriptions herein refer to one or more of the following functions that can be performed by one or more emulation devices (not shown in the figures): WTRU 102a-d, base station 114a-b, eNode-B160a-c, MME 162, SGW 164, PGW 166, gNB180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein. An emulation device can be one or more devices configured to simulate 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.

[0066] The simulation device may be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, the one or more simulation devices may perform one or more or all functions, fully or partially implemented and / or deployed as part of a wired and / or wireless communication network, to test other devices within that communication network. The one or more simulation devices may perform one or more or all functions, temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing, and / or may perform tests using over-the-air wireless communication.

[0067] One or more simulation devices can perform one or more functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices can be used in test scenarios within a test laboratory and / or an undeployed (e.g., testing) wired and / or wireless communication network to perform testing on one or more components. One or more simulation devices can be test rigs. Simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0068] WTRU can indicate support for one or more associated QoS flow (AQF) features. Application Function (AF) can request resources for Extended Reality Media (XRM) data sessions, which may include uplink (UL) and downlink (DL) flows subject to round-trip (RT) requirements.

[0069] The Policy Control Function (PCF) generates one or more Policy and Charging Control (PCC) rules for the considered UL and DL traffic flows. The Session Management Function (SMF) determines the association ID and / or QoS Flow Identifier (QFI) determination rules for the linked UL and DL flows. The QFI determination rules may include information about the QFI of the UL QoS flow carrying the UL flow. DL flows may be carried by the QoS flow identified by the DLQFI.

[0070] The SMF can generate one or more QoS rules, which may include QFI determination rules and / or service identification information that helps identify UL services (e.g., association ID and / or service description of DL flows). The SMF can generate N4 rules for the UPF and / or QoS profiles for the RAN. The SMF can (e.g., via a PDU session modification response message) send QoS rules to the WTRU, N4 rules to the UPF, and / or QoS profiles to the RAN. If there is an uplink XRM service to be transmitted by the WTRU, the WTRU can use the association ID of the UL flow to determine the QoS rules. The WTRU can then use the QFI determination rules in the QoS rules to determine the QFI used to transmit the UL service.

[0071] The WTRU can be configured to adjust the UL QFI based on DL traffic, as described herein. The WTRU can receive DL packets and / or the association ID in the SDAP header of the DL packets. The WTRU can be triggered to check whether the QoS flow allocation (e.g., QFI) of the UL flow associated with the DL packet flow can be updated. The WTRU can use the association ID to determine the UL packet filter associated with the downlink packets. The WTRU can use the QFI determination rule in the QoS rules corresponding to the UL flow of interest and / or the QFI of the downlink packets to determine the QFI that should be allocated to the uplink traffic. The WTRU can receive UL traffic from a higher layer (e.g., an application hosted at the WTRU). The WTRU can determine that the uplink traffic matches the UL traffic filter associated with the association ID and transmit the uplink traffic in the QoS flow associated with the QFI that the WTRU determines should be allocated to the uplink traffic. The WTRU can map the UL traffic to the UL QFI based on the UL traffic filter match and the QFI determination rule in the QoS rules. The WTRU can transmit the uplink traffic in the determined QoS flow.

[0072] This document describes the SMF's actions. The SMF can receive from the AMF an indication that the WTRU supports one or more AQF features. The SMF can receive PCC rules from the PCF. PCC rules indicate the association between UL and DL service flows. PCC rules may include RT latency requirements for the UL and DL service flows. The SMF can determine an association ID value that identifies the association between the UL and DL service flows based on the received PCC rules. The SMF can construct QoS rules for the WTRU, indicating that AQF features should be applied to certain services. QoS rules may indicate UL packet filters for UL flows, packet filters for DL ​​flows associated with the UL services of interest, and / or the resulting association IDs. The SMF can generate QFI determination rules for UL flows. The SMF can construct N4 rules for the PDU session. The SMF may include in the N4 rules an indication that AQF can be used for services matching DL services (e.g., video) and / or UL services (e.g., attitude information). The SMF may include the association ID in the resulting N4 rules. SMF can generate QoS profiles, which may include indications such as: AQF is enabled for QoS flow carrying UL and DL service flows. SMF can trigger PDU session modification procedures to send N4 rules to the UPF, QoS rules to the WTRU, and QoS profiles to the RAN nodes. QFI-determined rules can be included in the QoS rules.

[0073] This document describes RAN node actions. A RAN node can receive DL packets from a UPF (e.g., in a GTP-U message). The GTP-U header and / or GTP-U extended header may include an association ID derived from the DL filter of that DL packet. The RAN node may encapsulate the DL packet in an SDAP header. The RAN node may include the association ID value in the SDAP header.

[0074] This document describes configuring a RAN node to adjust the UL QFI based on DL services. The RAN node can receive a QoS profile from the SMF, which may include indications that the AQF feature is enabled for QoS flow carrying UL and DL service flows. The QoS profile may include the derived association ID and / or QFI determination rules for UL flows. The RAN node can receive DL packets from the UPF in GTP-U messages. The GTP-U header and / or GTP-U extended header may include the association ID derived from the DL filter of the DL packet. The RAN node can identify the QoS flow ID (QFI) of the received DL packets. The RAN node can use the DL flow's QFI and / or association ID to determine which UL flow should be used for the DL flow associated with the DL flow of interest. The RAN node can use the AQF determination rules, DL QFI, and / or association ID in the QoS profile to determine the QFI for the UL flow that can be associated with the DL flow of interest. The RAN node may encapsulate DL packets in an SDAP header, which may include: an indication that AQF is enabled (e.g., an AQF field value of 1 in the SDAP header), an association ID, and / or the determined UL QFI. The RAN node may transmit the encapsulated DL packets to the WTRU. The RAN node may (e.g., if available) include a field in the SDAP header with a UL DRB value to indicate the value and / or identifier of the UL DRB to which the UL packets of interest are to be mapped.

[0075] This document describes the WTRU action used to configure a RAN node to adjust the UL QFI based on DL services. The WTRU may receive a PDU session establishment / modification accept message from the SMF, which includes an indication that AQF is enabled for the PDU session. This message may include an AQF timer for QoS rules. The WTRU may receive DL packets, an AQF indication (e.g., a value of 1), an association ID, the QFI value of the UL QFI, and / or the DRB value of the UL DRB (e.g., in the SDAP header of the DL packet). The WTRU may be triggered based on the AQF indication to check whether the QoS flow assignment (e.g., QFI) of the UL flow, which may be associated with the flow of the DL packet, can be updated.

[0076] The WTRU can be triggered based on an AQF indication to check whether the UL QFI to DRB mapping rule can be updated (e.g., at the SDAP layer). The WTRU can use the received QFI value and / or UL DRB value to update the QFI to DRB mapping of the UL flow. The WTRU can determine based on the AQF indication that a QoS rule can be created and / or updated. The UL filter set used for the QoS rule may include an associated ID value provided by the RAN. The QFI value in the QoS rule can be set to the UL QFI value received from the RAN (e.g., in the DL packet header). A timer associated with the QoS rule can be started, with its duration set to the value of a previously received AQF timer.

[0077] This document describes the SMF action used to configure RAN nodes to adjust UL QFI based on DL services. The SMF can receive an indication from the AMF that the WTRU supports the AQF feature.

[0078] The SMF can receive PCC rules from the PCF. PCC rules indicate the association between UL and DL service flows. PCC rules may include RT delays associated with the UL and DL service flows. The SMF can determine an association ID value based on the received PCC rules, which identifies the association between the UL and DL service flows. The SMF can construct a QoS profile for the RAN, indicating that the AQF feature is enabled for QoS flow carrying UL and DL service flows. The QoS profile may indicate the derived association ID and / or QFI determination rules for UL flows. The SMF can construct N4 rules for PDU sessions. The SMF may include in the N4 rules an indication that AQF can be used for services matching DL video or UL services. The SMF may include the association ID in the derived N4 rules. The SMF may send the QoS profile to the RAN and / or send the N4 rules to the UPF.

[0079] This document describes the adjustment of the UL QFI based on RT delay measurement results. It describes the RAN node actions for adjusting the UL QFI based on RT delay measurement results. The RAN node can be configured to adjust RT based on DL services. The RAN node can monitor the RT delay of both UL and DL services. The RAN node can determine that the RT delay can be adjusted. The RAN node can determine the QFI of the DL flow (e.g., information based on DL packets of the DL service). The RAN node can use QFI determination rules in the QoS profile, the association ID, and / or the QFI value of the DL flow to determine the value of the QFI of the UL flow (e.g., the UL QFI). The RAN node can encapsulate DL packets in an SDAP header, which may include an AQF indication, an association ID, and / or the QFI value of the UL QFI, and can send it to the WTRU.

[0080] This document describes the WTRU action for adjusting the UL QFI based on RT delay measurement results. The WTRU receives DL packets with an SDAP header, which includes an AQF indication, an associated ID, and / or the QFI value of the UL flow. The WTRU can use the AQF indication, associated ID, and / or QFI value to update the QoS rules for the UL flow.

[0081] 5G systems may have round-trip (RT) requirements. 5G systems can perform UL / DL policy control based on these RT requirements. In an example, the Application Function (AF) can introduce RT latency requirements. An Application Function (AF) can request an AF session for a specific service, including a round-trip latency indication. The Process Control Function (PCF) can receive this request from the AF (e.g., via the Neural Function). The PCF can use the RT latency indication to determine the RT latency requirement (e.g., its value is equal to the RT latency indication). The PCF can determine the DL PDB and / or UL PDB for XRM services of interest (e.g., video services in the DL direction and attitude information in the UL direction). The sum of the DL PDB and / or UL PDB is set to be less than the RT latency requirement value.

[0082] If data services use different service data streams or have different QoS parameters, the PCF can generate PCC rules (e.g., two PCC rules). PCC rules can be used for DL ​​services and / or UL services. The PCF can send the PCC rules to the SMF, which can generate corresponding N4 rules for the UPF, QoS profiles for the RAN, and / or QoS rules for the WTRU.

[0083] The 5GS can monitor the round-trip latency of the DL and UL services of interest separately and merge the results at the SMF. The SMF can then provide this information to the PCF. The PCF can determine updated DL PDB and / or UL PDB values ​​based on the RT monitoring results, for example, to help ensure that RT latency meets RT latency requirements.

[0084] The PCF can perform UL / DL policy control based on round-trip time (RTT) requirements. The PCF can also perform UL / DL policy control based on receiving separate QoS monitoring reports for UL flows and / or separate QoS monitoring reports for DL ​​flows. The PCF can check if the sum of the UL and DL packet delays exceeds the RTT requirement. If the RTT requirement is exceeded, the PCF can change the PDB of the UL and / or DL ​​flows. This change in the PDB can cause the PCF to generate a new PCC rule. The PCC rule can be sent to the SMF. The SMF can use the PCC rule to generate a new QoS rule for the UL flow. The new QoS rule can be sent to the WTRU. The WTRU can receive the new QoS rule (e.g., in a NAS message) and apply it to the UL flow. The SMF can use the PCC rule to generate a new N4 rule for the DL flow and send the new N4 rule to the UPF. The UPF can receive the new N4 rule (e.g., in an N4 message) and apply it to the DL flow.

[0085] This document describes Reflective QoS (RQoS) for 5G systems. Reflective QoS refers to a feature of the 5GS where the WTRU is configured to use information from received DL packets to determine the QoS label of UL packets with the same identification information (e.g., packet filter information). The WTRU can indicate to the 5GS that it supports reflective QoS for PDU sessions. The WTRU can use the PDU session establishment and / or PDU session modification procedures to indicate this support. The WTRU can also determine whether to revoke RQoS support for that PDU session.

[0086] The PCF can generate one or more PCC rules for services carried in a PDU session. The PCF can include in these PCC rules an indication that RQoS will be used for services with the SDF template included in the PCC rules. PCC rules with a full match to the SDF template can include an indication that RQoS is disabled. The PCF can send the PCC rules to the SMF. The SMF can derive N4 rules. The N4 rules can instruct the UPF to enable RQoS for services with the included service data identifier.

[0087] SMF can generate QoS profiles for QoS flows carrying services of interest. The QoS profile may include the QoS flow ID (QFI) of the QoS flow carrying the service of interest. The QoS profile may include a Reflective QoS Attribute (RQA) to indicate that RQoS is enabled for that QoS flow.

[0088] If the UPF receives a DL packet whose service identification information matches a PDR with RQoS enabled, the UPF may determine to set the RQI field value to 1 in the GTP-U header and / or header extension of the DL packet and send the packet to the RAN node. This packet (e.g., sent by the UPF) may include the QFI value of the QoS flow of interest. The RAN can use the RQI value and / or QFI to provide this indication to the WTRU.

[0089] If the WTRU receives a DL packet with the RQI field set to 1 and / or a QFI value, the WTRU can generate a new UL QoS rule or update an existing QoS rule. The packet filter for the UL direction can be set to the packet filter determined based on the received DL packet. The QFI for the QoS flow for this QoS rule can be set to the QFI value received in the DL packet header. A priority value can be set (e.g., set to 80). The WTRU can start a timer associated with this QoS rule (e.g., called timer T3583). The timer value can be set to the last RQ timer value received by the WTRU and / or a default value. If the WTRU receives a new DL packet with both QFI and RQI, the timer (e.g., timer T3583) can be restarted, and the QoS rule update can be performed.

[0090] UL services using QoS rules derived from WTRU can share characteristics with DL services from which QFIs are derived. For example, when the DL service is TCP or UDP, the uplink service using QoS rules derived from WTRU can also be TCP or UDP. For example, the destination port of the uplink service can be equal to the source port of the uplink service. For example, the source port of the uplink service can be equal to the destination port of the uplink service. For example, the destination IP address of the uplink service can be equal to the source IP address of the uplink service.

[0091] This document describes reflected QoS at the SDAP layer. The SDAP layer is the user plane layer between the WTRU and RAN nodes. The SDAP layer may include the following functions: transmission of user plane data, mapping between QoS flows for DL ​​and / or UL (e.g., both) and DRB, QFI marking in DL and / or UL (e.g., both) packets, and / or mapping of reflected QoS flows for UL SDAP data PDUs to DRB.

[0092] The SDAP layer at the WTRU can be configured with UL QoS flow-to-DRB mapping. If there is no UL QoS flow-to-DRB mapping rule for this QoS flow, the SDAP entity can construct an end-of-flow control PDU, map the end-of-flow control PDU to the default DRB, and / or submit the end-of-flow control PDU to a lower layer.

[0093] If a previously stored UL QoS flow to DRB mapping rule exists, and if the mapping is different, the SDAP entity may update the UL QoS flow to DRB mapping rule to the new one, construct an end-of-flow marker PDU and map it to the DRB according to the previous QoS flow to DRB mapping rule, and / or send the PDU to a lower layer.

[0094] Reflection mapping can be enabled. For reflection mapping, if the SDAP entity at the WTRU receives a DL PDU with RDI set (e.g., set to 1), the SDAP entity can process the QFI field in the SDAP header, determine the QoS flow, and / or determine the QoS flow to DRB mapping based on the DLPDU. If the mapping rule differs from the stored QoS flow to DRB mapping, the SDAP entity can generate an end marker for the old mapping rule and send it to a lower layer. The SDAP entity can store the newly determined mapping. If the SDAP entity receives a DL PDU with the RQI field set to a value (e.g., 1) from the SDAP header of the DL PDU, the SDAP entity can provide the RQI and / or QFI to the NAS layer of the WTRU.

[0095] When a 5G system is executing UL / DL policy control based on round-trip latency requirements, and the PCF detects that the sum of the latency of UL and DL packets exceeds the round-trip latency requirements, the PCF needs to update the PCC rules used for UL and / or DL ​​services. Updating the PCC rules can trigger the SMF to generate new QoS rules for UL services and / or new N4 rules for DL ​​services.

[0096] Updating QoS rules may involve sending the updated QoS rules to the WTRU via signaling. If the PCF detects that a PCC rule can be adjusted, there may be a delay in applying that adjustment at the WTRU. This delay can result in more time elapsed before service processing can be adjusted. In scenarios where measured UL and DL delays vary and require frequent adjustments, individual implementations may become inefficient. Inefficiency may arise, for example, from frequent changes to PCC rules triggering frequent changes to QoS rules, thus requiring additional air signaling to send QoS rules to the WTRU. If there is more latency associated with XRM services, it may be desirable for the entities of interest (e.g., RAN and / or WTRU) to react quickly using the user plane.

[0097] The methods, embodiments, and implementations described herein may relate to faster RTT adjustments. Consider services (e.g., XRM services) that may include RT constraints and / or requirements. For example, in the downlink, video services may be sent from an application server to the WTRU. This service may be displayed in the WTRU and / or XRM device (e.g., an XR headset). In the uplink, the WTRU may send attitude information services to the application server (e.g., via 5GS) to notify the AS of new / updated attitude information. The AS can use this attitude information to determine what to send to the WTRU (e.g., video). In the example, UL and DL services may include RT latency requirements (e.g., attitude-to-position requirements).

[0098] DL and UL services, including those requiring RT (Real-Time Response), can be carried using different service data streams and via different QoS streams in the user plane. It is clear that UL and DL services can be carried using the same service data stream and can apply the same QoS stream. In the example, if the DL service is a video service and the UL service is gesture information, the protocols used to carry the UL and DL services can be different (e.g., audio services). UL services can be sent to a different destination IP address and / or port number combination than the source IP address and / or port number combination of the DL service.

[0099] The WTRU can be informed that an uplink flow is linked and / or associated with a downlink flow, which may have different characteristics than the uplink flow (e.g., using a different protocol). The WTRU can be informed how to map the uplink flow to a QoS flow based on the QoS flow used (e.g., by the base station) to transmit the downlink flow. In the example, the uplink QoS flow and the downlink QoS may have different requirements or parameters (e.g., different PDBs). The WTRU can be configured to determine the resources (e.g., QoS flows, DRBs, and / or logical channels) used to transmit uplink packets based on the network resources used to transmit downlink packets. This capability may be referred to as Associated QoS Flow (AQF).

[0100] AQF enables WTRU to create and / or update QoS flow information for UL services (e.g., attitude information), for example, when the service is linked to DL services (e.g., video) and / or is subject to RT requirements in 5GS.

[0101] In the example, the AQF indication can be used to adjust parameters to meet RTT requirements. If the reflected QoS feature indicates that uplink and downlink services use the same protocol and / or are associated with the same QoS requirements (e.g., PDB), the implementation of one or more reflected QoS features in a 5G system may not provide this functionality.

[0102] The WTRU can indicate to the network that it supports one or more AQF features. This indication can be provided to the SMF during PDU session establishment. The SMF can indicate to the PCF that the WTRU supports AQF features for that PDU session. If UL / DL policy control based on round-trip delay requirements is utilized, the PCF can use the support indication from the WTRU to determine whether to use AQF features, whether to monitor uplink and / or downlink QoS flows, and / or adjust the associated PCC rules as needed.

[0103] This article describes how to configure WTRU to adjust UL QFI based on DL services. Figure 2 At point 200, a system flowchart is depicted illustrating the provision and implementation of AQF at the WTRU. At point 202, the WTRU, SMF, AMF, PCF, and / or UPF may participate in the PDU session establishment process. The WTRU may send an indication to the network that it supports one or more AQF features. This indication may be sent in the PDU session establishment request and / or the NAS message carrying the PDU session establishment request. The SMF may receive the indication from the AMF that the WTRU supports one or more AQF features. The SMF may provide the indication that the WTRU supports one or more AQF features to the PCF serving the PDU session.

[0104] At position 204, the AF may invoke the NEF API (e.g., the Nnef_AfsessionWithQoS service) to request services for XRM services. The AF may include a RT latency indication and / or RT latency requirement in this request. The request message may include service flow descriptions for DL ​​services (e.g., video services) and / or UL services (e.g., attitude information). At position 206, the NEF may authorize the AF request and / or provide the PCF with the RT latency indication, RT latency requirement, UL service flow descriptor, and / or DL ​​service flow descriptor.

[0105] At 208, the PCF can use information provided by the AF (e.g., via the NEF) to generate PCC rules for XRM services. Based on the RT latency requirement received from the AF and an indication received that the WTRU supports the AQF feature, the PCF can determine to use AQF. The PCF can generate PCC rules (e.g., the QER portion of a PCC rule) that indicate the association between UL and DL service flows, and / or the RT latency requirements for UL and DL service flows. At 210, the PCF can send the PCC rules to the SMF.

[0106] At 212, the SMF can generate QoS rules, N4 rules, and / or QoS profiles. The SMF can build QoS rules for the WTRU. QoS rules can indicate that the AQF should be applied to traffic matching the UL packet filter. QoS rules can indicate the DL flows associated with the UL packet filter. QoS rules can indicate which DL flow is associated with the UL packet filter by describing the DL packet filter associated with it. In addition to providing the DL packet filter describing the associated DL flow, or as an alternative, QoS rules can include an association ID associated with the DL flow. The association ID can be, for example, a value sent to the WTRU when the WTRU receives some packets from the DL flow. The WTRU can use the DL packet filter and / or the association ID to detect whether DL packets are associated with the UL packet filter.

[0107] SMF can determine the association ID value, for example, upon receiving a new PCC rule. This value can be unique within a PDU session and can identify the association between UL and DL flows. If a QoS rule indicates that AQF should be applied to traffic matching UL packet filters, a QFI determination rule can be sent to the WTRU for the UL flow. The QFI determination rule for the UL flow will instruct the WTRU how to derive the UL flow's QFI based on the DL flow's QFI. For example, the QFI determination rule could indicate that if the downlink packet's QFI for the associated flow is X, then the uplink packet's QFI should be Y. In an example, the network could configure the WTRU to use the QFI associated with a relatively large PDB in the downlink and the QFI associated with a relatively small PDB in the uplink. The QFI determination rule can be part of a QoS rule.

[0108] The SMF can construct N4 rules for a PDU session. One or more N4 rules (e.g., constructed by the SMF) may include indications such as: AQF can be used for services matching DL video or UL services. One or more N4 rules (e.g., derived by the SMF) may include an association ID. In the example, the PDR for DL ​​and / or UL services may (e.g., additionally) include an association ID value. One or more N4 rules may indicate: DL services match SDF and / or packet filters associated with the association ID. Alternatively or additionally, the SMF may create a QoS profile for the PDU session. At 214, the SMF may trigger a PDU session modification process to send: N4 rules to the UPF, QoS rules to the WTRU, and / or the QoS profile to the RAN node.

[0109] At 216, the application server may send downlink traffic (e.g., video) to the UPF. At 218, the UPF may determine that a DL packet matches an N4 rule associated with an association ID. The UPF may detect that a DL packet matches an SDF and / or packet filter (e.g., indicated by an SMF) associated with an association ID. The UPF may detect that an AQF feature is applicable to the DL packet. At 220, the UPF may send a GTP-U message, including the packet and / or association ID, to the RAN node. The GTP-U header and / or GTP-U extended header (e.g., the GTP-U header and / or GTP-U extended header of a message from the UPF) may include a field that includes the association ID derived from the DL filter of the DL packet.

[0110] At position 222, the RAN node can encapsulate DL packets in an SDAP header and include the associated ID value in the SDAP header.

[0111] At 224, at the SDAP layer, the WTRU may receive DL packets and / or association IDs. Receiving the association ID triggers the WTRU to check whether the QoS flow allocation (e.g., QFI) of the UL flow associated with the flow of the DL packets should be updated. At 224, the WTRU can use the association ID to determine the UL packet filter associated with the downlink packets. The WTRU can use the association ID to determine which uplink service is associated with the DL packets. The WTRU can use the QFI determination rules and / or the QFI of the downlink packets to determine the QFI that should be allocated to the uplink service. Uplink QoS processing can be adjusted based on downlink QoS processing. This adjustment can cause shorter PDBs to be associated with uplink when relatively larger PDBs are associated with downlink. The WTRU may receive the QFI determination rules in the PDU session modification command at 214.

[0112] At position 226, the WTRU can receive UL traffic from higher layers (e.g., applications hosted at the WTRU). Uplink traffic can be matched against UL traffic filters associated with the associated ID. The WTRU can then transmit uplink traffic within the QoS flow determined at position 224.

[0113] This document describes configuring the RAN to adjust the UL QFI based on DL services. In addition to configuring the WTRU to adjust the UL QFI based on DL services, or as an alternative, the network can send QFI determination rules to the RAN node. If the RAN node receives a DL packet with an associated ID from the UPF, the RAN node can use the QFI of the DL packet and / or the QFI determination rules to determine the QFI of the associated UL packet. The RAN can then send the DL packet, the associated ID, and / or the determined UL QFI to the WTRU. The associated ID and / or the determined UL QFI can be included in the SDAP header. An example of the process is provided in [link to documentation]. Figure 3 As shown in the image.

[0114] Figure 3 This is a system flowchart depicting the configuration for providing AQF in the RAN, shown at point 300. Steps 302 to 310 can be similar to... Figure 2 Steps 202 to 210 as described in step 302. WTRU may have indicated support for AQF during the PDU session establishment or modification process in step 302.

[0115] At positions 304 and 306, the AF may request to reserve a session for XRM services, and may include a UL service descriptor, a DL service descriptor, and / or an RT delay indication and / or RT delay requirement. This request may be sent to the PCF (e.g., via the NEF).

[0116] At 308, the PCF can use RT delay indications and / or RT delay requirements to generate PCC rules for UL and DL flows. At 310, the PCF can send the PCC rules to the SMF.

[0117] At 312, the SMF can generate one or more N4 rules and / or QoS profiles. In the example, the SMF can build a QoS profile for a PDU session. The built QoS profile can include information about the QoS flows of the PDU session. The QoS profile can include QFI determination rules. The QFI determination rules can indicate that for a DL flow carried in a QoS flow with ID QFI X, the QoS flow ID of the UL flow associated with that DL flow should be QFI Y. The QoS profile can include an association ID that identifies the link between the DL flow and the UL flow of interest. The QoS profile can include indications that AQF should be applied to the QoS flow of interest and / or to the DL flow and UL flow linked by the provided association ID. Based on the information included in the QoS profile, the RAN node can determine that it should provide information about the UL flow associated with the DL flow in the header of the DL packet. If AQF is not enabled (e.g., the AQF field value is 0), the RAN node may not include information about the UL flow associated with the DL flow in the header of the DL packet.

[0118] SMF can construct N4 rules for PDU sessions. SMF can include the following indications in the N4 rules: TRQI can be used for services matching DL video or UL services. SMF can include an association ID in the resulting N4 rules. For example, the PDR for the DL and UL services of interest can include an association ID value. The N4 rules can indicate that a DL service matching a certain SDF and / or packet filter is associated with a certain association ID.

[0119] At 314, the SMF can send a QoS profile to the RAN node, and at 316, it can send N4 rules to the UPF. At 318, the application server can send downlink services (e.g., video) to the UPF. At 320, the UPF can detect AQF applicability and generate DL packets including an AQF indication and / or an associated ID. At 322, the UPF can send DL packets to the RAN node.

[0120] At 324, the RAN node can identify the QoS Flow ID (QFI) of the received DL packets. The RAN node can use the DL flow's QFI and / or association ID to determine the AQF that should be used for the UL flow associated with that DL. The RAN node can use the AQF determination rules in the QoS profile, the DL QFI, and / or the association ID to determine the QFI of the UL flow associated with the DL flow of interest. The RAN node can encapsulate the DL packets in an SDAP header, which may include an indication that AQF is enabled (e.g., an AQF field with a value of 1 in the SDAP header), the association ID, and / or the determined UL QFI. The RAN may include a field with a UL DRB value indicating the value and / or identifier of the UL DRB to which the UL packets of interest should be mapped. Based on this, the WTRU can create and / or update QoS flow to DRB mapping rules for the UL services of interest. At 326, the RAN node can send the DL packets to the WTRU.

[0121] In step 328, at the SDAP layer, the WTRU receives the DL packet, along with an AQF indication (e.g., an AQF field value of 1), an associated ID, and / or the QFI value of the UL QFI (e.g., and ultimately the DRB value for the UL DRB). Receipt of an AQF indication with a value of 1 triggers the WTRU to check whether the QoS flow assignment (e.g., QFI) of the UL flow associated with the flow of the DL packet needs to be updated.

[0122] The WTRU can use an AQF value of 1 to determine that the UL QFI to DRB mapping rule needs to be updated. The WTRU can use this UL QFI value, and optionally the UL DRB value, to update the QFI to DRB mapping of the UL flow. If no DRB value for the UL DRB is provided, the WTRU can determine to use the DRB value of the received DL packet.

[0123] At the NAS layer, the WTRU can receive packets from the SDAP layer. The WTRU can determine whether a QoS rule should be created / updated based on an AQF indication (e.g., a value of 1). If no previous QoS rule has been created for UL traffic utilizing a UL filter with an associated ID, the WTRU can determine to create a new QoS rule. The set of UL filters for the QoS rule can include the associated ID value provided to the WTRU from the RAN node. The QFI value of the QoS rule can be set to the UL QFI value (e.g., received from the RAN in the DL packet header). Based on this, UL traffic including a UL filter matching the associated ID of the rule can be carried / labeled on the QoS flow of the considered PDU session, where the QoS flow ID is the UL QFI value. The WTRU can set a priority value for the QoS rule (e.g., a low priority value indicates a high priority for the QoS rule). The WTRU can start a timer associated with the QoS rule. The duration of this timer can be set using an AQF timer value (e.g., provided by the network) or using a default value. If a QoS rule for the UL service filter already exists, and it includes a QFI value that differs from the UL QFI value received from the RAN in the DL packet, the WTRU can update the QoS rule, for example, by changing the QFI value to the received UL QFI value. The WTRU can then restart the timer associated with that QoS rule.

[0124] At position 330, the WTRU can receive UL traffic from higher layers (e.g., applications hosted at the WTRU). Uplink traffic can be matched against UL traffic filters associated with the associated ID. The WTRU can transmit uplink traffic within the QoS flow determined at position 328.

[0125] This article describes the adjustment of UL QFI based on DL services. Figure 4 The system flowchart at point 400 depicts the use of AQF to adjust UL QFI based on DL services.

[0126] At position 402, a PDU session can be established between the WTRU and the PSA UPF. XRM services can be exchanged between the WTRU and the AS. XRM services may include DL and UL flows, which may be subject to RT latency requirements. RT latency requirements can be configured in the 5GS. RT latency indications from the AF may exist (e.g., at position 402). The PCF can generate PCC rules (e.g., two, for uplink and downlink services). PCC rules can be generated after determining that the UL PDB and DL PDB meet the RT latency requirements. PCC rules may include indications to enable AQF.

[0127] At position 404, the RAN node can monitor the RT latency of XRM services. Based on determined and / or received (e.g., from UPF) RT latency monitoring measurements, in this example, the RAN node can determine that the RT latency measurement exceeds an RT latency threshold. The RAN node can then determine to adjust the RTT using AQF capabilities.

[0128] The RAN node can determine the association ID of DL and UL flows based on information from the monitored data packets. For example, the RAN node can use DL packets from the DL or UL flows of interest for RT delay monitoring, which may include the association ID in the packet header. The RAN can use this information to identify the association ID value. The RAN node can store the association ID, which links the UL and DL flows associated with the RAN performing RT delay monitoring for a pair of UL and DL flows. At 406, the RAN can use the association ID and / or RT monitoring results to determine the QFI value of the DL flow.

[0129] Alternatively or additionally, the RAN may receive an indication from the UPF that the RT delay can be adjusted. This indication may include RT delay monitoring results and / or QFI recommendations for the DL flow.

[0130] RAN nodes can use the associated ID, RT monitoring results, the QFI of the DL flow, and / or determination rules determined at the RAN (e.g., in a QoS profile) to determine the value of the UL QFI for the UL flow of interest. The QFI value (e.g., a new value) for the QFI of the UL service (e.g., attitude information) may have a UL PDB value that reduces the total RT latency. The RAN may also include, for example, a ratio or percentage value of the RT latency requirement consumed by the DL or UL path in the DL packet that includes the determined QFI. The RAN may also include a ratio, percentage, and / or value of the expected UL latency for the UL QoS flow path.

[0131] The RAN can encapsulate DL packets in an SDAP header, which may include: an AQF indication (e.g., a value of 1 indicating that the AQF feature is enabled), the association IDs of the DL and UL flows of interest, and / or the ULQFI value to be used by the WTRU for the UL flows of interest. DL packets may be, for example, user plane DL packets from DL flows, DL monitoring packets for the DL flows of interest, or packets constructed by the RAN node to inform the WTRU of adjustments to be adopted.

[0132] The RAN can determine a new value for the UL DRB for UL services of interest, which is either UL DRB or identified as UL DRB. In the example, this determination may be based on RT monitoring results determined by the RAN, QFI recommendations received from the UPF, received from the UPF, and / or determined by the RAN. In the example, the RAN can determine to include the new UL DRB value in the SDAP encapsulation header of the DL data packet to be sent to the WTRU. At 408, the RAN can send the DL data packet to the WTRU.

[0133] At 410, the WTRU can use the information received in the header of the DL packet to determine which QoS rules are available for AQF and / or which are updatable for the UL flows of interest. The WTRU can determine the UL QFI value as received by the RAN from the SDAP header of the DL packet.

[0134] At the SDAP layer, the WTRU can use an AQF indication value (e.g., a value of 1) to determine if DL information can be used to update the UL's QoS flow to DRB mapping (e.g., at the SDAP layer). If the RAN includes the UL DRB value in the SDAP header of the DL packet, the WTRU can determine to use that value as the new UL DRB value. If the RAN does not provide such a value in the DL packet SDAP header, the WTRU can determine to use DL packet DRB information (e.g., values ​​and / or identifiers) for the UL DRB.

[0135] WTRU can use the associated ID, UL QFI value and / or AQF indication provided by RAN in the SDAP header of DL packets to determine the QoS rules to be updated, and can use this information to update the QoS rules.

[0136] At 412, the WTRU can receive UL packets for XRM services from higher layers (e.g., applications hosted at the WTRU). The WTRU can use the associated ID and / or UL packet filter ID to match them with the packet filters of QoS rules and determine the QoS rules to be applied to that UL packet.

[0137] The WTRU can define a QoS rule where packet filters match the packet filter information of UL packets (e.g., having the same association ID value). The WTRU can use the QoS rule to determine the QFI value of uplink packets. At the SDAP layer, the WTRU can use the QFI-to-DRB mapping to determine on which DRB to send UL packets. The WTRU can tag UL packets using the QFI field of the UL QFI and can send UL packets to the AS.

Claims

1. A wireless transmit / receive unit (WTRU) including a processor, the processor being configured to: Receive QoS rules from the network, wherein the QoS rules indicate that the associated QoS flow (AQF) should be applied to uplink traffic that matches the uplink packet filter; Receive downlink packets in a PDU session, wherein the downlink packets indicate an association identifier (ID); Based on the association ID, it is determined that the uplink data packet is associated with the downlink data packet; Based on the QoS rules and the first QoS flow identifier (QFI) of the downlink data packet, determine the second QFI to be assigned to the uplink data packet; as well as The uplink data packet is sent to the network according to the determined second QFI.

2. The WTRU of claim 1, wherein the processor is further configured to: The uplink data packets are received from the application hosted on the WTRU.

3. The WTRU of claim 1, wherein the processor is further configured to: Determine if the uplink data packet matches the uplink data packet filter.

4. The WTRU of claim 1, wherein the processor is further configured to: Based on the association ID, check whether the QoS flow allocation of the uplink flow associated with the downlink data packet flow needs to be updated.

5. The WTRU of claim 1, wherein the QoS rule includes an AQF indication.

6. The WTRU of claim 1, wherein the QoS rule includes one or more QFI determination rules.

7. The WTRU of claim 1, wherein the processor is further configured to: Send a message to the network indicating that the WTRU supports AQF.

8. The WTRU of claim 1, wherein the processor is further configured to: Based on the association ID, multiple uplink data packets are identified as being associated with the downlink data packets; Assign the second QFI to each of the plurality of uplink packets; and The plurality of uplink data packets are sent according to the determined second QFI.

9. The WTRU of claim 1, wherein the second QFI is different from the first QFI.

10. The WTRU of claim 1, wherein the second QFI is determined based on the QoS rules and the first QFI of the downlink packet, wherein the second QFI is selected based on the packet delay budget (PDB) associated with the first QFI and the round-trip time associated with the downlink packet.

11. A method for use in a wireless transmit / receive unit (WTRU), the method comprising: Receive QoS rules from the network, wherein the QoS rules indicate that the associated QoS flow (AQF) should be applied to uplink traffic that matches the uplink packet filter; Receive downlink packets in a PDU session, wherein the downlink packets indicate an association identifier (ID); Based on the association ID, it is determined that the uplink data packet is associated with the downlink data packet; Based on the QoS rules and the first QoS flow identifier (QFI) of the downlink data packet, determine the second QFI to be assigned to the uplink data packet; as well as The uplink data packet is sent to the network according to the determined second QFI.

12. The method of claim 11, further comprising: The uplink data packets are received from the application hosted on the WTRU.

13. The method of claim 11, further comprising: Determine if the uplink data packet matches the uplink data packet filter.

14. The method of claim 11, further comprising: Based on the association ID, check whether the QoS flow allocation of the uplink flow associated with the downlink data packet flow needs to be updated.

15. The method of claim 11, wherein the QoS rule includes an AQF indication.

16. The method of claim 11, wherein the QoS rule comprises one or more QFI determination rules.

17. The method of claim 11, further comprising: Send a message to the network indicating that the WTRU supports AQF.

18. The method of claim 11, further comprising: Based on the association ID, multiple uplink data packets are identified as being associated with the downlink data packets; The second QFI is assigned to each of the plurality of uplink packets; as well as The plurality of uplink data packets are sent according to the determined second QFI.

19. The method of claim 11, wherein the second QFI is different from the first QFI.

20. The method of claim 11, wherein the second QFI is determined based on the QoS rules and the first QFI of the downlink packet, wherein the second QFI is selected based on the packet delay budget (PDB) associated with the first QFI and the round-trip time associated with the downlink packet.

Images