Jitter monitoring in wireless communication networks

Abstract

Systems, methods, and means for jitter monitoring in wireless communication networks are described herein. Network devices associated with a wireless communication network may receive information regarding one or more aspects of jitter monitoring within the wireless communication network. Based on the received information, the network device may determine a jitter monitoring policy and transmit the jitter monitoring policy to another device in the wireless communication network. After transmitting the jitter monitoring policy to another device in the wireless communication network, the network device may receive indications of jitter measurement results from the other device.

Description

[Technical Field]

[0001] This disclosure relates to jitter monitoring in wireless communication networks. [Background technology]

[0002] Cross-reference of related applications This application claims the interests of U.S. Provisional Patent Application No. 63 / 457,684, filed on April 6, 2023, the entirety of which is incorporated herein by reference.

[0003] Mobile communications using wireless communication are constantly evolving. The fifth generation is sometimes called 5G. Previous (legacy) generations of mobile communications could be, for example, the fourth generation (4G) Long Term Evolution (LTE). Wireless communication traffic can be transmitted in one or more protocol data units (PDUs). Depending on the nature of the network carrying the PDUs (for example, from an application server (AS) to a network device), the PDUs may experience different delays, and the difference in delays experienced by the PDUs may be measured by jitter. [Overview of the project]

[0004] Systems, methods, and means relating to jitter monitoring in wireless communication networks are described herein. Network devices associated with a wireless communication network may receive information relating to one or more aspects of jitter monitoring within the wireless communication network. Based on the received information, the network device may determine a jitter monitoring policy and transmit the jitter monitoring policy to another device in the wireless communication network. After transmitting the jitter monitoring policy to the other device in the wireless communication network, the network device may receive an indication of the jitter measurement results from the other device.

[0005] In the example, a network device may receive information about one or more aspects of jitter monitoring within a wireless communication network from a network exposure function (NEF) associated with an application server (AS) or application function (AF). In the example, the network device may transmit indications of jitter measurement results to the NEF.

[0006] In the example, information regarding one or more aspects of jitter monitoring within a wireless communication network may indicate that jitter monitoring should be performed at the protocol data unit (PDU) set level or burst level. In the example, a jitter monitoring policy may be associated with PDU sessions that have extended reality traffic.

[0007] In the example, information regarding one or more aspects of jitter monitoring within a wireless communication network may indicate a jitter measurement period and / or a jitter sampling period. In the example, information regarding one or more aspects of jitter monitoring within a wireless communication network may indicate jitter monitoring trigger conditions. In the example, a network device may be configured to determine and transmit a jitter monitoring policy as a quality of service monitoring rule.

[0008] In the example, information regarding one or more aspects of jitter monitoring within a wireless communication network may be received via a policy authorization request, and the network device may further be configured to send a policy authorization response confirming the use of the information received via the policy authorization request. In the example, the network device may be a policy control function of the wireless communication network, and another device may be a session management function of the wireless communication network. [Brief explanation of the drawing]

[0009] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system shown in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RAN and further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 2] This figure shows an example of configuring discontinuous reception mode (CDRX) based on jitter information. [Figure 3] This diagram illustrates an example of having one more Service Data Flow (SDF) for a QoS flow. [Figure 4] This figure shows an exemplary approach for performing jitter measurement at a certain PDU set level. [Figure 5] This figure shows an example of the steps for configuring jitter monitoring (or jitter measurement) requirements for an XRM service. [Figure 6] This figure illustrates an exemplary procedure for provisioning jitter monitoring, jitter measurement, and / or jitter reporting for a WTRU using a tethered device. [Figure 7] This figure shows an example of a PDU set-level playout delay buffer. [Figure 8] This figure shows an exemplary procedure for monitoring and reducing jitter based on the PDU set playout buffer and / or PDU set importance value. [Figure 9] This diagram illustrates an exemplary procedure for a Wireless Access Network (RAN) to configure CDRX for multiple SDFs on a QoS flow. [Figure 10]FIG. is a diagram illustrating an example of determining downlink (DL) periodicity and / or relative time difference associated with a plurality of SDFs. [Figure 11] FIG. is a diagram illustrating an example of determining a DRX cycle based on a plurality of SDFs having the same periodicity. [Figure 12] FIG. is a diagram illustrating an example of determining a DRX cycle based on a plurality of SDFs having different periodicities.

MODE FOR CARRYING OUT THE INVENTION

[0010] FIG. 1A is a diagram showing an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 can be a multi-connection system that provides content such as voice, data, video, messaging, broadcasting, etc. to a plurality of wireless users. The communication system 100 can enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 can utilize one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DFT-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filterbank multicarrier (FBMC).

[0011] As shown in Figure 1A, the communication system 100 may include transmit / receive 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 intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be called “station” and / or “STA”, may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, contract-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and medical applications (e.g., remote surgery), industrial devices and industrial applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain settings), consumer electronics, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRU102a, 102b, 102c, and 102d may be interchangeably referred to as UE.

[0012] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may 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 such as CN 106 / 115, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be a base transceiver base 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 each illustrated as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0013] 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 wireless signals on one or more carrier frequencies, which may be called cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells may provide coverage for wireless 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 cells. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of a cell. In one embodiment, the base station 114a may utilize multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

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

[0016] In one embodiment, base stations 114a and WTRUs 102a, 102b, 102c may 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).

[0017] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as NR radio access, which can establish an air interface 116 using New Radio (NR).

[0018] In one embodiment, base station 114a and WTRU 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRU 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRU 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNB and gNB).

[0019] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may 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, CDMA 2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0020] The base station 114b in Figure 1A may be a wireless router, Home Node B, Home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in localized areas such as businesses, homes, vehicles, campuses, industrial facilities, aerial walkways (e.g., for use by drones), and roads. In one embodiment, the base station 114b and WTRU 102c, 102d may implement radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and WTRU 102c, 102d may implement radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and WTRU 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106 / 115.

[0021] RAN104 / 113 may communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more WTRU102a, 102b, 102c, and 102d. The data may have variable Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, and / or implement high-level security features such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs that utilize the same or different RAT as RAN104 / 113. For example, in addition to being connected to RAN104 / 113, which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) that utilizes GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0022] CN106 / 115 may also serve as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing basic telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as the Transmit Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs that may utilize the same RAT as RAN104 / 113 or a different RAT.

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

[0024] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the elements described above, while remaining consistent with the embodiment.

[0025] The processor 118 may 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 application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may 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 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Figure 1B illustrates the processor 118 and transceiver 120 as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0026] The transmit / receive element 122 may 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 transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0028] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmit / receive element 122 and to demodulate the signal to be received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

[0030] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components of the WTRU 102. The power supply 134 can 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.

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

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

[0033] WTRU102 may include a full-duplex radio where the transmission and reception of some or all of the signal (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing or substantially eliminating self-interference, either through hardware (e.g., chokes) or through signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of the signal (e.g., associated with specific subframes for either UL (e.g., for transmission) or downlink (e.g., for reception)).

[0034] Figure 1C is a system diagram showing RN104 and CN106 according to one embodiment. As described above, RAN104 may utilize E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0035] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while remaining consistent with the embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may use multiple antennas, for example, to transmit a wireless signal to and / or receive a wireless signal from WTRU102a.

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

[0037] 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 above elements is illustrated 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.

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

[0039] 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 perform other functions such as anchoring the user plane during handovers between eNode B, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0040] SGW164 may be connected to PGW166, which may 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.

[0041] CN106 may facilitate communication with other networks. For example, CN106 may 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 fixed telephone communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) acting as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0042] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in some representative embodiments, it is intended that such a terminal may have a wired communication interface with a communication network (for example, temporarily or permanently).

[0043] In a typical embodiment, the other network 112 may be a WLAN.

[0044] In Infrastructure Basic Service Set (BSS) mode, a WLAN may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces to a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic originating outside the BSS and destined for an STA may arrive via the APs and be delivered to the STAs. Traffic originating from an STA to a destination outside the BSS may be transmitted to the APs so that it is delivered to its respective destination. Traffic between STAs within a BSS may be transmitted via the APs; for example, a source STA may transmit traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS is considered and / or may be referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (e.g., directly between them) using a Direct Link Setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with one another. The IBSS communication mode is sometimes referred to herein as the “ad-hoc” communication mode.

[0045] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may also be the operating channel of the BSS and may be used by an STA to establish a connection with the AP. In some typical embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. In CSMA / CA, an STA, including the AP (e.g., any STA), may sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be busy, that particular STA may make concessions. A single STA (e.g., just one station) may transmit at any given time within a given BSS.

[0046] A high-throughput (HT) STA may use a 40MHz wide channel for communication, for example, through a combination of a primary 20MHz channel with adjacent or non-adjacent 20MHz channels, in order to form a 40MHz wide channel.

[0047] Ultra-high throughput (VHT) STAs may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels may be formed by combining consecutive 20 MHz channels. 160 MHz channels may be formed by combining eight consecutive 20 MHz channels or two non-consecutive 80 MHz channels, sometimes referred to as an 80+80 configuration. In an 80+80 configuration, data may, after channel coding, pass through a segment parser that can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to a medium access control (MAC).

[0048] Sub-1GHz operating modes are 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 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to one typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including support for some and / or limited bandwidths (e.g., support only for that). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0049] WLAN systems that can support multiple channels, as well as channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by one of the STAs among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the 802.11ah example, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the primary channel may be 1MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1MHz mode. Carrier detection and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the main channel is busy because an STA (which only supports 1MHz operation mode) is transmitting to the AP, then the majority of the frequency band remains idle, and even if it could be available, the entire available frequency band can be considered busy.

[0050] In the United States, the available frequency band that can be used by 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 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.

[0051] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 may utilize NR radio technology to communicate with WTRU102a, 102b, and 102c via air interface 116. RAN113 may also communicate with CN115.

[0052] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while remaining consistent with a particular embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a may use multiple antennas, for example, to transmit wireless signals to and / or receive wireless signals from WTRU102a. In a particular embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may 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 one embodiment, gNB180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0053] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the spacing of OFDM symbols and / or OFDM subcarriers may differ for different transmissions, different cells, and / or different parts of the wireless transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., storing a variable number of OFDM symbols and / or lasting for a variable absolute length).

[0054] 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 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 gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in the unlicensed band. In a non-standalone configuration, WTRU102a, 102b, and 102c may communicate with and connect to other RANs such as eNode-B160a, 160b, and 160c while simultaneously communicating with and connecting to gNB180a, 180b, and 180c. For example, WTRU102a, 102b, and 102c may 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 a non-standalone configuration, eNode-B160a, 160b, and 160c may serve as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c may provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0055] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interaction between NR and E-UTRA, routing of user plane data toward User Plane Functions (UPF) 184a and 184b, and routing of control plane information toward 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.

[0056] 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 possibly a Data Network (DN)185a, 185b. While each of the above elements is illustrated 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.

[0057] AMF182a and 182b may be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and may act as control nodes. For example, AMF182a and 182b may be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, and mobility management. Network slicing may 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, different network slices may be established for different use cases, such as services relying on ultra-high reliability low latency (URLLC) access, enhanced massive mobile broadband (eMBB) access, and services for machine-type communications (MTC) access. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) that utilize other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0058] 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 allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

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

[0060] CN115 can facilitate communication with other networks. For example, CN115 may 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 may provide WTRU102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to the local data network (DN) 185a, 185b via the N3 interface to UPF184a, 184b and via the N6 interface between UPF184a, 184b and DN185a, 185b.

[0061] In view of Figures 1A to 1D and the corresponding descriptions of Figures 1A to 1D, one or more or all of the WTRU102a to d, base stations 114a to b, eNode-B 160a 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 may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

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

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

[0064] Systems, methods, and means relating to jitter monitoring are described herein. These systems, methods, and means may be associated with extended and / or multimodal reality (XRM) services. The term “jitter monitoring” may be used interchangeably with “jitter measurement” herein.

[0065] Network devices or nodes, such as Policy Control Functions (PCFs), may be configured with (e.g., additional) information relating to jitter monitoring or jitter measurement (e.g., by WTRUs and / or User Plane Functions (UPFs)) at, for example, the Protocol Data Unit (PDU) set level or burst level. Where used herein, a burst may refer to a set of PDUs or one or more sets of PDUs generated and transmitted within a period of time (e.g., by an application). The (e.g., additional) information configured for a network device may include, among other parameters, information on whether jitter monitoring should be performed at the PDU level, the PDU set level, or the burst level; information on whether jitter monitoring is related to (e.g., each) media modality (e.g., video, audio, haptics, etc.); and / or one or more indications of what method should be used to calculate jitter or what type of jitter should be measured. A PCF may generate jitter monitoring policies (e.g., one or more Policy Charge and Control (PCC) rules that include jitter monitoring information) based on the received information. The PCF may provide (e.g., forward) jitter monitoring policies (e.g., one or more PCC rules) to one or more other network devices such as a Session Management Function (SMF), UPF, and / or WTRU. Following the provision of jitter monitoring policies, the PCF may receive jitter measurement results. The PCF may notify application servers (AS) or application functions (AF) about jitter-related events (e.g., jitter monitoring results), for example, via a network exposure function (NEF) that exposes the PCF and / or other network devices to the AS / AF.

[0066] The WTRU and / or UPF may use a PDU set-level playout or dejittering buffer, for example, to minimize jittering. The WTRU and / or UPF may receive configuration information about one or more characteristics of the buffer (e.g., buffer size). The WTRU and / or UPF may receive jitter monitoring parameters via one or more QoS rules (e.g., for the WTRU) and / or one or more N4 rules (e.g., for the UPF). The WTRU and / or UPF may perform jitter measurements. The WTRU and / or UPF may report the results of the measurements to the SMF and / or PCF. The PCF may transmit the jitter measurement results (e.g., via the aN NEF) to the AF / AS. The AF / AS may provide information to help correct the PDU set-level dejitter buffer in the WTRU and / or UPF.

[0067] Systems, methods, and means relating to jitter monitoring for extended and / or multimodal reality (XRM) services are described herein. Systems, methods, and means relating to provisioning jitter monitoring policies and / or requirements (e.g., at the PDU set level) in wireless communication networks (e.g., fifth-generation systems (5GS)) are described herein.

[0068] A network device (e.g., a device with or configured to implement a policy control function (PCF)) may be configured to perform one or more of the following actions: The network device (e.g., a PCF) may receive messages containing jitter monitoring information. The messages may include an indication of whether jitter monitoring is enabled (e.g., required) and / or whether jitter monitoring should be performed at the PDU level, the PDU set level, or the burst level (e.g., for a certain media modality). The messages may include an indication of what methods may be used to calculate jitter and / or what types of jitter may be measured. An application function (AF) may anticipate different codec settings that a certain modality (e.g., a video modality) may take (e.g., for several modalities such as a video modality) for, for example, extended and / or multimodal reality (XRM) services. The AF may provide (e.g., provide to the network device) different jitter monitoring parameters for different combinations of video resolution and / or frame rate. AF may provide trigger conditions for jitter monitoring (for example, for several modalities). AF may provide delay budget, PDU set delay budget, and / or delay budget monitoring for a given modality. AF may provide delay difference thresholds between different modalities of an XRM service. AF may provide jitter monitoring parameters for burst level monitoring.

[0069] Network devices such as PCFs may use information provided by AF / AS (e.g., via NEF) to determine or generate one or more jitter monitoring policies for multimodal services (e.g., Extended Reality (XR) services). One or more policies may be determined or generated as part of quality of service (QoS) monitoring rules (e.g., in the form of one or more policy billing and control (PCC) rules). Network devices may send policies and / or rules to one or more other network devices, including, for example, devices that have or are configured to implement session management functions (SMFs).

[0070] A network device (e.g., PCF) may receive notifications (e.g., from SMF) regarding jitter measurement results, such as whether the measured amount of jitter exceeds a certain threshold. The network device may send indications of the jitter measurement results (e.g., notifications regarding jitter measurement results) to the AF, for example, via NEF.

[0071] A device (for example, a WTRU and / or network device / node configured as a UPF) may perform one or more of the following actions: The device may receive jitter monitoring information contained in one or more QoS rules provided by the PCF (for example, via the SMF). The device may perform a jitter measurement according to the received jitter monitoring information (for example, which may include one or more jitter measurement parameters). The device may send the jitter measurement results to the SMF, which may forward the results to the PCF.

[0072] A device as described herein may include a processor configured to perform one or more actions configured for the device. For example, a device as described herein (e.g., an NEF) may include a processor configured to receive requests and / or jitter monitoring information from a requesting entity (e.g., an AS / AF) for a multimodal session with a WTRU. The device may send a policy authorization request to another device (e.g., a PCF) for the multimodal session and / or jitter monitoring associated with the multimodal session. The device may receive a policy authorization response (e.g., from the PCF), which may confirm authorization of the policy authorization request. The device may send a message to the requesting entity (e.g., an AS / AF) to confirm the multimodal session. The device may receive at least one jitter measurement result or notification regarding the jitter measurement result (e.g., from the PCF), and may send a jitter measurement result or notification regarding the jitter measurement result to the requesting entity.

[0073] The jitter monitoring information described herein may indicate whether jitter monitoring should be performed, the type or method of jitter calculation, and an index of a set of jitter monitoring parameters. The set of jitter monitoring parameters may comprise each jitter monitoring parameter associated with a condition. Messages confirming a multimodal session may indicate confirmation of information and / or parameters indicated by the requesting entity when requesting a multimodal session and providing jitter monitoring information. The requesting entity may be an application function.

[0074] Traffic within a flow can be periodic. For example, a downlink flow from a server (e.g., an application server) to a WTRU may carry PDUs, which may be sent in a periodic pattern (e.g., by the server to the WTRU). This periodic pattern could be, for example, one PDU sent at regular intervals.

[0075] The delay experienced by each PDU can vary, for example, depending on the nature of the network carrying the downlink data (e.g., from the AS to the UPF or WTRU). Jitter can be a measure of how much the delay experienced by each PDU varies. Jitter can also be a measure of how much the time used to transmit each PDU varies (e.g., measured by the UPF).

[0076] An application server associated with a wireless communication network or system may provide the expected periodicity of traffic flow to a network device (e.g., a PCF). The network device (e.g., a PCF) may provide the expected periodicity of traffic flow to another network device, such as an SMF. The SMF may provide information to yet another network device, such as a UPF.

[0077] The UPF may report jitter measurements to the SMF. The SMF may provide jitter measurements to RAN nodes such as base stations. The RAN nodes may use this information to adjust the Connectivity Mode Discrete Receive (CDRX) settings of the WTRU.

[0078] The UPF may report jitter measurements to the application server. The jitter measurement report may be sent directly to the application server, or indirectly, for example, via SMF, PCF, and / or NEF. The application server may use the jitter measurement information to configure one or more jitter buffers in the server application and / or WTRU application.

[0079] PDU Set Integrated Handling Information (PSIHI) may indicate whether one or more (e.g., all) PDUs in a PDU set should be transmitted / received before the PDU set becomes available for use by the application layer (e.g., the receiver side). PSIHI may be provided to network devices (e.g., PCFs) by the application server. PSIHI (e.g., if enabled) may be applied to (e.g., all) traffic in the PDU set within a QoS flow.

[0080] A dejitter buffer can remove the effects of jitter from a received stream by buffering each incoming packet for a short interval before playing it out synchronously (for example, it can be configured to do so). A fixed dejitter buffer can maintain a constant size. An adaptive dejitter buffer can adjust its size to optimize the delay / drop trade-off (for example, it may have the ability to adjust dynamically).

[0081] The dejitter buffer size (JBS) can be defined as the maximum length of time a packet can remain in the buffer. The dejitter buffer delay (JBD) can also be called the dejitter delay, hold time, or playout delay. The JBD may be smaller than the dejitter buffer size and can represent the time a packet remains in the buffer. The departure time of each packet can be determined, for example, by reading timestamp information provided by the Real-Time Transport Protocol (RTP).

[0082] Jitter can be used for CDRX configuration. A network device (e.g., UPF) may be configured with session reporting rules to assist a RAN node (e.g., base station) in establishing CDRX configuration parameters for a WTRU. The session reporting rule may be, for example, a "Per QoS Flow N6 Jitter Measurement Report". This rule may include N6 jitter measurement control information indicating that a network device (e.g., UPF) should report N6 jitter information associated with downlink (DL) periodicity for QoS flows in the downlink direction (e.g., to assist a RAN node in configuring CDRX for a WTRU). The N6 jitter measurement report may be generated by a network device (e.g., UPF) and sent to another network device (e.g., SMF). This report may show the N6 jitter measurement results for the periodicity of the QoS flow.

[0083] In establishing a PDU session with QoS (for example, by AS / AF), the network (e.g., a 5G system) may provide periodicity information. This periodicity information may be provided by the AF to a first network device (e.g., a PCF) via the NEF, or directly to the first network device if the AF is trusted. The first network device (e.g., a PCF) may transmit the periodicity information received from the AF to a second network device (e.g., a SMF). The first network device may include an indication to the second network device (e.g., within one or more PCC rules) to require a third network device (e.g., a UPF) to perform jitter measurements, for example, in accordance with the operator's local policy.

[0084] A second network device (e.g., SMF) may determine time-dependent communication assistance information (TSCAI) (e.g., upon receiving a PCC rule) and forward the TSCAI to a RAN node (e.g., a base station). The second network device (e.g., SMF) may send an indication of DL periodicity (e.g., the period between two data bursts) to a third network device (e.g., UPF) if, for example, the PCC rule includes an indication for performing jitter measurements. The second network device may request the third network device to monitor and / or periodically report jitter information associated with DL periodicity, for example, using an N4 session correction procedure. The second network device may provide DL periodicity in its request to the third network device. How the third network device derives N6 jitter may depend on the implementation. How the third network device derives DL periodicity when not provided by AF may also depend on the implementation.

[0085] A second network device (e.g., SMF) may receive jitter measurement results from a third network device (e.g., UPF), for example, in an N4 session-level report. The second network device may include the jitter measurement information in the TSCAI, for example, along with the associated periodicity, and the second network device may forward the TSCAI to the RAN node (e.g., via an NG Application Protocol (NGAP) message). The third network device may periodically send an N6 jitter measurement report, or when the measured jitter is greater than a threshold (e.g., only when it is greater than a threshold). This can prevent frequent updates from the third network device.

[0086] Figure 2 shows an example of jitter measurement / reporting and CDRX configuration determination based on jitter information.

[0087] As shown in Figure 2, in 1, a first network device (e.g., PCF) may transmit DL periodicity information (e.g., which may be received from AF / AS) and / or indications for performing jitter measurements to a second network device (e.g., SMF), and the second network may forward the received information to a third network device (e.g., UPF) configured to perform jitter measurements. In some examples, the second network device (e.g., SMF) may not receive DL periodicity information and may request the third network device (e.g., UPF) to determine the DL periodicity.

[0088] In step 2, a third network device (e.g., UPF) may, after receiving control information related to jitter measurement (e.g., N6 jitter measurement control information), perform one or more jitter measurements based on the control information. For example, the third network device may measure and / or report N6 jitter information associated with DL periodicity for QoS flow in the downlink direction based on the received control information, which may include jitter monitoring indications and / or rules described herein. As part of this process, the third network device may map service data flows (SDFs) to QoS flows.

[0089] In step 3, the third network device (e.g., UPF) may provide jitter measurement information (e.g., jitter measurement results) to the second network device (e.g., SMF).

[0090] In step 4, the second network device (e.g., SMF) may provide jitter information to RAN nodes such as base stations.

[0091] In step 5, the RAN node may use the received jitter information to configure the CDRX for the WTRU.

[0092] The example shown and described in relation to Figure 2 may assume that a second network device (e.g., an SMF) may provide DL periodicity information for each traffic flow (e.g., each SDF), or that a second network device (e.g., an SMF) may request a third network device (e.g., a UPF) to measure DL periodicity for each traffic flow (or each SDF). The example shown and described in relation to Figure 2 may also assume that one traffic flow (e.g., or an SDF) may be mapped to a QoS flow, and / or that jitter may be measured for each QoS flow.

[0093] Wireless communication networks (e.g., 5G systems (5GS)) may perform jitter measurements for XRM traffic. QoS flows associated with one or more PDU sets may be associated with a PDU set delay budget (PSDB). Jitter between PDU sets may be measured and reported, for example, when PDU set-based handling is enabled in the communication system. AF / AS may configure or request jitter monitoring at the PDU set level and / or burst level, for example, to facilitate integrated handling of PDU sets (hereafter, PDU set integrated handling). This is because, when PDU set integrated handling is enabled, the application layer may utilize PDUs only when (for example, only when) the entire PDU set is received. In these situations, jitter between PDUs may be less significant than jitter between PDU sets.

[0094] In some cases, a WTRU can facilitate communication between a device tethered to (e.g., attached to or associated with) the WTRU and an application server (AS). As described herein, an AS (or AF) may configure or require a network (e.g., a wireless communications network) to measure and report jitter between the AS and the tethered device.

[0095] Wireless communication networks (e.g., 5GS) can leverage PDU set handling to help reduce jitter at the application layer so that jitter does not negatively impact the user experience. In some examples, payload playout buffers may be deployed for RTP streams. Some traffic characteristics or specific sets of traffic may have different jitter requirements. For example, one application may prefer that inter-I frame jitter (e.g., for video content) be reduced with higher priority than inter-P frame jitter. PDU set handling can be used to minimize jitter by implementing PDU set-level buffering, for example, by considering XRM traffic information such as PDU set importance values.

[0096] In a wireless communication network (e.g., 5GS), if, for example, one or more traffic flows (e.g., one or more SDFs) are associated with the same QoS flow, RAN nodes such as base stations may help configure CDRX parameters.

[0097] Figure 3 shows an exemplary scenario where there is one or more SDFs per QoS flow. As shown in Figure 3, DL periodicity can be a property of DL traffic arriving at a network device (e.g., UPF) through the SDF and / or SDF. The network device may receive information that can help it calculate DL periodicity, for example, if the network device is asked to derive periodicity (e.g., when DL periodicity is not provided by the AF).

[0098] As shown in Figure 3, jitter can be measured for each QoS flow. A QoS flow may have multiple SDFs (Single-Distributed Fields) multiplexed together, and these SDFs may have different periodicities. DL transmissions associated with an SDF may not be time-synchronized, even if the SDFs have the same periodicity. The network may provide support for calculating jitter for each QoS flow.

[0099] Embodiments of the present disclosure contemplate that jitter monitoring can be performed at the PDU set level and / or at the burst level. The jitter between two packets can indicate (e.g., be defined as) the difference (e.g., absolute value) in transfer delay of two packets that can belong to the same stream (e.g., can be received consecutively).

[0100] Considering two consecutive PDU sets, the first received PDU of each PDU set may be denoted as PDU1 and PDU respectively, and the last received PDU of each PDU set may be denoted as PDU N and PDU N’ respectively. Denoting the transmission time and reception time of PDU1 as t T1 and t R1 respectively, the transmission time and reception time of PDU 1’ as t T1’ and t R1’ respectively, the transmission time and reception time of PDU N as t TN and t RN respectively, and the transmission time and reception time of PDU N’ as t TN’ and t RN1’ respectively, the jitter J1 between the first received PDUs of each of the two PDU sets can be calculated according to Equation (1). J1 = |(t R1 - t T1 ) - (t R1’ - t T1’ )| (1)

[0101] The jitter J2 between the last received PDUs of each of the two PDU sets can be calculated according to Equation (2). J2 = |(t RN - t TN ) - (t RN’ - t TN’ )| (2)

[0102] In some cases, the PDU set jitter may be determined or measured as the average of jitter J1 and jitter J2 according to, for example, equation (3), which may be referred to as the first approach in this specification. PDU_Set_Jitter=(J1+J2) / 2 (3)

[0103] In some examples, PDU set jitter may be determined or measured as the jitter for the first received PDU in each of two PDU sets, for example, PDU_Set_Jitter=J1, which may be referred to as the second approach herein.

[0104] In some examples, PDU set jitter may be determined or measured as the jitter for the last received PDU in each of two PDU sets, e.g., PDU_Set_Jitter=J2, which may be referred to as the third approach herein.

[0105] The PDU set delay (PSD) can represent (for example, be defined as) the delay a PDU set may experience in its movement between the WTRU and the N6 termination point (for example, in the UPF). For example, the PSD can be calculated as the time between the reception of the first PDU and the reception of the last PDU in a PDU set. Using this definition, the PDU set delays for PDU set 1 and PDU set 2 can be determined according to equation (4) (for example, using the previous notation). PSD1=|t RN -t T1 |and PSD2=|t RN’ -t T1’ (4)

[0106] The jitter for two PDU sets may also be measured, for example, based on the difference between PSD measurements, according to equation (5), which is sometimes referred to as the fourth approach in this specification. PS_Jitter=|PSD1-PSD2| (5)

[0107] The exemplary approaches described herein may differ and may convey different information about delay differences across PDU sets. One or more (e.g., all) of the approaches may be important to the application functionality. For example, a jitter measurement using equation (3) may show how much the average per-PDU jitter changes during the transmission of a PDU set. A jitter measurement using equation (5) may show how much the PDU set delay varies from one PDU set to the next, which may be useful, for example, for setting PSDB values ​​for QoS flows that transmit PDU sets.

[0108] Figure 4 shows an exemplary approach for performing jitter measurement at a given PDU set level. A similar approach can be used to calculate and measure jitter at a burst level, for example, by considering the first and last successfully delivered PDUs of each of two bursts to calculate the jitter (for example, using one of the formulas or approaches described herein). Jitter measurement and calculation may use, for example, the first PDU and / or PDU set of the burst, as well as the last PDU and / or PDU set of the burst.

[0109] PDU set jitter monitoring requirements may be provisioned in a wireless communication network (e.g., 5GS). In some examples, an Application Function (AF) may require establishing a multimodal XRM session with a WTRU over the wireless communication network (e.g., 5GS). The AF may provide requirements and / or configuration information regarding jitter monitoring. Figure 5 shows an example of how the wireless communication network (e.g., 5GS) may be configured with information to provide multimodal services between the AF and the WTRU.

[0110] In Figure 5-1, the AF (or AS) may request to set up a multimodal session with a WTRU over a wireless communication network (e.g., 5GS) by, for example, calling the NEF Application Programming Interface (API). As an example, the API may be modeled after the Nnef_AFsessionnWithQoS service operation. The AF may provide service information (e.g., in the request) such as flow description information, WTRU address, and / or combination of data network name (DNN) and single network slice selection assistance information (S-NSSAI). The AF may provide service requirements for the multimodal service, including QoS monitoring requirements and / or QoS parameters, such as packet delay budget for each media modality.

[0111] AF can provide jitter monitoring information (e.g., jitter monitoring parameters) for multimodal services (for example, this could be an XRM service). Jitter monitoring information / parameters for an XRM service may include, for example, an indication of whether jitter monitoring is required, an indication of whether jitter monitoring should be performed at the PDU level, PDU set level, or burst level (for a given media modality), a jitter monitoring period or frequency (for example, for downlink traffic and / or modality), an indication of what method should be used to calculate jitter and / or what type of jitter should be measured, codec settings associated with the video modality of the XRM service, events / conditions that may trigger the wireless communications network to perform some action (for example, reporting jitter measurements and / or jitter monitoring events to the AF), uplink jitter monitoring models and / or parameters, round-trip (RT) related jitter monitoring parameters, conditions for triggering jitter monitoring for any modality, PSIHI enablement and / or indications, jitter monitoring parameters for burst-level monitoring, and multimodal service IDs.

[0112] AF may provide an indication of whether jitter monitoring is required, and, if required, whether jitter monitoring should be performed at the PDU level, the PDU set level, or the burst level for a given modality. AF may provide jitter monitoring duration and / or jitter monitoring frequency (e.g., for downlink traffic and / or each modality). AF may provide PDU set jitter monitoring requirements (e.g., frequency, duration, etc., for each modality) if PDU set handling is enabled for XRM services.

[0113] The AF may provide indications of which method should be used to calculate jitter and / or which type of jitter should be measured. For example, if the AF is aware of the methods it can use to calculate jitter (e.g., PDU set jitter) or has a prior agreement with the wireless communication network about it, it may indicate to the wireless communication network which method it would like them to use.

[0114] AF may provide different codec settings (for example, for several modalities such as video modalities) that a video modality may adopt for XRM services. For example, AF may provide different jitter monitoring parameters for different video resolution, frame rate combinations, etc. AF may pre-provide parameters so that wireless communications can modify or read the jitter monitoring parameters accordingly when the wireless communications network is aware that a codec setting has changed or is about to change. The set of parameters may be indexed so that the wireless communications network knows which jitter monitoring parameters to use when the index of the codec setting being used changes.

[0115] The AF may identify events that can trigger the wireless communication network to take some action, including, for example, reporting jitter measurements and / or jitter monitoring events to the AF. For example, the AF may provide a threshold for PDU set jitter so that if a PDU set jitter measurement exceeds the threshold, the wireless communication network may report an event to the AF (for example, the report may include additional jitter measurement results). For example, the AF may provide different thresholds and / or ranges for jitter values ​​(for example, for each modality), and the wireless communication network may report to the AF which range the jitter belongs to (for example, or take some action if possible).

[0116] The AF may provide uplink jitter monitoring modes and / or parameters (e.g., measurement period, reporting frequency, and / or event notification configuration), similar to downlink jitter monitoring modes. The AF may provide round-trip (RT) related jitter monitoring parameters. In some scenarios, the AF may be interested in round-trip jitter measurement information instead of, for example, DL or UL jitter measurement information.

[0117] AF may specify conditions that may trigger jitter monitoring for one or more modalities. For example, AF may provide delay budget (e.g., PDU set delay budget) and / or delay budget monitoring for a certain (e.g., each) modality. AF may provide delay difference thresholds between different modalities of an XRM service. AF may consider a delay difference threshold to be irrelevant for measuring jitter if, for example, a delay measurement exceeds a certain (e.g., some) value. AF may tell a wireless communication network to stop monitoring jitter for a modality if, for example, a delay difference measurement between two modalities exceeds a certain (e.g., some) threshold (e.g., because synchronization between modalities is not maintained by the amount of the threshold). For example, if another monitoring is not satisfied, the related monitoring versus separate monitoring may be irrelevant or unnecessary.

[0118] The AF may provide an indication of whether PDU set integrated handling is enabled and / or a PSIHI indication. When PDU set integrated handling is enabled, some or all of the PDUs in the PDU set may be required for the PDU set to be useful at the application layer. For example, if all the PDUs in the PDU set are required for the PDU set to be useful, the PDU set may be discarded if one of its PDUs is lost. In some cases, the absence of an indication of enabling PDU set integrated handling may mean that it is possible to lose one or more (e.g., several) PDUs (e.g., not more than a certain percentage of PDUs) from the PDU set without considering the PDU set to be insignificant and therefore discardable (e.g., the PDU set may be retained in this situation). In some cases (e.g., depending on whether an indication of enabling PDU set integrated handling exists), the AF may (e.g., implicitly) instruct the wireless communication network to perform jitter monitoring differently (e.g., for each modality). Indications for enabling PDU set integrated handling may affect which PDU sets can be considered for a given PDU set jitter measurement, and / or how jitter can be measured (for example, for a partially restored PDU set or a fully received PDU set). AF may provide one or more parameters indicating the method or approach to use for jitter monitoring (for example, for each modality), and / or which type of PDU set should be used.

[0119] The AF may provide jitter monitoring parameters for burst-level jitter monitoring. The AF may also provide traffic description information for bursts, which may be in the form of IP 3-tuples. For example, if more than one modality is carried in a QoS flow, the AF may provide the same or different burst-level jitter measurements for each modality. In this case, the AF may provide different monitoring parameters for the traffic descriptor of each XRM modality. The AF may specify whether it requests jitter measurements within a burst (e.g., within the burst itself) and / or between bursts (e.g., between consecutive bursts). The AF may provide a measurement period, which may be the length of time during which jitter measurements may be performed. The AF may also provide a sampling period, which may represent how often a wireless communications network (e.g., 5GS) may ingest sample PDU / PDU sets and use those samples in calculating burst-level jitter. For example, AF might indicate that within a 20ms measurement period, the wireless communication network should sample a PDU / PDU set every 4ms and use that sample (including, for example, transmit and receive times) for jitter measurement.

[0120] The AF may provide the number of PDU sets to be used for burst-level jitter measurement over a certain period (e.g., some period). For example, the AF may request the use of five PDU sets every 30ms to measure jitter. The AF may specify (e.g., where possible) which PDU sets should be used for the measurement. For example, the AF may indicate that it wants the first and last PDU sets to be included in the burst to be used to calculate the jitter for a wireless communications network. The AF may use traffic characteristics as parameters. For example (for example, for a certain video modality), the AF may request the use of 75% I-frames and 25% non-I-frames in the calculation of burst jitter, and / or the AF may provide a pattern of frames to be used to calculate the burst-level jitter (e.g., use pattern IPPPI to calculate jitter).

[0121] The AF may provide a multimodal service ID, which may be an identifier that associates multimodal flows belonging to the same multimodal service. In Figure 5, 1, the AF may send a multimodal session setup request and / or jitter monitoring information (e.g., jitter monitoring parameters) to the NEF.

[0122] In Figure 5-2, the NEF may authorize the request from the AF.

[0123] In Figure 5, 3a, the NEF may send a policy authorization request to another network device such as the PCF. The NEF may send the information provided to the NEF in 1 to the PCF (for example, in a policy authorization request or in a separate message). This information may include, for example, a traffic flow descriptor, a WTRU address, and / or a multimodal service ID. This information may include a PDU set and / or other jitter monitoring parameters.

[0124] In Figure 5, 3b, the PCF may authorize a request from the NEF. Based on this request, the PCF may generate a jitter monitoring policy for a critical multimodal XRM service. This policy may be part of a QoS monitoring rule (for example, this may be included in one or more PCC rules) if other parameters, such as PDU set delay, are required to be monitored by the AF for the XRM service. The PCF may associate multiple (for example, two) QoS monitoring rules with a common identifier.

[0125] In Figure 5-4, the PCF may send a policy authorization response message to the NEF, for example, to confirm the authorization of a service request.

[0126] In Figure 5, in step 5, the NEF may send a message to the AF to confirm the provisioning of the XRM service using the parameters and information provided by the AF in step 1.

[0127] In Figures 5, 6a and 6b, the PCF may transmit information regarding jitter monitoring (e.g., a jitter monitoring policy determined by the PCF) to another network device such as an SMF, which may then forward the jitter monitoring policy to yet another network device such as a UPF. This information provided in 6a and 6b (e.g., the policy) may include or reflect the information provided in 1, and the UPF may use this information (e.g., the measurement period and / or sampling period) to set up a jitter measurement procedure (e.g., with corresponding periods and appropriate timers). For example, the UPF may use this information to determine the granularity of the jitter monitoring / measurement to be performed (e.g., for each modality), such as whether the jitter monitoring / measurement should be performed per PDU, per set of PDUs, or per burst, whether the jitter monitoring / measurement is for uplinks and / or downlinks, and / or what method should be used for the jitter monitoring / measurement.

[0128] UPF can use this information to set up triggers and conditions for sending notifications to SMF about jitter measurements (e.g., measurement reports). For example, these triggers and conditions may include reporting frequency. As another example, these triggers and conditions may include thresholds for sending notifications to SMF (for example, a notification may be sent if the measured jitter exceeds a threshold).

[0129] As described herein, the handling of PDU sets may be enabled in a wireless communications network (e.g., 5GS) for PDU sessions carrying XRM traffic. Jitter monitoring per PDU set or at the burst level may be required, and the UPF may use PDU sequence numbers, PDU set sequence numbers, and / or burst termination indicators to determine which PDU or PDU set should be used for jitter measurement. Some of this information may be available to the UPF in the PDU header of the PDU set (e.g., the GTP-U header).

[0130] UPF may use PDU set importance information (if available) to determine whether any PDU set should be considered for jitter calculation. UPF may use PDU set importance values ​​to distinguish between I-frames and P-frames (for video modalities) if a pattern for jitter measurement (e.g., for burst-level jitter monitoring) is provided and / or a percentage of I-frames that should be used for jitter measurement (e.g., for burst-level jitter monitoring) is provided.

[0131] In Figure 56c, a jitter monitoring policy (including, for example, jitter monitoring parameters) as described herein may be sent to the WTRU. The jitter monitoring policy may be sent to the WTRU by, for example, the SMF, which may send rules regarding jitter monitoring to the WTRU as part of the QoS rules. Alternatively, the jitter monitoring policy may be provided to the WTRU by the PCF (for example, via the WTRU configuration update procedure).

[0132] In Figure 5, 7, the WTRU and / or UPF may perform jitter measurements (for example, for DL ​​and / or UL traffic) using one or more of the jitter calculation techniques described herein.

[0133] In Figures 5, 8a and 8b, the UPF and / or WTRU may transmit indications of the jitter measurement results to a network device such as an SMF.

[0134] In Figure 5, 9, the PCF may send notifications to the AF (e.g., via the NEF) regarding jitter measurement or jitter management results. The AF (or AS) may utilize the jitter management results. For example, the AF may adjust the jitter buffer parameters at the application level. For instance, the AF may decide to reduce the jitter buffer size for certain modalities, such as those with relatively low jitter. The AF may decide to increase the PDU set delay budget (PSDB) for a modality if it receives an indication that the PDU set level jitter for that modality has exceeded a provided threshold. Increasing the PSDB for a modality may allow the application server to account for jitter larger than the threshold fluctuation, which can help with PDU set-based QoS handling in the RAN.

[0135] AF may use the jitter between WTRU and UPF, along with the N6 jitter (e.g., between AS and UPF) that AF may already know, to evaluate the overall jitter. AF may decide to adjust its buffer based on the evaluation of the overall jitter.

[0136] Based on the jitter measurement results, the AF may decide to change the frame rate for the video modality. For example, if the AS determines that the PDU set-level jitter is high (e.g., exceeding a threshold) for video delivered at 120fps, the AS may switch to a 90fps configuration so that the jitter is reduced and has less impact on the video modality.

[0137] PDU set-related jitter monitoring requirements may be provided for devices tethered (e.g., attached) to the WTRU. In one example, a WTRU exchanging traffic with an AF / AS for an XRM service may be tethered to other devices (e.g., AR glasses and / or haptic gloves) and may receive XRM traffic associated with those devices. In this scenario, the AF and wireless communications network may configure jitter measurement / reporting between the WTRU and network devices (e.g., UPF) for the tethered links to each modality.

[0138] Figure 6 shows an example of the procedure for provisioning jitter monitoring, jitter measurement, and / or reporting for WTRU using a tethered device.

[0139] As shown in Figure 6, in 1, with tethering enabled, the AF may request to set up a multimodal session with the WTRU (e.g., for XMR services) over the wireless communication network (e.g., 5GS). The AF may do this, for example, by calling the NEF API. The AF may provide jitter monitoring parameters for the tethered link. The AF may provide end-to-end jitter monitoring requirements. Based on the information provided by the AF, the wireless communication network may derive one or more jitter monitoring rules or requirements for one or more communication links or legs, including, for example, the UPF-to-WTRU leg and / or the tethered leg. The jitter monitoring requirements may include requirements for the tethered device. Based on these requirements, the WTRU may monitor the tethering transmission delay between the WTRU and the tethered device. The WTRU may report the monitored tethering transmission delay to the AF.

[0140] In the example shown in Figure 6, the PCF may authorize a jitter monitoring request (e.g., from the AF) and generate one or more jitter monitoring policies for a multimodal session (e.g., for an XRM service). The jitter monitoring policy may include WTRU-to-UPF jitter monitoring parameters and / or tethering jitter monitoring parameters. The PCF may send the policy to the SMF, which may forward the policy to the UPF and WTRU.

[0141] In Figure 6-2, the WTRU can configure jitter monitoring using a tethered device.

[0142] In Figure 6-3, the WTRU can perform jitter measurements for the tethered link.

[0143] In Figure 64a, the WTRU may transmit jitter measurement results to the SMF. In the example, the measurement results transmitted to the SMF may not indicate a request for a delay budget and may indicate a measured or estimated transmission delay between the WTRU and the tethered device. Such an estimate may be based on a preconfiguration. For example, the WTRU may be configured to report the transmission delay to a device connected to the WTRU via Bluetooth. The WTRU may be configured to calculate the delay based on a formula. Inputs to the formula may be, for example, the RAT type used to connect to the WTRU and the distance between the WTRU and the tethered device. In the measurement results transmitted to the SMF, the WTRU may include an IP 4 tuple to which the measurement results may be associated.

[0144] In Figure 64b, the SMF may report the tethering measurement results to the PCF based on the measurement results provided by the WTRU.

[0145] In Figure 6-5, the PCF may use information reported by the SMF to create or modify PCC rules. For example, the PCF may learn from the reported information that a large amount of jitter may originate from a tethered link, and the PCF may send a notification to the AF (for example, regarding changes to PCC rules and / or QoS parameters) so that one or more application layer configurations may be adjusted (for example, by the AF) to reduce the jitter (for example, the PCF may not be able to resolve the jitter problem on its own).

[0146] In Figure 6, 6, the PCF may send jitter measurement results and / or notifications regarding the jitter measurement results to the AF (e.g., via the NEF). For example, if the PCF knows that a large amount of jitter is originating from the tethered link, the PCF may indicate to the AF that the jitter may not improve any further.

[0147] PDU set-level payload playout buffers can be implemented in WTRUs and / or UPFs. PDU set-level payload delay buffers can be implemented in WTRUs and / or UPFs. These buffers can be configured, used, and / or managed at the PDU set level (for example, considering PDU set information when storing and / or releasing data to reduce jitter associated with PDU sets). Figure 7 shows an example of a PDU set-level playout delay buffer. This buffer may be similar to a payload playout buffer used at the application layer to reduce jitter associated with a stream of data (e.g., comprising RTP packets). This buffer can be used to reduce jitter in wireless communication networks. WTRUs can be configured with PDU set handling capabilities to reduce jitter associated with downlink traffic at the PDU set level. Network devices such as UPFs can be configured with PDU set handling capabilities to reduce jitter associated with uplink traffic at the PDU set level. These capabilities can utilize PDU set-level playout buffers or PDU set-level playout delay buffers for PDU sets. This buffer may be used to handle packets at the PDU set level. This buffer may be characterized by its jitter buffer size and / or buffer delay. These parameters may differ and may vary for various scenarios and implementations.

[0148] The handling of PDU sets using a playout buffer may depend on the type of PDU set, the modality associated with the PDU size, the size of the PDU set, and / or the importance of each PDU set. For example, a PDU set with a certain importance value (e.g., I-frames) may be preferred over a PDU set with a different importance value.

[0149] Jitter monitoring and reduction (for example, for XRM services) can be performed based on the importance of the PDU set. Figure 8 shows an example of a procedure for monitoring and minimizing jitter based on the PDU set playout buffer and / or PDU set importance.

[0150] As shown in Figure 8, in 1, the procedure shown in Figure 5 (e.g., steps 1 to 6c) relating to provisioning jitter monitoring information to a wireless communication network (e.g., 5GS) and / or WTRU may be performed. In addition to the jitter monitoring-related parameters described in relation to the procedure shown in Figure 5, the AF may provide additional and / or alternative parameters. For example, the AF may provide periodicity information to the wireless communication network to facilitate the configuration of jitter measurements per PDU set importance value. The AF may provide different jitter monitoring parameters depending on the PDU set importance value. The AF may provide importance levels (e.g., threshold importance levels) for PDU sets on which jitter measurements should be performed. For example, for a certain video modality, the AF may be interested in knowing the jitter with respect to I-frames, so the AF may provide importance levels or indications to show that jitter should be measured for PDU sets associated with I-frames. The AF may provide multiple PDU set importance values ​​on which jitter monitoring should be performed (e.g., I-frames vs. B-frames for a certain video modality). AF may provide information to help configure PDU set playout delay buffer parameters, such as buffer size and / or buffer delay size.

[0151] In Figure 8-2a, user-plane XRM DL traffic can be transmitted from the AF to the WTRU.

[0152] In Figure 8, 2b, PDU set traffic arriving at the WTRU may pass through a PDU set level playout delay buffer to reduce jitter (for example, before the traffic is sent to the application layer).

[0153] In Figure 8, 3a, the WTRU can exchange UL traffic with network devices such as UPF.

[0154] In Figure 8, 3b, UL PDU set traffic arriving at the UPF may be routed through a PDU set playout buffer to reduce jitter.

[0155] In Figure 8, 3c, the UPF can forward UL traffic to the AF.

[0156] In Figure 8-4, the WTRU and / or UPF may perform jitter measurements using, for example, one or more of the jitter determination techniques described herein.

[0157] In Figure 8-5, the wireless communication network (e.g., WTRU, UPF, and PCF) may transmit jitter measurement results and / or corresponding event notifications to the AF (e.g., via the NEF).

[0158] In Figure 8-6, the AF may decide to modify PDU set playout delay buffer parameters, such as buffer size and / or buffer delay size, in accordance with the received jitter measurement results and / or notifications.

[0159] In Figure 8-7, AF may provide changes to the wireless communication network, for example, using the procedure shown in Figure 5.

[0160] A CDRX can be configured for QoS flows that may be associated with multiple SDFs. A WTRU may be interested in receiving multiple traffic flows (e.g., multiple SDFs), such as XR traffic flows. Each traffic flow may be associated with a set of QoS requirements and / or QoS characteristics. Traffic for a traffic flow may be split into sets of PDUs. Mapping traffic flows (e.g., XR traffic flows) to QoS flows may be based on the QoS parameters of the XR flows. A QoS flow may represent the finest granularity of QoS distinctions in a PDU session. A QoS flow may be expected to multiplex traffic (e.g., only traffic) with similar QoS requirements and / or characteristics. An AF may provide PDU set-related support information for dynamic PCC control. Figure 9 shows an exemplary procedure (for a RAN node, such as a base station) for configuring a CDRX for a WTRU interested in receiving multiple traffic flows (e.g., multiple SDFs), such as multiple XR traffic flows associated with QoS flows.

[0161] As shown in Figure 9, in case 0, AF may provide DL periodicity for a subset of SDFs (e.g., SDF_set1). As a result, DL periodicity may be known for SDF_set1 but not for other SDFs (e.g., SDF_set2). One or more of the following PDU set-related supporting information may be provided to the NEF and / or PCF using an AF session with PDU set QoS parameters and / or protocol descriptions that may indicate some QoS procedure: the protocol and / or payload type used by the SDF.

[0162] PDU set QoS parameters and / or protocol descriptions (e.g., provided by AF) may be used by PCF to determine the QoS profile and / or by PDU session anchor (PSA) UPF to identify PDU set information. PDU set information may include, for example, one or more of the following: PDU set sequence number, indication of the ending PDU of the PDU set, PDU sequence numbers within the PDU set, and / or PDU set importance values ​​that may indicate the relative importance of the PDU set when compared to other PDU sets in the QoS flow.

[0163] In Figure 9-1, the PCF may provide the UPF with one or more policy rules, for example, via the SMF. The policy rules may include PDU set QoS parameters, protocol descriptions, and / or N6 jitter measurement control information, the N6 jitter measurement control information may instruct the UPF to report N6 jitter information associated with the DL periodicity of a certain (e.g., one) QoS flow in the downlink direction. Additional information that may be provided to the UPF may include, for example, a list of SDFs for which DL periodicity is provided (e.g., SDF_set1), a list of SDFs for which the UPF can determine DL periodicity (e.g., SDF_set2), a list of SDFs for which the UPF can determine jitter (e.g., SDF_set3), an indication of which SDFs may be primary SDFs, reporting periodicity, reporting thresholds, and / or jitter calculation configurations.

[0164] The PCF may provide a list of SDFs for which DL periodicity is provided (e.g., SDF_set1). For example, DL periodicity may be provided for each SDF in SDF_set1. The PCF may provide a list of SDFs for which UPF can determine DL periodicity (e.g., SDF_set2). For example, for each SDF in SDF_set2, an indication may be provided as to whether UPF should report the determined DL periodicity to SMF. The PCF may provide a list of SDFs for which UPF can determine jitter (e.g., SDF_set3). For example, for each SDF in SDF_set3, an indication may be provided as to whether UPF should report the determined jitter to SMF. The PCF may provide an indication as to which SDF may be the primary SDF. Relative time differences (e.g., delta) calculated for a wireless communication network (e.g., a 5G system) may relate to the primary SDF.

[0165] The PCF may provide reporting periodicity, for example, the time between N6 jitter measurement reports from the UPF to the SMF. This periodicity may be common to multiple (e.g., all) SDFs, or to a group of SDFs. For example, (e.g., all) SDFs with the same DL periodicity may be configured using the same reporting periodicity. The UPF may be configured using multiple thresholds. For example, the periodicity may relate to changes in jitter measurements, changes in the measured DL periodicity, or changes in the relative time difference (e.g., delta) between an SDF and a primary SDF.

[0166] A PCF may provide one or more reporting thresholds. For example, an N6 jitter measurement report to an SMF may be sent when the measured jitter exceeds a configured threshold. The configured threshold may be common to multiple (e.g., all) SDFs, or to a group of one or more SDFs. For example, (e.g., all) SDFs with the same DL periodicity may be configured using the same threshold. A UPF may be configured using multiple thresholds. For example, the thresholds may relate to changes in jitter measurements, changes in measured DL periodicity, or changes in relative time difference (delta) between an SDF and a primary SDF.

[0167] The PCF may provide a jitter calculation configuration, which may include configuration information regarding which measure should be measured. For example, the measure could be the mean, variance, standard deviation, median, or K-percentile. The jitter calculation configuration may indicate an observation time frame, e.g., the time over which the measure is obtained. The jitter calculation configuration may also indicate an observation sample size, e.g., the minimum number of jitter measurements that may be performed to determine the measure.

[0168] In Figure 9-2, the UPF can determine the periodicity of the SDFs in SDF_set2. The UPF can also measure the jitter for the SDFs in SDF_set3. The UPF can perform measurements according to a jitter calculation configuration. The UPF may rely on PDU set QoS parameters and / or protocol descriptions to identify the SDFs and / or PDU sets within the SDFs. The UPF can determine the relative time difference (e.g., delta) between incoming DL traffic on a certain (e.g., each) SDF and incoming DL traffic on the main SDF.

[0169] Figure 10 shows an example of determining the periodicity and / or relative time difference of a first SDF (e.g., SDF1, which may be the primary SDF), a second SDF (e.g., SDF2), and the DL periodicity and / or relative time difference associated with the SDFs. The SDFs may have different periodicities. This periodicity may be known to the UPF and may be based, for example, on the composition from the SMFs and / or on internal measurements. As shown in Figure 10, in some cases, a set of PDUs on one (e.g., each) SDF may arrive earlier than expected, while in other cases, a set of PDUs on an SDF may arrive later than expected. The UPF may also find a relative time difference between SDF2 and SDF1 (e.g., the primary SDF), which may suggest that the set of PDUs on SDF2 arrives delta milliseconds later than the set of PDUs on SDF1. Based, for example, on knowledge of the periodicity of the two SDFs and a calculated delta, the UPF may know when a set of PDUs is expected.

[0170] Returning to Figure 9, in 3, the UPF may provide the SMF with jitter measurement reports, such as N6 jitter measurement reports. The jitter measurement reports provided by the UPF may include, for example, measured jitter information for each SDF, the relative time difference (delta) between an SDF and a primary SDF, an indication of which SDF the UPF may use as the primary SDF, an indication of the QoS flow to which these SDFs may be linked, which may be provided if the UPF has multiple QoS flows carrying XRM traffic flows, the relative time difference between the QoS flows, which may be provided if the UPF has multiple QoS flows carrying XRM traffic flows, the respective DL periodicity for each SDF flow, which may apply if the UPF is required to determine periodicity, and / or an indication of the cause for sending the measurement report (e.g., periodic reporting of delta values ​​between SDF2 and SDF1, jitter change of SDF1 exceeding a threshold, etc.). The UPF may provide the measurement report based, for example, on a configured reporting frequency and / or reporting threshold.

[0171] In Figure 9-4, the SMF may transmit DL periodicity information, jitter information, and / or delta information to a RAN node such as a base station. The SMF may transmit this information, for example, whenever it receives a measurement report from the UPF. The SMF may (for example, alternatively) be configured with its own periodicity and / or thresholds to transmit DL periodicity information, jitter information, and / or delta information to the RAN. Such an SMF configuration is not shown in Figure 9.

[0172] The SMF may transmit information to the RAN node as part of TSCAI or as part of signaling exchange between the SMF and the RAN node. For example, the information provided to the RAN node by the SMF may include one or more of the following: an SDF identifier to identify the SDF, a QoS flow identifier to identify the QoS flow to which the SDF is associated, a primary SDF used for calculating the relative time difference, the relative time difference between SDFs and primary SDFs (e.g., delta), the measured jitter per SDF flow, and / or the DL periodicity per SDF flow.

[0173] In Figure 9-5, the RAN node may use jitter information and / or DL ​​periodicity to configure CDRX for the WTRU. For example, the RAN node may use this information to determine the approximate arrival time of DL traffic on (e.g., all) QoS flows to the WTRU. The RAN node may send CDRX configuration information to the WTRU via an RRCReconfiguration message.

[0174] Figure 11 shows an example where a WTRU has a QoS flow with two SDFs having the same DL periodicity, and a RAN node determines DRX cycles with the same periodicity. As shown in Figure 11, the RAN node may also determine the expected arrival times of PDU sets at the RAN node, which may be from SDF1 (PDU set 1) and / or SDF2 (PDU set 2). The RAN node may make decisions based, for example, on DL periodicity information, jitter information, and / or delta information from the SDFs. The RAN node may also determine how long the WTRU should be awake (e.g., X seconds every T seconds). The RAN node may configure the DRX cycles and / or DRX on / off time lengths according to the ratio of X to T, and the WTRU accordingly.

[0175] Figure 12 shows an example where a WTRU has a QoS flow with two SDFs having different DL periodics, and a RAN node determines DRX cycles with different periodics. The RAN node may determine the expected arrival times of PDU sets at the RAN node, which may be from SDF1 (PDU set 1) and SDF2 (PDU set 2). The RAN node may make decisions based, for example, on DL periodicity information, jitter information, and / or delta information from the SDFs. Depending on the expected arrival times of the PDU sets for each SDF, the RAN node may or may not be able to determine efficient X and T to consider the SDFs. The RAN node may determine X and T for each SDF (e.g., X1 and T1 for SDF1, and X2 and T2 for SDF2) (for example, in this case). The RAN node may construct a WTRU using two DRX cycles (e.g., a first DRX cycle for SDF1 and a second DRX cycle for SDF2). WTRU may enter a power-saving state when both DRX cycles are off (for example, only at that time).

[0176] The exemplary procedures described herein may assume that a primary SDF is defined for each QoS flow. In some (e.g., alternative) implementations, a single SDF may be used as the primary SDF for multiple (e.g., all) QoS flows. In those implementations, the UPF may report the relative time differences of the SDFs in the (e.g., all) QoS flows relative to this primary SDF. Furthermore, in those implementations, signaling may be performed to indicate the QoS flow to which the primary SDF is associated. Such signaling may be performed, for example, when signaling the primary SDF (e.g., from the UPF to the SMF, or from the SMF to a RAN node).

[0177] While the features and elements described above are described in specific combinations, each feature or element can be used alone without other features and elements in a preferred embodiment, or in various combinations with or without other features and elements. The implementations described herein may consider 3GPP-specific protocols, but it should be understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, the strategies described herein consider protocols specific to LTE, LTE-A, New Radio (NR), or 5G, but it should be understood that the strategies described herein are not limited to this scenario and may be applicable to other wireless systems.

[0178] The processes described above may be implemented in computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM discs and / or digital multipurpose discs (DVDs). Software-related processors may be used to implement radio frequency transceivers for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A network device associated with a wireless communication network, Receiving information regarding one or more aspects of jitter monitoring within the wireless communication network, Based on the information received, a jitter monitoring policy is determined. The jitter monitoring policy is transmitted to another device in the wireless communication network. After transmitting the jitter monitoring policy to the other device in the wireless communication network, the jitter measurement result indication is received from the other device. A network device equipped with a processor configured in such a way.

2. The network device according to claim 1, wherein the processor is configured to receive the information relating to one or more aspects of the jitter monitoring in the wireless communication network from an application server (AS) or a network exposure function (NEF) associated with an application function (AF).

3. The network device according to claim 2, wherein the processor is configured to transmit the indication of the jitter measurement result to the NEF.

4. The network device according to claim 1, wherein the information relating to one or more aspects of the jitter monitoring within the wireless communication network indicates that the jitter monitoring should be performed at the protocol data unit (PDU) set level or burst level.

5. The network device according to claim 4, wherein the jitter monitoring policy is associated with a PDU session having extended reality traffic.

6. The network device according to claim 1, wherein the information relating to one or more aspects of jitter monitoring in the wireless communication network indicates a jitter measurement period or a jitter sampling period.

7. The network device according to claim 1, wherein the information relating to one or more aspects of the jitter monitoring within the wireless communication network indicates jitter monitoring trigger conditions.

8. The network device according to claim 1, wherein the processor is configured to determine and transmit the jitter monitoring policy as a quality of service monitoring rule.

9. The network device according to claim 1, wherein the information is received via a policy authorization request, and the processor is further configured to send a policy authorization response confirming the use of the information received via the policy authorization request.

10. The network device according to claim 1, wherein the network device is a policy control function for the wireless communication network, and the other device is a session management function for the wireless communication network.

11. A method performed by a network device associated with a wireless communication network, Receiving information regarding one or more aspects of jitter monitoring within the wireless communication network, Based on the information received, a jitter monitoring policy is determined, The jitter monitoring policy is transmitted to another device in the wireless communication network. After transmitting the jitter monitoring policy to the other device in the wireless communication network, the jitter measurement result indication is received from the other device. Methods that include...

12. The method according to claim 11, wherein the information relating to one or more aspects of the jitter monitoring within the wireless communication network is received from an application server (AS) or a network exposure function (NEF) associated with an application function (AF).

13. The method according to claim 12, further comprising transmitting the indication of the jitter measurement result to the NEF.

14. The method according to claim 11, wherein the information relating to one or more aspects of the jitter monitoring within the wireless communication network indicates that the jitter monitoring should be performed at the protocol data unit (PDU) set level or burst level.

15. The method according to claim 14, wherein the jitter monitoring policy is associated with a PDU session having extended reality traffic.

16. The method according to claim 11, wherein the information relating to one or more aspects of jitter monitoring in the wireless communication network indicates a jitter measurement period or a jitter sampling period.

17. The method according to claim 11, wherein the information relating to one or more aspects of the jitter monitoring in the wireless communication network indicates jitter monitoring trigger conditions.

18. The method according to claim 11, wherein the jitter monitoring policy is determined and transmitted as a quality of service monitoring rule.

19. The method according to claim 11, wherein the information relating to one or more aspects of the jitter monitoring in the wireless communication network is received via a policy authorization request, and the method further comprises sending a policy authorization response confirming the use of the information received via the policy authorization request.

20. The method according to claim 11, wherein the network device is a policy control function for the wireless communication network, and the other device is a session management function for the wireless communication network.

Images