Communication associated with relative importance

Abstract

Systems, methods, and instrumentalities are disclosed for a user plane function (UPF) to determine relative protocol data unit (PDU) set importance within a quality of service (QoS) flow. A first network node (e.g., a UPF) may receive, from a second network node, a first message indicating a protocol data unit (PDU) set allocation rule associated with a quality of service (QoS) flow. The first network node may receive a first downlink PDU. The first network node may determine a PDU set value associated with the first downlink PDU based on a PDU set allocation rule and one or more of a PDU set base value or a previous PDU set value corresponding to a previous PDU. The first network node may send the second message to a third network node. The second message may include the first downlink PDU and an indication of a PDU set value.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 442,916, filed February 2, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communications using wireless communication continue to evolve. The fifth-generation mobile radio access technology (RAT) can be referred to as 5G New Radio (NR). Previous-generation (traditional) mobile communication RATs could be, for example, fourth-generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] A system, method, and means are disclosed for a User Plane Function (UPF) to determine the relative importance of Protocol Data Unit (PDU) sets within a Quality of Service (QoS) flow. A first network node (e.g., a UPF) can receive a first message from a second network node, the first message indicating a PDU set allocation rule associated with the QoS flow. The first network node can receive a first downlink PDU. The first network node can determine a PDU set value associated with the first downlink PDU based on the PDU set allocation rule and one or more of a PDU set base value or a previous PDU set value corresponding to a previous PDU. The first network node can send a second message to a third network node. The second message may include an indication of the first downlink PDU and the PDU set value.

[0004] PDU set allocation rules can be associated with PDU set reset triggers that indicate conditions. The first network node can allocate a PDU set base value as the PDU set value based on the met conditions. PDU set allocation rules can be associated with PDU set reset triggers. PDU set reset triggers can indicate time values.

[0005] If the duration associated with a PDU set for a transmitted or received QoS flow exceeds a time value, the first network node may assign a PDU set base value as the PDU set value for the second downlink PDU. The first network node may determine the PDU set allocation rule to be applied to the first downlink PDU based on the application type. The PDU set allocation rule may include a PDU set importance (PDSI) allocation rule. The PDU set base value may include a PDSI base value. Previous PDU set values ​​may include previous PDSI values. The PDU set base value may indicate the starting value of the PDU set importance value. Attached Figure Description

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

[0007] Figure 1B is a diagram illustrating an example wireless communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that Figure 1A is a system diagram of an example wireless transmit / receive unit (WTRU) that can be used within the communications system 100 shown in FIG. 1 according to an embodiment;

[0008] Figure 1C is a system diagram of an example wireless transmit / receive unit (WTRU) that can be used within the communications system 100 shown in FIG. 1 according to an embodiment; Figure 1A is a system diagram of an example wireless transmit / receive unit (WTRU) that can be used within the communications system 100 shown in FIG. 1 according to an embodiment;

[0009] Figure 1D is a system diagram of an example wireless transmit / receive unit (WTRU) that can be used within the communications system 100 shown in FIG. 1 according to an embodiment; Figure 1A is a system diagram of an example wireless transmit / receive unit (WTRU) that can be used within the communications system 100 shown in FIG. 1 according to an embodiment; and

[0010] Figure 2 is a system diagram of an example wireless transmit / receive unit (WTRU) that can be used within the communications system 100 shown in FIG. 1 according to an embodiment; DETAILED DESCRIPTION

[0011] Figure 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments can be implemented. The communication system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the

[0012] As Figure 1AAs shown, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which can be referred to as a "station" and / or a "STA") can be configured to transmit and / or receive wireless signals, and can include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot or other wireless devices operating in an industrial and / or an automated processing chain environments), a consumer electronics, a device operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0013] The communication system 100 can also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface

[0014] The base stations 114a can be part of the RAN 104 / 113, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base stations 114a and / or the base stations 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrums. A cell can provide wireless service coverage to a particular geographic area, which can be relatively fixed or can change over time as users who are using the cells move throughout the network. The cell can further be divided into cell sectors. For example, a cell associated with a base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, one for each sector of the cell. In one embodiment, the base station 114a can employ multiple-input multiple-output (MIMO) techniques, and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0015] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the 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.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0016] More specifically, as noted above, the communications 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, and the like. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). 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).

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

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

[0019] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access and NR wireless access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

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

[0021] For example, Figure 1AThe base station 114b in the RAN 104 / 113 can be a wireless router, Home Node B, Home eNode B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity access. The base station 114b and the WTRUs 102c, 102d in the RAN 104 / 113 can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106 / 115. Figure 1A

[0022] The RAN 104 / 113 can be in communication with the CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in Figure 1A Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which can employ a NR radio technology, the CN 106 / 115 can also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0023] ​CN 106 / 115 can also serve 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 use the same RAT as RAN 104 / 113 or a different RAT.

[0024] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the 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 base station 114a, which can use cellular-based radio technology, and to communicate with base station 114b, which can use IEEE 802 radio technology.

[0025] Figure 1B This shows a system diagram of an example WTRU 102. (See diagram below.) Figure 1B As shown, among other things, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0026] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but can be integrated together in an electronic package or chip.

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

[0028] Although the transmit / receive element 122 is depicted in the WTRU 102 Figure 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to facilitate MIMO technology. In this embodiment, the transmit / receive element 122 can be configured to transmit and / or receive wireless signals, respectively, using multiple antennas.

[0029] The transceiver 120 can be configured to modulate information to be transmitted by the transmit / receive element 122 and to demodulate information received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[0030] The processor 118 of the WTRU 102 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 can access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0032] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or

[0033] The processor 118 can further couple to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands- free headset, a Bluetooth® The peripheral 138 can include one or more sensors, which can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, a compass sensor, a proximity sensor, a temperature sensor, a time sensor; a geo-location sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a posture sensor, a biometric sensor, and / or a humidity sensor.

[0034] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals (e.g., some or all signals associated with particular subframes for both the UL (e.g., for transmission) and the downlink (e.g., for reception) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or eliminate self-interference and / or cross- interference due to concurrent transmission and reception. In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals (e.g., some or all signals associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception) are not concurrent.

[0035] Figure 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can be in communication with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

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

[0037] Each of eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown, the eNode-Bs 160a, 160b, 160c can communicate with one another over an X2 interface. Figure 1C

[0038] Figure 1C The CN 106 can include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166, as shown. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0039] The MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 can provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

[0042] ​The CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Further, the CN 106 can facilitate communications with other networks 112. Other networks 112 can include other wired or wireless networks that are owned and / or operated by other service providers. In

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

[0044] In representative embodiments, the other network 112 can be a WLAN.

[0045] A WLAN in an infrastructure Basic Service Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS can arrive through the AP and can be delivered to the STAs by the AP. Traffic originating from STAs to destinations outside the BSS can be sent to the AP to be delivered to respective destinations depending on the traffic. Traffic between STAs within the BSS can be sent using a direct link between the source and destination STAs with possible involvement of the AP (e.g., to provide QoS, to authenticate the STAs, to authorize the STAs, etc.). The involvement of the AP can depend on whether the STAs belong to the same group, whether the STAs are associated with the AP, the availability of a direct link between the STAs, the security settings of the STAs, etc.

[0046] When using an 802.11 ac infrastructure mode of operation or similar, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or dynamically set through signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems, with collision avoidance. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If a particular STA senses / detects the primary channel and / or determines that the primary channel is busy, the particular STA can back off. One STA (e.g., only one station) can transmit in a given BSS at any given time.

[0047] High Throughput (HT) STAs can use 40 MHz wide channels, for example, by combining the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0048] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be parsed into two streams by a segment parser. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be done on each stream separately. The streams can be mapped on to the two 80 MHz channels and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described 80+80 configuration operations can be reversed, and the combined data can be sent to the Medium Access Control (MAC).

[0049] 802.11af and 802.11ah support sub-1 GHz modes of operation. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11η and 802.1 lac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support metering type control / machine type communications, such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

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

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

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

[0053] The RAN 113 can include gNBs 180a, 180b, 180c, although the RAN 113 can include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c can implement MIMO technology. For example, gNBs 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c can implement carrier aggregation technology. For example, the gNB 180a can transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0054] The WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using transmissions associated with the extensible numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or lasting varying lengths of absolute time).

[0055] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with the gNBs 180a, 180b, 180c without also accessing other RANs, such as eNode-Bs 160a, 160b, 160c. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize signal transmission and reception over an unlicensed frequency band with gNBs 180a, 180b, 180c. In the non-standalone configuration, the WTRUs 102a, 102b, 102c can communicate / be connected with the gNBs 180a, 180b, 180c, while also communicating / being connected with another RAN, such as eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c can implement DC principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c can serve as a mobility anchor for the WTRUs 102a, 102b, 102c and the gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to the WTRUs 102a, 102b, 102c.

[0056] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b, and the like. As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface. Figure 1D As shown, the gNBs 180a, 180b, 180c can be in communication with the AN 180a, 180b, 180c over an Xn interface.

[0057] Figure 1DThe illustrated CN 115 can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0058] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and can serve as the control node. For example, the AMF 182a, 182b can be responsible for authenticating the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the WTRU 102a, 102b, 102c registration area, termination of NAS signaling, mobility management, and the like. The AMF 162 can utilize network slicing to tailor CN support for the WTRUs 102a, 102b, 102c based on the type of service being accessed by the WTRUs 102a, 102b, 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, and / or the like. The AMF 162 can provide control plane functionality such as switching, handover, QoS, and throttle management.

[0059] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b can also be connected to the UPF 184a, 184b in the CN 115 by an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. PDU session types can be IP-based, non-IP based, Ethernet-based, and the like.

[0060] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0061] The CN 115 can facilitate communications with other networks. For example, the CN 115 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface between the UPF 184a, 184b and the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

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

[0063] The one or more emulation devices can perform one or more, or all, of the functions while not implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices can be utilized in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement test scenarios in order to test one or more components. The one or more emulation devices can be test equipment. The emulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas).

[0064] The one or more emulation devices can perform one or more, or all, of the functions while not implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices can be utilized in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement test scenarios in order to test one or more components. The one or more emulation devices can be test equipment. The emulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas).

[0065] Features described herein can be associated with a PDU Set. A PDU Set can be one or more PDUs that carry the payload of an information unit generated at the application level (e.g., a frame or video slice for an extended reality (XR) service).

[0066] PDU Set Importance can be the importance of a PDU Set within a QoS Flow. NG-RAN can use PDU Set Importance for PDU Set level packet dropping when there is congestion.

[0067] PDU Set information can be different for different PDU Sets within a QoS Flow. There can be no defined mechanism for how and whether to interpret PDU Set Importance across QoS Flows. There can be no defined mechanism for how a WTRU and RAN determine when to use PDU Set Importance, when to use QoS Flow Priority, and when to use a combination of PDU Set Importance and QoS Flow Priority to make packet dropping decisions.

[0068] Features described herein can be associated with a QoS Flow. A UPF can assign downlink packets to a QoS Flow based on rules (e.g., N4 rules) configured in the UPF by a SMF. A WTRU can assign uplink packets to a QoS Flow based on QoS rules configured in the WTRU by a SMF. The QoS rules can be sent to the WTRU in a PDU Session Establishment Accept message or a PDU Session Modification Command message.

[0069] A QoS flow can be identified with a QoS Flow ID (QFI). The QFI (e.g., in downlink) can be carried from a UPF to a RAN in an encapsulation header (e.g., over N3 and / or N9). The (R)AN can map PDUs from a QoS flow to access-specific resources based on the QFI and associated QoS profile (e.g., associated 5G QoS profile). The QoS profile associated with a QFI can be configured by the SMF in the RAN.

[0070] In downlink, the SMF can configure the UPF to detect what QoS flow a downlink packet is mapped to, and the SMF can configure the RAN with information about forwarding treatment of the QoS flow.

[0071] In uplink, the SDAP layer can use QoS rules and QFI of a QoS flow to determine a DRB for a packet. The packet and selected DRB can be sent from the SDAP layer to lower layers. The lower layers can use DRM to map the PDU to access-specific resources. The QoS profile associated with a QFI can be configured by the SMF in the RAN.

[0072] In uplink, the SMF can configure the WTRU to detect what QoS flow an uplink packet is mapped to, and the SMF can configure the WTRU with information about forwarding treatment of the QoS flow.

[0073] Different types of media can be mapped to the same QoS flow. In an example, if two types of media (e.g., video and haptic feedback) have similar delay budget characteristics (e.g., requirements), the two types of media can be mapped to the same QoS flow. A single QoS flow can carry multiple types of media flows or data flows.

[0074] A QoS flow can be associated with a priority level. In downlink, the SMF can configure a network node (e.g., RAN / RAN node) with information about forwarding treatment of the QoS flow. A QoS flow can be associated with a 5QI value. The 5QI value can be translated into the following characteristics used in DL for determining packet forwarding treatment: resource type (e.g., non-GBR, GBR, delay-critical GBR); priority level; packet delay budget (e.g., including core network packet delay budget); packet error rate; average window (e.g., for GBR and delay-critical GBR resource types); and maximum data burst amount (e.g., for delay-critical GBR resource type).

[0075] For a QFI, the QoS profile can indicate a 5QI value and a priority associated with the QFI. When a priority level is included in the QoS profile, the priority in the QoS profile can override the priority level associated with the 5QI. The priority level in the QoS profile can override the priority level associated with the 5QI in a mapping table.

[0076] The priority level associated with the 5G QoS characteristics can indicate a priority of scheduling resources in a QoS flow.

[0077] The SMF can provide a packet detection rule (PDR) to the UPF. The PDR can be associated with a QoS enforcement rule (QER). The QER can be applied when the UPF detects a packet matching the PDR.

[0078] The PDR can include a set of IP packet filters, and the QER can be applied if the traffic matches an IP filter. The PDR can include an application ID. The application ID can be an index to a set of application detection rules configured in the UPF. The application detection rules can be more granular than a simple IP filter.

[0079] A packet flow descriptor (PFD) can be sent to the SMF, and the SMF can provide the PFD to the UPF. The PFD can contain application detection rules. As described herein, the rules can be more granular than an IP filter (e.g., a simple IP filter). In an example, the descriptor can include a simple IP filter or a URL (or domain name, or protocol) that can be matched. The PFD can have an application ID.

[0080] When the SMF obtains the PFD, the SMF can look at the application ID of the PFD and check which PDRs have the same application ID. The SMF can check which UPFs have PDRs with matching application IDs. The SMF can send the PFD to the UPFs (e.g., all UPFs identified by the SMF).

[0081] The SMF can send a QoS rule to the WTRU and a QER to the UPF. There can be no PFD-like functionality in the WTRU. The network can tell the WTRU to apply a certain QFI value to a certain IP flow, and the network can not tell the WTRU to apply a certain QFI value when the network detects a certain URL name.

[0082] Packet importance can be derived from the application layer header. Application layer messages can be carried via a protocol that indicates the type of payload carried in the message. In an example, RTP messages can carry (e.g., different) types of payloads. The format of the RTP header can vary depending on the type of payload. For (e.g., some) types of payload, the header can include an indication of the type of packet. In an example, when the RTP payload carries H.265 data, the RTP header can include a NAL unit type indication that indicates whether the payload is a single NAL unit packet, part of a packet aggregation, a segment unit, or a PACI packet. The NAL unit type indication can be used to indicate the importance of the payload.

[0083] The (e.g., different) type of application layer protocol is MOQ. In MOQ, the application can set an importance value or a preferred delivery order that has no absolute meaning. The importance value can indicate the importance relative to the importance of surrounding application layer messages.

[0084] The SDAP layer of the WTRU can map QoS flows to DRBs. One or more QoS flows can be mapped to one DRB. In the UL, one QoS flow can be mapped to one DRB at a time.

[0085] In downlink, the UPF can be configured with rules that the UPF can use to detect the format of the media carried in a PDU set. When the format of a PDU set is detected, the UPF can use information included in the header of the PDU to determine what PDU set importance to assign to the PDU set. In an example, if the UPF detects that the format of the PDU set is H.266 RTP, the UPF can use the NAL unit type field of the header to determine the PDU set importance value. If the PDU set importance value is a 4-bit value, an example of a direct mapping from NAL unit type field value to PDU set importance value can be as follows.

[0086] The UPF can assign a PDU set importance value of 1 for (e.g., all) NAL unit type values of 0-25. The UPF can assign a PDU set importance value of 3 for (e.g., all) NAL unit type values of 28. The UPF can assign a PDU set importance value of 2 for (e.g., all) NAL unit type values of 29. The UPF can assign a PDU set importance value of 0 for (e.g., all) NAL unit type values of 26-27 and 30-31.

[0087] In examples described herein, the type of media carried in a QoS flow can vary can not be considered. In examples, a QoS flow can carry H.266 RTP payloads and haptic feedback. Using separate PDU set importance determination rules for one type of media can result in allocated PDU set importance values that do not accurately reflect the relative importance of (e.g., each) PDU set. The RAN can be impacted to discard packets that are relatively more important than other packets in other QoS flows that can be discarded.

[0088] It can not be practical for application developers to set application layer importance and importance values that are specific to a network (e.g., a 5G network). The network can determine the importance of a packet based on information (e.g., a header or a payload) derived (or detected) in an application layer message.

[0089] Example methods can be associated with UPF-enabled configurations such that a UPF can detect and indicate the relative importance of PDU sets, e.g., when a QoS flow carries different types of media.

[0090] As described herein, when a RAN node receives PDU sets from UPF(s), the RAN node can use PDU set importance values to decide which PDU sets can (e.g., should) be discarded in a congestion situation. The PDU set importance values can indicate the relative importance of PDUs carried in a QoS flow, and the RAN node can be configured with information to help determine the importance of a PDU set relative to PDU sets of (e.g., other) QoS flows. As described above, a priority level of a single QoS flow indicates the relative importance of the QoS flow relative to other QoS flows. Examples of determining which PDU set(s) to discard during a congestion situation can be as follows: a discardable (e.g., any discardable) PDU set in a lowest priority QoS flow with a lowest importance value can be discarded. A discardable (e.g., any discardable) PDU set in the lowest priority QoS flow with a next highest importance value can be discarded. The RAN can continue in this manner (e.g., discard PDU sets in the lowest priority QoS flow with a next highest importance value) until (e.g., all) PDU sets of the lowest priority QoS flow are discarded. (e.g., All) PDU sets of the lowest priority QoS flow can be discarded, and the RAN can start discarding PDU sets from a next highest priority QoS flow.

[0091] In examples described herein, the RAN can discard (e.g., all) sets of PDUs from low priority QoS flows without discarding sets of PDUs from high priority QoS flows. A user can perceive the fact that (e.g., all) sets of PDUs are discarded from low priority QoS flows. At the same time, there can be sets of PDUs of relatively lower importance available to be discarded in high priority QoS flows. If the set of PDU discarding has been rolled out across more QoS flows, the packet discarding can be less perceptible to a user.

[0092] Example methods can be associated with enabling configurations of a RAN such that the RAN can roll out PDU set discarding events more evenly across QoS flows. Such configurations can not instruct the RAN to make discarding decisions that are evenly distributed across QoS flows, and can direct the RAN to make (e.g., more) balanced decisions that are less (e.g., not) perceptible to a user.

[0093] In uplink, a WTRU can be configured with rules that the WTRU can use to detect the format of media carried in a set of PDUs. When the format of a set of PDUs is detected, the WTRU can use information included in the header of the PDU to determine what PDU set importance to assign to the set of PDUs. In an example, if the WTRU detects that the format of the payload / set of PDUs is H.264 RTP, the WTRU can use the payload type field of the header to determine a PDU set importance value. If the PDU set importance value is a 4-bit value, examples of mapping described herein that occur at a UPF can occur at a WTRU. This example can result in drawbacks described herein. This example can not account for (e.g., well account for) the fact that the type of media carried in a QoS flow can vary.

[0094] Example methods can be associated with enabling configurations of a WTRU, such as a WTRU upper layer (e.g., a WTRU SDAP layer), such that the WTRU upper layer can detect and indicate the relative importance of a set of PDUs when a QoS flow carries different types of media. The WTRU upper layer can provide relative importance information to lower layers (e.g., lower layers of the WTRU) such that the lower layers can efficiently (e.g., more efficiently) prioritize the priority of sets of PDUs across QoS flows and within QoS flows. Efficient prioritization of sets of PDUs can include the lower layers using information provided by the SDAP layer to determine how many QoS flows with a relatively lower priority level can be deprioritized before a PDU from a QoS flow with a relatively higher priority level is deprioritized from being preferred from a QoE perspective.

[0095] Features described herein can be associated with how to modify (e.g., 5G) systems according to how to handle downlink traffic. Enhancements can describe how a UPF can determine the importance of a PDU set relative to a PDU set previously transmitted in the same QoS flow and provide the importance information to a RAN node. The RAN node can be configured with information so that the RAN can prioritize packets based on the PDU set importance value and the priority level of the QoS flow, and based on how much traffic can be dropped from the QoS flow before the user detects QoE degradation. The RAN node can select packets for dropping in a way that is unlikely to impact overall user QoE.

[0096] Features described herein can be associated with how to modify (e.g., 5G) systems according to how to handle uplink traffic. Enhancements can describe how a WTRU upper layer can determine the importance of a PDU set relative to a PDU set previously transmitted in the same QoS flow and provide the importance information to a WTRU lower layer. The WTRU lower layer can prioritize packets based on the PDU set importance value and the priority level of the QoS flow, and based on how much traffic can be dropped from the QoS flow before the user detects QoE degradation. The WTRU can prioritize packets in a way that is unlikely (e.g., less likely) to impact overall user QoE.

[0097] Features described herein can be associated with downlink handling of PDU set importance. In the downlink, data can be transmitted from an application server to a WTRU. Data from the application server can enter a (e.g., 5G P) core network via a UPF. The UPF can use a PDU session of the WTRU to deliver data to the WTRU via a RAN node. A SMF can configure the UPF and the RAN node with information used by the UPF and the RAN node to determine how to handle (e.g., prioritize) traffic of the PDU session. It can be described below how the SMF, the UPF, and the RAN node can determine the importance of a PDU, assign an importance value to the PDU, and use the PDU set importance value to prioritize the PDU so that a user of the WTRU is unlikely to notice a degradation of QoE during congestion when the PDU is dropped (e.g., needs to be dropped) by the network (e.g., the RAN node). The SMF can configure the UPF and the RAN node based on PCC rules received from a PCF. The PCF can derive the PCC rules based on information received from an AF / AS.

[0098] In an example (e.g., downlink), a relative importance can be identified and can be conveyed to the RAN node. The UPF can be configured with PDU set importance assignment rules that the UPF can use to determine the importance of a PDU set relative to a PDU set most recently transmitted from the UPF to the RAN node.

[0099] A network node (e.g., a user plane function (UPF)) can receive a rule, such as a packet data unit (PDU) set importance (PDSI) allocation rule, e.g., the PDSI rule can be received in a first message (e.g., an N4 message). The PDSI rule can be received from an SMF. As described herein, a PDU set allocation rule and a PDSI allocation rule can be used interchangeably (e.g., a PDU set allocation rule can include a PDSI allocation rule). As described herein, a PDU set base value and a PDSI base value can be used interchangeably (e.g., a PDU set base value can include a PDSI base value). As described herein, a previous PDU set value and a previous PDSI value can be used interchangeably (e.g., a previous PDU set value can include a previous PDSI value).

[0100] The PDSI allocation rule can be associated with a QoS flow. The UPF can receive a downlink data packet (e.g., a PDU). The UPF can determine a PDU set importance value associated with the downlink data packet (e.g., for the downlink data packet) based on the PDSI allocation rule and one or more of a PDSI base value or a PDU set importance of a previous downlink data packet (e.g., a previous PDU). The UPF can send (e.g., in a second message) the downlink data packet and the PDU set importance value of the downlink data packet (e.g., to a RAN node, e.g., in a GTP-U message).

[0101] The PDSI allocation rule can be associated with an application identifier (e.g., an application type). The application identifier can be used to determine to apply the PDSI allocation rule (e.g., detection of the application identifier can be used to determine to apply the PDSI allocation rule). The application identifier can be used to determine what relative importance determination (RID) rule (e.g., within the PDSI allocation rule) to use to determine a PDU set importance value to assign to the downlink data packet.

[0102] The PDSI allocation rule can be associated with a PDSI base value that indicates a starting value for a PDU set importance value.

[0103] The PDSI allocation rule can be associated with a PDSI reset trigger that indicates a condition. Based on the condition being satisfied, the UPF can assign the PDSI base value as a PDU set importance value to the downlink data packet.

[0104] Protocol data unit (PDU) set importance (PDSI) assignment rules can include information indicating assignment rules for PDU set importance (e.g., priority of PDU set). As described herein, PDU set importance and PDSI can be used interchangeably. PDSI assignment rules, logical rules, priority rules, importance rules, and logical priority rules can be used interchangeably herein. In an example, PDSI assignment rules can include logical rules that can determine importance of a PDU set. In an example, PDSI assignment rules can include data and / or code that, when processed by a processor, can determine importance. In an example, PDSI assignment rules can include information corresponding to one or more of: a protocol discriminator, a security header, an authorization code, a sequence number, a message type, and / or a payload container. PDSI assignment rules can affect priority of a PDU with respect to a layer (e.g., a particular layer) of a WTRU. PDSI assignment rules can include information indicating logical rules that can determine importance (e.g., objective importance, relative importance, etc.) of data (e.g., PDU, PDU set, QoS flow, etc.). Data can have a priority (e.g., a particular priority) in a layer (e.g., a particular layer). PDSI assignment rules can be associated to a priority (e.g., high / medium / low) associated with a layer.

[0105] A reset trigger can indicate a time value, and if a duration between PDU sets of a QoS flow (e.g., same QoS flow) received or transmitted exceeds the time value (e.g., on a condition that a duration associated with PDU sets of a QoS flow transmitted or received exceeds the time value), the UPF can assign (e.g., be triggered to assign) a PDSI base value as a PDU set importance value for a next downlink data packet (e.g., second downlink PDU).

[0106] A reset trigger can indicate an application ID (e.g., application type). If the UPF detects that a downlink packet matches an application detection rule identified by the application ID, the UPF can be triggered to assign a PDSI base value as a PDU set importance value for the downlink data packet.

[0107] A reset trigger can indicate a protocol / media type / field value combination, and if the UPF detects that a downlink packet matches the combination, the UPF can be triggered to assign a PDSI base value as a PDU set importance value for the downlink data packet.

[0108] The PDSI allocation rule can (e.g., also can) be associated with a RID rule that identifies a PDSI mapping algorithm (e.g., previously) configured in the UPF and that identifies PDSI mapping algorithm parameters used to configure the identified algorithm. One example of a PDSI mapping algorithm parameter can include a reset trigger and a base value. One example can include a PDSI step value that indicates how much the PDSI can increase or decrease.

[0109] When the UPF sends a PDU set importance value to the RAN node in a GTP-U message, the UPF can include in the GTP-U message an indication that the UPF assigned a PDSI base value to the packet because a reset trigger was detected. The RAN can use this information (e.g., in the indication) to determine that the PDU set importance value cannot be used to infer the importance of this packet relative to an earlier packet of the same QoS flow.

[0110] The relative importance can be determined by the UPF.

[0111] The SMF can configure the UPF with the rules used by the UPF to determine what PDU set importance value to indicate to the RAN when the UPF sends a PDU set to the RAN. The indication can be sent from the UPF to the RAN in a header of a GTP-U message used to send the PDU set to the RAN. The SMF can configure the UPF by sending (e.g., N4) messages to the UPF during a PDU session establishment or PDU session modification procedure.

[0112] The UPF can be configured with a packet detection rule (PDR) that the UPF uses to detect the format of a packet and to assign the packet to a QoS flow. Detecting the format of a packet can mean that the UPF detects the type of media carried in the packet. In an example, the UPF can receive a PDR that includes an application ID that identifies an application detection rule. The application detection rule can be a rule that the UPF uses to detect a particular media format. The PDR can be associated with a PDSI allocation rule. The PDSI allocation rule can be part of a QoS enforcement rule (QER). The PDSI allocation rule can be a rule that the UPF uses to determine what PDU set importance value to assign to a PDU set.

[0113] The PDSI allocation rules can be associated with an application identifier (e.g., application type). The application identifier can identify a protocol and media type combination (e.g., RTP H.265). The application identifier and / or the PDSI allocation rules can identify a relative importance determination (RID) rule. The RID rule can list possible values for one or more header fields associated with the protocol and media type combination. The list can be presented in ascending or descending order to indicate to the UPF how to use the one or more header fields to determine the importance of the packet relative to other packets. For a header field associated with the protocol and media type combination, the list can indicate how / should much the assigned PDU set importance value is greater or less than the PDU set importance of a previous PDU set. Different RID rules can be used at the same time, e.g., for different applications or flows.

[0114] The PDSI allocation rules (e.g., each) can include a PDSI base value. The base value can indicate a starting value for the PDU set importance. In an example, the PDSI base value can be assigned to a first PDU set received by the UPF that matches the protocol and media type combination identified by the application identifier. If the next PDU is more important than the first PDU set, the UPF can assign a higher PDU set importance value to the next PDU set (e.g., second PDU set). If the next PDU is not as important as the first PDU set, the UPF can assign a lower PDU set importance value to the next PDU set. If the next PDU has the same importance as the first PDU set, the UPF can assign the same PDU set importance value to the next PDU set. As described herein, the RID rule can be used to determine the importance of the next PDU set relative to the first PDU set.

[0115] When assigning a PDSI base value to a QoS flow / protocol / media type combination, the system (e.g., SMF) can configure the UPF(s) such that different QoS flows use different PDSI base values. Using different base values can allow the system to configure a relatively higher base value for a QoS flow or protocol / media format combination that is relatively more important than other QoS flows or protocol / media format combinations.

[0116] The PDSI allocation rules can describe a PDSI reset trigger. The PDSI allocation rules can indicate to the UPF what event can (e.g., should) trigger the UPF to assign a PDSI base value to a PDU set.

[0117] In an example, the PDSI allocation rule can indicate to the UPF a time value. The time value can be a PDSI reset trigger, and the time value can indicate to the UPF that, if no PDU set for a QoS flow is received within the time value, the UPF can (e.g., should) allocate a PDSI value to the next PDU set with an equal PDSI base value. Enough time can have passed so that it is unlikely (e.g., still) that the RAN node is buffering a PDU set for the QoS flow. Indicating PDU set significance relative to PDU sets that the RAN node has already sent can not be valuable.

[0118] In an example, the PDSI allocation rule can indicate to the UPF an application ID (e.g., application type). The application ID can be a PDSI reset trigger (e.g., detection of the application ID can be used to determine that the PDSI allocation rule is to be applied). The application ID can point to or identify an application detection rule. If the UPF detects traffic that matches the application detection rule, the UPF can allocate a PDSI value to the next PDU set with an equal PDSI base value. The PDSI value can be allocated to the next PDU group with an equal PDSI base value because the packet that matches the application detection rule is not relevant to packets that were previously sent (e.g., because a significant amount of time has passed since the previous packets were sent). The packet that matches the application detection rule can not be significant relative to the last received packet.

[0119] In an example, the PDSI allocation rule can indicate to the UPF a protocol / media type / field value. The protocol / media type / field value can include a PDSI reset trigger. If the UPF detects traffic that matches the identified protocol type and media payload type, the UPF can check whether the identified field matches the value provided in the PDSI reset trigger. If there is a match, the UPF can allocate a PDSI value to the next PDU group with an equal PDSI base value. The packet that matches the combination can represent a packet that is not relevant (e.g., typically associated) or not relevant to packets that were previously sent. The packet that matches the combination can not be significant relative to the last received packet.

[0120] When the UPF determines to assign a PDU set significance value based on a reset trigger (e.g., decides to assign a PDSI base value), the UPF can indicate to the RAN node that the PDU set is being assigned a PDSI base value (e.g., because the UPF has determined that the PDU set is not associated with a previous PDU set (e.g., it is part of a new data burst)). The indication can be sent to the RAN node in the GTP-U header with the PDU set significance value. If the UPF determines to assign a PDSI base value, the UPF can indicate (e.g., can also indicate) to the RAN node that the PDU set is considered lower in priority than a previously sent PDU set, higher in priority than a previously sent PDU set, or the same priority as a previously sent PDU set. The indication can be sent to the RAN node in the GTP-U header with the PDU set significance value.

[0121] In examples involving a RAN node, PDU significance can be used to determine what packets to drop during congestion.

[0122] When the RAN receives a PDU from a PDU set from the UPF, the PDU can be received in a GTP-U packet. The header of the GTP-U packet can indicate a PDU set significance value for the PDU set. As described herein, the PDU set significance value can have been assigned by the UPF. In a congestion situation, the RAN can use the PDU set significance value to determine what PDU(s) to drop or discard to resolve the congestion. Since the same PDU set significance value can be assigned to (e.g., all) PDUs of a PDU set, the UPF can choose not to include the PDU set significance in the GTP-U. The fact that there is no PDU set significance value in the header can indicate that the PDU set significance value is indicated in a message carrying an earlier PDU of the same PDU set.

[0123] As described herein, a PDU set significance value can indicate to a RAN node the relative importance of a PDU relative to other PDU(s) of the same QoS flow. When the RAN determines what PDU(s) to drop or discard in a congestion situation, the RAN can select the PDU(s) to drop from (e.g., any) QoS flow. A priority level can be a parameter assigned to (e.g., an entire) QoS flow and can indicate to the RAN the relative priority of the QoS flow relative to other QoS flows. As described herein, the parameter can indicate the importance of the QoS flow relative to other QoS flows and can not (e.g., ever) account for the fact that PDUs within a QoS flow can vary in importance.

[0124] As described herein, an example of a drop or discard by a RAN of packets from a lowest priority flow can result in a user-perceivable QoE degradation.

[0125] During a PDU session establishment or PDU session modification procedure, the SMF can send a discard factor for a QoS flow to the RAN node. The discard factor can be sent by the SMF to the RAN node via the AMF. The AMF can forward the message in a (e.g., N2) message to the RAN node. The discard factor (e.g., for each) QoS flow can be included as part of the QoS profile for the PDU session. The discard factor can indicate to the RAN node how many percent of PDUs can be discarded from a QoS flow before a user can expect to notice QoE degradation. The RAN node can use the value to determine when to stop discarding packets from a first QoS flow and when to start discarding packets from a second QoS flow that has been assigned a higher overall priority level.

[0126] In a downlink example associated with a RAN node, the relative importance and discard factor can be used to determine packet discard eligibility.

[0127] A WTRU can be configured with a PDU set importance allocation rule and a discard factor. The WTRU upper layer can use the PDU set importance allocation rule to determine the importance of a PDU set relative to (e.g., a most recent) PDU set sent from the WTRU upper layer to the WTRU lower layer. The WTRU upper layer can determine the discard factor and the WTRU lower layer can use the PDU set importance value and the discard factor to determine which logical channel to allocate the PDU set to.

[0128] A network node (e.g., RAN node) can receive a discard factor in a message (e.g., N2 message) from a network node (e.g., SMF). The discard factor can be associated with a QoS flow and sent in a QoS profile. The RAN node can receive a downlink data packet (i.e., PDU) and a PDU set importance value in a GTP-U message from a UPF. In an example, the RAN node can use the discard factor and the PDU set importance value to determine transmission information. The RAN node can send a transmission according to the determined transmission information. The transmission information can include discarding or dropping what (multiple) PDU(s) (e.g., at least one PDU) to address congestion (e.g., the transmission information can indicate discarding at least one PDU from a plurality of PDUs). The transmission can not include the at least one PDU (e.g., if the determined transmission indicates discarding the at least one PDU from the plurality of PDUs). In an example, the RAN node can use the discard factor and the PDU set importance value to determine transmission information (e.g., the transmission information can include allocating a packet (e.g., a downlink PDU) to which logical channel). The downlink PDU can be sent over a logical channel.

[0129] The drop factor can indicate to the RAN node how many percent of PDUs can be dropped from the QoS flow before the user can be expected to notice a degradation in QoE (e.g., the drop factor can indicate to the RAN node how many percent of PDUs can be dropped from the QoS flow based on reaching a degradation threshold associated with the QoS flow).

[0130] The drop factor can indicate to the RAN node how many percent of PDUs can be dropped from the QoS flow before the user can be expected to notice a degradation in QoE (e.g., the drop factor can indicate to the RAN node how many percent of PDUs can be dropped from the QoS flow based on reaching a degradation threshold associated with the QoS flow).

[0131] The (e.g., one) drop factor associated with (e.g., each) PDU set importance value or range / multiple PDU set importance values can be indicated in the (e.g., N2) message.

[0132] The drop factor (e.g., multiple drop factors) can be provided to the RAN node for (e.g., each) QoS flow. There can be one drop factor associated with (e.g., each) PDU set importance value or (e.g., each) PDU set importance value range. The RAN node can be configured such that the RAN node will drop a relatively high percentage of low importance PDUs in the QoS flow and a relatively low percentage of high importance PDUs in the QoS flow.

[0133] The drop factor can be important to communicate to the RAN node because without the drop factor, the RAN would be limited to using the priority level of the QoS flow in making drop decisions, and as described herein, relying on the priority level example can result in a large percentage (e.g., too large a percentage) of dropped packets from (e.g., a single) QoS flow and result in a degradation in QoE for the user. The examples described herein can implement a RAN configuration that will avoid dropping a large percentage (e.g., too large a percentage) of dropped packets from a single QoS flow.

[0134] To more evenly distribute drops over time, the drop factor can be expressed as a percentage per time unit.

[0135] When the AF configures QoS for a session, the drop factor can be explicitly signaled by the AF to the PCF. The AF can indicate the type of data in the flow and the PCF can use this indication to determine the drop factor. The PCF can provide the drop factor to the SMF as part of the PCC rules.

[0136] An example of how to apply the drop factor is as follows. During a congestion period, the RAN can start the process of dropping PDUs. The RAN can start dropping packets from the lowest priority QoS flow. As (e.g., each time) the RAN drops a packet from a QoS flow, the RAN can calculate the percentage of packets dropped from the QoS flow over a period of time. The RAN can compare the calculated percentage to the drop factor for the QoS flow. If the percentage is below the drop factor, the RAN can continue to drop packets from the QoS flow until congestion is resolved, or until the calculated percentage is greater than or equal to the drop factor. When the result of the calculation is greater than or equal to the drop factor, the RAN can start dropping packets from the next highest priority QoS flow. The RAN can continue to drop PDUs from the next highest priority QoS flow until the percentage of dropped packets exceeds or equals the drop factor for the next highest priority QoS flow. Once the percentage of dropped packets exceeds or equals the drop factor for the next highest priority QoS flow, the RAN will decide to start dropping packets from a third QoS flow. The RAN can select the next highest priority QoS flow, or the RAN can again select the lowest priority QoS flow (e.g., if enough time has passed such that the percentage of dropped packets from the first QoS flow is below the drop factor for the first QoS flow).

[0137] Features described herein can be associated with uplink handling of PDU set importance.

[0138] In the uplink, data can be sent from a WTRU application to an application server. The WTRU can use a PDU session to send data to a UPF via a RAN node. The SMF can configure the WTRU, the UPF, and the RAN node with information for the WTRU and the RAN node to determine how to handle (e.g., prioritize) traffic for the PDU session. The following examples can describe how the SMF, the WTRU, and the RAN node can determine the importance of a PDU, assign an importance value to the PDU, and use the importance value to prioritize the PDU such that a user of the WTRU is less likely to notice a degradation in QoE when the WTRU prioritizes and allocates the PDU to network resources (e.g., logical channels).

[0139] At the WTRU upper layer(s), a relative importance can be identified and the relative importance information can be provided (e.g., conveyed) to the WTRU lower layer(s).

[0140] The RAN node can be configured with a drop factor for a QoS flow. In some examples, the drop factor can be used such that the RAN node does not drop packets from the lowest priority QoS flow, and such that the RAN node can spread the PDU set drop event evenly across QoS flows.

[0141] A WTRU (e.g., WTRU upper layers) can receive a PDSI allocation rule from a network node (e.g., SMF) in a message (e.g., NAS message). The PDSI allocation rule can be associated with a QoS flow. The WTRU upper layers can receive an uplink data packet (e.g., PDU) from an application (e.g., WTRU application) associated with the WTRU. The WTRU upper layers can determine a PDU set importance value associated with the PDU using the PDSI allocation rule and one or more of a PDSI base value or a PDU set importance of a previous uplink data packet. The WTRU upper layers can determine a drop factor (e.g., for the uplink data packet) associated with the uplink data packet using the PDSI allocation rule. The WTRU upper layers can transmit the PDU, the determined PDU set importance value, and the drop factor (e.g., to a lower layer(s) of the WTRU), and the WTRU lower layers can use the PDU set importance value and the drop factor to determine to which logical channel to allocate the PDU set, such that the lower layers can allocate PDUs from the same QoS flow to different logical channels (e.g., the WTRU can transmit the PDUs associated with the QoS flow according to the PDU set value and the drop factor). In an example, the WTRU can determine a first logical channel for a first PDU of the PDUs based on the PDU set value and the drop factor. In an example, the WTRU can determine a second logical channel for a second PDU of the PDUs based on the PDU set value and the drop factor. The WTRU can transmit the first PDU on the first logical channel and the second PDU on the second logical channel.

[0142] The WTRU upper layers can be the SDAP layer, the NAS layer, or a combination of the SDAP layer and the NAS layer.

[0143] The message (e.g., NAS message) can be a PDU session establishment accept message or a PDU session modification message (e.g., PDU session modification command message).

[0144] The PDSI allocation rule can be part of a QoS rule.

[0145] The PDSI allocation rule can be associated with an application identifier. The application identifier can be used to determine to apply the PDSI allocation rule. The application identifier can be used to determine what relative importance determination (RID) rule to use to determine a PDU set importance value to assign to an uplink data packet.

[0146] The PDSI allocation rule can be associated with a PDSI base value indicating a starting value for a PDU set importance.

[0147] The PDSI allocation rule can be associated with a PDSI reset trigger that indicates a condition that triggers the WTRU upper layer to allocate a PDSI base value as a PDU set importance value for an uplink data packet.

[0148] The reset trigger can indicate a time value, and if the duration between PDU sets of the same QoS flow that are received or transmitted exceeds the time value, the WTRU can be triggered to allocate a PDSI base value as a PDU set importance value for a next uplink data packet.

[0149] The reset trigger can indicate an application ID, and the UPF can be triggered to allocate a PDSI base value as a PDU set importance value for an uplink data packet when the WTRU detects that the uplink packet matches an application detection rule identified by the application ID.

[0150] The reset trigger can indicate a combination of protocol / media type / field value. The WTRU can be triggered to allocate a PDSI base value as a PDU set importance value for an uplink data packet when the WTRU detects that the uplink packet matches the combination.

[0151] The WTRU upper layer can receive a mapping table that indicates at least one URL is associated with at least one application ID. The WTRU upper layer can determine to use the URL to download an application detection rule associated with the application ID, and the WTRU upper layer can use the application detection rule to determine whether a PDSI allocation rule can (e.g., should) be applied to an uplink data packet.

[0152] When a PDU set importance value is sent by the SDAP layer to a lower layer, the SDAP layer can include in the message an indication that the WTRU upper layer allocated a PDSI base value to the packet because a reset trigger was detected. The WTRU lower layer can use this information (e.g., information in the indication) to determine that the PDU set importance value cannot be used to infer the importance of the packet relative to an earlier packet of the same QoS flow.

[0153] The SMF can configure the WTRU with rules for the WTRU to use to determine what PDU set importance value the SDAP layer can (e.g., should) indicate to a lower layer when the SDAP layer sends a PDU to the lower layer. The SMF can configure the WTRU by sending a NAS message to the WTRU during a PDU session establishment or PDU session modification procedure. In an example, the configuration information can be sent in a PDU session establishment accept message or a PDU session modification command message.

[0154] The QoS rules sent to the WTRU can be modified to include application ID(s) that identify application detection rules. The application detection rules can be rules used by the WTRU to detect a particular media format. When the WTRU upper layers determine that a packet of application traffic matches an application detection rule, the WTRU can assign the packet to a QoS flow. The QoS rules can be associated with PDSI allocation rules. The PDSI allocation rules can be part of the QoS rules. Similar to examples described herein (e.g., for a UPF), the PDSI allocation rules can be rules used by the WTRU to determine what PDU set importance value to assign to a PDU set. As described herein, the PDSI allocation rules can include application identifier(s), PDSI base value(s), and PDSI reset triggers. The application identifier can further identify a relative importance determination (RID) rule. The QoS rules can be associated with a WTRU discard factor. The WTRU discard factor can be part of the QoS rules. Similar to examples described herein (e.g., for a RAN node), the WTRU discard factor can indicate to the WTRU what percentage of PDUs can be dropped from a QoS flow before a user can be expected to notice a degradation in QoE. The PDSI allocation rules can describe how to detect the traffic to which the rule applies (e.g., using application detection rules identified by the application identifier), indicate how to inspect the traffic deeply (e.g., look at headers), and determine a PDU set importance value (e.g., using header values and PDU set importance values assigned to previous packets).

[0155] The discard factor configured in the RAN and described above can be referred to as a RAN discard factor or a downlink discard factor. As described above, the RAN discard factor is configured in the RAN by the SMF in the QoS profile.

[0156] The discard factor configured in the WTRU and described herein can be referred to as a WTRU discard factor or an uplink discard factor. As described herein, the WTRU discard factor can be configured in the WTRU by the SMF in the QoS rules.

[0157] The SMF can determine the WTRU discard factor and the RAN discard factor based on PCC rules or explicit indication from the PCF. The information from the PCF can be based on information from the AF (e.g., a discard factor or traffic type information from the AF).

[0158] The SMF can select to send different discard factors to the WTRU and the RAN for QoS flows associated with the same IP 4-tuple. In an example, downlink traffic can be more important than uplink traffic.

[0159] Application detection rules identified by application IDs can be configured in the WTRU. This information can be configured in the WTRU in a NAS message. In one example, this information can be configured in the WTRU and the PCF can send the WTRU a list of application ID(s) and a URL associated with (e.g., each) application ID. The application layer of the WTRU can use the URL to contact the server and download the application detection rules from the server. The WTRU application can subscribe to the server to receive updated versions of the application detection rules from the server. The list of application ID(s) and associated URL(s) can be referred to as a WTRU application ID mapping table.

[0160] The WTRU application ID mapping table can include the application detection rules instead of a URL for downloading the application detection rules. When including the application detection rules instead of the URL, the WTRU can not use (e.g., can not need to use) the WTRU application to download the application detection rules over the user plane. When including the URL in the WTRU application ID mapping table, the application detection rules (which can be relatively large) can not (e.g., can not need to be) sent in a message (e.g., a NAS) message and can be downloaded and updated (e.g., on an on-demand basis).

[0161] The application layer can provide application layer packets to the WTRU upper layers, and the WTRU upper layers can use QoS rules to assign packets to QoS flows, and can use PDSI assignment rules to determine a PDU set significance value for (e.g., each) PDU. The PDU set significance value can be assigned as described herein. If the WTRU upper layers detect traffic matching the identified protocol type and media payload type, the WTRU upper layers can check if the identified fields match the values provided in the PDSI reset trigger. If there is a match, the UPF can assign the PDSI value to the next PDU set that is the equal PDSI base value. Packets matching the combination can represent packets that are not associated (e.g., generally not associated) or not associated with previously transmitted packets. Packets matching the combination can not be significant relative to the last received packet. The WTRU upper layers can assign the PDSI base value to the first PDU set that the WTRU upper layers receive from an application matching the protocol and media type combination identified by the application identifier. If the next PDU is more significant than the first PDU set, the WTRU upper layers can assign a higher PDU set significance value to the next PDU set. If the next PDU set is less significant than the first PDU set, the WTRU upper layers can assign a lower PDU set significance value to the next PDU set. If the next PDU has the same significance as the first PDU set, the WTRU upper layers can assign the same PDU set significance value to the next PDU set. The WTRU upper layers can use RID rules to determine the significance of the next PDU set relative to the first PDU set as described herein.

[0162] The SDAP layer can send the determined PDU set significance value and drop factor to the WTRU lower layers. The WTRU lower layers can use the PDU set significance value and drop factor to determine which logical channel to assign the PDU set to (e.g., rather than assigning (e.g., all) PDUs from one DRB to the same logical channel). In an example, significant (e.g., more significant) packets can be assigned to logical channels configured to be significant (e.g., more significant), and can be prioritized in allocating network resources. In an example, packets associated with a larger drop factor can be assigned to logical channels that are allocated relatively less network resources.

[0163] When the SDAP layer sends a PDU set importance value to a lower layer based on a reset trigger (e.g., the upper layer decides to assign a PDSI base value), the SDAP layer can indicate to the lower layer that the PDU set is being assigned a PDSI base value because the WTRU upper layer has determined that the PDU set is not associated with a previous PDU set (e.g., the PDU set is part of a new data burst). An indication with the PDU set importance value can be sent to the lower layer. As described herein, data sent to a particular layer (e.g., higher layer / lower layer) can indicate that data is being sent to a device regardless of the layer (e.g., data is being sent to a network node, WTRU, base station, network, etc.).

[0164] A WTRU, UPF, and RAN node of a PDU session can be configured (e.g., by an SMF) to handle relative importance (e.g., for uplink and downlink).

[0165] To configure a PDU session, an SMF can send a first PDSI allocation rule to a WTRU in a NAS message. The PDSI allocation rule can be associated with a QoS flow. The PDSI allocation rule can include a PDSI base value and a drop factor. The SMF can send a second PDSI allocation rule to a UPF in a message (e.g., N4 message). The PDSI allocation rule can be associated with a QoS flow and can include a PDSI base value. The SMF can send a drop factor to a RAN node in a message (e.g., N2 message). The drop factor can be associated with a QoS flow and can be sent in a QoS profile.

[0166] A network node (e.g., SMF) can detect a trigger event. The SMF can send a first PDSI allocation rule to a WTRU in a message (e.g., NAS message). The PDSI allocation rule can be associated with a QoS flow. The PDSI allocation rule can include a PDSI base value and a drop factor. The SMF can send a second PDSI allocation rule to a network node (e.g., UPF) in a message (e.g., N4 message). The PDSI allocation rule can be associated with a QoS flow and can include a PDSI base value. The SMF can send a drop factor to a RAN node in a message (e.g., N2 message). The drop factor can be associated with a QoS flow and can be sent in a QoS profile.

[0167] One or more of the first or second PDSI allocation rules can include a PDSI reset trigger. The PDSI reset trigger can indicate a condition that can trigger the WTRU or UPF to assign a PDSI base value as a PDU set importance value for a data packet. In an example, the PDU set importance reset trigger can indicate a condition, and the SMF can assign a first PDU set importance base value as a PDU set value for a downlink PDU based on the condition being satisfied. In an example, the SMF can assign a second PDU set importance base value as a PDU set importance value for a downlink PDU based on the condition being satisfied.

[0168] The reset trigger can indicate a combination of time value, application ID, or protocol / media type / field value, and the WTRU or UPF can be triggered to assign a PDSI base value as a PDU set importance value for a data packet when the combination is detected in a downlink packet.

[0169] The reset trigger can indicate a time value, and the WTRU or UPF can be triggered to assign a PDSI base value as a PDU set importance value for a next data packet when a duration between PDU sets for the same QoS flow exceeds the time value.

[0170] The reset trigger can indicate an application ID, and the WTRU or UPF can be triggered to assign a PDSI base value as a PDU set importance value for a data packet when the WTRU detects that an uplink packet matches an application detection rule identified by the application ID.

[0171] The reset trigger can indicate a combination of protocol / media type / field value, and the WTRU or UPF can be triggered to assign a PDSI base value as a PDU set importance value for a data packet when the WTRU or UPF detects that an uplink packet matches the combination.

[0172] The NAS message can be a PDU session establishment accept message or a PDU session modification message.

[0173] The first PDSI allocation rule can be part of a QoS rule.

[0174] The NAS message can include a mapping table indicating that at least one URL is associated with at least one application ID.

[0175] The trigger event can be receiving a PDU session establishment request from the WTRU, receiving a PDU session modification request from the WTRU, or receiving an updated PCC rule from the PCF.

[0176] The PDU set importance can be handled in a PDU session.

[0177] Figure 2Examples of the present disclosure can show how examples of the features described herein can be implemented. Figure 2 An example process is shown for PDU set importance in a PDU session, in which one or more of the following operations can be performed.

[0178] At 1, a network node (e.g., SMF) can detect a triggering event. The triggering event can be receiving a PDU session establishment request from a WTRU, receiving a PDU session modification request from a WTRU, or receiving updated PCC rules from a PCF.

[0179] At 2, based on the triggering event and as described above, the SMF can send a QoS profile to a RAN node. The QoS profile can include a discard factor for (e.g., each) QoS flow.

[0180] At 3, based on the triggering event and as described above, the SMF can configure a UPF with rules (e.g., PDSI allocation rules and one or more of a PDSI base value or a previous PDSI value corresponding to a previous PDU) that the UPF uses to determine what PDU set importance value can (e.g., should) be indicated to a RAN when the UPF sends a PDU set to the RAN. The configuration information can be sent to the UPF in a message (e.g., a N4 message). The configuration information can be PDSI allocation rules described herein, and the configuration information can be used to detect traffic to which the rules apply. The configuration information can be used to determine a PDU set importance value to assign to a PDU.

[0181] At 4, based on the triggering event and as described above, the SMF can configure a WTRU with rules that the WTRU uses to determine what PDU set importance value can (e.g., should) be indicated by an SDAP layer to a lower layer (e.g., a WTRU lower layer) when the SDAP layer sends a PDU to the lower layer. The configuration information can be sent to the WTRU in a message (e.g., a NAS message). If the triggering event at 1 is a PDU session establishment request, the SMF can send the configuration information to the WTRU in a message (e.g., a PDU session establishment accept message). If the triggering event at 1 is a PDU session modification request or receiving PCC rules (e.g., updated PCC rules) from a PCF, the SMF can send the configuration information to the WTRU in a message (e.g., a PDU session modification message).

[0182] At 5, an application server can send downlink traffic to the WTRU (e.g., via the Internet). The downlink traffic can enter the system via a UPF on an (e.g., N6) interface.

[0183] At 6, as described above, the UPF can use the rules received at 3 (e.g., PDSI allocation rules and one or more of a PDSI base value or a previous PDSI value corresponding to a previous PDU) to determine a PDU set importance value for a downlink packet (e.g., PDU), and this PDU set importance value can be sent from the UPF to the RAN in a header of a message (e.g., GTP-U message(s)) that sends the packet to the RAN node.

[0184] At 7, as described herein, the RAN node can receive the packet and the PDU set importance value, and can use the PDU set importance value and information from the QoS profile received at 2 to determine what PDU(s) to drop or discard to resolve congestion. Packets that are not discarded by the RAN can be sent to the WTRU. The PDU set importance value and information from the QoS profile received at 2 can be used to determine to which logical channel to allocate the packet.

[0185] At 8, the packet (e.g., including PDU) received by the WTRU can be passed (e.g., sent) to the WTRU upper layers (e.g., to the SDAP layer and WTRU application).

[0186] At 9, the WTRU application can attempt to send the packet, and the WTRU can use the QoS rules received at 4 (e.g., modified QoS rules) to assign a PDU set importance value for the packet, assign the packet to a QoS flow, and determine a discard factor for the QoS flow. The packet, PDU set importance value, and discard factor can be sent to the WTRU layers (e.g., WTRU lower layers).

[0187] At 10, the WTRU lower layers can use the PDU set importance value and the discard factor to determine how to prioritize the uplink packet (e.g., to which logical channel to assign the PDU set). In an example, as described herein, the WTRU (e.g., WTRU lower layers) can use the PDU set importance value and the discard factor to determine to which logical channel to assign the PDU set (e.g., rather than assigning all PDU’s from one DRB to the same logical channel).

[0188] At 11, the RAN node can receive UL data. The RAN node can determine that the data is associated with what PDU session, and use the GTP-U tunnel associated with the PDU session to send the UL data to the UPF.

[0189] At 12, the UPF can receive the packet from the GTP-U message, and send the PDU (e.g., IP packet) to the AS on the (e.g., N6) interface.

[0190] Systems, methods, and instrumentalities are disclosed for a user plane function (UPF) to determine relative protocol data unit (PDU) set importance within a quality of service (QoS) flow. A first network node (e.g., a UPF) can be configured to receive, from a second network node, a first message indicating a protocol data unit (PDU) set importance allocation rule associated with a quality of service (QoS) flow. The first network node can receive a first downlink PDU. The first network node can determine a PDU set importance value associated with the first downlink PDU based on the PDU set importance allocation rule and one or more of a PDU set base value or a previous PDU set importance value corresponding to a previous PDU. The first network node can send, to a third network node, a second message. The second message can include the first downlink PDU and an indication of the PDU set importance value.

[0191] The PDU set importance allocation rule can be associated with a PDU set importance reset trigger indicating a condition. The first network node can assign the PDU set base value as the PDU set importance value based on the condition being satisfied.

[0192] The PDU set importance allocation rule can be associated with a PDU set importance reset trigger, and the PDU set importance reset trigger can indicate a time value. The first network node can assign the PDU set importance base value as the PDU set importance value for a second downlink PDU in an instance in which a duration associated with a set of PDUs transmitted or received for the QoS flow exceeds the time value.

[0193] The first network node can determine that the PDU set importance allocation rule is to be applied to the first downlink PDU based on an application type. The first network node can include a user plane function (UPF), and the second network node can include a session management function (SMF), and the third network node can include a radio access network (RAN) node.

[0194] The PDU set importance allocation rule can include a PDU set importance (PDSI) allocation rule. The PDU set importance base value can include a PDSI base value, and the previous PDU set value can include a previous PDSI value. The PDU set importance base value can indicate a starting value for the PDU set importance value.

[0195] Systems, methods, and instrumentalities are disclosed for a wireless transmit / receive unit (WTRU) to determine relative protocol data unit (PDU) set importance within a quality of service (QoS) flow. The WTRU can be configured to receive a PDU set importance allocation rule corresponding to a quality of service (QoS) flow in a first message from a network node. The WTRU can receive a PDU from an application associated with the WTRU. The WTRU can determine a PDU set importance value associated with the PDU based on the PDU set importance allocation rule and one or more of a PDU set importance base value or a previous PDU set importance value associated with a previous PDU. The WTRU can determine a drop factor for the PDU based on the PDU set importance allocation rule. The WTRU can transmit the PDU associated with the QoS flow according to the PDU set importance value and the drop factor.

[0196] The first message can include a PDU session establishment accept message or a PDU session modification command message. The WTRU can determine a first logical channel for a first PDU of the PDU based on the PDU set importance value and the drop factor. The WTRU can determine a second logical channel for a second PDU of the PDU based on the PDU set importance value and the drop factor. The WTRU can transmit the first PDU on the first logical channel and the second PDU on the second logical channel.

[0197] The PDU set importance base value can indicate a starting value for the PDU set importance value. The PDU set importance allocation rule can include a PDU set importance (PDSI) allocation rule. The PDU set importance base value can include a PDSI base value. The PDU set importance base value can include a PDSI base value. The network node can include a session management function (SMF).

[0198] Systems, methods, and instrumentalities are disclosed for a radio access network (RAN) to determine relative protocol data unit (PDU) set importance within a quality of service (QoS) flow. A first network node (e.g., a RAN) can be configured to receive a first message from a second network node. The first message can include a QoS profile and the QoS profile can indicate a drop factor. The first network node can receive a PDU set importance value and a downlink PDU. The first network node can determine transmission information based on the drop factor and the PDU set importance value. The first network node can transmit a transmission according to the determined transmission information.

[0199] The determined transmission information can indicate discarding at least one PDU from the plurality of PDUs. The transmission can not include the at least one PDU. The determined transmission information can indicate assigning a downlink PDU to a logical channel. The downlink PDU can be transmitted via the logical channel. The drop factor can include an indication that the downlink PDU is not discarded from the QoS flow. The first message can include an indication that the drop factor corresponds to a PDU set importance value or a plurality of PDU set importance values. The drop factor can indicate a percentage of PDUs that can be discarded or a percentage of PDUs to be discarded. The first network node can determine the percentage based on a degradation threshold associated with the QoS flow. The protocol data unit (PDU) set importance value can include a PDU set importance (PDSI) value. The second network node can include a session management function (SMF).

[0200] Systems, methods, and instrumentalities are disclosed for a session management function (SMF) determining relative protocol data unit (PDU) set importance within a quality of service (QoS) flow. A first network node (e.g., SMF) can be configured to detect a trigger event. The first network node can transmit a first message to a first wireless transmit receive unit (WTRU). The first message can include a first protocol data unit (PDU) set importance allocation rule. The first PDU set importance allocation rule can correspond to a quality of service (QoS) flow. The first PDU set importance allocation rule can indicate a first PDU set importance base value and a drop factor.

[0201] The first network node can transmit a second message to a second network node. The second message can include a second PDU set importance allocation rule. The second PDU set importance allocation can be associated with the QoS flow. The second PDU set importance allocation rule can indicate a second PDU set importance base value.

[0202] The first network node can transmit a third message to a third network node. The third message can include a QoS profile. The QoS profile can indicate the drop factor. The drop factor can correspond to the QoS flow. The second PDU set importance allocation rule can include a PDU set importance reset trigger. The PDU set importance reset trigger can indicate a condition. The first network node can assign the first PDU set importance base value as a PDU set value for a downlink PDU based on the condition being satisfied.

[0203] The first PDU set importance allocation rule can include a PDU set importance reset trigger. The PDU set importance reset trigger can indicate a condition. The first network node can assign the second PDU set importance base value as a PDU set importance value for a downlink PDU based on the condition being satisfied. The trigger event can be associated with one or more of a PDU session establishment request, a PDU session modification request, or receiving a PCC rule.

[0204] The second network node can comprise a user plane function (UPF), and the third network node can comprise a radio access network (RAN) node. The first message can comprise a non-access stratum (NAS) message. The NAS message can correspond to one or more of a PDU session establishment accept message or a PDU session modification command message. The first PDU set importance allocation rule can comprise a first PDU set importance (PDSI) allocation rule. The second PDU set importance allocation rule can comprise a second PDU set importance (PDSI) allocation rule. The first PDU set importance base value can comprise a first PDSI base value. The second PDU set importance base value can comprise a second PDSI base value.

[0205] Although the above-described features and elements are described in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements. For example, the methods can be performed by a single processor or multiple processors.

[0206] Although implementations described herein can consider 3GPP specific protocols, it should be understood that implementations described herein are not limited to such scenarios and can be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G specific protocols, it should be understood that the solutions described herein are not limited to this scenario and are applicable to other wireless systems as well. For example, while the system has been described with reference to 3GPP, 5G, and / or NR network layers, contemplated embodiments extend beyond implementations using particular network layer technologies. Likewise, potential implementations extend to all types of service layer architectures, systems, and embodiments. The techniques described herein can be applied independently and / or in conjunction with other resource configuration techniques.

[0207] The processes described herein can be implemented in a computer program, software, and / or firmware incorporated in a computer- readable medium for execution by a computer and / or processor. Examples of computer-readable media include but are not limited to electronic signals (optical and / or non-optical) and / or computer- readable storage media. Examples of computer-readable storage media include but are not limited to removable and / or built-in memory devices, optical storage media, and / or virtual storage media. Combinations of the above should also be included within the scope of computer-readable media. The processes described herein can be implemented using a programmed computer and / or a general purpose computer. As used herein, the term "computer" and "processor" are intended to encompass all of the above, both singly and in various combinations. The processes described herein can be implemented using a programmed computer and / or a general purpose computer.

[0208] It should be understood that the entities performing the processes described herein can be logical entities that can be implemented in the form of software (e.g., computer-executable instructions) stored in memory of, and executing on, a mobile device, network node, or computer system. That is, the processes can be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device and / or network node, such as a node or computer system, which software when executed by a processor of the node, performs the processes discussed. It should also be understood that any transmitting and receiving processes illustrated in the figures can be performed by communication circuitry of the node under control of the processor of the node and computer-executable instructions (e.g., software) executed thereby.

[0209] The various techniques described herein can be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, implementations of the subject matter described herein, or certain aspects or portions thereof, can take the form of program code (e.g., instructions) embodied in tangible media, including any machine-readable storage medium or media, including any other machine-readable storage medium or media. When the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the subject matter described herein. In the case of program code execution on a programmable device, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. One or more programs can implement or utilize the processes described with respect to the subject matter described herein, e.g., through the use of an API, reusable controls, and the like. Such programs can be implemented in a high-level procedural or object-oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language, and combined with hardware implementations.

[0210] While example embodiments can involve utilizing aspects of the subject matter described herein in the context of one or more standalone computing systems, the subject matter described herein is not so limited, but rather can be implemented in connection with any computing environment, such as a network or distributed computing environment. In addition, aspects of the subject matter described herein can be implemented in multiple processing chips or devices or across multiple processing chips or devices, and storage can similarly be implemented across multiple devices. Such devices can include personal computers, network servers, hand-held devices, supercomputers, or computers integrated into other systems such as automobiles and aircraft.

[0211] In describing the preferred embodiment of the subject disclosure, reference has been made to particular terms to describe certain aspects in accordance with the terminology that has become established in the art. However, the subject disclosure is not intended to be limited to the specific terms so selected and it is understood that each specific element encompasses all technical equivalents that operate in a similar manner to accomplish a similar purpose.

Claims

1. The first network node includes: The processor is configured as follows: Receive a first message from the second network node, the first message indicating the protocol data unit (PDU) set allocation rules associated with the quality of service (QoS) flow; Receive the first downlink PDU; Based on the PDU set allocation rules and one or more of the PDU set base value or the previous PDU set value corresponding to the previous PDU, determine the PDU set value associated with the first downlink PDU; as well as A second message is sent to a third network node, wherein the second message includes an indication of the first downlink PDU and the PDU set value.

2. The first network node according to claim 1, wherein the PDU set allocation rule is associated with a PDU set reset trigger indicating a condition, and wherein the processor is further configured to: Based on the satisfied conditions, the PDU set base value is assigned as the PDU set value.

3. The first network node according to claim 1, wherein the PDU set allocation rule is associated with a PDU set reset trigger, wherein the PDU set reset trigger indicates a time value, and wherein the processor is further configured to: If the duration associated with the PDU set sent or received with the QoS flow exceeds the time value, the base value of the PDU set is assigned as the PDU set value of the second downlink PDU.

4. The first network node according to any one of claims 1 to 3, wherein, The processor is also configured to determine, based on the application type, that the PDU set allocation rules will be applied to the first downlink PDU.

5. The first network node according to any one of claims 1 to 4, wherein, The first network node includes a User Plane Function (UPF).

6. The first network node according to any one of claims 1 to 5, wherein the PDU set allocation rule includes a PDU set importance (PDSI) allocation rule, wherein the PDU set base value includes a PDSI base value, and wherein the previous PDU set value includes a previous PDSI value.

7. The first network node according to any one of claims 1 to 6, wherein, The base value of the PDU set indicates the starting value of the importance value of the PDU set.

8. A method for a first network node includes: Receive a first message from the second network node, the first message indicating the protocol data unit (PDU) set allocation rules associated with the quality of service (QoS) flow; Receive the first downlink PDU; Based on the PDU set allocation rules and one or more of the PDU set base value or the previous PDU set value corresponding to the previous PDU, determine the PDU set value associated with the first downlink PDU; as well as A second message is sent to a third network node, wherein the second message includes an indication of the first downlink PDU and the PDU set value.

9. The method of claim 8, wherein the PDU set allocation rule is associated with a PDU set reset trigger indicating a condition, and wherein the method further comprises: Based on the satisfied conditions, the PDU set base value is assigned as the PDU set value.

10. The method of claim 8, wherein the PDU set allocation rule is associated with a PDU set reset trigger, wherein the PDU set reset trigger indicates a time value, and wherein the method further comprises: If the duration associated with the PDU set sent or received with the QoS flow exceeds the time value, the base value of the PDU set is assigned as the PDU set value of the second downlink PDU.

11. The method according to any one of claims 8 to 10, wherein, The method also includes determining, based on the application type, that the PDU set allocation rules will be applied to the first downlink PDU.

12. The method according to any one of claims 8 to 11, wherein, The first network node includes a user plane function (UPF), and the second network node includes a session management function (SMF), and the third network node includes a radio access network (RAN) node.

13. The method according to any one of claims 8 to 12, wherein the PDU set allocation rule includes a PDU set importance (PDSI) allocation rule, wherein the PDU set base value includes a PDSI base value, and wherein the previous PDU set value includes a previous PDSI value.

14. The method according to any one of claims 8 to 14, wherein, The PDU set base value indicates the starting value of the PDU set.

Images