Handover handling

Abstract

There is provided a method for handling a handover (HO) of a wireless device from a source cell to a target cell of a communications network. The method is performed by a network node of the communications network. The method comprises estimating (302) a HO time. The HO time comprises an amount of time required for the wireless device to HO to the target cell. The method comprises receiving (304) one or more reports from the wireless device. Each report of the one or more reports comprises information indicative of an expiration time indicating a time remaining until a packet in a transmission queue of the wireless device expires. The method comprises initiating (306) the HO if the estimated HO time is less than a traffic cycle time. The traffic cycle time is determined based on the information comprised in the one or more reports, and the traffic cycle time corresponds to an amount of time between consecutive packets entering the transmission queue.

Description

[0001] HANDOVER HANDLING

[0002] Technical Field

[0003] The present disclosure relates to methods for handling a handover of a wireless device, and a network node and system configured to operate in accordance with those methods.

[0004] Background

[0005] Many industrial use cases utilize time-critical communication (TCC) traffic. This type of traffic usually has a low latency requirement. For example, TCC traffic can have a latency requirement of <100ms. In general, traffic periodicity can vary depending on the hardware involved in the communication of the traffic. For example, some devices have a traffic periodicity of around 10ms and have a delay requirement (delay budget) (e.g. watch-dog timer) of 30-40ms. In some other use cases (e.g. involving mobile robots and / or automated guided vehicles (AGVs)), the traffic periodicity may be in the range 30- 60ms, and the delay requirement may be similar. When the amount of (e.g. traffic) delay exceeds the delay requirement, the data packet is considered late or lost. In such scenarios, a watch-dog alert may be triggered when (e.g. 3-4 consecutive) packets are received late or become lost. When a watch-dog alert occurs in a use case such as an industrial production process, the process will be undesirably slowed down, or even stopped, for safety reasons.

[0006] Usually, latency in uplink (UL) communication is longer than in downlink (DL) communication. This is due to the higher availability of time resources in DL, and the lack of requirement of a scheduling request process. More specifically, in normal UL transmission, the UE sends a request to the network and the network sends a transmission grant back to the UE, such that the UE can send the data in UL. Delay, especially in UL, usually depends on the time spent on buffer status report (BSR) transmission delay (e.g. including scheduling request delay, UL grant delay, UL grant- to-PUSCH delay, etc.), the time taken in a queue by a scheduler, and the time taken to transmit data over-the-air (OTA). When a UE is moving from one cell to another (e.g. due to mobility), a handover (HO) event is triggered. Usually, HO events for TCC, especially for use cases that require low latency, should ideally be avoided. This is because HO results in HO-interruption, where an explicit radio resource configuration (RRC) signaling is triggered, which can result in extra delay (sometimes referred to as “HO-interruption time”). Normally, the HO-interruption corresponds to an amount of time that is longer than the delay requirements of TCC traffic, which is not acceptable for most TCC use cases (e.g. industrial use cases).

[0007] With regards to the reduction of HO-interruption, L1 / L2 triggered mobility (LTM) is a promising feature described in Third Generation Partnership Project (3GPP) Release 18, and is set to be improved in 3GPP Release 19. However, even with the use of LTM, HO- interruption could still amount to 30ms. In a worst case scenario, the total delay, including HO-interruption, BSR transmission delay, scheduling delay, and OTA delay, will exceed latency requirements, or may even trigger a watch-dog alert, which is not preferred in an industrial deployment.

[0008] One way to avoid HO-interruption is to attempt to retain a UE in its current serving cell for as long as possible. For example, the UE could be retained in the serving cell until the UE is out of control channel coverage, or the link to the current serving cell is too weak to support (e.g. TCC) service to the UE. However, one potential issue with this approach is that, when the UE is far away from its serving cell, and close to a neighboring cell the Reference Signal Received Power (RSRP) from the serving cell is some decibel (dB) weaker than the RSRP from the neighboring cell. As such the UE will suffer strong inter-cell interference in DL, and cause strong inter-cell interference in UL. Moreover, the interference generated in UL will impact other TCC UEs in the neighboring cell. Such a methodology will also eventually result in radio link failure (RLF) which can cause even longer delay for RRC connection and service recovery. Therefore, retaining the UE in its current serving cell for as long as possible is not an ideal solution for avoiding HO- interruption.

[0009] New Radio Dual Connectivity (NR-DC) could also help to move data transmission to a leg (e.g. connection and / or channel) not currently requiring HO. However, NR-DC requires a (e.g. industrial) network having both frequency range 1 (FR1) and frequency range 2 (FR2) bands available, and NR-DC to be deployed, which may not always be the case in every local dedicated network.

[0010] WO 2024 / 015341 discloses systems, methods and instrumentalities associated with performing HO. In more detail, the disclosure of WO 2024 / 015341 attempts to plan a HO such that the HO has less impact on user equipment (UE) traffic. However, there exist certain use cases with stringent requirements for low latency and packet loss that require improved HO timing precision than what is disclosed in WO 2024 / 015341. As mentioned above, there are certain challenges associated with existing techniques for handling HO. Indeed, wireless devices (e.g. UEs) can experience long latency during HO, which causes service disruption, especially for use cases involving industrial scenarios. Some existing techniques (e.g. LTM) can reduce the latency experienced during HO, but still have issues with HO interruption time. That is, even an HO interruption time of around 30ms is still undesirable for TOO services with stringent latency requirements.

[0011] It is an object of the disclosure to obviate or eliminate at least some of these challenges associated with existing techniques.

[0012] Therefore according to an aspect of the disclosure, there is provided a method for handling a handover (HO) of a wireless device from a source cell to a target cell of a communications network. The method is performed by a network node of the communications network. The method comprises estimating a HO time. The HO time comprises an amount of time required for the wireless device to HO to the target cell. The method also comprises receiving one or more reports from the wireless device. Each report of the one or more reports comprises information indicative of an expiration time indicating a time remaining until a packet in a transmission queue of the wireless device expires. The method also comprises initiating the HO if the estimated HO time is less than a traffic cycle time. The traffic cycle time is determined based on the information comprised in the one or more reports, and the traffic cycle time corresponds to an amount of time between consecutive packets entering the transmission queue.

[0013] According to another aspect of the disclosure, there is provided a network node comprising processing circuitry configured to operate in accordance with the method referred to herein. In some embodiments, the network node may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the network node to operate in accordance with the method referred to herein.

[0014] According to another aspect of the disclosure, there is provided a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method referred to herein. According to another aspect of the disclosure, there is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the method referred to herein.

[0015] Thus, in the manner described above, improved techniques for handling a HO of a wireless device are provided. Advantageously, the network node estimates a HO time and initiates the HO if the HO time is less than a traffic cycle time (which is determined based on one or more reports received from the wireless device). Thus, the technique beneficially utilises the one or more reports to predict a (e.g. traffic) pattern (e.g. periodicity and / or traffic arrival time) of the packets of the wireless device and initiate HO at a time that reduces the chances of service disruption being caused as a result of the HO. For example, the techniques described herein can be used to find a time for HO when a (e.g. residual) time delay budget of the wireless device is large enough to successfully complete a HO. Therefore, the information comprised in the one or more reports received from the wireless device can be used to improve the HO process (e.g. for TOO traffic). As such, the technique prevents (e.g. TOO) traffic(e.g. packets) arriving late from the wireless device, or becoming lost, as a result of HO.

[0016] Brief description of the drawings

[0017] For a better understanding of the techniques, and to show how they may be put into effect, reference will now be made, by way of example, to the accompanying drawings, in which:

[0018] Figure 1 is a signalling diagram illustrating an existing communication technique between a wireless device and a network;

[0019] Figure 2 is a signalling diagram illustrating an existing technique for performing HO;

[0020] Figure 3 is a block diagram illustrating a network node according to an embodiment;

[0021] Figure 4 is a block diagram illustrating a method performed by the network node according to an embodiment;

[0022] Figures 5 to 10 are block diagrams illustrating a method performed in accordance with some embodiments; and Figure 11 is a flow chart illustrating a method performed by the network node according to an embodiment.

[0023] Detailed Description

[0024] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0025] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject-matter disclosed herein, the disclosed subject-matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject-matter to those skilled in the art.

[0026] In some instances, detailed descriptions of well-known methods, entities, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more entities using hardware circuitry (e.g., analogue and / or discrete logic gates interconnected to perform a specialised function, ASICs, PLAs, etc.) and / or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Entities that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0027] The communications network referred to herein can be any type of communications network. For example, the communications network referred to herein may be a telecommunications network. In some embodiments, the communications network can be a mobile network, such as a fifth generation (5G) mobile network or any other generation mobile network (e.g. 6G). For example, the communications network can be a 5G core (5GC) network. In some embodiments, the communications network can be a radio access network (RAN). Although some examples have been provided for the type of communications network referred to herein, it will be understood that the communications network referred to herein can be any other type of communications network. The communications network can be referred to herein as the “network”.

[0028] The techniques described herein involve a wireless device. As used herein, a wireless device may refer to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other wireless devices (e.g. user equipment (UE)). Examples of a wireless device include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless camera, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptopmounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any wireless device identified by the 3GPP.

[0029] The techniques described herein relate to handover (HO) of a wireless device. HO can involve mobility (e.g. of a wireless device). As used herein, HO may refer to a process of transferring an (e.g. ongoing) communication session of a wireless device (e.g. a UE) from one cell (e.g. a base station and / or gNodeB (gNB)) to another cell. HO can be used to ensure seamless connectivity and / or continuity of service for (e.g. a user of) the wireless device. As such, HO can be especially useful when a wireless device is in transit, for example when a user of the wireless device is on the move. Herein, a HO of a wireless device can be described as being from a source cell to a target cell. The source cell can be understood to be the current (e.g. serving) cell of the wireless device. For example, for any given HO, the source cell can be the initial cell to which the wireless device is associated (e.g. connected). The target cell can be understood to be the cell that the wireless device transfers to upon a successful HO. However, it will be understood that, in some scenarios, a HO may not be successful (i.e. the HO can fail). In such a scenario, the target cell can be understood to be the cell that the wireless device attempts to connect to via HO. It will be understood that a HO, as described herein, may be performed for one or more reasons, such as wireless device mobility, coverage, load, and / or bandwidth triggered HO

[0030] Figure 1 is a signalling diagram illustrating an example exchange of signals between a wireless device 100 and a network entity 102 according to an existing technique. In the example illustrated in Figure 1 , a process of sending packets (e.g. traffic) from the wireless device 100 to the network entity 102 is illustrated. Herein, packets can comprise traffic data and / or information. As such, a packet may be referred to herein as a data packet.

[0031] As illustrated by arrow 104 of Figure 1 , a first packet enters a transmission queue of the wireless device 100 (“Packet #1 In”). A packet entering the transmission queue of the wireless device 100 may be referred to herein as a packet entering a buffer of the wireless device 100. As illustrated by arrow 106 of Figure 1 , the wireless device 100 transmits a scheduling request (SR) towards the network entity 102. Thus, the network entity 102 receives the SR from the wireless device 100. The SR can comprise a request for the wireless device 100 to transmit data and / or information (e.g. the first packet) towards the network entity 102. As illustrated in the example of Figure 1 , there is some delay (“SR transmission delay”) between the first packet entering the transmission queue of the wireless device 100 and the transmission of the SR.

[0032] As illustrated by arrow 108 of Figure 1 , the network entity 102 transmits a grant message (“Grant”) towards the wireless device 100. Transmission of the grant message can be initiated in response to receiving the SR from the wireless device 100. The grant message can comprise information that the wireless device 100 is allowed to transmit data and / or information (e.g. the first packet) via UL (e.g. using one or more network resources indicated in the grant message).

[0033] As illustrated in Figure 1 , there can be some delay (“UL-grant to PUSCH delay”) between receipt of the grant message (as described with reference to arrow 108 of Figure 1) and the associated data transmission (as described with reference to arrow 116 of Figure 1). The delay (“UL-grant to PUSCH delay”) typically contains a waiting time of the wireless device 100 for a UL slot in which to transmit data and / or information (e.g. of the first packet). The specific UL slot can be specified in the grant message. As illustrated by arrow 110 of Figure 1 , during this time, multiple grants can be sent from the network entity 102 to the wireless device 100. For example, if the grant message as described with reference to arrow 108 of Figure 1 only gives the wireless device 100 a small resource block for the UL transmission, the wireless device 100 may only be able to transmit a buffer status report. In this scenario, the network entity 102 may need to send another grant message to the wireless device 102. In another example, the network entity 102 can transmit multiple grant messages to the wireless device 100 (e.g. if a packet is too large and is segmented into multiple UL transmissions over time). In another example, if the wireless device 100 fails to correctly decode the grant message, the network entity 102 may consider it as a transmission failure and initiate a retransmission process to send another grant message to the wireless device 100.

[0034] As illustrated by arrows 112 and 116 of Figure 1 , the wireless device 100 transmits the first packet towards the network entity 102 (“Data transmission”). In many industrial use cases, the packet may comprise a (e.g. small enough) amount of data and / or information such that one UL transmission may be sufficient for the packet to be transmitted. However, in some cases, transmission of the data and / or information associated with the first packet may require multiple UL transmissions (e.g. if the amount of data and / or information is large). In such a case, the data transmission process illustrated by arrows 112 and 116 of Figure 1 can last from a first transmission until a last transmission of the data and / or information associated with the first packet. As illustrated by arrow 114 of Figure 1 , the amount of time between the first packet entering the transmission queue of the wireless device 100 (i.e. as illustrated with respect to arrow 104 of Figure 1), and the transmission initiation of the first packet, can be referred to as “Overhead latency”. The duration of the overhead latency may be different depending on how the network entity 102 provides grant(s) to the wireless device 100. Figure 1 illustrates the case where a scheduling request is needed in order to obtain a grant. However, in some scenarios, the network entity 102 may use prescheduling (e.g. omitting the step as described with reference to arrow 106 of Figure 1) or configured grant (e.g. omitting the steps as described with reference to arrows 106 and 108of Figure 1). As illustrated by arrow 118 of Figure 1 , the first packet is received by the network entity 102 before the first packet is considered to be expired (e.g. by the network node). As mentioned herein, if a packet is not received from the wireless device 100 before a threshold amount of time elapses, the packet can be considered expired (e.g. by the network entity 102), which is undesirable. As illustrated by arrow 122 of Figure 1 , the amount of time between a packet (e.g. the first packet) entering the transmission queue of the wireless device, and the receipt of the packet by the network entity 102, can be referred to herein as “UL latency”. As illustrated by arrow 120 of Figure 1 , the amount of time between transmission initiation of a packet (e.g. the first packet), and the receipt of the packet by the network entity 102, can be referred to herein as “Data transmission latency”. The data transmission latency can be said to correspond to an OTA delay, as defined herein.

[0035] As illustrated by arrow 126 of Figure 1 , a second packet (“Packet #2”) can enter the transmission queue of the wireless device 100. The steps illustrated by arrows 128, 130 and 132 of Figure 1 can be as described with reference to arrows 106, 108 and 116 of Figure 1 respectively, with the exception that the steps illustrated by arrows 128, 130 and 132 are carried out in respect of the second packet instead of the first packet.

[0036] Arrow 124 of Figure 1 illustrates a point in time at which receipt of the first packet by the network entity 102 from the wireless device 100 is considered late and / or lost. This point in time can be referred to herein as the expiry of the first packet. As illustrated by arrow 126 of Figure 1 , a second packet can enter the transmission queue of the wireless device 100. As illustrated in Figure 1 , the point in time at which a subsequent packet (e.g. the second packet of Figure 1) enters the transmission queue of the wireless device 100 can correspond to the expiration time of the previous packet (e.g. the first packet of Figure 1). For example, the availability of a new packet can result in the previous (e.g. old) packet being considered redundant (e.g. in the network entity 102).

[0037] Arrow 134 of Figure 1 illustrates a point in time at which receipt of the second packet by the network entity 102 from the wireless device 100 is considered late and / or lost. This point in time corresponds to the expiry of the second packet. As illustrated by arrow 136 of Figure 1 , a third packet can enter the transmission queue of the wireless device 100. Transmission of packets can occur in the manner described with reference to Figure 1 in order to, for example, maintain a service used and / or provided by the wireless device 100.

[0038] Figure 2 is a signalling diagram illustrating an example exchange of signals between a wireless device 100 and a network entity 102. The example of Figure 2 illustrates an issue that can arise in existing systems as a result of performing a HO. The steps illustrated by arrows 206 to 224 of Figure 2 can be as described with reference to arrows 106 to 124 of Figure 1 respectively.

[0039] As illustrated at block 240 of Figure 2, a HO is performed. For example, the wireless device 100 can perform the HO from a source cell to a target cell of the network, as described herein. As also illustrated by block 240 of Figure 2, interruption (“HO interruption”) is caused by (e.g. actively) performing the HO. The interruption caused by the HO can be associated with a process of transferring an (e.g. ongoing) communication session of the wireless device 100 from one cell to another cell, as described herein. The HO interruption can be associated with some amount of time in which the (e.g. normal) communication of the wireless device 100 with the network is interrupted. Although not explicitly illustrated in Figure 2, it will be understood that the network entity 102 is different after HO. That is, the wireless device 100 can be said to communicate with a first network entity (e.g. of a source cell) before performing HO, and a second network entity (e.g. of a target cell) after HO is complete.

[0040] As illustrated by arrow 226 of Figure 2, a second packet (“Packet #2”) can enter the transmission queue of the wireless device 100. As illustrated in Figure 2, the second packet enters the transmission queue of the wireless device 100 while the HO is being performed. As such, the second packet enters the transmission queue during the period of HO interruption. During the HO interruption, the wireless device 100 is unable to communicate packets to the network entity 102 (e.g. the first network entity or the second network entity, as defined herein). As such, the wireless device 100 must delay the handling of the second packet until the HO process is completed (e.g. successfully or unsuccessfully). As illustrated in Figure 2, once the HO process is complete (i.e. the HO interruption period has ended), the wireless device 100 is able to communicate the second packet to the network entity 102 (e.g. the first network entity or the second network entity, as defined herein).

[0041] As illustrated by arrow 228 of Figure 2, the wireless device 100 transmits a scheduling request (SR) towards the network entity 102. Thus, the network entity 102 receives the SR from the wireless device 100. The SR can comprise a request for the wireless device 100 to transmit data and / or information (e.g. the second packet) towards the network entity 102. As illustrated in the example of Figure 2, the delay between the first packet entering the transmission queue of the wireless device 100 and the transmission of the SR, as described with reference to arrow 206 of Figure 2, is relatively shorter than the delay between the second packet entering the transmission queue of the wireless device 100 and the transmission of the SR as described with reference to arrow 228 of Figure 2 (i.e. due to the performance of the HO).

[0042] As illustrated by arrow 230 of Figure 2, the network entity 102 transmits a grant message (“Grant”) towards the wireless device 100. Transmission of the grant message can be initiated in response to receiving the SR from the wireless device 100. The grant message can comprise information that the wireless device 100 is allowed to transmit data and / or information (e.g. the second packet) via UL (e.g. using one or more network resources). As illustrated by arrow 236 of Figure 2, a third packet (“Packet #3”) enters the transmission queue of the wireless device 100. Arrow 234 of Figure 2 illustrates a point in time, after which receipt of the second packet by the network entity 102 from the wireless device 100 is considered late and / or lost (e.g. expired).

[0043] As illustrated by arrow 232 of Figure 2, the wireless device 100 transmits the second packet towards the network entity 102. Thus, the network entity 102 receives the second packet from the wireless device 100. However, as illustrated by arrow 238 of Figure 2, the second packet is received by (e.g. arrives at) the network entity 102 after the point in time at which the second packet is considered late and / or lost. As such, the second packet arrives at the network entity 102 (e.g. network side) after the second packet is (e.g. considered) expired. Therefore, the handling of the second packet has not met latency requirements.

[0044] Figure 2 illustrates the challenges associated with meeting strict latency requirements (e.g. for TOO traffic) in the context of a wireless device 100 (e.g. a UE) performing HO. The long latency caused by performing HO can causes service disruption, which is especially disadvantageous for use cases involving industrial scenarios.

[0045] Figure 3 illustrates a network node 10 of a communications network in accordance with an embodiment. The network node 10 is for handling a HO of a wireless device from a source cell to a target cell of the communications network. In some embodiments, the network node 10 referred to herein can refer to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with the wireless device referred to herein, and / or with other nodes or equipment to enable and / or to perform the functionality described herein. In some embodiments, the network node 10 referred to herein can, for example, be a physical node (e.g. a physical machine or server) or a virtual node (e.g. a virtual machine, VM).

[0046] As illustrated in Figure 3, the network node 10 comprises processing circuitry (or logic) 12. The processing circuitry 12 controls the operation of the network node 10 and can implement the method described herein in respect of the network node 10. The processing circuitry 12 can be configured or programmed to control the network node 10 in the manner described herein. The processing circuitry 12 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and / or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the network node 10. In some embodiments, the processing circuitry 12 can be configured to run software to perform the method described herein in respect of the network node 10. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 12 may be configured to run a container to perform the method described herein in respect of the network node 10.

[0047] Briefly, the processing circuitry 12 of the network node 10 is configured to estimate a HO time. The HO time comprises an amount of time required for the wireless device to HO to the target cell. The processing circuitry 12 of the network node 10 is also configured to receive one or more reports from the wireless device. Each report of the one or more reports comprises information indicative of an expiration time indicating a time remaining until a packet in a transmission queue of the wireless device expires. The processing circuitry 12 of the network node 10 is also configured to initiate the HO if the estimated HO time is less than a traffic cycle time. The traffic cycle time is determined based on the information comprised in the one or more reports, and the traffic cycle time corresponds to an amount of time between consecutive packets entering the transmission queue

[0048] As illustrated in Figure 3, in some embodiments, the network node 10 may optionally comprise a memory 14. The memory 14 of the network node 10 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 14 of the network node 10 may comprise a non-transitory media. Examples of the memory 14 of the network node 10 include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital versatile disk (DVD), and / or any other memory.

[0049] The processing circuitry 12 of the network node 10 can be communicatively coupled (e.g. connected) to the memory 14 of the network node 10. In some embodiments, the memory 14 of the network node 10 may be for storing program code or instructions which, when executed by the processing circuitry 12 of the network node 10, cause the network node 10 to operate in the manner described herein in respect of the network node 10. For example, in some embodiments, the memory 14 of the network node 10 may be configured to store program code or instructions that can be executed by the processing circuitry 12 of the network node 10 to cause the network node 10 to operate in accordance with the method described herein in respect of the network node 10. Alternatively or in addition, the memory 14 of the network node 10 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 12 of the network node 10 may be configured to control the memory 14 of the network node 10 to store any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0050] In some embodiments, as illustrated in Figure 3, the network node 10 may optionally comprise a communications interface 16. The communications interface 16 of the network node 10 can be communicatively coupled (e.g. connected) to the processing circuitry 12 of the network node 10 and / or the memory 14 of the network node 10. The communications interface 16 of the network node 10 may be operable to allow the processing circuitry 12 of the network node 10 to communicate with the memory 14 of the network node 10 and / or vice versa. Similarly, the communications interface 16 of the network node 10 may be operable to allow the processing circuitry 12 of the network node 10 to communicate with any one or more nodes (e.g. the wireless device referred to herein) referred to herein and / or any other node. The communications interface 16 of the network node 10 can be configured to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 12 of the network node 10 may be configured to control the communications interface 16 of the network node 10 to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. Although the network node 10 is illustrated in Figure 3 as comprising a single memory 14, it will be appreciated that the network node 10 may comprise at least one memory (i.e. a single memory or a plurality of memories) 14 that operate in the manner described herein. Similarly, although the network node 10 is illustrated in Figure 3 as comprising a single communications interface 16, it will be appreciated that the network node 10 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 16 that operate in the manner described herein. It will also be appreciated that Figure 3 only shows the components required to illustrate an embodiment of the network node 10 and, in practical implementations, the network node 10 may comprise additional or alternative components to those shown.

[0051] Figure 4 illustrates a method performed by a network node 10 in accordance with an embodiment. The method is for handling a HO of a wireless device from a source cell to a target cell of a communications network. The network node 10 described earlier with reference to Figure 3 can be configured to operate in accordance with the method of Figure 4. The method can be performed by or under the control of the processing circuitry 12 of the network node 10 according to some embodiments.

[0052] As mentioned herein, a wireless device can perform a HO from a source cell to a target cell. In some examples, the network node 10 may be comprised in the source cell. For example, the network node 10 may be a serving network node for the wireless device in the source cell. Herein, a HO may be said to be performed by one or more (e.g. different) entities. For example, the performance of a HO of a wireless device can involve an entity of the source cell (e.g. the network node 10) and the wireless device itself. In some cases, the performance of a HO can also involve an entity of the target cell. As such, multiple entities can be described herein as performing (e.g. at least in part) the HO of the wireless device.

[0053] With reference to Figure 4, at block 302, a HO time is estimated. The network node 10 (e.g. the processing circuitry 12 of the network node 10) can be configured to perform this estimation. The HO time comprises an amount of time required for the wireless device to HO to the target cell. The HO time can, for example, comprise an amount of time between the initiation of a HO procedure and the termination (e.g. completion) of the HO procedure. In some examples, the HO time may be an estimate of the amount of time required for the wireless device to perform a successful HO. However, it will be understood that, in some cases, HO may not (e.g. successfully) occur even if the HO procedure is initiated. For example, the HO procedure may fail and / or be delayed. It will be understood that the estimation of HO time does not require that a successful HO is completed. Therefore, the estimation of HO time can comprise estimating the time that the wireless device would (e.g. statistically) require during an HO event in the communications network. Herein, the HO time may be understood to comprise “HO interruption time” and / or “interruption time”.

[0054] As illustrated by block 304 of Figure 4, one or more reports are received from the wireless device. The network node 10 (e.g. the processing circuitry 12 of the network node 10) can receive the one or more reports (e.g. via the communications interface 16 of the network node 10). Each report of the one or more reports comprises information indicative of an expiration time indicating a time remaining until a packet in a transmission queue of the wireless device expires. In some examples, the packet in the transmission queue of the wireless device may correspond to the packet in the transmission queue at the time at which the wireless device initiated transmission of the report. In some examples, a packet may be considered expired if the content of the packet (e.g. the information and / or data comprised in the packet) is no longer useful, for example, to the communications network (e.g. the source cell and / or the target cell). In some examples, a packet may be discarded (e.g. from the transmission queue of the wireless device) if the packet expires. The transmission queue of the wireless device, as referred to herein, may be referred to herein as a “buffer” and / or a “transmit buffer” of the wireless device. The transmission queue of the wireless device may be used to (e.g. temporarily) store packets that are to be transmitted towards (e.g. one or more other entities in) the communication network.

[0055] In some examples, the information comprised in each report of the one or more reports may comprise information indicative of an amount of time elapsed since a packet entered the transmission queue of the wireless device. Herein, the information comprised in the one or more reports can be used to determine (e.g. estimate) a time when a packet expires, as defined herein. The time at which a packet expires can, for example, correspond to the time at which a new (e.g. next) packet enters the transmission queue of the wireless device. As illustrated by block 306 of Figure 4, the HO is initiated if the estimated HO time is less than a traffic cycle time. The network node 10 (e.g. the processing circuitry 12 of the network node 10) can be configured to initiate the HO. Herein, the term “initiate” can mean, for example, cause or establish. Thus, the network node 10 (e.g. the processing circuitry 12 of the first network node 10) can be configured to itself initiate the HO (e.g. via the communications interface 16 of the network node 10) or can be configured to cause another entity (e.g. the wireless device) to initiate the HO. The traffic cycle time is determined based on the information comprised in the one or more reports. The traffic cycle time corresponds to an amount of time between consecutive packets entering the transmission queue. In some examples, the one or more reports can comprise a plurality of reports. In these examples, the traffic cycle time can be determined based on the information comprised in the plurality of the one or more reports. Therefore, in some examples, the traffic cycle time referred to herein may be an average traffic cycle time. The traffic cycle time can correspond to an average amount of time between consecutive packets entering the transmission queue of the wireless device. The traffic cycle time can be referred to herein as “T”.

[0056] Thus, the network node can determine a criterion (i.e. based on the estimate HO time and traffic cycle time) based on which the network node can decide whether to allow the wireless device (e.g. with TCC traffic) to proceed to HO.

[0057] As mentioned above with reference to block 302 of Figure 4, the method comprises estimating a HO time. In some examples, estimating the HO time can comprise performing one or more filed measurements to determine the amount of time required for the wireless device to HO. In some examples, estimating the HO time may comprise performing a simulation of the HO to determine the amount of time required for the wireless device to HO. Alternatively, or in addiction, in some examples, estimating the HO time may comprise (e.g. analytically) summing up the time required to perform each step of the HO (e.g. event). The HO interruption time may not be a constant value in all scenarios. In some examples, estimating the HO time may comprise determining a percentile value of a plurality of (e.g. recorded and / or stored) HO times. The percentile value could be high to avoid optimistically estimating the HO interruption time. For example, the HO time could be estimated to be a 99.9 percentile of multiple HO interruption times. Herein, the amount of time required for the wireless device to HO can be referred to as tHo. The estimation of tHo may vary depending on one or more features and / or characteristics of the HO. For example, the estimation of the tHo can depend on HO features such as LTM, Contention Free Random Access, and / or Multi Radio Link.

[0058] In some examples, the communications network can tolerate receiving one or more (e.g. consecutive) packets late from the wireless device. The communications network may be configured to tolerate one or more late, lost, and / or expired packets without the communications network triggering an (e.g. watch-dog) alert. For example, the network node 10 may only trigger an alert if at least four consecutive packets are received late from the wireless device. In such an example, the communications network can be said to tolerate receiving at least three packets late from the wireless device.

[0059] Although not illustrated in Figure 4, in some examples, the method may comprise initiating the HO if the estimated HO time is less than an amount of time corresponding to a product of the traffic cycle time and a first integer number. The first integer number can be determined based on the amount of one or more packets that the communications network can tolerate receiving late. For example, the communications network may be able to tolerate receiving k-1 packets late from the wireless device (where k is an integer number), k-1 may be a (e.g. maximum) limit of late packets that can be tolerated by the communications network. That is, in some examples, the communications network may be unable to tolerate receiving k (e.g. consecutive) packets late. In such an example, the first integer number referred to herein may be equal to k. In this example, the amount of time corresponding to a product of the traffic cycle time and a first integer number can be determined as k*T (where T is the traffic cycle time as defined herein).

[0060] In some examples, the information comprised in each report of the one or more reports may comprise information indicative of a transmission time of the report. For example, the information comprised in each report can be indicative of the time at which the transmission of the report was initiated by the wireless device.

[0061] Although not illustrated in Figure 4, in some examples, the method may comprise, if the estimated HO time is greater or equal to the traffic cycle time, initiating the HO procedure if a modified HO time is less than a modified traffic cycle time. The modified HO time can comprise at least the estimated HO time, as defined herein. The modified traffic cycle time can comprise the expiration time and an amount of time corresponding to a product of the traffic cycle time and a second integer number. The second integer number may be determined based on the number of late packets that the communications network can tolerate receiving late. The second integer number may be the same or different to the first integer number referred to herein.

[0062] For example, in some cases, the network may be able to tolerate receiving k-1 late packets, but cannot tolerate receiving k late packets (where k is an integer number, e.g. 3). In such a scenario, the second integer number may be equal to k. As such, in some examples, the amount of time corresponding to a product of the traffic cycle time and the second integer number can be equal to k*T. For example, the network may be able to tolerate receiving 2 late packets, but may be unable to tolerate receiving 3 late packets. In this example, k can be said to be equal to 3, and thus k*T = 3T.

[0063] In some examples, although not illustrated in Figure 4, the method may comprise, if the estimated HO time is greater or equal to the traffic cycle time, determining whether the modified HO time is less than the modified traffic cycle time. Thus, in some examples, if it is determined that a delay budget of the wireless device is too small, and / or the estimated HO time is too long, the network node 10 can determine (e.g. check) if the modified HO time is less than the modified traffic cycle time. In this way, there can exist a fallback option for initiating HO.

[0064] Although not illustrated in Figure 4, in some examples, the method may comprise, if the modified HO time is greater or equal to the modified traffic cycle time, delaying the HO. For example, if the modified HO time is not less than the modified traffic cycle time, then the network node 10 may not allow the wireless device to perform a (e.g. mobility triggered) HO. In some examples, delaying the HO may comprise avoiding the HO (e.g. by configuring a larger threshold for HO measurement events). By delaying and / or avoiding the HO, the occurrence of undesirable late packets due to HO can be reduced and / or avoided. A decision to delay HO may be valid for some period of time. For example, HO may be delayed in the hope that the channel quality of the wireless device improves (e.g. the wireless device may move back towards the source cell), thus removing the need to HO. In some examples, the delay to HO may exist until the wireless device causes a large enough impact (e.g. interference) to other network entities (e.g. wireless devices). The degree of impact may be determined (e.g. measured) by the network node 10.

[0065] Although also not illustrated in Figure 4, in some examples, the method may comprise initiating transmission of a first message towards a server of the communications network. The first message can comprise information indicative of a delay of the HO, as described herein. In this way, in cases in which a HO is really needed (e.g. because the wireless device will cause significant impact to other network entities if it does not HO) then the network node 10 (e.g. of the source cell) can notify the (e.g. time-critical service) server to expect some long latency due to the HO process of the wireless device.

[0066] In scenarios in which upcoming (e.g. time-critical) traffic may experience long latency due to a delay to the HO process, the information comprised in the first message can comprise information indicative of the estimated HO time. In this way, the network node 10 (e.g. of the source cell) can inform the (e.g. application) server to expect some long delays for some period of time (e.g. based on the estimated HO time). Upon receiving the information, the (e.g. application) server may expect some longer delay from the wireless device. As such, the server may adjust a watchdog timer for the wireless device so as not to trigger an alarm or cause an emergency break in service. If the wireless device connects to the target cell successfully, the target cell may inform the server that the HO process is finished, and the server may revert the watchdog timer to a default configuration (e.g. as described with reference to Figure 10 below).

[0067] Although not illustrated in Figure 4, in some examples, the method may comprise determining the expiration time, as referred to herein, based on the information comprised in the one or more reports. In some examples, the method may comprise initiating transmission of information indicative of the expiration time towards the target cell. Thus, the target cell can receive the information indicative of the expiration time from the network node 10.

[0068] Although also not illustrated in Figure 4, in some examples, the method may comprise estimating a packet entry time based on the information comprised in the one or more reports. The packet entry time can correspond to a time at which a next subsequent packet will enter the transmission queue of the wireless device. The estimation of the next subsequent packet can correspond to a prediction of a (e.g. point in) time at which a next packet is due to enter the transmission queue of the wireless device. The estimation of the packet entry time can be based on the expiration time, as defined herein.

[0069] In some examples, the method may comprise estimating a subsequent transmission time. The subsequent transmission time can correspond to a time at which the wireless device is able to initiate transmission of the next subsequent packet. The subsequent transmission time can correspond to a point in time at which the wireless device is able to initiate transmission of the next subsequent packet. For example, the subsequent transmission time can be the time that the source cell (e.g. the network node 10) would allow the wireless device to initiate transmission of a new packet (e.g. in the next UL slot after the next subsequent packet enter the transmission queue of the wireless device). The subsequent transmission time can be referred to herein as “tuL, next”.

[0070] In some examples, the method may comprise initiating transmission of a second message towards the wireless device before (e.g. prior to) the subsequent transmission time. The second message can comprise pre-scheduling information associated with transmission of the next subsequent packet. For example, based on the estimation (e.g. calculation) of the subsequent transmission time, the network node 10 (e.g. of the source cell) can send pre-scheduling information to the wireless device before the subsequent transmission time. The pre-scheduling information can enable the wireless device to transmit a packet (e.g. the subsequent packet referred to herein) to the network node 10 at the subsequent transmission time (e.g. via uplink). The pre-scheduling information can, for example, comprise information associated with a UL grant (e.g. resource).

[0071] In some examples, initiating the HO may comprise initiating transmission of a HO command towards the wireless device. Thus, the wireless device can receive the HO command from the network node 10. The HO command can comprise a request for the wireless device to perform the HO immediately after the subsequent transmission time, as defined herein. Therefore, the network node 10 (e.g. of the source cell) can configure the wireless device to proceed to HO soon after the subsequent transmission time tui_, next. For example, the wireless device may perform HO in response to transmitting the next subsequent packet (e.g. newly arrived time-critical packet). The time at which the network node 10 initiates transmission of the HO command towards the wireless device does not necessarily need to be after the wireless device has sent the next subsequent packet, as defined herein. In some examples, the wireless device may require some time to decode the HO command. As such, in some examples, the network node 10 (e.g. of the source cell) can send the HO command (e.g. slightly) early, and / or include information in the HO command that is indicative of how many timeslot(s) should occur between (e.g. receipt of) the HO command (e.g. downlink control information (DCI) / Physical Downlink Control Channel (PDCCH)) and the time at which the wireless device begins the HO. For example, if the information comprised in the HO command is indicative that x time slots(s) should occur between the HO command and the time at which the wireless device begins the HO, the HO command may be sent x-1 timeslots before the subsequent transmission time (tui_, next), such that the wireless device can begin HO at the timeslot after tui_, next.

[0072] In some examples, transmission of the HO command may only be initiated if the next subsequent packet, as defined herein, is received from the wireless device. In these examples, the HO command can be a conditional command. For example, if the wireless device receives an acknowledgment (ACK) that it can perform HO after it sends the next subsequent packet, then the wireless device can proceed to HO. If the wireless device receives a negative acknowledgement (NACK) indicating that it is not able to HO, then the wireless device may delay the HO. In such a scenario the source cell may estimate another subsequent transmission time and / or repeat some procedures. In some examples, the method may comprise, if the next subsequent packet is not received from the wireless device, delaying transmission initiation of the HO command. In some examples, the network node 10 may initiate transmission of a third message towards the target cell. The third message can comprise information indicative of a delay to transmission initiation of the HO command. Therefore, in some examples, if the next subsequent packet is not (e.g. successfully) received from the wireless device, the network node 10 (e.g. of the source cell) may not send the HO command to the wireless device, and / or may notify the target cell that the HO will be postponed. The information indicative of the delay to the transmission initiation of the HO command can comprise a postponed time. The postponed time may correspond to an amount of time until the network node 10 is expected to receive the next subsequent packet.

[0073] In some examples, if the next subsequent packet is not received from the wireless device, the method may comprise initiating transmission, towards the wireless device, of a request for retransmission of the next subsequent packet. Thus, in some examples, the network node 10 (e.g. of the source cell) can request a retransmission of the (e.g. lost) packet from the wireless device (e.g. at the same time as initiating transmission of the third message referred to herein). In some examples, the HO command referred to herein can comprises radio resource control, RRC, configuration information. Although not illustrated in Figure 4, in some examples, the method may comprise performing the HO in response to receiving the next subsequent packet from the wireless device. For example, the network node 10 may trigger the wireless device to perform HO right after the transmission of the next subsequent packet. In this way, the wireless device can have sufficient time to transmit the packet following the next subsequent packet (e.g. after the wireless device has performed HO to the target cell). Therefore, the HO can be scheduled to take place right after the last (e.g. PUSCH) transmission from the wireless device to the target cell in order to gain maximum time budget for the next UL packet (e.g. in the target cell) and thus minimize packet delay and possible packet loss upon HO. This is especially advantageous when applied to time critical communication UEs performing HO. In some examples, the network node 10 (e.g. via a grant message transmitted to the wireless device) may configure a wireless device transmission with higher reliability. For examples, the network node 10 may configure the wireless device to use a robust enough modulation and coding scheme (MCS) and / or use a higher transmit power. In this way, it can be ensured that the transmission of the next subsequent packet will be successfully received (e.g. with large enough probability).

[0074] As described herein, in some examples, the traffic cycle time can correspond to an average amount of time between consecutive packets entering the transmission queue of the wireless device. For example, the determination of the traffic cycle time can take into account multiple packets which have entered the transmission queue of the wireless device. Although not illustrated in Figure 4, in some examples, the method may comprise initiating transmission of information indicative of the traffic cycle time towards the target cell. As such, the target cell can be made aware of the traffic periodicity of the wireless device.

[0075] As mentioned herein, the estimated HO time comprises an amount of time required for the wireless device to HO to the target cell. The amount of time required for the wireless device to HO to the target cell can be referred to herein as tHo. In some examples, the estimated HO time can comprise one or more of an amount of time required for a grant procedure between the wireless device and the network node to be completed, an amount of time required for a packet to be transmitted from the wireless device to the network node, and a timing margin. The amount of time required for a grant procedure between the wireless device and the network node to be completed can be referred to herein as tSR. In some examples, the amount of time required for the grant procedure between the wireless device and the network node to be completed may comprise an amount of time between transmission initiation of a scheduling request by the wireless device towards the network node, and receipt, by the wireless device, of a response to the scheduling request from the network node. For example, the amount of time required for a grant procedure between the wireless device and the network node to be completed can correspond to the time required for the process starting from a wireless device initiating transmission of a scheduling request (SR) until the wireless device receiving a grant and / or being ready to initiate transmission of data (e.g. a packet) associated with the SR. In some examples, the amount of time required for the grant procedure between the wireless device and the network node 10 to be completed may comprise the time between the network node 10 initiating transmission of a pre-scheduled grant towards the wireless device and receipt of the pre-scheduled grant by the wireless device. The amount of time required for a packet to be transmitted from the wireless device to the network node can be referred to herein as tdata. The amount of time required for a packet to be transmitted from the wireless device to the network node can correspond to the time required for data transmission over the air. The timing margin can be referred to herein as A. The timing margin can be an amount of time corresponding to an (e.g. error) offset. For example, the timing margin may comprise a time duration of one or more time subframes. In some examples, the estimated HO time may be equal to tno + tsR + tdata + A.

[0076] Although not illustrated in Figure 4, in some examples, the method may comprise estimating one or more of the amount of time required for a grant procedure between the wireless device and the network node to be completed, the amount of time required for a packet to be transmitted from the wireless device to the network node, and the timing margin.

[0077] In some examples, the modified HO time, as referred to herein, may comprise the amount of time required for the grant procedure between the wireless device and the network node to be completed, an amount of time equal to double the time required for a packet to be transmitted from the wireless device to the network node, and the timing margin. In some examples, the modified HO time may be equal to tno + tsR + 2tdata + A.

[0078] Although not illustrated in Figure 4, in some examples, the method may comprise receiving, from the target cell, a response to a request to perform the HO. In some examples, the HO may only be performed if the response received from the target cell is indicative that the target cell is able to perform the HO. Although also not illustrated in Figure 4, in some examples, the method may comprise initiating transmission of the request to perform the HO towards the target cell. Thus, the target cell can receive the request to perform the HO from the network node 10. Therefore, in some examples, the network node 10 (e.g. of the source cell) can send the HO request to the target cell (e.g. gNB). If the target cell admits the UE, and informs the network node 10 accordingly, then the HO may proceed. If the response to the request to perform the HO is indicative that the target cell is unable to perform the HO, then the network node 10 may delay the HO, as defined herein. In some examples, if the network node 10 does not receive a response to the request to perform the HO, then the network node 10 may delay the HO.

[0079] As described above, in some examples, the network node 10 (e.g. of the source cell) may send an HO request to the target cell (e.g. a gNB of the target cell). If the target cell accepts the HO request (e.g. admits the wireless device), and informs the source cell, then the network node 10 (e.g. of the source cell) may then send the HO command, as defined herein, to the wireless device. The HO command may comprise an RRC reconfiguration. The HO command referred to herein may comprise instructions for the wireless device to disconnect from the source cell (e.g. at a time slot right after it transmits the next subsequent packet, as defined herein) and to connect to the target cell.

[0080] Although not illustrated in Figure 4, in some examples, the method may comprise receiving, from the wireless device, a measurement report. The measurement report may be a mobility report according to some examples. The measurement report may comprise information indicative of a measured signal quality of the source cell and / or a measured signal quality of the target cell. For example, the measurement report can comprise information indicative of a reference signal received power (RSRP), reference signal received quality (RSRQ), and / or a signal-to-interference-plus-noise ratio (SINR). Thus, the measurement report can comprise information indicative of the signal quality of the serving cell and / or on or more neighbouring cells. The measurement report may be a different report to the one or more reports referred to herein (e.g. as described with reference to block 304 of Figure 4). Although not illustrated in Figure 4, in some examples, the method may comprise determining, based on the measurement report, that the wireless device should perform the HO. As such, in some examples, the measurement report may trigger the decision on whether (e.g. when and / or how) to perform the HO. The measurement report may be received prior to the initiation of the HO (e.g. as described with reference to block 302 of Figure 4). Although not illustrated in Figure 4, in some examples, the method may comprise initiating transmission of reporting information towards the wireless device. Thus, the wireless device can receive the reporting information from the network node 10. The reporting information can be indicative of a criterion for initiating transmission of a report of the one or more reports, as defined herein, by the wireless device. In some examples, the criterion can be met if an amount of time until expiry of a first packet in the transmission queue of the wireless device is less than a threshold amount of time. In some examples, the threshold amount of time can be configured by the network node 10.

[0081] Although also not illustrated in Figure 4, in some examples, the method may comprise determining the threshold amount of time. Herein, the threshold amount of time may be referred to as tDSRjhreshoid. The network node 10 may initiate transmission of the reporting information to multiple wireless devices. For example, the network node 10 may initiate transmission of the reporting information to one or more wireless devices (e.g. UEs) that would like to avoid late packet(s) due to HO. The one or more wireless devices can report the one or more reports, as defined herein, based on tDSRjhreshoid. For example, when a data packet of the one or more wireless devices has a remaining delay budget smaller than tDSRjhreshoid, the one or more wireless devices may attempt to send a report to the network node 10. In some examples, determining (e.g. calculating) tDSRjhreshoid may comprise setting tDSRjhreshoid to be any value larger than the (e.g. total) delay budget, as defied herein, of the of the one or more wireless devices. In such cases, a wireless device may send a report whenever a packet (e.g. of time critical traffic, such as PROFINET data) arrives to the transmission queue of the wireless device, and when a slot is available to transmit the report. Such a tDSRjhreshoid may be usefully configured in scenarios in which the traffic cycle time of the wireless device is not equal (e.g. different) to the (e.g. total) delay budget.

[0082] As described herein, expiration time (e.g. VDSR) may be represented by 6 bits (e.g. in line with 3GPP standards) in each report of the one or more reports. As such, a maximum value of the expiration time may not be larger than 63ms, according to some examples. If tDSRjhreshoid is set to be 64ms, all scenarios in which a remaining delay budget is larger than or equal to 63ms will be reported as 63~64ms.Thus, in some examples, the tDSRjhreshoid may be set to be less than 63ms. In some examples, the tDSRjhreshoid may be set to a value equal to 1 ms less than a maximum value that can be configured for the expiration time (e.g. VDSR) .

[0083] In some examples, the amount of time required for the wireless device to perform the HO, as referred to herein, can correspond to an average time required for the wireless device to perform the HO. For example, one or more field measurements can be used to estimate an average time required for the wireless device to perform the HO.

[0084] In some examples, the one or more reports referred to herein can comprise at least one delay status report (DSR). For example, the one or more reports referred to herein may be one or more DSRs. A DSR can be described with reference to Release 18 of the technical standards of the third generation partnership project (3GPP). In some examples, the one or more reports referred to herein can comprise a plurality of reports. In some examples, packets received from the wireless device can comprise packets associated with TCC traffic. For example, in some examples, any packet of the wireless device referred to herein may be associated with (e.g. comprise) data related to TCC traffic.

[0085] In some examples, the network node 10 referred to herein may comprise a gNB. For example, the network node 10 may be a gNB. As described herein, in some examples, the network node 10 may be comprised in the source cell.

[0086] Therefore, as described herein, the one or more reports referred to herein (e.g. DSRs) can be used to determine (e.g. estimate) how much delay budget a wireless device has in respect of one or more packets. In this way, the method described herein reduces the total delay (e.g. especially in UL) that is associated with HO. When a wireless device (e.g. UE) is about to trigger a mobility-based HO (e.g. the UE is close to the cell edge and moving outward to a neighboring cell, detected based on measurements related to RSRP, RSRQ, and / or SINR), the network node 10 can trigger the HO based on the one or more reports (e.g. DSR). When there is a large enough delay budget, the network node 10 (e.g. gNB) can decide on a configuration for the HO (e.g. use LTM and initiate LTM candidate preparation). In some examples, the network node 10 can provide a grant (e.g. time and / or frequency resource) to the wireless device to transmit any (e.g. TCC) traffic before the HO. Moreover, in some examples, to reduce the chance of packet loss and / or packet retransmission, the network node 10 can schedule additional resources to the wireless device and / or configure the wireless device to use a specific (e.g. more conservative) modulation and coding scheme (MCS). In some examples, if the one or more reports (e.g. DSR) indicate that a delay budget of the wireless device is not large enough (e.g. at the moment), the network node 10 may not trigger the HO. In such scenarios, the network node 10 may try to keep the wireless device in the current (e.g. source) cell (e.g. especially if the HO is not mobility-based, but HO due to coverage).

[0087] The technique described herein can be applied to handovers triggered for any reason, such as coverage, load, and / or bandwidth triggered HO. Such HOs can, for example, be triggered in a Multi-Layer Coordination (MLC) feature.

[0088] Figure 5 is a signaling diagram illustrating an exchange of signals in a communications network according to an embodiment. As illustrated in Figure 5, the communications network comprises a wireless device 500, as described herein. In the embodiment illustrated in Figure 5, a network entity 502 represents the network side of the communications network. The network entity 502 can correspond to the source cell and / or the target cell, depending on which cell the wireless device 500 is connected to (e.g. at a given time). The network entity 502 can correspond to the network node 10 (e.g. of the source cell), as defined herein, with respect to any methodology occurring before the HO. The network entity 502 can correspond to an entity of the target cell with respect to any methodology occurring after the HO.

[0089] As illustrated by arrow 504 of Figure 5, in some examples, a first packet (“Packet #1) can enterthe transmission queue of the wireless device 500. The packet may comprise TOO data. As illustrated by arrow 506 of Figure 5, in some examples, the wireless device 500 may initiate transmission of a first scheduling request (“SR”) towards the network node 10. Thus, the network node 10 can receive the first scheduling request from the wireless device 500. The first scheduling request can comprise a request for the network node 10 to schedule one or more resources for the transmission of the first packet.

[0090] One or more scheduling requests (SRs) may be transmitted by the wireless device 500 for each packet in the transmission queue of the wireless device 500. The periodicity of transmitting the one or more SRs may be configured by the (e.g. network node 10 of the) communications network. For example, the wireless device may be configured to (e.g. periodically) transmit a SR every 2.5ms, 5ms, 10ms, 20ms, and / or 40ms. The wireless device may be configured to transmit a SR periodically if it has a packet in the transmission queue. As such, in some examples, an estimation of traffic cycle time, as defined herein, may be determined (e.g. inferred) from the timing of SR transmission by the wireless device 500 and / or SR receipt by the network node 10.

[0091] As illustrated by arrow 508 of Figure 5, in some examples, the network node 10 may initiate transmission of a grant (e.g. message) (“Grant”) towards the wireless device 500. Thus, the wireless device 500 can receive the grant from the network node 10. Transmission initiation of the grant message can be initiated in response to receiving the first scheduling request from the wireless device 500. The grant can comprise information indicative of one or more resources that that the wireless device 500 can utilise to transmit the first packet (e.g. via UL). As illustrated by arrow 510 of Figure 5, in some examples, the wireless device 500 may initiate transmission of the first packet towards the network node 10. In some examples, the periodicity with which packets are received by the network node 10, from the wireless device 500, can be used to determine (e.g. check) an estimation of traffic cycle time, as defined herein. As illustrated by arrow 512 of Figure 5, in some examples, the network node 10 can receive the first packet from the wireless device 500. As illustrated by arrows 512 and 516 of Figure 5, the first packet can be received before the packet is considered to be expired. Thus, in the example illustrated in Figure 5, the first packet can be said to be received successfully.

[0092] As illustrated by arrow 514 of Figure 5, in some examples, a second packet (“Packet #2”) can enter the transmission queue of the wireless device 500. As illustrated by block 518 of Figure 5, in some examples, the wireless device may perform a HO from the source cell to the target cell, as described herein. Although not explicitly illustrated in Figure 5, the network node 10 estimates the HO time (e.g. comprising “HO interruption”), as defined herein. In the embodiment illustrated in Figure 5, the HO is initiated as the estimated HO time is less than the traffic cycle time. That is, in the embodiment illustrated in Figure 5, the HO time is short enough to initiate HO. In the embodiment illustrated in Figure 5, the traffic cycle time is referred to as “T”. It can be seen from the example illustrated in Figure 5 that the traffic cycle time (T) corresponds to the amount of time between consecutive packets entering the transmission queue of the wireless device 500 (e.g. the amount of time between Packet #1 and Packet #2 entering the transmission queue). Although not explicitly illustrated, in the example of Figure 5, the wireless device 500 successfully completes the HO. The steps illustrated by arrows 520, 522 and 524 of Figure 5, can be as described with reference to arrows 506, 508 and 510 of Figure 5, respectively, with the exception that the communications take place between the wireless device and the target cell (i.e. instead of the network node 10). As illustrated by arrows 524 and 526 of Figure 5, the second packet is received by the network entity 502 (i.e. the target cell) prior to the second packet being considered expired. As such, advantageously, no late packets have resulted from the HO process illustrated in Figure 5. As illustrated by arrow 528 of Figure 5, in some examples, a third packet (“Packet #3”) may enter the transmission queue of the wireless device 500. Thus, the wireless device 500 can continue sending packets to the network side (network entity 502) without any damage to the quality of service of the wireless device 500.

[0093] In the example of Figure 5, the HO time may be equal to tHO + tsR + tdata + A, as defined herein. Thus, in the embodiment illustrated in Figure 5, it can be said that tno + tsR + tdata + A < T. Therefore, in the example illustrated in Figure 5, the traffic cycle time (e.g. cycling time) of the wireless device is long enough to complete the HO event, in addition to completion of a grant procedure (e.g. as described with reference to arrows 520 and 522 of Figure 5) and a data transmission (e.g. as described with reference to arrow 524 of Figure 5) after HO completion. In the embodiment illustrated in Figure 5, if the first packet is not late and the HO is performed immediately after the first packet is received, the wireless device 500 has time to perform a SR and transmit data (i.e. the second packet) after the HO to the target cell. In some examples, as illustrated in Figure 5, when a wireless device 500 needs to perform HO, the network node 10 (e.g. of the source cell) can perform the HO process in response to (e.g. immediately after) successfully receiving the first packet (e.g. comprising TOO data) from the wireless device 500. In this way, and as illustrated in the example of Figure 5, since the time duration from arrow 512 to arrow 526 of Figure 5 is longer than T, which is longer than the duration of time corresponding to the HO event (as described with reference to arrow 518 of Figure 5)), the grant procedure (as described with reference to arrows 520 and 522 of Figure 5), and the data transmission (as described with reference to arrow 524 of Figure 5), the second packet is not considered late and / or lost. After the wireless device 500 handovers to the target cell, the target cell may schedule the wireless device 500 to send a newly arrived packet (e.g. the second packet of Figure 5). It will be understood that, if the estimated HO time was determined to be greater or equal to the traffic cycle time, then the HO may not have been initiated (e.g. the HO may have been delayed). Herein, and as illustrated in Figure 5, a (e.g. total) delay budget of the wireless device 500 can be referred to as tdeiay_budget. As illustrated in Figure 5, in some examples, the (e.g. total) delay budget of the wireless device 500 can correspond to an amount of time between a packet entering the transmission queue of the wireless device 500 and the time at which said packet is considered to be expired (e.g. by the communications network).

[0094] The delay budget of the wireless device 500 may be referred to herein as the delay requirement of the wireless device 500. In some examples, the delay budget of the wireless device 500 may be (pre)configured. For example, the delay budget may be configured as a parameter for the wireless device 500 (e.g. via manual configuration by an operator, such as a factory operator). In some examples, the delay budget may be given by a packet data convergence protocol (PDCP) discardTimer (e.g. of the wireless device 500). In some examples, the (e.g. total) delay budget of the wireless device 500 may be equal to the traffic cycle time of the wireless device 500. Such a scenario can be seen in the example illustrated in Figure 7 (see the value ‘IDEI-AY-BUDGET” of Figure 7).

[0095] Figure 6 is a signaling diagram illustrating an exchange of signals in a communications network according to an embodiment. The communications network comprises a wireless device 500 and a network entity 502 as described with reference to the communications network of Figure 5.

[0096] The steps illustrated by arrows 606, 608, 610, 616, 618 and 622 of Figure 6 can be as described with reference to arrows 504, 506, 508, 510, 512 and 516 of Figure 5 respectively.

[0097] As illustrated by arrow 604 of Figure 6, the network node 10 receives one or more reports, as defined herein, from the wireless device 500. As illustrated in Figure 6, in some examples, the one or more reports may be one or more DSRs. The information comprised in the one or more reports can be used by the network node 10 to determine the traffic cycle time of the wireless device 500, as defined herein.

[0098] As illustrated by arrow 612 of Figure 6, in some examples, the network node 10 may initiate transmission of one or more (e.g. a plurality of) grants towards the wireless device 500. Thus, the wireless device 500 can receive the one or more grants from then network node 10. The amount of one or more grants transmitted by the network node 10 may be dependent on the size of the packet (e.g. the first packet of Figure 6). For example, as described with reference to arrow 110 of Figure 1 , multiple grants may be transmitted if a packet comprises a large amount of data and / or information.

[0099] As described herein, in some examples, the network node 10 may estimate a packet entry time based on the information comprised in the one or more reports (e.g. DSR). The packet entry time can correspond to a time at which a next subsequent packet will enter the transmission queue of the wireless device 500. In the embodiment illustrated in Figure 5, the next subsequent packet corresponds to a second packet (“Packet #2”) which enters the transmission queue of the wireless device, as described with reference to arrow 624 of Figure 6. Although not explicitly illustrated in Figure 6, in some examples, and as described herein, the network node 10 may estimate a subsequent transmission time. The subsequent transmission time can correspond to a time at which the wireless device is able to initiate transmission of the next subsequent packet. In the embodiment illustrated in Figure 6, the subsequent transmission time can correspond to the time at which transmission of the second packet is initiated, as described with reference to arrow 626 of Figure 6.

[0100] As illustrated by arrow 620 of Figure 6, in some examples, the network node 10 may initiate transmission of a second message, as defined herein, towards the wireless device 500 before the subsequent transmission time. The second message can comprise pre-scheduling information associated with transmission of the next subsequent packet. As illustrated by arrow 620 of Figure 6, the second message may be a grant message. For example, the pre-scheduling information comprised in the second message can comprise one or more resources to be used by the wireless device 500 to transmit the next subsequent packet (e.g. the second packet of Figure 6). As illustrated in Figure 6, in some examples, the transmission of the second message can be initiated before the next subsequent packet (as illustrated by arrow 624 of Figure 6) enters the transmission queue of the wireless device 500.

[0101] As illustrated by arrow 626 of Figure 6, in some examples, the wireless device 500 may initiate transmission of the next subsequent packet (e.g. the second packet) towards the network node 10. Thus, the network node can receive the next subsequent packet from the wireless device 500. As illustrated by arrows 628 and 634 of Figure 6, the second packet can be received by the network node 10 before the second packet is considered to be expired. Therefore, as illustrated by the steps described with reference to block 630 of Figure 6, late (e.g. UL) packets can be avoided at HO by providing early (e.g. UL) grant to the wireless device 500 in the source cell.

[0102] As illustrated by block 632 of Figure 6, the wireless device can HO to the target cell as described herein. As also illustrated by block 632 of Figure 6, in some examples, the network node 10 may perform the HO in response to receiving the next subsequent packet (e.g. the second packet of Figure 6) from the wireless device 500. Thus, in some examples, the network node 10 can trigger the HO for the wireless device 500 right after the transmission of the next subsequent packet. In this way, when the wireless device 500 connects to the target cell, the wireless device 500 has sufficient time to transmit the next packet (e.g. the third packet of Figure 6). As illustrated by arrow 636 of Figure 6, a third packet may enter the transmission queue of the wireless device 500.

[0103] The steps illustrated by arrows 638, 640, 642 and 644 of Figure 6 can be as described with reference to arrows 520, 522, 524 and 526 of Figure 5, respectively, with the exception that arrows 638, 640, 642 and 644 of Figure 6 relate to the third packet of Figure 6, whereas arrows 520, 522, 524 and 526 of Figure 5 relate to the second packet of Figure 5.

[0104] As illustrated by arrow 646 of Figure 6, in some examples, a fourth packet (“Packet #4”) may enter the transmission queue of the wireless device 500. Thus, the wireless device 500 can continue sending packets to the network side (network entity 502) without any damage to the quality of service of the wireless device 500 (i.e. due to the HO).

[0105] Figure 7 is a signalling diagram illustrating an exchange of signals in a communications network. The signalling illustrated in Figure 7 can be as described with reference to the signalling diagram of Figure 6, with the exception that the step as illustrated at arrow 612 of Figure 6 is not present in the example illustrated in Figure 7. Figure 7 provides additional detail regarding the timing of communications and events as described with reference to Figure 6.

[0106] For example, the value tHO in Figure 7 illustrates an example of the amount of time required for the wireless device to HO to the target cell, as defined herein. The value tsR in Figure 7 illustrates an example of the amount of time required for a grant procedure between the wireless device and the network node to be completed. The value tDATA in Figure 7 illustrates an example of the amount of time required for a packet to be transmitted from the wireless device to the network node. The value ICELAY-BUDGET in Figure 7 illustrates an example of a (e.g. remaining) delay budget (e.g. in terms of amount of time) for the wireless device. As illustrated in Figure 7, in some examples, the delay budget of the wireless device can be equal to the traffic cycle time, as defined herein. For example, for PROFINET traffic, the delay budget of the wireless device may be equal to the traffic cycle time. In some examples, the delay budget may be configured based on a PDCP discard timer for the (e.g. time critical) traffic of the wireless device.

[0107] There will now be described an example technique for determining traffic cycle time, as defined herein, with reference to Figure 7. In the example illustrated in Figure 7, the one or more reports are one or more DSRs. However, it will be understood that this is merely an example of the one or more reports, and that the example technique is not limited to the one or more reports being one or more DSRs.

[0108] As illustrated in Figure 7, the network node 10 can receive one or more DSRs from the wireless device. The one or more DSRs can comprise information indicative of one or more expiration times indicating the time remaining until one or more packets, corresponding to the one or more DSRs, in a transmission queue of the wireless device expire. As illustrated in Figure 7, the expiration time can be referred to as a DSR value VDSR(tj). For example, as illustrated in Figure 7, VDSR^I) corresponds to the expiration time of the first packet. In the example illustrated in Figure 7, the first packet expires after the expiration time has elapsed (e.g. as described with reference to arrow 622 of Figure 6). As also described herein, the information comprised in each DSR of the one or more DSRs can comprise information indicative of a transmission time of the report. The transmission time of the DSR can be the time at which the DSR is sent by the wireless device. As illustrated in Figure 7, the transmission time can be referred to as tj. For example, as also illustrated in Figure 7, the transmission time of the first packet can be referred to as ti.

[0109] The network node 10 can obtain (e.g. and / or store) each DSR (e.g. and each corresponding DSR value) received from the wireless device. For example, for each time-critical wireless device that sends time critical traffic (e.g. with a specific 5G quality of service (QoS) indicator (5qi)), the network node 10 can keep track of the DSR values and the time at which they are sent.

[0110] A wireless device (e.g. UE) can be associated with packets i=1 ,2,... ,n, over a given time window (e.g. the “history” time window of Figure 7). The DSR of packet i can be sent at time tj , and the value of the DSR can be referred to as VDSR I). If the network node 10 receives a plurality of the one or more DSRs, then, the network node 10 may be informed of tl,t2,...tn, and VDSR(tl), VDSR(t2),... VDSR(tn).

[0111] For two consecutive DSRs (i.e. DSRs that are received consecutively from the wireless device), for example for packets i and i+1 , the network node 10 may determine (e.g. calculate) traffic cycle time as:

[0112] 77 = ti+1 — ti + VDSR(ti+l) - VDSFl(ti)

[0113] In the above equation, Tj can be said to be the traffic cycle time associated with packets i and i+1. Therefore, for multiple DSRs, the network node may determine Ti,T2,...Tn-i. Tj. The determined traffic cycle time may be close to an actual traffic cycle time (e.g. periodicity) of the wireless device traffic. For example, a small error can exist due to the DSR value VDSR^I) being produced and / or measured with a granularity of ~1 ms. Whenever a new DSR, for example corresponding to packet j, is received by the network node 10, the network node 10 may determine (e.g. calculate) the freshest Tj, based on VDSR®, vDsR(tj-i), tj, and tj-i. An example of a plurality of DSRs being received by the network node 10 is illustrated in Figure 8.

[0114] To achieve a more accurate estimation of the traffic cycle time of wireless device traffic, the network node 10 may determine an average of Tj. The average of Tj may be given by:

[0115] Equation (2) may be used to make more substantial (e.g. full) use of all VDSR and t values. Equation (1) may only use the values VDSR^I), vDsR(tn), ti, and tn. As mentioned herein, in some examples (e.g. for PROFINET traffic), traffic cycle time may be the same as the delay budget (i.e. T = tdeiay_budget). In these examples, the average traffic cycle time may be given by T= tdeiay_budget. In some examples, the network node 10 may determine whether there is a difference between T (e.g. as determined using equation (1) and / or equation (2)) and tdeiay_budget. If the difference is (e.g. too) large, it may indicate that the configuration of tdeiay_budget does not reflect the actual (e.g. time-critical) traffic, and / or there is something wrong with the arrival of the (e.g. time-critical) traffic. In examples in which the traffic cycle time is not the same as the time delay budget, equations (1) and / or (2) may be used to determine (e.g. estimate) the traffic cycle time.

[0116] As described herein, in some examples, the network node 10 may delay the HO if the modified HO time, as defined herein, is less than the modified traffic cycle time, as defined herein. As also described herein, the modified traffic cycle time can comprise the expiration time, as defined herein, and an amount of time corresponding to a product of the (e.g. average) traffic cycle time and a second integer number. The second integer number can be determined based on a number of late packets that the communications network can tolerate receiving late.

[0117] For example, the modified traffic cycle time may be given by VDSR + k*f, where k-1 is the max number of consecutive late packet that the communications network can tolerate. In this example, the second integer number is equal to k. If k is not known, then k can be set as k=1 . As the value of VDSR^I) can be different for different values of i, the network node 10 may determine the modified traffic cycle time using the largest value of VDSR^I) among different i within a time window (e.g. i=1 ,2,...n). The decision to delay the HO could be valid for some period of time. For example, a channel quality of the wireless device may improve and result in a lack of need to HO (e.g. the wireless device moves back towards the source cell). In some examples, the HO may be delayed until the wireless device causes large (e.g. unacceptable) impact (e.g. interference) to other network entities (e.g. UEs). In cases in which a HO is required because the wireless device is / will cause significant impact to other network entities if it does not HO, then the network node may could notify a (e.g. time-critical service) server of the network to expect some long latency due to the HO process of the UE (e.g. as described with reference to Figures 10 and 1 1 below).

[0118] In some examples, the network node 10 may initiate the HO if the modified traffic cycle time is greater than or equal to the modified HO time (e.g. if vDsR+k* f >= tHO + tsR + 2tdata + A). The network node 10 may send a HO request, as described herein, to the target cell (e.g. gNB). If the target cell admits the UE, and informs the network node 10, then the HO may proceed. Otherwise, in some examples, the HO may not be initiated. The network node 10 may determine (e.g. check) the last DSR report received from the wireless device that fulfills VDSRCI) +k* f >= tHO + tsR + 2tdata + A. In some examples, the network node 10 may determine (e.g. calculate) a packet entry time, as defined herein. The packet entry time (e.g. the time of entry of packet i+1 to the transmission queue of the wireless device) may be calculated by tnext.i = vDsR(ti)+tj, . In some examples, the packet entry time may be the same as the time at which the previous packet (e.g. packet i) expires. This may be the case for PROFINET traffic in which the traffic cycle time can be equal to the time delay budget.

[0119] In some examples, the network node may determine the modified traffic cycle time by determining (e.g. finding): max{ VDSR(ti) fulfilling VDSRG +k* T >= tHO + tsR + 2tdata + A} i

[0120] In the example illustrated in Figure 7, it the value of i can be said to be i=1 . As such, in this example, VDSR(ti)+k* f>=tHoHsR+2tdata+ A, and vDsR(ti)>= vDsR(tn), for n not equal to 1.

[0121] In some examples, the network node 10 may determine (e.g. find) a minimum integer value m, such that tnext + m* T is larger than a current time value (e.g. tnOw of Figure 7). The integer value m can be determined using the following equation:

[0122] In the equation above, the function |x] maps x to the smallest integer value that is greater than or equal to x. That is, |x] takes the ceiling of a decimal number x. The value of the packet entry time (tnext of Figure 7), as defined herein, can then be calculated using tnext—tnextj + Hl T .

[0123] In some examples, as described herein, the network node 10 can determine a subsequent transmission time (e.g. tULinextof Figure 7). The subsequent transmission time can be given by tULinext> tnext+ 8prep. tULinextcan correspond to a (e.g. UL) time slot (e.g. in examples in which the source cell utilizes time division duplex (TDD)). In some examples, the subsequent transmission time can be given by tU next= tnext+ 8prep, where 8prep> 0 . 8prepcan be defined herein as a Physical Uplink Shared Channel (PUSCH) preparation procedure time (N2). Arrow 702 of Figure 7 is an example of the time duration of 8prep. As described herein, tU nextcan be the time that the network node 10 would let the wireless device transmit its next subsequent packet (e.g. at the next UL slot after tnext).

[0124] In some examples, based on the calculated value of tUL,next, the network node 10 may perform a pre-scheduling (e.g. as described with reference to arrow 620 of Figure 6) to the wireless device before tULinext. The pre-scheduling may allow the wireless device to transmit data (e.g. the next subsequent packet) at time tU next(e.g. via UL). Therefore, the time to send pre-scheduling from the network node 10 to the wireless device can be given by tUL,next- 6DC PUSCH, where 8DC[:PUSCHcan correspond to the time delay between a DCI slot and a PUSCH slot (as illustrated by arrow 704 of Figure 7). Typically, 6DCI,PSCHcanbe determined (e.g. calculated) based on K2.

[0125] When the cell transmits pre-scheduling information (e.g. DCI) towards the wireless device, according to some examples, the network node 10 can configure (e.g. for use by the wireless device) a robust MCS to avoid lost packets (e.g. in PDCCH). For example, the network node 10 may configure an aggregation level 8 or level 16 MCS (e.g. even if the CQI of the UE is good). The pre-scheduling information may allocate PRB resources and allow the wireless device to use a relatively conservative MCS (e.g. for UL transmission) to avoid lost packets.

[0126] After (e.g. successful) completion of the HO (e.g. when the HO process finishes), the wireless device may initiate transmission of a scheduling request to the target cell. The scheduling request can comprise a request for a grant to transmit a new packet to the target cell. If VDSRG +k* T >= tHO + tsR + 2tdata + A, the new packet will be received by the target cell before expiration of the new packet. In some examples, the time delay budget may not be larger or equal to the traffic cycle time. To handle this special case, the network node 10 may determine (e.g. check) whether T > tdeiay_budget. If this condition is true, the network node 10 may configure tnext = tnext + m* T + T - tdeiay_budget. In such cases, the estimated HO time may be adjusted to tno + tsR + 2tdata + A + T - tdeiay_budget In examples in which the network node 10 determines the subsequent transmission time tuL.next),asdefined herein, the network node 10 may initiate transmission of a HO request to the target cell (e.g. gNB). As such, the network node 10 can provide the target cell with some time to prepare and / or perform admission control for the HO. If the target cell admits the wireless device, and informs the network node 10 of the admission, the network node 10 could wait until time tULinext(e.g. when the wireless device should transmit a subsequent packet), before transmitting a HO command to the wireless device. If the subsequent packet is successfully received by the network node 10, the network node 10 may send the HO command to the UE. In some examples, if the target cell admits the wireless device, and informs the network node 10 of the admission, the network node 10 could send the HO command before (e.g. prior to) tui,next. In this scenario, the wireless device may begin the HO after (e.g. in response to) initiating transmission of the subsequent packet and / or receiving an ACK message (e.g. from the network node 10). In some examples, if the subsequent packet is not successfully received, the network node 10 node may not send the HO command to the wireless device. In these examples, the network node 10 may notify the target cell that the HO is postponed (e.g. delayed). The network node 10 may indicate that the amount of time associated with the postponement is equal to tU next+ T. In this way, the network node 10 may wait to receive the next packet from the wireless device before performing HO. In examples in which the subsequent packet is not successfully received from the wireless device, the network node 10 may initiate transmission of a request, towards the wireless device, requesting a retransmission of the (e.g. lost) subsequent packet. In such a scenario, the network node 10 may perform a pre-scheduling (e.g. by setting the time of pre-scheduling to be tU next+ f).

[0127] In some examples, the network node 10 may provide cell information to the target cell. The cell information can comprise, for example, information calculated and / or obtained by the network node 10 (e.g. one or more from neighboring cells). In some examples, providing the cell information may comprise initiating transmission of the cell information towards the target cell (e.g. at the same time as the transmittal of the HO request). In some examples, the cell information can comprise an estimated traffic cycle time T , tnext, tj, a corresponding VDSR^I) (e.g. based on which the network node 10 determines tnext, and / or tULinext. The cell information may be used by the target cell to determine the timing of a future HO (e.g. after the target cell becomes the serving cell for the wireless device and the wireless device needs to HO to another cell). Figure 8 is a signalling diagram illustrating an exchange of signals in a communications network between a wireless device 500 and a network node 10.

[0128] As described herein, and as illustrated in Figure 8, the network node 10 receives one or more reports from the wireless device 500. As illustrated by arrows 802, 804 and 806 of Figure 8, in some examples, the one or more reports can be one or more DSRs. The information comprised in each report of the one or more reports (e.g. DSRs) is indicative of an expiration time indicating a time remaining until a packet in a transmission queue of the wireless device 500 expires. As illustrated in Figure 8, and as described with reference to Figure 7, the expiration time can be referred to herein as VDsR(ti). VDsR(ti) can be a value that is reported (e.g. to the network node 10) in a DSR. As illustrated in Figure 8, each report of the one or more reports can comprise a value for VDSR at different points in time (ti) for a particular (e.g. TCC) packet (i) of the wireless device 500. As also illustrated in Figure 8, in some examples, for each report of the one or more reports, the expiration time (e.g. VDSRGO) can correspond to the amount of time between the transmission of the report and the time at which the packet in the transmission queue of the wireless device 500 (e.g. at the time at which the report is transmitted) expires.

[0129] As described herein, in some examples, the network node 10 can determine a (e.g. average) traffic cycle time of the wireless device 500. As illustrated in Figure 8, in some examples, determining the (e.g. average) traffic cycle time may involve receiving (e.g. collecting) a plurality of the one or more reports (e.g. DSRs). This may be done to more accurately find a time where the residual delay budget of the wireless device 500 is large (e.g. or maximized). As the traffic (e.g. PROFINET) from the wireless device 500 can be periodic, traffic periodicity can be measured (e.g. learned) by the network node 10 from a collection of the one or more reports (e.g. DSR) over time.

[0130] As described herein, in some examples, the network node 10 may initiate transmission of reporting information towards the wireless device. The reporting information can be indicative of a criterion for initiating transmission of a report of the one or more reports by the wireless device. The criterion can be met if an amount of time until expiry of a first packet in the transmission queue of the wireless device is less than a threshold amount of time. The network node 10 can configure the threshold amount of time (e.g. for the wireless device 500). The threshold can be configured such that, if the wireless device 500 has a packet with remaining delay budget (e.g. PDCP discard Timer) less than the threshold, the wireless device 500 can initiate transmission of a report of the one or more reports to the network node 10. Each report of the one or more reports (e.g. DSRs) can comprise information indicative of a remaining delay budget of a packet in the transmission queue of the wireless device, such that the network node 10 can make scheduling decisions accordingly. In some cases, even though the wireless device 500 may trigger report transmission when one of its packet’s remaining delay budget is less than the threshold amount mentioned herein, the value of VDsR(ti) reported may not always be the same, because the wireless device 500 may not be able to send the report whenever it wants. This can be due to limitation from a time division duplex (TDD) pattern (e.g. the next available UL slot that the UE could use for reporting).

[0131] In some examples, the wireless device referred to herein may handle (e.g. multiple) different types of traffic. In some examples, the one or more reports (e.g. DSRs) referred to herein may only be associated with time-critical traffic of the wireless device. For example, the wireless device may only send the one or more reports for time-critical traffic. In some examples, the wireless device may be configured with a specific type of (e.g. 5G QoS Identifier (5QI)) traffic associated with the one or more reports. In some examples, the one or more reports may be associated with a filter in an ethernet header, and / or an additional indicator to distinguish the one or more reports from other types of report (e.g. associated with the wireless device).

[0132] As mentioned above, the one or more reports referred to herein may be one or more DSRs. Delay status reporting can be performed in a periodic manner, and / or in an event- triggered manner (e.g. when a current delay budget is lower than a predefined threshold), as described herein. In some cases, if DSR periodicity differs from traffic periodicity, then the information (e.g. values) reported in the DSR may vary over time. This may be useful when attempting to find a time that has a large DSR value (e.g. as described with reference to Figure 7).

[0133] In some examples, a DSR may contain information indicative of both delay budget and current waiting time of data (e.g. packet(s)). As such, a DSR can be used to estimate the next packet arrival time (e.g. in the case where a packet’s delay budget does not equal traffic cycle time), as described herein. In some examples, the network node 10 may configure more than one threshold for triggering transmission of the one or more reports (e.g. DSRs) by the wireless device. For example, in cases in which there are two thresholds, then the wireless device may attempt to transmit a first DSR when its packet’s delay budget is lower than a high threshold, and / or attempt to transmit a second DSR when its packet’s delay budget is lower than a second highest threshold. In such examples, the different thresholds could be used for different purposes. For example, the higher threshold can be used to make a HO decision, and / or the lower threshold can be used for priority scheduling and / or link adaptation.

[0134] Figure 9 is a signalling diagram illustrating an exchange of signals in a system (e.g. a communications network as defined herein) according to an embodiment. As illustrated in Figure 9, the system can comprise a wireless device 900 (“UE”), a network node 10, and a target cell 904. The wireless device 900, the network node 10, and the target cell 904 can be of the communications network, as defined herein. In some examples, the wireless device 900 can communicate with the network (e.g. the network node 10 and / or the target cell 904) via a channel. The network node 10 can be comprised in a source cell as referred to herein. As such, some or all of the functionality described with reference to the network node 10 of Figure 9 can be said to be performed by the source cell.

[0135] As illustrated by arrows 906 and 908 of Figure 9, in some examples, the wireless device 900 can initiate transmission of one or more reports (e.g. DSRs) to the network node 10. Thus, the network node 10 receives the one or more reports from the wireless device 900.

[0136] As illustrated by block 910 of Figure 9, in some examples, the wireless device 900 may (e.g. continuously) monitor (e.g. channel) traffic. The wireless device 900 may report information indicative of the monitoring to the network node 10. For example, the wireless device 900 may (e.g. continuously and / or periodically) measure RSRP, RSRQ, and / or SINR. The report of information indicative of the monitoring may be referred to herein as a “HOevent-report”. It will be understood that the HOevent-report can be different to the one or more reports referred to herein. In some examples, the HOevent- report may be transmitted to the network node 10 in response to a monitoring condition being met. For example, the monitoring condition may comprise an RSRP of the current cell (e.g. source cell) being some value of dB weaker than an RSRP of a neighboring cell. As described herein, the wireless device 900 may (e.g. continuously and / or periodically) transmit (e.g. TCC) traffic towards the network node 10. Thus, the network node 10 can receive traffic from the wireless device 900. The traffic can comprise one or more packets, as described herein. As illustrated by block 912 of Figure 9, in some examples, the network node 10 may determine (e.g. detect) traffic cycle time based on information comprised in the one or more reports, as defined herein. Alternatively, or in addition, the network node 10 may obtain the traffic cycle time from one or more (e.g. neighboring) cells of the communications network. For example, another cell (e.g. a private local network) of the communications network may have already determined the traffic cycle time of the wireless device 900. The other cell of the communications network may provide the traffic cycle time (e.g. upon request) to the network node 10. Thus, in some examples, the network node 10 can obtain (e.g. receive) the traffic cycle time from the other cell. In some examples, the network node 10 may compare the value of traffic cycle time received from the other cell to the value of traffic cycle time that the network node 10 has determined (e.g. as described with reference to Figure 7). In some examples, the wireless device 900 may have previously performed HO to the current source cell. In such scenarios, the network node 10 can reuse the traffic cycle time determined in the previous serving cell of the wireless device 900.

[0137] As illustrated by block 914 of Figure 9, the network node 10 estimates the HO time, as described herein. As illustrated by block 916 of Figure 9, in some examples, the network node 10 may wait until a HO condition is met (e.g. before initiating the HO). In some examples, the HO condition may only be met if the network node 10 receives an HOevent-report, as defined herein, from the wireless device 900. As described herein, the network node 10 initiates the HO if the estimated HO time is less than the traffic cycle time. As also described herein, in some examples, the network node may initiate the HO if the estimated modified HO time is less than the modified traffic cycle time. However, if the HO condition is not met (e.g. the estimated HO time is greater than or equal to the traffic cycle time) then the HO can be delayed.

[0138] As illustrated by block 918 of Figure 9, in some examples, the network node 10 may estimate a packet entry time for a next subsequent packet, as described herein. For example, the network node 10 can predict the time at which the wireless device 900 will have a new (e.g. UL) packet enter the transmission queue (e.g. buffer) of the wireless device 900. As described herein, the manner in which the HO is handled can depend on the packet entry time, according to some examples. As illustrated by arrow 920 of Figure 9, in some examples, the network node 10 may initiate transmission of a request to perform the HO (“HO req.”) towards the target cell 904. Thus, the target cell 904 can receive the request to perform the HO from the network node 10. As illustrated by block 922 of Figure 9, in some examples, the target cell 904 may determine whether the wireless device 900 can be admitted to the target cell (e.g. via HO). As illustrated by arrow 924 of Figure 9, in some examples, the target cell 904 may initiate transmission of a response to the request to perform the HO (“HO req. Ack”) towards the network node 10. Thus, the network node 10 can receive the response to the request to perform the HO from the target cell 904. In some examples, the response to the request can be indicative that the target cell is able to perform the HO. Although not illustrated in Figure 9, in some examples, the network node 10 may initiate transmission of other information towards the target cell 904 in response to receiving the response from the target cell (e.g. as described with reference to arrow 924 of Figure 9). The other information can include a traffic cycle time (e.g. estimated by the network node 10), and / or a predicted packet entry time for the wireless device 900.

[0139] As illustrated by block 926 of Figure 9, in some examples, the network node 10 may determine prescheduling information to be transmitted in a second message to the wireless device 900, as described herein (e.g. with reference to Figure 6). As illustrated by arrow 928 of Figure 9, in some examples, the network node 10 may initiate transmission of the second message (“Prescheduling”), as defined herein, towards the wireless device 900. Thus, the wireless device 900 can receive the second message from the network node 10. The second message can comprise the prescheduling information. The pre-scheduling information can comprise a request for the wireless device 900 to use a specific type of MCS for packet transmission. For example, the prescheduling information can comprise a request for the wireless device 900 to use some lower MCS (e.g. even if the channel quality index (CQI) of the wireless device is good). The network node 10 may use a conservative MCS to transmit the pre-scheduling information (e.g. via the second message). For example, the conservative MCS may correspond to aggregation level 8 or aggregation level 16, such that the pre-scheduling information is very likely to be correctly received by the wireless device 900. In this way, the pre-scheduling information can be reliably transmitted towards the wireless device 900.

[0140] As illustrated by arrow 930 of Figure 9, in some examples, the wireless device 900 may initiate transmission of a packet (“Data of TCC traffic”) towards the network node 10. Thus, the network node 10 can receive the packet from the wireless device 900. The transmitted packet can be the next subsequent packet as defined herein. As illustrated by arrow 932 of Figure 9, in some examples, the network node 10 may initiate transmission of a HO command (“RRC reconfiguration”) towards the wireless device 900, as described herein. Thus, the wireless device 900 can receive the HO command from the network node 10. As illustrated in Figure 9, in some examples, the HO command can comprise RRC configuration information.

[0141] As illustrated by block 934 of Figure 9, in some examples, the wireless device 900 may HO to the target cell 904. For example, the wireless device 900 can detach from the source cell and connect to the target cell 904. As illustrated by arrow 936 of Figure 9, in some examples, the target cell 904 may initiate transmission of HO information (“Prescheduling for RRC reconfiguration complete and UL data pkt”) to the wireless device 900. Thus, the wireless device 900 can receive the HO information from the target cell 904. The HO information can comprise information to be used by the wireless device to connect to the target cell 904. In some examples, the HO information can comprise prescheduling information for the wireless device 900. As such, if a new (e.g. UL) packet enters the transmission queue of the wireless device 900 during the HO, the wireless device 900 may initiate transmission of the new packet to the target cell (e.g. together with a HO complete message) using the pre-scheduling information. In this way, the likelihood of any packets being late or lost is further reduced.

[0142] Although not illustrated in Figure 9, in some examples, the source cell (e.g. network node 10) may initiate transmission of information indicative of the time of the wireless device’s next (e.g. UL) packet arrival time towards the target cell 904. In these examples, the target cell 904 may perform (e.g. UL) prescheduling right after it receives a HO complete message. In this case, the HO time (tHOjhrehsoid) can be equal to tHO + tgrant + tdata+ A, where tgrant can correspond to an amount of time from when the target cell receives the HO complete message until the wireless device receives a grant message and is ready to send the next packet (e.g. via UL).

[0143] As illustrated by arrow 938 of Figure 9, in some examples, the wireless device 900 may initiate transmission of a HO complete message (“RRC reconfiguration complete”) towards the target cell 904. Thus, the target cell 904 can receive the HO complete message from the wireless device 900. As illustrated by arrow 940 of Figure 9, in some examples, the target cell 904 can initiate transmission of an HO success message (“HO success”) towards the network node 10 (e.g. of the source cell). Thus, the network node 10 can receive the HO success message from the target cell 904. The HO success message can comprise information indicative that the HO is completed successfully. As illustrated by arrow 942 of Figure 9, in some examples, the wireless device 900 can proceed with sending further traffic (e.g. packets) towards the target cell, which becomes the new serving cell of the wireless device 900.

[0144] Figure 10 is a signalling diagram illustrating an exchange of signals in a system (e.g. a communications network as defined herein) according to an embodiment. As illustrated in Figure 10, the system can comprise a wireless device 1000 (“UE”), a network node 10, a target cell 1004, and a server 1006 (“Application server”). The wireless device 1000, the network node 10, the target cell 1004, and the server 1006 can be of the communications network, as defined herein. In some examples, the wireless device 1000 can communicate with the network (e.g. the network node 10, the target cell 1004, and / or the server 1006) via a channel. The network node 10 can be comprised in a source cell as referred to herein. As such, some or all of the functionality as described with reference to the network node 10 of Figure 10 can be said to be performed by the source cell.

[0145] The steps illustrated by arrows 1008 and 1010 of Figure 10 can be as described with reference to arrows 928 and 932 of Figure 9 respectively.

[0146] As illustrated by arrow 1012 of Figure 10, in some examples, the wireless device 1000 may initiate transmission of traffic (e.g. a packet) towards the network node 10. Thus, the network node 10 can receive the traffic from the wireless device 1000. As illustrated in Figure 10, in some examples, the traffic may be TCC traffic. In some examples, the receipt of the traffic, as described with reference to arrow 1012 of Figure 10 (e.g. after the transmission as described with reference to arrow 1010 of Figure 10), may indicate that the wireless device 1000 is ready to perform the HO. For example, after the network node 10 (e.g. of the source cell) has sent a prescheduling grant to the wireless device 1000 (e.g. as described with reference to arrow 1008 of Figure 10) and receives the (e.g. UL) traffic (e.g. data) from the wireless device 1000, the network node 10 may expect the wireless device 1000 to begin the HO process. As illustrated by arrow 1014 of Figure 10, in some examples, the network node 10 may initiate transmission of information, indicative that the wireless device 1000 is under a HO process, towards the server 1006. Thus, the server 1006 can receive the information from the network node 10. Therefore, in some examples, the network node 10 may notify the (e.g. application) server 1006 that the wireless device is under (e.g. performing) the HO process and / or that some longer latency of upcoming packets should be expected. Such a notification is especially advantageous for time-critical traffic (e.g. in an industrial deployment). For example, the server 1006 may be a time-sensitive network server that is configured to handle industrial control based on the data (e.g. measurement) obtained from the wireless device 1000.

[0147] As illustrated by block 1016 of Figure 10, in some examples, the server 1006 may adjust a watchdog timer for the wireless device 1000 based on the information indicative that the wireless device 1000 is under the HO process. For example, based on the information, the server 1006 may adjust the watchdog timer to tolerate a longer delay due to the HO (e.g. increase the value of the watchdog timer).

[0148] In some examples, when the network node 10 determines that a condition for initiating HO is not met (e.g. estimated HO time is not less than traffic cycle time), the network node 10 may initiate a timer. The timer may reflect how much extra time the wireless device 1000 should remain in the source cell after HO should be performed but is not performed due to a lack of a condition for initiating the HO being met (e.g. due to the possible long latency of (e.g. time-critical) traffic). In such scenarios, if the wireless device 1000 continues to require HO, the network node 10 may initiate the HO upon expiration of the timer (e.g. to avoid too large interference caused by keeping the wireless device 1000 in the source cell).

[0149] In some examples, the wireless device 1000 may initiate transmission of information indicative that the wireless device 1000 is under the HO process towards the server 1006. For example, the wireless device 1000 may notify the server 1006 before and / or after the HO. In some examples, the wireless device 1000 may notify the server of HO start (e.g. together with time-critical traffic), at time tULinext, as defined herein. As illustrated by arrows 1022 and 1024 of Figure 10, the wireless device 1000 may initiate transmission of information indicative that the HO is completed (e.g. finished) towards the server 1006. As illustrated in Figure 10, in some examples, the transmission may be via the target cell 1004. As such, the target cell 1004 may notify the server 1006 of HO finish. As also illustrated by arrow 1022 of Figure 10, in some examples, the transmission of the information may be accompanied by a first packet transmitted towards the target cell 1004 (e.g. after HO completion).

[0150] The step illustrated by arrow 1026 can be as described with reference to arrow 940 of Figure 9.

[0151] As illustrated by block 1028 of Figure 10, in some examples, the server 1006 may (re)adjust the (e.g. value of the) watchdog timer. For example, (re)adjusting the watchdog timer may comprise configuring the watchdog timer to a default setting (e.g. the setting used prior to the adjustment as described with reference to block 1016 of Figure 10). As illustrated in Figure 10, the (re)adjustment of the watchdog timer may be performed in response to receiving the information indicative that the HO is completed. The information indicative that the HO is completed may comprise a flag (“flag of HO finish”) indicating HO is complete (e.g. finished).

[0152] Figure 11 is a flow chart illustrating additional detail relating to the method performed by the network node 10 (e.g. as described with reference to Figure 4).

[0153] As illustrated at block 1102 of Figure 11 , in some examples, the network node 10 (e.g. of the source cell) may determine traffic cycle time (e.g. traffic periodicity) of a wireless device, as defined herein. The traffic cycle time (“T”) can be indicative of the periodicity of the (e.g. TOO) traffic of the wireless device. As mentioned herein, the traffic cycle time is determined based on the information comprised in the one or more reports, as defined herein.

[0154] As illustrated at block 1104 of Figure 11 , in some examples, the network node 10 may determine whether the traffic cycle time is greater than or equal to the estimated HO time, as defined herein. As illustrated in Figure 11 , in some examples, the HO time can be equal to tHO + tsR + tdata + A, as defined herein. As illustrated by arrow 1106 of Figure 11 , if the traffic cycle time is greater than or equal to the estimated HO time, then the method may proceed to block 1108 of Figure 11. As illustrated at block 1108 of Figure 11 , in some examples, the network node 10 can initiate the HO of the wireless device. For example, when the wireless device needs to perform HO, the network node may allow the wireless device to detach from the source cell and connect to a target cell (e.g. immediately after the network node 10 receives a packet (e.g. TCC traffic) from the wireless device).

[0155] As illustrated by arrow 1110 of Figure 11 , in some examples, if the traffic cycle time is not greater than or equal to the estimated HO time, then the method may proceed to block 1112 of Figure 11 . As illustrated at block 1112 of Figure 11 , the network node may determine whether a modified traffic cycle time, as defined herein, is greater than or equal to a modified HO time, as defined herein. As illustrated in Figure 11 , in some examples, the modified traffic cycle time can be equal to VDSR + kT. As described herein, in some examples, k-1 may be the largest integer number of consecutive late and / or lost packets that can be tolerated by the communications network. It will be understood that the modified traffic cycle time can be a calculated value. As such, the network node 10 may discern the difference between the traffic cycle time and the modified traffic cycle time.

[0156] As also illustrated in Figure 11 , in some examples, the modified HO time may be equal to tHO + tsR + 2tdata + A. As illustrated by arrow 1114 of Figure 11 , in some examples, if the modified traffic cycle time is not greater than or equal to the modified HO time, then the method may proceed to block 1116 of Figure 11. As illustrated at block 1116 of Figure 11 , in some examples, if the modified traffic cycle time is not greater than or equal to the modified HO time, the network node 10 may delay the (e.g. initiation of the) HO. In some examples, in addition to delaying the HO, the network node 10 may obtain (e.g. receive) more of the one or more (e.g. additional) reports from the wireless device.

[0157] As illustrated by arrow 1118 of Figure 11 , in some examples, if the modified traffic cycle time is greater than or equal to the modified HO time, then the method may proceed to block 1120 of Figure 11. As illustrated at block 1120 of Figure 11 , in some examples, if the modified traffic cycle time is greater than or equal to the modified HO time, then the network node 10 may initiate the HO of the wireless device (e.g. as and when HO is needed).

[0158] As illustrated at blocks 1122, 1124 and 1126 of Figure 11 , in some examples, initiating the HO can comprise one or more sub-steps. As illustrated at block 1122 of Figure 11 , in some examples, the network node 10 may estimate a packet entry time, as defined herein. For example, the packet entry time can correspond to a time at which the next packet (e.g. of wireless device traffic) will enter the transmission queue of the wireless device. As illustrated at block 1124 of Figure 11 , in some examples, the network node 10 may initiate transmission of a second message towards the wireless device before a subsequent transmission time, as defined herein. The second message can comprise pre-scheduling information associated with transmission of the next subsequent packet. For example, the pre-scheduling information may comprise a grant for the wireless device to transmit the next subsequent packet at the subsequent transmission time tuL,next), as defined herein. As illustrated in Figure 11 , in some examples, the next subsequent transmission time may be a time (e.g. slot) immediately after the entry of the next subsequent packet (e.g. TCC traffic) to the transmission queue of the wireless device.

[0159] As illustrated at block 1126 of Figure 11 , in some examples, the network node 10 may perform the HO in response to receiving the next subsequent packet from the wireless device. Performing the HO may comprise allowing the wireless device to detach from the source cell (e.g. and connect to the target cell).

[0160] There is also provided a system (or communications network) comprising the network node 10 as described herein. The system can comprise one or more of the wireless device, as described herein, the target cell, as described herein, the network entity as described herein, and the server, as described herein. A method performed by the system comprises the method described herein in respect of one or more of the network node 10, the wireless device, the target cell, the network entity, and the server.

[0161] There is also provided a computer program comprising instructions which, when executed by processing circuitry (such as the processing circuitry 12 of the network node 10 described herein), cause the processing circuitry to perform at least part of the method described herein.

[0162] In some examples, the network node functionality described herein can be performed by hardware. Thus, in some embodiments, the network node 10 described herein can be a hardware entity. The network node functionality described herein may all be at the same location or at least some of the network node may be distributed, e.g. the network node functionality may be performed by one or more different entities. It will be understood that at least some or all of the method steps described herein can be automated in some embodiments. That is, in some embodiments, at least some or all of the method steps described herein can be performed automatically. The method described herein can be a computer-implemented method.

[0163] Therefore, as described herein, there is provided an advantageous technique for handling HO of a wireless device. In particular, the technique prevents packets from time-critical communication wireless devices becoming late or lost when performing HO. As described herein, one or more reports (e.g. DSRs) can be used to predict traffic pattern (periodicity) of (e.g. TOO) traffic, and the arrival time of the new packets to a wireless device. Based on the traffic pattern, the network node described herein can schedule (e.g. PUSCH) packet transmission soon after a new packet arrives in the transmission queue of the wireless device. In some examples, the network node may also perform functionality to make transmission more robust (e.g. avoid retransmissions). The techniques described herein can be used to ensure that a time remaining until the expiration of a packet to be transmitted by the wireless device is large enough for an HO event to occur without issue.

[0164] It should be noted that the above-mentioned embodiments illustrate rather than limit the idea, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS1 . A method for handling a handover, HO, of a wireless device (500, 900, 1000) from a source cell to a target cell (904, 1004) of a communications network, wherein the method is performed by a network node (10) of the communications network, the method comprising: estimating (302) a HO time, wherein the HO time comprises an amount of time required for the wireless device (500, 900, 1000) to HO to the target cell (904, 1004); receiving (304) one or more reports from the wireless device (500, 900, 1000), wherein each report of the one or more reports comprises information indicative of an expiration time indicating a time remaining until a packet in a transmission queue of the wireless device (500, 900, 1000) expires; and initiating (306) the HO if the estimated HO time is less than a traffic cycle time, wherein the traffic cycle time is determined based on the information comprised in the one or more reports, and wherein the traffic cycle time corresponds to an amount of time between consecutive packets entering the transmission queue.

2. The method as claimed in claim 1 , wherein the communications network can tolerate receiving one or more packets late from the wireless device (500, 900, 1000).

3. The method as claimed in claim 2, the method comprising: initiating the HO if the estimated HO time is less than an amount of time corresponding to a product of the traffic cycle time and a first integer number, wherein the first integer number is determined based on the amount of one or more packets that the communications network can tolerate receiving late.

4. The method as claimed in any of the preceding claims, wherein the information comprised in each report of the one or more reports comprises information indicative of a transmission time of the report.

5. The method as claimed in claim 4, when directly or indirectly dependent on claim 2, the method comprising: if the estimated HO time is greater or equal to the traffic cycle time, initiating the HO procedure if a modified HO time is less than a modified traffic cycle time; wherein the modified HO time comprises at least the estimated HO time; andwherein the modified traffic cycle time comprises the expiration time and an amount of time corresponding to a product of the traffic cycle time and a second integer number, wherein the second integer number is determined based on the number of late packets that the communications network can tolerate receiving late.

6. The method as claimed in claim 5, the method comprising: if the estimated HO time is greater or equal to the traffic cycle time, determining whether the modified HO time is less than the modified traffic cycle time.

7. The method as claimed in claim 5 or 6, the method comprising: if the modified HO time is greater or equal to the modified traffic cycle time, delaying the HO.

8. The method as claimed in claim 7, the method comprising: initiating transmission of a first message towards a server (1006) of the communications network, wherein the first message comprises information indicative of the delay of the HO.

9. The method as claimed in any of the preceding claims, the method comprising: determining the expiration time based on the information comprised in the one or more reports.

10. The method as claimed in any of the preceding claims, the method comprising: initiating transmission of information indicative of the expiration time towards the target cell (904, 1004).

11. The method as claimed in any of the preceding claims, the method comprising: estimating a packet entry time based on the information comprised in the one or more reports, wherein the packet entry time corresponds to a time at which a next subsequent packet will enter the transmission queue of the wireless device (500, 900, 1000).

12. The method as claimed in claim 11 , the method comprising: estimating a subsequent transmission time, wherein the subsequent transmission time corresponds to a time at which the wireless device (500, 900, 1000) is able to initiate transmission of the next subsequent packet.

13. The method as claimed in claim 12, the method comprising: initiating transmission of a second message towards the wireless device (500, 900, 1000) before the subsequent transmission time, wherein the second message comprises pre-scheduling information associated with transmission of the next subsequent packet.

14. The method as claimed in any of the preceding claims, wherein initiating the HO comprises: initiating transmission of a HO command towards the wireless device (500, 900, 1000).

15. The method as claimed in claim 12, when dependent on claim 12 or 13, wherein: the HO command comprises a request for the wireless device (500, 900, 1000) to perform the HO immediately after the subsequent transmission time.

16. The method as claimed in claim 14 or 15, when directly or indirectly dependent on claim 9, wherein: transmission of the HO command is only initiated if the next subsequent packet is received from the wireless device (500, 900, 1000).

17. The method as claimed in claim 16, the method comprising: if the next subsequent packet is not received from the wireless device (500, 900, 1000): delaying transmission initiation of the HO command; and initiating transmission of a third message toward the target cell (904, 1004), wherein the third message comprises information indicative of a delay to transmission initiation of the HO command.

18. The method as claimed in claim 17, the method comprising: if the next subsequent packet is not received from the wireless device (500, 900, 1000): initiating transmission, towards the wireless device (500, 900, 1000), of a request for retransmission of the next subsequent packet.

19. The method as claimed in any of claims 14 to 18, wherein the HO command comprises radio resource control, RRC, configuration information.

20. The method as claimed in any of claims 11 to 19, the method comprising: performing the HO in response to receiving the next subsequent packet from the wireless device (500, 900, 1000).

21. The method as claimed in any of the preceding claims, wherein the traffic cycle time corresponds to an average amount of time between consecutive packets entering the transmission queue of the wireless device (500, 900, 1000).

22. The method as claimed in any of the preceding claims, the method comprising: initiating transmission of information indicative of the traffic cycle time towards the target cell (904, 1004).

23. The method as claimed in any of the preceding claims, wherein the estimated HO time comprises one or more of: an amount of time required for a grant procedure between the wireless device (500, 900, 1000) and the network node (10) to be completed; an amount of time required for a packet to be transmitted from the wireless device (500, 900, 1000) to the network node (10); and a timing margin.

24. The method as claimed in claim 23, when directly or indirectly dependent on claim 3, wherein the modified HO time comprises: the amount of time required for the grant procedure between the wireless device (500, 900, 1000) and the network node (10) to be completed; an amount of time equal to double the time required for a packet to be transmitted from the wireless device (500, 900, 1000) to the network node (10); and the timing margin.

25. The method as claimed in claim 23 or 24, wherein the amount of time required for the grant procedure between the wireless device (500, 900, 1000) and the network node (10) to be completed comprises: an amount of time between transmission initiation of a scheduling request by the wireless device (500, 900, 1000) towards the network node (10), and receipt, by thewireless device (500, 900, 1000), of a response to the scheduling request from the network node (10).

26. The method as claimed in any of the preceding claims, the method comprising: receiving, from the target cell (904, 1004), a response to a request to perform theHO.

27. The method as claimed in claim 26, wherein the HO is only performed if the response received from the target cell (904, 1004) is indicative that the target cell (904, 1004) is able to perform the HO.

28. The method as claimed in claim 26 or 27, the method comprising: initiating transmission of the request to perform the HO towards the target cell (904, 1004).

29. The method as claimed in any of the preceding claims, the method comprising: receiving, from the wireless device (500, 900, 1000), a measurement report.

30. The method as claimed in claim 29, wherein the measurement report comprises information indicative of a measured signal quality of the source cell and / or a measured signal quality of the target cell (904, 1004).

31. The method as claimed in any of the preceding claims, the method comprising: initiating transmission of reporting information towards the wireless device (500,900, 1000), wherein the reporting information is indicative of a criterion for initiating transmission of a report of the one or more reports by the wireless device (500, 900, 1000), wherein the criterion is met if an amount of time until expiry of a first packet in the transmission queue of the wireless device (500, 900, 1000) is less than a threshold amount of time.

32. The method as claimed in claim 31 , wherein the threshold amount of time is configured by the network node (10).

33. The method as claimed in any of the preceding claims, wherein the amount of time required for the wireless device (500, 900, 1000) to perform the HO corresponds to an average time required for the wireless device (500, 900, 1000) to perform the HO.

34. The method as claimed in any of the preceding claims, wherein the one or more reports comprises at least one delay status report, DSR.

35. The method as claimed in any of the preceding claims, wherein the one or more reports comprises a plurality of reports.

36. The method as claimed in any of the preceding claims, wherein: packets received from the wireless device (500, 900, 1000) comprise packets associated with time critical communication, TCC, traffic.

37. The method as claimed in any of the preceding claims, wherein the wireless device (500, 900, 1000) comprises a user equipment, UE.

38. The method as claimed in any of the preceding claims, wherein the communications network is a telecommunications network.

39. The method as claimed in any of the preceding claims, wherein the network node (10) comprises a gNodeB, gNB.

40. The method as claimed in any of the preceding claims, wherein the network node (10) is comprised in the source cell.

41. A network node (10) comprising: processing circuitry (12) configured to cause the network node (10) to: estimate a HO time, wherein the HO time comprises an amount of time required for the wireless device (500, 900, 1000) to HO to the target cell (904, 1004); receive one or more reports from the wireless device (500, 900, 1000), wherein each report of the one or more reports comprises information indicative of an expiration time indicating a time remaining until a packet in a transmission queue of the wireless device (500, 900, 1000) expires; and initiate the HO if the estimated HO time is less than a traffic cycle time, wherein the traffic cycle time is determined based on the information comprised in the one or more reports, and wherein the traffic cycle time corresponds to an amount of time between consecutive packets entering the transmission queue.

42. The network node (10) as claimed in claim 41 , wherein: the processing circuitry (12) is configured to cause the network node (10) to perform the method according to any of claims 2 to 40.

43. A computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method according to any of claims 1 to 40.

44. A computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the method according to any of claims 1 to 40.

Images