Allocation of network resources based on latency information

Abstract

A device (for example, at least one network entity) can receive a message. The message may include round-trip (RT) latency requirements. The RT latency requirements may include uplink latency information and / or downlink latency information. The device may generate a first policy billing control (PCC) rule based on, for example, the uplink latency information and / or downlink latency information. The device may send first information indicating the first PCC rule to, for example, a session management function (SMF). The device may receive a notification that one or more of the uplink latency and / or downlink latency are associated with a flow. The device may determine a second PCC rule based on, for example, the uplink latency information and downlink latency information. The device may send second information indicating the second PCC rule to, for example, an SMF.

Description

Technical Field

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

Background Art

[0002] An application function (AF) can provide protocol data unit (PDU) set - related assistance information for dynamic policy charging and control (PCC). Parameters can be included in PDU set QoS parameters. One parameter can include a PDU set delay budget (PSDB). The PSDB is an upper limit regarding the delay that a PDU set can experience for transfer between a wireless transmit - receive unit (WTRU) and an N6 endpoint at a user plane function (UPF), for example, the duration between the reception time of the first PDU and the time when all PDUs of the PDU set are successfully received.

Summary of the Invention

[0003] The present disclosure relates to devices, methods, and systems for allocating network resources based on the delay requirements of extended reality and media (XRM) traffic. Devices, methods, and systems for allocation of network resources, specifically for latency and coverage enhancement related to allocation of network resources based on the delay requirements of XRM traffic, are provided herein.

[0004] These devices, methods, and systems relate, for example, to round-trip (RT) time requirements with uplink and downlink latency limits. These devices, methods, and systems relate, for example, to determining QoS requirements based on PDU set attributes. In one or more cases, these devices, methods, and systems receive messages containing RT latency requirements, where RT latency requirements include uplink latency information and downlink latency information. In one or more cases, these devices, methods, and systems use the uplink latency information and downlink latency information to create policy billing control (PCC) rules and send those PCC rules to the Session Management Function (SMF). In one or more cases, these devices, methods, and systems receive notifications that the latency associated with a flow is not within the range required by the PCC rules. In one or more cases, these devices, methods, and systems perform one of the following actions based on a received notification: determine new PCC rules using uplink delay information and downlink delay information and send those new PCC rules to the SMF; determine that it is not possible to create a PCC rule that satisfies all of the requirements indicated in the RT latency requirements, uplink delay information, and downlink delay information, and send a notification to the AF based on that determination; and determine a new set of RT latency requirements, uplink delay information, and downlink delay information, calculate new PCC rules based on the new set of RT latency requirements, uplink delay information, and downlink delay information, determine new PCC rules using the new uplink delay information and downlink delay information, and send those new PCC rules to the SMF.

[0005] A device (for example, at least one network entity) can receive a message. The message may include round-trip (RT) latency requirements. The RT latency requirements may include uplink latency information and / or downlink latency information. The device may generate a first policy billing control (PCC) rule based on, for example, the uplink latency information and / or downlink latency information. The device may send first information indicating the first PCC rule to, for example, a session management function (SMF). The device may receive a notification that one or more of the uplink latency and / or downlink latency are 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 are not within the range required by the first PCC rule. The device may determine a second PCC rule based on, for example, the uplink latency information and downlink latency information. The device may send second information indicating the second PCC rule to, for example, an SMF. A message may contain one or more multimodal service identifiers (IDs) and / or one or more traffic descriptors. One or more traffic descriptors may contain one or more representations of uplink data flows and / or downlink data flows.

[0006] The device can send a notification (for example, a second notification) to, for example, an application function (AF). This notification may include an indication that it is not possible to generate a PCC rule that satisfies one or more of the following: RT latency requirements, uplink delay information, and / or downlink delay information. The RT latency requirements may include the first RT latency requirements. The uplink delay information may include the first uplink delay information. The downlink delay information may include the first downlink delay information. The device can determine a second RT latency requirement. The second RT latency requirement may include the second uplink delay information and / or the second downlink delay information. The device can determine a third PCC rule based on, for example, the second RT latency requirement. The device can send the third PCC rule to the SMF.

[0007] Uplink delay information may include one or more representations 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 one or more representations of the maximum downlink PDB and / or the maximum downlink PSDB. The device may include policy control functions (PCFs). The device may generate N4 rules based, for example, on a second PCC rule. The device may send one or more quality of service (QoS) profiles to the access network and / or QoS rules to the wireless transceiver units (WTRUs). Flows associated with one or more uplink delays and / or downlink delays may be associated with one or more of the first PCC rules and / or the second PCC rules, either additionally or as an alternative.

[0008] A device can receive protocol data unit (PDU) set delay budget (PSDB) information, for example, from an application function (AF). The PSDB information may indicate a first PSDB value representing a PDU set size above a threshold, and / or a second PSDB value representing a PDU set size below a threshold. The device can generate rules that indicate PDU sets with a set size below a threshold should be allocated to a first quality of service (QoS) flow, and / or PDU sets with a set size above a threshold should be allocated to a second QoS flow. The device can send information indicating these rules to one or more of the following: a wireless transceiver unit (WTRU), a user plane function (UPF), or a radio access network (RAN).

[0009] The rule may include a display of a QoS profile, which may indicate, for example, that a set of PDUs from a first QoS flow with a set size below a threshold should be associated with a first PSDB value. The QoS profile may also, or alternatively, indicate that a set of PDUs from a 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 Billing Control (PCC) rules from, for example, a Policy Control Function (PCF). The device may generate N4 rules based on, for example, PCC rules. The device may send information indicating the N4 rules to, for example, a User Plane Function (UPF). The device may send an indication of whether one or more of the first QoS flows and / or the second QoS flows are within the delay range required by the rule. The rules may include representations of QoS rules, which may indicate, for example, that PDU sets with a set size matching a first packet detection rule and / or below a threshold should be associated with a first QoS flow. Additionally, or alternatively, the QoS rules may indicate that PDU sets with a set size matching a first packet detection rule and / or above a threshold should be associated with a second QoS flow. Representations of thresholds may be included in the PSDB information. [Brief explanation of the drawing]

[0010] A more detailed understanding can be obtained from the following description provided with the attached diagrams, and similar reference numbers in the diagrams refer to the same elements.

[0011] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments can be implemented. [Figure 1B] Figure 1A is a system diagram showing an exemplary wireless transceiver unit (WTRU) that can be used in the communication system shown. [Figure 1C] This is a system diagram showing exemplary radio access networks (RANs) and exemplary core networks (CNs) that can be used within the communication system shown in Figure 1A. [Figure 1D] Figure 1A is a system diagram showing further exemplary RAN and further exemplary CN that can be used within the communication system shown. [Figure 2] This diagram shows an example of steps for configuring multimodal requirements. [Figure 3] This diagram shows an example of the steps for configuring QoS monitoring. [Modes for carrying out the invention]

[0012] Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments can be implemented. The communication system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcasting, etc., to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 can employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), quadrature FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique word DFT-Spread OFDM (ZT UW DFT-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filtered bank multicarrier (FBMC), etc.

[0013] As shown in Figure 1A, the communication system 100 may include radio transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments assume any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d (any of which may be referred to as “station” and / or “STA”) can be configured to transmit and / or receive radio 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, radio sensors, hotspots or Mi-Fi devices, IoT devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in the context of industrial and / or automated processing chains), consumer electronics, and devices operating on commercial and / or industrial radio networks. Any of WTRU102a, 102b, 102c, and 102d may be referred to interchangeably as WTRU.

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

[0015] 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 a base station controller (BSC), a radio network controller (RNC), and relay nodes. Base stations 114a and / or base stations 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 licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells may provide coverage for radio services to a particular geographic area, which may be relatively fixed or may change over time. Cells may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In embodiments, the 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 may be used to transmit and / or receive signals in a desired spatial direction.

[0016] Base stations 114a and 114b are capable of communicating with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, the air interface 116 can be any suitable radio communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

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

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

[0019] In the embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as NR radio access, which enables the establishment of an air interface 116 using New Radio (NR).

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

[0021] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c can implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-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 for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0022] The base station 114b in FIG. 1A 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 connections in a local area, such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (e.g., for use by drones), a roadway, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Therefore, it is possible that the base station 114b is not required to access the Internet 110 via the CN 106 / 115.

[0023] RAN104 / 113 can be in communication with CN106 / 115, which can be any type of network configured to provide voice, data, applications, and / or VoIP services to one or more of WTRU102a, 102b, 102c, and 102d. The data can have various quality of service (QoS) requirements, such as separate throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 can provide call control, billing services, mobile location services, prepaid calls, internet connectivity, video distribution, and / or perform high-level security functions, such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 can be in direct or indirect communication with other RANs employing the same RAT as RAN104 / 113 or different RATs. For example, CN106 / 115 may be connected to RAN104 / 113, which may be using NR radio technology, and may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0024] CN106 / 115 can also serve as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 can include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols, such as TCP, UDP, and / or IP in the Transmission Control Protocol (TCP) / Internet Protocol (IP) Internet protocol suite. The network 112 can include a wired communication network and / or a wireless communication network that is owned and / or operated by other service providers. For example, the network 112 can include another CN that is connected to one or more RANs that can employ the same RAT or a different RAT as the RAN104 / 113.

[0025] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 can include a multimode function (e.g., the WTRU102a, 102b, 102c, 102d can include multiple transceivers to communicate with different wireless networks via separate wireless links). For example, the WTRU102c shown in FIG. 1A can be configured to communicate with a base station 114a that can employ a cellular-based wireless technology and a base station 114b that can employ an IEEE802 wireless technology.

[0026] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among many others, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a GPS chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any subcombination of the aforementioned elements while maintaining consistency with the embodiment.

[0027] The processor 118 can be a general-purpose processor, a dedicated 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 ASIC, an FPGA circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, and the transceiver 120 can be coupled to the transmit / receive element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

[0029] Although the transmitting / receiving element 122 is shown as a single element in Figure 1B, the WTRU 102 can include any number of transmitting / receiving elements 122. More specifically, the WTRU 102 can employ MIMO technology. Therefore, in one embodiment, the WTRU 102 can include two or more transmitting / receiving elements 122 (e.g., multiple antennas) to transmit and receive radio signals via the air interface 116.

[0030] The transceiver 120 can be configured to modulate the signal to be transmitted by the transmitting / receiving element 122 and to demodulate the signal received by the transmitting / receiving element 122. As described above, the WTRU 102 can have multimode functionality. Therefore, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0031] The processor 118 of the WTRU102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from there. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in those memories. Non-removable memory 130 can include RAM, ROM, a hard disk, or any other type of memory storage device. Removable memory 132 can include a SIM card, memory stick, SD memory card, etc. In other embodiments, the processor 118 can access information in memory on, for example, a server or home computer (not shown), which is not physically located on the WTRU 102, and store data in that memory.

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

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

[0034] The processor 118 can be further coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide further features, functionality, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, e-compass, satellite transceiver, digital camera (for photography and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth® module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0035] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with specific subframes with respect to both UL (e.g., for transmission) and DL (e.g., for reception)) can be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., chokes) or a separate processor (e.g., not shown) or via processor 118). In embodiments, WRTU102 may include a half-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with specific subframes of either UL (e.g., for transmission) or DL ​​(e.g., for reception)) can be parallel and / or simultaneous.

[0036] Figure 1C is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 can employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 can also be in communication with CN106.

[0037] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with the embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers to communicate with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B160a may use multiple antennas, for example, to transmit radio signals to and / or receive radio signals from WTRU102a.

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

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

[0040] The MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can act as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial connection of WTRU102a, 102b, and 102c. The MME162 can also provide control plane functionality for switching between RAN104 and other RANs (not shown) employing GSM and / or other radio technologies such as WCDMA.

[0041] The SGW164 can be connected to each of the eNode B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions, such as fixing the user plane during handover between eNode B, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and storing the context of WTRU102a, 102b, and 102c.

[0042] SGW164 can be connected to PGW166, which can provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0043] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial communication line devices. For example, CN106 can include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. In addition, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

[0044] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, it is assumed that such a terminal can use a wired communication interface with a communication network (for example, temporarily or permanently).

[0045] In a typical embodiment, the other network 112 can be a WLAN.

[0046] In Infrastructure Basic Service Set (BSS) mode, a WLAN can have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs can have access to or interfaces with a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic originating outside the BSS and destined for an STA can be received through the AP and delivered to the STA. Traffic originating from an STA and destined for an external destination can be sent to the AP and delivered to its respective destination. Traffic between STAs within the BSS can be sent through the AP; for example, a source STA can send traffic to the AP, which can then deliver that 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 a source STA and a destination STA (e.g., directly between them) using a Direct Link Setup (DLS). In certain representative embodiments, the DLS can use either 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all of the STAs) can communicate directly with one another. The IBSS mode of communication may sometimes be referred to herein as the “ad-hoc” mode of communication.

[0047] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width 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 certain typical embodiments, for example in an 802.11 system, a Carrier Sensitive Multiple Access / Collision Avoidance Scheme (CSMA / CA) can be implemented. With respect to CSMA / CA, an STA, including the AP (e.g., any STA), can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA can withdraw. One STA (e.g., only one station) can transmit on a given BSS at any given time.

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

[0049] Ultra-high throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz channels and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. 160 MHz channels can be formed by combining eight adjacent 20 MHz channels or by combining two non-adjacent 80 MHz channels (this can be called an 80+80 configuration). For the 80+80 configuration, the data can be passed through a segment parser after channel coding, which can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0050] The sub-1GHz mode of operation is supported by 802.11af and 802.11ah. Channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5MHz, 10MHz, and 20MHz in the TV white space (TVWS) spectrum, while 802.11ah supports bandwidths of 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including support for certain and / or limited bandwidths (e.g., support only for those). MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0051] A WLAN system capable of supporting multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, includes 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 smallest bandwidth operating mode among all STAs operating in the BSS. In the case of 802.11ah, for an STA that supports (e.g., only supports) the 1MHz mode (e.g., an MTC type device), 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 may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (which only supports 1MHz operating mode) is transmitting to an AP, the entire available frequency band may be considered busy, even if a large portion of those frequency bands could remain idle and be available.

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

[0053] Figure 1D is a system diagram showing RAN113 and CN115 according to an embodiment. As described above, RAN113 can employ NR radio technology to communicate with WTRU102a, 102b, and 102c via air interface 116. RAN113 can also be in communication with CN115.

[0054] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with the embodiment. Each of the gNB180a, 180b, and 180c may include one or more transceivers to communicate with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, the gNB180a, 180b, and 180c may implement MIMO technology. For example, the gNB180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNB180a, 180b, and 180c. Therefore, the gNB180a may use multiple antennas to transmit radio signals to and / or receive radio signals from the WTRU102a. In embodiments, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In embodiments, gNB180a, 180b, and 180c can implement coordinated multipoint (CoMP) technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0055] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may differ for separate transmissions, separate cells, and / or separate parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or lasting over varying lengths of absolute time).

[0056] The gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can use one or more of the gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c using signals in unlicensed bands. In configurations that are not standalone, WTRU102a, 102b, and 102c can communicate with / connect to gNB180a, 180b, and 180c while also communicating with / connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In non-standalone configurations, eNode-B160a, 160b, and 160c can serve as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

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

[0058] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. While each of the aforementioned elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0059] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N2 interface and can act as control nodes. For example, AMF182a and 182b can be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling separate PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services utilized by WTRU102a, 102b, and 102c. For example, separate network slices can be established for different use cases, such as services that rely on ultra-high reliability low latency (URLLC) access, services that rely on extended capacity mobile broadband (eMBB) access, and services related to machine-type communications (MTC) access. The AMF162 can provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other wireless technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0060] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b, and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions, such as managing and assigning 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.

[0061] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N3 interface, which can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184a and 184b can also 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.

[0062] CN115 can facilitate communication with other networks. For example, CN115 can include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. In addition, CN115 can provide WTRU102a, 102b, and 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, and 102c can be connected to local DN185a, and 185b via UPF184a, and 184b through an N3 interface to UPF184a, and 184b, and an N6 interface between UPF184a, and 184b and data networks (DNs) 185a, and 185b.

[0063] Considering Figures 1A to 1D and the corresponding descriptions therein, one or more or all of the functions described herein in relation to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device can be used to test other devices and / or to simulate network functions and / or WTRU functions.

[0064] Emulation devices can be designed to perform one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices can perform one, more, or all functions while being implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in that network. One or more emulation devices can perform one, more, or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices can be directly coupled to another device for testing purposes and / or testing can be performed using over-the-air radio communication.

[0065] One or more emulation devices can perform one or more functions, including all functions, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be used in a testing scenario in a testing laboratory and / or an undeployed (e.g., testing) wired and / or wireless communication network to perform testing of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0066] A network (NW) can be configured with RT latency information (e.g., latency requirements). Additionally, or alternatively, the NW can be configured with information (e.g., exceeding RT latency requirements) in, for example, a policy control function (PCF). This information may include one or more of the maximum uplink delay and / or maximum downlink delay. The uplink delay and / or downlink delay may include a protocol data unit (PDU) set delay budget (PSDB). For example, configuring the uplink delay and / or downlink delay to be a PSDB (e.g., including a PSDB) may allow an application function (AF) to configure round-trip time requirements. Round-trip time requirements may be for scenarios where traffic in one direction carries a set of PDUs and / or traffic in another direction carries PDUs that are not part of the set.

[0067] The Session Management Function (SMF) can receive PSDB information, for example, from the PCF. PSDB information can be used to determine the PSDB of a PDU set. PSDB information can include PSDB determination rules, which can map, for example, one or more traffic characteristics to the PSDB. One or more of these traffic characteristics may relate to the size of the PDU set. The network, for example, the SMF, can use the PSDB information to construct one or more rules. These one or more rules can be N4 rules. The SMF can send one or more rules (for example, information indicating one or more rules) to, for example, the User Plane Function (UPF). The network (e.g., the SMF) can send rule-indicating information to one or more of the following: a Wireless Transceiver Unit (WTRU), the User Plane Function (UPF), or the Radio Access Network (RAN). These one or more rules can include packet detection rules. One or more rules can indicate to a UPF, for example, that a set of PDUs matching a specific packet detection rule and / or being below a certain size should be allocated to a Quality of Service (QoS) flow (e.g., a specific one). That flow can be associated with one or more uplink delays or downlink delays. Additionally, or alternatively, that flow can be associated with one or more of the (e.g., first) PCC rules and / or the (e.g., second / new) PCC rules.

[0068] A network, such as a PCF, can receive messages. Messages can include RT latency requirements. Messages can be received from an AF. RT latency requirements can include uplink delay information and / or downlink delay information. For example, a message can include a multimodal service identifier (ID). Additionally or alternatively, a message can include one or more traffic descriptors, which can identify, for example, uplink and / or downlink data flows. Uplink delay information can indicate (e.g., represent) the maximum uplink PDB and / or maximum uplink PSDB. Additionally or alternatively, uplink delay information can indicate a percentage representing the maximum percentage of RT latency requirements that can be applied to uplink traffic. Downlink delay information can represent the maximum downlink PDB and / or maximum downlink PSDB. Additionally or alternatively, downlink delay information can indicate a percentage representing the maximum percentage of RT latency requirements that can be applied to downlink traffic.

[0069] A network, such as a PCF, can generate (e.g., create) PCC rules using uplink delay information and / or downlink delay information. The PCF can send information indicating the PCC rules to the SMF. A network, such as a 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 network, such as a PCF, can determine (e.g., a new) PCC rule. The network can determine a PCC rule based on the notification (e.g., that the notification was received). For example, based on the notification being received, the PCF can determine a new PCC rule using uplink delay information and / or downlink delay information. 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 to, for example, the SMF.

[0070] The PCF may determine (for example, based on receiving a notification) that it is not possible to create a PCC rule that satisfies the requirements (e.g., all of the requirements). The requirements may be indicated in one or more of the RT latency requirements, uplink delay information, and / or downlink delay information. Based on the determination that it is not possible to create a PCC rule that satisfies the requirements (e.g., all of the requirements), the PCF may send a notification to the AF. The notification may include an indication of whether one or more of the uplink delay and / or downlink delays can be satisfied (e.g., or can be satisfied). Based on the notification (e.g., receiving a notification), the PCF may determine one or more of the new sets of RT latency requirements, uplink delay information, and / or downlink delay information. The PCF may calculate a new PCC rule based on the new sets of RT latency requirements, uplink delay information, and / or downlink delay information. The PCF may determine a new PCC rule using the new uplink delay information and / or downlink delay information. The PCF can send new PCC rules to, for example, the SMF. New sets of RT latency requirements, uplink delay information, and / or downlink delay information can be based on sets of values ​​previously provided, for example, by the AF. The PCF can send a notification to the AF to inform it that, for example, a new set of values ​​has been used.

[0071] A network, such as an SMF, can be configured to determine QoS requirements. For example, a network can determine QoS requirements based on one or more PDU set attributes. A network, such as an SMF, can receive PSDB information. PSDB information can be received from a PCF. PSDB information can be used to determine the PSDB of a PDU set. PSDB information can include PSDB determination rules that map traffic characteristics to the PSDB. At least one of these characteristics may be related to the size of the PDU set.

[0072] A network (NW), such as an SMF, can use PSDB information to construct and / or send N4 rules. The NW can send N4 rules to a UPF. N4 rules can include packet detection rules. For example, an N4 rule might indicate to the UPF that sets of PDUs matching a first packet detection rule and / or being below a certain size should be allocated to a first QoS flow. Additionally, or alternatively, an N4 rule might indicate that sets of PDUs matching a first packet detection rule (e.g., the same rule) and / or being above a certain size should be allocated to a second QoS flow. Size information can be included with the packet detection rules (e.g., integrated into the packet detection rules). A network (NW), such as an SMF, can use PSDB information to construct QoS profiles. The NW can send QoS profiles to a RAN, for example. The QoS profile might indicate to the RAN that sets of PDUs from a first QoS flow that are below a certain size should be associated with a first PSDB. As an addition or alternative, a QoS profile can indicate to a RAN, for example, that a set of PDUs from a first QoS flow (e.g., the same QoS flow) and / or of the same specific size or larger should be associated with a second PSDB.

[0073] A network (e.g., an SMF) can use PSDB information to construct QoS rules. The network can send QoS rules to a WTRU, for example. The SMF can send a QoS rule indicating (e.g., to a WTRU) that sets of PDUs that match a first packet detection rule and / or filter and / or are less than a certain size (e.g., a threshold) should be allocated to a first QoS flow. The SMF can also send an indication (e.g., to a WTRU) that sets of PDUs that match a first packet detection rule and / or filter (e.g., the same filter) and / or are greater than or equal to a certain size (e.g., a threshold) should be allocated to a second QoS flow. This indication can be sent as part of the indicated QoS rule and / or as a new QoS rule. Size information can be included with (e.g., integrated into) the packet detection rules and / or filters.

[0074] PSDB determination rules and / or QoS profiles can indicate that any PDU set having a size less than or equal to a first value can have a PSDB of a second value. PSDB determination rules can indicate that any PDU set having a size greater than the first value can have a PSDB of a third value. N4 rules and / or QoS rules can indicate that any PDU set having a size less than or equal to a first value (e.g., any PDU set) should be allocated to the first QoS flow. PSDB determination rules can indicate that any PDU set having a size greater than the first value (e.g., any PDU set) should be allocated to the second QoS flow. PSDB determination rules and / or QoS profiles can include any number of mappings of PDU set sizes to PSDBs. N4 rules and / or QoS rules can include any number of mappings of PDU set sizes to QoS flows. The PDU set size in one or more of the PSDB determination rules, QoS profiles, N4 rules, and / or QoS rules can be expressed as the total number of bytes in the PDU set and / or the total number of PDUs in the PDU set. The PSDB determination rules and / or QoS profiles can represent a time value (e.g., a single value). The SMF and / or RAN can 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. The PSDB determination rule can be included in the N4 rule and / or QoS rule. The PSDB determination rule can be a standalone rule.

[0075] A WTRU can be configured to determine QoS flow allocation based, for example, on one or more PDU set attributes. A WTRU can receive QoS rules, for example, from an SMF. The QoS rules can indicate (for example, to the WTRU) that PDU sets matching a first packet detection rule and / or filter, and / or being below a certain size, should be allocated to a first QoS flow. Additionally, or alternatively, the QoS rules can indicate that PDU sets matching a first packet detection rule and / or filter (e.g., the same filter), and / or being above a certain size, should be allocated to a second QoS flow. Size information can also be integrated into the packet detection rules and / or filters.

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

[0077] The network can be configured with a PSDB. The network, for example, the AF, can provide PDU set-related support information for dynamic PCC control. The PDU set-related support information can include one or more parameters. The parameters can be included in the PDU set QoS parameters. The parameters can include the PDU set delay budget. The PDU set delay budget (PSDB) can correspond to a maximum value (e.g., a threshold) for delay. The delay may be the delay that the PDU set may experience with respect to the transfer between the WTRU and the N6 termination point, for example, in the UPF. The delay can include the duration between the time the first PDU is received (e.g., at the N6 termination point for DL ​​and / or at the WTRU for UL) and the time when all PDUs in the PDU set are successfully received (e.g., at the WTRU for DL ​​or at the N6 termination point for UL). PSDB can apply to one or more DL PDU sets received by a PDU session anchor (PSA) UPF via the N6 interface, and / or UL PDU sets transmitted by a WTRU. PSDB can take precedence over the packet delay budget (PDB) if, for example, PSDB is available.

[0078] The network can be configured with uplink and / or downlink policy controls, for example, for XRM services. The network can be configured with uplink and / or downlink policy controls based on round-trip (RT) latency (for example, for XRM services). The RT latency indicator can indicate that the service data flow must meet the RT latency requirements of the service. The RT latency requirement can be twice the unidirectional delay requirement between the WTRU and the PSA UPF, described, for example, by the QoS reference parameter and / or individual QoS parameters.

[0079] Enhancements to 5G systems can enable policy control based on round-trip latency requirements, for example. The AF can indicate to the PCF, for example, that UL flows and / or DL ​​flows must meet RT latency requirements. RT latency requirements can include, for example, a maximum value (e.g., a threshold) for the sum of UL and DL delays of data flows between the WTRU and, for example, the N6 termination point in the UPF. The PCF can monitor the delays for UL flows and / or DL ​​flows (e.g., both). The PCF can adjust the UL PDB and / or DL ​​PDB based, for example, the observed network performance.

[0080] XRM traffic can be transported using PDU sets. QoS flows can not be associated with any PDB if, for example, the QoS flow transports a PDU set. QoS flows can be associated with a PSDB (e.g., only a PSDB). For example, if a PDU set is transported in a flow in one direction, the associated flow in the other direction can not transport a PDU set. Downlink traffic can be based on PDU sets in some XRM scenarios. Additionally or alternatively, corresponding uplink traffic can correspond to data flows that do not transport PDU sets. For example, if a user is using VR glasses and / or haptic gloves for an XRM service, the downlink traffic supplied to the VR glasses and / or haptic gloves can be in the form of a PDU set (e.g., a PDU set for video modality). Uplink traffic can transport posture information, for example, to inform the application server of the user's posture and / or haptic feedback. Posture information and / or haptic feedback can not be transported using a PDU set (e.g., using a regular PDU). The downlink flow may carry PDU sets, and / or the associated uplink flow may carry acknowledgments and / or haptic feedback (e.g., traffic not carried in the PDU sets). For example, if the delay of DL traffic is below the PSDB, a margin (e.g., additional) may be added to the UL PDB. For example, if the delay of uplink traffic is below the PDB, a margin (e.g., additional) may be added to the downlink PSDB.

[0081] The system should not (e.g., always) assume that the uplink delay margin (e.g., all of the uplink delay margin) should be added to the downlink PSDB. For example, it is possible that some of the uplink delay margin may be added to the downlink PSDB, or that no uplink delay margin may be added to the downlink PSDB at all. Downlink traffic may carry updated scene information, and / or uplink traffic may carry acknowledgments of updated scene information. For example, a user may perceive a delay when viewing scene changes due to a delayed reception of updated scene information, which may result in a degraded user experience. For example, if round-trip time delays are evenly distributed between the uplink and downlink flows, the quality of the experience may be degraded.

[0082] For example, if an XRM application service provider is exposed to detailed uplink and / or downlink delay information, the XRM application service provider can learn that UL / DL delays are configured with (e.g., efficient) combinations. The XRM application service provider can configure (e.g., customize) the UL / DL configuration to best suit the XRM application, for example. Additionally, or alternatively, XRM traffic can contain more than one uplink and / or one downlink flow, for example, with respect to each modality and / or the same modality. UL / DL granularity can help application providers adjust requirements across multiple flows. For example, round-trip delay measurement, based on measuring the delay associated with individual packets, may not be sufficient. For example, RT delay measurement, based on measuring the delay associated with individual packets, may not be sufficient when a set of PDUs is sent in the uplink and / or downlink directions. Enhancements to 5G systems are provided herein, for example, in these enhancements, the AF can configure RT latency requirements for uplink and / or downlink flows (e.g., combinations). Uplink flows and / or downlink flows can carry PDU sets. The AF can measure the delay associated with the combination of flows. The AF can adjust the PSDB and / or PDB of the flows based, for example, configuration information and / or measurement information.

[0083] Some applications may need to control latency for more than one uplink and / or downlink flow (e.g., a combination thereof). Timing and / or perceived quality (QoE) for an application may depend, for example, on a combination of two downlink media flows and one uplink data flow. For example, the systems and procedures described herein for one UL and one DL flow can be used to enable AF (for example, to support such cases). The procedures described herein may specify UL and / or DL ​​delays for three or more flows, for example, so that the combination of delays provides the required round-trip time (RTT) for the application traffic.

[0084] 5G systems enable the AF to provide a PDU set delay budget (PSDB) to, for example, the 5GC. The 5GC can associate the PSDB with a QoS flow. Associating the PSDB with a QoS flow allows the PCF to use the PSDB to construct PCC rules that can be sent to the SMF, and / or the SMF to send the PSDB to the NG-RAN, for example, as part of a QoS profile. 5G systems can support enhancements that account for variations in the size of PDU sets in application layer sessions (e.g., Real-Time Transport Protocol (RTP) sessions). For example, if the size of PDU sets in an application layer session (e.g., an RTP session) can vary, a single PSDB configured for the session may not be sufficient. For example, if a (e.g., single) PSDB is provided, the PSDB can be set to a value that is large enough to accommodate the largest expected PDU set that may be sent in the application layer session. 5G systems (e.g., including the NG-RAN) can assume the same PSDB value (e.g., even when dealing with relatively small PDU sets from the same application layer session). 5G systems can tolerate excessively large delays when dealing with relatively small PDU sets, for example, when assuming the same PSDB values.

[0085] The network can be configured to provide round-trip latency requirements that recognize the PDU set in the 5GS. Figure 2 shows an exemplary procedure 200 for configuring multimodal requirements. The exemplary procedure 200 can accommodate an application function requesting that the requirements for a multimodal XRM session with the WTRU202 be configured through the 5GS and / or that the requirements related to round-trip latency be provided. The process can include configuring the 5GS with round-trip latency requirements to provide multimodal traffic between, for example, an application server and a WTRU.

[0086] In 218, a network, such as AF216, can request to set up a multimodal session with, for example, WTRU202 (e.g., via 5GS). AF216 can request to set up a multimodal session by calling the NEF214 Application Programming Interface (API). The NEF214 API can be based on (e.g., modeled after) the Nnef_AFsessionWithQoS service operation. In the request, for example, AF216 can provide service information. Service information can include one or more combinations of flow description information, WTRU address, and / or DNN / S-NSSAI. AF216 can provide service requirements related to the multimodal service, such as QoS monitoring requirements and / or QoS parameters, in the request. QoS parameters can include one or more of packet delay budgets (e.g., for each modality) and / or flows. AF216 can provide PDU set QoS parameters in the request. QoS parameters can include one or more of the following: PDU set delay budget (e.g., for each modality) and / or flow.

[0087] AF216 can provide RT latency requirements, for example, for XRM services. RT latency requirements can include one or more of the following: RT latency requirements, UL maximum delay, and / or DL ​​maximum delay. RT latency requirements can represent a maximum threshold for the sum of UL and DL delays of data flow between the WTRU and the N6 termination point (e.g., in UPF). UL maximum delay (e.g., threshold) can represent the maximum UL PDB and / or maximum UL PSDB. Alternatively, or additionally, UL maximum delay can represent a percentage representing the maximum percentage of the RT latency requirement that can be applied to UL traffic. The percentage representing the maximum percentage of the RT latency requirement may change over time. AF216 can provide a time frame for the duration for which the percentage is valid. AF216 can provide time frames for each separate percentage. The maximum DL delay (e.g., threshold) can correspond to the maximum DL PDB or maximum DL PSDB. Alternatively, or additionally, the maximum DL delay can represent a percentage that represents the maximum percentage of the RT latency requirement, which can be applied, for example, to DL traffic. The percentage representing the maximum percentage of the RT latency requirement may change over time. Therefore, AF216 can provide a time frame for the period during which the percentage is valid. AF216 can provide time frames for separate percentages, each corresponding to its respective percentage.

[0088] The AF216 can provide multiple sets of RT latency, UL maximum delay, and / or DL ​​maximum delay. The PCF212 can select the combination of RT latency, UL maximum delay, and / or DL ​​maximum delay to apply. The PCF212's decision on which combination of RT latency, UL maximum delay, and / or DL ​​maximum delay to apply can be based, for example, on a measurement report received by the PCF212. The measurement report may relate to the measured delays on the associated uplink path and / or downlink path.

[0089] In addition to providing RT latency requirements, or as an alternative, providing UL maximum delay and / or DL ​​maximum delay may be advantageous, for example, when UL flows and / or DL ​​flows carry PDU sets. UL maximum delay and / or DL ​​maximum delay can be used by PCF212 to limit increases in the UL delay budget and / or DL ​​delay budget, for example. The network can limit how RT latency is divided between uplink and downlink flows.

[0090] AF216 can, for example, provide a set of QoS parameters for a separate configuration for a certain (e.g., specific) modality. AF216 can identify separate modalities (e.g., identified by their traffic descriptors) using, for example, a multimodal service ID. For example, with respect to a video modality, the AS can anticipate a specific value for the frame rate and / or provide QoS parameters for each frame rate value. AF216 can provide RT latency requirements for, for example, one or more configurations. The set of requirements and QoS parameters can be indexed by a specific integer value. For example, by indexing the set of requirements and QoS parameters by a specific integer value, the 5GS and the AS can communicate more easily. For example, the AS and the 5GS can communicate regarding determining (e.g., selecting) a configuration for an XRM traffic modality (e.g., separate indices for separate frame rates). The configuration of a modality may change, for example, due to a request from the AF and / or due to changes in network conditions. 5GS can, for example, use an index of configurations (e.g., new configurations) (e.g., configurations in use) to determine (e.g., relevant) RT latency requirements. For example, if AF216 provides RT latency requirements, AF216 can provide multimodal service IDs. Multimodal service IDs can be identifiers that associate multimodal flows belonging to the same multimodal service. For example, if AF216 provides RT latency requirements, AF216 can provide packet detection rule identifiers. Packet detection rule identifiers can be used by the network to detect which traffic matches a rule.

[0091] In 220, the network, for example, NEF214, can authorize a request from AF216. In 222, the network (e.g., NEF214) can send a policy authorization request to, for example, PCF212. The network (e.g., NEF214) can send information provided by AF216 (for example, in 218) to PCF212. This information may include one or more of the following: RT latency requirements, traffic flow descriptors, WTRU addresses, and / or multimodal service IDs. NEF214 can send a list of (e.g., alternative) RT latency requirements as an alternative or additional option. NEF214 can send information to PCF212 by calling the Npcf_PolicyAuthorization create and / or update service operation of PCF212.

[0092] In 224, the NW, for example, PCF212, can approve the request. In 224, PCF212 can generate one or more policies (e.g., PCC rules) for, for example, multimodal services. For example, with respect to RT latency requirements, PCF212 can generate two PCC rules. One PCC rule may relate to an uplink flow, and / or another PCC rule may relate to a downlink flow. An uplink flow can be associated with a downlink flow. For example, an uplink flow can be associated with a PDB, and / or a downlink flow can be associated with a PSDB.

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

[0094] PCF212 can generate QoS monitoring rules for UL data traffic and / or DL ​​PDU set traffic, for example, to track RT latency. PCF212 can associate (e.g., two) QoS monitoring rules with each other using a common identifier (e.g., using a multimodal service ID).

[0095] In 226, the network, e.g., PCF212, can send a policy authorization response to, e.g., NEF214. NEF214 can receive the policy authorization response, e.g., via the Npcf_PolicyAuthorization creation response message from PCF212. The network (e.g., NEF214) can send (e.g., forward) the response from PCF212 to AF216. In 230, the network, e.g., PCF212, can send PCC rules to, e.g., SMF210. In 232, SMF210 can send N4 rules to UPF208. In 234, the network, e.g., SMF210, can send QoS rules to, e.g., WTRU202. SMF210 can send QoS profiles to RAN204. PCF212 can generate correlated QoS monitoring policies for UL data and / or DL ​​PDU set flows.

[0096] The network can be configured for behavior using QoS monitoring reports regarding RT latency. Figure 3 shows an exemplary procedure for configuring QoS monitoring. The system and procedure can accommodate, for example, a case where a multimodal service is established between AF316 and WTRU302 (e.g., using supplied RT latency requirements). The system and procedure describe aspects of monitoring related to RT latency measurement and / or network and application behavior, for example, as a result of QoS latency monitoring reports.

[0097] In 318, the NW (e.g., AF316) can request a session for a multimodal service, for example, with specific requirements. AF316 can request a session using a procedure such as, for example, as described herein (e.g., as shown in Figure 2). A session (e.g., a request) may involve establishing and / or configuring a policy regarding the XRM service. In 320, one or more of the following can be established: policies, QoS rules, and / or N4 rules regarding XRM traffic and QoS profiles. Additionally, or alternatively, QoS monitoring for delays of UL data and / or DL ​​PDU sets can be established, for example, for tracking RT latency. The WTRU302 and application servers can exchange XRM traffic, for example, through the user plane.

[0098] In 322, the NW, for example UPF308, can perform (e.g., begin performing) QoS monitoring after, for example, a user plane connection has been established and / or after traffic has been exchanged between WTRU302 and AF316. UPF308 can perform QoS monitoring for delay measurements related to RT latency, for example. UPF308 can perform QoS monitoring for delay measurements related to RT latency based on a QoS monitoring policy generated, for example by PCF312. For example, in the uplink direction, UPF308 can monitor the delay of UL data packets between WTRU302 and the N6 termination point. For example, in the downlink direction, UPF308 can monitor the delay of DL PDU sets between the N6 termination and WTRU302 (with the assistance of, for example, NG-RAN304 and / or WTRU302). The (e.g., two) monitoring procedures for the uplink and / or downlink directions can be performed at similar (e.g., the same) times. Performing (for example, two) monitoring procedures at similar times can allow the UPF208 to measure the target round-trip latency. The target round-trip latency may be the sum of the uplink and downlink measurement delays.

[0099] In 324, the network, for example UPF308, can report the results of QoS monitoring (for example, to SMF310). The monitoring results may include one or more of the following: UL packet delay measurement, DL PDU set delay measurement, and / or the sum of both delays (for example, RT latency measurement). In 326, the network, for example SMF310, can send a notification to, for example PCF312. For example, SMF310 can send a notification to PCF312 if the UL packet delay measurement and / or downlink PDU set delay measurement are not within an acceptable range.

[0100] In 328, if the NW (e.g., PCF) detects that, for example, a flow's PDB and / or PSDB is not satisfied and / or that the flow is associated with RT latency requirements, the NW (e.g., PCF) may adjust the policy using (e.g., new) PDB and / or PSDB rules and / or update the rules. For example, if the NW (e.g., PCF312) detects that a flow's PDB and / or PSDB is not satisfied and / or that the flow is associated with RT latency requirements, the PCF may calculate (e.g., new) delay budget values ​​for the uplink and / or downlink directions. The PCF312 may determine (e.g., new) PSDBs for downlink flows and / or (e.g., new) PDBs for uplink flows. For example, if the PCF determines that the UL PDB is not satisfied and / or the DL PSDB is satisfied, the PCF312 may increase the packet delay budget for uplink flows and / or decrease the packet set delay budget for downlink flows. PCF312 may, as an addition or alternative, keep UL PDBs below the UL maximum delay, keep DL PSDBs below the DL maximum delay, and / or keep the sum of UL PDBs and DL PSDBs below the RT latency requirement. PCF312 may use the RT latency requirement (e.g., the RT latency requirement in step 200) to determine, for example, a new delay budget value. PCF312 may generate (e.g., new) PCC rules for the uplink direction and / or downlink direction (e.g., both). PCF312 may configure uplink flows to use (e.g., new) PCC rules, and / or downlink flows to use (e.g., new) PCC rules.

[0101] If the NW (e.g., PCF) detects, for example, that a flow's PDB and / or PSDB are not met and / or that the flow is associated with RT latency requirements, PCF312 may determine that it is not possible to increase the delay allocated to a flow with an unmet PDB or PSDB. Additionally, or alternatively, PCF312 may notify AF316 that it is not possible to meet QoS requirements. For example, PCF312 may determine that increasing the delay (e.g., beyond a certain point) could violate the UL maximum delay and / or DL ​​maximum delay requirements (e.g., the UL maximum delay and / or DL ​​maximum delay requirements of Procedure 200). If PCF312 determines that it is not possible to increase the delay budget allocated to a flow with an unmet PDB and / or PSDB, for example, PCF312 may notify AF316 that it is not possible to meet QoS requirements. AF316 can adjust application layer settings (e.g., codec settings) and / or QoS requirements by, for example, restarting the setup and / or configuration of policies for XRM services (e.g., as described in Procedure 200) (e.g., to provide a new QoS configuration).

[0102] In 330, the network, for example, PCF312, can generate rules (e.g., N4 rules) based on, for example, PCC rules. In 330, PCF312 can send (e.g., forward) updated (e.g., pairs of) PCC rules to, for example, SMF310, as an addition or replacement. SMF310 can send (e.g., forward) the N4 rules to, for example, UPF308. In 332, the network, for example, PCF312, can send (e.g., forward) updated QoS rules (e.g., to WTRU302) and / or updated pairs of QoS profiles (e.g., via AMF306 to, for example, RAN304).

[0103] In 334, the NW, for example PCF312, can send (e.g., provide) notifications regarding information to, for example AF316 (e.g., via NEF314). PCF312 can determine the index of the (e.g., updated) (e.g., newly selected) PSDB value if, for example AF316 has provided (e.g., alternative) PSDB requirements and / or RT latency requirements. PCF312 can send the determined index to, for example AF316. In 336, AF316 can, for example, use the determined index to determine which configuration to use for the modality. In addition or alternatively, in 336, AF316 can adjust the codec configuration, change the configuration, and / or provide (e.g., new) RT requirements. The configuration may include, for example, codec settings for the video modality.

[0104] PCF312 can inform AF316 of a new pair of delay requirements to be selected for UL and / or DL, for example, if PCF312 has not been provided with (e.g., alternative) PSDB values ​​by AF316. The delay requirements for UL and / or DL ​​can be determined and / or selected to (e.g., continue to) satisfy the RT latency requirements provided by AF316. In PCF316, AF316 can use the information of the pair of delay requirements (e.g., internally) to modify one or more application parameters, for example. The DL PSDB and / or UL PDB values ​​sent to AF316 may not be indexed by 5GS if, for example, alternative values ​​have not been provided by AF316 (e.g., in advance). PCF312 can inform AF316 that the RT delay measurement exceeds the requirement if, for example, the RT delay requirement cannot be satisfied. PCF312 can provide AF316 with new RT measurement values, for example. AF316 can provide (e.g., new) RT measurements. Additionally or alternatively, AF316 can provide one or more of the measured DL PDU set delay, UL PDU delay, and / or an indication of whether the uplink delay and / or downlink delay can be met. In AF316, the provided information can be used to evaluate and / or modify the internal configuration of AF316. For example, AF316 can modify its internal configuration based on a new codec. AF316 can provide (e.g., new) RT latency requirements to 5GS / PCF312.

[0105] In 338, the network, for example AF316, can respond to a PCF message. For example, AF316 can respond to a PCF message by changing application-level information. AF316 can change application-level information, including codec settings, according to the DL PSDB index provided by PCF312 (for example in 334). AF316 can then use the new codec settings to exchange XRM traffic with WTRU302 via the user plane. AF316 can confirm the change to PCF312 (for example, via NEF314).

[0106] AF316 can respond to a PCF message by re-evaluating the RT latency requirements provided to 5GS. AF316 can provide PCF312 with (e.g., new) RT latency requirements, for example, via NEF314. PCF312 can derive (e.g., new) PCC rules using the RT latency requirements and / or one or more other parameters. For example, PCF312 can derive new PCC rules using the RT latency requirements and / or one or more other parameters. The (e.g., new) PCC rules may include one or more PCC rules with UL PDBs for XRM services and / or other PCC rules with DL PSDBs.

[0107] AF316 can determine that, given network conditions, an acceptable user experience may not be supported for WTRU302, and / or respond to the PCF message accordingly. For example, AF316 can notify the user of such an event. AF316 can also trigger WTRU302 to terminate user plane interactions, for example, for XRM services.

[0108] The network can be optimized to handle various PDU set sizes. AF316 can call the NEF314 API to provide the 5GC with information regarding the PSDB requirements of an application layer session, for example. An application layer session can be used to send and / or receive PDU sets of various sizes. For example, the NEF314 API can include the Nnef_AFsessionWithQoS_Create and / or Nnef_AFsessionWithQoS_Update service operations. The procedure for calling the NEF314 API can include the same or similar steps as those described herein, for example, as shown in Figure 2. AF316 can use the API to provide the NEF314, for example, PDU set QoS parameters and / or a protocol description of the service data flow. The protocol description can indicate, for example, the protocol and / or payload type used by the service data flow. The PDU set QoS parameters can include PSDB information.

[0109] PSDB information may include rules. Additionally, or alternatively, PSDB information may include thresholds (e.g., size). Size and thresholds may be used interchangeably as herein. Rules may be used by 5GC to associate PDU set sizes with PSDB values. For example, a rule may indicate that any PDU set having a size less than or equal to a first value (e.g., threshold) has a PSDB of a second value. A rule may indicate that any PDU set having a size greater than a first value (e.g., threshold) has a PSDB of a third value. Rules may include any number of mappings of PDU set sizes to PSDBs. PDU set size can be expressed 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 a time value (e.g., a single value). NW may determine the PSDB by multiplying the PDU set size by a 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. Additionally, or alternatively, a rule may specify a first value and / or range of values, for example, with respect to the attributes of a PDU set. Additionally, or alternatively, a rule may indicate that any PDU set having attribute values ​​equal to and / or within the range of the first value has a PSDB of the second value. The 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 regarding decoding, dependence on the payload of other PDU sets regarding 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.). The rule may include any mapping of attributes and / or values ​​to the PSDB.The network can determine the PSDB by obtaining the attribute values ​​(for example, initially) (for example, by analyzing the transport header of the PDU), and / or by looking up the attributes and / or values ​​in the mapping.

[0110] The NEF314 can provide rules to the PCF312. The PCF312 can send the rules to the SMF310, for example, as part of PCC rules. The SMF310 can include information from the rules in an N4 rule, which can be sent by the SMF310 to the UPF308, for example. For example, the SMF310 can send an N4 rule (for example, one). The N4 rule can indicate (for example, to the UPF308) that a set of PDUs matching a first packet detection rule and / or being below a certain size should be allocated to a first QoS flow. Additionally or alternatively, the N4 rule can indicate (for example, to the UPF308) that a set of PDUs matching a first packet detection rule (for example, the same rule) and / or being above the same certain size should be allocated to a second QoS flow. PDU sets, PDUs, and / or packets can include information, for example, in their headers. This information can be used, for example, to identify the traffic to which the packet belongs. For example, if information (e.g., in the header) matches an information element of a rule (e.g., a packet detection rule (PDR)), and / or contains at least some of the same information as that information element, it is possible to determine that the packet matches the PDR. A PDR may contain information elements that can help identify traffic and / or packets belonging to a particular traffic. Size information can be integrated into the packet detection rule.

[0111] The SMF310 can include information from rules in a QoS profile that is sent to the RAN304 by the SMF310. For example, the SMF310 can send a QoS profile to the RAN304 indicating that PDU sets from a first QoS flow that are less than a certain size (e.g., a threshold) should be associated with a first PSDB, and / or PDU sets from the first QoS flow (e.g., the same QoS flow) that are greater than or equal to a certain size (e.g., a threshold) should be associated with a second PSDB. The SMF310 can also send a QoS profile to the RAN304 indicating that PDU sets from a first QoS flow that are associated with a specific PDU set attribute value and / or range should be associated with a first PSDB. As an addition or alternative, a QoS profile may indicate that PDU sets from a first QoS flow (e.g., the same QoS flow) that are associated with other PDU set attribute values ​​and / or ranges should be associated with a second PSDB. For example, to enable this association, UPF308 may set attribute values ​​in the GTP-U header of the GTP-U packet used to forward the PDUs of the PDU set. Examples of Generic Packet Radio Services Tunneling Protocol User Plane (GTP-U) header information elements (IEs) for attribute values ​​may include existing IEs, such as the importance of the PDU set. Examples of GTP-U header IEs for attribute values ​​may include one or more new IEs such as independent PDU sets (e.g., 0 means dependent, 1 means independent), layer ID (e.g., indicating the decoding layer of the PDU payload), and / or base layer (e.g., 1 means the PDU payload holds a base layer for decoding, while 0 means it does not).

[0112] It should be noted that providing rule information to the UPF and RAN may be an alternative option. Additionally, or alternatively, the SMF310 can include information from the rules in QoS rules that are sent by the SMF310 to the WTRU302, for example. For example, the SMF310 can send (e.g., one) QoS rule indicating (e.g., to the WTRU302) that sets of PDUs that match a first packet detection rule and / or filter, and / or are less than a certain size, and / or match a certain attribute value / range, should be allocated to a first QoS flow. Additionally, or alternatively, the QoS rule can indicate that sets of PDUs that match a first packet detection rule and / or filter (e.g., the same filter), and / or are greater than a certain size, and / or match another attribute value / range, should be allocated to a second QoS flow. Size information and / or attribute values ​​can be integrated into the packet detection rules and / or filters.

[0113] While features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as ROM, RAM, registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital multi-purpose disks (DVDs). Software-related processors can be used to implement radio frequency transceivers for use in WTRUs, UEs, terminals, base stations, RNCs, or any host computer.

Claims

1. Network entity, Receiving a message containing round-trip (RT) latency requirements, wherein the RT latency requirements include uplink delay information and downlink delay information. Based on the uplink delay information and the downlink delay information, a first policy billing control (PCC) rule is generated. Sending the first information indicating the first PCC rule to the Session Management Function (SMF), Receiving a notification that one or more of the uplink and downlink delays are associated with the flow, Based on the uplink delay information and the downlink delay information, a second PCC rule is determined. Transmitting the second information indicating the second PCC rule to the SMF, A network entity equipped with a processor configured to perform [a specific task / function].

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

3. The RT latency requirement includes a first RT latency requirement, the uplink delay information includes a first uplink delay information, the downlink delay information includes a first downlink delay information, and the processor is To determine a second RT latency requirement, which includes a second uplink delay information and a second downlink delay information, The third PCC rule is determined based on the second RT latency requirement, Sending the aforementioned third PCC rule to the SMF, A network entity according to claim 1, further configured to perform the following:

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

5. The network entity according to claim 1, wherein the message includes one or more multimodal service identifiers (IDs) or one or more traffic descriptors.

6. The network entity according to 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 delays and downlink delays associated with the flow are not within the range required by the first PCC rule.

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

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

10. A method performed by at least one network entity, Receiving a message containing round-trip (RT) latency requirements, wherein the RT latency requirements include uplink delay information and downlink delay information. Based on the uplink delay information and the downlink delay information, a first policy billing control (PCC) rule is generated. Sending the first information indicating the first PCC rule to the Session Management Function (SMF), Receiving a notification that one or more of the uplink and downlink delays are associated with the flow, Based on the uplink delay information and the downlink delay information, a second PCC rule is determined. Transmitting the second information indicating the second PCC rule to the SMF, A method that includes this.

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

12. The RT latency requirement includes a first RT latency requirement, the uplink delay information includes a first uplink delay information, the downlink delay information includes a first downlink delay information, and the method is To determine a second RT latency requirement, which includes a second uplink delay information and a second downlink delay information, The third PCC rule is determined based on the second RT latency requirement, Sending the aforementioned third PCC rule to the SMF, The method of claim 10, further comprising:

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

14. The method of claim 10, wherein the message includes one or more multimodal service identifiers (IDs) or one or more traffic 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 delays and downlink delays 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 and the downlink delay is further associated with one or more of the first PCC rule and the second PCC rule.

Images