Network resource allocation based on delay information

Abstract

A device (e.g., at least one network entity) may receive a message. The message may include a round trip (RT) latency requirement. The RT delay requirement may include uplink delay information and / or downlink delay information. The device may generate a first policy charging and control (PCC) rule, e.g., based on the uplink delay information and / or the downlink delay information. The device may send first information indicating the first PCC rule, such as to a session management function (SMF). The device may receive a notification that one or more of an uplink delay and / or a downlink delay is associated with a flow. The device may determine a second PCC rule, e.g., based on the uplink delay information and the downlink delay information. The device may transmit second information indicating the second PCC rule, such as to the SMF.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 457,512, filed April 6, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] Application Functions (AFs) can provide auxiliary information related to Protocol Data Unit (PDU) sets for Dynamic Policy Charging and Control (PCC). Parameters can be included in the PDU set QoS parameters. One parameter may include the PDU set delay budget (PSDB). The PSDB may include the upper limit of the delay that the PDU set can experience for transmission between the Radio Transmit / Receive Unit (WTRU) and the N6 endpoint at the UPF, for example, the duration between the reception time of the first PDU and the time when all PDUs in the PDU set have been successfully received. Summary of the Invention

[0003] This disclosure relates to apparatus, methods, and systems for allocating network resources based on latency requirements of Extended Reality and Media (XRM) services. This document provides apparatus, methods, and systems for enhancing latency and coverage in network resource allocation, and particularly for network resource allocation based on latency requirements of XRM services.

[0004] The devices, methods, and systems relate to, for example, round-trip (RT) time requirements with uplink and downlink delay limits. The devices, methods, and systems relate to, for example, determining QoS requirements based on PDU set attributes. In one or more cases, the devices, methods, and systems receive a message including an RT delay requirement, wherein the RT delay requirement includes uplink delay information and downlink delay information. In one or more cases, the devices, methods, and systems use the uplink delay information and downlink delay information to create Policy Charging and Control (PCC) rules and send the PCC rules to the Session Management Function (SMF). In one or more cases, the devices, methods, and systems receive notification that the delay associated with a flow is not within the range required by the PCC rules. In one or more cases, the device, method, and system perform one of the following operations based on the received notification: determine a new PCC rule using uplink delay information and downlink delay information, and send the new PCC rule to the SMF; determine that a PCC rule satisfying all the requirements indicated in the RT delay requirement, the uplink delay information, and the downlink delay information cannot be created, and based on this determination, send a notification to the AF; and determine a new set of RT delay requirements, uplink delay information, and downlink delay information, calculate a new PCC rule based on the new set of RT delay requirements, uplink delay information, and downlink delay information, determine the new PCC rule using the new uplink delay information and downlink delay information, and send the new PCC rule to the SMF.

[0005] A device (e.g., at least one network entity) can receive messages. The message may include round-trip (RT) latency requirements. RT latency requirements may include uplink latency information and / or downlink latency information. The device may generate a first Policy Charging and Control (PCC) rule, for example, based on the uplink latency information and / or downlink latency information. The device may send first information indicating the first PCC rule, for example, to a Session Management Function (SMF). The device may receive notifications associated with one or more of the uplink latency and / or downlink latency associated with a flow. The notification may include an indication that one or more of the uplink latency and / or downlink latency associated with the flow is not within the range required by the first PCC rule. The device may determine a second PCC rule, for example, based on the uplink latency information and downlink latency information. The device may send second information indicating the second PCC rule, for example, to the SMF. The message may include a multimode service identifier (ID) and / or one or more service descriptors. One or more service descriptors may include indications of one or more uplink data flows and / or downlink data flows.

[0006] The device may send (e.g., a second) notification, such as to an application function (AF). The notification may include an indication that a PCC rule satisfying one or more of the following: RT latency requirements, uplink latency information, and / or downlink latency information, cannot be generated. The RT latency requirements may include a first RT latency requirement. The uplink latency information may include first uplink latency information. The downlink latency information may include first downlink latency information. The device may determine a second RT latency requirement. The second RT latency requirement may include second uplink latency information and / or second downlink latency information. The device may determine a third PCC rule, for example, based on the second RT latency requirement. The device may send the third PCC rule to the SMF.

[0007] Uplink delay information may include an indication of one or more of the maximum uplink packet delay budget (PDB) and / or the maximum uplink protocol data unit (PDU) set delay budget (PSDB). Downlink delay information may include an indication of one or more of the maximum downlink PDB and / or the maximum downlink PSDB. The device may include a policy control function (PCF). The device may generate N4 rules, such as based on a second PCC rule. The device may perform one or more of the following operations: sending a Quality of Service (QoS) profile to the access network and / or sending QoS rules to a radio transceiver unit (WTRU). Flows associated with one or more of the uplink delay and / or downlink delay may additionally or alternatively be associated with one or more of the first PCC rule and / or the second PCC rule.

[0008] The device can receive Protocol Data Unit (PDU) set Delay Budget (PSDB) information, such as from an Application Function (AF). The PSDB information can indicate a first PSDB value for PDU set sizes above a threshold and / or a second PSDB value for PDU set sizes below a threshold. The device can generate rules. These rules can indicate that PDU sets with sizes smaller than a threshold should be assigned to a first Quality of Service (QoS) flow and / or PDU sets with sizes greater than a threshold should be assigned to a second QoS flow. The device can send information indicating these rules, for example, to one or more of a Wireless Transmit / Receive Unit (WTRU), User Plane Function (UPF), or Radio Access Network (RAN).

[0009] The rules may include indications of a QoS profile, for example, that a set of PDUs from a first QoS flow (with a set size less than a threshold) should be associated with a first PSDB value. The QoS profile may additionally or alternatively indicate that a set of PDUs from the first QoS flow (with a set size greater than a threshold) should be associated with a second PSDB value. The device may include a Session Management Function (SMF). The device may receive Policy Charging and Control (PCC) rules, such as those from a Policy Control Function (PCF). The device may generate N4 rules, such as based on PCC rules. The device may send information indicating N4 rules, for example, to a User Plane Function (UPF). The device may send indications as to whether one or more of the first QoS flow and / or the second QoS flow are within the scope required by the rule. The rules may include indications of QoS rules, for example, that a set of PDUs matching a first Packet Detection rule and / or having a set size less than a threshold should be associated with the first QoS flow. QoS rules may additionally or alternatively indicate that a set of PDUs that matches the first packet detection rule and / or has a set size greater than a threshold should be associated with the second QoS flow. The threshold indication may be included in the PSDB information. Attached Figure Description

[0010] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, wherein the same reference numerals in the figures indicate the same elements.

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

[0012] Figure 1B It's shown in the diagram. Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0013] Figure 1C It's shown in the diagram. Figure 1A The diagram shows a system diagram of an example radio access network (RAN) and an example core network (CN) used within the communication system.

[0014] Figure 1D It's shown in the diagram. Figure 1A The system diagram shows a further example RAN and a further example CN used within the communication system shown.

[0015] Figure 2 The illustration shows an example process for configuring multi-mode requirements.

[0016] Figure 3The diagram illustrates an example process for configuring QoS monitoring. Detailed Implementation

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

[0018] like Figure 1A As shown, the communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112. Although it will be appreciated, the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain scenarios), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0019] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home node B, home eNode B, gNB, NR NodeB, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are depicted as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0020] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area for radio services, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, and multiple transceivers may be used for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

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

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

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

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

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

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

[0027] Figure 1A Base station 114b can be, for example, a wireless router, a home node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a commercial area, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0028] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data may have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although... Figure 1AAlthough not shown, it will be understood that RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113, which can utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0031] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be appreciated that WTRU 102 may include any sub-combination of the above-described elements while remaining consistent with the embodiments.

[0032] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

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

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

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

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

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

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

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

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

[0041] Figure 1C The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 employs E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

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

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

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

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

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

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

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

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

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

[0051] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be reached via the AP and delivered to the STA. Traffic from a STA to a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode can exist without an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0052] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented, for example, in an 802.11 system. For CSMA / CA, the STAs including the AP (e.g., each STA) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

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

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

[0055] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support instrument-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a lifespan exceeding a threshold (e.g., to maintain a very long battery life).

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

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

[0058] Figure 1D The diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

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

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

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

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

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

[0064] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slices can be used by AMF 182a and 182b to customize CN support for WTRU 102a, 102b, and 102c based on the service types utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be built for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0065] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure service routes through UPFs 184a and 182b. SMFs 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0066] UPF 184a and 184b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 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, and providing mobility anchoring.

[0067] CN 115 can facilitate communication with other networks. For example, CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108. Additionally, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can connect to local data networks (DNs) 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

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

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

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

[0071] The network (NW) can be configured with round-trip time (RT) information (e.g., latency requirements). Additionally or alternatively, the NW can be configured with information (e.g., exceeding RT latency requirements), for example, at the Policy Control Function (PCF). This information may include one or more of the maximum uplink delay and / or maximum downlink delay. The uplink and / or downlink delays may include a Protocol Data Unit (PDU) set delay budget (PSDB). For example, configuring the uplink and / or downlink delays to (e.g., including) a PSDB can allow the Application Function (AF) to configure round-trip time requirements. Round-trip time requirements can be used in scenarios where traffic in one direction carries a set of PDUs and / or traffic in another direction carries a set of PDUs that are not part of that set of PDUs.

[0072] The Session Management Function (SMF) can receive PSDB information, such as from the PCF. The PSDB information can be used to determine the PSDB of a PDU set. The PSDB information may include PSDB determination rules, for example, rules that map one or more service characteristics to the PSDB. One or more service characteristics may be related to the size of the PDU set. The network (e.g., the SMF) can use the PSDB information to construct one or more rules. The one or more rules may be N4 rules. The SMF can send one or more rules (e.g., information indicating one or more rules), for example, to the User Plane Function (UPF). The network (e.g., the SMF) can send information indicating rules, for example, to one or more of the Radio Transmit / Receive Unit (WTRU), User Plane Function (UPF), or Radio Access Network (RAN). One or more rules may include (e.g., multiple) Packet Detection Rules. One or more rules may indicate (e.g., to the UPF) that a set of (multiple) PDUs matching a certain Packet Detection Rule and / or smaller than a certain size should be assigned (e.g., a Quality of Service (QoS) flow). The flow may be associated with one or more of uplink delay or downlink delay. Additionally or alternatively, a flow may be associated with one or more of (e.g., a first) PCC rule and / or (e.g., a second / new) PCC rule.

[0073] The NW (e.g., PCF) can receive messages. Messages may include RT latency requirements. Messages may be received from the AF. RT latency requirements may include uplink latency information and / or downlink latency information. For example, the message may include a multi-mode service identifier (ID). Additionally or alternatively, the message may include one or more service descriptors, such as those identifying uplink and / or downlink data streams. Uplink latency information may indicate (e.g., represent) the maximum uplink PDB and / or maximum uplink PSDB. Additionally or alternatively, uplink latency information may indicate a percentage representing the maximum percentage of RT latency requirements that can be applied to uplink services. Downlink latency information may represent the maximum downlink PDB and / or maximum downlink PSDB. Additionally or alternatively, downlink latency information may indicate a percentage representing the maximum percentage of RT latency requirements that can be applied to downlink services.

[0074] A network network (NW) (e.g., a PCF) can use uplink delay information and / or downlink delay information to generate (e.g., create) PCC rules. The PCF can send information indicating the PCC rules to the SMF. The network (e.g., the PCF) can receive notification that the delay associated with a flow (e.g., a QoS flow) is not within the range required by the PCC rules. The NW (e.g., the PCF) can determine (e.g., a new) PCC rule. The NW can determine the PCC rule based on (e.g., receiving) a notification. For example, based on receiving a notification, the PCF can use uplink delay information and / or downlink delay information to determine a new PCC rule. The uplink delay information and / or downlink delay information may include new (e.g., updated) uplink delay information and / or downlink delay information. The PCF can send the new PCC rule, for example, to the SMF.

[0075] The PCF can determine (e.g., based on a received notification) that a PCC rule satisfying (e.g., all) the requirements cannot be created. The requirements may be indicated in one or more of the RT delay requirements, uplink delay information, and / or downlink delay information. The PCF can send a notification to the AF, for example, based on the determination that a PCC rule satisfying (e.g., all) the requirements cannot be created. The notification may include an indication of whether one or more of the uplink delay and / or downlink delay cannot (e.g., or can) be satisfied. The PCF can determine one or more of a new set of RT delay requirements, uplink delay information, and / or downlink delay information, for example, based on (e.g., a received) notification. The PCF can compute new PCC rules, for example, based on the new set of RT delay requirements, uplink delay information, and / or downlink delay information. The PCF can use the new uplink delay information and / or downlink delay information to determine new PCC rules. The PCF can send the new PCC rules, for example, to the SMF. The new set of RT latency requirements, uplink latency information, and / or downlink latency information can be based on a value set, for example, one previously provided by the AF. The PCF can send a notification to the AF, for example, to inform the AF that a new value set has been used.

[0076] A new network controller (NW) (e.g., an SMF) can be configured to determine QoS requirements. For example, the NW can determine QoS requirements based on one or more PDU set attributes. The NW (e.g., the SMF) can receive PSDB information. The PSDB information may be received from a PCF. The PSDB information can be used to determine the PSDB of the PDU set. The PSDB information may include PSDB determination rules, for example, rules that map service characteristics to the PSDB. At least one of the service characteristics may be related to the size of the PDU set.

[0077] The NW (e.g., SMF) can use PSDB information to construct and / or send N4 rules. The NW can send the N4 rules to the UPF. The N4 rules may include packet detection rules. The N4 rules may (e.g., to the UPF) indicate that a set of PDUs matching a first packet detection rule and / or smaller than a certain size should be assigned to a first QoS flow. Additionally or alternatively, the N4 rules may indicate that a set of PDUs matching a first packet detection rule (e.g., the same rule) and / or larger than or equal to a certain size should be assigned to a second QoS flow. Size information may be included (e.g., incorporated into) the packet detection rules. The NW (e.g., SMF) can use PSDB information to construct a QoS profile. The NW can send the QoS profile, for example, to the RAN. The QoS profile may (e.g., to the RAN) indicate that a set of PDUs from a first QoS flow smaller than a certain size should be associated with a first PSDB. Additionally or alternatively, the QoS profile may (e.g., to the RAN) indicate that a set of PDUs from a first QoS flow (e.g., the same QoS flow) and / or greater than or equal to the same specific size should be associated with a second PSDB.

[0078] NW (e.g., SMF) can use PSDB information to construct QoS rules. NW can send QoS rules, for example, to WTRU. SMF can send QoS rules (e.g., to WTRU) instructing that a set of PDUs matching a first packet detection rule and / or filter and / or smaller than a specific size (e.g., a threshold) should be assigned to a first QoS flow. SMF can send an instruction (e.g., to WTRU) that a set of PDUs matching a first packet detection rule and / or filter (e.g., the same filter) and / or larger than or equal to a specific size (e.g., a threshold) should be assigned to a second QoS flow. Instructions can be sent as part of the indicated QoS rule and / or as a new QoS rule. Size information can be included (e.g., incorporated into) the packet detection rule and / or filter.

[0079] The PSDB determination rule and / or QoS profile may indicate that any PDU set smaller than or equal to a first value may have a PSDB of a second value. The PSDB determination rule may indicate that any PDU set larger than the first value has a PSDB of a third value. The N4 rule and / or QoS rule may indicate that a PDU set smaller than or equal to the first value (e.g., any) should be assigned to a first QoS flow. The PSDB determination rule may indicate that a PDU set larger than the first value (e.g., any) should be assigned to a second QoS flow. The PSDB determination rule and / or QoS profile may include any number of mappings from PDU set sizes to PSDBs. The N4 rule and / or QoS rule may include any number of mappings from PDU set sizes to QoS flows. The PDU set size in one or more of the PSDB determination rule, QoS profile, N4 rule, and / or QoS rule may be represented as the total number of bytes in the PDU set and / or the total number of PDUs in the PDU set. The PSDB determination rule and / or QoS profile may indicate (e.g., a single) time value. The SMF and / or RAN may determine the PSDB, for example, by multiplying the PDU set size by the time value. For example, the time value can be multiplied by the number of PDUs in the PDU set and / or the number of bytes in the PDU set. PSDB determination rules can be included in N4 rules and / or QoS rules. PSDB determination rules can also be standalone rules.

[0080] The WTRU can be configured to determine QoS flow allocation, for example, based on one or more PDU set attributes. The WTRU can receive QoS rules, such as from the SMF. QoS rules can (e.g., to the WTRU) indicate that a PDU set matching a first packet detection rule and / or filter and / or smaller than a certain size should be allocated to a first QoS flow. Additionally or alternatively, QoS rules can indicate that a PDU set matching a first packet detection rule and / or filter (e.g., the same filter) and / or larger than or equal to a certain size should be allocated to a second QoS flow. Size information can also be incorporated into the packet detection rule and / or filter.

[0081] The WTRU can assign PDUs from a PDU set to QoS flows, for example, based on size information in a received QoS rule. A QoS rule can instruct that any PDU set with a size less than or equal to a first value should be assigned to a first QoS flow. Additionally or alternatively, a QoS rule can instruct that any PDU set with a size greater than the first value should be assigned to a second QoS flow. QoS rules can include (e.g., any number of) multiple mappings from PDU set sizes to QoS flows.

[0082] The NW can be configured with a PSDB. The network (e.g., AF) can provide auxiliary information related to PDU sets for dynamic PCC control. This auxiliary information can include one or more parameters. Parameters can be included in the PDU set QoS parameters. Parameters can include a PDU set delay budget. The PDU set delay budget (PSDB) can correspond to a maximum delay value (e.g., a threshold). Delay can be the delay that the PDU set can experience during transmission between the WTRU and the N6 endpoint (e.g., at the UPF). Delay can include the duration between the reception time of the first PDU (e.g., at the N6 endpoint of the DL and / or the WTRU of the UL) and the time when all PDUs in the PDU set are successfully received (e.g., at the WTRU of the DL or the N6 endpoint of the UL). The PSDB can be applied to one or more of the following: DL PDU sets received by the PDU Session Anchor (PSA) UPF via the N6 interface and / or UL PDU sets transmitted by the WTRU. The PSDB can replace the Packet Delay Budget (PDB), for example, when the PSDB is available.

[0083] The NW can be configured with uplink and / or downlink policy control, for example, for XRM services. The NW can be configured with uplink and / or downlink policy control based on round-trip (RT) latency (e.g., for XRM services). RT latency indications can indicate that service data flows need to meet the service's RT latency requirements. RT latency requirements can be twice the one-way latency requirement between the WTRU and the PSA UPF, for example, described by QoS reference parameters and / or separate QoS parameters.

[0084] Enhancements to 5G systems can allow for policy control, such as based on round-trip latency requirements. The AF (Action Center) can (e.g., instruct the PCF) that UL (Ultra-Low) and / or DL ​​(Low-Low) flows need to meet RT (Round-Trip) latency requirements. RT latency requirements can include maximum values ​​(e.g., thresholds), such as the sum of the UL and DL latency of the data flow between the WTRU and the N6 endpoint (e.g., at the UPF). The PCF can monitor latency on the UL and / or DL ​​flows (e.g., both). The PCF can adjust the UL PDB (Ultra-Low) and / or DL ​​PDB (Low-Low) latency, for example, based on observed network performance.

[0085] XRM services can be carried using PDU sets. QoS flows may not be associated with any PDB, for example, when a QoS flow carries a PDU set. QoS flows may (e.g., only) be associated with a PSDB. For example, when a PDU set is carried in one direction of a flow, the associated flow in the other direction may not carry a PDU set. Downlink services can be PDU set-based, for example, in some XRM scenarios. Additionally or alternatively, corresponding uplink services may correspond to data flows that do not carry PDU sets. For example, when a user is using VR glasses and / or haptic gloves for XRM services, the downlink service provided to the VR glasses and / or haptic gloves may be in the form of a PDU set (e.g., a PDU set for video mode). Uplink services may carry gesture information, for example, to notify the application server of the user's gestures and / or haptic feedback. Gesture information and / or haptic feedback may not be carried using a PDU set (e.g., using regular PDUs). Downlink flows may carry a set of PDUs, and / or (e.g., associated) uplink flows may carry acknowledgments and / or haptic feedback (e.g., services not carried in the PDU set). Additional margin may be added to the UL PDB, for example, when the latency of DL services is lower than the PSDB. Additional margin may be added to the downlink PSDB, for example, when the latency of uplink services is lower than the PDB.

[0086] The system should not (e.g., always) assume (e.g., all) that uplink latency margin should be added to the downlink PSDB. For example, some uplink latency margin or no uplink latency margin may be added to the downlink PSDB. Downlink traffic may carry updated scene information and / or uplink traffic may carry confirmation of updated scene information. User experience quality may degrade, for example, because users may perceive latency when watching scene changes due to delayed reception of updated scene information. Experience quality may also degrade, for example, when round-trip time delays are evenly distributed between uplink and downlink streams.

[0087] XRM application service providers can configure (e.g., efficient) combinations of UL / DL latency, for example, if the XRM application service provider is exposed to detailed uplink and / or downlink latency information. XRM application service providers can configure (e.g., customize) UL / DL configurations, for example, to best suit the XRM application. Additionally or alternatively, XRM services may include more than one uplink flow and / or one downlink flow, for example, for each mode and / or for the same mode. UL / DL granularity can help application providers tailor requirements for multiple flows. Round-trip latency measurements (e.g., based on measurements of latency associated with individual packets) may not be sufficient. For example, when transmitting PDU sets in the uplink and / or downlink directions, RT latency measurements based on measurements of latency associated with individual packets may not be sufficient. 5G system enhancements are provided herein, such as where the AF can configure RT latency requirements for uplink and / or downlink flows (e.g., combinations). Uplink and / or downlink flows may carry PDU sets. The AF can measure the latency associated with the flow combination. AF can adjust the PSDB and / or PDB of a stream, for example, based on configuration information and / or measurement information.

[0088] Some applications can (e.g., need to) control the latency of more than one uplink stream and / or one downlink stream (e.g., a combination of them). For example, an application's timing and / or quality of experience (QoE) may depend on a combination of two downlink media streams and one uplink data stream. The systems and processes described herein (e.g., for one UL stream and one DL stream) can be used to enable AF (e.g., to support such cases). The processes described herein can specify UL and / or DL ​​latency for three or more streams, e.g., such that the combination of latency provides the required round-trip time (RTT) for the application service.

[0089] 5G systems can allow the Application Controller (AF) to provide a PDU set latency budget (PSDB), for example, to the 5GC. The 5GC can associate the PSDB with QoS flows. Associating the PSDB with QoS can correspond to the PCF using the PSDB to construct PCC rules that can be sent to the SMF and / or the SMF sending the PSDB to the NG-RAN, for example, as part of a QoS profile. 5G systems can support enhancements that take into account variations in the size of the PDU set within an application layer session (e.g., a Real-time Transport Protocol (RTP) session). A single PSDB configured for a session may not be sufficient, for example, when the size of the PDU set within an application layer session (e.g., an RTP session) can vary. The PSDB can be set to a value large enough to accommodate the largest expected PDU set that might be sent in an application layer session, for example, when providing (e.g., a single) PSDB. 5G systems (e.g., including NG-RAN) can assume the same PSDB value (e.g., even when processing relatively small PDU sets from the same application layer session). 5G systems can tolerate excessive latency when processing relatively small PDU sets (e.g., when assuming the same PSDB value).

[0090] NW can be configured to provide a set of (multiple) PDUs in 5GS that know the round-trip delay requirements. Figure 2 The illustration shows an example procedure 200 for configuring multi-mode requirements. Example procedure 200 may configure requirements and / or provide round-trip latency-related requirements via 5GS for a multi-mode XRM session with WTRU 202 in response to application function requests. The procedure may include configuring 5GS with round-trip latency-related requirements, for example, to serve multi-mode traffic between the application server and WTRU.

[0091] In section 218, the NW (e.g., AF 216) can request the setup of a multi-mode session, such as with WTRU 202 (e.g., via 5GS). AF 216 can request the setup of a multi-mode session by calling the NEF 214 application programming interface (API). The NEF 214 API can be based on the Nnef_AFsessionWithQoS service operation (e.g., modeled after that operation). For example, in the request, AF 216 can provide service information. Service information may include one or more of the following: flow description information, WTRU address, and / or DNN / S-NSSAI combination. For example, in the request, AF 216 can provide service requirements related to the multi-mode service, such as including QoS monitoring requirements and / or QoS parameters. QoS parameters may include packet delay budgets (e.g., for each mode) and / or one or more of the flow. AF 216 can provide PDU set QoS parameters, as in the request. QoS parameters may include PDU set delay budgets (e.g., for each mode) and / or one or more of the flow.

[0092] AF 216 can provide RT latency requirements, such as for XRM services. RT latency requirements may include one or more of RT latency requirements, UL maximum latency, and / or DL ​​maximum latency. RT latency requirements may represent a maximum threshold, such as the sum of UL latency and DL latency for a data stream between a WTRU and an N6 endpoint (e.g., at a UPF). UL maximum latency (e.g., a threshold) may represent a maximum UL PDB and / or a maximum UL PSDB. Additionally or alternatively, UL maximum latency may indicate a percentage, such as the maximum percentage of RT latency requirements that can be applied to UL services. The percentage representing the maximum percentage of RT latency requirements may vary over time. AF 216 can provide a time window regarding when the percentage is valid. AF 216 may provide different percentages using time windows for each percentage. DL maximum latency (e.g., a threshold) may correspond to a maximum DL PDB or a maximum DL PSDB. Additionally or alternatively, DL maximum latency may indicate a percentage, such as the maximum percentage of RT latency requirements that can be applied to DL services. The percentage representing the maximum RT delay requirement can vary over time. Therefore, AF 216 can provide a time window regarding when the percentage is valid. AF 216 can provide different percentages using time windows for each percentage.

[0093] The AF 216 can provide multiple sets of RT delay, UL maximum delay, and / or DL ​​maximum delay. The PCF 212 can select a combination of RT delay, UL maximum delay, and / or DL ​​maximum delay to apply. The PCF 212's decision on which combination of RT delay, UL maximum delay, and / or DL ​​maximum delay to apply can be based on measurement reports, such as those received by the PCF 212. The measurement reports may relate to delays measured on the associated uplink and / or downlink paths.

[0094] In addition to providing RT latency requirements or alternatively providing RT latency requirements, providing UL maximum latency and / or DL ​​maximum latency can be advantageous, for example, when the UL and / or DL ​​streams carry PDU sets. UL maximum latency and / or DL ​​maximum latency can be used by PCF 212, for example, to limit increases in the UL and / or DL ​​latency budget. NW can limit how RT latency is allocated between uplink and downlink streams.

[0095] AF 216 can provide a set of QoS parameters, such as for (e.g., a certain) mode with (multiple) different configurations. AF 216 can identify different modes (e.g., by their service descriptors), for example, by utilizing a multi-mode service ID. For example, for a video mode, AS can expect a specific value of frame rate and / or provide QoS parameters for each frame rate value. AF 216 can provide RT latency requirements, such as for one or more configurations. A set of requirements and QoS parameters can be indexed by an integer value. For example, indexing a set of requirements and QoS parameters by an integer value makes communication between 5GS and AS easier. For example, AS and 5GS can communicate about determining (e.g., selecting) the configuration of the XRM service mode (e.g., different indexes for different frame rates). The configuration of the mode can change, for example, due to requests from AF and / or due to changes in network conditions. 5GS can determine (e.g., the relevant) RT latency requirements, for example, by using (e.g., a new) configuration (e.g., the configuration in use) as an index. AF 216 can provide a multi-mode service ID, for example, when AF 216 provides RT latency requirements. A multimode service ID can be an identifier that associates multimode flows, such as those belonging to the same multimode service. AF 216 can provide identifiers for packet detection rules, for example, when AF 216 provides RT latency requirements. For instance, the identifier of a packet detection rule can be used by the network to detect which services are subject to those rules.

[0096] In 220, the NW (e.g., NEF 214) can authorize requests from AF 216. In 222, the NW (e.g., NEF 214) can send policy authorization requests, such as to PCF 212. The NW (e.g., NEF 214) can send information (e.g., information provided by AF 216 (e.g., in 218)) to PCF 212. The information may include one or more of RT latency requirements, traffic flow descriptors, WTRU addresses, and / or multimode service IDs. NEF 214 may alternatively or additionally send (e.g., alternatively) a list of RT latency requirements. NEF 214 can send information to PCF 212 by invoking PCF 212 Npcf_PolicyAuthorization to create and / or update service operations.

[0097] In section 224, the NW (e.g., PCF 212) can authorize requests. In section 224, PCF 212 can additionally or alternatively generate one or more policies, such as for multi-mode services (e.g., PCC rules). For example, for (multiple) RT latency requirements, PCF 212 can generate two PCC rules. One PCC rule can be associated with an uplink flow and / or another PCC rule can be associated with a downlink flow. Uplink flows can be associated with downlink flows. For example, an uplink flow can be associated with a PDB and / or a downlink flow can be associated with a PSDB.

[0098] PCF 212 can use RT delay requirements (e.g., RT delay requirement, UL maximum delay, and / or DL ​​maximum delay) to (e.g., initially) assign PCC rules to uplink and / or downlink flows. PCF 212 can create PCC rules, for example, when the UL maximum delay is greater than the DL maximum delay. A PCC rule can cause the PDB associated with an uplink flow to be greater than the PSDB associated with a downlink flow. Additionally or alternatively, a PCC rule can indicate that the sum of the UL PDB and the DL PDSB should be less than or equal to the RT delay requirement.

[0099] PCF 212 can generate QoS monitoring rules for UL data services and / or DL ​​PDU set services, such as to track RT latency. PCF 212 can associate (e.g., two) QoS monitoring rules with (e.g., using) a common identifier. The common identifier may include a multi-mode service ID.

[0100] In section 226, the NW (e.g., PCF 212) can send a policy authorization response, for example, to NEF 214. NEF 214 can receive the policy authorization response, for example, by creating a response message via PCF 212's Npcf_PolicyAuthorization. The NW (e.g., NEF 214) can send (e.g., forward) the PCF 212 response to AF 216. In section 230, the NW (e.g., PCF 212) can send PCC rules, for example, to SMF 210. In section 232, SMF 210 can send N4 rules to UPF 208. In section 234, the NW (e.g., SMF 210) can send QoS rules, for example, to WTRU 202. SMF 210 can send a QoS profile to RAN 204. PCF 212 can generate relevant QoS monitoring policies for UL data and / or DL ​​PDU aggregation streams.

[0101] NW can be configured for behavior that uses QoS monitoring reports for RT latency. Figure 3 The illustration depicts an example process 300 for configuring QoS monitoring. For example, the system and process may correspond to a situation where a multi-mode service has been established between AF 316 and WTRU 302 (e.g., utilizing provided RT latency requirements). The system and process describe monitoring aspects related to RT latency measurement and / or NW and application behavior, such as as a result of QoS latency monitoring reports.

[0102] In 318, the NW (e.g., AF 316) can request a session for a multimodal service, such as based on specific requirements. AF 316 can request a session, for example, using the methods described herein (e.g., Figure 2 The process (as shown) involves a session (e.g., a request) that can be used to establish and / or configure policies for the XRM service. Within the WTRU 320, policies for XRM services, along with one or more QoS profiles, QoS rules, and / or N4 rules, can be established. Additionally or alternatively, QoS monitoring for UL data and / or DLPDU set latency can be established, for example, for RT latency tracking. The WTRU 320 and the application server can exchange XRM services, for example, via the user plane.

[0103] In 322, the NW (e.g., UPF 308) can (e.g., begin) perform QoS monitoring, such as after establishing a user plane connection and / or after exchanging traffic between WTRU 302 and AF 316. UPF 308 can perform QoS monitoring, such as for delay measurements related to RT delay. UPF 308 can perform QoS monitoring on delay measurements related to RT delay based on a QoS monitoring policy (e.g., generated by PCF 312). For example, in the uplink direction, UPF 308 can monitor UL data packet delay between WTRU 302 and N6 endpoint. For example, in the downlink direction, UPF 308 (e.g., with the assistance of NG-RAN 304 and / or WTRU 302) can monitor DL ​​PDU set delay between N6 endpoint and WTRU 302. The monitoring processes for the uplink and / or downlink directions (e.g., both) can be performed at similar (e.g., the same) times. Performing monitoring procedures (e.g., two) at similar times allows the UPF 208 to measure the round-trip time of interest. The round-trip time of interest can be the sum of the measured uplink and downlink delays.

[0104] In 324, the NW (e.g., UPF 308) can request QoS monitoring results (e.g., to SMF 310). Monitoring results may include one or more of UL packet delay measurements, DL PDU set delay measurements, and / or the sum of both (e.g., RT delay measurements). In 326, the NW (e.g., SMF 310) can send notifications, for example, to PCF 312. For example, if the UL packet delay measurement and / or the downlink PDU set delay measurement are not within acceptable limits, SMF 310 can send a notification to PCF 312.

[0105] In 328, the NW (e.g., PCF 312) can adjust the policy based on (e.g., new) PDB and / or PDSB rules; and / or update the rules, for example, when the NW (e.g., PCF) detects that the PDB and / or PSDB of a flow are not satisfied and / or the flow is associated with RT latency requirements. For example, when the NW (e.g., PCF 312) detects that the PDB and / or PSDB of a flow are not satisfied and / or the flow is associated with RT latency requirements, the PCF can calculate (e.g., new) latency budget values ​​for the uplink and / or downlink directions. PCF 312 can determine (e.g., new) PSDB for downlink flows and / or determine (e.g., new) PDB for uplink flows. For example, when the PCF determines that the UL PDB is not satisfied and / or the DL PDSB is satisfied, PCF 312 can increase the packet latency budget for the uplink flow and / or decrease the packet set latency budget for the downlink flow. PCF 312 may additionally or alternatively maintain one or more of the following: UL PDB is less than the UL maximum delay, DL PSDB is less than the DL maximum delay, and / or the sum of UL PDB and DL PSDB is less than the RT delay requirement. PCF 312 may use the RT delay requirement (e.g., the RT delay requirement of process 200) to determine, for example, a (new) delay budget value. PCF 312 may generate (e.g., new) PCC rules for (e.g., both) uplink and / or downlink directions. PCF 312 may configure uplink flows to use (e.g., new) PCC rules and / or configure downlink flows to use (e.g., new) PCC rules.

[0106] PCF 312 can determine that it cannot increase the delay allocated to a flow whose PDB or PSDB is not satisfied, for example, when NW (e.g., PCF) detects that the flow's PDB and / or PSDB is not satisfied and / or the flow is associated with RT latency requirements. Additionally or alternatively, PCF 312 can notify AF 316 that QoS requirements cannot be met. For example, PCF 312 can determine that increasing the delay (e.g., any further) might violate the UL maximum delay and / or DL ​​maximum delay requirements (e.g., the UL maximum delay and / or DL ​​maximum delay requirements of process 200). PCF 312 can notify AF 316 that QoS requirements cannot be met, for example, when PCF 312 determines that it cannot increase the delay budget allocated to a flow whose PDB and / or PSDB are not satisfied. AF 316 can adjust application layer settings (e.g., codec settings) and / or adjust QoS requirements, for example by re-initiating the settings and / or configuration of policies for XRM services (e.g., as described in procedure 200) (e.g., to provide a new QoS configuration).

[0107] In 330, the NW (e.g., PCF 312) can generate rules (e.g., N4 rules), such as based on PCC rules. In 330, PCF 312 can additionally or alternatively send (e.g., forward) updated (e.g., a pair) of PCC rules, such as to SMF 310. SMF 310 can send (e.g., forward) N4 rules, such as to UPF 308. In 332, the NW (e.g., PCF 312) can send (e.g., forward) updated QoS rules (e.g., to WTRU 302) and / or updated pairs of QoS profiles (e.g., to RAN 304), such as via AMF 306.

[0108] In 334, the NW (e.g., PCF 312) may send (e.g., provide) informational notifications, such as to the AF 316 (e.g., via NEF 314). The PCF 312 may determine (e.g., a newly selected) index of the PSDB value (e.g., after an update), for example, when the AF 316 provides (e.g., alternative) PSDB requirements and / or RT latency requirements. The PCF 312 may send the determined index, for example, to the AF 316. In 336, the AF 316 may determine which configuration of the mode to use, such as using the determined index. Additionally or alternatively, in 336, the AF 316 may perform one or more of the following: adjust the codec configuration, change the configuration, and / or provide (e.g., new) RT requirements. The configuration may include codec settings, such as for video modes.

[0109] PCF 312 may notify AF 316 of a new pair of delay requirements selected for UL and / or DL, for example, when PCF 312 is not provided with (e.g., alternative) PSDB values, for example, through AF 316. The delay requirements for UL and / or DL ​​may be determined and / or selected to (e.g., continue) meet RT delay requirements, for example, provided by AF 316. In 336, AF 316 may use information about a pair of delay requirements (e.g., internally) to change one or more application parameters. The values ​​of DL PSDB and / or UL PDB sent to AF 316 may be indexed by 5GS, for example, if AF 316 has not (e.g., in advance) provided alternative values. PCF 312 may notify AF 316 that RT delay measurements exceed requirements, for example, when RT delay requirements cannot be met. PCF 312 may provide new RT measurements, for example, to AF 316. AF 316 may provide (e.g., new) RT measurements. Additionally or alternatively, AF 316 may provide one or more indications of whether the measured DL PDU set delay, UL PDU delay, and / or uplink delay and / or downlink delay cannot be met. In 336, AF 316 may use the provided information to access and / or change the internal configuration of AF 316. For example, AF 316 may change its internal configuration based on a new codec. AF 316 may provide 5GS / PCF 312 according to (e.g., new) RT latency requirements.

[0110] In 338, the NW (e.g., AF 316) can respond to PCF messages. For example, AF 316 can respond to PCF messages by changing application-level information. AF 316 can change application-level information including codec settings, such as indexes of the DL PSDB provided by PCF 312 (e.g., in 334). AF 316 can exchange XRM services with WTRU 302 through the user plane, such as using new codec settings. AF 316 can acknowledge this change, for example, to PCF 312 (e.g., via NEF 314).

[0111] AF 316 can respond to PCF messages by re-evaluating the RT latency requirements provided to 5GS. AF 316 can provide (e.g., new) RT latency requirements to PCF 312, for example, via NEF 314. PCF 312 can derive (e.g., new) PCC rules using the RT latency requirements and / or one or more other parameters. For example, PCF 312 can derive new PCC rules using the RT latency requirements and / or one or more other parameters. For XRM services, (e.g., new) PPC rules may include one or more of PCC rules with UL PDB and / or other PCC rules with DL PSDB.

[0112] AF 316 can determine that, under given network conditions, an acceptable user experience may not be supported for WTRU 302, and / or can respond accordingly to PCF messages. For example, AF 316 can notify the user of this event. AF 316 can trigger WTRU 302 to terminate user plane switching, such as for XRM services.

[0113] NW can be optimized to handle different PDU set sizes. AF 316 can call the NEF 314 API, for example, to provide information to 5GC regarding PSDB requirements for application layer sessions. Application layer sessions can be used to send and / or receive PDU sets of different sizes. For example, the NEF 314 API may include the Nnef_AFsessionWithQoS_Create service operation and / or the Nnef_AFsessionWithQoS_Update service operation. The procedure for calling the NEF 314 API may include steps that are the same as or similar to those described herein, such as... Figure 2 As shown. AF 316 can use the API to provide PDU set QoS parameters and / or protocol descriptions of service data streams, for example, to NEF 314. The protocol description can indicate the protocol and / or payload type, such as that used by the service data stream. PDU set QoS parameters may include PSDB information.

[0114] PSDB information may include rules. Additionally or alternatively, PSDB information may include thresholds (e.g., size). In this document, size and threshold are used interchangeably. Rules can be used by 5GC to associate PDU set sizes with PSDB values. For example, a rule may indicate that any PDU set with a size less than or equal to a first value (e.g., a threshold) has a PSDB with a second value. A rule may indicate that any PDU set with a size greater than a first value (e.g., a threshold) has a PSDB with a third value. Rules may include any number of mappings from PDU set sizes to PSDBs. The PDU set size may be represented as the total number of bytes in the PDU set and / or the total number of PDUs in the PDU set. Additionally or alternatively, rules may indicate (e.g., a single) time value. NW may determine the PSDB, for example, by multiplying the PDU set size by the time value. The time value may be multiplied by the number of PDUs in the PDU set and / or the number of bytes in the PDU set. Additionally or alternatively, rules may indicate a first value and / or a range of values, such as attributes specific to the PDU set. Additionally or alternatively, rules may indicate that any PDU set with an attribute value equal to a first value and / or within the range has a PSDB with a second value. Attributes of a PDU set may include one or more of the following: association with layer ID "0", independence from the payload of other PDU sets used for decoding, dependency on the payload of other PDU sets used for decoding, and / or PDUs set to importance "1". Attributes may be specified using IDs (e.g., independent PDU set, PDU set layer ID, importance, etc.). Rules may include any mapping of attributes(s) and / or values ​​to a PSDB. The NW may determine the PSDB by (e.g., firstly) obtaining the values ​​of the attributes (e.g., by analyzing the transport header of the PDUs) and / or by looking up the attributes and / or values ​​in(s) of the mappings.

[0115] NEF 314 can provide rules to PCF 312. PCF 312 can send rules to SMF 310, for example, as part of a PCC rule. SMF 310 can include information from rules in N4 rules, for example, this information can be sent by SMF 310 to UPF 308. For example, SMF 310 can send (e.g., one) N4 rule. The N4 rule can (e.g., to UPF 308) indicate that a set of PDUs that matches the first packet detection rule and / or is smaller than a certain size should be assigned to the first QoS flow. Additionally or alternatively, the N4 rule can (e.g., to UPF 308) indicate that a set of PDUs that matches the first packet detection rule (e.g., the same rule) and / or is greater than or equal to the same specific size should be assigned to the second QoS flow. PDU sets, PDUs, and / or packets can include information, for example, in the header. The information can be used to identify services, such as the service to which the packet belongs. For example, a packet is determined to match a PDR if information (e.g., in the header) matches or includes at least some of the information (which is identical to (multiple) information elements in a rule (e.g., a Packet Detection Rule (PDR)). A PDR may include information elements that help identify a business and / or packets belonging to a specific business. Size information may be incorporated into the packet detection rule.

[0116] SMF 310 may include information about rules from a QoS profile (e.g., one sent by SMF 310 to RAN 304). For example, SMF 310 may send a QoS profile indicating to RAN 304 that a set of PDUs from a first QoS flow smaller than a specific size (e.g., a threshold) (e.g., having a size smaller than that specific size) should be associated with a first PSDB and / or a set of PDUs from the first QoS flow (e.g., the same QoS flow) greater than or equal to a specific size (e.g., a threshold) (e.g., having a size greater than or equal to that specific size) should be associated with a second PSDB. SMF 310 may send a QoS profile indicating to RAN 304 that a set of PDUs from the first QoS flow associated with a specific PDU set attribute value and / or range should be associated with a first PSDB. Additionally or alternatively, the QoS profile may indicate that a set of PDUs from the first QoS flow (e.g., the same QoS flow) associated with other PDU set attribute values ​​and / or ranges should be associated with a second PSDB. For example, to achieve this association, UPF 308 can set attribute values ​​in the GTP-U header of the GTP-U packet used to transmit the PDU set. Examples of General Packet Radio Service Tunneling Protocol User Plane (GTP-U) header information elements (IEs) for attribute values ​​may include existing IEs such as PDU set importance. Examples of GTP-U header IEs for attribute values ​​may include one or more of the following: a new IE for independent PDU sets (e.g., 0 for dependent, 1 for independent), a layer ID (e.g., the ID indicating the decoding layer of the PDU payload), and / or a base layer (e.g., 1 for the PDU payload having a base layer for decoding, and 0 for not having a base layer for decoding).

[0117] It is worth noting that providing rule information to the UPF and RAN can be an alternative. Additionally or alternatively, the SMF 310 may include rule information from QoS rules (e.g., rules sent by the SMF 310 to the WTRU 302). For example, the SMF 310 may send (e.g., a) QoS rule (e.g., to the WTRU 302) indicating that a set of PDUs that matches and / or is smaller than a specific size and / or matches a specific attribute value / range should be assigned to a first QoS flow. Additionally or alternatively, the QoS rule may indicate that a set of PDUs that matches and / or is greater than or equal to a specific size and / or matches another attribute value / range should be assigned to a second QoS flow. Size information and / or attribute values ​​may be incorporated into the packet detection rules and / or filters.

[0118] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used individually or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include (but are not limited to) read-only memory (ROM), random access memory (RAM), registers, caches, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROMs and digital multifunction discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, and / or any host computer.

Claims

1. A network entity, the network entity comprising: Processor, the processor being configured to: Receive a message including a round-trip (RT) delay requirement, wherein the RT delay requirement includes uplink delay information and downlink delay information; A first policy charging and control (PCC) rule is generated based on the uplink delay information and the downlink delay information; Send the first information indicating the first PCC rule to the Session Management Function (SMF); Receive one or more notifications associated with the flow, either uplink delay or downlink delay; The second PCC rule is determined based on the uplink delay information and the downlink delay information; as well as The second information instructing the second PCC rule is sent to the SMF.

2. The network entity of claim 1, wherein the notification is a first notification, and wherein the processor is further configured to send a second notification to an application function (AF), wherein the second notification includes an indication that a PCC rule satisfying one or more of the RT latency requirement, the uplink latency information, or the downlink latency information cannot be generated.

3. The network entity according to claim 1, wherein the RT latency requirement includes a first RT latency requirement, the uplink latency information includes first uplink latency information, and the downlink latency information includes first downlink latency information, and wherein the processor is further configured to: Determine the second RT delay requirement, which includes second uplink delay information and second downlink delay information; The third PCC rule is determined based on the second RT delay requirement; and The third PCC rule is sent to the SMF.

4. The network entity of claim 1, wherein the uplink delay information includes an indication of one or more of the maximum uplink packet delay budget (PDB) or the maximum uplink protocol data unit (PDU) set delay budget (PSDB), and wherein the downlink delay information includes an indication of one or more of the maximum downlink PDB or the maximum downlink PSDB.

5. The network entity of claim 1, wherein the message includes one or more of a multimode service identifier (ID) or a service descriptor.

6. The network entity of claim 1, wherein the network entity includes a policy control function (PCF).

7. The network entity of claim 1, wherein the notification includes an indication that one or more of the uplink delay or downlink delay associated with the flow are not within the range required by the first PCC rule.

8. The network entity of claim 1, wherein the processor is further configured to generate N4 rules based on the second PCC rule.

9. The network entity of claim 1, wherein the flow associated with one or more of the uplink delay or the downlink delay is further associated with one or more of the first PCC rule or the second PCC rule.

10. A method performed by at least one network entity, the method comprising: Receive a message including a round-trip (RT) delay requirement, wherein the RT delay requirement includes uplink delay information and downlink delay information; A first policy charging and control (PCC) rule is generated based on the uplink delay information and the downlink delay information; Send the first information indicating the first PCC rule to the Session Management Function (SMF); Receive one or more notifications associated with the flow, either uplink delay or downlink delay; The second PCC rule is determined based on the uplink delay information and the downlink delay information; as well as The second information instructing the second PCC rule is sent to the SMF.

11. The method of claim 10, wherein the notification is a first notification, and wherein the method further comprises sending a second notification to an application function (AF), wherein the second notification includes an indication that a PCC rule satisfying one or more of the RT latency requirement, the uplink latency information, or the downlink latency information cannot be generated.

12. The method of claim 10, wherein the RT delay requirement includes a first RT delay requirement, the uplink delay information includes first uplink delay information, and the downlink delay information includes first downlink delay information, and wherein the method further includes: Determine the second RT delay requirement, which includes second uplink delay information and second downlink delay information; The third PCC rule is determined based on the second RT delay requirement; and The third PCC rule is sent to the SMF.

13. The method of claim 10, wherein the uplink delay information includes an indication of one or more of the maximum uplink packet delay budget (PDB) or the maximum uplink protocol data unit (PDU) set delay budget (PSDB), and wherein the downlink delay information includes an indication of one or more of the maximum downlink PDB or the maximum downlink PSDB.

14. The method of claim 10, wherein the message includes one or more of a multimode service identifier (ID) or one or more service descriptors.

15. The method of claim 10, wherein the network entity includes a policy control function (PCF).

16. The method of claim 10, wherein the notification includes an indication that one or more of the uplink delay or downlink delay associated with the flow are not within the range required by the first PCC rule.

17. The method of claim 10, further comprising generating an N4 rule based on the second PCC rule.

18. The method of claim 10, wherein the flow associated with one or more of the uplink delay or the downlink delay is further associated with one or more of the first PCC rule or the second PCC rule.

Images