TECHNICAL FIELD

The invention relates to an apparatus and a method for efficient packet transmission procedure. Furthermore, the invention also relates to corresponding a computer program.

BACKGROUND

The upcoming fifth-generation (5G) wireless cellular communication system, also known as new radio (NR), is expected to carry more traffic and provide new service types compared to the current fourth-generation (4G) wireless cellular communication system, also known as long term evolution (LTE). LTE is mainly optimized for enhanced mobile broadband (eMBB) traffic with target block error rate (BLER) of 10e-1 before re-transmission and an expected one-way latency of around 20ms.

A critical requirement of 5G is the support of new services and one such service is ultra-reliable low-latency communication (URLLC), for which latency expressed as the time required for transmitting a data packet through the network and reliability is measured in packet error rate (PER). The requirements for URLLC one way over the radio access network (RAN) have been set to a latency of 1 ms combined with a PER of 10e ^-5 for 32 bytes packet. Thus, URLLC traffic requires much higher reliability and lower latency than eMBB traffic. The addition of such new services with significant reductions in latency while guaranteeing ultra reliability will put several challenges on the design of the 5G wireless communication system.

SUMMARY

An objective of the embodiments of the invention is to provide a solution which mitigates or solves the drawbacks and problems of conventional solutions.

The above and further objectives are solved by the subject matter of the independent claims. Further advantageous embodiments of the invention can be found in the dependent claims. The invention aims to balance the use of limited network resources in case of an advanced type of service (e.g., URLLC type of services). And the invention aims to minimize any adverse queuing of packets for the advanced type of services in case a packet fails to be transmitted within a predefined latency requirement, and the packet is not allowed to be discarded.

According to a first aspect of the invention, the above mentioned and other objectives are achieved with a first apparatus for a wireless communication system. The first apparatus is configured to determine a packet delay status of a first packet with regard to a Packet Delay Threshold Configuration for a first service type. The first packet belongs to the first service type. The first apparatus is further configured to transmit the first packet to a second apparatus according to either a first transmission procedure or a second transmission procedure (different from the first transmission procedure) in dependence on the determined packet delay status. The first transmission procedure and the second transmission procedure are both associated with the first service type.

It shall be noted, that the above disclosure concentrates on a scenario for the first apparatus to transmit or retransmit a packet to the second apparatus in a wireless communication system. The first apparatus can be implemented with a client device (e.g. a mobile phone, internet-of- things, loT device, or a modem, etc.), and the second apparatus can be implemented with a network access node (e.g., a base station, an access point, AP, etc.), and vice versa. Based on this disclosure, the embodiments of the invention can, e.g. be applied to uplink packet transmission (i.e., packet transmission from the client device to the network access node in a wireless network), or downlink packet transmission (i.e., packet transmission from the network access node to the client device in the wireless network).

In this disclosure, the term“service type” can be interpreted to mean a service having certain characteristics or quality of service requirements, e.g. a service having certain latency and/or reliability/error constraints, etc.

In this disclosure, the term“packet delay status” can be interpreted to mean a transmission delay status of a packet corresponding to a service type. For example, the“packet delay status” may specify whether the packet transmission time (e.g. a latency of the packet, or a quantity of transmission attempts of the packet) exceeds a latency requirement (e.g. a time threshold value, or a transmission attempt threshold value), just as an example, the“packet delay status” may comprise two statuses, e.g.,“elapsed” or“not elapsed”.

In this disclosure, the term “Packet Delay Threshold Configuration” comprises configuration/configurations for determining the packet delay status of a packet (e.g. a parameter or parameters for indicating the packet delay status), and strategy/strategies for choosing the transmission procedure for transmitting the packet. The packet delay threshold configuration can be defined to associate with a service type (e.g. an URLLC service).

A“packet” can for example, be a data packet or a control packet.

A specific“transmission procedure” can define a transmission process and corresponding transmission resources for transmitting a packet. The first transmission procedure and the second transmission procedure are two different transmission procedures. Just as an example, the transmission procedures comprises URLLC transmission procedure, and Enhanced Mobile Broadband, eMBB transmission procedure.

An advantage of the first apparatus according to the first aspect is that two different transmission procedures are defined for transmitting the first packet. The choosing of transmission procedure is determined according to the packet delay status of the first packet, and flexibility of the first packet transmission is thus improved.

In an implementation form of a first apparatus according to the first aspect, the first apparatus is further configured to transmit the first packet according to the first transmission procedure upon determining that the packet delay status is not elapsed with regard to the Packet Delay Threshold Configuration. The first apparatus is further configured to transmit the first packet according to the second transmission procedure upon determining that the packet delay status is elapsed with regard to the Packet Delay Threshold Configuration.

In this disclosure, the packet delay status comprises two statuses,“not elapsed” or“elapsed”.

An advantage with this implementation form is that two separated statuses“not elapsed” and “elapsed” are defined, based on which two transmission procedures can be chosen according to the packet delay status. By this, the complexity of the implementation is simplified.

In an implementation form of a first apparatus according to the first aspect, the Packet Delay Threshold Configuration comprises a time threshold value. The first apparatus is further configured to determine that the packet delay status of the first packet is not elapsed if a latency of the first packet is below the time threshold value. The first apparatus is further configured to determine that the packet delay status of the first packet is elapsed if the latency of the first packet exceeds the time threshold value. In this implementation, a specific criterion for determining the packet delay status,“a latency of the first packet is compared with a time threshold value”, is defined.

An advantage with this implementation form is that an implementation of the criteria for determining the packet delay status of the first packet is provided. This improves the flexibility of the first packet transmission.

In an implementation form of a first apparatus according to the first aspect, the first apparatus is further configured to determine the latency of the first packet based at least on an arrival time of the first packet in a given layer.

In an exemplary implementation, the expression“a latency of the first packet” may be specified as time elapsed, for the packet, between arrival in a given layer and the time of transmission from the given layer. So the latency of the packet can be obtained by calculating the difference between the arrival time of the first packet in a given layer and the transmission time of the first packet from the given layer.

An advantage with this implementation form is that an easier way of determining the latency of the first packet is provided.

In an implementation form of a first apparatus according to the first aspect, the given layer is a physical, PHY, layer or is a media access control, MAC, layer, or is a radio link control, RLC, layer, or is a packet data convergence protocol, PDCP, layer or is a service data adaptation protocol, SDAP, layer.

An advantage with this implementation form is that the implementation may be realized in different layers, and thus the applicability of the solution in the wireless communication system is improved.

In an implementation form of a first apparatus according to the first aspect, the first apparatus is further configured to: determine the latency of the first packet based at least on a time stamp in a packet header of the first packet. Just as an example, the format of the time stamp can be realized with a synchronized common time for the URLLC service with regard to the first packet.

In an embodiment of the implementation, the latency of the first packet can be determined based on a time stamp of the arrival time in a given layer and a time stamp of the transmitting time from the given layer. The time stamp of the arrival time in the given layer may be, e.g., recorded in a packet header of the first packet.

An advantage with this implementation form is that another easier way of determining the latency of the first packet is provided.

In an implementation form of a first apparatus according to the first aspect, the Packet Delay Threshold Configuration comprises a transmission attempt threshold value. The first apparatus is configured to determine that the packet delay status of the first packet is not elapsed if a quantity of transmission attempts of the first packet does not exceed the transmission attempt threshold value. The first apparatus is further configured to determine that the packet delay status of the first packet is elapsed if the quantity of transmission attempts of the first packet exceeds the transmission attempt threshold value.

In this implementation, another specific criterion for determining the packet delay status,“a quantity of transmission attempts of the first packet is compared with a transmission attempt threshold value” is defined.

An advantage with this implementation form is that such kind of implementation may be realized in different layers. This improves the applicability of invention in wireless communication systems. For example, for physical (PHY) layer or Media Access Control (MAC) layer, the quantity of transmission attempts of the first packet may be implemented as the number of Hybrid Automatic Repeat reQuest (HARQ) transmission attempts; for (RLC) layer, the quantity of transmission attempts of the first packet may be implemented as the number of Protocol Data Unit (PDU) negative-acknowledgement (NACK) message.

In an implementation form of a first apparatus according to the first aspect, the Packet Delay Threshold Configuration is obtained based on a configuration received from a network access node, or is obtained based on a pre-defined configuration, or is obtained based on a packet delay budget (PDB) of the first service type.

In the implementation, the Packet Delay Threshold configuration may be defined in a standard with which the first apparatus complies. The configuration may be pre-defined.

An advantage with this implementation form is that three implementations of obtaining the packet delay threshold configuration are provided, and the applicability of the implementation is thus improved. In an implementation form of a first apparatus according to the first aspect, the first apparatus is further configured to transmit a second packet belonging to a second service type according to the second transmission procedure (e.g. an eMBB transmission procedure). The second transmission procedure is associated with the second service type (e.g. an eMBB service).

An advantage with this implementation form is that the second transmission procedure may be flexibly configured for transmitting the second packet belonging to a second service type (e.g. an eMBB transmission procedure).

In an implementation form of a first apparatus according to the first aspect, the first service type is associated with a first Quality of Service, QoS ID and the second service type is associated with a second QoS ID. The first QoS ID has at least one of a higher reliability or stricter latency requirement than the second QoS ID.

In an exemplary implementation, according to Standardized 5QI to QoS characteristics mapping table, for example, the first QoS ID (i.e. 5G QoS identifier) is“B”, the second QoS flow ID is“1”, and the reliability requirement (e.g. Packet error rate) and the latency requirement (e.g. Packet Delay Budget) of the first QoS ID are higher than the reliability requirement and the latency requirement of the second QoS ID.

An advantage with this implementation form is that the two service types are associated with two different QoS flow IDs respectively. By using QoS flow IDs, the two service types can be easily identified.

In an implementation form of a first apparatus according to the first aspect, the first apparatus is further configured to transmit packets belonging to the second service type always according to the second transmission procedure.

An advantage with this implementation form is that the second transmission procedure may be a default transmission procedure. The second transmission procedure may be pre-defined for transmitting packets of the second service type.

In an implementation form of a first apparatus according to the first aspect, the first service type corresponds to an ultra-reliable and low latency communications, URLLC, type of service. In an implementation form of a first apparatus according to the first aspect, the second service type corresponds to an enhanced mobile broadband, eMBB, type of service.

In an implementation form of a first apparatus according to the first aspect, the transmission is a packet data convergence protocol, PDCP layer transmission, or a radio link control, RLC, layer transmission.

In an implementation form of a first apparatus according to the first aspect, the first transmission procedure is at least one of:

using pre-allocated transmission resources;

based on grant-free transmissions;

based on a periodic grant through semi-persistent scheduling;

having a lower block error rate, BLER, target compared to the second transmission procedure;

based on repetitions, for soft combining, of a packet within one transmission;

based on a Synchronous Hybrid Automatic Repeat request, HARQ scheme;

using a Prioritized Scheduling Request;

based on a physical downlink control channel, PDCCH, repetition;

using bandwidth part, BWP, with a numerology including a higher sub carrier spacing compared to the second transmission procedure, wherein the bandwidth parts are not greater than 30 kHz.

In this implementation, the first transmission procedure having at least one of the characteristics:

(1 ) Resources pre-allocated transmission: This resource pre-allocated transmission corresponds to an ultra-reliability and low latency communication, URLLC, type of service. For an uplink data transmission (e.g. a client device to a network access node), the transmission resources are pre-allocated for the client device, and packets from the client service are sent without firstly sending a scheduling request for allocating resources. For example, grant-free transmissions and a periodic grant through semi-persistent scheduling (i.e. Periodic Grant semi static scheduled to the client device with Radio Resource Control, RRC, signalling) are two implementations of resources pre-allocated transmission.

(2) A lower block error rate, BLER, target compared to the second transmission procedure.

(3) Repetitions, for soft combining, of a packet within one transmission: Hybrid Automatic Repeat reQuest (HARQ) retransmission are soft-combined, that is, multiple copies of the packet are transmitted at one transmission attempt as if there have been multiple HARQ transmission. (4) A Synchronous Hybrid Automatic Repeat request, HARQ scheme: The receiver has knowledge of the packet when to come in this sub frame, i.e. Network access node knows exactly which HARQ number and when will send. The network access node determines them from transmission time.

(5) A Prioritized Scheduling Request: a scheduling request with different priority levels are provided. These different priority levels may be corresponding to services with different service types, or a plurality of services for a same service type with different QoS priority levels.

(6) A physical downlink control channel, PDCCH, repetition: The PDCCH in LTE carries UE- specific scheduling assignments for Downlink (DL) resource allocation, Uplink (UL) grants, PRACH (Physical Random Access Channel) responses, UL power control commands, and common scheduling assignments for signalling messages (such as system information, paging, etc.).

(7) Bandwidth part, BWP, with a numerology including a higher sub carrier spacing compared to the second transmission procedure, wherein the bandwidth parts are not greater than 30 kHz.

In an implementation form of a first apparatus according to the first aspect, the second transmission procedure is at least one of:

based on a non-prioritized scheduling request corresponds to an enhanced mobile broadband, eMBB, type of service;

based on an Asynchronous HARQ scheme;

using bandwidth part, BWP, with lower sub carrier spacing compared to the first transmission procedure, wherein the bandwidth part are not less than 30kHz;

having a BLER target of 10% for Physical Downlink Shared Channel, PDSCH, and Physical Uplink Shared Channel, PUSCH.

In this implementation, the second transmission procedure has at least one of the characteristics:

(1 ) A non-prioritized scheduling request.

(2) Asynchronous HARQ scheme: this is used by downlink transmission. The transmitter provides details about which HARQ process it is using. This gives flexibility because retransmissions does not have to be scheduled during every sub-frame but it increases signalling overhead because sender has to send the information on a channel.

(3) Bandwidth parts, BWP, with lower sub carrier spacing compared to the first transmission procedure, wherein the bandwidth parts are not less than 30 kHz:

(4) A BLER target of 10% for Physical Downlink Shared Channel, PDSCH, and Physical Uplink Shared Channel, PUSCH. In an implementation form of a first apparatus according to the first aspect, the first apparatus is a client device and the second apparatus is a network access node, or vice versa.

According to a second aspect of the invention, the above mentioned and other objectives are achieved with a method for a communication system. The method comprises the following steps. Firstly, a packet delay status for a first packet with regard to a Packet Delay Threshold Configuration for a first service type (e.g. an URLLC service) is determined. The first packet belongs to the first service type (e.g. the URLLC service). Secondly, the first packet is transmitted to a second apparatus, in dependence on the determined packet delay status, according to either a first transmission procedure (e.g., an URLLC transmission procedure) or a second transmission procedure (e.g., an eMBB transmission procedure). The first transmission procedure and the second transmission procedure are associated with the first service type.

The method according to the second aspect can be extended into implementation forms corresponding to the implementation forms of the first apparatus according to the first aspect. Hence, an implementation form of the method comprises the feature(s) of the corresponding implementation form of the first apparatus.

The advantages of the methods according to the second aspect are the same as those for the corresponding implementation forms of the first apparatus according to the first aspect.

The invention also relates to a computer program, characterized in program code, which, when run by at least one processor causes said at least one processor to execute any method according to embodiments of the invention. Further, the invention also relates to a computer program product comprising a computer readable medium and said mentioned computer program, wherein said computer program is included in the computer readable medium, and comprises of one or more from the group: ROM (Read-Only Memory), PROM (Programmable ROM), EPROM (Erasable PROM), Flash memory, EEPROM (Electrically EPROM) and hard disk drive.

Further applications and advantages of the embodiments of the invention will be apparent from the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

The appended drawings are intended to clarify and explain different embodiments of the invention, in which:

- Fig. 1 shows a first apparatus (e.g. a client device) according to an embodiment of the invention;

- Fig. 2 shows a method according to an embodiment of the invention;

- Fig. 3 shows a wireless communication system according to an embodiment of the invention;

- Fig. 4 shows an implementation of the method according to an embodiment of the invention;

- Fig. 5 shows protocol stacks for the exemplary diagram of the communication system shown in Fig.3;

- Fig. 6 shows an illustrative example of transmission of multiple packets in the communication system;

- Fig. 7 shows a table for determining packet delay status of a packet according to an embodiment of the invention;

- Fig. 8 shows an exemplary embodiment of an RSP according to an embodiment of the invention; and

- Fig. 9a-9d shows four examples of efficient packet transmission according to embodiments of the invention.

DETAILED DESCRIPTION

Illustrative embodiments of method, apparatus, and program product for efficient packet transmission in a communication system are described with reference to the figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

Moreover, an embodiment/example may refer to other embodiments/examples. For example, any description including but not limited to terminology, element, process, explanation and/or technical advantage mentioned in one embodiment/example is applicative to the other embodiments/examples.

In a legacy (e.g., Enhanced Mobile Broadband, eMBB) type of services (e.g., voice or video service), a data packet may simply be discarded after a period of time in case of unsuccessful transmission. This is normal when the packets origin from a single source, but what if for an advanced type of service (e.g., URLLC), packets of the advanced type of service are independent, for example medical surveillance from different patients or different sensors of a patient, and a packet can hence not be discarded in case of unsuccessful transmission within its latency requirement. If the unsuccessful transmission exceeds its latency requirement, a possible way is to allocate or pre-allocate the advanced transmission resources (e.g., URLLC transmission resources) for the re-transmission. As the allocated transmission resources includes more transmission resources than those of the legacy type of services. Pre-allocating resources for all retransmissions will be a significant waste of resources, especially in the case that a data packet has already violated the latency requirement. This puts for instance requirements on packet transmission procedures (e.g. uplink and downlink) defined in the NR standard for such services.

Fig.1 shows a first apparatus 100 according to an embodiment of the invention. In the embodiment shown in Fig. 1 , the first apparatus 100 comprises a processor 102, a transceiver 104 and a memory 106. The processor 102 is coupled to the transceiver 104 and the memory 106 by communication means 108 known in the art. The first apparatus 100 further comprises e.g. for a mobile device, an antenna or antenna array 1 10 coupled to the transceiver 104 or e.g., for a wired network device, a wired connection interface 1 10 coupled to the transceiver 104. These mean that the first apparatus 100 is configured for wireless communications in a wireless communication system or is configured for wired communication in a wired communication system.

The first apparatus 100 is configured to perform certain actions in this disclosure can be understood to mean that the first apparatus 100 comprises suitable means, such as e.g. the processor 102 and the transceiver 104, configured to perform said actions.

According to embodiments of the invention the first apparatus 100 is configured to determine a packet delay status of a first packet with regard to a Packet Delay Threshold Configuration for a first service type. The first packet belongs to the first service type. The first apparatus 100 is further configured to transmit the first packet to a second apparatus according to either a first transmission procedure or a second transmission procedure in dependence on the determined packet delay status. The first transmission procedure and the second transmission procedure are both associated with the first service type, just as an example, the two transmission procedures may be pre-allocated for transmitting packets belonging to the first service type. In an embodiment of the invention, the first apparatus 100 may be a client device (e.g. a mobile phone, internet-of-things, loT device, a modem, etc.), the second apparatus may be a network access node (e.g., a base station, an access point, AP, etc.), and vice versa.

Fig. 2 shows a flow chart of a corresponding method 200 which may be executed in the first apparatus 100, such as the one shown in Fig. 1 . The method 200 comprises, determining 202 a packet delay status for a first packet with regard to a Packet Delay Threshold Configuration for a first service type. The first packet belongs to the first service type. The method 200 further comprises transmitting 204 the first packet to a second apparatus according to either a first transmission procedure associated with the first service type or a second transmission procedure associated with the first service type in dependence on the determined packet delay status.

Fig. 3 shows a communication system 300 according to an embodiment of the invention. The communication system 300 comprises a first apparatus (e.g. a client device 100) and a second apparatus (e.g. a network access node 120) configured to operate in the communication system 300. For simplicity, the communication system 300 shown in Fig. 3 only comprises one client device 100 and one network access node 120. However, the communication system 300 may comprise any number of client devices 100 and any number of network access nodes 120 without deviating from the scope of the invention. The first apparatus and the second apparatus are communicatively coupled via a wireless network, a wired network, or both a wireless network and a wired network.

As an example, in the embodiment shown in Fig. 3, the client device 100 is in connected mode with the network access node 120 and a wireless connection (e.g. radio link (RL)) is configured between the client device 100 and the network access node 120. The radio link (RL) may be configured to work in an uplink (UL) mode, or in a downlink (DL) mode. The radio link (RL) is configured for a first service type which can be understood to mean that the radio link (RL) between the client device 100 and network access node 120 is used for communicating data of a service type that may for instance be services requiring low latency and/or high reliability.

The embodiments of the invention may be implemented in the client device 100 or the network access node 120. A resource switching point, RSP, is pre-configured in the client device 100 or the network access node 120 to monitor a packet delay status of a first packet in either an UL packet transmission (packet transmission from the client device 100 to the network access node 120) or a DL packet transmission (packet transmission from the network access node 120 to the client device 100). A first transmission procedure and a second transmission procedure are allocated for transmitting the first packet of the first service type. As an alternative, the two transmission procedures (i.e. the first transmission procedure and the second transmission procedure) are pre-defined. For the first packet transmission or retransmission of the first service type (e.g., URLLC service), the RSP controls choosing of either the first transmission procedure (e.g., new URLLC type of procedures) or the second transmission procedure (e.g., legacy eMBB type of procedures) via allocating network access procedures and resources. The Resource Switching Point (RSP) determines when a Packet Delay Threshold for the first packet has not been exceeded (i.e. the packet delay status is not elapsed) or has exceeded (i.e., the packet delay status is elapsed).

It shall be noted, that when in this document it is referred to a transmission of a packet, this shall also cover a retransmission of this packet, where applicable.

Fig. 4 shows a flow chart of a method 400 for transmitting a packet according to an embodiment of the invention. The method 400 may be implemented in different layers of a client device, such as e.g. the client device 100 shown in Fig. 5 or in different layers of a network access node, such as e.g. the network access node 120 shown in Fig.5. Just as an example, this embodiment is described as implemented in a given layer of the client device. The given layer may be at least one of the following: a physical, PHY layer, a media access control, MAC layer, a radio link control, RLC layer, a service data adaptation protocol, SDAP layer, and a packet data convergence protocol, PDCP layer.

In step 402, the client device 100 is configured for a service requiring certain latency and/or reliability constraints.

Examples for such service could be URLLC services requiring a residual Block Error Rate, BLER of 10e-5 and having latency requirements of 1 millisecond (ms) (through Radio Access Network, RAN). However, the invention is not limited to the URLLC services. In addition a resource switching point, RSP can be also included in the respective configuration for such service. The configuration is called packet delay threshold configuration, and it can be associated with the service. For example, a first packet delay threshold configuration can be associated with a first service, and a second packet delay threshold configuration can be associated with a second service. The two packet delay threshold configurations may have individual RSP, or share a same RSP. If the two packet delay threshold configurations share a same Resource Switching Point (RSP), the RSP defines when a Packet Delay Threshold for the packet of the first service has not been exceeded (the packet delay status is not elapsed) or has exceeded (the packet delay status is elapsed), and determines when a Packet Delay Threshold for the packet of the second service has not been exceeded (the packet delay status is not elapsed) or has exceeded (the packet delay status is elapsed). If the two packet delay threshold configurations have individual RSPs, e.g. RSP1 is used for the first packet delay threshold configuration with regards to the first service, and RSP2 is used for the first packet delay threshold configuration with regards to the second service. RSP1 specifies when a Packet Delay Threshold for the packet of the first service has not been exceeded (the packet delay status is not elapsed) or has exceeded (the packet delay status is elapsed), and RSP2 specifies when a Packet Delay Threshold for the packet of the second service has not been exceeded (the packet delay status is not elapsed) or has exceeded (the packet delay status is elapsed).

In step 404, the client device 100 receives a packet (e.g. an URLLC service data packet) from upper layer(s). The upper layer(s) specify an upper layer of the given layer, for example, if the given layer is the MAC layer, the upper layer is the RLC layer. If the given layer is SDAP layer, the upper layer corresponds to Internet Protocol, IP layer.

In step 406, a packet delay status of the packet corresponding to URLLC service data is determined by the RSP. Based on the determined packet delay status, a corresponding transmission procedure is initiated. There are two statuses for the determined packet delay status, i.e.,“Not Elapsed” and“Elapsed”. If the determined packet delay status is“not elapsed”, go to step 408; and if the status is“elapsed”, go to step 414.

In one implementation of the embodiment, the packet delay threshold configuration comprises a time threshold value (e.g., 10 ms), that is, a time window has been defined. The client device 100 is configured to determine that the packet delay status of the packet is not elapsed if a latency of the packet is below the time threshold value (i.e. within the time window). The client device 100 is further configured to determine that the packet delay status of the packet is elapsed if the latency of the packet exceeds the time threshold value (i.e. outside the time window). Hence, the mentioned RSP here defines whether the latency of the packet exceeds the 10ms threshold. If latency of the packet exceeds 10ms, the transmission resources and transmission procedure are switched by the client device 100 from the first transmission procedure (e.g. URLLC compliant) to the second transmission procedure (e.g. eMBB compliant). In one implementation, the latency of the packet is determined based on an arrival time of the packet in the given layer (e.g. the MAC layer) and a transmission time of the packet transmitted from the given layer (e.g. the MAC layer). In another implementation, the latency of the packet is determined based on a time stamp in a packet header of the packet and a time stamp of transmitting the packet from the given layer (e.g. the MAC layer). Just as an example, the format of the time stamp can be realized with a synchronized common time for the URLLC service with regard to the first packet.

In another implementation, the packet delay threshold configuration comprises a transmission attempt threshold value. In an implementation, a counter can be configured to count the transmission attempts of the packet in the given layer. The client device 100 is further configured to determine that the packet delay status of the packet is not elapsed if a quantity of transmission attempts of the packet does not exceed the transmission attempt threshold value (i.e., the quantity of transmission attempts of the packet counted in the counter is smaller than or equal to the transmission attempt threshold value). The client device 100 is further configured to determine that the packet delay status of the packet is elapsed if the quantity of transmission attempts of the packet exceeds the transmission attempt threshold value (i.e., the quantity of transmission attempts of the packet counted in the counter exceeds the transmission attempt threshold value). Hence, the client device 100 monitors whether the quantity of transmission attempts of the packet exceeds the transmission attempt threshold value. If the packet was already transmitted more often than defined by the transmission attempt threshold value the transmission resources and procedure are switched by the client device 100 from the first transmission procedure (e.g. URLLC compliant) to the second transmission procedure (e.g. eMBB compliant).

In a further embodiment, both latency of the packet and transmission attempts are observed, and if only one of them exceeds its respective threshold, the packet delay status is elapsed. In a further implementation of this embodiment if both of them exceed its respective threshold, the packet delay status is elapsed

The packet delay threshold configuration for the client device 100 may be obtained based on a configuration received from a network access node (e.g. an eNB, a gNB, or an AP) or based on a pre-defined configuration in a standard (e.g. fifth-generation new radio, 5G NR) the client device complies with, or based on a packet delay budget, PDB (i.e. a per-QoS-class upper bound for the time delay of the data packets transferred by a bearer) of the first service type.

In step 408, the client device 100 uses a first transmission procedure (e.g. a URLLC type of procedures) and resources for transmitting the packet. In step 410, the client device 100 determines whether the packet transmission is successful, if the result of the determination is“YES”, go back to step 404; or else go back to step 406.

In step 414, the client device 100 uses a second transmission procedure (e.g. an eMBB type of procedure) and resources for transmitting the packet.

In step 416, the client device 100 uses the second transmission procedure and resources for re-transmission of the packet if the packet is not transmitted successfully.

In the implementation of this step, if the packet delay status is determined as“elapsed”, any upcoming retransmission shall use the second transmission procedure.

Fig. 6 shows an example where three URLLC type of packets arrive at a transmission phase, Uplink (UL) or Downlink (DL). The three URLLC packets can be from a same URLLC service type or different URLLC service types. Each packet has its Packet Delay Threshold Configuration (e.g., which comprises a time threshold value, or a transmission attempt threshold value).

In the Fig. 6, just as an example, a time threshold value is specified for each packet.

As seen from Fig. 6, a latency threshold A is specified for packet A, a latency threshold B is specified for packet B, and a latency threshold C is specified for packet C. As long as the transmission delay of packet A is below the latency threshold A, the client device 100 transmits or retransmits packet A using an URLLC procedure. However, when the transmission delay of packet A exceeds latency threshold A, packet A is not abandoned but will from now on, only be transmitted or retransmitted using an eMBB procedure. This process also applies to the transmission and retransmissions of packet B and packet C.

This process has the advantage, that a packet which failed its transmission requirements is still to be transmitted or retransmitted but with a normal priority. Hence the (re)transmissions of this packet do not compete with (re)transmissions of other packets (such as packet B and packet C) which can still meet their transmission requirements. In the context of URLLC, packets which didn’t meet their URLLC requirements, will still get transmitted but don’t block URLLC resources which may be needed for other URLLC packet transmissions. Although the example above used the latency thresholds for determining the switching point between the two transmission procedures, other thresholds may be used too, such as the transmission attempt threshold value. Fig. 7 shows a table 700 for determination of the packet delay status of a packet. In this table, each row corresponds to a service type. Service type 710 specifies type of the service, for example, in Fig.7, the service type comprises a URLLC type 1 , and a URLLC type 2, and an eMBB type 1 . Packet delay status determination 720 specifies the criterion for determining packet delay status, for example, the packet delay status determination 720 comprises a time threshold value and a transmission attempt threshold value. Status 1 /transmission procedure 730 specifies a first status and a transmission procedure corresponding to the first status. Status 2/transmission procedure 740 specifies a second status and a transmission procedure corresponding to the second status. Just as an example, the table 700 may be pre-determined before the initiation of each service type. The table 700 may be created and stored in the client device 100 when this embodiment of the invention is implemented in the client device, or in the access network node 120 when this embodiment of the invention is implemented in the network access node.

Assuming for packet A belonging to URLLC type 1 , a time threshold value is specified as a decision criteria for the packet delay status determination. This means that when the latency of packet A of URLLC type 1 is below the time threshold value, the packet delay status is not elapsed. Correspondingly, the transmission or retransmission of packet A shall be performed with an URLLC transmission (Tx) procedure 1 . However, when the latency of packet A of URLLC type 1 exceeds the time threshold value, the packet delay status is elapsed. Correspondingly, the transmission or retransmission of packet A shall be performed with a fall back transmission (Tx) procedure, in this case eMBB transmission procedure 1 .

Assuming for packet B belonging to a URLLC type 2, a transmission attempt threshold value is specified as a decision criteria for the packet delay status determination. This means, that when the quantity of transmission attempts of packet B is below the transmission attempt threshold value, the packet delay status is not elapsed. Correspondingly, the transmission or retransmission of packet B shall be performed with an URLLC transmission (Tx) procedure 2. However, when the quantity of transmission attempts of packet B of the URLLC type 2 exceeds the transmission attempt threshold value, the packet delay status is elapsed. Correspondingly, the transmission or retransmission of packet B shall be performed with a fall back transmission (Tx) procedure, in this case, eMBB transmission procedure 2.

For transmission or retransmission of a packet C belonging to an eMBB type 1 (e.g. a second service type), the packet C is transmitted all along according to the eMBB transmission procedure 1 (e.g. a second transmission procedure). Just for clarification, in this example, this eMBB transmission procedure 1 is the same as the fall back transmission procedure for packet A.

Hence, at least in some embodiments of the present invention, after fallback to the second transmission procedure, a packet of a first service type (URLLC) will be transmitted using the same (second) transmission procedure as a packet of a second service type (eMBB) which is always transmitted using this second transmission procedure.

Fig. 8 shows an exemplary embodiment of an RSP. In Fig. 8, the RSP is configured to monitor the packet delay status of a packet. If the packet delay status is determined as“not elapsed”, the packet is transmitted according to URLLC procedures. If the packet delay status is determined as “elapsed”, the packet is transmitted according to eMBB procedures. The concept of RSP is applicable for both Downlink (DL) and Uplink (UL) packet transmission. An RSP can be configured independently for DL and UL. Further, if a client device is configured with multiple URLLC data flows with different QoS (e.g., QoS Flow identifier, QFI), then each data flow may have its corresponding RSP. For each data flow, a corresponding RSP defines whether a Packet Delay Threshold for the packet has not been exceeded (i.e., the packet delay status is not elapsed) or has exceeded (i.e., the packet delay status is elapsed). The packet delay threshold is included in a Packet Delay Threshold Configuration. The Packet Delay Threshold Configuration is associated with a service type. The Packet Delay Threshold can be e.g., a time threshold value of the packet or a quantity of transmission attempts of the packet.

Figs. 9a-9d show four examples of efficient packet transmission according to embodiments of the invention.

Fig. 9a shows an example with an RSP using a priority timer in a DL scenario. In Fig. 9a, a delay timer (also referred to as a priority timer) has been configured to determine the packet delay status of a data packet for an URLLC service. A timer value of the priority timer is set to the before mentioned time threshold value. Until expiry of the priority timer any transmission and retransmission of the packet uses URLLC procedures. At expiry of the priority timer, the packet delay status is determined to be“Elapsed”, and any following retransmission of data packet shall use eMBB procedures. In a further embodiment, the priority timer can be implemented by means of a counter counting until the time threshold value.

Fig. 9b shows an example with an RSP configured as a counter also in a DL scenario. In Fig. 9b, the counter counts number of HARQ transmission. The counter can be configured with any number in implementation. In this example, the counter for determining the packet delay status as“Elapsed” is set to 2. Hence, after 2 transmission attempts, any further retransmission shall use eMBB procedures. As an example in such eMBB procedures the transmission can be scheduled on another Bandwidth Part, BWP with lower subcarrier spacing, SCS when compared to the URLLC procedure used for the first and second transmission attempt.

Fig. 9c shows an example with an RSP configured as a counter in a UL scenario. In Fig.9c, the counter counts the number of HARQ transmission. The counter can be configured with any number depending on the implementation. In the example the counter for determining the packet delay status as “Elapsed” is set to 2. Hence, after 2 transmissions any further retransmission may use eMBB procedures and hence the grant for retransmission may, for example, refer to a new Bandwidth Part, BWP with lower subcarrier spacing, SCS and as an example in such eMBB procedure, the transmission can be scheduled without any restriction in time when compared to the URLLC procedure used for the first and second transmission attempt.

Fig. 9d shows an example for the RLC layer. Acknowledge mode, AM is used for data transmission for a URLLC service. The RLC ARQ procedures are used. The RSP is configured as a counter of Negative Acknowledgements with the value of 1 . Hence, the first transmission of the RLC Protocol Data Unit, PDU shall utilize URLLC type of procedures and at reception of a NACK the packet delay status is determined as“Elapsed” and hence the RLC PDU shall be down prioritized to use the eMBB type of resources for the RLC PDU retransmission.

The client device 100 herein, may be denoted as a user device, a User Equipment (UE), a mobile station, internet of things (loT) device, a sensor device, a wireless terminal and/or a mobile terminal, is enabled to communicate wirelessly in a wireless communication system, sometimes also referred to as a cellular radio system. The UEs may further be referred to as mobile telephones, cellular telephones, computer tablets or laptops with wireless capability. The UEs in this context may be, for example, portable, pocket-storable, hand-held, computer- comprised, or vehicle-mounted mobile devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another receiver or a server. The UE can be a Station (STA), which is any device that contains an IEEE 802.1 1 -conformant Media Access Control (MAC) and Physical Layer (PHY) interface to the Wireless Medium (WM). The UE may also be configured for communication in 3GPP related LTE and LTE-Advanced, in WiMAX and its evolution, and in fifth generation wireless technologies, such as New Radio.

The network access nodes 120 herein may also be denoted as a radio client device, an access client device, an access point, or a base station, e.g. a Radio Base Station (RBS), which in some networks may be referred to as transmitter,“gNB”,“gNodeB”,“eNB”,“eNodeB”,� �NodeB” or“B node”, depending on the technology and terminology used. The radio client devices may be of different classes such as e.g. macro eNodeB, home eNodeB or pico base station, based on transmission power and thereby also cell size. The radio client device can be a Station (STA), which is any device that contains an IEEE 802.1 1 -conformant Media Access Control (MAC) and Physical Layer (PHY) interface to the Wireless Medium (WM). The radio client device may also be a base station corresponding to the fifth generation (5G) wireless systems.

Furthermore, any method according to embodiments of the invention may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer readable medium of a computer program product. The computer readable medium may comprise essentially any memory, such as a ROM (Read-Only Memory), a PROM (Programmable Read-Only Memory), an EPROM (Erasable PROM), a Flash memory, an EEPROM (Electrically Erasable PROM), or a hard disk drive.

Moreover, it is realized by the skilled person that embodiments of the client device 100 and the network access node 120 comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, MSDs, TCM encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

Especially, the processor(s) of the client device 100 and the network access node 120 may comprise, e.g., one or more instances of a Central Processing Unit (CPU), a processing unit, a processing circuit, a processor, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other processing logic that may interpret and execute instructions. The expression“processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like. Finally, it should be understood that the invention is not limited to the embodiments described above, but also relates to and incorporates all embodiments within the scope of the appended independent claims.