Time-to-live data transfer in wireless communication system

Abstract

Embodiments of the present disclosure provide a method (300) performed by a network node (204) for transmitting data packets to a wireless device (202). The method (300) includes obtaining (302) a packet delay budget (PDB), wherein the PDB represents a maximum allowable delay for a data packet. The method (300) comprises determining (304) a total delay time interval indicating a delay caused by an estimated number of consecutive data packets transmitted from the network node (204) to the wireless device (202). The method (300) comprises transmitting (308) the data packet to the wireless device (202) based on whether the determined total delay time interval exceeds the obtained PDB. A corresponding network node and computer program product are also disclosed.

Description

Technical Field

[0001] The present disclosure relates to wireless communication systems. More particularly, the present invention relates to methods, network nodes and computer program products for transmitting data in a wireless communication system. Background Art

[0002] Wireless connectivity is a key requirement to support industrial development and its mission-critical industrial activities as well as less critical communication needs. Wireless connectivity supports emerging technology tools and their applications such as digital twins, smart workspaces, smart robots, virtual assistants, etc.

[0003] The main drivers for wireless connectivity are:

[0004] Replace (or avoid) cables that are expensive to deploy and maintain / troubleshoot;

[0005] Connecting parts of a machine or equipment that would be impossible or impractical to connect by wire (e.g., fast-moving parts);

[0006] Preventive maintenance and big data analytics by connecting a large number of sensors; and

[0007] Further increase industry expectations for the realization of 5G technology as a means of achieving economies of scale in operational technology.

[0008] The wireless connectivity requirements for manufacturing use cases are very diverse. Today, most of the identified industrial automation use cases are connected via fixed industrial networks. Typical use cases in industrial automation are motion control, robotic control, production lines and process control. Current wireless connectivity use cases are usually less important compared to monitoring and parameterization. In an automotive factory, the business mainly consists of real-time business, which is carried by protocols with a highly integrated protocol stack, such as for example the Profmet real-time stack. The Transmission Control Protocol / Internet Protocol TCP / IP protocol stack is mainly used to carry messages related to startup configuration, notifications and non-critical alarm messages; together with preventive monitoring. Therefore, the wireless connectivity requirements are very use case and application specific.

[0009] The expected latency will be the main deciding factor as to whether a use case can be deployed using LTE or whether NR is required. Having a guaranteed upper bound on latency is also essential for critical automation use cases, as packets need to arrive on time or they are considered lost.

[0010] Mobile broadband (MBB) is the use case that mobile operators make money on, and therefore the use case that they optimize their networks for, and the use case that their vendors optimize their products for.

[0011] MBB services are mainly video and web services. MBB services require excellent network performance, which is a very important factor in customer satisfaction. However, there are no strict quality of service (QoS) requirements associated with MBB services. Applications (and consumers) that support MBB services are adaptive and can generally tolerate changes in network performance.

[0012] Most MBB services are carried via transport protocols (such as TCP) with reliable message transmission. This means that packet loss is usually visible to applications only as a reduction in network throughput. Applications dynamically adapt to such throughput changes. Therefore, MBB services do not have strict requirements on packet loss, but rather have soft requirements for providing a good end-user experience. Similarly, there are no strict network latency requirements associated with MBB services. Although there is a relationship between latency and TCP throughput, jitter is usually tolerable. However, packet loss has a greater negative impact on TCP throughput than jitter. In this way, 3GPP systems use network-internal retransmissions (such as, for example, hybrid automatic repeat request HARQ retransmissions) to deliver packets without any upper bound on latency.

[0013] In contrast to the applications supported by MBB (i.e., MBB applications), many industrial applications involve non-adaptive control systems with strict network performance requirements. Some of these industrial applications consider the communication system / wireless communication system to be unavailable if the communication system does not meet the QoS required by the application. QoS in this article generally means the ability to successfully deliver packets within a specified upper delay budget (i.e., packet delay budget PDB). QoS requirements are generally expressed as a target reliability, which is calculated as a percentage value of the number of transmitted packets successfully delivered within the PDB required by the target application divided by the total number of transmitted packets.

[0014] In addition, the application may support a time to live. The time to live indicates the application's tolerance for unsuccessful packet delivery, which is determined in part by how many consecutive lost application packets the application can accept before performing one or more emergency actions (such as, for example, emergency shutdown and production stop). Thus, the time to live refers to the period of time during which the application can manage some packet loss without performing emergency actions. The time to live depends on the implementation of the application and varies widely between different industries and use cases, from 10 seconds down to 10 milliseconds, 1 millisecond, or even 0 milliseconds. 3GPP TR 22.804 discloses some examples.

[0015] For applications supporting time-to-live, the reliability requirement indicates a time-to-live window during which the desired QoS level must be met, ie at least one data packet must be successfully delivered within the time-to-live window.

[0016] For applications with a time to live equal to 0 ms, the reliability requirement (e.g., 1-1e-6) indicates a time to live window including the PDB during which the desired QoS level must be met. Retransmissions using the communication system (such as HARQ retransmissions) may be acceptable as long as the complete packet can be delivered with the PDB. If the communication system cannot deliver the packet in time, the application considers the packet lost and immediately considers the communication system unavailable without any time to live.

[0017] For applications with a lifetime greater than 0ms, the reliability requirement indicates a lifetime window that includes the sum of the PDB and application lifetimes, during which the desired QoS level must be met. Therefore, for applications with a lifetime greater than 0ms, there are not one but two reliability requirements to consider:

[0018] 1. The probability of each individual grouping failure (referred to as Pi)

[0019] 2. The probability of more than X consecutive packets being unsuccessful (denoted as Px), where X depends largely on the survival time.

[0020] If the probability of more than X consecutive packets being unsuccessful is, for example, 1e-6, then the probability of each individual packet being unsuccessful may be higher than this probability.

[0021] An application with a time to live greater than 0 ms may, for example, accept that one packet is not successfully delivered within a PDB, but if two consecutive packets are not successfully delivered, the application performs one or more emergency actions.

[0022] Figure 1 An example of how two different applications experience the same sequence of events is shown, wherein the application implemented in the user device sends application packets AG, but wherein the communication system cannot successfully deliver packets B, C, E, F and G to the user device in a timely manner. In the example shown, one application has a survival time equal to 0ms, while the other application has a survival time greater than 0ms. Once packet B is not successfully delivered, the application with a survival time equal to 0ms just considers the communication system to be unavailable. In this example, the application with a survival time greater than 0ms can tolerate two consecutive unsuccessful packets. However, if three consecutive packets are unsuccessful, the application considers the communication system to be unavailable. Therefore, the application with a survival time greater than 0ms still considers the communication system to be available when packet B is not successfully delivered and when packet C is not successfully delivered and then the delivery of packet D is successful. Therefore, even if packets B and C are lost, the application does not consider the communication system / service to be closed.

[0023] But when three consecutive packets, such as packets E, F, and G, are not successfully delivered to the user device, the application considers the communication system / service to be unavailable. Upon considering the communication system to be unavailable, the application performs one or more emergency actions. For example, in an industrial environment, upon considering the communication system to be unavailable, the application initiates an emergency shutdown of a production unit or production line, for example, to avoid damage to machinery, products, or injury to people.

[0024] Furthermore, the radio access network RAN ​​of the communication system comprises a scheduler feature, such as a RAN scheduler feature (also referred to as a scheduler), for allocating / scheduling radio interface and radio base station RBS resources between user and control data flows requesting to be transmitted in a cell. Thus, priority is provided for robust system control signaling and user data retransmissions. Furthermore, the radio interface and RBS resources are allocated such that users (also referred to as user devices, user equipment, UE, etc.) can be multiplexed and scheduled in time and frequency by efficiently using spectrum and hardware resources to optimize user throughput and cell capacity.

[0025] The scheduler dynamically performs scheduling, also known as dynamic resource allocation, for each 1 ms Transmission Time Interval TTI in a standard LTE system.For each upcoming TTI, the RAN determines the users to which the radio interface and RBS resources are assigned.

[0026] For more advanced LTE systems or systems involving NR technology, the TTI in question may be of varying size and be shorter than 1 ms.

[0027] The scheduler considers multiple inputs when determining at least one of the following: which users to schedule for the upcoming TTI, the amount of resources to allocate to each user, what transport block size to use for each user device, TBS and transport format, etc. Examples of inputs may include, but are not limited to, channel quality information CQI confirmation ACK or negative confirmation NACK reported by the user, the amount of data each user wants to transmit, available uplink UL / downlink DL bandwidth, bearer priority, QoS class identifier QCI, etc.

[0028] The main functionality of the scheduler is to maximize the number of users meeting QoS requirements and maximize spectrum / resource efficiency. The following set of scheduling algorithms are used to achieve this:

[0029] Round Robin Scheduling Algorithm: The scheduler allocates the same number of resource blocks to all users. This is simple, but it leads to very unfair resource allocation, where users at the edge of the cell get the same amount of resources as users in the center, resulting in huge differences in throughput.

[0030] Proportional Fair Scheduling Algorithm: This scheduler addresses the main drawback of the round-robin scheduler, which is fairness. The scheduler allocates resources to users based on a priority mechanism. The priority of a user is inversely proportional to the amount of data that the user could transmit in the previous communication phase. Scheduling based on the priority mechanism ensures that all users are treated fairly in terms of throughput and unallocated resources.

[0031] Delay-based scheduler: This scheduler is primarily designed for Voice over Internet Protocol VoIP services or conversational video services. Such services have the following characteristics: QoS may be significantly reduced when a packet exceeds its PDB, but even a faster arrival time than the PDB will not improve the QoS. The scheduler exploits the characteristics associated with VoIP services / conversational video services to enhance spectral efficiency in a hybrid scenario with both best-effort services and VoIP services. Best-effort service refers to an Internet delivery service in which the provider does not make any guarantees about when a packet will be delivered or the QoS of the packet when it is delivered. The scheduler allocates resources to the best-effort service before users using VoIP arrive at the PDB, and allocates resources to users using the VoIP service when their PDB is in danger of being violated. In this way, the scheduler is able to maximize the throughput of the best-effort service while protecting the PDB of the VoIP service.

[0032] In view of the above, the scheduler may allocate radio resources to users according to one or more of the following: a uniform allocation method (i.e., a round-robin scheduling algorithm), a priority mechanism, and a delay mechanism based on service characteristics. However, the scheduler does not consider certain reliability requirements associated with each packet when allocating radio resources for transmitting packets to users. Therefore, the aggregate reliability and robustness requirements may not be achieved over multiple transmissions of packets to users. This further increases continuous packet loss (i.e., unsuccessful delivery of continuous packets to users). Summary of the invention

[0033] Therefore, there is a need for an improved method and arrangement for performing data transfer to a wireless device by improving radio resource allocation which alleviates at least some of the above-mentioned problems.

[0034] It is therefore an object of the present disclosure to provide a method, a network node and a computer program product for performing transmission of data packets to a wireless device that mitigates, alleviates or eliminates all or at least some of the above-mentioned disadvantages of currently known solutions.

[0035] This and other objects are achieved by a method, a network node and a computer program product as defined in the appended claims.The term exemplary is herein to be understood as serving as an example, instance or illustration.

[0036] According to a first aspect of the present disclosure, there is provided a method for transmitting a data packet to a wireless device, performed by a network node. The method includes obtaining a packet delay budget (PDB), wherein the PDB represents a maximum allowed delay for a data packet. The method includes determining a total delay time interval, the total delay time interval indicating a delay caused by an estimated number of consecutive data packets transmitted from the network node to the wireless device. The method includes transmitting the data packet to the wireless device based on whether the determined total delay time interval exceeds the obtained PDB.

[0037] In some embodiments, the step of transmitting a data packet to a wireless device includes: when it is determined that the total delay time interval exceeds the PDB, selecting at least one transmission parameter for transmitting the data packet to the wireless device. The method includes adjusting a block error rate (BLER) of the data packet to a first BLER target according to the selected at least one transmission parameter. The method includes transmitting the data packet to the wireless device with the first BLER target.

[0038] In some embodiments, the transmission parameters include one or more of: a modulation and coding scheme MCS, a number of resource blocks, and a transmission power.

[0039] In some embodiments, the total delay time interval includes one or more of the following items: a scheduling delay indicating the difference between a scheduled time interval and an actual time interval for transmission of each data packet to the wireless device, a hybrid automatic repeat request HARQ round trip time RTT associated with the retransmission of each data packet to the wireless device, a delay associated with receiving an acknowledgment and a negative acknowledgment A / N from the wireless device, and a decoding delay indicating the time taken for a network node to decode the reception of the A / N.

[0040] In some embodiments, the step of transmitting a data packet to a wireless device includes: when determining that the total delay time interval does not exceed the PDB, determining a reliability requirement, the reliability requirement indicating a survival time window within which a quality of service QoS must be satisfied for transmitting the data packet to the wireless device. The method includes determining a second BLER target for the data packet to be received by the wireless device within the survival time window based on the determined reliability requirement. The method includes transmitting the data packet to the wireless device using the second BLER target for the data packet.

[0041] In some embodiments, the step of determining a reliability requirement for transmitting a data packet to a wireless device includes determining that a remaining PDB of at least one previously transmitted data packet is not within an allowed time interval for retransmitting the at least one previously transmitted data packet. The method includes estimating a number of remaining transmissions of the data packet to be transmitted within the time-to-live window when it has been determined that the remaining PDB of the at least one previously transmitted data packet is not within the allowed time interval for retransmission; and the method includes determining the reliability requirement based on the estimated number of remaining transmissions.

[0042] In some embodiments, transmitting the data packet to the wireless device comprises selecting one or more of the following based on reliability requirements for transmitting the data packet: MCS, number of resource blocks, and transmit power.

[0043] According to a second aspect of the present disclosure, there is provided an apparatus of a network node configured to perform transmission of a data packet to a wireless device. The apparatus comprises a control circuit, the control circuit being configured to cause obtaining a packet delay budget (PDB), wherein the PDB represents a maximum allowed delay of a data packet. The control circuit is configured to cause determining a total delay time interval, the total delay time interval indicating a delay caused by an estimated number of consecutive data packets transmitted from the network node to the wireless device. The control circuit is configured to cause transmitting the data packet to the wireless device based on whether the determined total delay time interval exceeds the obtained PDB.

[0044] A third aspect is a network node comprising the apparatus of the second aspect.

[0045] According to a fourth aspect of the present disclosure, there is provided a computer program product comprising a non-transitory computer readable medium having a computer program including program instructions thereon, the computer program being loadable into a data processing unit and configured to cause execution of the method according to the first aspect when the computer program is run by the data processing unit.

[0046] In some embodiments, any of the above aspects may further have features that are the same as or correspond to any of the various features explained above for any other aspect.

[0047] An advantage of some embodiments is that an alternative and / or improved method for performing transmission of data packets to a wireless device by identifying a relationship between a PDB and a total delay time interval is provided, thereby emphasizing the importance of conditions when using a lifetime to determine reliability requirements for data packets. As a result, radio resource allocation can be improved. In addition, aggregate reliability and robustness requirements can be achieved across multiple transmissions of data packets belonging to the same data flow.

[0048] An advantage of some embodiments is that when the total delay time interval exceeds PDB, the BLER of the data packet is adjusted to the first BLER target (ie, low BLER is enabled) and then the data packet is transmitted. As a result, the data packet can be transmitted to the wireless device with reliable transmission.

[0049] An advantage of some embodiments is that when the total delay time interval does not exceed PDB, a second BLER target for the data packet can be determined for the data packet based on the determined reliability requirement. As a result, the rate of successful delivery of data packets to the wireless device can be improved by reducing consecutive packet losses.

[0050] An advantage of some embodiments is that a link adaptation method for an application supporting an ultra-reliable low-latency communication (URLLC) service is determined while using the lifetime to transmit data packets based on the PDB, the total delay time interval, and the lifetime. As a result, the robustness of individual transmissions / data packets belonging to the same data stream can be adjusted to successfully deliver at least one data packet during a given time interval.

[0051] Other advantages may be apparent to those skilled in the art.Some embodiments may have none, some, or all of the advantages described. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The foregoing will be apparent from the following more particular description of example embodiments, as illustrated in the accompanying drawings, in which like reference numerals refer to like parts throughout the different views. The drawings are not necessarily drawn to scale, emphasis instead being placed upon illustrating the example embodiments.

[0053] Figure 1 An example showing how two different applications experience the same sequence of events;

[0054] Figure 2 An example wireless communication system according to some embodiments is disclosed;

[0055] Figure 3 is a flow chart illustrating example method steps according to some embodiments;

[0056] Figure 4 is a flow chart illustrating example method steps according to some embodiments;

[0057] Figure 5 is a schematic block diagram illustrating an example device according to some embodiments;

[0058] Figure 6 is a block diagram of a telecommunications network connected to a host computer via an intermediate network according to some embodiments;

[0059] Figure 7 is a block diagram of a host computer communicating with a user equipment UE via a base station through a partial wireless connection according to some embodiments;

[0060] Figure 8 is a block diagram of a method implemented in a communication system including a host computer, a base station, and a UE according to some embodiments;

[0061] Fig. 9 is a block diagram of a method implemented in a communication system including a host computer, a base station, and a UE according to some embodiments;

[0062] Fig.10 is a block diagram of a method implemented in a communication system including a host computer, a base station, and a UE according to some embodiments;

[0063] Fig.11 is a block diagram of a method implemented in a communication system including a host computer, a base station, and a UE according to some embodiments; and

[0064] Fig.12 An example computing environment is disclosed in accordance with some embodiments. DETAILED DESCRIPTION

[0065] The various aspects of the present disclosure will be described more fully below with reference to the accompanying drawings. However, the devices and methods disclosed herein can be implemented in many different forms and should not be construed as being limited to the aspects set forth herein. The same reference numerals in the accompanying drawings always represent the same elements.

[0066] The terms used herein are only used for the purpose of describing specific aspects of the present disclosure, and are not intended to limit the present invention. It should be emphasized that when used in this specification, the term "comprising" is used to specify the presence of the features, integers, steps or components, but does not exclude the presence or addition of one or more other features, integers, steps, components or their groups. As used herein, the singular forms "a" (a, an) and "said" are intended to also include plural forms, unless the context clearly indicates otherwise.

[0067] In some embodiments, the more general term "network node" may be used and may correspond to any type of radio network node or any network node that communicates with a user equipment UE (directly or via another node) and / or with another network node. Examples of network nodes are radio access networks RAN, NodeB, MeNB, ENB, network nodes belonging to a master cell group MCG or a secondary cell group SCG, base stations BS and multi-standard radios MSR, radio nodes such as MSR BS, eNodeB, gNodeB, network controllers, radio network controllers RNC, base station controllers BSC, relays, donor nodes that control relays, base transceiver stations BTS, access points AP, transmission points, transmission nodes, remote radio units RRU and remote radio heads RRH, nodes in distributed antenna systems DAS, core network nodes (e.g., mobile switching centers MSC, mobile management entities MME, etc.), operation & management O&M nodes, operation support system OSS nodes, self-optimizing networks SON, positioning nodes (e.g., evolved service mobile positioning centers E-SMLC), minimized drive tests MDT, test equipment (e.g., physical nodes or software), etc.

[0068] In some embodiments, the non-limiting term user equipment UE or wireless device may be used and may refer to any type of wireless device that communicates with a network node and / or with another UE in a wireless communication system. Examples of UEs are target devices, device-to-device D2D UEs, machine-type UEs, UEs capable of machine-to-machine M2M communication, personal digital assistants PDAs, tablet computers, mobile terminals, smart phones, laptop embedded equipment LEEs, laptop mounted equipment LMEs, universal serial bus USBs, dongles, UE category M2, ProSe UEs, vehicle-to-vehicle V2V UEs, vehicle-to-vehicle V2X UEs, etc.

[0069] In addition, terms such as base station / gNodeB and UE should be considered non-restrictive and especially do not imply a certain hierarchical relationship between the two; generally, "gNodeB" can be considered as device 1, and "UE" can be considered as device 2, and the two devices communicate with each other through a certain radio channel. And in the following, a transmitter or a receiver can be a gNB or a UE.

[0070] Certain embodiments apply methods to reduce the risk of continuous data packet loss beyond what is supported by existing link adaptation mechanisms (to which industrial applications are sensitive). Industrial applications are particularly sensitive to continuous data packet loss. This means that industrial applications can perceive higher reliability in data packet delivery compared to systems that do not apply methods to reduce continuous data packet loss.

[0071] According to certain embodiments, some assumptions may be applicable:

[0072] The RAN knows, for a specific data flow, the required reliability in terms of the packet delay budget PDB and the maximum number of consecutive data packets that may be lost, by e.g. but not limited to standards, configuration (e.g. as part of quality control information, quality of service QoS, class identifier QCI, 5G QoS identifier 5QI profile, signaled from the core network CN to the RAN as a specific information element IE), machine learning, etc.

[0073] The techniques described herein are applicable to application messages that are segmented or unsegmented within the RAN (e.g., by a gNB or eNB).

[0074] • When stated below, retransmission may refer to retransmission performed by the RAN, such as, for example, Packet Data Convergence Protocol PDCP, Hybrid Automatic Repeat Request HARQ, Radio Link Control RLC retransmission.

[0075] The time-to-live window mentioned below corresponds to the transmission time of a single application packet or the packet delay budget PDB plus the time-to-live of the application. Within the time-to-live window, at least one application packet must be successfully delivered so that the application does not consider the communication service to be down.

[0076] • In one example, the time to live of the industrial application is provided to the RAN as part of the QCI profile configuration associated with the bearer configured to carry the associated application traffic.

[0077] Figure 2 An example wireless communication system 200 is disclosed. Although the subject matter described herein may be implemented in any suitable type of system using any suitable components, the embodiments disclosed herein are generally intended to be used with respect to wireless communication systems / wireless networks such as Figure 22. The wireless communication system 200 may include and / or interface with any type of communication, telecommunication, data, cellular and / or radio network or other similar type of system. In some embodiments, the wireless communication system 200 may be configured to operate in accordance with a specific standard or other type of predefined process rules. Therefore, a specific embodiment of the wireless communication system 200 may implement a communication standard such as, but not limited to, a global system for mobile communications GSM, a universal mobile telecommunications system UMTS, a long term evolution LTE and / or other suitable 2G, 3G, 4G or 5G standard, a wireless local area network WLAN standard, such as the IEEE 802.11 standard, and / or any other suitable wireless communication standard, such as the global microwave access interoperability WiMax, Bluetooth, Z-Wave and / or ZigBee standard. The wireless communication system 200 may provide communication and other types of services to one or more wireless devices to facilitate access and / or use of services provided by or via the wireless communication system 200 by the wireless communication system 200.

[0078] For simplicity, Figure 2 As depicted, wireless communication system 200 includes wireless device 202, network node 204, and network 206. Wireless device 202 and network node 204 operate together to provide wireless connectivity in wireless communication system 200. Network 206 may include one or more backhaul networks, core networks, IP networks, public switched telephone networks PSTN, packet data networks, optical networks, wide area networks WAN, local area networks LAN, wireless local area networks WLAN, wired networks, wireless networks, metropolitan area networks, and other networks to enable communications between devices (e.g., wireless devices and network nodes).

[0079] In practice, the wireless communication system 200 may further include any additional elements suitable for supporting communications between wireless devices or between a wireless device and another communication device (such as a landline phone, a service provider, or any other network node or terminal device). In various embodiments, the wireless communication system 200 may include any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals (whether via a wired or wireless connection).

[0080] The wireless device 202 represents a device capable of, configured to, arranged to, and / or operable to wirelessly communicate with a network node and / or other wireless devices. Unless otherwise indicated, the term "wireless device" may be used interchangeably with user equipment UE in this document. Wireless communication may involve the use of electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for delivering information over the air to transmit and / or receive wireless signals.

[0081] In some embodiments, the wireless device 202 may be configured to transmit data packets to or receive data packets from the network node 204. The data packets may also be referred to as application messages, etc. For example, when triggered by an internal or external event, or in response to a request received from the network node 204, the wireless device 202 may transmit data packets to the network node 204 in a predetermined schedule. Each data packet indicates one or more of the following: a command, information, a signal, etc.

[0082] Examples of wireless device 202 may include, but are not limited to, smartphones, mobile phones, cellular phones, voice over Internet Protocol (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, rechargeable devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEE), laptop mounted devices (LME), smart devices, wireless customer premises equipment (CPE), wireless terminal devices installed in vehicles, etc.

[0083] In some examples, the wireless device 202 may support device-to-device D2D communication, for example, by implementing the 3GPP standard for sidelink communication, vehicle-to-vehicle V2V, vehicle-to-infrastructure V2I, and vehicle-to-network V2X, and in this case may be referred to as a D2D communication device. In some other examples, in the Internet of Things IoT scenario, the wireless device 202 may represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another wireless device and / or network node 204. In this case, the wireless device 202 may be a machine-to-machine M2M device, which may be referred to as an MTC device in the 3GPP context. In some other examples, the wireless device 202 may be a UE that implements the 3GPP narrowband IoT NB-IoT standard. Specific examples of such machines or devices are sensors, metering devices (such as power meters), industrial machinery, or household or personal appliances (such as refrigerators, televisions, etc.), personal wearables (such as watches, fitness trackers, etc.). In some other examples, the wireless device 202 may represent a vehicle or other equipment capable of monitoring and / or reporting its operating status or other functions associated with its operation. The wireless device 202 as described above may represent an endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. In addition, the wireless device as described above may be mobile, in which case it may also be referred to as a mobile device or mobile terminal.

[0084] The network node 204 represents a device that is capable of, configured to, arranged to, and / or operable to communicate directly or indirectly with the wireless device 202 and / or with other network nodes or devices in the wireless communication system 200 to implement and / or provide wireless access to the wireless device 202 and / or perform other functions (e.g., management) in the wireless communication system 200. Examples of the network node 204 may include, but are not limited to, an access point AP (e.g., a radio access point), a base station BS (e.g., a radio base station, a node B, an evolved node B eNB, a new radio NR node (gNB), etc.). The BS may be classified based on the amount of coverage provided by the BS (or in other words, its transmission power level), and then may also be referred to as a femto BS, a pico BS, a micro BS, a macro BS. The BS may be a relay node or a relay donor node that controls a relay.

[0085] In some other examples, the network node 204 may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit RRU, sometimes referred to as a remote radio head RRH. Such remote radio units may or may not be integrated with antennas as antenna-integrated radios. Portions of a distributed radio base station may also be referred to as nodes in a distributed antenna system DAS.

[0086] In some other examples, the network node 204 may also include a multi-standard radio MSR device (such as an MSRBS), a network controller (such as a radio network controller RNC or a base station controller BSC), a base transceiver station BTS, a transmission point, a transmission node, a multi-cell / multicast coordination entity MCE, a core network node (e.g., a mobile switching center MSC, a mobility management entity MME, etc.), an operation and management O&M node, an operation support system OSS node, a self-organizing network SON node, a positioning node (e.g., E-SMLC) and / or a minimized drive test MDT test device.

[0087] More generally, the network node 204 may represent any suitable device (or group of devices) that is capable of, configured to, arranged to, and / or operable to enable and / or provide access to the wireless communication system 200 for the wireless device 202 or to provide some services (referred to as communication services) to the wireless device 202 that has access to the wireless communication system 200.

[0088] The network node 204 may also be configured to transmit data packets to the wireless device 202 or receive data packets from the wireless device 202. In some examples, the data packet may be associated with the data stream of the application. Examples of applications may include, but are not limited to, industrial applications or any other applications supporting ultra-reliable low-delay communication URLLC or any industrial system. Many industrial applications are non-adaptive control systems with strict requirements on network performance. If the communication system cannot meet the quality of service required by the application, some industrial applications will consider the communication system unavailable. In some examples, the application may be associated with a communication system reliability requirement / quality of service QoS requirement. The system reliability requirement herein may indicate a survival time window during which the desired QoS level must be met. Meeting QoS refers to successfully delivering at least one data packet during the survival window. For data packets, the requirement is usually expressed as a target reliability, which is calculated as the percentage value of the number of transmitted data packets successfully delivered within the packet delay budget required by the target application divided by the total number of transmitted data packets.

[0089] Within the survival window, at least one data packet must be successfully delivered so that the application does not think that the communication service / network node 204 is closed. The survival window refers to the sum of the transmission time or packet delay budget PDB of a single application / data packet and the survival time of the application. PDB indicates the maximum allowed delay of a data packet. The survival time of an application can be a period of time in which the application can manage some packet losses (i.e., unsuccessful delivery of packets) without performing any emergency actions (e.g., emergency shutdown, production stop, etc.). The survival time depends on the implementation of the application and varies from industry to industry and use case. For example, the survival time can vary from 0 milliseconds to 25ms.

[0090] The network node 204 may transmit / schedule data to the wireless device 202 using:

[0091] the same amount of radio resources already allocated to other wireless devices; or

[0092] Radio resources allocated based on a priority mechanism; or

[0093] • Radio resources allocated based on a delay mechanism that depends on the characteristics of the services (eg, VoIP services, conversational services) supported by the wireless device.

[0094] However, the network node 204 does not consider reliability requirements, robustness requirements, etc. when performing transmission of data packets to the wireless device 202. Therefore, the aggregate reliability and robustness requirements may not be achieved over multiple transmissions of data packets to the wireless device 202. As a result, consecutive data packet losses (i.e., unsuccessful delivery of consecutive data packets to the wireless device 202) may increase.

[0095] Therefore, according to some embodiments of the present disclosure, the network node 204 implements a method for improving the scheduling of transmission of data packets to the wireless device 202 .

[0096] According to some embodiments of the present disclosure, the network node 204 obtains a PDB. The PDB represents a maximum allowed delay for a data packet. The network node 204 determines a total delay time interval indicating a delay caused by an estimated number of consecutive data packets transmitted from the network node 204 to the wireless device 202. The network node 204 transmits the data packet to the wireless device based on whether the determined total delay time interval exceeds the obtained PDB. Therefore, from such transmission, aggregated reliability and robustness requirements can be achieved across multiple transmissions of the data packet to the wireless device 202, and consecutive packet losses can be reduced.

[0097] Various embodiments for performing the transmission of data packets to the wireless device 202 are explained in conjunction with the figures in the later portions of the description.

[0098] Figure 3 3 is a flow chart illustrating example method steps of a method 300 performed by a network node for transmitting a data packet to a wireless device. In some examples, the data packet may be a new data packet of an application within the same data flow that includes at least one previously transmitted data packet. In some examples, the application may support a time-to-live feature. The time-to-live indicates the application's tolerance for unsuccessful packet delivery, which is controlled in part by how many consecutive lost application packets the application can accept before performing one or more emergency actions (such as, for example, emergency shutdown and production stop).

[0099] At step 302, method 300 includes obtaining a PDB. The PDB represents a maximum allowed delay for a data packet. In some embodiments, a network node may pre-configure a PDB.

[0100] At step 304, method 300 includes determining a total delay time interval indicating a delay caused by an estimated number of consecutive data packets transmitted from the network node to the wireless device.

[0101] In some examples, the network node may estimate a number of consecutive data packets for which a total delay time interval must be determined based on the time to live. The time to live may be associated with an application to which the data packet to be transmitted to the wireless device belongs. The network node may obtain information about the time to live as part of a QoS class identifier (QCI) profile configuration associated with a bearer configured to carry associated packet / application traffic. The estimate of the number of consecutive data packets for which a total delay time interval must be determined may vary based on the time to live. In some examples, when the time to live associated with the application is greater than 0 ms and the application tolerates two consecutive packet losses, the number of consecutive packets for which a total delay time interval must be determined may be three (3).

[0102] In some embodiments, the total delay time interval may include one or more of the following: scheduling delay, hybrid automatic repeat request HARQ round trip time HARQ RTT, receiving delay and decoding delay. The scheduling delay indicates the difference between the scheduled time interval and the actual time interval for the transmission of each data packet to the wireless device. The HARQ RTT may be associated with the retransmission of each data packet from the network node to the wireless device. The receiving delay may indicate the delay associated with receiving an acknowledgment and a negative acknowledgment A / N from the wireless device. The decoding delay indicates the time taken for the network node to decode the reception of the A / N.

[0103] Upon obtaining the PDB and determining the total delay time interval, at step 308, method 300 includes transmitting a data packet to the wireless device based on whether the determined total delay time interval exceeds the obtained PDB.

[0104] When it has been determined that the total time interval exceeds the PDB, the step 308 of transmitting the data packet to the wireless device may include selecting at least one transmission parameter for transmitting the data packet to the wireless device. In some examples, the transmission parameter may include one or more of the following: modulation and coding scheme MCS, number of resource blocks, and transmission power.

[0105] When selecting at least one transmission parameter, the method may include adjusting a block error rate BLER of the data packet to a first BLER target for the data packet according to the selected at least one transmission parameter. The first BLER target for the data packet may represent a decoding failure rate for the data packet. In some examples, the first BLER target may be set to 10%, but the BLER target may vary depending on the characteristics of the cell served by the network node. For example, if the first BLER target is 10%, this means that the receiver (e.g., a wireless device) must receive at least 90% of successful transmissions.

[0106] In some examples, adjusting the BLER of the data packet to the first BLER target may involve reducing the BLER of the data packet to meet the first BLER target while transmitting the data packet to the wireless device. Thus, the data packet is transmitted to the wireless device at a low BLER.

[0107] When it has been determined that the total time interval does not exceed the PDB, the step 308 of transmitting the data packet to the wireless device may include determining a reliability requirement, the reliability requirement indicating that the transmission of the data packet to the wireless device must meet the survival time window of the QoS. The survival time window corresponds to the transmission time of a single application packet or the sum of the survival time of the PDB and the application. Within the survival time window, at least one application packet must be successfully delivered so that the application does not think that the communication service / network node is down. Meeting the QoS in this article can refer to successfully delivering at least one data packet within the survival time window.

[0108] In some embodiments, the step of determining reliability may include determining that the remaining PDB of at least one previously transmitted data packet is not within an allowed time interval for retransmitting the at least one previously transmitted data packet. The remaining PDB may identify the remaining time length that the at least one previously transmitted data packet may be retransmitted based on a negative acknowledgement NACK received from the wireless device. The allowed time interval for retransmitting the at least one previously transmitted data packet may refer to a time interval for retransmitting the at least one previously transmitted data packet. When it has been determined that the remaining PDB of at least one previously transmitted data packet is not within the allowed time interval for retransmission, the method may include determining an estimated number of remaining transmissions of the data packet to be transmitted within the survival time window. The method may also include determining a reliability requirement based on the estimated number of remaining transmissions.

[0109] In some examples, if there is a HARQ NACK obtained for a data packet, the network node evaluates the remaining PDB of the previously transmitted data packet for retransmission. If the remaining PDB is not within the allowed time interval, the network node handles the retransmission of the previously transmitted data packet and the transmission of other data packets based on the survival time (i.e., determining the reliability requirement for transmitting the data packet). In an example regarding retransmission, if the remaining PDB of the previously transmitted data packet is not within the allowed time interval for retransmission and if the survival time is sufficient, the HARQ retransmission is ignored. In another example regarding the transmission of other data packets, if the remaining PDB of the previously transmitted data packet is not within the allowed time interval for retransmission, the network node determines the reliability requirement based on the estimated number of remaining transmissions of the data packet to be transmitted within the survival window. The network node transmits other data packets to the wireless device based on the determined reliability requirement.

[0110] When determining the reliability requirement, the method may include determining a second BLER target for the data packet based on the reliability requirement. The method includes transmitting the data packet to the wireless device based on the second BLER target for the data packet. More details on determining the reliability requirement can be found in International Publication WO 2020 / 167231 A1.

[0111] Optionally, the step of transmitting the data packet to the wireless device may include: when it has been determined that the total time interval does not exceed the PDB, selecting one or more of the following items based on reliability requirements for transmitting the data packet: MCS, number of resource blocks and transmission power.

[0112] Thus, transmitting the data packet by either adjusting the BLER of the data packet to a first BLER or a second BLER target for the data packet determined based on the use reliability requirement achieves aggregate reliability and robustness across multiple transmissions of the packet.

[0113] Figure 4 is a flow chart illustrating example method steps performed by a network node for transmitting data including one or more packets to a wireless device.

[0114] In step 402, the network node determines a PDB, which represents a maximum allowed delay for a data packet.

[0115] At step 404, the network node determines a total delay time interval (e.g., Figure 4 denoted as "X" in FIG. 1 ). The total delay time interval indicates the delay caused by an estimated number of consecutive data packets transmitted from the network node to the wireless device. In an embodiment, the total delay time interval includes one or more of the following items: a scheduling delay indicating the difference between a predetermined time interval and an actual time interval for transmission of each data packet to the wireless device, a HARQ RTT associated with a retransmission of each data packet to the wireless device, a delay associated with receiving an A / N from the wireless device, and a decoding delay indicating the time taken by the network node to decode the reception of the A / N.

[0116] At step 406, the network node determines whether the total delay time interval exceeds the PDB.

[0117] When it has been determined that the total delay time interval exceeds the PDB, at step 407a, the network node adjusts the BLER of the data packet to a first BLER target for the data packet according to at least one selected transmission parameter for transmitting the data packet to the wireless device. In some embodiments, the transmission parameter includes one or more of the following: MCS, number of resource blocks, and transmission power.

[0118] When it has been determined that the total delay time does not exceed the PDB, in step 407b, the network node determines a second BLER target for the data packet based on a reliability requirement, the reliability requirement indicating a survival time window within which the QoS must be met (i.e., successfully delivering at least one data packet within the survival time window). When the remaining PDB of at least one previously transmitted data packet is not within an allowed time interval for retransmitting at least one previously transmitted data packet, the reliability requirement may be determined based on an estimated number of remaining transmissions to be transmitted within the survival time window.

[0119] In step 408, the network node transmits the data packet with either the first BLER target for the data packet or the second BLER target for the data packet and the selected at least one transmission parameter to the wireless device according to the determined reliability requirement.

[0120] In an example, consider that the network node selects at least one transmission parameter and adjusts the BLER of the data packet to a first BLER target in step 407a. In such a scenario, the network node transmits packets to the wireless device by setting a low BLER. In some examples, the setting of the low BLER may depend on at least one of the following items: the length of the survival time, etc. For example, the BLER may be set to (1-initial reliability target / requirement). Therefore, since there is no available feedback, the packet may be transmitted to the wireless device with a reliable BLER.

[0121] In another example, consider that the network node determines the reliability requirement for transmitting the packet at step 407b. In such a scenario, the network node transmits the packet to the wireless device by determining the second BLER target for the data packet, and then the network node selects the MCS, the number of resource blocks, and the transmission power (based on the determined reliability requirement). Therefore, the transmission can be performed by improving the successful delivery rate of the packet to the wireless device.

[0122] Figure 5 is an example schematic diagram illustrating an apparatus 204. The apparatus 204 may be included in a network node, for example. The apparatus 204 is capable of performing transmission of data packets to a wireless device and may be configured to cause execution of the method 300 for transmitting data to a wireless device.

[0123] According to at least some embodiments of the present invention, Figure 5 The device 204 in the embodiment includes one or more modules. These modules may be, for example, a memory 502, a processor 504, a control circuit 506, a transceiver 508, a parameter estimator 510, and a packet scheduler 512. In some embodiments, the control circuit 506 may be adapted to control the above modules.

[0124] The memory 502, the processor 504, the transceiver 508, the parameter estimator 510, the packet scheduler 512, and the control circuit 506 may be operably connected to each other.

[0125] The control circuit 506 may be adapted to control the steps performed by the network node. For example, the control circuit 506 may be adapted to perform the transmission of the data packet to the wireless device (as described above in conjunction with the method 300 and Figure 3 described).

[0126] The parameter estimator 510 may be adapted to obtain a PDB indicating a maximum allowed delay for a packet.The parameter estimator 510 may also be adapted to determine a total delay time interval indicating a delay caused by an estimated number of consecutive data packets transmitted from the network node to the wireless device.

[0127] The packet scheduler 512 may be adapted to determine whether the total delay time interval exceeds the PDB, and thus enable transmission of the packet to the wireless device. In some embodiments, when the total delay time interval exceeds the PDB, the packet scheduler 512 may be adapted to adjust the BLER of the data packet to a first BLER target according to the selected at least one transmission parameter. In some embodiments, when the total delay time interval does not exceed the PDB, the packet scheduler 512 may be adapted to determine a second BLER target for the data packet for transmitting the data packet based on a reliability requirement.

[0128] The transceiver 508 may be adapted to transmit the data packet to the wireless device. In some embodiments, the packet may be transmitted based on a first BLER target for the data packet. In some embodiments, the packet may be transmitted based on a second BLER target for the data packet.

[0129] The processor 504 may be adapted to determine the reliability requirement.

[0130] Furthermore, the memory 502 is adapted to store PDBs, total delay time intervals, transmission parameters, BLER targets for data packets, reliability requirements, and the like.

[0131] Figure 6 is a block diagram of a telecommunications network connected to a host computer via an intermediate network according to some embodiments; Figure 6According to an embodiment, a communication system includes a telecommunication network 4410 (such as a 3GPP type cellular network), which includes an access network 4411 (such as a radio access network) and a core network 4414. The access network 4411 includes a plurality of base stations 4412a, 4412b, 4412c, such as NBs, eNBs, gNBs or other types of wireless access points, each of which defines a corresponding coverage area 4413a, 4413b, 4413c. Each base station 4412a, 4412b, 4412c is connectable to the core network 4414 via a wired or wireless connection 4415. A first UE 4491 located in the coverage area 4413c is configured to be wirelessly connected to the corresponding base station 4412c or to be paged by the base station 4412c. A second UE 4492 in the coverage area 4413a is wirelessly connectable to the corresponding base station 4412a. Although multiple UEs 4491, 4492 are shown in this example, the disclosed embodiments are equally applicable to situations where a single UE is located in the coverage area or where a single UE is connected to the corresponding base station 4412.

[0132] The telecommunications network 4410 itself is connected to a host computer 4430, which may be implemented in hardware and / or software of a stand-alone server, a cloud-enabled server, a distributed server, or as a processing resource in a server farm. The host computer 4430 may be under the ownership or control of a service provider, or may be operated by or on behalf of a service provider. The connections 4421 and 4422 between the telecommunications network 4410 and the host computer 4430 may extend directly from the core network 4414 to the host computer 4430, or may be made via an optional intermediate network 4420. The intermediate network 4420 may be one or a combination of more than one of a public, private, or managed network; the intermediate network 4420 (if any) may be a backbone network or the Internet; in particular, the intermediate network 4420 may include two or more sub-networks (not shown).

[0133] Figure 6The communication system as a whole enables connectivity between the connected UEs 4491, 4492 and the host computer 4430. The connectivity may be described as an over-the-top OTT connection 4450. The host computer 4430 and the connected UEs 4491, 4492 are configured to communicate data and / or signaling via the OTT connection 4450 using the access network 4411, the core network 4414, any intermediate networks 4420, and other possible infrastructure (not shown) as intermediaries. The OTT connection 4450 may be transparent in the sense that the OTT connection 4450 is unaware of the routing of uplink and downlink communications through the participating communication devices therein. For example, the base station 4412 may not or need not be informed of past routing of incoming downlink communications with data originating from the host computer 4430 to be forwarded (e.g., switched) to the connected UE 4491. Similarly, the base station 4412 need not be aware of future routing of outgoing uplink communications originating from the UE 4491 toward the host computer 4430.

[0134] Figure 7 is a block diagram of a host computer communicating with a user device via a base station over a partially wireless connection. Figure 7 45. The example implementation of the UE, base station and host computer described in the above paragraphs according to the embodiment is described. In the communication system 4500, the host computer 4510 includes hardware 4515, which includes a communication interface 4516, which is configured to establish and maintain a wired or wireless connection with the interface of different communication devices of the communication system 4500. The host computer 4510 further includes a processing circuit 4518, which may have storage and / or processing capabilities.

[0135] In particular, the processing circuit 4518 may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination of these devices (not shown) suitable for executing instructions. The host computer 4510 further includes software 4511, which is stored in the host computer 4510 or accessible to the host computer 4510 and is executable by the processing circuit 4518. The software 4511 includes a host application 4512. The host application 4512 may be operable to provide services to a remote user (such as a UE 4530 connected via an OTT connection 4550 terminated at the UE 4530 and the host computer 4510). In providing services to the remote user, the host application 4512 may provide user data transmitted using the OTT connection 4550.

[0136] The communication system 4500 further comprises a base station 4520, which is provided in the telecommunication system and comprises hardware 4525 enabling it to communicate with the host computer 4510 and with the UE 4530. The hardware 4525 may comprise: a communication interface 4526 for establishing and maintaining a wired or wireless connection to the interface of different communication devices of the communication system 4500; and a radio interface 4527 for establishing and maintaining at least a wireless connection 4570 with the UE 4530, which is located in the coverage area served by the base station 4520 ( Figure 6 Communication interface 4526 may be configured to facilitate connection 4560 to host computer 4510. Connection 4560 may be direct, or it may pass through a core network ( Figure 7 4520) and / or through one or more intermediate networks external to the telecommunications system. In the illustrated embodiment, the hardware 4525 of the base station 4520 further includes processing circuitry 4528, which may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination of these devices (not shown) suitable for executing instructions. The base station 4520 further has software 4521, which is stored internally or accessible via an external connection.

[0137] The communication system 4500 further includes the UE 4530 already mentioned. Its hardware 4535 may include a radio interface 4537, which is configured to establish and maintain a wireless connection 4570 with a base station serving the coverage area where the UE 4530 is currently located. The hardware 4535 of the UE 4530 further includes a processing circuit 4538, which may include one or more programmable processors, application-specific integrated circuits, field programmable gate arrays, or a combination of these devices (not shown) suitable for executing instructions. The UE 4530 further includes software 4531, which is stored in the UE 4530 or accessible by it and executable by the processing circuit system 4538. The software 4531 includes a client application 4532. The client application 4532 may be operable to provide services to human or non-human users via the UE 4530 through the support of the host computer 4510. In the host computer 4510, the executing host application 4512 can communicate with the executing client application 4532 via the OTT connection 4550 terminated at the UE 4530 and the host computer 4510. When providing services to users, the client application 4532 can receive request data from the host application 4512 and provide user data in response to the request data. The OTT connection 4550 can transmit the request data and the user data. The client application 4532 can interact with the user to generate the user data it provides.

[0138] Please note, Fig. 9The host computer 4510, base station 4520, and UE 4530 shown may be similar or identical to host computer 4430, one of base stations 4412a, 4412b, and 4412c, and one of UEs 4491 and 4492, respectively. That is, the internal workings of these entities may be similar to Fig.12 As shown, the surrounding network topology can be independently Figure 7 shown.

[0139] Figure 7 45, an OTT connection 4550 is abstractly drawn to illustrate communications between a host computer 4510 and a UE 4530 via a base station 4520, without explicit reference to any intermediate devices and the precise routing of messages via those devices. The network infrastructure may determine the routing, which it configures to be hidden from the UE 4530 or from the service provider operating the host computer 4510, or from both. While the OTT connection 4550 is active, the network infrastructure may further make decisions by which it dynamically changes the routing (e.g., based on load balancing considerations or reconfiguration of the network).

[0140] The wireless connection 4570 between the UE 4530 and the base station 4520 is in accordance with the teachings of the embodiments described throughout the present disclosure. One or more of the various embodiments may use the OTT connection 4550 to improve the performance of the OTT service provided to the UE 4530, where the wireless connection 4570 forms the last segment. More specifically, the teachings of these embodiments may increase the random access speed and / or reduce the random access failure rate, thereby providing benefits such as faster and / or more reliable random access.

[0141] For the purpose of monitoring data rate, latency, and other factors for which one or more embodiments improve, a measurement process may be provided. There may further be optional network functionality for reconfiguring the OTT connection 4550 between the host computer 4510 and the UE 4530 in response to changes in the measurement results. The measurement process and / or the network functionality for reconfiguring the OTT connection 4550 may be implemented in the software 4511 and hardware 4515 of the host computer 4510 or in the software 4531 and hardware 4535 of the UE 4530 or in both. In an embodiment, a sensor (not shown) may be deployed in or associated with a communication device through which the OTT connection 4550 passes; the sensor may participate in the measurement process by providing the values ​​of the monitored quantities exemplified above or providing the values ​​of other physical quantities from which the software 4511, 4531 can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 4550 may include message formats, retransmission settings, preferred routing, etc.; the reconfiguration need not affect the base station 4520, and it may be unknown or imperceptible to the base station 4520. Such processes and functionality may be known and practiced in the art. In certain embodiments, the measurements may involve proprietary UE signaling that facilitates the host computer 4510 to measure throughput, propagation time, latency, and the like. The measurements may be achieved because the software 4511 and 4531 causes messages to be transmitted using the OTT connection 4550 while it monitors propagation time, errors, etc., particularly empty or 'dummy' messages.

[0142] Figure 8 is a block diagram of a method implemented in a communication system including a host computer, a base station, and a user device according to some embodiments. For the sake of brevity of this disclosure, this section will only include Figure 8 Reference to the accompanying drawings of . In step 4610, the host computer provides user data. In sub-step 4611 of step 4610 (the sub-step may be optional), the host computer provides the user data by executing a host application. In step 4620, the host computer initiates a transmission to the UE carrying the user data. In accordance with the teachings of the embodiments described throughout the present disclosure, in step 4630 (the step may be optional), the base station transmits user data to the UE, the user data being carried in the transmission initiated by the host computer. In step 4640 (the step may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0143] Fig. 9 is a block diagram of a method implemented in a communication system including a host computer, a base station, and a user device according to some embodiments. For the sake of brevity of this disclosure, this section will only include Fig. 9Reference to the accompanying drawings of the method. In step 4710 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides the user data by executing a host application. In step 4720, the host computer initiates a transmission to the UE carrying the user data. In accordance with the teachings of the embodiments described throughout the present disclosure, the transmission may be delivered via a base station. In step 4730 (which may be optional), the UE receives the user data carried in the transmission.

[0144] Fig.10 is a block diagram of a method implemented in a communication system including a host computer, a base station, and a user device according to some embodiments. For the sake of brevity of this disclosure, this section will only include Fig.10 Reference to the accompanying drawings. In step 4810 (the step may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 4820, the UE provides user data. In sub-step 4821 of step 4820 (the sub-step may be optional), the UE provides user data by executing a client application. In sub-step 4811 of step 4810 (the sub-step may be optional), the UE executes a client application, which reacts to the received input data provided by the host computer and provides user data. In providing user data, the executed client application may further consider user input received from the user. Regardless of the specific manner of providing user data, the UE provides transmission of user data to the host computer in sub-step 4830 (the sub-step may be optional). In accordance with the teachings of the embodiments described throughout the present disclosure, in step 4840 of the method, the host computer receives user data transmitted from the UE.

[0145] Fig.11 is a block diagram of a method implemented in a communication system including a host computer, a base station, and a user equipment according to some embodiments. Fig.11 is a flow chart showing a method implemented in a communication system according to an embodiment. The communication system includes a host computer, a base station and a UE. For the sake of brevity of the present disclosure, this section will only include Fig.11 In step 4910 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step 4920 (which may be optional), the base station initiates a transmission of the received user data to the host computer. In step 4930 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0146] Any suitable steps, methods, features, functions or benefits disclosed herein may be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include a plurality of these functional units. These functional units may be implemented via a processing circuit, which may include one or more microprocessors or microcontrollers and other digital hardware, which may include a digital signal processor (DSP), dedicated digital logic and the like. The processing circuit may be configured to execute program codes stored in a memory, which may include one or more types of memory, such as a read-only memory (ROM), a random access memory RAM, a cache memory, a flash memory device, an optical storage device, etc. The program code stored in the memory includes program instructions for executing one or more telecommunications and / or data communication protocols and instructions for executing one or more of the technologies described herein. In some implementations, according to one or more embodiments of the present disclosure, a processing circuit may be used to cause a corresponding functional unit to perform a corresponding function.

[0147] The foregoing description of specific embodiments will so fully reveal the general nature of the embodiments herein that others can easily modify and / or adapt such specific embodiments for various applications by applying current knowledge without departing from the general concept, and therefore, such adaptations and modifications should and are intended to be understood as being within the meaning and scope of equivalents of the disclosed embodiments. It should be understood that the wording or terminology employed herein is for descriptive and not limiting purposes. Therefore, although the embodiments herein have been described according to preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced by modification within the scope of the present disclosure.

[0148] Fig.12 It shows how to implement Figure 3 An example computing environment 1200 of the methods and network nodes described in Fig.12 As depicted, the computing environment 1200 includes at least one data processing module 1206 equipped with a control module 1202 and an arithmetic logic unit (ALU) 1204, a plurality of networking devices 1208 and a plurality of input and output I / O devices 1210, a memory 1212, and a storage device 1214. The data processing module 1206 may be responsible for implementing Figure 3 For example, in some embodiments, the data processing module 1206 may be equivalent to the above combined Figure 5 The data processing module 1206 is capable of executing software instructions stored in the memory 1212. The data processing module 1206 receives commands from the control module 1202 in order to perform its processing. In addition, any logical and arithmetic operations involved in the execution of instructions are calculated with the help of the ALU 1204.

[0149] The computer program may be loaded into a data processing module 1206, which may be included in an electronic device (such as a UE or a network node), for example. When loaded into the data processing module 1206, the computer program may be stored in a memory 1212 associated with the data processing module 1206 or included in the data processing module 1206. According to some embodiments, when the computer program is loaded into the data processing module 1206 and executed by it, the computer program may cause execution according to, for example Figure 3 Method steps of any method shown in or otherwise described herein.

[0150] The entire computing environment 1200 may be composed of multiple homogeneous and / or heterogeneous cores, multiple CPUs of different types, special media and other accelerators. In addition, multiple data processing modules 1206 may be located on a single chip or on multiple chips.

[0151] The algorithm including the instructions and codes required for the implementation is stored in either the memory 1212 or the storage device 1214 or both. When executed, the instructions can be retrieved from the corresponding memory 1212 and / or storage device 1214 and executed by the data processing module 1206.

[0152] In the case of any hardware implementation, various networking devices 1208 or external I / O devices 1210 may be connected to the computing environment to support the implementation via the networking devices 1208 and I / O devices 1210 .

[0153] The embodiments disclosed herein may be implemented by at least one software program running on at least one hardware device and performing network management functions to control the elements. Fig.12 The elements shown in include blocks that may be at least one of hardware devices or a combination of hardware devices and software modules.

Claims

1. A method (300) performed by a network node (204) for transmitting a data packet to a wireless device (202), the method (300) comprising: - obtaining (302) a packet delay budget PDB, wherein said PDB represents a maximum allowed delay for a data packet; - determining (304) a total delay time interval indicating a delay caused by an estimated number of consecutive data packets transmitted from the network node (204) to the wireless device (202); and - transmitting (308) the data packet to the wireless device (202) based on whether the determined total delay time interval exceeds the obtained PDB.

2. The method (300) according to claim 1, wherein: The step (308) of transmitting the data packet to the wireless device (202) comprises: - when it is determined that the total delay time interval exceeds the PDB, selecting at least one transmission parameter for transmitting the data packet to the wireless device (202); - adjusting a block error rate BLER of said data packets to a first BLER target according to the selected at least one transmission parameter; and - transmitting said data packets with said first BLER target to said wireless device (202).

3. The method (300) of claim 2, wherein: The transmission parameters include one or more of the following: a modulation and coding scheme MCS, a number of resource blocks, and a transmission power.

4. The method (300) according to any one of the preceding claims, wherein: The total delay time interval includes one or more of the following: - a scheduling delay indicating a difference between a scheduled time interval and an actual time interval for transmission of each data packet to the wireless device (202); - a Hybrid Automatic Repeat Request (HARQ) Round Trip Time (RTT) associated with a retransmission of each data packet to the wireless device (202); - delays associated with receiving acknowledgements and negative acknowledgements A / N from the wireless device (202); as well as - a decoding delay indicating the time taken by the network node (204) to decode the reception of the A / N.

5. The method (300) according to any one of the preceding claims, wherein: The step (308) of transmitting the data packet to the wireless device (202) comprises: - when it is determined that the total delay time interval does not exceed the PDB, determining a reliability requirement, the reliability requirement indicating a time-to-live window within which a quality of service QoS must be satisfied for transmitting the data packet to the wireless device (202); - determining a second BLER target for the data packets to be received by the wireless device (202) within the time-to-live window based on the determined reliability requirement; and - transmitting the data packet to the wireless device (202) using the second BLER target for the data packet.

6. The method (300) of claim 5, wherein: The step of determining the reliability requirement for transmitting the data packet to the wireless device (202) comprises: - determining that a remaining PDB of at least one previously transmitted data packet is not within an allowed time interval for retransmitting said at least one previously transmitted data packet; - when it has been determined that the remaining PDB of the at least one previously transmitted data packet is not within the allowed time interval for retransmission, estimating the number of remaining transmissions of the data packets to be transmitted within the time-to-live window; and - determining the reliability requirement based on the estimated number of remaining transmissions.

7. The method (300) according to any one of claims 5 or 6, wherein: The step of transmitting the data packet to the wireless device (202) comprises: - selecting one or more of the following based on said reliability requirement for transmitting said data packet: MCS, number of resource blocks and transmit power.

8. An apparatus (204) of a network node, configured to perform transmission of a data packet to a wireless device (202), the apparatus (204) comprising a control circuit (506) configured to cause: - obtaining a packet delay budget PDB, wherein the PDB represents a maximum allowed delay for a data packet; - determining a total delay time interval indicating a delay caused by an estimated number of consecutive data packets transmitted from the network node to the wireless device (202); and - transmitting the data packet to the wireless device (202) based on whether the determined total delay time interval exceeds the obtained PDB.

9. The device (204) according to claim 8, wherein The control circuit (506) is configured to cause transmission of the data packet to the wireless device (202) by causing: - when it is determined that the total delay time interval exceeds the PDB, selecting at least one transmission parameter for transmitting the data packet to the wireless device (202); - adjusting a block error rate BLER of said data packets to a first BLER target according to the selection of said at least one transmission parameter; as well as - transmitting said data packets with said first BLER target to said wireless device (202).

10. The device (204) according to claim 9, wherein: The transmission parameters include one or more of the following: a modulation and coding scheme MCS, a number of resource blocks, and a transmission power.

11. The device (204) according to any one of claims 8 to 10, wherein: The total delay time interval includes one or more of the following: - a scheduling delay indicating a difference between a scheduled time interval and an actual time interval for transmission of each data packet to the wireless device (202); - a Hybrid Automatic Repeat Request (HARQ) Round Trip Time (RTT) associated with a retransmission of each data packet to the wireless device (202); - delays associated with receiving acknowledgements and negative acknowledgements A / N from the wireless device (202); as well as - A decoding delay indicating the time taken by the network node to decode the reception of the A / N.

12. The device (204) according to any one of claims 8 to 11, wherein: The control circuit (506) is configured to cause transmission of the data packet to the wireless device (202) by causing: - when it is determined that the total delay time interval does not exceed the PDB, determining a reliability requirement, the reliability requirement indicating a time-to-live window within which a quality of service QoS must be satisfied for transmitting the data packet to the wireless device (202); - determining a second BLER target for the data packets to be received by the wireless device (202) within the time-to-live window based on the determined reliability requirement; as well as - transmitting the data packet to the wireless device (202) using the second BLER target for the data packet.

13. The device (204) according to claim 12, wherein: The control circuit (506) is configured to cause determination of the reliability requirement for transmitting the data packet to the wireless device (202) by: - determining that a remaining PDB of at least one previously transmitted data packet is not within an allowed time interval for retransmitting said at least one previously transmitted data packet; - when it has been determined that said remaining PDB of said at least one previously transmitted data packet is not within said allowed time interval for retransmission, estimating the number of remaining transmissions of said data packets to be transmitted within said time-to-live window; as well as - determining the reliability requirement based on the estimated number of remaining transmissions.

14. The device (204) according to any one of claims 12-13, wherein: The control circuit (506) is configured to cause transmission of the data packet to the wireless device (202) by causing: - selecting one or more of the following based on said reliability requirement for transmitting said data packet: MCS, number of resource blocks and transmit power.

15. A network node (204) comprising the apparatus according to any one of claims 8 to 14.

16. A computer program product comprising a non-transitory computer readable medium having thereon a computer program comprising program instructions, the computer program being loadable into a data processing unit and being configured to cause the execution of the method according to any one of claims 1 to 7 when the computer program is run by the data processing unit.

Images