Delivery time windows for low latency communications

Abstract

In general, the described techniques provide a device for determining or receiving signaling including a packet delivery time window configuration, which indicates a delivery window in which a transmission may be held and / or a delivery opportunity in which a communication is expected to be transmitted. For example, the device may identify a packet delivery time window configuration for communication with another device. The packet delivery window configuration may indicate the periodicity, offset, start time, end time, and / or duration of the delivery window, as well as other information. Based on the identified packet delivery time window configuration, the device may delay transmission of the data packet (e.g., for the duration of one or more configured delivery windows). For example, at the end of the corresponding delivery window, the device may deliver the data packet to a network device for which the information of the data packet is to be used.

Description

[0001] Cross-references

[0002] This patent application claims priority to U.S. Patent Application No. 16 / 582,671, entitled “DELIVERY TIME WINDOWS FOR LOW LATENCY COMMUNICATIONS,” filed by PRAKASH et al. on September 25, 2019; and U.S. Provisional Patent Application No. 62 / 739,096, entitled “DELIVERY TIME WINDOWS FOR LOW LATENCY COMMUNICATIONS,” filed by PRAKASH et al. on September 28, 2018; and each of which is assigned to the assignee of this application.

[0003] background

[0004] The following relates generally to wireless communications and, more particularly, to delivery time windows for low latency communications.

[0005] Wireless communication systems are widely deployed to provide various types of communication content, such as voice, video, packet data, messaging, broadcasting, etc. These systems may be able to support communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Examples of such multiple access systems include fourth generation (4G) systems (such as long term evolution (LTE) systems, advanced LTE (LTE-A) systems, or LTE-A Pro systems), and fifth generation (5G) systems, which may be referred to as new radio (NR) systems. These systems may use various technologies, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), or discrete Fourier transform spread orthogonal frequency division multiplexing (DFT-S-OFDM). A wireless multiple access communication system may include several base stations or network access nodes, each of which simultaneously supports the communication of multiple communication devices, which may be referred to as user equipment (UE).

[0006] A wireless multiple access communication system may include several base stations or network access nodes (or both), each of which simultaneously supports communication for multiple devices, which may be otherwise referred to as UEs. In some cases, various applications (e.g., motion control, discrete manufacturing) may utilize relatively stringent reliability, latency, and jitter requirements. Thus, it is desirable to have an improved apparatus that supports delivery time windows for low latency communications.

[0007] Overview

[0008] The described techniques relate to improved methods, systems, devices, and apparatuses that support delivery time windows for low latency communications. In general, the described techniques provide a device (e.g., such as a user equipment (UE), a base station, one or more adapter functions, and / or any other wireless communication device) for determining or receiving signaling including a packet delivery time window configuration, which packet delivery time window configuration may indicate a delivery window in which a transmission may be performed and / or a delivery opportunity in which a communication is expected to be transmitted. For example, the device may identify a packet delivery time window configuration for communication with another device (e.g., for communication between a UE and a base station or an adapter function). The packet delivery window configuration may indicate the periodicity, offset, start time, end time, and / or duration (e.g., length) of the delivery window, as well as other information.

[0009] Based on the identified packet delivery time window configuration, the device may delay transmission of the data packet (e.g., for the duration of one or more configured delivery windows). For example, when the device receives a data packet within the duration of one of the delivery windows, the device may delay the data packet for at least a portion of the duration of the corresponding delivery window (if not until the end of the duration of the corresponding delivery window), etc. For example, at the end of the corresponding delivery window, the device may deliver the data packet to a network device that is to use information of the data packet (e.g., the UE may deliver a retained data packet containing application data from a model of the UE to a corresponding application of the UE).

[0010] A wireless communication method is described. The method may include: identifying a packet delivery time window configuration for communications of a traffic type; receiving a data packet of the traffic type prior to a delivery opportunity based on the packet delivery time window configuration; delaying transmission of the data packet based on the packet delivery time window configuration and receiving the data packet prior to the delivery opportunity; and transmitting the data packet to a network device after delaying transmission and based on the delivery opportunity.

[0011] An apparatus for wireless communication is described. The apparatus may include a processor, a memory in electronic communication with the processor, and instructions stored in the memory. The instructions are executable by the processor to cause the apparatus to: identify a packet delivery time window configuration for communications of a traffic type; receive a data packet of the traffic type before a delivery opportunity based on the packet delivery time window configuration; delay transmission of the data packet based on the packet delivery time window configuration and receipt of the data packet before the delivery opportunity; and transmit the data packet to a network device after delaying transmission and based on the delivery opportunity.

[0012] Another apparatus for wireless communication is described. The apparatus may include means for: identifying a packet delivery time window configuration for communications of a traffic type; receiving a data packet of the traffic type prior to a delivery opportunity based on the packet delivery time window configuration; delaying transmission of the data packet based on the packet delivery time window configuration and receiving the data packet prior to the delivery opportunity; and transmitting the data packet to a network device after delaying transmission and based on the delivery opportunity.

[0013] A non-transitory computer-readable medium storing code for wireless communication is described. The code may include instructions executable by a processor for the following operations: identifying a packet delivery time window configuration for communication of a traffic type; receiving a data packet of the traffic type before a delivery opportunity based on the packet delivery time window configuration; delaying transmission of the data packet based on the packet delivery time window configuration and receiving the data packet before the delivery opportunity; and transmitting the data packet to a network device after delaying transmission and based on the delivery opportunity.

[0014] Some examples of the methods, apparatus (devices) and non-transitory computer-readable media described herein may further include operations, features, apparatuses or instructions for the following actions: determining a delivery time window based on the packet delivery time window configuration, wherein transmitting the data packet may be based on the delivery time window.

[0015] Some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for the following actions: determining a time interval associated with the delivery opportunity based on the end time of the delivery time window, wherein transmitting the data packet includes. In some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein, receiving the data packet may include operations, features, means, or instructions for the following actions: receiving the data packet within the delivery time window. In some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein, the packet delivery time window configuration indicates: the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, or the duration of the delivery time window, or any combination thereof.

[0016] Some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for the following actions: receiving an indication of the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, or the duration of the delivery time window, or any combination thereof, from a radio access node, wherein determining the delivery time window may be based on receiving the indication. In some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein, receiving the indication may include operations, features, means, or instructions for the following actions: receiving the indication via a radio protocol message.

[0017] In some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein, transmitting the data packet may include operations, features, means, or instructions for the following actions: transmitting the data packet within the time interval of the delivery opportunity. In some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein, transmitting the data packet may include operations, features, means, or instructions for the following actions: transmitting the data packet within a delivery window in a delivery window set associated with the communication of the traffic type.

[0018] In some examples of methods, apparatuses (devices), and non-transitory computer-readable media described herein, transmitting the data packet may include operations, features, means, or instructions for the following actions: transmitting the data packet during the end portion of the delivery window based on the packet delivery time window configuration. In some examples of methods, apparatuses (devices), and non-transitory computer-readable media described herein, transmitting the data packet may include operations, features, means, or instructions for the following actions: transmitting the data packet before or after the delivery opportunity.

[0019] Some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein may further include operations, features, devices, or instructions for the following actions: determining a delay budget associated with the communication of the traffic type; and determining the delivery opportunity based on the delay budget, wherein transmitting the data packet may be based on determining the delivery opportunity. Some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein may further include operations, features, devices, or instructions for the following actions: determining a delivery time window for the communication of the traffic type based on the delay budget, wherein transmitting the data packet may be based on the delivery time window. In some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein, delaying the transmission of the data packet may include operations, features, devices, or instructions for the following actions: buffering the data packet before transmission based on receiving the data packet before the delivery opportunity.

[0020] Some examples of the methods, apparatus (devices), and non-transitory computer-readable media described herein may further include operations, features, apparatuses, or instructions for: identifying a packet arrival window associated with the network device; and determining the delivery opportunity based on the end duration of the packet arrival window, wherein transmitting the data packet may be based on determining the delivery opportunity.

[0021] Some examples of the methods, apparatus (devices) and non-transitory computer-readable media described herein may further include operations, features, apparatuses or instructions for the following actions: receiving a packet arrival time window configuration indicating at least one of a user plane function (UPF) packet arrival time window configuration, a radio access network (RAN) data packet arrival time window configuration, or a UE packet arrival time window configuration, wherein determining the delivery opportunity may be based on receiving the packet arrival time window configuration.

[0022] Some examples of the methods, apparatuses (devices), and non-transitory computer-readable media described herein may further include operations, features, apparatuses, or instructions for the following actions: determining the delivery opportunity based on a packet arrival time associated with the network device and a delay budget for communications of the traffic type, wherein transmitting the data packet may be based on determining the delivery opportunity. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1

[0013] An example of a system for wireless communications that supports delivery time windows for low-latency communications in accordance with aspects of the present disclosure is illustrated.

[0025] Figure 2 An example of a transmission timeline supporting a delivery time window for low-latency communications in accordance with aspects of the present disclosure is illustrated.

[0026] Figure 3 An example of a transmission timeline supporting a delivery time window for low-latency communications in accordance with aspects of the present disclosure is illustrated.

[0027] Figure 4 An example of a process flow that supports delivery time windows for low-latency communications in accordance with aspects of the present disclosure is illustrated.

[0028] Figure 5 An example of a process flow that supports delivery time windows for low-latency communications in accordance with aspects of the present disclosure is illustrated.

[0029] Figure 6 and 7 A block diagram of a device supporting delivery time windows for low-latency communications in accordance with aspects of the present disclosure is shown.

[0030] Figure 8 A block diagram of a communications manager supporting delivery time windows for low-latency communications is shown in accordance with aspects of the present disclosure.

[0031] Fig. 9 A diagram of a system including a device supporting delivery time windows for low-latency communications is shown in accordance with aspects of the present disclosure.

[0032] Figures 10 to 12 A flow chart illustrating a method of supporting a delivery time window for low-latency communications in accordance with aspects of the present disclosure is shown.

[0033] Detailed Description

[0034] Some wireless communication systems may be used to facilitate communication in networks that rely on relatively strict timing synchronization of network components, sometimes referred to as time-sensitive networking (TSN) systems. Such systems may be used to support, for example, factory automation. Some TSN systems specify relatively stringent quality of service (QoS) parameters such as latency, jitter, and reliability requirements for data traffic (e.g., latency of less than 1 ms and reliability of 10 ms). -6 In some cases, such data traffic may be supported in a wireless communication system using a high reliability service, such as an Ultra Reliable Low Latency Communication (URLLC) service.

[0035] In a wireless communication system (e.g., carrying TSN communications), the QoS requirements for a specific QoS flow can define one or more target packet delay budgets (PDBs). The target PDB can set a target latency or time delay for communications between a user equipment (UE) and a core network of a wireless communication system, etc., at which the data packets communicated can be used. In the case of downlink transmission, the PDB may include a first delay component incurred between the core network (e.g., from a user plane function (UPF), a session management function (SMF), or other adapter functions) and a radio access node (e.g., at a base station). The PDB may also include a second delay component incurred between the base station and the UE. In general, this total PDB defines the target latency from the UPF via the base station to the UE. In the case of uplink transmission, the PDB may similarly define the target latency from the UE via the base station to the UPF or SMF. If the total delay when conveying a data packet exceeds the total PDB defined by the PDB configuration, the data packet may not be usable and may be ignored.

[0036] However, in some cases, jitter in a wireless communication system may cause changes in the total delay of communications between UEs, base stations and / or UPFs, and other devices in the wireless communication system. In some cases, jitter may cause a receiving device (e.g., a UE or another device within a wireless communication system) to receive a transmission before it is expected to be received. However, a transmission received in advance may be received during a packet delivery window, for which the receiving device delays the data transmission until the end of the packet delivery window. Therefore, transmissions received in advance (e.g., due to jitter) may result in transmission queues. This may reduce the efficiency of conveying these transmissions (e.g., utilization of time and frequency resources).

[0037] Discussed herein is a technique for providing a signaling for determining or receiving a packet delivery time window configuration at a receiving device, which indicates a delivery window in which a transmission may be retained and / or a delivery opportunity in which a communication is expected to be transmitted. For example, a packet delivery time window configuration may provide a configuration of multiple delivery windows, each of which may have a duration from a start time to an end time. In some cases, one or more of the delivery windows may be separated by a delivery window offset. As described herein, a packet received during one of the delivery windows may be retained (e.g., until the end time of the corresponding delivery window), at which point the packet may be transmitted during the delivery opportunity. In some cases, these delivery opportunities may be consistent with the delivery window offset between each of the delivery windows.

[0038] In some cases, a network device (e.g., a UE, a base station, one or more adapter functions, or any other wireless communication device) may determine a packet delivery window configuration for transmitting and receiving data packets along a transmission timeline. The packet delivery window configuration may indicate a periodicity, offset, start time, end time, and / or duration (length) of a delivery window.

[0039] In some cases, a data packet received within the duration of one of the delivery windows may be retained (e.g., up to a retention time) and delivered later (e.g., at the end time of the corresponding delivery window in which the data packet is received). The retention time may be a time period from when the data packet is received in a particular delivery window to the end time of the corresponding delivery window. Based on the packet delivery window configuration, the UE (or, for example, a UPF or other adapter function at another node of the wireless communication system) may determine a delivery time for delivering a data packet corresponding to a specific application. The data packet may then be delivered (during the corresponding delivery opportunity or after its end time).

[0040] Certain aspects of the subject matter described herein can be implemented to achieve one or more advantages. The described techniques can support improvements in delivery time windows for low latency communications, reduce signaling overhead, and improve reliability, among other advantages. Thus, the supported techniques can include improved network operation, and in some examples, can improve the efficiency of the network, among other benefits.

[0041] Aspects of the present disclosure are initially described in the context of wireless communication systems. Aspects of the present disclosure are also described in the context of transmission timelines and process flows. Aspects of the present disclosure are further illustrated by and described with reference to device diagrams, system diagrams, and flow diagrams related to delivery time windows for low latency communications.

[0042] Figure 1 An example of a wireless communication system 100 supporting a delivery time window for low latency communications in accordance with various aspects of the present disclosure is illustrated. The wireless communication system 100 includes a base station 105, a UE 115, and a core network 130. In some examples, the wireless communication system 100 may be a long term evolution (LTE) network, an advanced LTE (LTE-A) network, an LTE-A Pro network, or a new radio (NR) network. In some cases, the wireless communication system 100 may support enhanced broadband communications, ultra-reliable (e.g., mission-critical) communications, low latency communications, or communications with low-cost and low-complexity devices.

[0043] The base station 105 may communicate wirelessly with the UE 115 via one or more base station antennas. The base station 105 described herein may include or may be referred to by those skilled in the art as a base transceiver station, a radio base station, an access point, a radio transceiver, a Node B, an evolved Node B (eNB), a next generation Node B, or a Gigabit Node B (any of which may be referred to as a gNB), a home Node B, a home evolved Node B, or some other suitable terminology. The wireless communication system 100 may include different types of base stations 105 (e.g., macro cell base stations or small cell base stations). The UE 115 described herein may be able to communicate with various types of base stations 105 and network equipment (including macro eNBs, small cell eNBs, gNBs, relay base stations, etc.).

[0044] Each base station 105 may be associated with a particular geographic coverage area 110 in which it supports communications with various UEs 115. Each base station 105 may provide communications coverage for the respective geographic coverage area 110 via a communications link 125, and the communications link 125 between the base station 105 and the UE 115 may utilize one or more carriers. The communications link 125 shown in the wireless communication system 100 may include an uplink transmission from the UE 115 to the base station 105, or a downlink transmission from the base station 105 to the UE 115. Downlink transmissions may also be referred to as forward link transmissions, and uplink transmissions may also be referred to as reverse link transmissions.

[0045] The geographic coverage area 110 of the base station 105 may be divided into sectors that constitute only a portion of the geographic coverage area 110, and each sector may be associated with a cell. For example, each base station 105 may provide communication coverage for a macrocell, a small cell, a hotspot, or other types of cells, or various combinations thereof. In some examples, the base station 105 may be mobile and therefore provide communication coverage for a mobile geographic coverage area 110. In some examples, different geographic coverage areas 110 associated with different technologies may overlap, and overlapping geographic coverage areas 110 associated with different technologies may be supported by the same base station 105 or different base stations 105. The wireless communication system 100 may include, for example, a heterogeneous LTE / LTE-A / LTE-A Pro or NR network, in which different types of base stations 105 provide coverage for various geographic coverage areas 110.

[0046] The term "cell" refers to a logical communication entity for communicating with base station 105 (e.g., on a carrier), and may be associated with an identifier to distinguish adjacent cells operating via the same or different carriers (e.g., physical cell identifier (PCID), virtual cell identifier (VCID)). In some examples, a carrier may support multiple cells, and different cells may be configured according to different protocol types that may provide access to different types of devices (e.g., machine type communication (MTC), narrowband Internet of Things (NB-IoT), enhanced mobile broadband (eMBB), or others). In some cases, the term "cell" may refer to a portion of a geographic coverage area 110 (e.g., a sector) on which the logical entity operates.

[0047] Each UE 115 can be dispersed throughout the wireless communication system 100, and each UE 115 can be stationary or mobile. UE 115 can also be referred to as a mobile device, a wireless device, a remote device, a handheld device, or a subscriber device, or some other suitable term, wherein "device" can also be referred to as a unit, a station, a terminal, or a client. UE 115 can also be a personal electronic device, such as a cellular phone, a personal digital assistant (PDA), a tablet computer, a laptop computer, or a personal computer. In some examples, UE 115 can also refer to a wireless local loop (WLL) station, an Internet of Things (IoT) device, an Internet of Everything (IoE) device, or an MTC device, etc., which can be implemented in various items (such as electrical appliances, vehicles, meters, etc.).

[0048] Some UEs 115, such as MTC or IoT devices, may be low-cost or low-complexity devices and may provide automated communication between machines (e.g., via machine-to-machine (M2M) communication). M2M communication or MTC may refer to data communication technology that allows devices to communicate with each other or with a base station 105 without human intervention. In some examples, M2M communication or MTC may include communications from devices that integrate sensors or meters to measure or capture information and relay the information to a central server or application, which may utilize the information or present the information to a person interacting with the program or application. Some UEs 115 may be designed to collect information or implement automated behavior of machines. Examples of applications for MTC devices include: smart metering, inventory monitoring, water level monitoring, equipment monitoring, health care monitoring, field survival monitoring, weather and geographic event monitoring, queue management and tracking, remote security sensing, physical access control, and transaction-based commercial charging.

[0049] Some UEs 115 may be configured to employ a reduced power consumption mode of operation, such as half-duplex communication (e.g., a mode that supports unidirectional communication via transmission or reception but not simultaneous transmission and reception). In some examples, half-duplex communication may be performed with a reduced peak rate. Other power saving techniques for UE 115 include entering a power saving "deep sleep" mode when not engaged in active communications, or operating over a limited bandwidth (e.g., in accordance with narrowband communications). In some cases, UE 115 may be designed to support critical functions (e.g., mission critical functions), and the wireless communication system 100 may be configured to provide ultra-reliable communications for these functions.

[0050] In some cases, UE 115 may also be able to communicate directly with other UE 115 (e.g., using a peer-to-peer (P2P) or device-to-device (D2D) protocol). One or more UEs in a group of UEs 115 utilizing D2D communication may be within the geographic coverage area 110 of the base station 105. Other UEs 115 in this group may be outside the geographic coverage area 110 of the base station 105, or may not be able to receive transmissions from the base station 105 for other reasons. In some cases, each group of UEs 115 communicating via D2D communication may utilize a one-to-many (1:M) system, in which each UE 115 transmits to each other UE 115 in the group. In some cases, the base station 105 facilitates the scheduling of resources for D2D communication. In other cases, D2D communication is performed between UEs 115 without involving the base station 105.

[0051] The base stations 105 may communicate with the core network 130 and with each other. For example, the base stations 105 may interface with the core network 130 via a backhaul link 132 (e.g., via S1, N2, N3, or other interfaces). The base stations 105 may communicate with each other directly (e.g., directly between the base stations 105) or indirectly (e.g., via the core network 130) on a backhaul link 134 (e.g., via X2, Xn, or other interfaces).

[0052] The core network 130 may provide user authentication, access authorization, tracking, Internet Protocol (IP) connectivity, and other access, routing, or mobility functions. The core network 130 may be an evolved packet core (EPC), which may include at least one mobility management entity (MME), at least one serving gateway (S-GW), and at least one packet data network (PDN) gateway (P-GW). The MME may manage non-access layer (e.g., control plane) functions such as mobility, authentication, and bearer management of UEs 115 served by base stations 105 associated with the EPC. User IP packets may be delivered through the S-GW, which itself may be connected to the P-GW. The P-GW may provide IP address allocation and other functions. The P-GW may be connected to network operator IP services. Operator IP services may include access to the Internet, intranets, IP multimedia subsystems (IMS), or packet switched (PS) streaming services.

[0053] At least some network devices (such as base stations 105) may include subcomponents, such as access network entities, which may be examples of access node controllers (ANCs). Each access network entity may communicate with each UE 115 through a number of other access network transport entities, which may be referred to as radio heads, smart radio heads, or transmission / reception points (TRPs). In some configurations, the various functions of each access network entity or base station 105 may be distributed across various network devices (e.g., radio heads and access network controllers) or merged into a single network device (e.g., base station 105).

[0054] The wireless communication system 100 may operate using one or more frequency bands, typically in the range of 300 MHz to 300 GHz. In general, the 300 MHz to 3 GHz region is referred to as the ultra-high frequency (UHF) region or decimeter band because the wavelengths range from about 1 decimeter to 1 meter long. UHF waves may be blocked or redirected by buildings and environmental features. However, these waves may penetrate various structures sufficiently for macro cells to provide services to UEs 115 located indoors. Transmission of UHF waves may be associated with smaller antennas and shorter ranges (e.g., less than 100 km) compared to transmission using lower frequencies and longer waves in the high frequency (HF) or very high frequency (VHF) portion of the spectrum below 300 MHz.

[0055] The wireless communication system 100 may also operate in the Super High Frequency (SHF) region using a frequency band from 3 GHz to 30 GHz, also known as the centimeter band. The SHF region includes frequency bands that may be opportunistically used by devices that can tolerate interference from other users, such as the 5 GHz Industrial, Scientific, and Medical (ISM) band.

[0056] The wireless communication system 100 may also operate in the extremely high frequency (EHF) division of the spectrum (e.g., from 30 GHz to 300 GHz), which is also referred to as the millimeter band. In some examples, the wireless communication system 100 may support millimeter wave (mmW) communications between the UE 115 and the base station 105, and the EHF antenna of the corresponding device may be even smaller and more closely spaced than the UHF antenna. In some cases, this may facilitate the use of antenna arrays within the UE 115. However, the propagation of EHF transmissions may be subject to even greater atmospheric attenuation and shorter range than SHF or UHF transmissions. The technology disclosed herein may be adopted across transmissions using one or more different frequency divisions, and the use of designated frequency bands across these frequency divisions may differ by country or regulatory agency.

[0057] In some cases, the wireless communication system 100 may utilize both licensed and unlicensed radio frequency spectrum bands. For example, the wireless communication system 100 may adopt license assisted access (LAA), LTE unlicensed (LTE-U) radio access technology, or NR technology in an unlicensed band (such as a 5GHz ISM band). When operating in an unlicensed radio frequency spectrum band, wireless devices (such as base stations 105 and UE 115) may adopt a listen-before-talk (LBT) procedure to ensure that the frequency channel is clear before transmitting data. In some cases, operations in unlicensed bands may be based on CA configurations (e.g., LAA) in coordination with CCs operating in licensed bands. Operations in unlicensed spectrum may include downlink transmissions, uplink transmissions, peer-to-peer transmissions, or a combination of these. Duplexing in unlicensed spectrum may be based on frequency division duplexing (FDD), time division duplexing (TDD), or a combination of the two.

[0058] In some examples, the base station 105 or the UE 115 may be equipped with multiple antennas, which may be used to employ techniques such as transmit diversity, receive diversity, multiple-input multiple-output (MIMO) communication, or beamforming. For example, the wireless communication system 100 may use a transmission scheme between a transmitting device (e.g., the base station 105) and a receiving device (e.g., the UE 115), wherein the transmitting device is equipped with multiple antennas and the receiving device is equipped with one or more antennas. MIMO communication may employ multipath signal propagation to increase spectral efficiency by transmitting or receiving multiple signals via different spatial layers, which may be referred to as spatial multiplexing. For example, the transmitting device may transmit multiple signals via different antennas or different antenna combinations. Similarly, the receiving device may receive multiple signals via different antennas or different antenna combinations. Each of these multiple signals may be referred to as a separate spatial stream and may carry bits associated with the same data stream (e.g., the same codeword) or different data streams. Different spatial layers may be associated with different antenna ports for channel measurement and reporting. MIMO technology includes single-user MIMO (SU-MIMO), in which multiple spatial layers are transmitted to the same receiving device, and multi-user MIMO (MU-MIMO), in which multiple spatial layers are transmitted to multiple devices.

[0059] Beamforming (which may also be referred to as spatial filtering, directional transmission, or directional reception) is a signal processing technique that may be used at a transmitting device or a receiving device (e.g., a base station 105 or a UE 115) to shape or direct an antenna beam (e.g., a transmit beam or a receive beam) along a spatial path between the transmitting device and the receiving device. Beamforming may be achieved by combining signals communicated via antenna elements of an antenna array so that signals propagating at a particular orientation relative to the antenna array experience constructive interference, while other signals experience destructive interference. Adjustments to signals communicated via antenna elements may include the transmitting device or the receiving device applying a particular amplitude and phase shift to the signal carried via each antenna element associated with the device. Adjustments associated with each antenna element may be defined by a set of beamforming weights associated with a particular orientation (e.g., relative to the antenna array of the transmitting device or the receiving device, or relative to some other orientation).

[0060] In one example, the base station 105 may use multiple antennas or antenna arrays to perform beamforming operations for directional communication with the UE 115. For example, some signals (e.g., synchronization signals, reference signals, beam selection signals, or other control signals) may be transmitted multiple times by the base station 105 in different directions, which may include a signal being transmitted according to different beamforming weight sets associated with different transmission directions. Transmissions in different beam directions may be used to identify (e.g., by the base station 105 or a receiving device, such as the UE 115) a beam direction for subsequent transmission and / or reception by the base station 105. Some signals (such as data signals associated with a particular receiving device) may be transmitted by the base station 105 in a single beam direction (e.g., a direction associated with a receiving device (such as the UE 115)). In some examples, the beam direction associated with transmissions along a single beam direction may be determined based at least in part on signals transmitted in different beam directions. For example, UE 115 may receive one or more signals transmitted by base station 105 in different directions, and UE 115 may report indications of the signals it received with the highest signal quality or other acceptable signal quality to base station 105. Although these techniques are described with reference to signals transmitted by base station 105 in one or more directions, UE 115 may use similar techniques for transmitting signals multiple times in different directions (e.g., for identifying a beam direction for subsequent transmission or reception by UE 115) or for transmitting signals in a single direction (e.g., for transmitting data to a recipient device).

[0061] A receiving device (e.g., UE 115, which may be an example of a mmW receiving device) may try multiple receive beams when receiving various signals (such as synchronization signals, reference signals, beam selection signals, or other control signals) from base station 105. For example, the receiving device may try multiple receive directions by receiving via different antenna subarrays, processing received signals according to different antenna subarrays, receiving according to different receive beamforming weight sets applied to signals received at multiple antenna elements of an antenna array, or processing received signals according to different receive beamforming weight sets applied to signals received at multiple antenna elements of an antenna array, any of which may be referred to as "listening" according to different receive beams or receive directions. In some examples, the receiving device may use a single receive beam to receive along a single beam direction (e.g., when receiving a data signal). The single receive beam may be aligned on a beam direction determined at least in part based on listening according to different receive beam directions (e.g., a beam direction determined to have the highest signal strength, highest signal-to-noise ratio, or other acceptable signal quality based at least in part on listening according to multiple beam directions).

[0062] In some cases, the antennas of a base station 105 or a UE 115 may be located within one or more antenna arrays that may support MIMO operations or transmit or receive beamforming. For example, one or more base station antennas or antenna arrays may be co-located at an antenna assembly, such as an antenna tower. In some cases, the antennas or antenna arrays associated with a base station 105 may be located at different geographic locations. A base station 105 may have an antenna array having several rows and columns of antenna ports that the base station 105 may use to support beamforming for communications with a UE 115. Likewise, a UE 115 may have one or more antenna arrays that may support various MIMO or beamforming operations.

[0063] In some cases, the wireless communication system 100 can be a packet-based network that operates according to a layered protocol stack. In the user plane, the communication of the bearer or packet data convergence protocol (PDCP) layer can be based on IP. In some cases, the radio link control (RLC) layer can perform packet segmentation and reorganization to communicate on the logical channel. The media access control (MAC) layer can perform priority handling and multiplex logical channels into transport channels. The MAC layer can also use hybrid automatic repeat request (HARQ) to provide retransmission of the MAC layer, thereby improving link efficiency. In the control plane, the radio resource control (RRC) protocol layer can provide the establishment, configuration and maintenance of the RRC connection of the radio bearer supporting user plane data between the UE 115 and the base station 105 or the core network 130. In the physical (PHY) layer, the transport channel can be mapped to the physical channel.

[0064] In some cases, UE 115 and base station 105 may support retransmission of data to increase the likelihood that the data is successfully received. HARQ feedback is a technique that increases the likelihood of correctly receiving data on communication link 125. HARQ may include a combination of error detection (e.g., using cyclic redundancy check (CRC)), forward error correction (FEC), and retransmission (e.g., automatic repeat request (ARQ)). HARQ can improve the throughput of the MAC layer in poor radio conditions (e.g., signal-to-noise ratio conditions). In some cases, a wireless device may support simultaneous slot HARQ feedback, where the device may provide HARQ feedback in a specific time slot for data received in a previous symbol in the time slot. In other cases, the device may provide HARQ feedback in a subsequent time slot or according to some other time interval.

[0065] The time interval in LTE or NR can be represented by a basic time unit (which may refer to a sampling period T for example). s =1 / 30,720,000 seconds). The time intervals of the communication resources may be organized according to each other radio frame having a duration of 10 milliseconds (ms), where the frame period may be expressed as T f =307,200Ts . A radio frame may be identified by a system frame number (SFN) ranging from 0 to 1023. Each frame may include 10 subframes numbered from 0 to 9, and each subframe may have a duration of 1 ms. A subframe may be further divided into 2 slots, each slot having a duration of 0.5 ms, and each slot may contain 6 or 7 modulation symbol periods (e.g., depending on the length of a cyclic prefix prepended to each symbol period). Excluding the cyclic prefix, each symbol period may contain 2048 sampling periods. In some cases, a subframe may be the minimum scheduling unit of the wireless communication system 100 and may be referred to as a transmission time interval (TTI). In other cases, the minimum scheduling unit of the wireless communication system 100 may be shorter than a subframe or may be dynamically selected (e.g., in a burst of a shortened TTI (sTTI) or in a selected component carrier using sTTI).

[0066] In some wireless communication systems, a time slot may be further divided into a plurality of mini-slots containing one or more symbols. In some instances, a symbol of a mini-slot or a mini-slot may be the minimum scheduling unit. For example, each symbol may vary in duration depending on the subcarrier spacing or the operating frequency band. Further, some wireless communication systems may implement time slot aggregation, wherein a plurality of time slots or mini-slots are aggregated together and used for communication between UE 115 and base station 105.

[0067] The term "carrier" refers to a set of radio frequency spectrum resources having a defined physical layer structure for supporting communications on the communication link 125. For example, a carrier of the communication link 125 may include a portion of a radio frequency spectrum band that operates according to a physical layer channel for a given radio access technology. Each physical layer channel may carry user data, control information, or other signaling. A carrier may be associated with a predefined frequency channel (e.g., an E-UTRA Absolute Radio Frequency Channel Number (EARFCN)) and may be located according to a channel grid for discovery by a UE 115. A carrier may be downlink or uplink (e.g., in FDD mode), or configured to carry downlink communications and uplink communications (e.g., in TDD mode). In some examples, a signal waveform transmitted on a carrier may include multiple subcarriers (e.g., using a multi-carrier modulation (MCM) technique such as orthogonal frequency division multiplexing or discrete Fourier transform spread OFDM (DFT-s-OFDM)).

[0068] The organization structure of the carrier may be different for different radio access technologies (e.g., LTE, LTE-A, LTE-A Pro, NR, etc.). For example, communications on a carrier may be organized according to TTIs or time slots, each of which may include user data and control information or signaling to support decoding of the user data. A carrier may also include dedicated acquisition signaling (e.g., synchronization signals or system information, etc.) and control signaling to coordinate carrier operations. In some examples (e.g., in a carrier aggregation configuration), a carrier may also have acquisition signaling or control signaling to coordinate the operations of other carriers.

[0069] Physical channels may be multiplexed on a carrier according to various techniques. Physical control channels and physical data channels may be multiplexed on a downlink carrier, for example, using a time division multiplexing (TDM) technique, a frequency division multiplexing (FDM) technique, or a hybrid TDM-FDM technique. In some examples, control information transmitted in a physical control channel may be distributed in a cascaded manner between different control regions (e.g., between a common control region or a common search space and one or more UE-specific control regions or UE-specific search spaces).

[0070] A carrier may be associated with a particular bandwidth of the radio frequency spectrum, and in some examples, the carrier bandwidth may be referred to as the "system bandwidth" of the carrier or wireless communication system 100. For example, the carrier bandwidth may be one of several predetermined bandwidths of a carrier for a particular radio access technology (e.g., 1.4, 3, 5, 10, 15, 20, 40, or 80 MHz). In some examples, each served UE 115 may be configured to operate on part or all of the carrier bandwidth. In other examples, some UEs 115 may be configured to operate using a narrowband protocol type associated with a predefined portion or range (e.g., a set of subcarriers or RBs) within a carrier (e.g., an "in-band" deployment of a narrowband protocol type).

[0071] In a system using MCM technology, a resource element may include a symbol period (e.g., the duration of a modulation symbol) and a subcarrier, where the symbol period and the subcarrier spacing are inversely related. The number of bits carried by each resource element may depend on the modulation scheme (e.g., the order of the modulation scheme). Thus, the more resource elements received by UE 115 and the higher the order of the modulation scheme, the higher the data rate of UE 115 can be. In a MIMO system, wireless communication resources may refer to a combination of radio frequency spectrum resources, time resources, and space resources (e.g., space layers), and the use of multiple space layers may further increase the data rate of communication with UE 115.

[0072] A device (e.g., base station 105 or UE 115) of wireless communication system 100 may have a hardware configuration that supports communication on a particular carrier bandwidth, or may be configurable to support communication on one carrier bandwidth in a set of carrier bandwidths. In some examples, wireless communication system 100 may include base stations 105 and / or UEs 115 that may support simultaneous communication via carriers associated with more than one different carrier bandwidths.

[0073] The wireless communication system 100 may support communication with a UE 115 on multiple cells or carriers, a feature that may be referred to as carrier aggregation (CA) or multi-carrier operation. The UE 115 may be configured with multiple downlink CCs and one or more uplink CCs according to a carrier aggregation configuration. Carrier aggregation may be used with both FDD and TDD component carriers.

[0074] In some cases, the wireless communication system 100 may utilize an enhanced component carrier (eCC). An eCC may be characterized by one or more features including a wider carrier or frequency channel bandwidth, a shorter symbol duration, a shorter TTI duration, or a modified control channel configuration. In some cases, an eCC may be associated with a carrier aggregation configuration or a dual connectivity configuration (e.g., when multiple serving cells have suboptimal or non-ideal backhaul links). An eCC may also be configured for use in an unlicensed spectrum or a shared spectrum (e.g., where more than one operator is allowed to use the spectrum). An eCC characterized by a wide carrier bandwidth may include one or more segments that may be utilized by a UE 115 that is not capable of monitoring the entire carrier bandwidth or is otherwise configured to use a limited carrier bandwidth (e.g., to save power).

[0075] In some cases, an eCC may utilize a different symbol duration than other CCs, which may include using a reduced symbol duration compared to the symbol duration of other CCs. A shorter symbol duration may be associated with an increased spacing between adjacent subcarriers. A device utilizing an eCC (such as a UE 115 or a base station 105) may transmit a wideband signal (e.g., based on a frequency channel or carrier bandwidth of 20, 40, 60, 80 MHz, etc.) with a reduced symbol duration (e.g., 16.67 microseconds). A TTI in an eCC may include one or more symbol periods. In some cases, the TTI duration (i.e., the number of symbol periods in a TTI) may be variable.

[0076] Wireless communication systems (such as NR systems) can utilize any combination of licensed, shared, and unlicensed spectrum bands, etc. The flexibility of eCC symbol duration and subcarrier spacing can allow for the use of eCC across multiple spectrums. In some examples, NR shared spectrum can improve spectrum utilization and spectrum efficiency, particularly through dynamic vertical (e.g., across frequency domain) and horizontal (e.g., across time domain) sharing of resources.

[0077] Some wireless communication systems (e.g., wireless communication system 100) may be used to facilitate communication in networks that rely on relatively strict timing synchronization of network components, sometimes referred to as TSN systems. Such systems may be used to support, for example, factory automation. Some TSN systems specify relatively stringent quality of service (QoS) parameters such as jitter, reliability targets (e.g., packet error loss), and / or delay targets (e.g., PDB, latency targets, etc.) for data traffic. For example, a TSN system may have latency targets such as less than 1 ms and less than 10 -6 In some cases, such data traffic may be supported in a wireless communication system using a high reliability service such as a URLLC service.

[0078] In a wireless communication system 100 (e.g., carrying TSN communications), QoS requirements for a specific QoS flow can define a target PDB. The target PDB can set a target latency or total time delay for communications between a UE 115 and a core network 130 of the wireless communication system 100, at which the data packets communicated can be used. In the case of downlink transmission, the PDB may include a first delay component incurred between the core network 130 (e.g., from a UPF, SMF, or other adapter function) and a radio access node (e.g., at a base station). The PDB may also include a second delay component incurred between a base station 105 and a UE 115. In general, this total PDB defines a target latency from a UPF via a base station 105 to a UE 115. In the case of uplink transmission, the PDB may similarly define a target latency from a UE 115 via a base station 105 to a UPF or SMF. If the total delay of conveying a data packet exceeds the total PDB defined by the PDB configuration, the data packet may not be usable and may be ignored.

[0079] According to some aspects, the total PDB or one or more delay components in the total PDB may be divided into one or more additional components or delay budgets. For example, one or more delay budgets may be divided within a radio access network (RAN). In some cases, the RAN may be or include a central unit (CU) and a distributed unit (DU). A delay budget configuration (e.g., a PDB configuration indicating the total PDB or one or more components in the total PDB) may include one or more delay budgets (e.g., variable and / or non-variable delay budgets) incurred between the CU and the DU. For example, the delay budget configuration may indicate a balanced budget (e.g., a uniformly split delay budget) between the CU, the DU, and the UE 115. In such cases, the delay budget configuration may indicate that the delay budget between the base station 105-a of the RAN and the UE 115 is divided into a corresponding delay budget for each of the CU to the DU and the DU to the UE 115. In other examples, the delay budget between the RAN and the UE 115 may be unbalanced (e.g., unevenly split) between the CU, the DU, and the UE 115, or may be defined separately from the total PDB and may be a separate component of the total PDB.

[0080] However, in some cases, jitter in the wireless communication system 100 may cause the total delay of the communication between the UE 115, the base station 105, the UPF, and other devices (e.g., CU, DU) in the wireless communication system 100 to change. In some cases, jitter may cause the receiving device (e.g., UE 115 or another device within the wireless communication system 100) to receive the transmission before it is expected to be received. However, the transmission received in advance can be received during the packet delivery window, for which the receiving device delays the data transmission until the end of the packet delivery window. Therefore, the transmission received in advance due to jitter may result in a transmission queue to be transmitted at the end of the packet delivery window. This may reduce the efficiency (e.g., utilization of time and frequency resources) in which these transmissions can be communicated.

[0081] Discussed herein are techniques for providing signaling (e.g., at a recipient device) to determine or receive a packet delivery time window configuration that indicates a delivery window in which a transmission may be held and / or a delivery opportunity in which a communication is expected to be transmitted. For example, the packet delivery time window configuration may indicate a periodicity, offset, and / or duration of one or more delivery windows for delivering packets to a recipient device. The packet delivery time window configuration may implicitly (e.g., based on knowledge of the delivery window) or explicitly indicate a periodicity, offset, and / or duration of one or more delivery opportunities during which a corresponding data transmission may be transmitted by the recipient device.

[0082] Figure 2An example of a transmission timeline 200 associated with a wireless communication system supporting a delivery time window for low latency communications in accordance with aspects of the present disclosure is illustrated. In some examples, the transmission timeline 200 may be implemented as described with reference to Figure 1 Aspects of the wireless communication system 100 are described. Transmission timeline 200 illustrates a transmission scheme for downlink low latency transmission communications in a low latency communication system, which may be referred to by reference. Figure 1 The low latency communication system is described with reference to a radio access node (eg, at a base station 105) and a UE 115, which may be implemented as described with reference to Figure 1 Examples of corresponding devices described. A UE may include a modem that may receive data packets from a radio access node and deliver the received data packets to a corresponding application hosted by the UE that may use information in the received data packets.

[0083] It should be understood that references to specific RATs (e.g., LTE or NR) are provided for illustrative purposes only, and different RATs not specifically mentioned herein may be used interchangeably with those described herein. In addition, although each operation may be described as being performed by one device to another device in one of an uplink or a downlink, it should be understood that these functions may be similarly performed for both uplink and downlink and by each of the different devices described herein. Each operation also generally describes communication between one transmitting device and a receiving device, but may be similarly applied to multiple devices in any combination, for example, to coordinate between different ports at different bridges of different receiving devices from one transmitting device.

[0084] Transmission timeline 200 illustrates a transmission scheme for low latency communication between a transmitting device and a receiving device. In this example (e.g., downlink), the transmitting device is described herein as a base station, and the receiving device is described herein as a UE. However, it should be understood that in different RATs, devices, nodes, functions (e.g., different adapter functions), etc. may perform each of the corresponding functions, and similar techniques may also be applicable to uplink communications. Transmission timeline 200 illustrates a timeline for receiving a transmission at a modem, which may be implemented, for example, at a UE or another wireless node in the system. For example, the modem may deliver data to an application hosted by the UE.

[0085] The base station may also communicate with a core network (e.g., a data network). In some cases, the core network entity may include various adapter functions, such as SMF, UPF, access and mobility function (AMF) and / or control plane function (CPF). In some cases, SMF may provide session management services for UE. For example, SMF may communicate with different nodes in a wireless communication system to signal different QoS procedures to be performed for different QoS standards to the nodes. In some cases, UPF may handle user information, such as PDCP, RLC, MAC and PHY communications. In other cases, and as contemplated below, the functions of UPF (and any other adapter functions) may be performed at another device within the system. In some cases, the adapter function may be communicatively coupled in the core network entity. In other cases, the adapter function may be located at separate nodes within the system.

[0086] The transmission timeline 200 shows a plurality of delivery windows 210, each of which has a duration from a start time 215 to an end time 220. In some cases, one or more of the delivery windows 210 may be separated by a delivery window offset. In some cases, the delivery window offset may be constant or variable between each of the delivery windows 210 relative to a global clock (e.g., 0.5 ms, or any other constant or variable offset value relative to a global clock). As described herein, a packet received during one of the delivery windows 210 may be retained until the end time 220 of the corresponding delivery window 210, at which time the packet may be transmitted during a delivery opportunity 225. These delivery opportunities 225 may coincide with the delivery window offset between each of the delivery windows 210.

[0087] In some cases, the UE may determine a packet delivery window configuration for transmitting and receiving data packets along the transmission timeline 200. Additionally or alternatively, the packet delivery window configuration may be determined at another device (e.g., by a UPF (or other adapter function) at a base station or another wireless device within the wireless communication system). The packet delivery window configuration may indicate the periodicity, offset, start time 215 (e.g., expressed as a timestamp relative to a reference time), end time 220 (e.g., expressed as a timestamp relative to a reference time), and / or duration (e.g., length) of the delivery window 210. Similarly, the packet delivery window configuration may explicitly or implicitly indicate the periodicity, offset, start and end times, and / or duration of the delivery window 210 (e.g., based on knowledge of the periodicity, offset, and / or duration of the delivery window 210). The periodicity of the delivery window 210 and the delivery opportunity 225 may be defined by a period 230 including one or more delivery windows 210 and one or more delivery opportunities 225. The period 230 may be fixed, for example, as may have been negotiated for the wireless communication system.

[0088] In some cases, a data packet received within the duration of one of the delivery windows 210 may be retained for a retention time and delivered later (e.g., at an end time 220 of the corresponding delivery window 210 in which the data packet was received). In some cases, the retention time may be a time period from when the data packet is received in a particular delivery window 210 to the end time 220 of the corresponding delivery window 210. The data packet may then be delivered in a corresponding delivery opportunity 225 after the end time 220. In some cases, the UE may buffer the data packet until a subsequent delivery opportunity 225 (e.g., storing the data packet in a buffer for the duration of the retention time). Alternatively, the data packet may be received outside of the delivery window 210, in which case the data packet may be delivered, for example, based on a configured priority (e.g., the data packet may be delivered as soon as it is received, or delivered subject to a delay based on the configured priority (which may not be subject to retention)).

[0089] That is, according to the packet delivery window configuration, the UE (or, for example, a UPF or other adapter function at another node of the wireless communication system) can determine a delivery time for delivering a data packet corresponding to a specific application. As described herein, the packet delivery time of the data packet can be determined based on the arrival time of the data packet received by the UE compared to the delivery window 210. The delivery window 210 can be a time interval configured according to the packet delivery window configuration, the packet arrival time configuration, the PDB configuration for the QoS flow associated with the data packet (for example, the PDB configuration determined by one of the adapter functions at the node of the wireless communication system and signaled to the UE), and / or one or more configurable parameters (for example, the periodicity, offset and duration of the delivery window 210 and the delivery opportunity 225). The packet arrival time configuration may include one or more indications of the packet arrival time (for example, using a period and an offset / phase) or an indication of the RAN packet arrival time (for example, indicated using a period and an offset / phase).

[0090] In some cases, the UE may determine the delivery time of the data packet based on the end time 220 of the delivery window 210 in which the UE receives the data packet. Figure 2 As shown, the end time 220 of the delivery window 210 can define the time when the delivery opportunity 225 can start. For example, for a data packet received by the UE's modem during the delivery window 210 (e.g., received from the UPF via the base station), the modem can deliver the data packet to the corresponding application during the same delivery window 210 (e.g., before the end time 220 or following the end time 220). In some cases, the duration of the delivery window 210 can be configured to be equal to the PDB (as indicated by the PDB configuration). Alternatively, a delivery opportunity may not be provided, in which case the UE may continue to retain the data packet, or in other cases, the UE may discard the data packet.

[0091] Additionally or alternatively, the UE may determine the delivery time of the data packet based on the sum of the arrival time of the data packet received by the UE (e.g., determined based on the packet arrival time configuration) and the PDB corresponding to the QoS flow associated with the data packet. In this case, the delay may follow the end time of the delivery window 210 and before the UE's modem delivers the data packet to the application.

[0092] Figure 3 An example of a transmission timeline 300 supporting a delivery time window for low latency communications in accordance with aspects of the present disclosure is illustrated. In some examples, the transmission timeline 300 may be implemented as described with reference to Figure 1 and 2Aspects of the wireless communication system described. Transmission timeline 300 illustrates a transmission scheme for uplink low latency transmission communication in a low latency communication system, which can be referred to by reference Figure 1 and 2 Aspects of the wireless communication system 100 or transmission timeline 200 described herein are implemented. A low latency communication system is described with reference to a radio access node (eg, at a base station 105) and a UE 115, which may be as described with reference to Figure 1 and 2 Examples of corresponding devices described. A UE may include a modem that may receive data packets from a radio access node and deliver the received data packets to a corresponding application hosted by the UE that may use information in the received data packets.

[0093] It should be understood that references to specific RATs (e.g., LTE or NR) are provided for illustrative purposes only, and different RATs not specifically mentioned herein may be used interchangeably with those described herein. In addition, although each operation may be described as being performed by one device to another device in one of an uplink or a downlink, it should be understood that these functions may be similarly performed for both uplink and downlink and by each of the different devices described herein. Each operation also generally describes communication between one transmitting device and a receiving device, but may be similarly applied to multiple devices in any combination, for example, to coordinate between different ports at different bridges of different receiving devices from one transmitting device.

[0094] Transmission timeline 300 illustrates a transmission scheme for low latency communication between a transmitting device and a receiving device. In this example (e.g., uplink), the transmitting device is described herein as a UE, and the responding device is described herein as a UPF. However, it should be understood that in different RATs, devices, nodes, functions (e.g., different adapter functions), etc. may perform each of the corresponding functions, and similar techniques may also be applicable to uplink communications. Transmission timeline 300 illustrates a timeline for receiving a transmission from a modem, which may be implemented, for example, at a UE or another wireless node in the system. For example, the modem may deliver data to an application hosted by the UE.

[0095] The base station can also communicate with the core network (e.g., data network). In some cases, the core network entity may include various adapter functions, such as SMF, UPF, AMF and / or CPF. In some cases, SMF can provide session management services for UE. For example, SMF can communicate with different nodes in the wireless communication system to signal the nodes to perform different QoS procedures for different QoS standards. In some cases, UPF can handle user information, such as PDCP, RLC, MAC and PHY communications. In other cases, and as conceived below, the functions of UPF (and any other adapter functions) can be performed at another device in the system. In some cases, the adapter functions can be coupled in the core network entity. In other cases, the adapter functions can be located at separate nodes in the system.

[0096] The transmission timeline 300 shows a plurality of delivery windows 310, each of which has a duration from a start time 315 to an end time 320. In some cases, one or more of the delivery windows 310 may be separated by a delivery window offset. In some cases, the delivery window offset may be constant or variable between each of the delivery windows 310 relative to a global clock (e.g., 0.5 ms, or any other constant or variable offset value relative to a global clock). As described herein, a packet received during one of the delivery windows 310 may be retained until the end time 320 of the corresponding delivery window 310, at which time the packet may be transmitted during a delivery opportunity 325. These delivery opportunities 325 may coincide with the delivery window offset between each of the delivery windows 310.

[0097] In some cases, the UPF may determine a packet delivery window configuration for transmitting and receiving data packets along the transmission timeline 300. Additionally or alternatively, the packet delivery window configuration may be determined at another device (e.g., by a UE within the wireless communication system, another adapter function, at a base station or another wireless device). In some cases, the packet delivery window configuration may be signaled via a radio protocol message. The packet delivery window configuration may indicate the periodicity, offset, start time 315 (e.g., expressed as a timestamp relative to a reference time), end time 320 (e.g., expressed as a timestamp relative to a reference time), and / or duration (e.g., length) of the delivery window 310. Similarly, the packet delivery window configuration may explicitly or implicitly indicate the periodicity, offset, start and end time and / or duration of the delivery window 310 or delivery opportunity 325 (e.g., based on knowledge of the periodicity, offset, and / or duration of the delivery window 310). The periodicity of the delivery window 310 and the delivery opportunity 325 may be defined by a period 330 that includes one delivery window 310 and one delivery opportunity 325. The period 330 may be constant, for example, as may have been negotiated for the wireless communication system.

[0098] In some cases, a data packet received within the duration of one of the delivery windows 310 may be retained for the retention time and delivered (at the end time 320 of the corresponding delivery window 310 in which the data packet is received). The retention time may be a time period from when the data packet is received in a particular delivery window 310 to the end time 320 of the corresponding delivery window 310. The data packet may then be delivered to the core network in a corresponding delivery opportunity 325 after the end time 320. In some cases, the UPF may buffer the data packet until a subsequent delivery opportunity 325 (e.g., storing the data packet in a buffer for the duration of the retention time). Alternatively, the data packet may be received outside the delivery window 310, in which case the data packet may be delivered, for example, based on a configured priority (e.g., the data packet may be delivered as it is received, or delivered subject to a delay based on the configured priority (which may not be subject to retention)).

[0099] That is, according to the packet delivery window configuration, the UPF (or other adapter functions at another node of the wireless communication system) can determine the delivery time for delivering data packets corresponding to a specific application. As described herein, the packet delivery time of the data packet can be determined based on the arrival time of the data packet received by the UPF compared to the delivery window 310. The delivery window 310 can be a time interval configured according to the packet delivery window configuration, the packet arrival time configuration, the PDB configuration for the QoS flow associated with the data packet (e.g., the PDB configuration is determined by the UPF, or another adapter function (such as SMF) at the node of the wireless communication system signals the UPF), and / or one or more configurable parameters (e.g., the periodicity, offset and duration of the delivery window 310 and the delivery opportunity 325). The packet arrival time configuration may include one or more indications of the packet arrival time (e.g., UE packet arrival time) (e.g., using a period and an offset / phase), or an indication of the RAN packet arrival time (e.g., indicated using a period and an offset / phase).

[0100] In some cases, the UPF may determine the delivery time of the data packet based on the end time 320 of the delivery window 310 in which the UPF receives the data packet. Figure 3 As shown, the end time 320 of the delivery window 310 can define the time when the delivery opportunity 325 can start. For example, for a data packet received by the UPF during the delivery window 310 (e.g., received from the UE via the base station), the UPF can deliver the data packet to the core network during the delivery window 310 following the end time 320. In some cases, the duration of the delivery window 310 can be configured to be equal to the PDB (as indicated by the PDB configuration). Alternatively, a delivery opportunity may not be provided, in which case the UPF may continue to retain the data packet, or in other cases, the UPF may discard the data packet.

[0101] Additionally or alternatively, the UPF may determine the delivery time of the data packet based on the arrival time of the data packet received by the UPF (e.g., determined based on the packet arrival time configuration) and the sum of the PDB corresponding to the QoS flow associated with the data packet. In this case, the delay may follow the end time of the delivery window 310 and before the UPF delivers the data packet to the core network.

[0102] Figure 4An example of a process flow 400 for supporting a delivery time window for low latency communications in accordance with aspects of the present disclosure is illustrated. In some examples, the process flow 400 may implement aspects of the wireless communication system 100, the transmission timeline 200 associated with the wireless communication system, and the transmission timeline 300 associated with the wireless communication system. The process flow 400 includes a base station 105-a and a UE 115-a, wherein the UE 115-b includes an application 405 and a modem 410, and each may be referenced Figures 1 to 3 Examples of corresponding devices described. Different RATs, devices, nodes, functions, etc. may perform similar functions. Process flow 400 illustrates a transmission scheme for downlink low latency transmission communication in a low latency communication system, which may implement reference Figures 1 to 3 Aspects of wireless communication system 100 are described.

[0103] It should be understood that references to specific RATs (e.g., LTE or NR) are provided for illustrative purposes only, and different RATs not specifically mentioned herein may be used interchangeably with those described herein. In addition, while process flow 400 shows an example of downlink communications, it should be understood that functions may be similarly performed for uplink and downlink and by each of the different devices described herein. The operations also generally describe communications between one transmitting device and a receiving device, but may be similarly applied to multiple devices in any combination, such as to coordinate between different ports at different bridges of different receiving devices from one transmitting device.

[0104] Process flow 400 illustrates a transmission scheme for low latency communication between a transmitting device and a receiving device. In this example (e.g., downlink), the transmitting device is described herein as a base station 105-a, and the receiving device is described herein as a UE 115-a, wherein the UE 115-a includes an application 405 and a modem 410. However, it should be understood that in different RATs, devices, nodes, functions (e.g., different adapter functions), etc. may perform each of the corresponding functions, and similar techniques may also be applicable to uplink communications. Process flow 400 illustrates that the UE 115-a receives a transmission at the modem 410. The modem 410 may deliver data to the application 405 hosted by the UE 115-a.

[0105] Process flow 400 includes a first time period 415, a second time period 420, a third time period 430, and a fourth time period 440. Initially, modem 410 may identify a packet delivery time window configuration (e.g., a packet delivery window configuration) for a communication of a traffic type (e.g., a traffic class). Traffic types may include or refer to communication traffic with different reliability thresholds, different latency thresholds, different services, or various combinations thereof. According to the packet delivery time window configuration, a corresponding delivery time window and a delivery opportunity are included in each of the time periods. Modem 410 may determine the delivery time window based on the packet delivery time window configuration. In some cases, modem 410 may determine a delay budget (e.g., PDB 460) associated with the communication of the traffic type, and may determine the delivery opportunity based on the delay budget. In some cases, modem 410 may determine the delivery time window based on the delay budget.

[0106] In some cases, the modem 410 may determine the time interval associated with the delivery opportunity based on the end time of the delivery time window. In some cases, the packet delivery time window configuration may indicate: the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, and / or the duration of the delivery time window. In some cases, the modem 410 may receive an indication of the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, and / or the duration of the delivery time window from the base station 105-a (e.g., via the radio access node of the base station 105-a), and may determine the delivery time window based on receiving the indication. In some cases, the modem 410 may receive the indication via a radio protocol message.

[0107] For example, first time period 415 includes first delivery opportunity 417 and first delivery time window 418, second time period 420 includes second delivery opportunity 422 and second delivery time window 423, third time period 430 includes third delivery opportunity 432 and third delivery time window 433, and fourth time period 440 includes fourth delivery opportunity 442 and fourth delivery time window 443. As described herein, a data packet received during one of the delivery time windows may be retained until the end time of the corresponding delivery time window, at which time the data packet may be transmitted during a subsequent delivery opportunity.

[0108] Alternatively or additionally, the modem 410 may identify a packet arrival window associated with the UE 115-a. Based on the packet arrival window, the modem 410 may determine a delivery opportunity based on the end duration of the packet arrival window. Additionally or alternatively, the modem 410 may determine a delivery opportunity based on a packet arrival time associated with the UE 115-a and a delay budget for communication of the traffic type (for which a packet delivery time window configuration has been identified). In some cases, the modem 410 may receive a packet arrival time window configuration indicating a UPF packet arrival time window configuration, a RAN packet arrival time window configuration, and / or a UE packet arrival time window configuration, and may determine a delivery opportunity based on receiving the packet arrival time window configuration.

[0109] At 450, the base station 105-a may identify a first data packet to be transmitted to the modem 410. In some cases, the base station 105-a may periodically (e.g., with a defined periodicity) receive data packets from the core network. For example, the base station 105-a may receive a first data packet from the core network, the first data packet including information for the application 405.

[0110] At 452, the base station 105-a may transmit a first data packet to the modem 410, and the modem 410 may receive the first data packet from the base station 105-a, as already identified at 450. As shown, the modem 410 receives the first data packet prior to a first delivery opportunity 417, where the first delivery opportunity 417 is based on a packet delivery time window configuration. In some cases, the first data packet may be a traffic type for which a packet delivery time window configuration may have been identified.

[0111] At 454, the modem 410 may transmit an acknowledgment to the base station 105-a, and the base station 105-a may receive the acknowledgment from the modem 410. For example, the acknowledgment may indicate that the first data packet at 452 was successfully received.

[0112] At 456, modem 410 may delay transmission of the first data packet based on the packet delivery time window configuration and that the first data packet has been received prior to second delivery opportunity 422. In some cases, modem 410 may buffer the first data packet, as may have been received at 452. In some cases, modem 410 may buffer the first data packet prior to transmitting the first data packet based on having received the first data packet during first delivery time window 418 prior to an upcoming delivery opportunity (e.g., second delivery opportunity 422). Modem 410 may maintain the first data packet in the buffer for the hold time until a time when modem 410 may deliver the first data packet (e.g., following an end time of first delivery time window 456).

[0113] At 458, modem 410 may deliver (e.g., transmit) the first data packet to application 405, and application 405 may receive the first data packet from modem 410. Modem 410 may deliver the first data packet during a time interval that has been determined to be associated with second delivery opportunity 422. As shown, application 405 delivers the first data packet at the beginning of second delivery opportunity 422 after the end time of first delivery time window 418. Alternatively, modem 410 may deliver (e.g., transmit) the first data packet during the end portion of first delivery time window 418 based on the packet delivery time window configuration.

[0114] At 462, following the PDB 460, the base station 105-a may identify a second data packet to transmit to the modem 410. For example, the base station 105-a may receive the second data packet including information for the application 405 from the core network.

[0115] At 464, the base station 105-a may transmit the second data packet to the modem 410, and the modem 410 may receive the second data packet from the base station 105-a, as already identified at 462. As shown, the modem 410 receives the second data packet prior to the third delivery opportunity 432, where the third delivery opportunity 432 is based on the packet delivery time window configuration. In some cases, the second data packet may be a traffic type for which the packet delivery time window configuration may have been identified.

[0116] At 466, modem 410 may transmit an acknowledgment to base station 105-a, and base station 105-a may receive an acknowledgment from modem 410. For example, the acknowledgment may indicate that the second data packet was successfully received at 464.

[0117] At 468, modem 410 may delay transmission of the second data packet based on the packet delivery time window configuration and that the second data packet has been received prior to third delivery opportunity 432. In some cases, modem 410 may buffer the second data packet, as may have been received at 464. In some cases, modem 410 may buffer the second data packet before transmitting the second data packet based on having received the second data packet during a second delivery time window 423 prior to an upcoming delivery opportunity (e.g., third delivery opportunity 432). Modem 410 may maintain the second data packet in the buffer for the hold time until a time when modem 410 may deliver the second data packet (e.g., following an end time of second delivery time window 423).

[0118] At 470, modem 410 may deliver the second data packet to application 405, and application 405 may receive the second data packet from modem 410. As shown, application 405 delivers the second data packet at the beginning of a third delivery opportunity 432 after the end time of second delivery time window 423.

[0119] At 472, the base station 105-a may identify a third data packet to be transmitted to the modem 410. For example, the base station 105-a may receive a third data packet 450 including information for the application 405 from the core network.

[0120] At 474, the base station 105-a may transmit the third data packet to the modem 410, and the modem 410 may receive the third data packet from the base station 105-a, as already identified at 472. In this example, the transmission of the third data packet may encounter interference or congestion, or for other reasons may not be successfully received at the modem 410 to enable the modem 410 to decode sufficient information from the third data packet (e.g., based on a threshold).

[0121] At 476, the modem 410 may transmit a negative acknowledgement to the base station 105-a, and the base station 105-a may receive the negative acknowledgement from the modem 410. For example, the negative acknowledgement may indicate that the third data packet at 474 was not successfully received.

[0122] At 478, the base station 105-a may retransmit the third data packet to the modem 410, and the modem 410 may receive the third data packet from the base station 105-a, as already identified at 472. The base station 105-a may retransmit the third data packet based on receiving a negative acknowledgment from the modem 410 at 476. As shown, the modem 410 receives the third data packet prior to the fourth delivery opportunity 442, where the fourth delivery opportunity 442 is based on the packet delivery time window configuration. In some cases, the first data packet may be a traffic type whose packet delivery time window configuration may have been identified.

[0123] At 480, modem 410 may delay transmission of the third data packet based on the packet delivery time window configuration and the fact that the third data packet has been received before fourth delivery opportunity 442. In some cases, modem 410 may buffer the third data packet, as may have been received in the retransmission of 478. In some cases, modem 410 may buffer the third data packet before transmitting the third data packet based on the fact that the third data packet has been received during the third delivery time window 433 before the upcoming delivery opportunity (e.g., fourth delivery opportunity 442). Modem 410 may maintain the third data packet in the buffer for the hold time until a time when modem 410 may deliver the third data packet (e.g., following the end time of third delivery time window 433). As shown in this example, since modem 410 receives the third data packet in the retransmission of 478, the hold time of the third data packet is relatively shorter than the hold times of the first, second, and fourth data packets.

[0124] At 482, modem 410 may deliver the third data packet to application 405, and application 405 may receive the third data packet from modem 410. As shown, application 405 delivers the third data packet at the beginning of fourth delivery opportunity 442 after the end time of third delivery time window 433.

[0125] At 484, the base station 105-a may identify a fourth data packet to be transmitted to the modem 410. For example, the base station 105-a may receive a fourth data packet from the core network, the fourth data packet including information for the application 405. In this example, the base station 105-a may receive the fourth data packet relatively earlier than the other data packets for the fourth time period 440. As shown, the base station 105-a identifies the fourth data packet during a time period that overlaps with the third time period 430.

[0126] At 486, base station 105-a may transmit a fourth data packet to modem 410, and modem 410 may receive the fourth data packet from base station 105-a, as already identified at 484. Because, in this example, the fourth data packet was received earlier, modem 410 receives the fourth data packet during fourth delivery time window 443. Since modem 410 receives the fourth data packet during fourth delivery time window 443 and not during a delivery opportunity, modem 410 may not deliver the fourth data packet to application 405.

[0127] At 488, the modem 410 may transmit an acknowledgment to the base station 105-a, and the base station 105-a may receive an acknowledgment from the modem 410. For example, the acknowledgment may indicate that the fourth data packet was successfully received at 486.

[0128] At 490, modem 410 may buffer the fourth data packet, as may have been received at 488. Modem 410 may maintain the fourth data packet in the buffer for the hold time until a time when modem 410 may deliver the second data packet. However, as in this example, modem 410 receives the fourth data packet during fourth delivery time window 443, but not during the delivery opportunity, and thus modem 410 may not deliver the fourth data packet to application 405. In this case, modem 410 may, for example, discard the fourth data packet to clear the packet from the buffer.

[0129] At 492, modem 410 may not deliver the fourth data packet to application 405. In this example, modem 410 receives the fourth data packet during fourth delivery time window 443 but not during a delivery opportunity, and thus modem 410 may not deliver the fourth data packet to application 405. Therefore, application 405 may not receive the fourth data packet at this time.

[0130] Figure 5 An example of a process flow 500 for supporting a delivery time window for low latency communications in accordance with aspects of the present disclosure is illustrated. In some examples, the process flow 500 can implement the wireless communication system 100, the transmission timeline 200 associated with the wireless communication system, and the transmission timeline 300 associated with the wireless communication system, as well as the wireless communication system 100, the wireless communication system 100, and the wireless communication system 100. Figures 1 to 4 Aspects of the process flow 400 are described. The process flow 500 includes a data network 501 (e.g., a core network), a UPF 502, a base station 105-b, and a UE 115-b, wherein the UE 115-b includes an application 505 and a modem 510, and each may be referenced Figures 1 to 3Examples of corresponding devices described herein. Different RATs, devices, nodes, functions, etc. may perform similar functions. Process flow 500 illustrates a transmission scheme for uplink low latency transmission communication in a low latency communication system, which may be implemented with reference to Figures 1 to 4 Aspects of wireless communication system 100 are described.

[0131] It should be understood that references to specific RATs (e.g., LTE or NR) are provided for illustrative purposes only, and different RATs not specifically mentioned herein may be used interchangeably with those described herein. In addition, while process flow 500 shows an example of uplink communications, it should be understood that functions may be similarly performed for both uplink and downlink and by each of the different devices described herein. The operations also generally describe communications between one transmitting device and a receiving device, but may be similarly applied to multiple devices in any combination, such as to coordinate between different ports at different bridges of different receiving devices from one transmitting device.

[0132] Process flow 500 illustrates a transmission scheme for low latency communication between a transmitter device and a receiver device. In this example (e.g., uplink), the transmitter device is described herein as UE 115-b, and the receiver device is described herein as UPF 502, wherein UE 115-b includes application 505 and modem 510. However, it should be understood that in different RATs, devices, nodes, functions (e.g., different adapter functions), etc. may perform each of the corresponding functions, and similar techniques may also be applicable to uplink communications. For example, process flow 500 includes UPF 502, although the functions of UPF 502 may be similarly performed by another adapter function or another wireless device.

[0133] Process flow 500 includes a first time period 515, a second time period 520, a third time period 530, and a fourth time period 540. Initially, UPF 502 may identify a packet delivery time window configuration (e.g., a packet delivery window configuration) for a communication of a traffic type. According to the packet delivery time window configuration, a corresponding delivery time window and a delivery opportunity are included in each of the time periods. UPF 502 may determine the delivery time window based on the packet delivery time window configuration. In some cases, UPF 502 may determine a delay budget (e.g., PDB 560) associated with the communication of the traffic type, and may determine the delivery opportunity based on the delay budget. In some cases, UPF 502 may determine the delivery time window based on the delay budget.

[0134] In some cases, the UPF 502 may determine the time interval associated with the delivery opportunity based on the end time of the delivery time window. In some cases, the packet delivery time window configuration may indicate: the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, and / or the duration of the delivery time window. In some cases, the UPF 502 may receive an indication of the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, and / or the duration of the delivery time window from the UE 105-b (e.g., via the radio access node of the base station 105-b), and may determine the delivery time window based on receiving the indication. In some cases, the UPF 502 may receive the indication via a radio protocol message.

[0135] For example, first time period 515 includes first delivery opportunity 517 and first delivery time window 518, second time period 520 includes second delivery opportunity 522 and second delivery time window 523, third time period 530 includes third delivery opportunity 532 and third delivery time window 533, and fourth time period 540 includes fourth delivery opportunity 542 and fourth delivery time window 543. As described herein, a data packet received during one of the delivery time windows may be retained until the end time of the corresponding delivery time window, at which time the data packet may be transmitted during a subsequent delivery opportunity.

[0136] Alternatively or additionally, UPF 502 may identify a packet arrival window associated with data network 501. Based on the packet arrival window, UPF 502 may determine a delivery opportunity based on the end duration of the packet arrival window. Additionally or alternatively, UPF 502 may determine a delivery opportunity based on a packet arrival time associated with data network 501 and a delay budget for communication of the traffic type (for which a packet delivery time window configuration has been identified). In some cases, UPF 502 may receive a packet arrival time window configuration indicating a UPF packet arrival time window configuration, a RAN data packet arrival time window configuration, and / or a UE packet arrival time window configuration, and may determine a delivery opportunity based on receiving the packet arrival time window configuration.

[0137] At 550, UE 115-b may identify a first data packet to transmit to UPF 502. In some cases, UE 115-b may periodically (eg, with a defined periodicity) identify data packets to transmit.

[0138] At 552, UE 115-b may transmit a first data packet to UPF 502 via base station 105-b, and UPF 502 may receive the first data packet from UE 115-b, as already identified at 550. As shown, UPF 502 receives the first data packet prior to first delivery opportunity 517, where first delivery opportunity 517 is based on a packet delivery time window configuration. In some cases, the first data packet may be a traffic type for which a packet delivery time window configuration may have been identified.

[0139] At 554, the base station 105-b may transmit an acknowledgment to the UE 115-b, and the UE 115-b may receive the acknowledgment from the base station 105-b. For example, the acknowledgment may indicate that the first data packet was successfully received at 552.

[0140] At 556, UPF 502 may delay transmission of the first data packet based on the packet delivery time window configuration and that the first data packet has been received before the second delivery opportunity 522. In some cases, UPF 502 may buffer the first data packet, as may have been received at 552. In some cases, UPF 502 may buffer the first data packet before transmitting the first data packet based on having received the first data packet during the first delivery time window 518 before an upcoming delivery opportunity (e.g., the second delivery opportunity 522). UPF 502 may maintain the first data packet in the buffer for a hold time until a time when UPF 502 may deliver the first data packet (e.g., following an end time of the first delivery time window 556).

[0141] At 558, UPF 502 may deliver (e.g., transmit) the first data packet to data network 501, and data network 501 may receive the first data packet from UPF 502. UPF 502 may deliver the first data packet during a time interval that has been determined to be associated with second delivery opportunity 522. As shown, application 505 delivers the first data packet at the beginning of second delivery opportunity 518 after the end time of first delivery time window 522. Alternatively, UPF 502 may deliver (e.g., transmit) the first data packet during the end portion of first delivery time window 518 based on the packet delivery time window configuration.

[0142] At 562, following the PDB 560, the UE 115-b may identify a second data packet to be transmitted to the UPF 502. For example, the UE 115-b may receive the second data packet from the core network, the second data packet including information for the data network 501.

[0143] At 564, UE 115-b may transmit a second data packet to UPF 502 via base station 105-b, and UPF 502 may receive the second data packet from UE 115-b, as already identified at 562. As shown, UPF 502 receives the second data packet prior to third delivery opportunity 532, where third delivery opportunity 532 is based on the packet delivery time window configuration. In some cases, the second data packet may be a traffic type for which the packet delivery time window configuration may have been identified.

[0144] At 566, the base station 105-b may transmit an acknowledgment to the UE 115-b, and the UE 115-b may receive the acknowledgment from the base station 105-b. For example, the acknowledgment may indicate that the second data packet was successfully received at 564.

[0145] At 568, UPF 502 may delay transmission of the second data packet based on the packet delivery time window configuration and the second data packet having been received before the third delivery opportunity 532. In some cases, UPF 502 may buffer the second data packet, as may have been received at 564. In some cases, UPF 502 may buffer the second data packet before transmitting the second data packet based on having received the second data packet during the second delivery time window 523 before the upcoming delivery opportunity (e.g., the third delivery opportunity 532). UPF 502 may maintain the second data packet in the buffer for the hold time until a time when UPF 502 may deliver the second data packet (e.g., following the end time of the second delivery time window 523).

[0146] At 570, UPF 502 may deliver the second data packet to data network 501, and data network 501 may receive the second data packet from UPF 502. As shown, application 505 delivers the second data packet at the beginning of a third delivery opportunity 532 after the end time of second delivery time window 523.

[0147] At 572, UE 115-b may identify a third data packet to be transmitted to UPF 502. For example, UE 115-b may receive a third data packet 550 including information for data network 501 from the core network.

[0148] At 574, UE 115-b may transmit a third data packet to UPF 502 via base station 105-b, and UPF 502 may receive the third data packet from UE 115-b, as already identified at 572. In this example, the transmission of the third data packet may encounter interference or congestion, or may not be successfully received at UPF 502 to enable UPF 502 to decode sufficient information (e.g., based on a threshold) from the third data packet.

[0149] At 576, the base station 105-b may transmit a negative acknowledgement to the UE 115-b, and the UE 115-b may receive the negative acknowledgement from the base station 105-b. For example, the negative acknowledgement may indicate that the third data packet was not successfully received at 574.

[0150] At 578, UE 115-b may retransmit the third data packet to UPF 502 via base station 105-b, and UPF 502 may receive the third data packet from UE 115-b, as already identified at 572. UE 115-b may retransmit the third data packet based on receiving a negative acknowledgment from UPF 502 at 576. As shown, UPF 502 receives the third data packet before fourth delivery opportunity 542, where fourth delivery opportunity 542 is based on the packet delivery time window configuration. In some cases, the first data packet may be a traffic type for which the packet delivery time window configuration may have been identified.

[0151] At 580, UPF 502 may delay transmission of the third data packet based on the packet delivery time window configuration and the fact that the third data packet has been received before the fourth delivery opportunity 542. In some cases, UPF 502 may buffer the third data packet, as may have been received in the retransmission of 578. In some cases, UPF 502 may buffer the third data packet before transmitting the third data packet based on the fact that the third data packet has been received during the third delivery time window 533 before the upcoming delivery opportunity (e.g., the fourth delivery opportunity 542). UPF 502 may maintain the third data packet in the buffer for the retention time until the moment when UPF 502 can deliver the third data packet (e.g., following the end time of the third delivery time window 533). As shown in this example, since UPF 502 receives the third data packet in the retransmission of 578, the retention time of the third data packet is relatively shorter than the retention times of the first, second, and fourth data packets.

[0152] At 582, UPF 502 may deliver the third data packet to data network 501, and data network 501 may receive the third data packet from UPF 502. As shown, application 505 delivers the third data packet at the beginning of fourth delivery opportunity 542 after the end time of third delivery time window 533.

[0153] At 584, UE 115-b may identify a fourth data packet to be transmitted to UPF 502. For example, UE 115-b may receive a fourth data packet from the core network, the fourth data packet including information for data network 501. In this example, for a fourth time period 540, UE 115-b may receive the fourth data packet relatively earlier than other data packets. As shown, UE 115-b identifies the fourth data packet during a time period overlapping with third time period 530.

[0154] At 586, UE 115-b may transmit a fourth data packet to UPF 502 via base station 105-b, and UPF 502 may receive the fourth data packet from UE 115-b, as already identified at 584. Because, in this example, the fourth data packet was received earlier, UPF 502 receives the fourth data packet during fourth delivery time window 543. Since UPF 502 receives the fourth data packet during fourth delivery time window 543 and not during a delivery opportunity, UPF 502 may not deliver the fourth data packet to data network 501.

[0155] At 588, the base station 105-b may transmit an acknowledgment to the UE 115-b, and the UE 115-b may receive the acknowledgment from the base station 105-b. For example, the acknowledgment may indicate that the fourth data packet was successfully received at 586.

[0156] At 590, UPF 502 may buffer the fourth data packet, as may have been received at 588. UPF 502 may hold the fourth data packet in the buffer for the hold time until a time when UPF 502 may deliver the second data packet. However, in this example, since UPF 502 receives the fourth data packet during the fourth delivery time window 543 and not during the delivery opportunity, UPF 502 may not deliver the fourth data packet to data network 501. In this case, UPF 502 may, for example, drop the fourth data packet to clear the packet from the buffer.

[0157] At 592, UPF 502 may not deliver the fourth data packet to data network 501. In this example, UPF 502 receives the fourth data packet during fourth delivery time window 543 but not during the delivery opportunity, and therefore UPF 502 may not deliver the fourth data packet to data network 501. Therefore, data network 501 may not receive the fourth data packet at this time.

[0158] Figure 6 A block diagram 600 of a device 605 supporting a delivery time window for low latency communications according to aspects of the present disclosure is shown. The device 605 may be an example of aspects of a network entity as described herein. The device 605 may include a receiver 610, a communication manager 615, and a transmitter 620. The device 605 may also include a processor. Each of these components may be in communication with each other (e.g., via one or more buses).

[0159] Receiver 610 may receive information, such as packets, user data, or control information associated with various information channels (e.g., control channels, data channels, and information related to delivery time windows for low latency communications, etc.). The information may be passed to other components of device 605. Receiver 610 may be a reference Fig. 9 Examples of aspects of the transceiver 920 are described. The receiver 610 may utilize a single antenna or a collection of antennas.

[0160] The communication manager 615 may identify a packet delivery time window configuration for a communication of a traffic type; receive a data packet of the traffic type before a delivery opportunity based on the packet delivery time window configuration; delay transmission of the data packet based on the packet delivery time window configuration and receiving the data packet before the delivery opportunity; and transmit the data packet to a network device after delaying transmission and based on the delivery opportunity. The communication manager 615 may be an example of aspects of the communication manager 910 described herein.

[0161] The communication manager 615 or its subcomponents may be implemented in hardware, in code (e.g., software or firmware) executed by a processor, or any combination thereof. If implemented in code executed by a processor, the functions of the communication manager 615 or its subcomponents may be performed by a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device designed to perform the functions described in the present disclosure, discrete gate or transistor logic, discrete hardware components, or any combination thereof.

[0162] The communication manager 615 or its subcomponents may be physically located at various locations, including being distributed such that portions of functionality are implemented by one or more physical components at different physical locations. In some examples, according to various aspects of the present disclosure, the communication manager 615 or its subcomponents may be separate and distinct components. In some examples, according to various aspects of the present disclosure, the communication manager 615 or its subcomponents may be combined with one or more other hardware components (including, but not limited to, input / output (I / O) components, a transceiver, a network server, another computing device, one or more other components described in the present disclosure, or a combination thereof).

[0163] The transmitter 640 may transmit signals generated by other components of the device 605. In some examples, the transmitter 640 may be co-located with the receiver 610 in a transceiver module. For example, the transmitter 640 may be a reference Fig. 9 Examples of aspects of the transceiver 920 are described. The transmitter 640 may utilize a single antenna or a collection of antennas.

[0164] In some examples, the communication manager 615 may be implemented as an integrated circuit or chipset for a mobile device modem, and the receiver 610 and transmitter 620 may be implemented as analog components (e.g., amplifiers, filters, antennas) coupled to the mobile device modem to enable wireless transmission and reception on one or more frequency bands.

[0165] The communication manager 615 as described herein may be implemented to achieve one or more potential advantages. One implementation may allow the device 605 to support a delivery time window for low latency communications. The device 605 may identify a packet delivery window configuration and delay transmission for at least a portion of the corresponding delivery window. Such delays may improve reliability and reduce signaling overhead.

[0166] Based on the techniques for implementing delivery time windows supporting low latency communications as described herein, a processor of UE 115 (e.g., controlling receiver 610, transmitter 620, or a processor of UE 115) may be configured to: Fig. 9 The described transceiver 920) can improve reliability and reduce signaling overhead during delivery time windows with low latency communications because the UE 115 can avoid sending unnecessary transmissions.

[0167] Figure 7A block diagram 700 of a device 705 supporting a delivery time window for low latency communications according to aspects of the present disclosure is shown. The device 705 may be an example of aspects of the device 605 or a network entity as described herein. The device 705 may include a receiver 710, a communication manager 715, and a transmitter 740. The device 705 may also include a processor. Each of these components may be in communication with each other (e.g., via one or more buses).

[0168] Receiver 710 may receive information such as packets, user data, or control information associated with various information channels (e.g., control channels, data channels, and information related to delivery time windows for low latency communications, etc.). The information may be passed to other components of device 705. Receiver 710 may be a reference Fig. 9 Examples of aspects of the transceiver 920 are described. The receiver 710 may utilize a single antenna or a collection of antennas.

[0169] The communication manager 715 may be an example of aspects of the communication manager 615 as described herein. The communication manager 715 may include a delivery time window configuration manager 720, a data packet reception manager 725, a packet delivery time window configuration manager 730, and a data packet transmission manager 735. The communication manager 715 may be an example of aspects of the communication manager 910 as described herein.

[0170] Delivery time window configuration manager 720 may identify a packet delivery time window configuration for communications of a traffic type.

[0171] The data packet reception manager 725 may receive data packets of the traffic type prior to a delivery opportunity configured based on the packet delivery time window.

[0172] The packet delivery time window configuration manager 730 may delay transmission of the data packet based on the packet delivery time window configuration and receipt of the data packet prior to the delivery opportunity.

[0173] The data packet transmission manager 735 may transmit the data packet to the network device after delaying transmission and based on the delivery opportunity.

[0174] The transmitter 740 may transmit signals generated by other components of the device 705. In some examples, the transmitter 740 may be co-located with the receiver 710 in a transceiver module. For example, the transmitter 740 may be a reference Fig. 9 Examples of aspects of the transceiver 920 are described. The transmitter 740 may utilize a single antenna or a collection of antennas.

[0175] In some examples, the communication manager 715 may be implemented as an integrated circuit or chipset for a mobile device modem, and the receiver 710 and transmitter 740 may be implemented as analog components (e.g., amplifiers, filters, antennas) coupled to the mobile device modem to enable wireless transmission and reception on one or more frequency bands.

[0176] The communication manager 715 as described herein may be implemented to achieve one or more potential advantages. An implementation may allow the device 705 to support a delivery time window for low latency communications. The device 705 may identify a packet delivery window configuration and delay transmission for at least a portion of the corresponding delivery window. Such delays may improve reliability and reduce signaling overhead.

[0177] Based on the techniques for implementing delivery time windows supporting low latency communications as described herein, a processor of UE 115 (e.g., controlling receiver 710, transmitter 740, or Fig. 9 The described transceiver 920) can improve reliability and reduce signaling overhead during delivery time windows with low latency communications because the UE 115 can avoid sending unnecessary transmissions.

[0178] Figure 8 A block diagram 800 of a communication manager 805 supporting delivery time windows for low latency communications in accordance with aspects of the present disclosure is shown. The communication manager 805 may be an example of aspects of the communication manager 615, the communication manager 715, or the communication manager 910 described herein. The communication manager 805 may include a delivery time window configuration manager 810, a data packet reception manager 815, a packet delivery time window configuration manager 820, a data packet transmission manager 825, a radio protocol component 830, a delay budget manager 835, a buffer component 840, and an arrival window manager 845. Each of these modules may communicate directly or indirectly with each other (e.g., via one or more buses).

[0179] The delivery time window configuration manager 810 may identify a packet delivery time window configuration for a communication of a traffic type. In some examples, the delivery time window configuration manager 810 may determine a delivery time window based on the packet delivery time window configuration, wherein transmitting the data packet is based on the delivery time window. In some examples, a time interval associated with the delivery opportunity is determined based on an end time of the delivery time window, wherein transmitting the data packet includes.

[0180] In some examples, the delivery time window configuration manager 810 may receive from the radio access node an indication of the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, or the duration of the delivery time window, or any combination thereof, wherein determining the delivery time window is based on receiving the indication.

[0181] In some examples, the delivery time window configuration manager 810 may determine the delivery opportunity based on the delay budget, wherein transmitting the data packet is based on determining the delivery opportunity. In some examples, the delivery time window configuration manager 810 may determine a delivery time window for communications of the traffic type based on the delay budget, wherein transmitting the data packet is based on the delivery time window. In some cases, the packet delivery time window configuration indicates: the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, or the duration of the delivery time window, or any combination thereof.

[0182] The data packet receiving manager 815 may receive the data packet of the traffic type before a delivery opportunity configured based on the packet delivery time window. In some examples, the data packet receiving manager 815 may receive the data packet within the delivery time window.

[0183] The packet delivery time window configuration manager 820 may delay transmission of the data packet based on the packet delivery time window configuration and receiving the data packet before the delivery opportunity. In some examples, the packet delivery time window configuration manager 820 may determine the delivery opportunity based on the end duration of the packet arrival window, wherein transmitting the data packet is based on determining the delivery opportunity.

[0184] The data packet transmission manager 825 may transmit the data packet to the network device after the delayed transmission and based on the delivery opportunity. In some examples, the data packet transmission manager 825 may transmit the data packet within the time interval of the delivery opportunity. In some examples, the data packet transmission manager 825 may transmit the data packet within a delivery window in a delivery window set associated with the communication of the traffic type. In some examples, the data packet transmission manager 825 may transmit the data packet during the end portion of the delivery window based on the packet delivery time window configuration. In some examples, the data packet transmission manager 825 may transmit the data packet before or after the delivery opportunity.

[0185] The radio protocol component 830 may receive the indication via a radio protocol message.

[0186] The delay budget manager 835 may determine a delay budget associated with communications of the traffic type.

[0187] The buffering component 840 can buffer the data packet prior to transmission based on receiving the data packet prior to the delivery opportunity.

[0188] The arrival window manager 845 may identify a packet arrival window associated with the network device. In some examples, the arrival window manager 845 may receive a packet arrival time window configuration indicating at least one of a UPF packet arrival time window configuration, a radio access network (RAN) packet arrival time window configuration, or a UE packet arrival time window configuration, wherein determining the delivery opportunity is based on receiving the packet arrival time window configuration. In some examples, the arrival window manager 845 may determine the delivery opportunity based on a packet arrival time associated with the network device and a delay budget for communications of the traffic type, wherein transmitting the data packet is based on determining the delivery opportunity.

[0189] Fig. 9 A diagram of a system 900 including a device 905 supporting a delivery time window for low latency communications according to aspects of the present disclosure is shown. The device 905 may be an example of or include components of a device 605, a device 705, or a network entity as described herein. The device 905 may include components for two-way voice and data communications, including components for transmitting and receiving communications, including a communication manager 910, an I / O controller 915, a transceiver 920, an antenna 925, a memory 930, and a processor 935. These components may be in electronic communication via one or more buses (e.g., bus 945).

[0190] The communication manager 910 may identify a packet delivery time window configuration for communications of a certain traffic type; receive a data packet of the traffic type before a delivery opportunity based on the packet delivery time window configuration; delay transmission of the data packet based on the packet delivery time window configuration and receipt of the data packet before the delivery opportunity; and transmit the data packet to a network device after delayed transmission and based on the delivery opportunity.

[0191] I / O controller 915 can manage input and output signals of device 905. I / O controller 915 can also manage peripheral devices that are not integrated into device 905. In some cases, I / O controller 915 can represent a physical connection or port to an external peripheral device. In some cases, I / O controller 915 can utilize an operating system, such as Or another known operating system. In other cases, I / O controller 915 may represent or interact with a modem, keyboard, mouse, touch screen, or similar device. In some cases, I / O controller 915 may be implemented as part of a processor. In some cases, a user may interact with device 905 via I / O controller 915 or via hardware components controlled by I / O controller 915.

[0192] The transceiver 920 may communicate bidirectionally via one or more antennas, wired or wireless links, as described herein. For example, the transceiver 920 may represent a wireless transceiver and may communicate bidirectionally with another wireless transceiver. The transceiver 920 may also include a modem to modulate packets and provide the modulated packets to an antenna for transmission, and demodulate packets received from an antenna.

[0193] In some cases, a wireless device may include a single antenna 925. However, in some cases, the device may have more than one antenna 925, which may be capable of transmitting or receiving multiple wireless transmissions concurrently.

[0194] The memory 930 may include random access memory (RAM) and read-only memory (ROM). The memory 930 may store computer-readable, computer-executable code 940 including instructions that, when executed, cause the processor to perform the various functions described herein. In some cases, the memory 930 may contain a basic input / output system (BIOS), etc., which may control basic hardware or software operations, such as interaction with peripheral components or devices.

[0195] The processor 935 may include an intelligent hardware device (e.g., a general purpose processor, a DSP, a central processing unit (CPU), a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, the processor 935 may be configured to operate a memory array using a memory controller. In other cases, the memory controller may be integrated into the processor 935. The processor 935 may be configured to execute computer-readable instructions stored in a memory (e.g., memory 930) to cause the device 905 to perform various functions (e.g., functions or tasks that support a delivery time window for low latency communications).

[0196] The code 940 may include instructions for implementing various aspects of the present disclosure, including instructions for supporting wireless communications. The code 940 may be stored in a non-transitory computer-readable medium, such as a system memory or other type of memory. In some cases, the code 940 may not be directly executed by the processor 935, but may cause a computer (e.g., when compiled and executed) to perform the functions described herein.

[0197] Fig.10 A flow chart illustrating a method 1000 for supporting a delivery time window for low latency communications according to aspects of the present disclosure is shown. The operations of the method 1000 may be implemented by a network entity or component thereof as described herein. For example, the operations of the method 1000 may be implemented by a network entity or component thereof as described with reference to Figures 6 to 9 In some examples, a network entity may execute an instruction set to control functional elements of the network entity to perform the functions described herein. Additionally or alternatively, a network entity may use dedicated hardware to perform various aspects of the functions described herein.

[0198] At 1005, the network entity may identify a packet delivery time window configuration for communications of a traffic type. The operations of 1005 may be performed according to the methods described herein. In some examples, aspects of the operations of 1005 may be performed as described with reference to Figures 6 to 9 The described delivery time windows are configured to be executed by the manager.

[0199] At 1010, the network entity may receive a data packet of the traffic type prior to a delivery opportunity configured based on the packet delivery time window. The operations of 1010 may be performed according to the methods described herein. In some examples, aspects of the operations of 1010 may be performed as described with reference to Figures 6 to 9 The described data packet reception manager is executed.

[0200] At 1015, the network entity may delay transmission of the data packet based on the packet delivery time window configuration and receiving the data packet before the delivery opportunity. The operations of 1015 may be performed according to the methods described herein. In some examples, aspects of the operations of 1015 may be performed as described with reference to Figures 6 to 9 The described packet delivery time window configuration manager is implemented.

[0201] At 1020, the network entity may transmit the data packet to the network device after delaying the transmission and based on the delivery opportunity. The operations of 1020 may be performed according to the methods described herein. In some examples, aspects of the operations of 1020 may be performed as described with reference to Figures 6 to 9 The described data packet transfer manager is executed.

[0202] In a wireless communication system (e.g., carrying TSN communications), QoS requirements for a particular QoS flow can define a target PDB. The target PDB can set a target latency or total time delay for communications between a UE and a core network of the wireless communication system, at which data packets communicated can be used. In the case of downlink transmission, the PDB may include a first delay component incurred between the core network. The PDB may also include a second delay component incurred between a base station and the UE. In general, this total PDB defines the target latency from the UPF via the base station to the UE. In the case of uplink transmission, the PDB may similarly define a target latency from the UE via the base station to the UPF or SMF. If the total delay in conveying a data packet exceeds the total PDB defined by the PDB configuration, the data packet may not be used and may be ignored.

[0203] However, in some cases, jitter in a wireless communication system may cause changes in the total delay of communications between UEs, base stations, UPFs, and other devices in the wireless communication system. In some cases, jitter may cause a receiving device (e.g., a UE or another device within a wireless communication system) to receive a transmission before it is expected to be received. However, a transmission received in advance may be received during a packet delivery window, for which the receiving device delays data transmission until the end of the packet delivery window. Therefore, transmissions received in advance due to jitter may result in a transmission queue to be transmitted at the end of the packet delivery window. This may reduce the efficiency with which these transmissions can be communicated (e.g., utilization of time and frequency resources).

[0204] Accordingly, method 1000 provides a technique for determining or receiving signaling including a packet delivery time window configuration at a receiving device, the packet delivery time window configuration indicating a delivery window in which a transmission may be retained and / or a delivery opportunity in which a communication is expected to be transmitted. For example, the device may identify a packet delivery time window configuration for communication with another device. Based on the identified packet delivery time window configuration, the device may delay the transmission of the data packet for the duration of one or more configured delivery windows. For example, when a device receives a data packet within the duration of one of the delivery windows, the device may delay the data packet for the duration of the corresponding delivery window. For example, at the end of the corresponding delivery window, the device may deliver the data packet to a network device that is to use the information of the data packet (e.g., a UE may deliver a retained data packet containing application data from a model of the UE to a corresponding application of the UE). By retaining these data packets for the duration of the delivery window and transmitting the data packets during the transmission opportunity, the UE may set a consistent time period for transmitting the data packets, thereby reducing jitter in the system.

[0205] Fig.11A flow chart illustrating a method 1100 for supporting a delivery time window for low latency communications according to aspects of the present disclosure is shown. The operations of the method 1100 may be implemented by a network entity or component thereof as described herein. For example, the operations of the method 1100 may be implemented by a network entity or component thereof as described with reference to Figures 6 to 9 In some examples, a network entity may execute an instruction set to control functional elements of the network entity to perform the functions described herein. Additionally or alternatively, a network entity may use dedicated hardware to perform various aspects of the functions described herein.

[0206] At 1105, the network entity may identify a packet delivery time window configuration for communications of a traffic type. The operations of 1105 may be performed according to the methods described herein. In some examples, aspects of the operations of 1105 may be performed as described with reference to Figures 6 to 9 The described delivery time windows are configured to be executed by the manager.

[0207] At 1110, the network entity may receive data packets of the traffic type before a delivery opportunity configured based on the packet delivery time window. The operations of 1110 may be performed according to the methods described herein. In some examples, aspects of the operations of 1110 may be performed as described with reference to Figures 6 to 9 The described data packet reception manager is executed.

[0208] At 1115, the network entity may determine a delivery time window based on the packet delivery time window configuration, wherein transmitting the data packet is based on the delivery time window. The operations of 1115 may be performed according to the methods described herein. In some examples, aspects of the operations of 1115 may be performed as described with reference to Figures 6 to 9 The described delivery time windows are configured to be executed by the manager.

[0209] At 1120, the network entity may delay transmission of the data packet based on the packet delivery time window configuration and receiving the data packet before the delivery opportunity. The operations of 1120 may be performed according to the methods described herein. In some examples, aspects of the operations of 1120 may be performed as described with reference to Figures 6 to 9 The described packet delivery time window configuration manager is implemented.

[0210] At 1125, the network entity may transmit the data packet to the network device after delaying the transmission and based on the delivery opportunity. The operations of 1125 may be performed according to the methods described herein. In some examples, aspects of the operations of 1125 may be performed as described with reference to Figures 6 to 9 The described data packet transfer manager is executed.

[0211] In a wireless communication system (e.g., carrying TSN communications), the QoS requirements for a specific QoS flow can define a target PDB. The target PDB can set a target latency or total time delay for communications between a UE and a core network of the wireless communication system, and the data packets communicated under this target latency or total time delay can be used. In the case of downlink transmission, the PDB may include a first delay component incurred between the core network. The PDB may also include a second delay component incurred between the base station and the UE. In general, this total PDB defines the target latency from the UPF via the base station to the UE. In the case of uplink transmission, the PDB can similarly define the target latency from the UE via the base station to the UPF or SMF. If the total delay of the communication data packet exceeds the total PDB defined by the PDB configuration, the data packet may not be used and may be ignored.

[0212] However, in some cases, jitter in a wireless communication system may cause changes in the total delay of communications between UEs, base stations, UPFs, and other devices in the wireless communication system. In some cases, jitter may cause a receiving device (e.g., a UE or another device within a wireless communication system) to receive a transmission before it is expected to be received. However, a transmission received in advance may be received during a packet delivery window, for which the receiving device delays data transmission until the end of the packet delivery window. Therefore, transmissions received in advance due to jitter may result in a transmission queue to be transmitted at the end of the packet delivery window. This may reduce the efficiency of conveying these transmissions (e.g., utilization of time and frequency resources).

[0213] Accordingly, method 1000 provides a technique for determining or receiving signaling including a packet delivery time window configuration at a receiving device, the packet delivery time window configuration indicating a delivery window in which a transmission may be retained and / or a delivery opportunity in which a communication is expected to be transmitted. For example, the device may identify a packet delivery time window configuration for communicating with another device. Based on the identified packet delivery time window configuration, the device may delay the transmission of the data packet for the duration of one or more configured delivery windows. For example, when a device receives a data packet within the duration of one of the delivery windows, the device may delay the data packet for the duration of the corresponding delivery window. For example, at the end of the corresponding delivery window, the device may deliver the data packet to a network device that is to use the information of the data packet (e.g., a UE may deliver a retained data packet containing application data from a model of the UE to a corresponding application of the UE). By retaining these data packets for the duration of the delivery window and transmitting the data packets during the transmission opportunity, the UE may set a consistent time period for transmitting these data packets, thereby reducing jitter in the system.

[0214] Fig.12A flow chart illustrating a method 1200 for supporting a delivery time window for low latency communications according to aspects of the present disclosure is shown. The operations of the method 1200 may be implemented by a network entity or component thereof as described herein. For example, the operations of the method 1200 may be implemented by a network entity or component thereof as described with reference to Figures 6 to 9 In some examples, a network entity may execute an instruction set to control functional elements of the network entity to perform the functions described herein. Additionally or alternatively, a network entity may use dedicated hardware to perform various aspects of the functions described herein.

[0215] At 1205, the network entity may identify a packet delivery time window configuration for communications of a traffic type. The operations of 1205 may be performed according to the methods described herein. In some examples, aspects of the operations of 1205 may be performed as described with reference to Figures 6 to 9 The described delivery time windows are configured to be executed by the manager.

[0216] At 1210, the network entity may receive a data packet of the traffic type prior to a delivery opportunity configured based on the packet delivery time window. The operations of 1210 may be performed according to the methods described herein. In some examples, aspects of the operations of 1210 may be performed as described with reference to Figures 6 to 9 The described data packet reception manager is executed.

[0217] At 1215, the network entity may delay transmission of the data packet based on the packet delivery time window configuration and receiving the data packet before the delivery opportunity. The operations of 1215 may be performed according to the methods described herein. In some examples, aspects of the operations of 1215 may be performed as described with reference to Figures 6 to 9 The described packet delivery time window configuration manager is implemented.

[0218] At 1220, the network entity may buffer the data packet prior to transmission based on receiving the data packet prior to the delivery opportunity. The operations of 1220 may be performed according to the methods described herein. In some examples, aspects of the operations of 1220 may be performed as described with reference to Figures 6 to 9 The described buffer component is implemented.

[0219] At 1225, the network entity may transmit the data packet to the network device after delaying the transmission and based on the delivery opportunity. The operations of 1225 may be performed according to the methods described herein. In some examples, aspects of the operations of 1225 may be performed as described with reference to Figures 6 to 9 The described data packet transfer manager is executed.

[0220] In a wireless communication system (e.g., carrying TSN communications), QoS requirements for a particular QoS flow can define a target PDB. The target PDB can set a target latency or total time delay for communications between a UE and a core network of the wireless communication system, at which data packets communicated can be used. In the case of downlink transmission, the PDB may include a first delay component incurred between the core network. The PDB may also include a second delay component incurred between a base station and the UE. In general, this total PDB defines the target latency from the UPF via the base station to the UE. In the case of uplink transmission, the PDB may similarly define a target latency from the UE via the base station to the UPF or SMF. If the total delay when communicating a data packet exceeds the total PDB defined by the PDB configuration, the data packet may not be used and may be ignored.

[0221] However, in some cases, jitter in a wireless communication system may cause changes in the total delay of communications between UEs, base stations, UPFs, and other devices in the wireless communication system. In some cases, jitter may cause a receiving device (e.g., a UE or another device within a wireless communication system) to receive a transmission before it is expected to be received. However, a transmission received in advance may be received during a packet delivery window, for which the receiving device delays data transmission until the end of the packet delivery window. Therefore, transmissions received in advance due to jitter may result in a transmission queue to be transmitted at the end of the packet delivery window. This may reduce the efficiency of conveying these transmissions (e.g., utilization of time and frequency resources).

[0222] Accordingly, method 1000 provides a technique for determining or receiving signaling including a packet delivery time window configuration at a receiving device, the packet delivery time window configuration indicating a delivery window in which a transmission may be retained and / or a delivery opportunity in which a communication is expected to be transmitted. For example, the device may identify a packet delivery time window configuration for communicating with another device. Based on the identified packet delivery time window configuration, the device may delay the transmission of the data packet for the duration of one or more configured delivery windows. For example, when a device receives a data packet within the duration of one of the delivery windows, the device may delay and buffer the data packet for the duration of the corresponding delivery window. For example, at the end of the corresponding delivery window, the device may deliver the data packet to a network device that is to use the information of the data packet (e.g., a UE may deliver a retained data packet containing application data from a model of the UE to a corresponding application of the UE). By buffering these data packets for the duration of the delivery window and transmitting the data packets during the transmission opportunity, the UE may set a consistent time period for transmitting these data packets, thereby reducing jitter in the system.

[0223] It should be noted that the methods described herein describe possible implementations, and that the various operations and steps may be rearranged or otherwise modified and other implementations are possible. Furthermore, aspects from two or more methods may be combined.

[0224] The technology described herein can be used for various wireless communication systems, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA) and other systems. CDMA systems can implement radio technologies such as CDMA2000, Universal Terrestrial Radio Access (UTRA). CDMA2000 covers IS-2000, IS-95 and IS-856 standards. IS-2000 versions are generally referred to as CDMA2000 1X, 1X, etc. IS-856 (TIA-856) is generally referred to as CDMA2000 1xEV-DO, High Rate Packet Data (HRPD), etc. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. TDMA systems can implement radio technologies such as Global System for Mobile Communications (GSM).

[0225] OFDMA systems can implement radio technologies such as Ultra Mobile Broadband (UMB), Evolved UTRA (E-UTRA), Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunications System (UMTS). LTE, LTE-A, and LTE-A Pro are versions of UMTS that use E-UTRA. UTRA, E-UTRA, UMTS, LTE, LTE-A, LTE-A Pro, NR, and GSM are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). CDMA2000 and UMB are described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2). The techniques described herein may be used for systems and radio technologies mentioned herein as well as for other systems and radio technologies. Although aspects of LTE, LTE-A, LTE-A Pro, or NR systems may be described for example purposes and LTE, LTE-A, LTE-A Pro, or NR terminology may be used in much of the description, the techniques described herein may also be applicable to applications other than LTE, LTE-A, LTE-A Pro, or NR applications.

[0226] A macro cell generally covers a relatively large geographic area (e.g., an area of ​​several kilometers in radius) and may allow unrestricted access by UEs 115 that have service subscriptions with a network provider. A small cell may be associated with a lower power base station 105 (compared to a macro cell), and the small cell may operate in the same or different (e.g., licensed, unlicensed, etc.) frequency band as the macro cell. According to various examples, a small cell may include a pico cell, a femto cell, and a micro cell. A pico cell, for example, may cover a smaller geographic area and may allow unrestricted access by UEs 115 that have service subscriptions with a network provider. A femto cell may also cover a smaller geographic area (e.g., a residence) and may provide restricted access by UEs 115 associated with the femto cell (e.g., UEs 115 in a closed subscriber group (CSG), UEs 115 of users in a residence, etc.). An eNB for a macro cell may be referred to as a macro eNB. An eNB for a small cell may be referred to as a small cell eNB, a pico eNB, a femto eNB, or a home eNB. An eNB may support one or more (eg, two, three, four, etc.) cells and may also support communication using one or more component carriers.

[0227] One or more wireless communication systems 100 described herein may support synchronous or asynchronous operation. For synchronous operation, the base stations 105 may have similar frame timing, and transmissions from different base stations 105 may be approximately aligned in time. For asynchronous operation, the base stations 105 may have different frame timing, and transmissions from different base stations 105 may not be aligned in time. The techniques described herein may be used for synchronous or asynchronous operation.

[0228] The information and signals described herein may be represented using any of a variety of different techniques and technologies. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referred to throughout this description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0229] The various illustrative blocks and modules described in conjunction with the disclosure herein may be implemented or executed with a general purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).

[0230] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted by a computer-readable medium as one or more instructions or codes. Other examples and implementations fall within the scope of the present disclosure and the appended claims. For example, due to the nature of software, the functions described herein may be implemented using software executed by a processor, hardware, firmware, hardwiring, or any combination thereof. Features that implement the functions may also be physically located in various locations, including being distributed so that parts of the functions are implemented at different physical locations.

[0231] Computer readable medium includes both non-transient computer storage medium and communication medium, and it includes any medium that facilitates computer program to transfer from one place to another place.Non-transient storage medium can be any available medium that can be accessed by general or special-purpose computer.As an example and not limitation, non-transient computer readable medium can include RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory, compact disk (CD) ROM or other optical disk storage, disk storage or other magnetic storage device, or can be used to carry or store instruction or data structure form of desired program code means and can be accessed by general or special-purpose computer or general or special-purpose processor any other non-transient medium.Any connection is also properly referred to as computer readable medium.For example, if software is transmitted from website, server or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technology such as infrared, radio and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL or wireless technology such as infrared, radio and microwave are just included in the definition of medium. Disk and disc as used herein include CDs, laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.

[0232] As used herein (including in the claims), "or" used in a list of items (e.g., a list of items with a phrase such as "at least one of" or "one or more of") indicates an inclusive list, so that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Similarly, as used herein, the phrase "based on" should not be interpreted as referring to a closed set of conditions. For example, an exemplary step described as "based on condition A" may be based on both condition A and condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase "based on" should be interpreted in the same manner as the phrase "based at least in part on."

[0233] In the accompanying drawings, similar components or features may have the same reference number. In addition, various components of the same type may be distinguished by following the reference number with a dash and a second reference number that distinguishes between similar components. If only the first reference number is used in the specification, the description may apply to any of the similar components having the same first reference number regardless of the second reference number, or other subsequent reference numbers.

[0234] The descriptions set forth herein in conjunction with the accompanying drawings describe example configurations and do not represent all examples that may be implemented or that fall within the scope of the claims. The term "exemplary" as used herein means "used as an example, instance, or illustration" and does not mean "better than" or "better than other examples." This detailed description includes specific details to provide an understanding of the described techniques. However, these techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form to avoid obscuring the concepts of the described examples.

[0235] The description herein is provided to enable those skilled in the art to make or use the present disclosure. Various modifications to the present disclosure will be apparent to those skilled in the art, and the universal principles defined herein may be applied to other variations without departing from the scope of the present disclosure. Thus, the present disclosure is not limited to the examples and designs described herein, but should be granted the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for wireless communication, comprising: identifying a packet delivery time window configuration for communications of a traffic type; determining a delivery time window based at least in part on the packet delivery time window configuration; receiving data packets of the traffic type during the delivery time window and prior to a delivery opportunity configured based at least in part on the packet delivery time window; determining a time interval associated with the delivery opportunity based at least in part on an end time of the delivery time window; delaying transmission of the data packet based at least in part on the packet delivery time window configuration and receipt of the data packet prior to the delivery opportunity and during the delivery time window; as well as The data packet is transmitted to a network device after delaying transmission and based at least in part on a time interval associated with the delivery opportunity.

2. A method as claimed in claim 1, wherein the packet delivery time window configuration indicates: the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, or the duration of the delivery time window or any combination thereof.

3. The method of claim 1, further comprising: Receiving from a radio access node an indication of the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, or the duration of the delivery time window, or any combination thereof, wherein determining the delivery time window is based at least in part on receiving the indication.

4. The method of claim 3, wherein receiving the indication comprises: The indication is received via a radio protocol message.

5. The method of claim 1 , wherein transmitting the data packet comprises: The data packet is transmitted within a time interval of the delivery opportunity.

6. The method of claim 5, wherein transmitting the data packet comprises: The data packet is transmitted within a delivery window in a set of delivery windows associated with communications of the traffic type.

7. The method of claim 5, wherein transmitting the data packet comprises: The data packet is transmitted during an end portion of a delivery window based at least in part on the packet delivery time window configuration.

8. The method of claim 1, wherein transmitting the data packet comprises: The data packet is transmitted before or after the delivery opportunity.

9. The method of claim 1, further comprising: determining a delay budget associated with communications of the traffic type; as well as The delivery opportunity is determined based at least in part on the delay budget, wherein transmitting the data packet is based at least in part on determining the delivery opportunity.

10. The method of claim 9, further comprising: The delivery time window for communications of the traffic type is determined based at least in part on the delay budget, wherein transmitting the data packet is based at least in part on the delivery time window.

11. The method of claim 1 , wherein delaying transmission of the data packet comprises: The data packets are buffered prior to transmission based at least in part on receiving the data packets prior to the delivery opportunity.

12. The method of claim 1, further comprising: identifying a packet arrival window associated with the network device; as well as The delivery opportunity is determined based at least in part on an end duration of the packet arrival window, wherein transmitting the data packet is based at least in part on determining the delivery opportunity.

13. The method of claim 12, further comprising: Receiving a packet arrival time window configuration indicative of at least one of a user plane function (UPF) packet arrival time window configuration or a user equipment (UE) packet arrival time window configuration, wherein determining the delivery opportunity is based at least in part on receiving the packet arrival time window configuration.

14. The method of claim 1, further comprising: The delivery opportunity is determined based at least in part on packet arrival times associated with the network device and a delay budget for communications of the traffic type, wherein transmitting the data packet is based at least in part on determining the delivery opportunity.

15. The method of claim 1, wherein transmitting the data packet to the network comprises: The data is transmitted by the user equipment UE to the network device including the user plane function UPF.

16. An apparatus for wireless communication, comprising: processor, a memory coupled to the processor and storing instructions executable by the processor to cause the apparatus to: identifying a packet delivery time window configuration for communications of a traffic type; determining a delivery time window based at least in part on the packet delivery time window configuration; receiving data packets of the traffic type during the delivery time window and prior to a delivery opportunity configured based at least in part on the packet delivery time window; determining a time interval associated with the delivery opportunity based at least in part on an end time of the delivery time window; delaying transmission of the data packet based at least in part on the packet delivery time window configuration and receipt of the data packet prior to the delivery opportunity and during the delivery time window; as well as The data packet is transmitted to a network device after delaying transmission and based at least in part on a time interval associated with the delivery opportunity.

17. An apparatus as claimed in claim 16, wherein the packet delivery time window configuration indicates: the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, or the duration of the delivery time window or any combination thereof.

18. The apparatus of claim 16, wherein the instructions are further executable by the processor to cause the apparatus to: Receiving from a radio access node an indication of the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, or the duration of the delivery time window, or any combination thereof, wherein determining the delivery time window is based at least in part on receiving the indication.

19. The apparatus of claim 16, wherein the instructions for transmitting the data packet are executable by the processor to cause the apparatus to: The data packet is transmitted within a time interval of the delivery opportunity.

20. The apparatus of claim 16, wherein the instructions are further executable by the processor to cause the apparatus to: identifying a packet arrival window associated with the network device; and The delivery opportunity is determined based at least in part on an end duration of the packet arrival window, wherein transmitting the data packet is based at least in part on determining the delivery opportunity.

21. The apparatus of claim 20, wherein the instructions are further executable by the processor to cause the apparatus to: Receiving a packet arrival time window configuration indicative of at least one of a user plane function (UPF) packet arrival time window configuration or a user equipment (UE) packet arrival time window configuration, wherein determining the delivery opportunity is based at least in part on receiving the packet arrival time window configuration.

22. The apparatus of claim 16, wherein the apparatus comprises a user equipment (UE).

23. A non-transitory computer readable medium storing code for wireless communication, the code comprising instructions executable by a processor to: identifying a packet delivery time window configuration for communications of a traffic type; determining a delivery time window based at least in part on the packet delivery time window configuration; receiving data packets of the traffic type during the delivery time window and prior to a delivery opportunity configured based at least in part on the packet delivery time window; determining a time interval associated with the delivery opportunity based at least in part on an end time of the delivery time window; delaying transmission of the data packet based at least in part on the packet delivery time window configuration and receipt of the data packet prior to the delivery opportunity and during the delivery time window; as well as The data packet is transmitted to a network device after delaying transmission and based at least in part on a time interval associated with the delivery opportunity.

24. A device for wireless communication, comprising: means for identifying a packet delivery time window configuration for communications of a traffic type; means for determining a delivery time window based at least in part on the packet delivery time window configuration; means for receiving data packets of the traffic type during the delivery time window and prior to a delivery opportunity configured based at least in part on the packet delivery time window; means for determining a time interval associated with the delivery opportunity based at least in part on an end time of the delivery time window; means for delaying transmission of the data packet based at least in part on the packet delivery time window configuration and receipt of the data packet prior to the delivery opportunity and during the delivery time window; as well as Means for transmitting the data packet to a network device after delaying transmission and based at least in part on a time interval associated with the delivery opportunity.

25. An apparatus as claimed in claim 24, wherein the packet delivery time window configuration indicates: the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, or the duration of the delivery time window or any combination thereof.

26. The apparatus of claim 24, further comprising: A device for receiving from a radio access node an indication of the periodicity of the delivery time window, the start time of the delivery time window, the end time of the delivery time window, the offset of the delivery time window relative to time, or the duration of the delivery time window, or any combination thereof, wherein determining the delivery time window is based at least in part on receiving the indication.

27. The apparatus of claim 24, wherein the means for transmitting the data packet further comprises: Means for transmitting the data packet within a time interval of the delivery opportunity.

28. The apparatus of claim 24, further comprising: means for identifying a packet arrival window associated with said network device; as well as Means for determining the delivery opportunity based at least in part on an end duration of the packet arrival window, wherein transmitting the data packet is based at least in part on determining the delivery opportunity.

29. The apparatus of claim 28, further comprising: A device for receiving a packet arrival time window configuration indicating at least one of a user plane function (UPF) packet arrival time window configuration or a user equipment (UE) packet arrival time window configuration, wherein determining the delivery opportunity is at least partially based on receiving the packet arrival time window configuration.

30. The apparatus of claim 24, wherein the apparatus comprises user equipment (UE).

Images